Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

再起動時に再開

アンドロイド11において、OTAアップデートを使用して適用することができるA / B更新または仮想A / Bの更新と合わせ機構、 RecoverySystemのクラスメソッドを。デバイスは、OTAアップデートを適用するために再起動した後、再開オンリブート(RoRの)は、デバイスロック解除資格暗号化(CE)ストレージ

パートナーはこのプロセスを、Android 11でデバイスがアイドル状態であると予想されるときに更新を適用するOTAシステム機能と組み合わせることができますが、Android12パートナーでは追加のOTAシステム機能は必要ありません。 RoRプロセスは、デバイスのアイドル時間中に更新を行うことができるため、ユーザーにセキュリティと利便性を追加します。Android12マルチクライアントとサーバーベースの更新機能は、デバイスのハードウェアレベルのタイプのセキュリティを提供します。

あなたは、デバイスのアクセス許可を提供する必要がありますがandroid.hardware.reboot_escrow Androidの11でRoRのをサポートするための機能を、あなたは彼らがHALを使用していないので、Androidの12でサーバーベースのRoRのを有効にして高いためにこれにする必要はありません。

用のデバイス権限提供android.hardware.reboot_escrow機能を。 Android 12以降ではHALを使用しないため、Android12でサーバーベースのRoRを有効にするために何もする必要はありません。

バックグラウンド

アンドロイド7以降では、Androidのは、サポートされている直接ブートCEストレージがユーザによってロックが解除される前に起動するデバイスでアプリを可能にします。ダイレクトブートサポートの実装により、ブート後にロック画面ナレッジファクター(LSKF)を入力する必要が生じる前に、ユーザーのエクスペリエンスが向上しました。

RoRを使用すると、OTAの更新後に再起動が開始されたときに、ダイレクトブートをサポートしていないアプリを含め、デバイス上のすべてのアプリのCEストレージのロックを解除できます。この機能により、ユーザーは再起動後に、インストールされているすべてのアプリから通知を受け取ることができます。

脅威モデル

RoRのの実装では、デバイスが攻撃者の手に渡ったとき、攻撃者は、デバイスがCEストレージのロックが解除され、電源が入っている場合でも、ユーザーのCE-暗号化されたデータを回復するために、それは非常に困難だということを確認する必要があり、デバイスがでロックが解除されますOTAアップデートを受信した後のユーザー。インサイダー攻撃への耐性は、攻撃者がブロードキャスト暗号署名キーにアクセスした場合でも効果的である必要があります。

具体的には、CEのストレージは、物理的にデバイスを持っており、これらの機能と制限があり、攻撃者によって読み取られてはなりません

機能

  • 任意のベンダーまたは会社の署名キーを使用して、任意のメッセージに署名できます。
  • デバイスがOTAアップデートを受信する原因となる可能性があります。
  • (例えばアプリケーションプロセッサ、またはフラッシュメモリのような)ハードウェアの動作を変更することができます-に詳述されている場合を除き制限以下。 (ただし、このような変更には、少なくとも1時間の遅延と、RAMの内容を破壊する電源の入れ直しの両方が含まれます。)

制限事項

  • 改ざん防止ハードウェア(Titan Mなど)の動作を変更することはできません。
  • ライブデバイスのRAMを読み取ることができません。
  • ユーザーの資格情報(PIN、パターン、パスワード)を推測したり、入力させたりすることはできません。

解決

Android 12 RoRアップデートシステムは、非常に高度な攻撃者に対するセキュリティを提供し、デバイス上のパスワードとPINがデバイスに残っている間、Googleサーバーに送信されたり保存されたりすることはありません。これは、提供されるセキュリティレベルがハードウェアベースのデバイスレベルのRoRシステムと同様であることを保証するプロセスの概要です。

  • Androidは、デバイスに保存されているデータに暗号化保護を適用します。
  • すべてのデータは、に保存されたキーによって保護されている、信頼できる実行環境(TEE)。
  • 実行中のオペレーティングシステムは、暗号化、認証(検証済みブート通過した場合TEEは、キーのみを解放します。
  • 限られた時間のために取得することができる秘密を格納することで、Googleのサーバーをしっかり止めCEデータ上で実行されているRoRのサービス。これはAndroidエコシステム全体で機能します。
  • ユーザーのPINで保護された暗号化キーは、デバイスのロックを解除し、CEストレージを復号化するために使用されます。
    • 夜間の再起動がスケジュールされると、AndroidはユーザーにPINの入力を求め、合成パスワード(SP)を計算します。
    • その後、二回SPを暗号化:キーで一度K_s RAMに格納され、再びキーでK_k TEEに保存されています。
    • 二重暗号化されたSPはディスクに保存され、SPはRAMから消去されます。両方のキーを新たに1つだけの再起動のために生成され、使用されています。
  • リブートするときの時間、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再生)を実行して、セルラー接続を復元する必要があります(電話、SMSメッセージ、およびデータサービスに必要)。 SIM PINとそれに対応するSIMカード情報(ICCIDとSIMスロット番号)は、一緒に安全に保管されます。保存されたPINは、無人再起動が成功した後にのみ取得して検証に使用できます。デバイスが保護されている場合、SIMPINはLSKFで保護されたキーとともに保存されます。 SIMは、そのPINが有効になっている場合は、RoRのサーバとの相互作用は、OTAアップデート、再起動後(セルラーコネクティビティと)基本的な機能を確保し、サーバーベースのRoRの、のためのWiFi接続が必要です

