המשך לאחר הפעלה מחדש

ב-Android 11, אפשר להחיל עדכוני OTA באמצעות עדכון A/B או מנגנוני של עדכון A/B וירטואלי, בשילוב עם recoverySystem שיטות לכיתה. לאחר הפעלה מחדש של מכשיר כדי להחיל עדכון OTA, המשך ההפעלה מחדש (RoR) מבטל את נעילת האחסון של פרטי כניסה מוצפנים (CE).

השותפים יכולים להתאים את התהליך הזה גם לתכונה של מערכת OTA עדכונים כשהמכשיר צפוי להיות לא פעיל ב-Android 11, שותפים עם Android 12 לא צריכים מערכת OTA נוספת . תהליך RoR מספק למשתמשים אבטחה ונוחות נוספות, כי אפשר לבצע את העדכונים במהלך זמנים שבהם המכשיר לא פעיל. בנוסף, התכונות של Android 12 לעדכונים מרובי לקוחות ומבוססי-שרת מספקות יחד אבטחה ברמת החומרה של המכשיר.

כדי לתמוך ב-RoR ב-Android 11, צריך לתת הרשאת מכשיר לתכונה android.hardware.reboot_escrow. אבל כדי להפעיל RoR מבוסס-שרת ב-Android 12 ואילך, אין צורך לעשות זאת כי הגרסאות האלה לא משתמשות ב-HAL.

רקע

החל מגרסה 7 של Android, מערכת Android תומכת בהפעלה ישירה, שמאפשרת לאפליקציות במכשיר להתחיל לפעול לפני שהמשתמש פותח את נעילת האחסון של CE. הטמעת התמיכה בהפעלה ישירה (Direct Boot) אפשרה למשתמשים ליהנות מחוויית משתמש טובה יותר לפני שהם נדרשו להזין את גורם הידע של מסך הנעילה (LSKF) אחרי ההפעלה.

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

מודל איומים

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

באופן ספציפי, אסור שמתקפה שיש לו גישה פיזית למכשיר יוכל לקרוא את האחסון ב-CE, ויש לו את היכולות והמגבלות הבאות:

יכולות

  • יכולים להשתמש במפתח החתימה של כל ספק או חברה כדי לחתום על הודעות שרירותיות.
  • יכולה לגרום לכך שהמכשיר יקבל עדכון OTA.
  • יכולים לשנות את הפעולה של כל חומרה (כמו מעבד אפליקציות או זיכרון פלאש) – למעט כפי שמפורט בקטע מגבלות בהמשך. (עם זאת, שינוי כזה כרוך גם בעיכוב של לפחות שעה וגם במחזור הפעלה שמחסל את התוכן ב-RAM).

מגבלות

  • לא ניתן לשנות את הפעולה של חומרה עמידת-זיוף (לדוגמה, Titan M).
  • לא ניתן לקרוא את זיכרון ה-RAM של המכשיר בשידור חי.
  • לא ניתן לנחש את פרטי הכניסה של המשתמש (קוד אימות, קו ביטול נעילה או סיסמה) או לגרום להזנה שלהם בדרך אחרת.

הפתרון

