重新啟動後繼續

在 Android 11 中，可透過 A/B 更新套用 OTA 更新 或虛擬 A/B 更新機制，搭配 RecoverySystem 類別方法。重新啟動裝置以套用 OTA 更新後， 裝置重新啟動後 (RoR) 會解鎖裝置憑證加密 (CE) 儲存空間。

雖然合作夥伴也能將此程序與適用的 OTA 系統功能配對 更新並接收來自 Android 版本回應 Android 12 合作夥伴不需要額外的 OTA 系統 而不是每個特徵的分數RoR 程序能為使用者提供多一層的安全性和便利性。 如果是 Android 12 裝置，則可在裝置閒置時更新 多重用戶端和伺服器型更新功能同時提供裝置 硬體層級類型安全性

但你必須為android.hardware.reboot_escrow提供裝置權限 在 Android 11 中支援 RoR，您不需要執行此操作 Android 12 以上版本中的伺服器型 RoR 請不要使用 HAL

背景

自 Android 7 起，Android 支援直接啟動功能。 可讓裝置上的應用程式在解鎖 CE 儲存空間前啟動 使用者。採用直接啟動支援，為使用者提供更便捷的體驗 熟悉鎖定螢幕知識 (LSKF) 階段 的使用者體驗 執行這些動作

RoR 可解鎖裝置上所有應用程式的 CE 儲存空間，包括 不支援直接啟動應用程式 (在 OTA 更新。這項功能可讓使用者接收來自 已安裝的應用程式、重新啟動後。

威脅模型

RoR 實作必須確保裝置成為攻擊者 攻擊者很難恢復使用者的 CE- 加密資料 (即使裝置開機) 且 CE 儲存空間處於解鎖狀態 使用者收到 OTA 更新後，就會解鎖裝置。內部人士 即使攻擊者取得 廣播加密簽署金鑰。

具體來說，攻擊者不得讀取 CE 儲存空間 下載裝置，並且提供下列功能和限制：

功能

• 可使用任何供應商或公司的簽署金鑰簽署任意訊息。
• 這可能會導致裝置接收 OTA 更新。
• 能修改任何硬體的作業 (例如應用程式處理器、 或 Flash 記憶體) 觸發的廣告，但詳情請參閱下方「限制」一節。 (但是，這類修改需要至少延遲 1 小時，且 破壞 RAM 內容的電源循環。)

限制

• 無法修改防竄改硬體 (例如 Titan M)。
• 無法讀取使用中裝置的 RAM。
• 無法猜測使用者的憑證 (PIN 碼、解鎖圖案、密碼) 或其他原因 輸入的名稱

解決方案

Android 12 RoR 更新系統提供安全性 以便防範非常複雜的攻擊者；而這麼做也能使用裝置端密碼和 PIN 碼會保留在裝置上，絕不會傳送至 Google 伺服器，也不會儲存在 Google 伺服器上。這個 是一套程序總覽，可確保提供的資安等級 類似於硬體式裝置的 RoR 系統：

• Android 會對儲存在裝置上的資料套用加密保護。
• 所有資料都會受到儲存在受信任的執行環境中儲存的金鑰保護 (TEE)。
• 只有在運作中的作業系統通過測試時，TEE 才會釋出金鑰 加密編譯驗證 (驗證開機程序)。
• 在 Google 伺服器上運作的 RoR 服務會儲存密鑰，藉此保護 CE 資料 且限時擷取。 整個 Android 生態系統都適用。
• 使用加密編譯金鑰 (受到使用者 PIN 碼保護) 可用於解鎖裝置 以及解密 CE 儲存空間
  • 安排裝置整晚重新啟動時，Android 會提示使用者進入 並計算合成密碼 (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 碼重播)，藉此恢復行動網路連線 連線能力 (通話、簡訊和資料服務需要)。 SIM 卡 PIN 碼和相應的 SIM 卡資訊 (ICCID 和 SIM 卡插槽) 號碼) 會一起安全儲存。可擷取及使用儲存的 PIN 碼 。如果裝置 SIM 卡 PIN 碼儲存在由 LSKF 保護的金鑰上，安全無虞。如果 SIM 卡已插入 已啟用 PIN 碼，如要與 RoR 伺服器互動，就需要 Wi-Fi 連線 ，與 OTA 更新和伺服器式 RoR 通訊，可確保基本功能 ( 行動網路連線)。

