ארנק קריפטו לדסקטופ: היכן דולפים מפתחות פרטיים
מפתח פרטי לעתים רחוקות נגנב מאחסון מוצפן — הוא נלקח במקום שבו הוא כבר מפוענח. המפתח חי בזיכרון התהליך בזמן החתימה, נכנס לדאמפ בעת קריסה ונשאר על הדיסק בטקסט גלוי אם האחסון נשמר ללא הצפנה «כדי שלא יפריע». מדיום עם עותק של קובץ כזה — זה גישה לכל כתובות הארנק, כולל אלו שבעלים כבר שכח.
נקודת כניסה שנייה — החלפת כתובת הנמען. תוסף דפדפן או תהליך צד שלישי בלוח ההעתקה משכתבים את המחרוזת ברגע ההעתקה: התווים הראשונים והאחרונים זהים, לכן אי אפשר לתפוס את אי-ההתאמה בעין. העסקה יוצאת לכתובת זרה ומאושרת בחתימה תקינה — אי אפשר לבטל אותה, והנמען נשאר לא ידוע.
פריצת אחסון היא לרוב לא עניין של פריצה, אלא של גישה. קובץ אחד בתיקייה ברשת, הרשאות קריאה לכל הצוות, גיבוי בענן ללא ביטוי סיסמה. די במקום עבודה נגוע אחד כדי שהעותק ידלוף החוצה יחד עם היסטוריית הפעולות והכתובות שנצברו.
סוג נפרד של בעיות — היעדר יומן. אם הארנק לא מתעד אילו עסקאות נוצרו ומי פתח את האחסון, בירור האירוע מצטמצם לניחושים, ואין במה להוכיח עובדת התערבות חיצונית. אובדן גישה לנכסים מתרחש גם בלי תוקף: סיסמה נשכחת עם עותק יחיד של מדיום או קובץ אחסון פגום סוגרים את הגישה לתמיד.
כל ארבעת התרחישים נסגרים ברמת הארכיטקטורה: בידוד המפתח ממערכת ההפעלה, אישור פרטי החשבון במסך מהימן, הפרדת הרשאות ויומן פעולות מלא. נסביר כיצד זה בנוי ומה בדיוק יש לבדוק בבנייה כזו.
מה נותן ארנק קריפטו לדסקטופ: בידוד מפתחות וחתימה
מפתח פרטי קיים בדיוק במקום אחד — במכשיר המשתמש — והוא לא נכנס לזיכרון של השרת, לא ללוגים ולא לגיבויים. מחוץ להיקף הסיכון יוצא סוג שלם של כשלים: דליפה דרך דאמפ של תהליך, פענוח ערוץ מיורט, גישה של קבלן למסד הנתונים. את זה בודקים בלי לקחת על סמך אמונה — במעקב אחר בקשות אין אף בייט אחד של החלק הסודי.
חתימה מקומית על עסקאות פירושה שגוף התשלום נבנה ונבדק בצד הלקוח, והחוצה יוצא רק התוצאה המוגמרת. השרת פיזית לא יכול ליזום העברה, כי אין בידיו חומר לחתימה — פריצת השרת אינה הופכת לפריצת הכספים.
בדרך אגב מצטמצמות פעולות ידניות: העברה טיפוסית מפסיקה לדרוש ייצוא מפתח, העתקה ואישור דרך חלון צד שלישי.
הפרדת הרשאות מפעילים בנויה על תפקידים: אחד רואה יתרות והיסטוריה, השני מכין תשלום, השלישי מאשר. אף תפקיד לא אוסף ולא חותם על עסקה לבדו, וכל חתימה נרשמת ביומן עם ציון המכשיר והזמן. זה סוגר את התרחיש הפנימי — קנוניה של שני עובדים או טעות של אחד.
סטק Rust ו-Tauri נותן לוגיקה בטוחה לזיכרון ללא מתווך וובי מובנה, לכן משטח התקיפה של האפליקציה קטן יותר מאשר בבניות על מנועים מפורשים, ומשקל ההפצה נשאר מתון.
שחזור גישה מתוכנן מראש: תמונת גיבוי מוצפנת של המפתח, ביטוי מנמוני ונוהל העברה למכונה חדשה — החזרה לעבודה אורכת דקות, ולא התכתבות עם תמיכה. מפתח במקום אחד, חתימה במכשיר, הרשאות מופרדות — כל סעיף נבדק במעמד לפני מסירה.
מצבי אחסון מפתחות: חם, קר, חומרה
מצב אחסון המפתח קובע לא את הנוחות, אלא את מודל האיומים: אותו ארנק קריפטו לדסקטופ עם מפתח בזיכרון התהליך ועם מפתח על מדיום מבודד — אלו שני סוגי סיכון שונים. אנחנו מרכיבים את כל המצבים בלקוח אחד, כדי שהבחירה תיעשה לא לפי העיקרון «בטוח או נוח», אלא לפי משימה ספציפית והיקף פעולות.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| אחסון חם | תשלומים שוטפים, חתימות תכופות על סכומים קטנים | המפתח נגיש לתהליך: פריצת מכונת העבודה חושפת את כל היתרה הזמינה בארנק |
| אחסון קר וחתימה לא מקוונת | רזרבה, יתרות גדולות, פעולות נדירות | מעבירים את העסקה ידנית, אין בקרת יתרה מקוונת, טעות בהעברה אינה ניתנת לביטול |
| חתימת חומרה | אישור כל פעולה במכשיר נפרד | סט מוגבל של רשתות ופורמטים נתמכים של עסקאות, כריכה למכשיר מסוים |
| ריבוי חתימות | כספים משותפים, גזברות, הפרדת תפקידים | הסף ותוכנית השחזור נקבעים מראש, אובדן קוורום עוצר פעולות |
המצבים לא מתחרים, אלא מצטברים: מפתח חם סוגר את הזרימה היומית, קר מחזיק רזרבה, חתימת חומרה מאשרת העברות גדולות, ריבוי חתימות מפזר אמון בין המשתתפים.
בלקוח דסקטופ ב-Rust המפתח לא עוזב את האחסון המאובטח של מערכת ההפעלה, והחוצה מוצא רק תוצאת החתימה — לכן מעבר בין מצבים לא דורש לכתוב מחדש את לוגיקת הארנק.
שלבי הטמעה: ממודל איומים ועד מסירת פתרון
הטמעת ארנק דסקטופ היא לא בניית בינארי, אלא רצף של צעדים ניתנים לבדיקה. הסדר כאן חשוב: אם מתכננים את תוכנית אחסון המפתחות לפני מודל האיומים, יהיה צורך לשנות אותה יחד עם הממשק. להלן — כיצד מתנהלת העבודה מהביקורת ועד מסירת קוד המקור.
- ביקורת של המתאר הנוכחי: עורכים מלאי של רשתות, פורמטי חתימה וארנקים שכבר בשימוש בצוות. בפלט — מפה של מה שמועבר לאפליקציה החדשה ומה נשאר כפי שהוא.
- מודל איומים: מפרטים נכסים, יריבים ותרחישי תקיפה — גניבת מפתח, החלפת עסקה, פריצת בנייה. עבור כל תרחיש קובעים אמצעי הגנה וקריטריון שלפיו הוא יתקבל.
- תוכנית אחסון מפתחות: קובעים היכן חי חומר המפתח — אחסון סודות מערכתי, מכולה מוצפנת או מודול חומרה — וכיצד בנויה החסימה בעת האתחול.
- הגדרת תפקידים והרשאות: מפרידים בין חתימה לצפייה, קובעים אישורים לפעולות גדולות, מגבילים ייצוא מפתחות. את ההרשאות בודקים על אפליקציה עובדת, ולא על תרשים.
- בדיקת שחזור: מריצים תרחישי כשל — אובדן מכשיר, ביטוי שחזור נשכח, פרופיל פגום — ומוודאים שהארנק עולה מגיבוי באופן צפוי.
- מסירת פתרון: קוד מקור, בנייה ניתנת לשחזור, הוראות למנהלי מערכת ונוהל עדכון. צוות הלקוח צריך להוציא את האפליקציה ללא השתתפותנו.
מדיניות גישה, תוכניות אחסון מפתחות ותיעוד
ערכת התיעוד נאספת כך שניתן ליישמה ללא השתתפותנו: קוד מקור, תצורות ותרשימים נמצאים במאגר אחד, התקנות מנוסחות כתרחישים שלב-אחר-שלב עבור תפקיד מסוים. להלן — רשימת מה שהלקוח מקבל לידיו עם מסירת ארנק קריפטו לדסקטופ.
- מדיניות גישה — תפקידי מפעיל, מבקר ומנהל מערכת עם גבולות הרשאה מדויקים: מי חותם על עסקה, מי רק קורא יתרה, מי משנה תצורה.
- תוכניות אחסון מפתחות — היכן נמצא חומר המפתח, כיצד הוא מחולק בין מדיומים ומה קורה בעת פריצה של אחד מהם.
- גיבוי מפתחות — נוהל יצירת עותקים, בדיקת שחזור במתאר נפרד, תנאי השמדת עותקים לאחר הוצאת המפתח משימוש.
- תקנון רוטציה — תדירות החלפת מפתחות ותעודות, הוצאת חומר ישן משימוש, רשימת בדיקה של מהנדס תורן עם סימוני ביצוע.
- הוראות למפעילים — תרחישים שלב-אחר-שלב עם מצב המסכים, ניתוח שגיאות קלט אופייניות ונוהל פעולה בחשד לדליפה.
- תרשימי אינטגרציה — נקודות חיבור הארנק לקטלוג הנכסים, שירות התמיכה ומערכת הדיווח, עם פורמטי החלפה ותיאור כשלים.
- נוהל עדכון וחזרה לאחור — כיצד מוציאים גרסה חדשה, אילו בדיקות היא עוברת לפני מסירה למשתמשים וכיצד לחזור לקודמת ללא אובדן נתונים.
תרשימים ותקנות מתעדכנים יחד עם הגרסה, לכן לאחר המסירה לא מצטברות אי-התאמות בין התיאור לאפליקציה העובדת.
מקרה בוחן: כיצד צמצמנו סוג כשלים בחתימה על עסקאות
הלקוח — שירות תשלומים, שבו מפעילים חתמו על עסקאות מארנק קריפטו לדסקטופ ידנית: המפתח היה בקובץ ליד האפליקציה, את הכתובת והסכום השוו בעין. ברבעון הצטברו 17 אירועי חתימה — מחתימות חלקיות בעת ניתוק הקשר עם אחסון חומרה ועד שתי העברות לכתובת מוחלפת.
מה שינו
החתימה והממשק הופרדו: המפתח נוצר וחי בתוך מודול מאובטח, החוצה יוצא רק ההאש החתום. הליבה ב-Rust עובדת כתהליך מבודד, לכן פריצת חלון האפליקציה לא נותנת גישה לחומר המפתח. בדיקת הכתובת והסכום הועברה למסך של המכשיר עצמו — המפעיל מאשר את מה שהוא רואה, ולא את מה שהדביק בטופס.
כל פעולה — פתיחת אחסון, בקשת חתימה, סירוב, שינוי מדיניות — נכנסת ליומן פעולות עם שרשרת האשים, לכן אי אפשר להחליף רשומה בדיעבד. את מדיניות הגישה השווינו להמלצות OWASP לאחסון מפתחות וחתימת סף.
מה היה בסוף
סוג הכשלים בחתימה הצטמצם משמונה קטגוריות לאחת — נותרו רק כשלי חומרה. זמן שחזור הגישה ירד מכמה שעות לדקות: מפעיל חדש מקבל את חלקו במפתח לפי תוכנית סף, ולא ממתין להנפקה מחדש. חלק הפעולות הידניות ירד מתשע מתוך עשר לאחת — ידנית נותרה רק הקצאת חלק בעת חיבור מפעיל. אי-התאמות ביומן הפעולות מנותחות לפי ציר זמן תוך דקות ספורות.
במה שונה חתימה מקומית מחתימה בשרת?
ההסתעפות ארכיטקטונית ודי נוקשה: המפתח הפרטי או לא עוזב את מכשיר המשתמש, או נשמר בתשתית השירות. במקרה הראשון הלקוח אוסף את העסקה, חותם עליה מקומית ומוסר החוצה אובייקט חתום מוגמר — נתונים לא חתומים הרשת לא רואה בכלל. במקרה השני הלקוח רק מנסח כוונה, והחתימה נוצרת בשרת עם המפתח שלו.
מודל האיומים משתנה מזה באופן עקרוני. חתימה מקומית משאירה נקודת פריצה יחידה — המכשיר עצמו, ומפעיל השירות פיזית לא יכול ליזום העברה.
חתימה בשרת נוחה יותר לפעולות המוניות, אך מוסיפה סוג שלם של כשלים: דליפת חומר מפתח בצד השירות משמעה פריצה של כל הארנקים בבת אחת, וגישה אדמיניסטרטיבית מאפשרת לחתום על תשלום בלי ידיעת הבעלים.
מצב לא מקוון — תוצאה ישירה של חתימה מקומית. העסקה נאספת ונחתמת בלי רשת, השידור מתבצע מאוחר יותר, ואותו מנגנון עומד בבסיס אחסון קר.
את המפתח מחזיקים בסביבה מבודדת: תהליך נפרד עם הרשאות מינימליות, בלי גישה לרשת ולמערכת הקבצים של הממשק, החלפה — רק דרך ערוץ צר וניתן לבדיקה עם אישור מפורש לכל פעולה.
אנחנו מרכיבים לקוח דסקטופ ב-Rust ו-Tauri, שבו החתימה נשארת בצד המשתמש, והשרת אחראי רק לשערים, היסטוריה ושליחת עסקאות לרשת. זה מסיר את האמון במפעיל כתנאי הכרחי לעבודה והופך את התנהגות הארנק לניתנת לבדיקה. נסביר כיצד תוכנית כזו נבנית והיכן עובר הגבול בין הלקוח לתשתית.
ספקות טכניים: גיבויים, ריבוי חתימות, הגירה
לפני תחילת העבודה לקוחות מעלים את אותן שאלות הנדסיות: כיצד בנויה ריבוי חתימות, מה יקרה בעת אובדן מפתח, כיצד תתבצע הגירה לגרסה חדשה. אנחנו עונים בקצרה — תשובות אלו מסירות אי-ודאות עוד לפני הערכת ההיקף.
כיצד מיושמת ריבוי חתימות?
תוכנית סף m מתוך n: המפתח הפרטי לא נאסף בתהליך אחד ולא מונח בשלמותו על אף מכונה. כל צד חותם על העסקה בפרגמנט שלו, הרכבת החתימה הסופית מתבצעת לאחר בדיקת כל החלקים.
כיצד נוצרים גיבויים של מפתחות?
ביטוי מנמוני בתוספת תמונת אחסון מוצפנת: מפתח ההצפנה נגזר מהסיסמה ולא עוזב את המכשיר. את השחזור בודקים על מכונה נפרדת לפני המסירה — כדי שהעותק ייקרא באופן מובטח.
מה עם הגירה לגרסה חדשה?
תוכנית האחסון ממוספרת בגרסאות, העדכון מתבצע באופן טרנזקציוני: בעת כשל בכל שלב הארנק חוזר למצב הקודם, הקובץ הישן נשאר על הדיסק עד לבדיקה מוצלחת.
כיצד מובטחת תאימות?
כתובות, פורמטי חתימה וייצוא מפתחות נשמרים במסגרת תקנים ענפיים — הארנק נקרא על ידי לקוחות אחרים ועובד עם הרשתות הנדרשות ללא ממירים.
כיצד מתבצע תיעוד פעולות?
יומן מקומי עם רוטציה והגנה מפני החלפה: רואים מי ומתי יצר כתובת, חתם על עסקה או שינה הגדרות. סודות לא נכנסים ליומן.
נדון במשימה ונחזור עם תוכנית והערכה
הערכה מדויקת של ארנק קריפטו לדסקטופ נשענת על שלושה דברים: אילו רשתות ונכסים נתמכים, היכן וכיצד נשמרים המפתחות, וכיצד בנוי מחזור הוצאת העדכונים. בלי נתוני קלט אלו נחזיר טווח «מכאן ועד כאן», שאינו אומר דבר. לכן אנו מבקשים מינימום נתוני קלט — לפיהם נבנה תוכנית הטמעה ולוחות זמנים לפי שלבים.
- רשימת רשתות ונכסים בהתחלה, וכן מה מתוכנן להוסיף באיטרציות הבאות.
- דרישות לאחסון מפתחות: קובץ מקומי מוצפן, מודול חומרה, תמיכה בריבוי חתימות.
- פלטפורמות ופורמט אספקה: Windows, macOS, Linux, האם נדרש חילוף עדכונים אוטומטי.
- תרחישי חתימה: שליחה פשוטה, פעולות מרוכזות, עבודה עם אחסון קר.
- מה כבר קיים: אב טיפוס, תרשים ממשק, ספריות שאתם כבולים אליהן.
- מגבלות שלביות — האם יש תאריך שבו נדרש שלד עובד.
בתגובה נשלח תוכנית הטמעה: שלבים, התלויות שלהם, לוחות זמנים משוערים לכל אחד והרכב הצוות. בנפרד נקבע כיצד אנו בודקים את התוצאה — בדיקות לבידוד מפתחות, בניות לכל פלטפורמה, נוהל הפצת עדכונים ללא אובדן נתונים אצל המשתמש.
תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית.