חתימה מאובטחת על עסקאות: שילוב Trezor באפליקציית אינטרנט

אינטגרציית Trezor: היכן נשברת חתימת העסקאות

האינטגרציה של Trezor באפליקציית ווב נראית כמו כפתור אחד: המשתמש לוחץ על "אישור", הנתונים נשלחים לארנק החומרה, חוזרת חתימה, והעסקה נשלחת לרשת. המפתח הפרטי לא עוזב את המכשיר — וזה בדיוק המשמעות של חתימת עסקאות באמצעות חומרה. התרשים נשבר, בדרך כלל, לא בקריפטוגרפיה, אלא בממשקים: בנקודות שבהן מצב הארנק ומצב הממשק חלוקים.

הכשל הראשון — ניתוק הקשר עם המכשיר באמצע הפעולה. המשתמש הוסח, המכשיר נכנס למצב שינה, הכבל התנתק כבר לאחר שהחתימה נוצרה. העסקה נשלחת לרשת, ואפליקציית הווב נשארת במצב "המתנה" ומציעה לחזור על הפעולה.

השני — אובדן סטטוס האישור. הלשונית נטענה מחדש, הסשן פג, התשובה מהמכשיר לא הגיעה לשרת, והאפליקציה לא יודעת אם הפעולה בוצעה או לא. בלי יומן מצבים ובלי ההאש של העסקה, אין למשתמש מה להציג, וחתימה חוזרת עלולה ליצור כפילות.

השלישי והיקר ביותר — פער בין מה שנחתם לבין מה שנשלח בפועל. אם כתובת הנמען או הסכום מוזרקים לאחר החתימה, החתימה נשארת תקפה, אבל לרשת נשלחת עסקה זרה. בהמשך נפרט כיצד שלוש הנקודות הללו נסגרות: היכן מתבצעת הצלבה של הפרמטרים, כיצד נשמר הסטטוס ומה קורה בעת ניתוק.

מה משתנה לאחר הטמעת חתימה בחומרה

כל עוד המפתח הפרטי שוכן בתחנת העבודה של המפעיל או במשתני הסביבה של השירות, כל חתימה היא הצלבה ידנית של כתובת הנמען והסכום. שגיאה בתו אחד בכתובת או תוסף שהוחלף בדפדפן מובילים לחתימה על עסקה שאין עוד דרך לבטל.

עם חתימה בחומרה על Trezor, המפתח לא עוזב את המכשיר: האפליקציה מרכיבה את הפעולה, המכשיר מציג את הכתובת והסכום על המסך שלו, והמפעיל מאשר פיזית. זמן אישור הפעולה הופך לצפוי מראש — שניות לאתחול ולהצלבת הפרטים, בלי להמתין לתשובה משירות חיצוני ובלי להעתיק מפתחות בין מכונות.

חלק הפעולות הנדחות עולה במודע: ניסיונות לחתום על כתובת או סכום ששונו נחסמים במכשיר עוד לפני השליחה לרשת. סוג התקלות "החלפת פרטים דרך תחנת עבודה נגועה" מפסיק להתקיים באופן עקרוני — לחתימה עובר רק מה שהמפעיל ראה במו עיניו ואישר.

אפקט נפרד — עמידות התהליך בעת תקלות. אובדן או התקנה מחדש של תחנת העבודה כבר לא חוסמים תשלומים: הגישה משוחזרת באמצעות צירוף השחזור במכשיר חדש, תרשים האינטגרציה וההרשאות בשירות נשארים זהים, ותור הפעולות ממשיך להיות מעובד בלי להנפיק מפתחות מחדש.

אינטגרציית Trezor: אפשרויות ומצבי חיבור

המכשיר מתחבר לאפליקציית הווב ביותר מדרך אחת, והערוץ הנבחר קובע ישירות איזה חלק מהקהל יגיע עד לחתימה. בדפדפנים מבוססי Chromium החתימה מתבצעת ישירות, ובשאר הפלטפורמות נדרש יישום גשר או לקוח נייד. להלן המצבים שביניהם באמת בוחרים בתחילת הפרויקט.

