このページは Cloud Translation API によって翻訳されました。

ファイルベースの暗号化

Android 7.0 以降では、ファイルベースの暗号化 (FBE) がサポートされています。ファイルベースの暗号化では、個別にロックを解除できるさまざまなキーでさまざまなファイルを暗号化できます。

この記事では、新しいデバイスでファイルベースの暗号化を有効にする方法と、システムアプリケーションがダイレクトブート API を使用して、可能な限り最高で最も安全なエクスペリエンスをユーザーに提供する方法について説明します。

ダイレクトブート

ファイルベースの暗号化により、Android 7.0 で導入されたDirect Bootと呼ばれる新機能が有効になります。ダイレクトブートを使用すると、暗号化されたデバイスをロック画面から直接起動できます。以前は、フルディスク暗号化(FDE) を使用して暗号化されたデバイスでは、ユーザーはデータにアクセスする前に資格情報を提供する必要があり、電話は最も基本的な操作以外のすべてを実行できませんでした。たとえば、アラームは作動せず、アクセシビリティサービスは利用できず、電話は着信できず、基本的な緊急ダイヤラー操作のみに制限されていました。

ファイルベースの暗号化 (FBE) と、アプリケーションが暗号化を認識できるようにする新しい API の導入により、これらのアプリは限られたコンテキスト内で動作することが可能になりました。これは、ユーザーの個人情報を保護しながら、ユーザーが資格情報を提供する前に発生する可能性があります。

FBE 対応デバイスでは、デバイスの各ユーザーは、アプリケーションで使用できる 2 つのストレージの場所を持ちます。

Credential Encrypted (CE) ストレージ。デフォルトのストレージの場所であり、ユーザーがデバイスのロックを解除した後にのみ使用できます。
デバイス暗号化 (DE) ストレージ。これは、ダイレクトブートモード中と、ユーザーがデバイスのロックを解除した後の両方で使用できるストレージの場所です。

この分離により、暗号化が起動時のパスワードのみに基づくものではなくなるため、一度に複数のユーザーを保護できるため、作業プロファイルがより安全になります。

ダイレクトブート API を使用すると、暗号化対応アプリケーションがこれらの各領域にアクセスできます。ロック画面で資格情報を最初に入力することに応答してユーザーの CE ストレージのロックが解除されたとき、または作業プロファイルが作業チャレンジを提供する場合に、アプリケーションに通知する必要性に対応するために、アプリケーションのライフサイクルに変更があります。 Android 7.0 を実行するデバイスは、FBE を実装しているかどうかに関係なく、これらの新しい API とライフサイクルをサポートする必要があります。ただし、FBE がない場合、DE および CE ストレージは常にロック解除状態になります。

Ext4 および F2FS ファイルシステムでのファイルベースの暗号化の完全な実装は、Android オープンソースプロジェクト (AOSP) で提供されており、要件を満たすデバイスでのみ有効にする必要があります。 FBE の使用を選択するメーカーは、使用されるシステムオンチップ (SoC) に基づいて機能を最適化する方法を検討することをお勧めします。

AOSP で必要なすべてのパッケージは、ダイレクトブートに対応するように更新されています。ただし、デバイスメーカーがこれらのアプリのカスタマイズされたバージョンを使用している場合、少なくとも次のサービスを提供するダイレクトブート対応パッケージがあることを確認する必要があります。

テレフォニーサービスとダイヤラ
ロック画面へのパスワード入力方法

例とソース

Android は、ファイルベースの暗号化のリファレンス実装を提供します。その中で vold ( system/vold ) は、Android でストレージデバイスとボリュームを管理するための機能を提供します。 FBE の追加により、複数のユーザーの CE および DE キーのキー管理をサポートするいくつかの新しいコマンドが vold に提供されます。カーネルでファイルベースの暗号化機能を使用するためのコアの変更に加えて、ロックスクリーンや SystemUI を含む多くのシステムパッケージが、FBE およびダイレクトブート機能をサポートするように変更されました。これらには以下が含まれます：

AOSP Dialer (パッケージ/アプリ/Dialer)
卓上時計 (パッケージ/アプリ/DeskClock)
LatinIME (パッケージ/inputmethods/LatinIME)*
設定アプリ (パッケージ/アプリ/設定)*
SystemUI (フレームワーク/ベース/パッケージ/SystemUI)*