SIM PINは、ユーザーがSIM PINを有効化、検証、または変更するたびに再暗号化および保存されます。次のいずれかが発生した場合、SIMPINは破棄されます。

  • SIMが取り外されるかリセットされます。
  • ユーザーはPINを無効にします。
  • RoRによって開始されていない再起動が発生しました。

SIMカードの試合の詳細場合-保存されたSIM PINは一度しかRoRの主導の再起動後、唯一の非常に短い時間間隔(20秒)のために使用することができます。保存されたSIMPINは、TelephonyManagerアプリを離れることはなく、外部モジュールから取得することもできません。

実装ガイドライン

Android 12では、マルチクライアントおよびサーバーベースのRoR機能により、パートナーがOTAアップデートをプッシュする際の負荷が軽減されます。必要な更新は、指定されたスリープ時間中など、デバイスの便利なダウンタイム中に発生する可能性があります。

このような期間中のOTA更新がユーザーの邪魔にならないようにするには、ダークモードを使用して発光を軽減します。そのためには、文字列の理由のためのデバイスブートローダ検索持ってunattended 。場合はunattendedあるtrue 、暗いモードでデバイスを置きます。音と光の放出を軽減するのは各OEMの責任であることに注意してください。

Android 12にアップグレードする場合、またはAndroid 12デバイスを起動する場合は、新しいRoR機能を実装するために何もする必要はありません。

マルチクライアント流れ、1回の新しいコールがありますisPreparedForUnattendedUpdate以下に示すが、:

@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
            android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)

HALはAndroid12で非推奨になるため、これを実装する必要はありません。

TelephonyManager

OTAクライアントが起動しますTelephonyManager再起動がAndroidの12の移動は、すべてのPINコードをキャッシュされたこのAPIで差し迫っているとき、システムの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()

TelephonyManagerシステムAPIは、特権APKによって使用されます。

テスト

新しいAPIをテストするには、次のコマンドを実行します。

    adb shell cmd phone unattended-reboot

シェルはルート(として実行されている場合は、このコマンドはのみ動作adb root )。

Android11のみ

このページの残りの部分はAndroid11に適用されます。

2020年7月の時点で、RoRHALの実装は2つのカテゴリに分類されます。

  1. リブートしてSoCのハードウェアサポートのRAMの持続した場合、OEMは(AOSPにデフォルトの実装を使用することができますRAMエスクローデフォルト)。
  2. デバイスハードウェアまたはSoCが安全なハードウェアエンクレーブ(独自のRAMとROMを備えた個別のセキュリティコプロセッサー)をサポートしている場合は、さらに次のことを行う必要があります。
    • メインCPUの再起動を検出できます。
    • 再起動後も持続するハードウェアタイマーソースを用意します。つまり、エンクレーブは再起動を検出し、再起動前に設定されたタイマーを期限切れにする必要があります。
    • エスクローされたキーをエンクレーブRAM / ROMに保存して、オフライン攻撃で回復できないようにすることをサポートします。インサイダーや攻撃者がRoRキーを回復できないようにRoRキーを保存する必要があります。

デフォルトのRAMエスクロー

AOSPには、RAM永続性を使用したRoRHALの実装があります。これが機能するためには、OEMは、SoCが再起動後もRAMの永続性をサポートしていることを確認する必要があります。一部のSoCは、再起動後もRAMの内容を保持できないため、OEMは、このデフォルトのHALを有効にする前にSoCパートナーに相談することをお勧めします。次のセクションでこれに関する標準的なリファレンス。

RoRを使用したOTA更新のフロー

電話でのOTAクライアントアプリは持っている必要がありますManifest.permission.REBOOTManifest.permission.RECOVERY RoRのを実装するために必要なメソッドを呼び出すための権限を。その前提条件が整っている場合、更新のフローは次の手順に従います。

  1. OTAクライアントアプリがアップデートをダウンロードします。
  2. OTAクライアントアプリコールRecoverySystem#prepareForUnattendedUpdateそのPIN、パターン、または次のロック解除時のロック画面にパスワードの入力を要求するユーザーをトリガします。
  3. ユーザーはロック画面でデバイスのロックを解除し、デバイスは更新を適用する準備ができています。
  4. OTAクライアントアプリコールRecoverySystem#rebootAndApplyすぐに再起動をトリガし、。

このフローの最後に、デバイスがリブートし、RoRメカニズムがクレデンシャル暗号化(CE)ストレージのロックを解除します。 Appsに、通常のユーザーのロック解除など、この表示されますが、そう、彼らのようなすべての信号、受信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 (のような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