גיבוב, חתימה, בנייה הניתנת לשחזור וביקורת עונים על שאלות שונות.
קוד פתוח מאפשר לבדוק את הקוד, אך אינו מוכיח לבדו שהיישום המותקן תואם לאותו קוד או שאין בו פגיעויות. כשמעריכים יישום הודעות, כדאי להפריד בין כמה סוגי ראיות: קוד המקור, תהליך הבנייה, חתימת הקובץ, בדיקות הפרוטוקול ודוח ביקורת.
מה בדיוק מלמדת כל ראיה?
| ראיה | התרומה העיקרית | מה אינה מוכיחה לבדה |
|---|---|---|
| קוד מקור שניתן לקרוא | אפשרות לבדוק את התכנון והמימוש | התאמה לקובץ ההתקנה או היעדר כל הבאגים |
| בנייה הניתנת לשחזור | אפשרות להשוות תוצרים ממקור וסביבה מוגדרים | שהקוד עצמו מאובטח |
| חתימת APK | בדיקת החתימה וקישור הקובץ למפתח חתימה מהימן | שהתנהגות היישום אינה מזיקה |
| גיבוב SHA-256 | זיהוי הבדלים בבתים ביחס לערך גיבוב מהימן | אותנטיות כאשר תוקף החליף גם את הקובץ וגם את ערך הגיבוב |
| וקטור בדיקה | בדיקת התנהגות מסוימת עבור קלט ופלט מוגדרים | כיסוי כל המצבים ונתיבי ההרצה |
| ביקורת עצמאית | ממצאי בדיקה בהיקף ובגרסה מוגדרים | הבטחה קבועה לכל הגרסאות העתידיות |
בנייה הניתנת לשחזור אינה זהה להורדת קובץ בעל גיבוב תואם
לפי ההגדרה של Reproducible Builds, יכולת שחזור עוסקת בבניית תוצר זהה ממקור, סביבה והוראות מוגדרים. אם רק השוויתם קובץ שהורדתם לערך הגיבוב שפרסם היצרן, ביצעתם בדיקת שלמות; עדיין לא בניתם בעצמכם את הקובץ מהקוד.
כדי להעריך טענה ליכולת שחזור, בקשו את גרסת הקוד, התלויות, הוראות הבנייה ודוח של אדם אחר ששחזר את התוצאה. האמירה ״המקור נמצא ב־GitHub״ אינה תחליף לראיות האלה.
איך מפרשים נכון בדיקה של APK?
- הורידו את הקובץ מהמקור הרשמי ועבור גרסה מוגדרת.
- קבלו את ערך הגיבוב ואת פרטי החותם ממקור שאתם סומכים על האותנטיות שלו.
- חשבו את ערך הגיבוב של הקובץ והשוו לערך של אותה גרסה.
- בבדיקה טכנית, אמתו גם את החתימה; הכלי הרשמי apksigner תומך בכך.
- אם גיליתם אי־התאמה, עצרו את ההתקנה ובררו את הסיבה; אל תחתמו מחדש על הקובץ כדי לעקוף את השגיאה.
דוגמה לפקודת בדיקה עבור מומחה שברשותו Android SDK Build Tools:
apksigner verify --verbose --print-certs app.apk
השם app.apk הוא דוגמה בלבד. הצלחת הפקודה אינה מבטלת את הצורך להכיר את המפתח התקף של המפיץ.
מה תפקידו של Proof Lab?
Proof Lab של Livara מציע כלים לבדיקות מוגדרות. קראו מהו ההיקף של כל ניסוי: גיבוב קובץ, דוגמה להסכמה על מפתח ודחיית נתונים ששונו הם שאלות שונות. הדגמה קריפטוגרפית מוצלחת אינה ביקורת על כל היישום המותקן, השרת, העדכונים או ניהול החשבון.
גם מודל האיומים של Livara מציין במפורש שאם תוקף מחליף גם את קובץ ה־APK וגם את ערך הגיבוב המוצג, התאמת הגיבוב לבדה אינה מוכיחה אותנטיות. זו מגבלה כללית של בדיקת גיבוב, ולא תכונה של יישום הודעות מסוים.
מה כדאי לשאול כשקוראים דוח ביקורת?
- איזה ארגון או אילו אנשים ביצעו את הבדיקה, והיכן נמצא הדוח הציבורי?
- איזו גרסה ואיזה commit נבדקו?
- אילו חלקים היו מחוץ להיקף הבדיקה?
- כיצד תוקנו ממצאים חשובים ונבדקו שוב?
- האם הגרסה המותקנת אצלכם היא אותה גרסה או כוללת את תיקוניה?
אל תסיקו מסקנות נחרצות ממילים כמו ״מאושר״ בלי תשובות לשאלות האלה. גם שימוש באלגוריתם תקני אינו שקול להסמכה של המוצר כולו לפי תקן.
המסקנה לבחירת יישום הודעות
קוד פתוח ויכולת אימות אינם מתחרים; הם מספקים ראיות משלימות. העדיפו מוצר שטענותיו מדויקות, ניתנות למעקב ובעלות היקף ברור. לאחר מכן החילו את אותה בדיקה על אופן השימוש שלכם, כגון קבוצות, גרסת אינטרנט, גיבויים ומכשירים מקושרים, במקום להסיק על אבטחה מוחלטת מבדיקה מוצלחת אחת.
