在 Android 11 中，可以使用A/B 更新或虛擬 A/B 更新機制，結合RecoverySystem類方法應用 OTA 更新。在設備重新啟動以應用 OTA 更新後，重啟時恢復 (RoR) 解鎖設備憑據加密 (CE) 存儲。
儘管合作夥伴可以將此過程與 OTA 系統功能配對，當設備在 Android 11 中預計空閒時應用更新，但在 Android 12 中，合作夥伴不需要額外的 OTA 系統功能。 RoR 過程為用戶提供了更高的安全性和便利性，因為可以在設備空閒時間進行更新，而 Android 12 多客戶端和基於服務器的更新功能共同提供設備硬件級類型的安全性。
儘管您必須為android.hardware.reboot_escrow功能提供設備權限才能在 Android 11 中支持 RoR，但您無需執行此操作即可在 Android 12 及更高版本中啟用基於服務器的 RoR，因為它們不使用 HAL。
背景
從 Android 7 開始，Android 支持Direct Boot ，這使得設備上的應用程序能夠在用戶解鎖 CE 存儲之前啟動。直接啟動支持的實施為用戶在啟動後需要輸入鎖屏知識因素 (LSKF) 之前提供了更好的體驗。
RoR 允許在 OTA 更新後啟動重啟時解鎖設備上所有應用程序的 CE 存儲，包括那些不支持直接啟動的應用程序。此功能使用戶能夠在重新啟動後接收來自所有已安裝應用程序的通知。
威脅模型
RoR的實現必須確保當設備落入攻擊者手中時，攻擊者極難恢復用戶的CE加密數據，即使設備已開機，CE存儲已解鎖，並且設備被解鎖用戶在收到 OTA 更新後。即使攻擊者獲得了對廣播加密簽名密鑰的訪問權限，內部攻擊抵抗也必須有效。
具體來說，CE 存儲不得由實際擁有該設備並具有以下功能和限制的攻擊者讀取：
能力
- 可以使用任何供應商或公司的簽名密鑰來簽署任意消息。
- 可以使設備接收 OTA 更新。
- 可以修改任何硬件（例如應用程序處理器或閃存）的操作 - 以下限制中詳述的除外。 （但是，此類修改涉及至少一小時的延遲，以及破壞 RAM 內容的電源循環。）
限制
- 無法修改防篡改硬件（例如 Titan M）的操作。
- 無法讀取實時設備的 RAM。
- 無法猜測用戶的憑據（PIN、圖案、密碼）或以其他方式導致他們被輸入。
解決方案
Android 12 RoR 更新系統提供了針對非常老練的攻擊者的安全性，並且在設備上的密碼和 PIN 保留在設備上的同時執行此操作——它們永遠不會發送到或存儲在 Google 服務器上。這是確保提供的安全級別類似於基於硬件的設備級 RoR 系統的過程的概述：
- Android 對存儲在設備上的數據應用加密保護。
- 所有數據都受到存儲在可信執行環境(TEE) 中的密鑰的保護。
- 只有在運行的操作系統通過密碼身份驗證（已驗證啟動）時，TEE 才會發布密鑰。
- 在 Google 服務器上運行的 RoR 服務通過存儲只能在有限時間內檢索的秘密來保護 CE 數據。這適用於整個 Android 生態系統。
- 受用戶 PIN 保護的加密密鑰用於解鎖設備和解密 CE 存儲。
- 當安排夜間重啟時，Android 會提示用戶輸入 PIN，然後計算合成密碼 (SP)。
- 然後它對 SP 進行兩次加密：一次使用存儲在 RAM 中的密鑰
K_s，另一次使用存儲在 TEE 中的密鑰K_k。 - 雙重加密的 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-PIN重放
在某些情況下，SIM 卡的 PIN 碼會從緩存中得到驗證，這個過程稱為 SIM-PIN 重播。
啟用了 PIN 的 SIM 卡在無人值守重啟後還必須經過無縫 PIN 碼驗證（SIM-PIN 重播）以恢復蜂窩連接（電話、SMS 消息和數據服務需要）。 SIM PIN 及其匹配的 SIM 卡信息（ICCID 和 SIM 插槽編號）一起安全存儲。只有在無人看管的重啟成功後，才能檢索存儲的 PIN 並將其用於驗證。如果設備是安全的，則 SIM PIN 與受 LSKF 保護的密鑰一起存儲。如果 SIM 已啟用其 PIN，則與 RoR 服務器的交互需要WiFi 連接以進行 OTA 更新和基於服務器的 RoR，這可確保重啟後的基本功能（具有蜂窩連接）。
每次用戶成功啟用、驗證或修改時，SIM PIN 都會重新加密並存儲。如果發生以下任何一種情況，SIM PIN 將被丟棄：
- SIM 被移除或重置。
- 用戶禁用 PIN。
- 發生了非 RoR 啟動的重啟。
存儲的 SIM PIN 只能在 RoR 啟動的重啟後使用一次，並且只能持續很短的時間（20 秒）——如果SIM 卡的詳細信息匹配。存儲的 SIM PIN 永遠不會離開 TelephonyManager 應用程序，也無法通過外部模塊檢索。
實施指南
在 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)
您不需要實現它，因為從 Android 12 開始，HAL 已被棄用。
電話管理器
當 Android 12 中即將重啟時，OTA 客戶端會調用TelephonyManager系統 API。此 API 會將所有緩存的 PIN 碼從AVAILABLE狀態移動到REBOOT_READY狀態。 TelephonyManager系統 API 受現有的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()
TelephonyManager 系統 API 由特權 APK 使用。
測試
要測試新 API，請執行以下命令：
adb shell cmd phone unattended-reboot
此命令僅在 shell 以根用戶身份 ( adb root ) 運行時有效。
僅限安卓 11
本頁的其餘部分適用於 Android 11。
截至 2020 年 7 月，RoR HAL 的實施分為兩類：
- 如果 SoC 硬件支持重啟後的 RAM 持久性，OEM 可以使用 AOSP 中的默認實現（默認 RAM 託管）。
- 如果設備硬件或 SoC 支持安全硬件 enclave（具有自己的 RAM 和 ROM 的分立安全協處理器），則它還必須執行以下操作：
- 能夠檢測到主 CPU 重啟。
- 有一個在重新啟動後仍然存在的硬件計時器源。也就是說，飛地必須能夠檢測到重新啟動並在重新啟動之前設置的計時器到期。
- 支持將託管密鑰存儲在 enclave RAM/ROM 中，使其無法通過離線攻擊恢復。它必須以一種使內部人員或攻擊者無法恢復它的方式存儲 RoR 密鑰。
默認 RAM 託管
AOSP 有一個使用 RAM 持久性的 RoR HAL 實現。為此，OEM 必須確保其 SoC 支持 RAM 在重啟後的持久性。某些 SoC 無法在重啟後保留 RAM 內容，因此建議 OEM 在啟用此默認 HAL 之前諮詢其 SoC 合作夥伴。下一節中對此的規範參考。
使用 RoR 的 OTA 更新流程
手機上的 OTA 客戶端應用程序必須具有Manifest.permission.REBOOT和Manifest.permission.RECOVERY權限才能調用必要的方法來實現 RoR。有了這個先決條件，更新流程將遵循以下步驟：
- OTA 客戶端應用程序下載更新。
- OTA 客戶端應用調用
RecoverySystem#prepareForUnattendedUpdate觸髮用戶在下次解鎖期間在鎖定屏幕上提示輸入 PIN、圖案或密碼。 - 用戶在鎖屏界面解鎖設備，設備準備好應用更新。
- OTA 客戶端應用程序調用
RecoverySystem#rebootAndApply，這會立即觸發重啟。
在此流程結束時，設備重新啟動並且 RoR 機制解鎖憑據加密 (CE) 存儲。對於應用程序，這表現為普通用戶解鎖，因此它們會收到所有信號，例如它們通常會收到的ACTION_LOCKED_BOOT_COMPLETED和ACTION_BOOT_COMPLETED 。
修改產品配置
在 Android 11 中標記為支持 RoR 功能的產品必須包含 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) 字節。切勿將這些字節寫入非易失性存儲，以確保安全屬性持續存在。
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