סכום ביקורת מתאים בתים לערך ייחוס. חתימה קושרת שלמות למפתח. אף אחד מהם אינו מוכיח לבדו שהתוכנה בטוחה.
לפני שמתקינים קובץ APK ל־Android, יש להבחין בין שלוש בדיקות: האם הקובץ הזה תואם למהדורה הצפויה? האם הוא נחתם במפתח הצפוי? האם גורמים עצמאיים יכולים לשחזר אותו מקוד המקור המוצהר? סכום ביקורת מסוג SHA-256, חתימת APK ובנייה הניתנת לשחזור עונים על השאלות האלה בדרכים שונות.
אף אחת מהן אינה קביעה עצמאית בשאלה אם התוכנה זדונית. גם תוכנה שנחתמה כראוי וניתן לשחזר את בנייתה עלולה להכיל חולשת אבטחה או התנהגות מזיקה במכוון.
מה כל שיטת אימות מוכיחה
| בדיקה | תוצאה שימושית | מגבלה חשובה |
|---|---|---|
| ערך גיבוב SHA-256 של הקובץ | הבתים שברשותכם תואמים לערך גיבוב מסוים ממקור מהימן | תוקף שמחליף גם את הקובץ וגם את ערך הגיבוב יכול לסכל את ההשוואה הזאת |
| אימות חתימת APK | חתימת החבילה מאומתת באמצעות תעודת החתימה שלה | צריך לברר מהו מפתח החתימה הצפוי; תקפות החתימה כשלעצמה אינה מאמתת את זהות המפרסם |
| השוואת בנייה הניתנת לשחזור | ניתן ליצור מחדש את התוצר המסוים מתוך קלטים מתועדים | התאמה בין קוד המקור לקובץ הבינארי אינה מוכיחה שקוד המקור בטוח |
| סקירת אבטחה | נבדקו סוגיות מסוימות בתכנון או במימוש | יש חשיבות להיקף הבדיקה, לגרסה, לממצאים ולבעיות שלא נפתרו |
Android מחייבת חתימה על קובצי APK לצורך התקנה ועדכונים. באמצעות Play App Signing, Google יכולה לנהל את מפתח החתימה של האפליקציה וליצור קובצי APK להפצה מתוך חבילת app bundle. אלה הסדרי אמון מתועדים, ולא ראיה לכך שכל גורם מתווך יכול לשנות חבילה בחשאי תוך שמירה על תקפות החתימה שלה. המדריך של Android לחתימה על אפליקציות.
שלב 1: זהו את התוצר המדויק
תעדו את גרסת האפליקציה, ערוץ ההפצה, שם הקובץ וגרסת הפלטפורמה הייעודית שעבורה הוא נועד. השתמשו בדף ההפצה הרשמי של המפרסם, ולא בסכום ביקורת שהועתק מאותה הודעה לא רצויה שסיפקה לכם את ה־APK.
APK שהורד ישירות מהמפרסם עשוי להיות שונה מ־APK שחנות אפליקציות יצרה עבור מכשיר מסוים. הבדלים בגרסאות, בארכיטקטורות, באריזה או בהסדרי החתימה יכולים להניב באופן לגיטימי ערכי גיבוב שונים לקבצים. ודאו שאתם משווים תוצרים מקבילים לפני שאתם רואים באי־התאמה ראיה לשינוי לא מורשה.
השאלה המעשית היא: מה מקורו של הערך הצפוי, ומדוע אני סומך על המקור הזה? חישוב ערך גיבוב ללא חיבור לרשת אינו פותר את בעיית האמון בערך ייחוס שהתקבל דרך האינטרנט.
שלב 2: חשבו SHA-256 באופן מקומי
החליפו את messenger.apk בשם הקובץ שהורדתם. הדוגמאות האלה קוראות את הקובץ; הן אינן מתקינות אותו.
Linux:
sha256sum messenger.apk
macOS:
shasum -a 256 messenger.apk
שורת הפקודה של Windows:
certutil -hashfile messenger.apk SHA256
השוו את ערך הגיבוב במלואו, תוך התעלמות רק מרווחי תצוגה ומהבדלי אותיות גדולות וקטנות. אל תשוו רק את התווים הראשונים או האחרונים. שמרו את ערך הגיבוב הצפוי לצד פרטי המהדורה והגרסה, כדי שיהיה אפשר לחזור על ההשוואה.
אם הערכים שונים, עצרו לפני ההתקנה. בדקו את התוצר ואת הגרסה, הורידו שוב מהמקור המהימן אם יש בכך צורך, ופנו למפרסם לגבי אי־התאמה שאין לה הסבר. אל ״תתקנו״ את סכום הביקורת הצפוי כך שיתאים לקובץ שהגיע לידיכם.
שלב 3: בדקו את חתימת ה־APK
למשתמשים שבידיהם Android SDK Build Tools, התיעוד של apksigner מטעם Google מסביר כיצד לאמת חתימות ולהציג פרטי תעודות:
apksigner verify --verbose --print-certs messenger.apk
האימות אמור להצליח עבור הפלטפורמות שבהן ה־APK תומך. השוו את פרטי תעודת החותם לרישום מהדורה ממקור מהימן או לשרשרת החלפת מפתחות החתימה שתיעד המפרסם. חתימה שנוצרה במפתח לא מוכר אינה נעשית מהימנה בזכות המילה ״אומת״. גם החלפה לגיטימית של מפתח חתימה דורשת ראיות, ולא הוראה להתעלם מאי־התאמה.
ערך הגיבוב SHA-256 של קובץ ה־APK וטביעת האצבע SHA-256 של תעודת החתימה שלו הם ערכים שונים. אל תשוו אחד לשני.
שלב 4: חפשו ראיות לבנייה הניתנת לשחזור
טענה שבנייה ניתנת לשחזור דורשת מהדורת קוד מקור מוגדרת, סביבת בנייה, הוראות ותוצר יעד מוגדר. גורמים עצמאיים צריכים להיות מסוגלים ליצור מחדש את התוצר הזה ולהשוות את התוצאה. ההגדרה של מיזם Reproducible Builds כוללת את הקלטים האלה כחלק מהטענה.
באפליקציית מסרים, ראיות שימושיות לגבי מהדורה כוללות תג של קוד המקור, גרסאות מקובעות של תלויות ושל שרשרת כלי הבנייה, הוראות בנייה ותוצאות השוואה עצמאיות. שאלו מה בדיוק הושווה: תוצר לא חתום, APK חתום או חלקים נבחרים מתוכן החבילה. אל תסיקו שהבנייה ניתנת לשחזור רק מפני שקוד המקור וערך הגיבוב של הקובץ להורדה פורסמו.
יכולת השחזור מחזקת את הקשר בין קוד מקור שנבדק לבין הקוד המופץ. היא אינה הופכת מימוש שלא נבדק לפרוטוקול מאובטח ואינה מוכיחה שטלפון פועל לא נפרץ.
מה תפקידו של Proof Lab של Livara
Proof Lab של Livara מאפשר לחשב באופן מקומי ערך גיבוב של APK ולהשוות אותו לערך הגיבוב שפורסם. ההדגמות הקריפטוגרפיות שבו מצומצמות יותר מביקורת של פרוטוקול המסרים המלא. השתמשו בבדיקת הגיבוב למטרתה המוצהרת, לצד פרטי המהדורה והחתימה הצפויים; אל תראו בה ראיה עצמאית לבניות הניתנות לשחזור או להיעדר דלתות אחוריות.
מודל האיומים מציין במפורש את המגבלה כאשר ניתן להחליף גם את ה־APK וגם את ערך הגיבוב המוצג שלו. לכן מקורו של ערך הייחוס חשוב לא פחות מביצוע החישוב כראוי.
שאלות נפוצות
האם סכום ביקורת תואם מוכיח שה־APK בטוח?
לא. הוא מוכיח התאמה לערך הגיבוב המשמש לייחוס, בהנחה שהייחוס מהימן ותכונות האבטחה של פונקציית הגיבוב מתקיימות. הוא אינו בוחן את התנהגות התוכנה.
האם אימות חתימה מיותר אם סכום הביקורת תואם?
לא. הבדיקות מספקות ראיות שונות. חתימה קושרת את שלמות החבילה למפתח; ערך גיבוב של קובץ מזהה רצף בתים מסוים.
האם קובץ שהורד מחנות חייב להתאים לערך הגיבוב של ה־APK באתר?
רק אם הם אמורים להיות אותו תוצר. בדקו תחילה את ערוץ ההפצה, הגרסה והאריזה. אי־התאמה שאין לה הסבר מצריכה בירור, לא האשמה אוטומטית ולא אישור אוטומטי.
האם הבדיקות האלה יכולות לזהות תוכנת ריגול שכבר נמצאת בטלפון שלי?
לא. הן בוחנות תוצר התקנה, ולא כל רכיב במצב הריצה הנוכחי של המכשיר.