* defaultToDeviceProtectedStorageマニフェスト属性を使用するシステムアプリケーション

AOSP ソースツリーのフレームワークまたはパッケージディレクトリでコマンドmangrep directBootAwareを実行すると、暗号化を認識するアプリケーションとサービスのその他の例を見つけることができます。

依存関係

FBE の AOSP 実装を安全に使用するには、デバイスが次の依存関係を満たす必要があります。

Ext4 暗号化または F2FS 暗号化のカーネルサポート。
HAL バージョン 1.0 または 2.0 による Keymaster のサポート。 Keymaster 0.3 は、必要な機能を提供しないか、暗号化キーの十分な保護を保証しないため、サポートされていません。
Keymaster/ Keystoreおよび GatekeeperはTrusted Execution Environment (TEE) に実装して DE キーを保護し、承認されていない OS (デバイスにフラッシュされたカスタム OS) が単純に DE キーを要求できないようにする必要があります。
Keymaster の初期化にバインドされたハードウェア Root of TrustとVerified Bootは、許可されていないオペレーティングシステムがデバイス暗号化資格情報にアクセスできないようにするために必要です。

注: ストレージポリシーは、フォルダーとそのすべてのサブフォルダーに適用されます。メーカーは、暗号化されていないコンテンツを、OTA フォルダーと、システムを復号化するキーを保持するフォルダーに制限する必要があります。ほとんどのコンテンツは、デバイスで暗号化されたストレージではなく、資格情報で暗号化されたストレージに存在する必要があります。

実装

まず第一に、目覚まし時計、電話、アクセシビリティ機能などのアプリは、 Direct Boot開発者向けドキュメントに従って android:directBootAware にする必要があります。

カーネルのサポート

Ext4 および F2FS 暗号化のカーネルサポートは、Android 共通カーネルバージョン 3.18 以降で利用できます。バージョン 5.1 以降のカーネルで有効にするには、次を使用します。

CONFIG_FS_ENCRYPTION=y

古いカーネルの場合、デバイスのユーザーuserdataファイルシステムが Ext4 の場合はCONFIG_EXT4_ENCRYPTION=yを使用し、デバイスのユーザーデータファイルシステムがuserdataの場合はCONFIG_F2FS_FS_ENCRYPTION=yを使用します。

デバイスがAdoptable Storageをサポートするか、内部ストレージでメタデータ暗号化を使用する場合は、メタデータ暗号化のドキュメントで説明されているように、メタデータ暗号化に必要なカーネル構成オプションも有効にします。

デバイスメーカーは、Ext4 または F2FS 暗号化の機能サポートに加えて、ファイルベースの暗号化を高速化し、ユーザーエクスペリエンスを向上させるために、暗号化アクセラレーションも有効にする必要があります。たとえば、ARM64 ベースのデバイスでは、次のカーネル構成オプションを設定することで、ARMv8 CE (Cryptography Extensions) アクセラレーションを有効にすることができます。

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

パフォーマンスをさらに向上させ、電力使用量を削減するために、デバイスメーカーは、ストレージデバイスとの間でデータを暗号化/復号化するインライン暗号化ハードウェアの実装を検討することもできます。 Android 共通カーネル (バージョン 4.14 以降) には、ハードウェアとベンダードライバーのサポートが利用可能な場合にインライン暗号化を使用できるようにするフレームワークが含まれています。インライン暗号化フレームワークは、次のカーネル構成オプションを設定することで有効にできます。

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

デバイスが UFS ベースのストレージを使用している場合は、以下も有効にします。

CONFIG_SCSI_UFS_CRYPTO=y

デバイスが eMMC ベースのストレージを使用している場合は、次も有効にします。

CONFIG_MMC_CRYPTO=y

ファイルベースの暗号化を有効にする

デバイスで FBE を有効にするには、内部ストレージ ( userdata ) で有効にする必要があります。これにより、Adoptable Storage で FBE も自動的に有効になります。ただし、Adoptable Storage の暗号化形式は、必要に応じてオーバーライドできます。

内部記憶装置