אין מצב אוניברסלי, ולכן בפרויקט אנחנו מבצעים זיהוי יכולות הסביבה ונסיגה מדורגת: קודם מנסים את הערוץ הישיר, ובמקרה של כשל מציגים מסלול ברור — גשר או לקוח נייד. כך המשתמש לא נתקל ב"המכשיר לא נמצא" בלי הסבר.

תאימות הסביבות נבדקת בנפרד: גרסאות דפדפנים, מדיניות של מחשבים ארגוניים, שירותים מקומיים חוסמים, והרשאות גישה למכשיר במערכות הפעלה שונות. כל אחד מהסעיפים הללו הופך לתרחיש בדיקה נפרד — אחרת בפרודקשן מתגלה משתמש שהחתימה אצלו לא עובדת מסיבות שאינן קשורות לקוד.

סדר ההטמעה: מהביקורת ועד המסירה

העבודה מתנהלת באופן סדרתי, והסדר כאן אינו פורמליות: כל שלב עוקב נשען על תוצאה מתועדת של השלב הקודם. אם מתחילים את המימוש לפני שנותח זרם החתימה הנוכחי, את התרשים ממילא יהיה צורך לשנות — אבל כבר על סביבת הבדיקות, כשחלק מהקוד כבר כתוב ונבדק.

1. ביקורת החתימה. מנתחים היכן נוצרת העסקה, באיזה רגע מיושם עליה המפתח ואילו חלקים בזרם רואים את החלק הסגור. מתעדים את הנקודות שבהן החתימה עוברת דרך צד השרת, תוסף הדפדפן או שירות צד שלישי — דווקא הן קובעות את היקף הבנייה מחדש.
2. תכנון התרשים. קובעים מה עובר למכשיר החומרה ומה נשאר באפליקציה, וכיצד מתואר חילופי הנתונים ביניהם. בנפרד מפתחים את תרחישי הכשל: המכשיר נותק, הפעולה נדחתה, כתובת הנמען לא תאמה לצפוי.
3. מימוש. מרכיבים את זרם החתימה בקוד: הכנת הנתונים, אישור במכשיר, החזרת התוצאה ובדיקתה לפני שליחה לרשת. כל שלב מתועד ביומן כך שאפשר לנתח תקלה לפי היומן, ולא לשחזר אותה בעיוורון.
4. בדיקה על סביבת הבדיקות. מריצים תרחישים על רשת הבדיקה: פעולה רגילה, דחייה, ניתוק קשר, ניסיון חוזר, החלפת כתובת. בנפרד בודקים שהאפליקציה אינה יכולה לחתום על פעולה בלי אישור הבעלים.
5. קבלת ההטמעה. חוזרים על תרחישי המפתח בפעולות אמיתיות על מדגם קטן, מצליבים את התוצאה לפני ואחרי, ומתעדים את התנהגות המערכת ביומנים. הקבלה נסגרת בדוח עם רשימת המסלולים שנבדקו והמגבלות הידועות.
6. מסירה. מוסרים תיעוד של זרם החתימה, תרשים הטיפול בכשלים והוראות לתמיכה — כדי שההמשך ימשיך בלעדינו.

מה נשאר אצלכם: תרשים, מדיניות, נהלים

לאחר מסירת האינטגרציה של Trezor נשאר אצלכם לא רק מודול חתימה עובד, אלא גם מערך מסמכים שלפיהם הצוות מפתח ומתפעל אותו בלעדינו. כל נכס נבדק על תרחיש חי: לפיו אפשר להכשיר מהנדס חדש, לעבור ביקורת אבטחה פנימית או להחליף קבלן בלי לאבד את ההקשר.

