מדוע ארנק HD נייד מאבד גישה לכספים
ארנק HD נייד מחזיק את כל הגישה לכספים בסוד שורשי אחד: ממנו נגזרת באופן דטרמיניסטי שרשרת מפתחות לכתובות, והמשפט המנמוני נשאר הנשא היחיד שאפשר לשחזר במכשיר אחר. כל עוד האפליקציה חיה בטלפון אחד, הסכימה אינה מורגשת. התקלה מתגלה ברגע השחזור או העדכון ונראית כמו יתרה שנעלמה, אף שהכספים לא הלכו לשום מקום.
הסיבה הנפוצה ביותר — חוסר סנכרון של אינדקס הכתובות. הארנק מקצה למשתמש כתובת חדשה לקבלה, אבל בזמן השחזור סורק פחות מיקומים ממה שבפועל נעשה בהם שימוש, ועוצר בפער הריק הראשון.
העסקאות ברשת קיימות, אבל בממשק מוצג אפס: המשתמש תופס זאת כאובדן גישה ופונה בתלונה למוצר, ולא לגיבוי שלו עצמו.
מחלקת תקלות שנייה — שרשרת מפתחות שנעשה בה שימוש חוזר. התקנה מחדש מעל פרופיל ישן, שני עותקים של האפליקציה שכותבים לאותו אחסון מקומי, או גיבוי שנלקח בצורה לא מלאה, מובילים לכך שהכתובות מתפצלות, וחלק מההיסטוריה נשאר מחוץ לענף הנוכחי. הנורמה בתחום כאן — תקני משפחת BIP: הם מגדירים את כללי הגזירה, אבל לא מגנים מפני טעויות ביישום שלהם.
התקלה השלישית — הגירה לא תקינה בין גרסאות של האחסון. סכימת ההצפנה או נתיב גזירת המפתחות משתנים, רשומות ישנות אינן נקראות, האפליקציה עולה עם פרופיל ריק ואינה מודיעה על כך במפורש. בהמשך נבחן כיצד התרחישים האלה נסגרים ברמת ארכיטקטורת האחסון וניהול הכתובות.
מה משנה תכנון מחדש של ארכיטקטורת הארנק
תכנון מחדש של ארכיטקטורת הארנק משנה את האופן שבו ארנק HD מאחסן חומר מפתח, משחזר מצב ומסתנכרן עם הרשת. התוצאה נמדדת בדקות של השבתה ובמספר התרחישים שהופכים לבלתי אפשריים.
שחזור גישה בדקות ספורות במקום התכתבות עם התמיכה
בבסיס — משפט מנמוני וגזירה דטרמיניסטית של כתובות: המשתמש מזין אותו במכשיר חדש ומקבל את אותה קבוצת כתובות בלי לפנות לתמיכה. זמן שחזור הגישה יורד משעות של התכתבות לכמה דקות. אנחנו בודקים:
- התקנה מחדש והזנת המשפט מחזירות את כל הכתובות והיסטוריית הפעולות; התרחיש מכוסה בבדיקה אוטומטית במכשיר נקי.
- ההוראה למקרה «איבדתי טלפון» נמצאת באפליקציה, ולא בהתכתבות עם התמיכה.
- לאחר החזרה לרשת, הבלוקים שהוחמצו מדביקים פערים בלי התערבות ידנית.
מחלקת כשלים שטופלה: דליפת מפתח בגיבוי
גיבוי מפסיק להעתיק מפתחות פרטיים: נשמר רק מכל מוצפן או המשפט שהמשתמש שומר בנפרד. זה מסיר מחלקת כשלים שלמה — חשיפת מפתח דרך עותקים בענן וצילומי מערכת של המכשיר. את הדרישות אנחנו מצליבים עם מדריכי אבטחה חיצוניים, למשל OWASP Mobile Application Security. רשימת בדיקה:
- מפתחות אינם נכנסים לעותקים בענן ולצילומי מערכת.
- עמידות ההצפנה נבדקת בבדיקות לסיסמאות חלשות וחוזרות.
- חזרה לגרסה קודמת של האפליקציה אינה שוברת את הגישה לכתובות שנוצרו.
מצבי אחסון מפתחות: השוואת גישות
מצב אחסון המפתחות הפרטיים מגדיר את מודל האיומים: היכן חי המפתח, מי חותם בו ומה יקרה בעת חשיפת המכשיר. להלן חמישה вариантов, שביניהם באמת בוחרים בתכנון ארנק HD.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| מפתח בזיכרון האפליקציה | אב טיפוס, סביבה סגורה, אין דרישות לעמידות | המפתח נכנס לדאמפ זיכרון, אין הגנה במקרה של אובדן המכשיר |
| מפתח באחסון מאובטח של המכשיר | ארנק המוני: המפתח קשור למכשיר | שחזור רק באמצעות משפט מנמוני, תלות בפלטפורמה |
| חותם חיצוני | החתימה מועברת לרכיב נפרד | נדרש ערוץ מאובטח, זמן השהיית החתימה גדל |
| ריבוי חתימות עם הפרדת תפקידים | תרחישים ארגוניים, שליטה בלעדית אינה אפשרית | מורכב יותר לנהל תפקידים ולשחזר בעת אובדן חלק |
| מצב צפייה בלבד | מעקב אחר יתרה והיסטוריה בלי חתימה | אין חתימה בתוך האפליקציה, תלות בחתם |
מתי כל מצב מוצדק
לארנק צרכני מספיק מפתח באחסון מאובטח של המכשיר ומצב צפייה במכשיר שני. סכימות ארגוניות דורשות ריבוי חתימות עם הפרדת תפקידים, ושירותים עם משיכת כספים אוטומטית — חותם חיצוני. המצבים משולבים: צפייה בלי הרשאת חתימה ניתנת לתמיכה ולאנליטיקה.
עלות טעות בבחירת מצב
הטעות אינה נראית בבדיקות: האפליקציה עובדת, העסקאות עוברות. היא נחשפת ברגע האירוע — באובדן המכשיר, בדליפת גיבוי או בעזיבת עובד עם מפתח. תיקון מחדש נוגע בגזירת הכתובות ובהגירה של ארנקים שכבר נוצרו, ולכן את המצב מקבעים לפני הגרסה הראשונה.
שלבי העבודה: ביקורת, סכימת מפתחות, בדיקה, מסירה
סדר העבודה בנוי כך שהחלקים הבלתי הפיכים — סכימת המפתחות ומודול החתימה — יתוכננו רק אחרי שאנחנו מבינים את האחסון הנוכחי ואת דרישות השחזור. להלן הרצף שבו מתנהל הפרויקט: כל שלב מסתיים בארטיפקט שאפשר לבדוק לפני המעבר לשלב הבא.
- ביקורת ארנק. מפרקים את אחסון הסודות הנוכחי, את אופן קבלת הכתובות, יומני הפעולות ואת הדרך שבה היום משחזרים גישה בעת אובדן המכשיר. הפלט — מפת צווארי בקבוק ורשימת החלטות שאין לשנות אחרי הגרסה.
- סכימת מפתחות. מקבעים את עץ המפתחות ואת נתיבי הגזירה שלהם, מקצים ענפים לרשתות ולסוגי כתובות, מתארים את סדר גזירת המשפט המנמוני ואת כללי אחסונו. כאן גם מגדירים אילו מפתחות בכלל לא יוצאים מהאזור המאובטח של המכשיר.
- מודול חתימה ומדיניות גישה. מממשים חתימת עסקאות בתוך מודול מבודד, מגדירים מגבלות, אישור לפעולות גדולות והפרדת הרשאות בין תפקידים. יומן החתימה אינו מכיל סודות, אבל מאפשר לשחזר את כרונולוגיית האירועים.
- שחזור והגירה. מתארים העברת ארנק למכשיר חדש, החלפת סיסמה וחזרה תקינה למצב הקודם אם העדכון נפסק. בודקים שכתובות שנוצרו קודם נשארות נגישות.
- בדיקה בתרחישי כשל. מריצים אובדן מכשיר, ניתוק קשר באמצע עסקה, אחסון פגום והתקנה מחדש של האפליקציה. לכל תרחיש יש תוצאה צפויה והתנהגות ממשק ברורה.
- מסירת תיעוד והדרכה. מוסרים את סכימת המפתחות, מדיניות החתימה, הוראות שחזור וניתוח המגבלות הידועות. מעבירים הדרכה לצוות כדי ששינויים יבוצעו לפי נוהל, ולא בתיקון תוך כדי תנועה.
ארטיפקטי מסירה: סכימות, מדיניות, נהלים
המסירה אינה מסתיימת בהעברת מאגר הקוד. אצל הלקוח צריך להישאר סט מסמכים שלפיו המהנדסים שלו יוכלו לבנות גרסה, להעניק גישה לעובד חדש ולשחזר ארנק משתמש בלי אנחנו.
החלק הטכני
- סכימת שרשרת המפתחות: כיצד מהמשפט המנמוני נגזרים ענפים למטבעות ולחשבונות, אילו נתיבים נחשבים ראשיים ואילו שמורים לכתובות שירות.
- תצורת מודול החתימה: פרמטרים לגזירת מפתחות, מצב הצפנה של האחסון המקומי, כללי אישור פעולות ומגבלות שמעליהן נדרש אישור נוסף.
- מדיניות גישה לאחסון: מטריצת תפקידים שבה חתימה וייצוא גיבוי אינם זמינים לאדם אחד, והפעולות נכתבות ליומן בלתי ניתן לשינוי.
- הוראות הגירה: סדר העברת ארנקים קיימים והזנה מחדש של המשפט המנמוני כך שהכתובות והיתרות יישארו כשהיו.
החלק הארגוני
- נוהל שחזור גישה: תרחישים נפרדים למכשיר שאבד, לסיסמה שנשכחה ולגיבוי שאבד חלקית — עם ציון מי מבצע כל שלב ובאיזה מועד.
- סדר ביטול ורוטציה של מפתחות: מה נחשב לחשיפה, מי מקבל החלטה על החלפה, כיצד מוציאים כתובות ישנות משימוש ומה קורה לפעולות שלא הושלמו.
- רשימת בדיקה לגרסה: בדיקות בנייה ברשת בדיקה, השוואת סכום ביקורת של המילון, הרצת שחזור מגיבוי ובדיקות סופיות לפני פרסום בחנויות האפליקציות.
הסט מנוהל יחד עם הקוד: שינוי בסכימת המפתחות או במדיניות הגישה מחייב עדכון של המסמך באותו שינוי, אחרת הוא מאבד תוקף.
מקרה בוחן: שחזור גישה בלי הוצאה מחדש של האפליקציה
ארנק HD לא-משמורתי מאחסן מפתחות רק במכשיר, ולכן אובדן גישה אינו תקלת שרת, אלא תרחיש שחזור: המשפט המנמוני, סדר המילים, בחירת סכימת מפתחות נגזרים מתוך Bitcoin Improvement Proposals.
דווקא בשלב הזה הצטברו הבעיות אצל הלקוח: לוגיקת החתימה עבדה, אבל לעיתים קרובות המשתמש לא הצליח להחזיר לעצמו את הארנק.
מה היה לפני
חלק הפניות לתמיכה בעקבות אובדן גישה היווה כרבע מכלל הפניות. השחזור נעשה ידנית: התכתבות, צילומי מסך, מהנדס השווה מילים וניסה ידנית וריאציות של סכימות מפתחות נגזרים, וענה בממוצע לאחר כמה ימים. בניסיון הראשון החזירו גישה לפחות ממחצית הפונים — האחרים כתבו שוב, וחלק עזבו ולא חזרו.
מה קרה אחרי
הוספנו ניתוח שלב-אחר-שלב של המשפט: נרמול קלט, רמזים לפי המילון ואבחון מפורש — איזו מילה לא עוברת בדיקה ולמה. סכימת המפתחות הנגזרים נבחרת אוטומטית לפי רשימת המוכרות, והמשתמש מיד רואה וריאנט עם יתרה שאינה אפס.
זמן השחזור הצטמצם לכמה דקות, שיעור הניסיונות המוצלחים בניסיון הראשון עלה ל-96%, והיקף הפעולות הידניות בתמיכה ירד בסדר גודל.
ההגירה עברה בלי הוצאה מחדש של האפליקציה: השתנה רק מודול השחזור, הוא הגיע עם עדכון שגרתי, והארנקים הקיימים המשיכו לעבוד כמו קודם. תרחיש דומה ניתחנו בפרסום — תיאור ההטמעה והמדידות לפני ואחרי.
במה ארנק HD שונה מארנק עם כתובת אחת
ארנק HD — זה לא «הרבה ארנקים באחד», אלא זרע אחד שממנו נגזר באופן דטרמיניסטי עץ מפתחות. ארנק עם כתובת אחת מאחסן זוג יחיד: החליף כתובת — קיבל ארנק חדש וגיבוי חדש. בארנק HD הזרע מקודד במשפט מנמוני, והמפתחות נגזרים לפי נתיבים — חשבון, מטבע, ענף, אינדקס.
שחזור. משפט אחד מספיק כדי להחזיר את כל העץ, כולל כתובות שהאפליקציה עוד לא הציגה — והגיבוי לא גדל עם מספרן. בארנק בודד הגיבוי נשאר קומפקטי בדיוק עד הכתובת החדשה הראשונה: بعده צריך להוציא אותו מחדש, והגרסה הקודמת הופכת בשקט לאשפה.
פרטיות עסקאות. כתובת אחת מקשרת את כל התקבולים לשרשרת גלויה אחת: צופה חיצוני מחבר מחזור, צדדים נגדיים ויתרה. כתובת חדשה לכל תקבול מנתקת את הקשר — את ההיסטוריה אפשר להרכיב רק מסימנים חיצוניים, ולא ממבנה הארנק.
התמיכה במשתמשים משתנה בהתאם: משפט אחד סוגר את התרחיש «איבדתי מכשיר», אבל גדלה העלות של טעות בנתיב הגזירה ובבחירת הרשת — כשהמשפט תקין לכאורה, האדם רואה יתרה ריקה.
| מאפיין | כתובת אחת | ארנק HD |
|---|---|---|
| שחזור | לפי מפתח, את הגיבוי מעדכנים בעת החלפה | משפט אחד מחזיר את כל העץ |
| שימוש חוזר בכתובות | אחת לכל הפעולות | חדשה לכל תקבול |
| נפח הגיבוי | קבוע, מתיישן בעת החלפה | לא גדל עם מספר הכתובות |
| פרטיות עסקאות | התקבולים מקושרים לשרשרת | הקשרים מנותקים לפי כתובות |
| מורכבות התמיכה | פניות פשוטות, אובדן גישה תכוף | פחות אובדנים, עלות גבוהה יותר לטעויות בנתיבים |
שאלות טכניות נפוצות וגבולות ישימות
להלן חמש שאלות שעולות לרוב לפני ההתחלה. הן נוגעות לא לבחירת טכנולוגיות, אלא לגבולות האחריות: מהתשובות תלויות גם הארכיטקטורה וגם האופן שבו האפליקציה תתנהג שנה אחרי הגרסה.
מפתחות פרטיים אינם יוצאים מהמכשיר של המשתמש: החלק השרתי אחראי רק לשערים ולאגרגציה של יתרות. זה מגביל חלק מהתרחישים, אבל מסיר מחלקת סיכונים שלמה — דליפה דרך השרת שלנו.
כבר הוצאנו אפליקציה — צריך לכתוב אותה מחדש מאפס?
לא. אנחנו מסתכלים על סכימת אחסון המפתחות ופורמט הכתובות הנגזרות: אם הם תואמים לתקן, הליבה נשארת, ומשתנים שכבות העבודה עם הרשתות והממשק. כדאי לכתוב מחדש רק ליבה שלא מאפשרת גישה למפתחות נגזרים.
מי שומר את המפתחות של המשתמש?
רק המשתמש עצמו. משפט seed נוצר במכשיר ונמצא באחסון מאובטח, אין לנו עותק — אנחנו פיזית לא יכולים לשחזר גישה במקום המשתמש. לכן אנחנו מטמיעים גיבוי כבר בהפעלה הראשונה, ולא מחביאים אותו בהגדרות.
מה יקרה בעת אובדן המכשיר?
השחזור מתבצע לפי משפט seed במכשיר חדש: הכתובות נגזרות מחדש מאותו שורש, והיתרות נמשכות מהרשת. מצדנו לא נדרש דבר, אבל התרחיש הזה נבדק בנפרד — הוא נבדק אחרת מאשר כניסה רגילה.
איך מוסיפים רשתות חדשות?
באמצעות תיאור הרשת ונתיב המפתח הנגזר: הליבה לא משתנה, מתווספים תצורה ומודול חתימת עסקאות של הרשת הזאת. אם לרשת פורמט כתובות או חתימה שונה, היקף העבודה מוערך בנפרד.
איך נבדקת תקינות יצירת המפתחות?
בהשוואה לוקטורי בדיקה ייחוסיים: אותו seed חייב לתת אותן כתובות לפי BIP-39 ו-BIP-44. בנוסף, סט בדיקות לשחזור — טעות במפתח הנגזר גורמת לאובדן גישה בלתי הפיך, ולא לשגיאה מובנת בלוגים.
נדון במשימה ונחזור עם הערכה ותוכנית
הניתוח מתחיל מהסכימה שלכם לאחסון: כיצד נוצר המשפט המנמוני, היכן חיים המפתחות, כיצד חותמים על עסקאות ומה כבר מכוסה בבדיקות. מהפרטים האלה תלויים היקף העבודה ואילו סיכונים עוברים לדרישות ההגנה.
לאחר הפנייה תקבלו:
- ניתוח של הסכימה הנוכחית לאחסון מפתחות וגזירת כתובות — מה משאירים, מה בונים מחדש לפי BIP-39/BIP-44;
- רשימת סיכונים: דליפת המשפט המנמוני, הגנה חלשה על האחסון המקומי, היעדר בדיקות בשחזור;
- וריאנט ארכיטקטורת ארנק — קו חם וקו קר, בידוד מפתחות, עבודה עם הרשת;
- רצף עבודה ותוכנית הטמעה עם תוצאה ניתנת לבדיקה בכל איטרציה;
- הרכב הצוות: מפתחים לפלטפורמות מובייל, מהנדס קריפטוגרפיה, בודק;
- פורמט מסירה — תיעוד, בניות, סדר עדכונים ותמיכה;
- לוחות זמנים: טווח עם הנחות שעליהן הוא נשען, ולא מספר נוח אחד.
כמה שמדויק יותר תתארו את הסכימה הנוכחית והמגבלות, כך יישארו פחות הנחות בהערכה. תארו את המשימה — נחזור עם הערכת העבודה, לוחות זמנים ותוכנית הטמעה.