סריקה בצד הלקוח בוחנת תוכן במכשיר המשתמש, שבו הוא עשוי כבר להיות קריא לפני השליחה או לאחר הקבלה. לכן היא יכולה ליצור נתיב לחשיפת מידע מחוץ לערוץ המסירה המוצפן. השוואת סכום ביקורת של APK אינה מוכיחה שאין באפליקציה קוד סריקה. היא עונה על שאלה צרה יותר: האם הבתים שנבחרו תואמים לערך גיבוב מסוים.
הפרדה בין הטענות האלה הופכת הן את ההצפנה והן את אימות התוכנה למועילים יותר.
מדוע סריקה במכשיר משנה את גבול הפרטיות
אפליקציה חייבת לטפל במידע גלוי כדי להציג הודעה או להכין תמונה לשליחה. תכונת סריקה יכולה לפעול בשלב הזה, גם אם ההודעה שנשלחת לאחר מכן ברשת מוצפנת מקצה לקצה. מה שיוצא מהמכשיר תלוי בתכנון הסורק: הוא עשוי לדווח על התאמה, להעלות תוכן נבחר או לשלוח מידע נגזר אחר.
המאמר המחקרי Bugs in our Pockets בוחן סיכונים ובהם שימוש לרעה, זיהויים חיוביים שגויים ומשטח תקיפה נוסף. אלה סיבות לבדוק את זרימות הנתונים ואת מנגנוני הממשל של מערכת סריקה מוצעת. הן אינן מוכיחות שכל תכונה במכשיר היא מעקב, או שחוק מסוים הטיל חובת סריקה גורפת.
תכונה מקומית בשליטת המשתמש אינה שקולה אוטומטית לדיווח חובה. שאלו מי בוחר את הניתוח, מה מפעיל אותו, מי יכול לעדכן את כלליו ואילו נתונים יכולים לצאת מהמכשיר.
ארבע צורות שונות של ראיות על תוכנה
| בדיקה | מה היא יכולה לקבוע | מה אינה יכולה לקבוע לבדה |
|---|---|---|
| סכום ביקורת SHA-256 | הקובץ תואם לערך גיבוב מהימן להשוואה | שתוכנת הייחוס בטוחה או תואמת לקוד המקור |
| אימות חתימת APK | חתימת החבילה תקפה ומזהה תעודת חתימה | שהחותם מהימן או שאין בקוד התנהגות לא רצויה |
| בנייה ניתנת לשחזור | קוד מקור וקלטי בנייה מוגדרים יכולים להפיק את התוצרים הצפויים | שאין בקוד המקור פגיעויות או לוגיקה מזיקה |
| סקירה ובדיקות עצמאיות | ממצאים לגבי גרסה והיקף מוגדרים | ערבות קבועה המכסה כל עדכון עתידי |
תיעוד apksigner של Android מסביר אימות חבילות ודיווח על תעודות. ההגדרה של Reproducible Builds מסבירה מדוע קוד המקור, סביבת הבנייה וההוראות חשובים כולם לשחזור תוצר.
ארכיון קוד מקור וסכום ביקורת המודפס לצדו אינם, לבדם, תוצאה של בנייה ניתנת לשחזור. בדומה לכך, חתימה תקפה על מהדורה זדונית היא עדיין חתימה תקפה.
כיצד לבדוק הורדה בלי לייחס לתוצאה יותר ממה שהיא אומרת
תחילה זהו את המהדורה הרצויה והשיגו את ה־APK שלה ואת ערך הגיבוב הצפוי דרך נתיב הפצה מהימן. חשבו את ערך הגיבוב מקומית. אם הוא שונה, אל תתקינו את הקובץ כל עוד אין הסבר לפער: מהדורה אחרת, הורדה חלקית או שינוי זדוני יכולים כולם לגרום לאי־התאמה.
אם הוא תואם, תעדו את המהדורה ואת התוצאה. קבעתם שוויון בתים ביחס לאותו ערך ייחוס, לא היעדר סריקה בצד הלקוח. אם אותו תוקף יכול להחליף גם את ההורדה וגם את סכום הביקורת המוצג, ההשוואה עדיין עשויה להצליח. מקורות ייחוס עצמאיים, המשכיות של מפתח החתימה ושקיפות מהדורות מסייעים לטפל בחלקים שונים של בעיית האמון הזאת.
כדי לבחון טענה על התאמה בין קוד מקור לקובץ בינארי, חפשו הוראות בנייה מתועדות ותוצאות ששוחזרו באופן עצמאי עבור המהדורה עצמה. אל תסיקו את התכונה הזאת מהמילים ״קוד פתוח״.
עדכונים עדיין חשובים
ניתן לתקוף הפצת תוכנה, אך הימנעות מעדכוני אבטחה ללא הגבלת זמן אינה הגנה כללית נבונה. עדכונים גם מתקנים פגיעויות שניתן לנצל. השתמשו בערוץ עדכון מהימן, עיינו בהודעות אבטחה מהותיות ואמתו ראיות לגבי המהדורה כאשר רמת הסיכון שלכם מצדיקה זאת. גרסה ישנה עם פגם ידוע אינה בטוחה יותר רק משום שסכום הביקורת שלה התאים בעבר.
מה Proof Lab של Livara קובעת
Proof Lab של Livara מציעה השוואה מקומית של ערך גיבוב APK והדגמות קריפטוגרפיות בדפדפן. העמוד מציין שאינו מפעיל את מנגנוני ה־ratchet המלאים של LVR1/LGS1 ואינו מהווה ביקורת פרוטוקול. גם מודל האיומים שלה מסביר את המגבלה כשגורם תוקף יכול להחליף גם קובץ וגם את ערך הגיבוב הצפוי שלו.
הבדיקות האלה מועילות במסגרת היקפן. הן אינן מוכיחות שהטלפון שעליו מותקנת האפליקציה נקי מנוזקות, של־Livara יש מהדורות הניתנות לשחזור עצמאי, או שהאפליקציה שלה אינה יכולה להכיל התנהגות שלא נחשפה. קראו בנפרד את תיעוד האבטחה כדי להבין את גבולות ההגנה על הודעות הנטענים בו.
השאלה הנכונה אינה אם תג מסוים אומר ״מאומת״. השאלה היא איזו טענה נבדקה, מול איזה מקור ייחוס מהימן ועבור איזו מהדורה מדויקת.
