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

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

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

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

רקע

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

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

מודל איומים

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

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

יכולות

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

מגבלות

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

הפתרון

מערכת העדכון של RoR ל-Android 12 מספקת אבטחה מפני תוקפים מתוחכמים מאוד. היא עושה זאת כשהסיסמאות וקודי האימות במכשיר נשארים במכשיר – הם אף פעם לא נשלחים לשרתים של 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 מופעל, נדרש חיבור Wi-Fi כדי לבצע אינטראקציה עם שרת RoR לעדכון OTA ול-RoR מבוסס-שרת, וכך להבטיח פונקציונליות בסיסית (עם קישוריות סלולרית) אחרי ההפעלה מחדש.

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

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

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

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

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

כדי להבטיח שעדכוני OTA לא יפריעו למשתמשים במהלך פרק הזמן הזה, כדאי להשתמש במצב כהה כדי לצמצם את פליטות האור. כדי לעשות זאת, מבקשים מתוכנת האתחול של המכשיר לחפש את המחרוזת reason 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.

TelephonyManager

לקוח ה-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 (Default RAM Escrow).
  2. אם חומרת המכשיר או ה-SoC תומכים בחומרה מאובטחת (מעבד עזר נפרד לאבטחה עם זיכרון RAM ו-ROM משלו), צריך גם לבצע את הפעולות הבאות:
    • זיהוי של הפעלה מחדש של המעבד (CPU) הראשי.
    • יש מקור לטיימר בחומרה שנשמר אחרי הפעלות מחדש. כלומר, המובלעת צריכה להיות מסוגלת לזהות את ההפעלה מחדש ולפקוע טיימר שהוגדר לפני האתחול.
    • תמיכה באחסון מפתח בקרן נאמנות ב-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 חייב לכלול הטמעה של RebootEscrow HAL וגם את קובץ ה-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