userdata のfstab行のfs_mgr_flags列にオプションuserdata fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]]を追加することで、FBE が有効になります。このオプションは、内部ストレージの暗号化形式を定義します。コロンで区切られた最大 3 つのパラメーターが含まれます。

contents_encryption_modeパラメータは、ファイルコンテンツの暗号化に使用する暗号化アルゴリズムを定義します。 aes-256-xtsまたはadiantumのいずれかです。 Android 11 以降では、デフォルトのアルゴリズムであるaes-256-xtsを指定するために空のままにすることもできます。
filenames_encryption_modeパラメータは、ファイル名の暗号化に使用する暗号化アルゴリズムを定義します。 aes-256-cts 、 aes-256-heh 、 adiantum 、またはaes-256-hctr2かです。指定されていない場合、 contents_encryption_modeがaes-256-xts場合は aes- aes-256-ctsに、 contents_encryption_modeがadiantumの場合はadiantumにデフォルト設定されます。
Android 11 の新機能であるflagsパラメータは、 +文字で区切られたフラグのリストです。次のフラグがサポートされています。
- v1フラグは、バージョン 1 の暗号化ポリシーを選択します。 v2フラグは、バージョン 2 暗号化ポリシーを選択します。バージョン 2 の暗号化ポリシーは、より安全で柔軟な鍵派生機能を使用します。デフォルトは、デバイスが Android 11 以降 ( ro.product.first_api_levelによって決定) で起動された場合は v2 であり、デバイスが Android 10 以前で起動された場合は v1 です。
- inlinecrypt_optimizedフラグは、大量のキーを効率的に処理できないインライン暗号化ハードウェア向けに最適化された暗号化形式を選択します。これは、ファイルごとに 1 つではなく、CE キーまたは DE キーごとに 1 つのファイルコンテンツ暗号化キーを導出することによって行われます。それに応じて、IV (初期化ベクトル) の生成が調整されます。
- emmc_optimizedフラグはinlinecrypt_optimizedに似ていますが、IV を 32 ビットに制限する IV 生成方法も選択します。このフラグは、JEDEC eMMC v5.2 仕様に準拠しているため、32 ビット IV のみをサポートするインライン暗号化ハードウェアでのみ使用する必要があります。他のインライン暗号化ハードウェアでは、代わりにinlinecrypt_optimizedを使用してください。このフラグは、UFS ベースのストレージでは決して使用しないでください。 UFS 仕様では、64 ビット IV の使用が許可されています。
- ハードウェアでラップされたキーをサポートするデバイスでは、 wrappedkey_v0フラグにより、FBE でハードウェアでラップされたキーを使用できるようになります。これは、 inlinecryptマウントオプション、およびinlinecrypt_optimizedまたはemmc_optimizedフラグと組み合わせてのみ使用できます。

インライン暗号化ハードウェアを使用していない場合、ほとんどのデバイスで推奨される設定はfileencryption=aes-256-xtsです。インライン暗号化ハードウェアを使用している場合、ほとんどのデバイスで推奨される設定はfileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (または同等fileencryption=::inlinecrypt_optimized ) です。 AES アクセラレーションの形式を持たないデバイスでは、 fileencryption=adiantumを設定することにより、AES の代わりにAdiantumを使用できます。

Android 14 (実験的な AOSP) 以降、AES-HCTR2 は高速化された暗号化命令を使用するデバイスのファイル名暗号化の推奨モードです。ただし、新しい Android カーネルのみが AES-HCTR2 をサポートしています。将来の Android リリースでは、ファイル名暗号化のデフォルトモードになる予定です。カーネルが AES-HCTR2 をサポートしている場合、 filenames_encryption_modeをaes-256-hctr2に設定することで、ファイル名の暗号化を有効にすることができます。最も単純なケースでは、これはfileencryption=aes-256-xts:aes-256-hctr2で行われます。

Android 10 以前で起動したデバイスでは、 fileencryption=iceも受け入れられ、 FSCRYPT_MODE_PRIVATEファイルコンテンツ暗号化モードの使用を指定します。このモードは、Android 共通カーネルでは実装されていませんが、カスタムカーネルパッチを使用してベンダーによって実装される可能性があります。このモードで生成されるオンディスクフォーマットは、ベンダー固有のものでした。 Android 11 以降で起動するデバイスでは、このモードは許可されなくなり、代わりに標準の暗号化形式を使用する必要があります。