מערכת העדכונים של Android 12 RoR מספקת אבטחה מפני תוקפים מתוחכמים מאוד, תוך שמירה על הסיסמאות ומפתחות הגישה במכשיר – הם אף פעם לא נשלחים לשרתי Google או נשמרים בהם. זוהי סקירה כללית של התהליך שמבטיח שרמות האבטחה שסופקו דומות למערכת RoR מבוססת-חומרה ברמת המכשיר:

  • מערכת Android מחילה אמצעי הגנה קריפטוגרפיים על נתונים שמאוחסנים במכשיר.
  • כל הנתונים מוגנים באמצעות מפתחות שמאוחסנים בסביבה מחשוב אמינה (TEE).
  • מכשיר ה-TEE משחרר את המפתחות רק אם מערכת ההפעלה שפועלת עוברת אימות קריפטוגרפי (הפעלה מאומתת).
  • שירות RoR שפועל בשרתי Google מאבטח את נתוני ה-CE על ידי אחסון סוד שאפשר לאחזר לזמן מוגבל בלבד. זה עובד בכל הסביבה העסקית של Android.
  • מפתח קריפטוגרפי שמוגן באמצעות קוד אימות של המשתמש, משמש לביטול נעילת המכשיר ולפענח את אחסון ה-CE.
    • כשמתזמנים הפעלה מחדש במהלך הלילה, מערכת Android מבקשת מהמשתמש להזין את קוד האימות שלו, ואז מחשבת סיסמה סינתטית (SP).
    • לאחר מכן, הוא מצפין את ספק השירות (SP) פעמיים: פעם אחת באמצעות מפתח K_s שמאוחסן ב-RAM, ופעם נוספת עם מפתח K_k שמאוחסן בסביבת TEE.
    • ה-SP המוצפן בשתי שכבות מאוחסן בדיסק, וה-SP נמחק מ-RAM. שני המפתחות נוצרים מחדש ומשמשים להפעלה מחדש אחת בלבד.
  • כשמגיע הזמן להפעיל מחדש, Android מעבירה את K_s לשרת. הקבלה עם K_k מוצפנת לפני שהיא מאוחסנת בדיסק.
  • לאחר ההפעלה מחדש, מערכת Android משתמשת ב-K_k כדי לפענח את הקבלה, ואז שולחת אותה אל השרת כדי לאחזר את K_s.
    • K_k ו-K_s משמשים לפענוח ה-SP שמאוחסן בדיסק.
    • Android משתמש ב-SP כדי לבטל את הנעילה של אחסון CE ולאפשר הפעלה רגילה של האפליקציה.
    • הערכים K_k ו-K_s יימחקו.

העדכונים ששומרים על אבטחת הטלפון יכולים להתבצע בזמן שנוח לך בשבילך: בזמן השינה.

הפעלה חוזרת של קוד האימות של ה-SIM

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

כרטיס SIM עם קוד אימות מופעל צריך לעבור גם אימות קוד אימות חלק (הפעלה חוזרת של קוד האימות של כרטיס ה-SIM) אחרי הפעלה מחדש ללא השגחה כדי לשחזר את הקישוריות הסלולרית (הכרחית לשיחות טלפון, להודעות SMS ולשירותי נתונים). קוד האימות של כרטיס ה-SIM והפרטים התואמים של כרטיס ה-SIM (מספר ה-ICCID ומספר חריץ ה-SIM) מאוחסנים יחד באופן מאובטח. ניתן לאחזר את קוד האימות שנשמר ולהשתמש בו לצורך אימות רק לאחר הפעלה מחדש ללא השגחה. אם המכשיר מאובטח, קוד האימות של כרטיס ה-SIM מאוחסן עם מפתחות שמוגנים על ידי LSKF. אם בכרטיס ה-SIM יש קוד האימות שלו מופעל, אינטראקציה עם שרת ה-RoR מחייבת חיבור Wi-Fi לעדכון OTA ול-RoR מבוסס-שרת, שמבטיח פונקציונליות בסיסית (עם קישוריות סלולרית) לאחר הפעלה מחדש.

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

  • כרטיס ה-SIM מוסר או מתאפס.
  • המשתמש משבית את קוד האימות.
  • בוצעה הפעלה מחדש שלא ביוזמת RoR.

ניתן להשתמש בקוד הגישה של כרטיס ה-SIM השמור רק פעם אחת לאחר הפעלה מחדש ביוזמת ה-RoR, וגם רק לזמן קצר מאוד (20 שניות) – אם הפרטים של כרטיס ה-SIM התאמת קלפים. קוד האימות של ה-SIM שנשמר אף פעם לא יוצא מאפליקציית TelephonyManager, ואי אפשר לאחזר אותו באמצעות מודולים חיצוניים.

הנחיות להטמעה

ב-Android 12, אפשרות ה-RoR מבוססת-השרתים ועל מספר הלקוחות שמספקות עומס קל יותר על השותפים כשהם דוחפים עדכוני OTA. עדכונים נחוצים יכולים להתבצע במהלך זמנים נוחים לזמן השבתה של המכשיר, למשל במהלך שעות השינה הייעודיות.

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

אם אתם משדרגים ל-Android 12 או משיקים מכשירי Android 12, אתם לא צריכים לעשות שום דבר כדי להטמיע את הפונקציונליות החדשה של RoR.

