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

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

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

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

רקע

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

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

מודל של איום

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

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

יכולות

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

מגבלות

  • לא ניתן לשנות את הפעולה של חומרה עמידה בפני התעסקות (לדוגמה, טיטאן מ).
  • לא ניתן לקרוא את זיכרון ה-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-PIN.

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

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

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

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

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

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

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

אם אתם משדרגים ל-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. מערכת TelephonyManager ה-API מוגן על-ידי ה-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

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