デフォルトでは、ファイルコンテンツの暗号化は Linux カーネルの暗号化 API を使用して行われます。代わりにインライン暗号化ハードウェアを使用する場合は、 inlinecryptマウントオプションも追加してください。たとえば、完全なfstab行は次のようになります。

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

注:

inlinecryptオプションとfileencryptionオプションは異なる列に表示されますinlinecryptはファイルシステムのマウントオプションであり、 fileencryptionは Android ユーザー空間のフラグであるためです。
インライン暗号化ハードウェアが正常に動作し、 wrappedkey_v0フラグが設定されていない場合は、デバイスをワイプすることなく、いつでもinlinecryptマウントオプションを追加または削除できます。つまり、ハードウェアでラップされたキーが有効になっていない限り、 inlinecryptは実装にのみ影響し、ディスク上のフォーマットには影響しません。インライン暗号化ハードウェアが正しく機能していることを確認するために、開発中にinlinecryptの削除をテストする必要があります。

採用可能なストレージ

Android 9以降、FBEとAdoptable Storageを併用できるようになりました。

また、 userdataにfileencryption fstab オプションを指定すると、Adoptable Storage で FBE とメタデータ暗号化の両方が自動的に有効になります。ただし、 PRODUCT_PROPERTY_OVERRIDESでプロパティを設定することにより、Adoptable Storage の FBE および/またはメタデータ暗号化形式をオーバーライドできます。

Android 11 以降で起動したデバイスでは、次のプロパティを使用します。

ro.crypto.volume.options (Android 11 の新機能) は、採用可能なストレージで FBE 暗号化形式を選択します。これは、 fileencryption fstab オプションの引数と同じ構文を持ち、同じデフォルトを使用します。ここで何を使用するかについては、上記のfileencryptionの推奨事項を参照してください。
ro.crypto.volume.metadata.encryptionは、採用可能なストレージのメタデータ暗号化形式を選択します。メタデータ暗号化のドキュメントを参照してください。

Android 10 以前で起動したデバイスでは、次のプロパティを使用します。

ro.crypto.volume.contents_modeは、コンテンツの暗号化モードを選択します。これは、 ro.crypto.volume.optionsの最初のコロンで区切られたフィールドに相当します。
ro.crypto.volume.filenames_modeは、ファイル名の暗号化モードを選択します。これはro.crypto.volume.optionsの 2 番目のコロンで区切られたフィールドと同等ですが、Android 10 以下で起動したデバイスのデフォルトはaes-256-hehです。ほとんどのデバイスでは、これを明示的にaes-256-ctsにオーバーライドする必要があります。
ro.crypto.fde_algorithmとro.crypto.fde_sector_sizeは、採用可能なストレージのメタデータ暗号化形式を選択します。メタデータ暗号化のドキュメントを参照してください。

Keymaster との統合

鍵の生成とカーネル鍵リングの管理はvoldによって処理されます。 FBE の AOSP 実装では、デバイスが Keymaster HAL バージョン 1.0 以降をサポートしている必要があります。以前のバージョンの Keymaster HAL はサポートされていません。

最初の起動時に、ユーザー 0 のキーが生成され、起動プロセスの早い段階でインストールされます。 initのon-post-fsフェーズが完了するまでに、Keymaster は要求を処理する準備ができている必要があります。 Pixel デバイスでは、これは、 /dataがマウントされる前に Keymaster が開始されるようにスクリプトブロックを設定することで処理されます。

暗号化ポリシー

ファイルベースの暗号化は、ディレクトリレベルで暗号化ポリシーを適用します。デバイスのuserdataパーティションが最初に作成されると、 initスクリプトによって基本的な構造とポリシーが適用されます。これらのスクリプトは、最初のユーザー (ユーザー 0) の CE キーと DE キーの作成をトリガーし、これらのキーで暗号化するディレクトリを定義します。追加のユーザーとプロファイルが作成されると、必要な追加のキーが生成され、キーストアに格納されます。資格情報とデバイスの保存場所が作成され、暗号化ポリシーによってこれらのキーがそれらのディレクトリにリンクされます。