יש קריאה חדשה אחת בתהליך מרובה הלקוחות, isPreparedForUnattendedUpdate, למטה:

@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
            android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)

אין צורך להטמיע את הקוד הזה, כי ה-HAL הוצא משימוש החל מ-Android 12.

מנהל טלפוניה

לקוח ה-OTA מפעיל את ה-API של המערכת TelephonyManager כשבקרוב תתבצע הפעלה מחדש ב-Android 12. ה-API הזה מעביר את כל קודי האימות ששמורים במטמון מ- את המצב AVAILABLE למצב REBOOT_READY. ה-API של המערכת TelephonyManager מוגן באמצעות הרשאת המניפסט הקיימת REBOOT.

 /**
    * The unattended reboot was prepared successfully.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_SUCCESS = 0;

   /**
    * The unattended reboot was prepared, but the user will need to manually
    * enter the PIN code of at least one SIM card present in the device.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED = 1;

   /**
    * The unattended reboot was not prepared due to generic error.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_ERROR = 2;

   /** @hide */
   @Retention(RetentionPolicy.SOURCE)
   @IntDef(prefix = {"PREPARE_UNATTENDED_REBOOT_"},
           value = {
                   PREPARE_UNATTENDED_REBOOT_SUCCESS,
                   PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED,
                   PREPARE_UNATTENDED_REBOOT_ERROR
           })
   public @interface PrepareUnattendedRebootResult {}

   /**
    * Prepare TelephonyManager for an unattended reboot. The reboot is
    * required to be done shortly after the API is invoked.
    *
    * Requires system privileges.
    *
    * <p>Requires Permission:
    *   {@link android.Manifest.permission#REBOOT}
    *
    * @return {@link #PREPARE_UNATTENDED_REBOOT_SUCCESS} in case of success.
    * {@link #PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED} if the device contains
    * at least one SIM card for which the user needs to manually enter the PIN
    * code after the reboot. {@link #PREPARE_UNATTENDED_REBOOT_ERROR} in case
    * of error.
    * @hide
    */
   @SystemApi
   @RequiresPermission(android.Manifest.permission.REBOOT)
   @PrepareUnattendedRebootResult
   public int prepareForUnattendedReboot()

ממשק ה-API של מערכת טלפוניה נמצא בשימוש על ידי חבילות APK בעלות הרשאות.

בדיקה

כדי לבדוק את ה-API החדש, מריצים את הפקודה הבאה:

    adb shell cmd phone unattended-reboot

הפקודה הזו פועלת רק כשהמעטפת פועלת בתור root‏ (adb root).

Android 11 בלבד

שאר הדף רלוונטי ל-Android 11.