• תרשים החתימה — מסלול העסקה מההרכבה ועד השליחה לרשת, עם סימונים בנקודות שבהן המפתח הפרטי לא עוזב את המכשיר והאפליקציה מקבלת רק אישור.
• מדיניות גישה — תפקידים, היקף הפעולות לכל אחד מהם, מגבלות על חתימה בודדת ונוהל אישור להעברות גדולות.
• נוהל שחזור — סדר הפעולות בעת אובדן המכשיר או חשיפת המפתח: מי משחזר את הגישה, באילו לוחות זמנים, ומה נבדק לאחר מכן.
• תיעוד תפעולי — חיבור, עדכון קושחה, רוטציית מפתחות, ניתוח תקלות אופייניות עם סיבה ופתרון.
• מפת כשלים — אובדן קשר, חתימה שנדחתה, אי-התאמה בכתובת הנמען: מה עושה המערכת בכל מקרה והיכן זה נראה ביומנים.
• מטריצת אחריות — מי מחזיק גיבויים, מי מאשר הוצאת גרסה חדשה, מי מגיב לתקלה.
• נוהל ביקורת — אילו אירועים מתועדים, באיזה אופן נשמרים וכיצד לייצא אותם לצורך בדיקה פנימית.

המסמכים נמצאים במאגר הקוד לצד הקוד ומנוהלים בגרסאות יחד איתו: בשינוי הבא בתרשים החתימה רואים מיד אילו פרקים התיישנו ודורשים תיקון.

מקרה בוחן: חתימה בחומרה באזור האישי של השירות

מה היה לפני ההטמעה

האזור האישי של השירות חתם על פעולות בעזרת מפתח תוכנה: הוא שכן באחסון הדפדפן או הגיע משירות חיצוני. עד 12% מהפעולות המשתמשים דחו בשלב האישור, וכל מחלוקת התמיכה בחנה ידנית — הבדיקה ארכה שעות.

בתקלות החתימה התערבבו שלוש סיבות: החלפת כתובת הנמען באמצעות תוסף, דליפת מפתח בעת העתקה, ותקלת רשת שנראתה כמו סירוב של המשתמש.

מה שינו

את החתימה העבירו למדיום חומרה Trezor. האזור האישי מרכיב פעולה לא חתומה ומעביר אותה למכשיר, הבעלים רואה את כתובת הנמען והסכום על מסך המדיום ומאשר בלחיצת כפתור — המפתח הפרטי לא עוזב את המכשיר ואינו מגיע לזיכרון הדפדפן אפילו למשך החתימה.

הסירוב מטופל באופן מפורש: אם המדיום הוסר או שהאישור נדחה, הטיוטה נשמרת והפעולה חוזרת לתור, ולא הולכת לאיבוד.

מה נהיה

חלק הפעולות הנדחות ירד מתחת ל-1%, וזמן החתימה הממוצע הצטמצם ממאה ומשהו שניות לעשרים. מתקלות החתימה נעלמו שני סוגים לחלוטין: החלפת כתובת ודליפת מפתח — הכתובת כעת מוצלבת על מסך המדיום, ואין מה להעתיק. נותרה רק העבודה עם הרשת ועם המשתמש עצמו.

במה נבדלת חתימה בחומרה מחתימת תוכנה?

חתימת תוכנה מחזיקה את המפתח הפרטי במקום שבו מורץ הקוד: בזיכרון התהליך, בקובץ התצורה, במשתנה סביבה או באחסון סודות. כל עוד ההיקף שלם, התרשים נוח — החתימה נוצרת באותו מחזור עיבוד של הבקשה, בלי מכשירים חיצוניים ובלי שלבים מיותרים למשתמש.

אבל מודל האיומים כאן נבנה סביב הסביבה: תלות זדונית, גישה לשרת או דאמפ זיכרון מוסרים את המפתח כולו, ומכאן והלאה הוא חי מחוץ לשליטתכם.

חתימה בחומרה מעבירה את המפתח למדיום מבודד — למשל Trezor. העסקה נשלחת למכשיר, הבעלים רואה את פרטיה על המסך שלו ומאשר את הפעולה פיזית; בחזרה חוזרת רק חתימה מוכנה. חשיפת המארח מפסיקה לאיית חשיפת המפתח: התוקף זקוק לגישה למכשיר עצמו ולידע של ה-PIN, והחלפת הנמען נתקלת באישור על המסך.

ההבדל מתגלה במחיר הטעות. בחתימת תוכנה תקלה אחת משמעה אובדן מוחלט של השליטה על הכתובת והגירה דחופה; בחתימה בחומרה התקיפה נתקלת לרוב בצורך לאשר את הפעולה בידיים.

