המשך בעת אתחול מחדש

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

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

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

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

רקע כללי

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

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

מודל איום

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

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

יכולות

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

מגבלות

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

פִּתָרוֹן

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

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

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

הפעלה חוזרת של SIM-PIN

בתנאים מסוימים, קוד ה-PIN של כרטיס ה-SIM מאומת ממטמון, תהליך הנקרא SIM-PIN replay.

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

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

  • ה-SIM הוסר או מאופס.
  • המשתמש משבית את ה-PIN.
  • התרחש אתחול מחדש שלא יזום RoR.

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

הנחיות יישום

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

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

אם אתה משדרג לאנדרואיד 12, או משיק מכשירי אנדרואיד 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 זה מעביר את כל קודי ה-PIN המאוחסנים במטמון ממצב AVAILABLE למצב REBOOT_READY . ממשק ה-API של מערכת TelephonyManager מוגן על ידי הרשאת REBOOT Manifest הקיימת.

 /**
    * 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 של מערכת TelephonyManager נמצא בשימוש על ידי חבילות APK מורשות.

בדיקה

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

    adb shell cmd phone unattended-reboot

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

אנדרואיד 11 בלבד

שאר העמוד הזה חל על אנדרואיד 11.

החל מיולי 2020, יישומים של RoR HAL מתחלקים לשתי קטגוריות:

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

ברירת מחדל בפקדון RAM

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

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

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

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

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

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

מוצר המסומן כתומך בתכונת RoR באנדרואיד 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 (0x10000) בתים. לעולם אל תכתוב בתים אלה לאחסון לא נדיף כדי להבטיח שמאפייני האבטחה יימשכו.

שינויים בעץ הליבה של לינוקס

בעץ ההתקנים של ליבת לינוקס, עליך לשמור זיכרון לאזור 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