ב-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 מאוחסנים ביחד באופן מאובטח. אפשר לאחזר את מספר ה-PIN השמור ולהשתמש בו לאימות רק אחרי הפעלה מחדש ללא השגחה. אם המכשיר מאובטח, קוד האימות של ה-SIM מאוחסן עם מפתחות שמוגנים על ידי ה-LSKF. אם בכרטיס ה-SIM יש קוד האימות שלו מופעל, אינטראקציה עם שרת ה-RoR מחייבת חיבור Wi-Fi לעדכון OTA ול-RoR מבוסס-שרת, שמבטיח פונקציונליות בסיסית (עם קישוריות סלולרית) לאחר הפעלה מחדש.
קוד האימות של ה-SIM מוצפן מחדש ומאוחסן בכל פעם שהמשתמש מפעיל בהצלחה, מאמת או משנה אותו. קוד הגישה של כרטיס ה-SIM נמחק במקרים הבאים:
- כרטיס ה-SIM הוסר או אופס.
- המשתמש משבית את קוד האימות.
- בוצעה הפעלה מחדש שלא ביוזמת RoR.
ניתן להשתמש בקוד הגישה של כרטיס ה-SIM השמור רק פעם אחת לאחר הפעלה מחדש ביוזמת ה-RoR, וגם רק לזמן קצר מאוד (20 שניות) – אם הפרטים של כרטיס ה-SIM התאמת קלפים. קוד האימות של כרטיס ה-SIM השמור אף פעם לא יוצא מאפליקציית טלפוניה, שלא ניתן לאחזר באמצעות מודולים חיצוניים.
הנחיות להטמעה
ב-Android 12, אפשרות ה-RoR מבוססת-השרתים ועל מספר הלקוחות שמספקות עומס קל יותר על השותפים כשהם דוחפים עדכוני OTA. עדכונים נחוצים יכולים להתבצע במהלך זמנים נוחים לזמן השבתה של המכשיר, למשל במהלך שעות השינה הייעודיות.
כדי להבטיח שעדכוני OTA לא יפריעו למשתמשים במהלך פרק הזמן הזה,
להשתמש במצב כהה כדי לצמצם את פליטות האור. כדי לעשות זאת, מבקשים מתוכנת האתחול של המכשיר לחפש את המחרוזת reason 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הפקודה הזו פועלת רק כשהמעטפת פועלת בתור root (adb root).
Android 11 בלבד
שאר הדף רלוונטי ל-Android 11.
נכון ליולי 2020, הטמעות של RoR HAL נכללות בשתי קטגוריות:
- אם חומרת ה-SoC תומכת בהתמדה של זיכרון RAM בהפעלות מחדש, יצרני ציוד מקורי יכולים להשתמש והטמעת ברירת המחדל ב-AOSP (ברירת המחדל של השהיית RAM).
- אם חומרת המכשיר או המעבד המשולב (SoC) תומכים במתחם חומרה מאובטח (מעבד משולב נפרד לצורכי אבטחה עם זיכרון RAM ו-ROM משלו), בנוסף הוא צריך לבצע את הפעולות הבאות:
- לזהות הפעלה מחדש של המעבד הראשי.
- מקור טיימר לחומרה שממשיך לפעול בכל הפעלה מחדש. כלומר, Enclave חייבת להיות מסוגלת לזהות את ההפעלה מחדש ולפקוע טיימר שהוגדר לפני להפעיל מחדש.
- תמיכה באחסון מפתח בנאמנות ב-RAM/ROM של הקוד כך שהוא לא יוכל להתאושש באמצעות מתקפות לא מקוונות. עליו לאחסן את מפתח ה-RoR באופן גורמים פנימיים או תוקפים לא יכולים לשחזר אותו.
ברירת המחדל של חשבון נאמנות ל-RAM
ב-AOSP יש הטמעה של RoR HAL באמצעות עמידות ב-RAM. כדי שהפתרון הזה יעבוד, יצרני ציוד מקורי צריכים לוודא שרכיבי ה-SoC שלהם תומכים בשימוש עקבי של RAM, בכל הפעלות מחדש. חלק ממערכי ה-SoC לא יכולים לשמור את תוכן ה-RAM אחרי הפעלה מחדש, לכן מומלץ ליצרני ציוד מקורי להתייעץ עם שותפי ה-SoC שלהם לפני שהם מפעילים את HAL שמוגדרת כברירת מחדל. ההפניה הקנונית לכך מופיעה בקטע הבא.
זרימה של עדכון OTA באמצעות RoR
לאפליקציית הלקוח ל-OTA בטלפון צריכות להיות ההרשאות Manifest.permission.REBOOT ו-Manifest.permission.RECOVERY כדי לקרוא לשיטות הנדרשות להטמעת RoR. אחרי שמבצעים את התנאי הנדרש, תהליך העדכון מתבצע לפי השלבים הבאים:
- אפליקציית הלקוח ל-OTA מורידת את העדכון.
- אפליקציית הלקוח של OTA קוראת ל-
RecoverySystem#prepareForUnattendedUpdate, שמפעילה בקשה למשתמש להזין את קוד האימות, קו ביטול הנעילה או הסיסמה במסך הנעילה במהלך הביטול הבא של הנעילה. - המשתמש מבטל את נעילת המכשיר במסך הנעילה, והמכשיר מוכן להתקנת העדכון.
- אפליקציית לקוח OTA מפעילה קריאה ל-
RecoverySystem#rebootAndApply, שבאופן מיידי. מפעיל מחדש.
בסיום התהליך הזה, המכשיר יופעל מחדש וה-RoR מבטל את הנעילה של אחסון פרטי הכניסה המוצפנים (CE). מבחינת האפליקציות, הפעולה הזו מופיעה כביטול נעילה רגיל של המשתמש, כך שהן מקבלות את כל האותות, כמו ACTION_LOCKED_BOOT_COMPLETED ו-ACTION_BOOT_COMPLETED, כמו שהן מקבלות בדרך כלל.
שינוי הגדרות המוצר
מוצר שמסומן כתומך בתכונה RoR ב-Android 11 חייב לכלול הטמעה של RebootEscrow HAL וגם את קובץ ה-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 של הפעלה מחדש בנאמנות כברירת מחדל
כדי להשתמש בהטמעה שמוגדרת כברירת מחדל, צריך להקצות 65,536 (0x10000) בייטים. כדי לוודא שתכונות האבטחה יישארו קבועות, אף פעם אל תכתבו את הבייטים האלה באחסון לא נדיף.
שינויים בפירוט מבנה המכשיר (DT) של ליבה של 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