לבדיקה לא מקוונת צריכה להיות תוצאה מוגדרת; גיבוב או הדגמת הצפנה אינם ביקורת מלאה של המוצר.
בדיקה לא מקוונת יכולה להראות שחישוב מסוים מתבצע ללא תשובה חיה מהשרת. יש בכך ערך, אך אין זו הוכחה לאבטחת המסנג׳ר כולו. כדי לקבל תוצאה שימושית, יש לתעד במדויק איזה קובץ, גרסה, קלט ופלט נבדקו.
גיבוב קובץ, חתימת מהדורה, וקטור בדיקה, בנייה ניתנת לשחזור וביקורת אבטחה עונים על שאלות שונות. שילוב ראיות מועיל יותר מהפיכת אחת מהן ל״חותמת אבטחה מלאה״.
מה מראה כל ראיה?
| ראיה | מסקנה מוגבלת ונכונה | מה לא מוכח באופן אוטומטי |
|---|---|---|
| SHA-256 של הקובץ | הקובץ תואם לתמצית הייחוס | שמקור הייחוס ישר או שהקוד מושלם |
| חתימת APK | החתימה תקפה לחבילה וקשורה למפתח החותם | שהמפתח שייך למפיץ שאליו התכוונתם, אלא אם הדבר נבדק בנפרד |
| וקטור בדיקה | המקרים המכוסים מפיקים את הפלט הצפוי | שכל המצבים והשגיאות של המוצר מכוסים |
| בנייה ניתנת לשחזור | קוד מקור וסביבה מוגדרים מפיקים פלט זהה | שאין חולשות בקוד המקור |
| ביקורת | היקף וגרסה מוגדרים נבדקו | שגם שינויים מאוחרים ורכיבים מחוץ להיקף אושרו |
ההגדרה של בנייה ניתנת לשחזור מבוססת על קלט וסביבה מוגדרים. הכלי הרשמי apksigner של Android מיועד לבדיקת חתימת APK; פעולה זו אינה זהה לחישוב גיבוב.
מהו היקף Livara Proof Lab כיום?
עמוד Proof Lab מציג כלי מקומי לגיבוב APK והדגמה של פעולות P-256, HKDF ו־AES-GCM, לרבות שינוי סיבית אחת כדי לצפות בכשל בבדיקת האותנטיות. העמוד עצמו מציין במפורש שהשילוב המלא של LVR1/LGS1 נמצא מחוץ לסביבת ניסוי זו.
לכן כתבו את המסקנה הנכונה כך: ״קובץ זה תאם לתמצית הייחוס״ או ״הדגמת הצפנה זו דחתה את השינוי שנבדק״. אל תכתבו ״כל הפרוטוקול ההיברידי וכל הגרסה המותקנת עברו ביקורת עצמאית״. מאמר זה אינו מדווח על בדיקת הרצה חדשה של הכלי.
כיצד מכינים בדיקה לא מקוונת הניתנת לחזרה?
- הגדירו את המטרה. האם ברצונכם לבדוק את זהות הקובץ או את התנהגותה של פעולה קריפטוגרפית?
- תעדו את הגרסה והמקור. שם ה־APK, מספר הגרסה, כתובת ההורדה והתמצית של אותה מהדורה צריכים להיות קשורים זה לזה.
- הכינו את הכלי והקלט ממקור מהימן. ניתוק מהרשת אינו הופך קוד שהיה זדוני מלכתחילה למהימן.
- השתמשו בנתוני בדיקה שאינם רגישים. הדגמת הצפנה אינה דורשת הודעה פרטית או סוד אמיתי.
- נתקו את החיבור וחזרו על הבדיקה. שלב זה בוחן תלות בתשובה חיה, לא את האמון בקוד שכבר הורד.
- תעדו את התוצאה והשגיאות. אל תחליפו הבדל גרסאות, כשל טעינה או פלט שאינו תואם ב״עבר״.
אם הגיבוב שונה, עצרו את ההתקנה ובדקו תחילה את הגרסה, הקובץ ומקור הייחוס. ההבדל עשוי לנבוע מבחירת מהדורה אחרת; ללא בדיקה, אל תקבעו שמדובר בוודאות בנוזקה או בוודאות בדבר חסר חשיבות.
מה ההבדל בין וקטור בדיקה לאישור רשמי?
וקטור בדיקה מגדיר קלט ופלט צפוי של התנהגות מסוימת. אוספים כגון Wycheproof מועילים לבדיקת ספריות מול מקרים הקשורים לתקיפות מוכרות. מעבר שלהם אינו מוכיח כיסוי של מקרים לא מוכרים.
ל־NIST CAVP יש תהליך לאימות אלגוריתמים. הרצת כמה וקטורים ציבוריים בדפדפן אינה זהה לקבלת אישור אימות; גם שימוש באלגוריתם תקני אינו הופך את המוצר למאושר אוטומטית.
מה לבקש כשמשווים מסנג׳רים?
לגבי Livara, Signal, WhatsApp, Session או Element, שאלו אותן שאלות: מהי הגרסה המדויקת? מהו הקובץ הרשמי? כיצד מאמתים את מפתח החותם או את תמצית הייחוס? אילו בדיקות ניתן להריץ? אילו קוד ורכיבים נכללו בדוח הביקורת?
מאמר זה אינו דירוג מבוסס בדיקות של מוצרים אלה. היעדר כלי בעמוד יחיד אינו מוכיח היעדר ראיות אבטחה; גם נוכחותו אינה מוכיחה עליונות של המוצר כולו. השוו את התיעוד הרשמי של אותה גרסה ואת הדוח שניתן לשחזר.
גיליון תוצאות שימושי
בדוח הקצר שלכם כתבו: מטרה, גרסה, מקור הקובץ, גיבוב, כלי וגרסתו, מצב הרשת, קלט שאינו רגיש, פלט צפוי, פלט שנצפה ומגבלות. אם ניסוי אחר לא בוצע, ציינו ״לא נבדק״.
גם אימות המפתח של איש הקשר הוא בדיקה נפרדת. כלי מקומי יכול להדגים פעולה, אך אינו מאמת במקומכם את זהות הצד השני בשיחה או את תקינות הטלפון שלו. קראו את גבולות האבטחה של Livara לצד התוצאות, במקום לראות בציון מושלם בכלי ערובה לכל הגבולות.