Android 11 以降では、暗号化ポリシーは一元化された場所にハードコーディングされなくなりましたが、init スクリプトのmkdirコマンドへの引数によって定義されます。システム DE キーで暗号化されたディレクトリはencryption=Require使用しますが、暗号化されていないディレクトリ (またはサブディレクトリがユーザーごとのキーで暗号化されているディレクトリ) はencryption=Noneを使用します。

Android 10 では、暗号化ポリシーは次の場所にハードコードされていました。

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Android 9 以前では、場所は次のとおりでした。

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

例外を追加して、特定のディレクトリがまったく暗号化されないようにすることができます。この種の変更が行われた場合、デバイスメーカーは、暗号化されていないディレクトリを使用する必要があるアプリケーションへのアクセスのみを許可するSELinux ポリシーを含める必要があります。これにより、信頼されていないアプリケーションがすべて除外されます。

これの唯一の既知の受け入れ可能な使用例は、従来の OTA 機能のサポートです。

システムアプリケーションでのダイレクトブートのサポート

アプリケーションをダイレクトブートに対応させる

システムアプリの迅速な移行を容易にするために、アプリケーションレベルで設定できる 2 つの新しい属性があります。 defaultToDeviceProtectedStorage属性は、システムアプリでのみ使用できます。 directBootAware属性は、すべてのユーザーが使用できます。

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

アプリケーションレベルのdirectBootAware属性は、アプリ内のすべてのコンポーネントを暗号化対応としてマークするための省略形です。

defaultToDeviceProtectedStorage属性は、CE ストレージではなく、DE ストレージを指すようにデフォルトのアプリストレージの場所をリダイレクトします。このフラグを使用するシステムアプリは、既定の場所に保存されているすべてのデータを慎重に監査し、CE ストレージを使用するように機密データのパスを変更する必要があります。このオプションを使用するデバイスメーカーは、保存しているデータを慎重に検査して、個人情報が含まれていないことを確認する必要があります。

このモードで実行している場合、次のシステム API を使用して、必要に応じて CE ストレージによってサポートされるコンテキストを明示的に管理できます。これは、Device Protected の対応する API と同等です。

Context.createCredentialProtectedStorageContext()
Context.isCredentialProtectedStorage()

複数ユーザーのサポート

マルチユーザー環境の各ユーザーは、個別の暗号化キーを取得します。すべてのユーザーは、DE キーと CE キーの 2 つのキーを取得します。ユーザー 0 は特別なユーザーであるため、最初にデバイスにログインする必要があります。これは、デバイス管理の用途に適しています。

暗号対応アプリケーションは、次のようにユーザー間で対話しますINTERACT_ACROSS_USERSとINTERACT_ACROSS_USERS_FULLにより、アプリケーションはデバイス上のすべてのユーザー間で動作できます。ただし、これらのアプリは、既にロック解除されているユーザーの CE 暗号化ディレクトリにのみアクセスできます。

アプリケーションは DE 領域間で自由にやり取りできる場合がありますが、1 人のユーザーがロック解除されたからといって、デバイス上のすべてのユーザーがロック解除されるわけではありません。アプリケーションは、これらの領域にアクセスする前に、このステータスを確認する必要があります。

各仕事用プロファイルのユーザー ID も、DE と CE の 2 つのキーを取得します。仕事の課題が満たされると、プロファイルユーザーのロックが解除され、Keymaster (TEE 内) がプロファイルの TEE キーを提供できるようになります。

更新の処理

リカバリパーティションは、ユーザーデータパーティション上の DE で保護されたストレージにアクセスできません。 FBE を実装するデバイスは、 A/B システムアップデートを使用して OTA をサポートすることを強くお勧めします。 OTA は通常の操作中に適用できるため、暗号化されたドライブ上のデータにアクセスするためのリカバリは必要ありません。

従来の OTA ソリューションを使用している場合、ユーザーuserdataパーティションの OTA ファイルにアクセスするにはリカバリが必要です。

userdataパーティションに最上位ディレクトリ (例misc_ne ) を作成します。
この最上位ディレクトリを暗号化ポリシーの例外に追加します (上記の暗号化ポリシーを参照してください)。
最上位ディレクトリ内にディレクトリを作成して、OTA パッケージを保持します。
SELinux ルールとファイルコンテキストを追加して、このフォルダーとその内容へのアクセスを制御します。 OTA 更新を受信するプロセスまたはアプリケーションのみが、このフォルダーの読み取りと書き込みを行うことができます。他のアプリケーションやプロセスは、このフォルダーにアクセスできません。