נכון ליולי 2020, הטמעות של RoR HAL נכללות בשתי קטגוריות:

  1. אם חומרת ה-SoC תומכת בהתמדה של זיכרון RAM בהפעלות מחדש, יצרני ציוד מקורי יכולים להשתמש והטמעת ברירת המחדל ב-AOSP (ברירת המחדל של השהיית RAM).
  2. אם חומרת המכשיר או ה-SoC תומכים במובלעת חומרה מאובטחת ( עם זיכרון RAM ו-ROM משלו, וגם עליו לבצע את הבאים:
    • זיהוי של הפעלה מחדש של המעבד (CPU) הראשי.
    • מקור טיימר לחומרה שממשיך לפעול בכל הפעלה מחדש. כלומר, Enclave חייבת להיות מסוגלת לזהות את ההפעלה מחדש ולפקוע טיימר שהוגדר לפני להפעיל מחדש.
    • תמיכה באחסון מפתח בנאמנות ב-RAM/ROM של הקוד כך שהוא לא יוכל להתאושש באמצעות מתקפות לא מקוונות. הוא צריך לאחסן את מפתח ה-RoR באופן שלא יאפשר לגורמים פנימיים או לתוקפים לשחזר אותו.

ברירת מחדל של נאמנות RAM

ב-AOSP יש הטמעה של RoR HAL באמצעות שימוש מתמיד ב-RAM. כדי שהתכונה הזו תפעל, יצרני ציוד מקורי (OEM) צריכים לוודא שה-SoC שלהם תומך בשימור נתונים ב-RAM במהלך הפעלות מחדש. חלק ממערכי ה-SoC לא יכולים לשמור את תוכן ה-RAM אחרי הפעלה מחדש, לכן מומלץ ליצרני ציוד מקורי להתייעץ עם שותפי ה-SoC שלהם לפני שהם מפעילים את HAL שמוגדרת כברירת מחדל. ההפניה הקנונית לכך מופיעה בקטע הבא.

זרימה של עדכון OTA באמצעות RoR

אפליקציית הלקוח מסוג OTA בטלפון צריכה לכלול את Manifest.permission.REBOOT ואת ההרשאות Manifest.permission.RECOVERY כדי לקרוא ל-methods הנדרשות להטמיע RoR. אחרי שמבצעים את התנאי הנדרש, תהליך העדכון מתבצע לפי השלבים הבאים:

  1. אפליקציית לקוח OTA מורידה את העדכון.
  2. אפליקציית הלקוח של OTA קוראת ל-RecoverySystem#prepareForUnattendedUpdate, שמפעילה בקשה למשתמש להזין את קוד האימות, קו ביטול הנעילה או הסיסמה במסך הנעילה במהלך הביטול הבא של הנעילה.
  3. המשתמש מבטל את נעילת המכשיר במסך הנעילה, והמכשיר מוכן כדי שהעדכון יחול.
  4. אפליקציית לקוח OTA מפעילה קריאה ל-RecoverySystem#rebootAndApply, שבאופן מיידי. מפעיל מחדש.

בסיום התהליך הזה, המכשיר יופעל מחדש וה-RoR מבטל את הנעילה של אחסון פרטי הכניסה המוצפנים (CE). כשמדובר באפליקציות, מופיע כביטול נעילה רגיל של המשתמש, כך שהוא מקבל את כל האותות, כמו ACTION_LOCKED_BOOT_COMPLETED וגם ACTION_BOOT_COMPLETED שהם עושים בדרך כלל.

שינוי הגדרות המוצר

מוצר שמסומן כתומך בתכונה RoR ב-Android 11 צריך לכלול של אתחול הנאמנות והכללת קובץ ה-XML של סמן התכונה. הטמעת ברירת המחדל פועלת היטב במכשירים שמשתמשים בהפעלה מחדש חמה (כשהחשמל ל-DRAM נשאר פועל במהלך ההפעלה מחדש).

סמן התכונה של הפעלה מחדש של השירות לניהול כספים

גם סמן התכונה חייב להיות:

PRODUCT_COPY_FILES += \
    frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml

הטמעת HAL שמוגדרת כברירת מחדל להפעלה מחדש

כדי להשתמש בהטמעת ברירת המחדל, צריך להזמין 65536 (0x10,000) בייטים. לעולם לא לכתוב את הבייטים האלה באחסון לא תנודתי כדי לוודא שמאפייני האבטחה עקביים.

שינויים בעץ של מכשיר הליבה של Linux

בעץ המכשיר של הליבה של Linux, צריך לשמור זיכרון לאזור pmem. בדוגמה הבאה רואים שפריט 0x50000000 שמור:

  reserved-memory {
    my_reservation@0x50000000 {
      no-map;
      reg = <0x50000000 0x10000>;
    }
  }

  reboot_escrow@0 {
    compatible = "pmem-region";
    reg = <0x50000000 0x10000>;
  };

עליך לוודא שיש לך מכשיר חדש בספריית הבלוקים עם שם כמו /dev/block/pmem0 (למשל pmem1 או pmem2).

שינויים ב-Device.mk

בהנחה שהמכשיר החדש מהשלב הקודם נקרא pmem0, צריך לוודא שהרשומות החדשות הבאות מתווספות אל vendor/<oem>/<product>/device.mk:

# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
    ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
    android.hardware.rebootescrow-service.default
כללי SELinux

מוסיפים את הרשומות החדשות הבאות ל-file_contexts של המכשיר:

/dev/block/pmem0  u:object_r:rebootescrow_device:s0
/vendor/bin/hw/android\.hardware\.rebootescrow-service\.default  u:object_r:hal_rebootescrow_default_exec:s0