שקיפות במודולים ראשיים של Android

כדי להגביר את האמון ב-Android OS, אנחנו מתחייבים לרשום ביומן השקיפות שלנו כל מודול של Android OS (שנקרא Mainline) שמוצע כעדכון דרך Google Play. אנחנו מפרסמים את יומן השקיפות כדי לאמת את הטענות שלנו לגבי המודולים האלה. מודולים שהותקנו מראש לא מפורטים במפורש כי הם כבר כלולים בשקיפות בינארית של Pixel.

מודל איומים

אפשר להשתמש במערכות שקיפות כדי לזהות מתקפות על שרשרת האספקה, וכך למנוע אותן. הנה כמה דוגמאות.

נניח שתוקף משנה באופן זדוני מודול Mainline (שיכול להיות קובץ APEX או APK) ואפילו מצליח לחתום עליו באמצעות מפתח החתימה שמשמש להפצה דרך Google Play. כל מי שמקבל מודול מפוקפק יכול לשלוח שאילתה ליומן השקיפות הבינארי כדי לאמת את האותנטיות של המודול. הם יגלו ש-Google לא הוסיפה את המטא-נתונים של המודול המתאים ליומן, וידעו שלא כדאי לסמוך על מודול מערכת ההפעלה שנפרץ.

הפרסום ביומן הוא תהליך נפרד מתהליך השחרור עם חתימה, ולכן התוקף צריך לעשות הרבה יותר מאשר רק לפרוץ למפתח.

אנחנו מתכננים לשלב את היומן הזה גם ברשת ציבורית של עדים באמצעות פרוטוקול עדים סטנדרטי. אנחנו ממליצים לצדדים חיצוניים ועצמאיים לעקוב אחרי השלמות של היומן הזה שזמין לכולם. הגורמים האלה יכולים לאשר שהיומן הוא רק להוספה, ולדווח על כל שינוי לא מורשה.

הקיום של מערכת שקיפות כזו והאפשרות הנוספת לגלות מתקפות מרתיעים פעילות זדונית. אם מודול של מערכת הפעלה נפרץ, אבל המשתמשים סומכים רק על המודולים שמופיעים ביומן, המודול שנפרץ צריך להיות חשוף לציבור. כך גדל הסיכוי לגלות את קיומם של המודולים שנפרצו, וניתן לפעול להסרת ההפצה שלהם.

מודל המתלונן

מודל התובע הוא מסגרת שמשמשת להגדרת תפקידים וארטיפקטים במערכת שניתן לאמת. במקרה של שקיפות של מודולים ב-Android Mainline, הטענה שלנו היא שהגיבוב של קובץ מודול שמתועד ביומן הזה מייצג גרסה ספציפית של מודול Android רשמי שמיועד לשימוש הציבור.

• טענה^{MainlineModule}: (I, Google, claim that $hashModule is for $mainlineModule), where:
  • ‫$hashModule הוא גיבוב קריפטוגרפי (למשל SHA256) של קובץ מודול מערכת ההפעלה של גרסה ספציפית של $mainlineModule.
  • ‫$mainlineModule הוא APEX או חבילת Android ‏ (APK) שמרכיבים מודול של מערכת הפעלה ש-Google יוצרת, חותמת ומפיצה.

כל מי שיש לו עותק של $mainlineModule יכול לאמת את התביעה הזו. בדף האימות מופיעות הוראות מפורטות לתהליך הזה. השלבים האלה רלוונטיים גם לקובצי APK רגילים וגם למודולים של Mainline (שיכולים להיות קובצי APK או APEX).

תוכן היומן

כש-Google משיקה גרסה חדשה של מודול Mainline, היא מוסיפה רשומה תואמת ליומן השקיפות של מודולי Mainline.

כל רשומה ביומן הזה מכילה ארבעה פריטי מטא-נתונים:

1. הגיבוב (hash) של קובץ ה-APK או ה-APEX של מודול Android Mainline חתום. זוהי מחרוזת הקסדצימלית של תקציר ה-SHA256 של הקובץ כולו.
2. התיאור של סוג הגיבוב שלמעלה. זו מחרוזת.
3. שם החבילה של המודול. זו מחרוזת.
4. מספר הגרסה (versionCode) של המודול. הערך הזה חייב להיות מספר שלם שאינו אפס.

הפורמט של רשומה ביומן הוא שרשור של ארבעת פריטי המידע עם תו של שורה חדשה (\n), כמו בדוגמה הבאה:

hash\nhash_description\npackage_name\npackage_version\n

מודול ראשי יכול להיות קובץ APK או קובץ APEX, ולכן תיאור הגיבוב יכול להיות SHA256(APK) או SHA256(APEX).