היקף החשיפה תלוי בסוג המפתח ובמשך הגישה של התוקף; ראצ׳ט אינו מבטיח שרק הודעה אחת נמצאת בסיכון.
הצפנה חזקה דורשת גם ביצוע תקין במכשיר. חולשה במערכת ההפעלה, במימוש ההצפנה או בחומרה עלולה לפתוח גישה למידע רגיש; אך מעצם קיומו של מחקר על מתקפות מעבדים אי אפשר להסיק שכל טלפון או יישום מסרים ניתן לפריצה באותה דרך.
השאלה המועילה היא: איזו גישה יש לתוקף, איזה מפתח או טקסט הוא יכול לראות, והאם הגישה זמנית או מתמשכת? התשובות לשאלות האלה חשובות יותר משם האלגוריתם.
מה ההבדל בין ערוץ צד לחילוץ זיכרון?
בחילוץ ישיר של זיכרון, התוקף עשוי להיות מסוגל לקרוא חלקים ממרחב הזיכרון של תהליך או מכשיר. במתקפת ערוץ צד משתמשים בסימנים כגון משך ביצוע פעולות או התנהגות המטמון כדי להסיק מידע. לשתי הדרכים האלה אין בהכרח אותם תנאים מוקדמים או אותן תוצאות.
המחקר המקורי FLUSH+RELOAD בחן התנהגות מטמון ודפי זיכרון משותפים בסביבת ניסוי מסוימת, והדגים חילוץ מפתח מגרסה של GnuPG. תוצאה זו אינה בדיקת אבטחה של Livara או ראיה לפגיעות של כל מעבדי הטלפונים.
| סוג הגישה | השאלה הנדרשת להערכה |
|---|---|
| הפעלת יישום רגיל באותו מכשיר | האם בידוד התהליכים והתנאים המוקדמים למתקפה מאפשרים תצפית? |
| גישה בעלת הרשאות גבוהות למערכת ההפעלה | אילו נתונים או פעולות מפתח זמינים לתוקף? |
| גישה פיזית או מעבדתית | מה מצב הנעילה, דגם החומרה והגנת המפתחות? |
| גישה מתמשכת ליישום | האם התוקף יכול לאסוף שוב טקסט או מפתחות חדשים? |
הביטוי הכללי ״פריצת RAM״ ללא הפרטים האלה אינו הסבר טכני מספק.
כיצד Keystore וחומרה מאובטחת עוזרים?
Android Keystore יכול להגביל את השימוש במפתחות, ובמכשירים מתאימים לבצע פעולות בגיבוי חומרה. בתכנון הזה, אי־יכולת לחלץ מפתח אינה זהה לאי־יכולת של תוקף להשתמש בו: יישום נגוע עשוי, בתנאים מסוימים, לנצל לרעה פעולות מורשות של המפתח, גם בלי לחלץ את הבתים שלו. מדריך Android Keystore.
גם לא כל המפתחות וכל האלגוריתמים נמצאים אוטומטית בחומרה מאובטחת. צריך להגדיר את סוג המפתח, תמיכת המכשיר ואופן השימוש של היישום. האמירה ״המפתח נמצא במכשיר״ אינה מוכיחה לבדה את מיקומו או את רמת ההגנה עליו.
האם מפתח שנחשף חושף רק הודעה אחת?
לפעמים לחשיפת מפתח הודעה עצמאי יש היקף מוגבל. אבל אם התוקף משיג מפתח שרשרת, מצב הפעלה, מפתח זהות, היסטוריה קריאה או כמה מאגרים בזיכרון, התוצאה שונה. לכן אי אפשר לומר ש״לכל היותר הודעה אחת״ בסיכון בלי לציין אילו נתונים נחשפו.
גם החלפת מפתח לכל הודעה אינה בהכרח מנתקת את גישת התוקף. אם המפתחות הבאים נגזרים ממצב שברשותו, או שהוא עדיין נמצא במכשיר, הוא עשוי להגיע גם להודעות הבאות. הגנת העבר ושיקום האבטחה בעתיד הן שתי תכונות נפרדות בעלות הנחות מוגדרות.
אילו מגבלות יש לראצ׳ט ולניקוי הזיכרון?
מנגנון ראצ׳ט יכול לפתח את המפתחות לאורך השיחה. התאוששות אחרי חשיפה דורשת הכנסת מידע חדש שלתוקף אין גישה אליו; עצם שליחת הודעה אינה מוכיחה שהתנאי מתקיים. מפרט Double Ratchet מסביר, לצד ההתאוששות, את הסיכונים של גישה מתמשכת ושל שחזור נתונים שנמחקו.
קיצור משך החיים של מידע רגיש וניקוי מאגרי זיכרון מועילים, אך לא נובעת מכך שום טענה גורפת שכל העותקים ב־RAM נמחקים. יש לבחון ספריות, שפת תכנות ומסלולי הצגה.
מה אפשר לומר על Livara?
עמוד האבטחה של Livara מתאר מבנה היברידי והתפתחות מפתחות ב־LVR1. מאמר זה אינו ניסוי בערוץ צד, ביקורת זיכרון או אישור שכל המפתחות משתמשים ב־Keystore. בפרט, התיעוד הציבורי של מודל האיומים אינו מבטיח הגנה על מכשיר נגוע.
לכן אין לייחס למוצר הבטחות כגון ״נטרול פריצת חומרה באמצעות ההודעה הבאה״ או ״חשיפה של הודעה אחת לכל היותר״ ללא ראיות מוגדרות לאותה גרסה ולאותו תרחיש.
החלטה מעשית למשתמש
עדכנו את מערכת ההפעלה והיישום, בחרו מכשיר עם תמיכת אבטחה פעילה, הימנעו מהתקנות לא מהימנות ומגישה עודפת והשתמשו בנעילה מתאימה. אם יש חשד לפריצה רצינית, החלפת יישום המסרים או שליחת הודעה חדשה אינן תחליף לבדיקה ולניקוי המכשיר.
כשקוראים טענת אבטחה, בקשו ארבעה דברים: הגרסה שנבדקה, גישת התוקף, הנתונים שנחשפו ומגבלות התוצאה. שם של מעבד או תקן הצפנה אינו עונה לבדו על ארבע השאלות האלה.
