重啟時恢復

在Android中11,OTA更新可以使用被施加A / B更新虛擬A / B更新機制,與組合RecoverySystem類方法。後一設備重啟應用OTA更新,恢復打開-重啟(ROR)解鎖設備憑證加密(CE)存儲

儘管合作夥伴可以將此過程與 OTA 系統功能配對,該功能在 Android 11 中預期設備空閒時應用更新,但在 Android 12 中合作夥伴不需要額外的 OTA 系統功能。 RoR 過程為用戶提供了額外的安全性和便利性,因為可以在設備空閒時間進行更新,而 Android 12 多客戶端和基於服務器的更新功能共同提供設備硬件級類型的安全性。

雖然你必須為提供設備的相關權限android.hardware.reboot_escrow功能支持的回報率在11 Android的,你不需要這個,使基於服務器的回報率在12的Android和更高,因為它們不使用HAL。

提供設備許可android.hardware.reboot_escrow特徵。您無需執行任何操作即可在 Android 12 中啟用基於服務器的 RoR,因為 Android 12 及更高版本不使用 HAL。

背景

與Android 7開始,Android支援直接引導,其使得設備上的應用程式之前CE存儲由用戶解鎖以啟動。在啟動後需要輸入鎖屏知識因子 (LSKF) 之前,直接啟動支持的實施為用戶提供了更好的體驗。

RoR 允許在 OTA 更新後啟動重啟時解鎖設備上所有應用程序的 CE 存儲,包括那些不支持直接啟動的應用程序。此功能使用戶能夠在重新啟動後從所有已安裝的應用程序接收通知。

威脅模型

回報率的實現必須保證當一個設備落入攻擊者的手中,這是非常困難的攻擊者恢復用戶的CE的加密數據,即使設備上電後,CE存儲被解鎖,並且該裝置通過解鎖用戶收到 OTA 更新後。即使攻擊者獲得了廣播加密簽名密鑰的訪問權限,內部攻擊抵抗也必須有效。

具體而言,消費電子存儲不能被攻擊者物理誰擁有該設備,並擁有這些能力和限制閱讀:

能力

  • 可以使用任何供應商或公司的簽名密鑰對任意消息進行簽名。
  • 可能導致設備接收 OTA 更新。
  • 可以修改任何硬件的操作(例如,應用處理器,或閃速存儲器) -除非在詳述的限制之下。 (但是,這種修改涉及至少一小時的延遲,以及破壞 RAM 內容的電源循環。)

限制

  • 無法修改防篡改硬件(例如 Titan M)的操作。
  • 無法讀取實時設備的 RAM。
  • 無法猜測用戶的憑據(PIN、圖案、密碼)或以其他方式導致輸入它們。

解決方案

Android 12 RoR 更新系統提供了針對非常複雜的攻擊者的安全性,並且在設備上的密碼和 PIN 保留在設備上的情況下提供安全性 - 它們永遠不會發送到或存儲在 Google 服務器上。這是確保提供的安全級別類似於基於硬件的設備級 RoR 系統的過程的概述:

  • Android 對存儲在設備上的數據應用加密保護。
  • 所有數據都通過存儲在密鑰保護可信執行環境(TEE)。
  • 開球僅在操作系統上運行經過加密驗證(驗證開機)釋放鍵。
  • RoR的服務通過存儲,可以只在有限的時間內取回秘密在谷歌服務器上作保CE數據運行。這適用於整個 Android 生態系統。
  • 受用戶 PIN 保護的加密密鑰用於解鎖設備和解密 CE 存儲。
    • 當安排夜間重啟時,Android 會提示用戶輸入他們的 PIN,然後計算合成密碼 (SP)。
    • 然後,它加密SP兩次:一次用鑰匙K_s存儲在RAM中,並再次用鑰匙K_k存儲在TEE。
    • 雙重加密的 SP 存儲在磁盤上,並且 SP 會從 RAM 中擦除。這兩個鍵新鮮生成並用於重新啟動一次
  • 當它的時間來重新啟動,Android的委託K_s到服務器。該收據K_k它存儲在磁盤上之前被加密。
  • 重新啟動後,Android使用K_k解密收據,然後將其發送到服務器去取回K_s
    • K_kK_s用於解密存儲在磁盤上的SP。
    • Android 使用 SP 解鎖 CE 存儲並允許正常啟動應用程序。
    • K_kK_s被丟棄。

確保手機安全的更新可以在您方便的時間進行:在您睡覺時。