検証

実装されたバージョンの機能が意図したとおりに機能することを確認するには、最初にDirectBootHostTestやEncryptionTestなどの多くの CTS 暗号化テストを実行します。

デバイスが Android 11 以降を実行している場合は、 vts_kernel_encryption_testも実行します。

atest vts_kernel_encryption_test

また：

vts-tradefed run vts -m vts_kernel_encryption_test

さらに、デバイスの製造元は、次の手動テストを実行する場合があります。 FBE が有効になっているデバイスの場合:

ro.crypto.stateが存在することを確認します
- ro.crypto.stateが暗号化されていることを確認する
ro.crypto.typeが存在することを確認します
- ro.crypto.typeがfileに設定されていることを確認します

さらに、テスターは、プライマリユーザーに設定されたロック画面でuserdebugインスタンスを起動できます。次に、デバイスにadbシェルを挿入し、 suを使用して root になります。 /data/dataに暗号化されたファイル名が含まれていることを確認してください。そうでない場合は、何かが間違っています。

また、デバイスメーカーは、デバイスまたはカーネルで fscrypt のアップストリーム Linux テストを実行することを検討することをお勧めします。これらのテストは、xfstests ファイルシステムテストスイートの一部です。ただし、これらのアップストリームテストは、Android では公式にはサポートされていません。

AOSP 実装の詳細

このセクションでは、AOSP の実装について詳しく説明し、ファイルベースの暗号化がどのように機能するかについて説明します。デバイスメーカーがデバイスで FBE とダイレクトブートを使用するために、ここで変更を加える必要はありません。

fscrypt 暗号化

AOSP 実装は、カーネルで「fscrypt」暗号化 (ext4 および f2fs でサポート) を使用し、通常は次のように構成されます。

XTS モードで AES-256 を使用してファイルの内容を暗号化する
CBC-CTS モードで AES-256 を使用してファイル名を暗号化する

Adiantum 暗号化もサポートされています。 Adiantum 暗号化が有効になっている場合、ファイルの内容とファイル名の両方が Adiantum で暗号化されます。

fscrypt の詳細については、アップストリームカーネルのドキュメントを参照してください。

鍵の導出

512 ビットキーであるファイルベースの暗号化キーは、TEE に保持されている別のキー (256 ビット AES-GCM キー) によって暗号化されて格納されます。この TEE キーを使用するには、次の 3 つの要件を満たす必要があります。

認証トークン
拡大された認証情報
「secdiscardable ハッシュ」

認証トークンは、ユーザーが正常にログインしたときにGatekeeperによって生成される、暗号で認証されたトークンです。正しい認証トークンが提供されない限り、TEE はキーの使用を拒否します。ユーザーに資格情報がない場合、認証トークンは使用されず、必要ありません。

ストレッチされた資格情報は、 scryptアルゴリズムでソルティングおよびストレッチされた後のユーザー資格情報です。資格情報は、 scryptに渡すためにvoldに渡される前に、実際にはロック設定サービスで 1 回ハッシュされます。これは、 KM_TAG_APPLICATION_IDに適用されるすべての保証を使用して、TEE のキーに暗号的にバインドされます。ユーザーが資格証明を持っていない場合、拡張された資格証明は使用されず、必要ありません。

secdiscardable hashは、シードなどのキーを再構築するために使用される他の情報と一緒に保存されるランダムな 16 KB ファイルの 512 ビットハッシュです。このファイルは、キーが削除されるか、新しい方法で暗号化されると安全に削除されます。この追加された保護により、攻撃者はこの安全に削除されたファイルのすべてのビットを回復してキーを回復する必要があります。これは、 KM_TAG_APPLICATION_IDに適用されるすべての保証を使用して、TEE のキーに暗号的にバインドされます。

ほとんどの場合、FBE キーは、ファイルごとまたはモードごとのキーなど、実際に暗号化を行うために使用されるサブキーを生成するために、カーネル内で追加のキー派生ステップも実行されます。バージョン 2 の暗号化ポリシーでは、HKDF-SHA512 がこれに使用されます。