שחזור חשבון, זהות והיסטוריית שיחות הם פעולות שונות; בדקו איזו מהן המוצר באמת תומך בה.
שחזור זהות קריפטוגרפית משחזר את חומר המפתחות המשויך לזהות שלכם במערכת ההודעות. הוא אינו זהה בהכרח לכניסה מחודשת לחשבון, לשחזור כל השיחות או להוכחה שמכשיר חלופי בטוח לשימוש.
גיבוי מוצפן של מפתחות יכול לאפשר לשרת לאחסן חבילה הניתנת לשחזור בלי להחזיק בסוד הנחוץ לפתיחתה. השאלה אם תכנון כזה מגן על המשתמש תלויה ביצירת המפתחות, באימות, בשמירת סוד השחזור ובאופן שבו הלקוח מטפל בזהות ששוחזרה.
שלושה דברים שאנשים מכנים ״שחזור״
| מטרת השחזור | מה צריך לשחזר או לאשר |
|---|---|
| גישה לחשבון | הרשאה להיכנס ולהשתמש בשירות |
| זהות קריפטוגרפית | המפתחות הפרטיים המתאימים או זהות מאומתת חדשה |
| היסטוריית שיחות | נתוני ההודעות וכל המפתחות והמצבים הנדרשים לקריאתם |
כניסה מוצלחת אינה מוכיחה שאחת משתי המטרות האחרות הושגה. באופן דומה, מפתח זהות אינו יוצר בהכרח מחדש מפתחות ישנים של הודעות שנמחקו במכוון, או קובץ היסטוריה שכבר אינו קיים.
רשמו איזו מטרה תכונת השחזור של המוצר באמת מבטיחה להשיג לפני שתסתמכו עליה.
כיצד גיבוי זהות מוצפן עשוי לפעול
בתכנון טיפוסי נוצרים חומרי הזהות במכשיר מהימן, עותק גיבוי מוצפן באמצעות סוד שחזור נפרד, ורק החבילה המוגנת מאוחסנת בשירות. מכשיר חלופי מוריד את החבילה ומשתמש בסוד השחזור באופן מקומי.
השרת עדיין עשוי לשלוט בגישה לחבילה, לצפות בבקשות, למנוע מסירת נתונים או להחזיר גרסה ישנה יותר. הצפנה מאומתת וקישור לגרסה ולזהות עוזרים להתמודד עם סיכוני שינוי מסוימים; זמינות וטיפול בהחזרה למצב קודם דורשים תכנון נפרד. ״מוצפן בשרת״ אינו תשובה מלאה לכל תרחיש של פגיעה בשרת.
מפתח שחזור אקראי בעל אנטרופיה גבוהה וסיסמה שאדם בחר הם גם סוגי קלט שונים. אל תתארו את HKDF כשיטה שהופכת כל משפט סיסמה חלש לסוד חזק. RFC 5869 דן בתפקיד של HKDF ומבדיל בינו לבין חיזוק סיסמאות.
מה אומר התיעוד של Livara v7
דף האבטחה של Livara מציין שמפתחות הסכמת המפתח והחתימה מסוג P-256 וזרע ה-ML-KEM מוצפנים במכשיר במפתח שחזור אקראי של 256 סיביות לפני העלאתם. פורמט v7 מאמת מידע הכולל את חבילת האלגוריתמים, עידן הזהות והדור.
אותו דף אומר במפורש: הוא משחזר זהות, לא היסטוריית שיחות. הוא גם מציין שסיסמת כניסה נכונה לבדה אינה מספיקה לפתיחת גיבוי המפתחות המוצפן; נדרש מפתח השחזור המיוצג באמצעות ביטוי השחזור.
אלה טענות שפורסמו על המוצר, לא ביקורת חדשה של פורמט הגיבוי או של כל מסלולי השחזור. יש לקרוא את מודל האיומים הכללי יותר לצד תיאור השחזור המצומצם הזה.
היכן SRP משתלב
מודל האימות SRP עוסק בכניסה באמצעות סיסמה. הוא יכול למנוע העברה של הסיסמה עצמה במהלך חילופי המידע המיועדים בפרוטוקול, אבל אינו מגדיר את התוכן של גיבוי מפתחות ואינו גוזר אוטומטית כל מפתח שחזור.
ערך האימות בצד השרת עדיין זקוק להגנה. RFC 5054, סעיף 3.3 מתאר את הסיכון לניחוש סיסמה לאחר גנבת ערך האימות. אל תהפכו את ״השרת אינו מקבל את הסיסמה בחילופי המידע האלה״ ל״פריצה לשרת אינה יכולה לחשוף שום דבר מועיל״.
הפעלות החשבון, חבילות השחזור, מטא-נתונים תפעוליים ותוכנת הלקוח הם נכסים נפרדים בעלי אופני כשל נפרדים.
רשימת הכנה בטוחה לשחזור
- ודאו בדיוק אילו נתונים התכונה משחזרת ואילו אינה משחזרת.
- שמרו את סוד השחזור במקום שבו אובדן הטלפון לא יגרום גם לאובדן העותק היחיד.
- הימנעו מהכנסת הסוד להודעה, לפניית תמיכה או לצילום מסך פומבי.
- הגנו על המקום שבו הסוד שמור; מי שישיג אותו עשוי לקבל יכולות משמעותיות אם ישיג גם את הגיבוי הרלוונטי ואת הגישה הנדרשת.
- עיינו בהוראות השחזור הרשמיות לפני מחיקה או החלפה של המכשיר הפעיל היחיד.
- בדקו רק באמצעות הליכים נתמכים, בלי להרוס את העותק היחיד של נתונים חשובים.
לאחר השחזור, בדקו בנפרד מכשירים מקושרים והפעלות. חומר זהות ששוחזר אינו מבטל אוטומטית מכשיר ישן. אם הזהות הקריפטוגרפית משתנה, אנשי קשר שאיתם משתפים מידע רגיש צריכים לאמת את המפתח החדש דרך ערוץ מהימן באופן בלתי תלוי.
אם ביטוי השחזור אבד
אל תניחו שהתמיכה יכולה ליצור מחדש סוד שהמערכת תוכננה שלא לשמור. באותה מידה, אל תניחו שכל סיסמת חשבון שנשכחה פירושה שכל ההודעות המקומיות כבר אבדו. התוצאה תלויה במכשירים שנותרו, בגיבויים הזמינים ובכללים המתועדים של המוצר.
השאלה המועילה היא ממוקדת: ״איזה סוד או עותק חסר, ואיזו מטרת שחזור עדיין אפשרית?״ היא מניבה תשובה בטוחה יותר מהבטחה גורפת שהשחזור הוא קל לחלוטין או בלתי אפשרי.