SIM-PIN重放

在某些情況下,SIM 卡的 PIN 碼會從緩存中得到驗證,這一過程稱為 SIM-PIN 重放。

已啟用 PIN 的 SIM 卡還必須在無人值守重啟後進行無縫 PIN 碼驗證(SIM-PIN 重放),以恢復蜂窩連接(電話、短信和數據服務所需​​)。 SIM PIN 及其匹配的 SIM 卡信息(ICCID 和 SIM 卡槽號)被安全地存儲在一起。只有在成功進行無人值守重啟後,才能檢索存儲的 PIN 並將其用於驗證。如果設備受到保護,SIM PIN 將與受 LSKF 保護的密鑰一起存儲。如果SIM卡有PIN啟用,RoR的服務器交互,需要重新啟動後的OTA更新和基於服務器的回報率,從而保證基本功能的Wi-Fi連接(與手機連接)。

每次用戶成功啟用、驗證或修改 SIM PIN 時,都會重新加密並存儲它。如果發生以下任何一種情況,SIM PIN 將被丟棄:

  • SIM 被移除或重置。
  • 用戶禁用 PIN。
  • 發生了非 RoR 啟動的重啟。

存儲的SIM PIN只能一次RoR的啟動重啟後使用,並且只在非常短的持續時間(20秒) -如果SIM卡匹配的細節。存儲的 SIM PIN 永遠不會離開 TelephonyManager 應用程序,並且無法由外部模塊檢索。

實施指南

在 Android 12 中,當合作夥伴推送 OTA 更新時,多客戶端和基於服務器的 RoR 功能為合作夥伴提供了更輕的負載。必要的更新可以在方便的設備停機期間進行,例如在指定的睡眠時間。

為確保此類時間段內的 OTA 更新不會中斷用戶,請採用暗模式來減少光發射。要做到這一點,有串原因,設備的bootloader搜索unattended 。如果unattendedtrue ,將設備放在暗模式。請注意,每個 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 已被棄用。

電話經理

所述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()

TelephonyManager 系統 API 由特權 APK 使用。

測試

要測試新 API,請執行以下命令:

    adb shell cmd phone unattended-reboot

該命令只當殼以root權限運行(工作adb root )。

僅限 Android 11

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

截至 2020 年 7 月,RoR HAL 的實現分為兩類:

  1. 如果在重新啟動SoC的硬件支持RAM的持久性,原始設備製造商可以使用AOSP的默認實現(默認RAM託管)。
  2. 如果設備硬件或 SoC 支持安全硬件飛地(具有自己的 RAM 和 ROM 的離散安全協處理器),則它還必須執行以下操作:
    • 能夠檢測到主 CPU 重啟。
    • 有一個硬件定時器源,在重新啟動後仍然存在。也就是說,飛地必須能夠檢測到重新啟動並且使在重新啟動之前設置的計時器到期。
    • 支持將託管密鑰存儲在飛地 RAM/ROM 中,使其無法通過離線攻擊恢復。它必須以一種使內部人員或攻擊者無法恢復它的方式存儲 RoR 密鑰。

默認 RAM 託管

AOSP 使用 RAM 持久性實現了 RoR HAL。為此,OEM 必須確保其 SoC 支持跨重啟的 RAM 持久性。某些 SoC 無法在重新啟動後保留 RAM 內容,因此建議 OEM 在啟用此默認 HAL 之前諮詢其 SoC 合作夥伴。下一節中對此的規範參考。

使用 RoR 的 OTA 更新流程

在手機上的OTA客戶端應用程序必須有Manifest.permission.REBOOTManifest.permission.RECOVERY權限調用必要的方法來實現的回報率。有了這個先決條件,更新流程遵循以下步驟:

  1. OTA 客戶端應用程序下載更新。
  2. OTA客戶端應用程序調用RecoverySystem#prepareForUnattendedUpdate觸發用戶被提示輸入他們的PIN,圖案或鎖屏上的下一個解鎖時的密碼。
  3. 用戶在鎖屏時解鎖設備,設備已準備好應用更新。
  4. OTA客戶端應用程序調用RecoverySystem#rebootAndApply ,立即觸發重新啟動。

在此流程結束時,設備重新啟動並且 RoR 機制解鎖憑證加密 (CE) 存儲。到的應用程序,這顯示為普通用戶解鎖,因此它們接收的所有信號,例如ACTION_LOCKED_BOOT_COMPLETEDACTION_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 (如pmem1pmem2 )。

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