每當使用者成功啟用 SIM 卡 PIN 碼時，系統都會重新加密並儲存 SIM 卡 PIN 碼。 驗證或修改資料只要發生下列任一情況，系統就會捨棄 SIM 卡 PIN 碼 發生：

• 取出或重設 SIM 卡。
• 使用者停用 PIN。
• 發生非 RoR 啟動的重新啟動作業。

儲存的 SIM 卡 PIN 碼必須等到 RoR 重新啟動後才能使用一次，且 時間較短 (20 秒)，若 SIM 卡詳細資料 卡片一致。儲存的 SIM 卡 PIN 碼一律不會從 TelephonyManager 應用程式外流 無法由外部模組擷取。

導入指南

在 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 用戶端會叫用 TelephonyManager 系統 API 在 Android 12 中。這個 API 會將所有快取 PIN 碼從 將 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()

具有特殊權限的 APK 會使用 TelephonyManager 系統 API。

測試

如要測試新 API，請執行下列指令：

    adb shell cmd phone unattended-reboot

這個指令只有在殼層以根使用者的身分執行 (adb root) 時才有效。

僅限 Android 11

本頁的其餘部分適用於 Android 11。

自 2020 年 7 月起，RR HAL 的導入可分為兩大類：

1. 如果 SoC 硬體在重新啟動時支援 RAM 持續性，原始設備製造商 (OEM) 便可使用 Android 開放原始碼計畫的預設實作方式 (預設 RAM Escrow)。
2. 如果裝置硬體或 SoC 支援安全硬體安全區 (獨立的 搭載專屬 RAM 和 ROM 的安全輔助處理器，還須 包括：
   • 可偵測主要重新啟動的 CPU。
   • 具備硬體計時器來源，在重新啟動後仍會持續顯示。也就是說， 安全規則必須能夠偵測重新啟動，並在 。
   • 支援將託管金鑰儲存在安全區 RAM/ROM 中，以防該金鑰無法 遭到離線攻擊復原其儲存 RoR 金鑰的方式 因此內部人員或攻擊者無法予以復原。

預設 RAM 託管

Android 開放原始碼計畫已利用 RAM 持續性實作 RoR HAL。 為此，原始設備製造商 (OEM) 必須確保其 SoC 支援 RAM 持續性 不同的裝置重新啟動時部分 SoC 無法在重新啟動後保留 RAM 內容，因此 建議原始設備製造商 (OEM) 諮詢 SoC 合作夥伴，再啟用這個預設 HAL。 下一節的標準參考資料。

使用 RoR 進行 OTA 更新流程

手機上的 OTA 用戶端應用程式必須 Manifest.permission.REBOOT 和 Manifest.permission.RECOVERY 權限，以便呼叫必要方法， 實作 RoR先準備好這些必要條件後 更新步驟如下：

1. OTA 用戶端應用程式會下載更新。
2. OTA 用戶端應用程式呼叫 RecoverySystem#prepareForUnattendedUpdate 系統就會提示使用者在 鎖定螢幕。
3. 使用者在螢幕鎖定畫面解鎖裝置，且裝置已準備就緒 以套用更新
4. 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

預設重新啟動 Escrow HAL 實作

如要使用預設實作，您必須保留 65536 (0x10000) 位元組。一律不刪除 將這些位元組寫入非揮發性儲存空間，以確保安全屬性 持續性。

Linux 核心裝置樹狀結構異動

在 Linux kernel 的裝置樹狀結構中，您必須為 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