בתרחישי שרת בלי אדם בצד משתמשים בחתימת תוכנה, אבל עם בידוד המפתח והרשאות נפרדות; במקום שבו הבעלים מאשר את הפעולות, הגרסה בחומרה מסירה סוג שלם של כשלים.

ספקות טכניים לפני חיבור המכשיר

בשלב התיאום עולה אותה קבוצת שאלות: האם אפשר לחבר חתימה בחומרה לא עבור כולם בבת אחת, מה יקרה בעת אובדן המכשיר, האם יידרש שינוי בצד השרת ואילו סביבות יהיה צורך לתמוך. להלן תשובות קצרות, כדי להסיר את הספקות הללו לפני תחילת העבודה.

מה יקרה בעת אובדן המכשיר?

המפתחות לא עוזבים את המכשיר ולא נשמרים בשרת, ולכן השחזור מתבצע באמצעות צירוף השחזור בעותק חדש: הקישור מאושר מחדש, היסטוריית הפעולות נשמרת. תרחיש של אובדן הצירוף עצמו אנו מתארים מראש — הנפקת מפתחות מחדש והעברת נכסים מתבצעות לפי נוהל, ולא במצב חירום.

האם נדרש שינוי בצד השרת?

כן, זה לא רק הממשק. צד השרת מקבל פורמט חתימה חדש ומערך מפתחות ציבוריים, בדיקת כתובות נמען והגנה מפני שימוש חוזר באותה חתימה. היקף התיקונים תלוי בארכיטקטורה: אם העבודה עם החתימה כבר הועברה לשכבה נפרדת, השינויים מקומיים ואינם נוגעים בלוגיקה העסקית.

אילו סביבות יהיה צורך לתמוך?

דפדפנים שולחניים עובדים דרך יישום גשר, תרחישים ניידים נבנים אחרת ויש להם מגבלות בסוג החיבור. מטריצת הסביבות הנתמכות וההתנהגות בהיעדר מכשיר מתועדות לפני הפיתוח — המשתמש מקבל מסלול חלופי ברור במקום מבוי סתום.

נדון במשימה ונחזור עם הערכה ותוכנית

כדי שהניתוח של אינטגרציית Trezor באפליקציית ווב יתחיל מעובדות ולא מניחושים, די לשלוח את מה שכבר קיים בפרויקט. ככל שהחומרים קרובים יותר לקוד האמיתי ולנתוני החשבונאות, כך יהיו פחות סבבי הבהרה עד לתוכנית ההטמעה.

• תרחישי חתימה: העברה, משיכת כספים, החלפת בעלים, עבודה עם חוזה חכם — והיכן נשמרים המפתחות כעת.
• תרשים הזרימות: פרונטאנד, בקאנד, צמתי רשת, אחסון כתובות ומגבלות — בתיאור או בתרשים.
• מודל החשבונות: כיצד קשורים המשתמש, המכשיר ומערך הכתובות, וכיצד נפתר שחזור הגישה.
• מגבלות: דפדפנים ופלטפורמות נתמכות, דרישות לחתימה לא מקוונת ולמדיניות אבטחה.
• בדיקות נוכחיות: מה כבר מתועד ביומן ואילו פעולות דורשות אישור במכשיר.
• קו בדיקה: הרשאות לרשת הפיתוח, מפתחות בדיקה, דוגמאות עסקאות להרצה.

בתגובה מגיעים הבהרות לנקודות השנויות במחלוקת, תרשים עבודה עם גבולות אחריות ותוכנית הטמעה לפי שלבים: חיבור המכשיר, הרכבת עסקה לא חתומה, בדיקת הכתובת והסכום על המסך, והחזרת החתימה לרשת.

בנפרד נתאם את הרכב הצוות: מי אחראי על הפרונטאנד, מי על צד השרת והרשת, ובאילו נקודות נדרש המהנדס שלכם. לאחר מכן נתעד את סדר העבודה ואת הקריטריונים שלפיהם תקבלו את התוצאה.