תוצאת הבדיקה הפורנזית תלויה במצבם בפועל של המכשיר והמפתחות, ולא רק בשם מסד הנתונים או האלגוריתם.
הצפנה מקצה לקצה והגנה על מידע מקומי הן שתי סוגיות קשורות אך שונות. הודעה המוגנת בדרכה ברשת חייבת להפוך לקריאה כדי להופיע במכשיר. תוצאת בדיקה פורנזית תלויה במצב המכשיר, בסוג הגישה, בגרסת המערכת והאפליקציה ובמיקום המפתחות; שום שם של אלגוריתם אינו קובע לבדו את התוצאה.
לכן יש להיזהר הן מהטענה ״בגישה פיזית הכול נקרא מיד״ והן מההבטחה ״חילוץ לעולם אינו אפשרי״.
בדקו ארבע שכבות הגנה בנפרד
| שכבה | תפקיד עיקרי | מגבלה חשובה |
|---|---|---|
| הצפנת הודעות מקצה לקצה | הגנת התוכן בין מכשירי המשתתפים | אינה מבטיחה את תקינות המכשיר ואת הגנת העותקים המקומיים |
| בידוד אפליקציות | הגבלת הגישה של אפליקציות רגילות למידע זו של זו | גישה בעלת הרשאות גבוהות או חולשה עשויות לשנות את המודל |
| הצפנת קבצים או דיסק | הגנת מידע מאוחסן בתנאים מסוימים | מצב הנעילה וזמינות המפתח חשובים |
| הצפנת מסד נתונים באפליקציה | גבול נוסף להגנת קובץ מסד הנתונים | אופן השמירה והשימוש במפתח מכריע |
תיעוד FBE של Android מבחין בין אחסון התלוי בפרטי האימות של המשתמש לבין אחסון הזמין ב-Direct Boot. מהביטוי ״הטלפון נעול״ לבדו אי אפשר לדעת את מצבם המלא של המפתחות; גם השאלה אם כבר בוצעה פתיחת הנעילה הראשונה לאחר האתחול עשויה להיות חשובה.
מה מוכיח קובץ SQLite?
SQLite הוא פורמט ומנוע אחסון, לא תווית שמראה לבדה אם כל ההגנות קיימות או חסרות. הקובץ עשוי להימצא בשטח מוצפן של מערכת ההפעלה או להיות מוגן בפתרון נפרד.
כמו כן, מחיקת שורה אינה בהכרח מסירה את כל עקבותיה מכל הקבצים. תיעוד SQLite מסביר את הגדרות המחיקה המאובטחת ואת מגבלות הטבלאות הווירטואליות. יש להביא בחשבון גם קבצים נלווים וגיבויים בבחינת מחזור חיי המידע. אין בכך הבטחה לשחזור כל הודעה שנמחקה בכל טלפון.
אל תריצו פקודות תחזוקה של מסד נתונים על מידע אמיתי בלי להכיר את האפליקציה; שינוי ישיר של קובצי האפליקציה עלול להשחית מידע או לשנות ראיות.
SQLCipher ו-Keystore הם פתרונות, לא תעודות חסינות
SQLCipher נועד להצפנה שקופה של מסדי נתונים, אך צריך לקרוא את המפרט לפי הגרסה. עמוד התכנון של SQLCipher מתאר מבנה AES-CBC עם אימות אותנטיות; הצגת גרסת בטא 5 בספטמבר 2026 מתארת מעבר ל-AES-GCM. לכן ייחוס מצב הצפנה אחד לכל הגרסאות אינו מדויק.
גם Android Keystore יכול להגן על מפתח ולשלוט בשימוש בו, אך צריך לברר באילו יכולות ובאיזו רמת חומרה האפליקציה משתמשת בפועל. אזכור StrongBox במאמר אינו ראיה לכך שהמוצר משתמש בו. מדריך Keystore.
גם מפתח שאינו ניתן לחילוץ עשוי בתנאים מסוימים לשמש דרך פעולות מותרות. ״אי אפשר להעתיק את המפתח״ ו״התוקף אינו יכול לפתוח שום מידע״ אינן אותה טענה.
מה תפקידם של RAM ומנגנון ratchet?
הגבלת משך החיים של מפתח ושל טקסט רגיש מפחיתה את מספר הזדמנויות החשיפה. אבל ניקוי מאגר אחד אינו מוכיח שלא נותרו עותקים אחרים בספרייה, בתצוגה מקדימה או בתהליך התצוגה.
גם היקף ההגנה של ratchet משתנה לפי סוג המפתח שנחשף ולפי השאלה אם גישת התוקף נמשכת. מ״מפתח נפרד לכל הודעה״ אי אפשר להסיק שצילום אחד של הזיכרון חושף לכל היותר הודעה אחת. שמירת היסטוריה קריאה במכשיר היא סוגיה נפרדת ממפתחות התעבורה.
מה לא אושר לגבי Livara?
מודל האיומים של Livara אינו מבטיח הגנה על מכשיר נגוע או לא נעול. מאמר זה אינו מאשר באופן עצמאי שגרסה מסוימת של Livara משתמשת ב-SQLCipher או ב-StrongBox, מנקה לחלוטין את ה-RAM או אינה שומרת נתוני שיחות מקומיים. אין לייחס תכונות אלה למוצר ללא דוח בדיקה וראיות למימוש.
כמו כן, חבילת שחזור הזהות בתיעוד האבטחה אינה זהה לגיבוי היסטוריה. בדיקת גיבוב APK ב-Proof Lab יכולה להראות שהקובץ תואם לגיבוב מהימן; תוצאתה אינה ביקורת אחסון או בדיקת הגנה מפורנזיקה.
איזה מידע צריכה לכלול טענה פורנזית תקפה?
בקשו את דגם המכשיר, גרסאות המערכת והאפליקציה, מצב הנעילה, שיטת ורמת הגישה, סוג המידע שהושג ומגבלות הבדיקה. כישלון של כלי אחד בניסוי אחד אינו מוכיח שכל השיטות בלתי אפשריות; גם הצלחה מוגבלת אינה מצדיקה הכללה לכל המשתמשים.
עבור משתמש רגיל, סדר העדיפויות כולל עדכונים, נעילה חזקה, צמצום עותקי מדיה מיותרים ושמירה על דרכי השחזור. באירוע חמור, פנו למומחה מורשה לפני פעולות שמשנות מידע או ראיות.
