Marshmallow暗号化は技術的にどのように機能しますか?


14

プッシュ更新により、Nexus 5にMarshmallowをインストールしました。暗号化の仕組みについて混乱しています。コンピューターでの暗号化の技術的な知識があります。Android 6についても同様の知識を得たいと思います。

以下は私がやったことと私が混乱した方法です。工場出荷時の設定にリセットした後、PINを設定してからデバイスを暗号化しました。起動時に、PINの入力を求められましたが、これは予想どおりでした。その後、PINを削除してデバイスを再起動しました。起動時にPINを要求しませんでしたが、デバイスはセットアップメニューで暗号化されていると報告しました。後者は、PINが復号化キーのロックを解除することを期待していたため、私を混乱させるものです。

質問:

  • PINなしの暗号化の場合、復号化キーはどこから来ますか?TPMに似たチップに保存されていると思いますが、これは正しいですか?もしそうなら、ハッカーがチップからこのキーをリクエストするのを防ぐものは何ですか?ファームウェアのハッシュをチェックしますか?他に何か?技術的な詳細をいただければ幸いです。
  • PINを使用した暗号化の場合、PINは復号化キーにアクセスするための追加のトークンとして使用されますか?または、PINがない場合とまったく同じように復号化プロセスが機能しますか。

TL; DL回答:

復号化キーは、次のすべてでロック解除されます。

  • PIN(またはパスワードなど)または存在しない場合はデフォルトのパスワード
  • TEE(抽出できないキーを使用するハードウェア支援署名ジェネレーター)
  • ソルト(簡単に入手できますが、レインボーテーブル攻撃を防ぎます)

ありがとう。Lollipopに適用されますが、これは私が知る限り正しい答えです。Lにパスワードなしの暗号化を設定したり、暗号化後にPINを削除したりすることを思い出せないため、MとLに違いがあると思いました。
marcv81

回答:


15

私はここのAndroidマニュアルから引用していますが、:

注意:

私が使用したソースは、マシュマロには直接関係ありませんが、ロリポップ以上には関係があります。

TL:DR

OPの質問に今すぐ対処します。技術的な詳細が続きます。

  1. デフォルトの暗号化キーは、ハードウェアソース(TPMに類似したチップ)とソースファイルで定義されdefault_passwordているAOSPのデフォルトパスワードから取得されcryptfs.cます。以下を参照してください。

  2. はい、デフォルトだけでなく、パスワードはキーになり、TEEと呼ばれるTPMのようなチップに保存されます(「Trusted Execution Environment」の略。詳細は以下を参照)。

  3. デバイスのSoC上のチップにUART / JTAGでアクセスできるハッカーは、技術的にTEEキーにアクセスするか、カスタムカーネルがこの情報をハッカーに漏らす可能性があります。陰謀説の一部の3文字の代理店は、OEMと提携してこれらの安全でないカーネルを実動デバイスで使用できる可能性がありますが、私はそれで多くの店を建てることはしません。繰り返しますが、詳細についてはこの回答の最後のセクションを参照してください。

ハッカーがキーにアクセスできないようにする唯一の方法は、そのために必要な多大な労力です。

  1. ファームウェア(Googleによる「検証済みブート」と呼ばれる)のハッシュ(チェックサム)のチェックは、実際にはデフォルトでLollipop上で行われ(JellyBean 4.3以降で利用可能)、と呼ばれるカーネルモジュールによって行われますdm-verity。ただし、これは暗号化ステータスとは無関係です。

出典: AOSPセキュリティガイドはこちら

  1. カスタムパスワードを使用してシステムを復号化するプロセスについては、以下を参照してください。ここで、ユーザーパスワードが暗号化キーの作成と使用の両方に関係していることをお知らせします。

概要

最初の起動時に、デバイスはランダムに生成された128ビットのマスターキーを作成し、デフォルトのパスワードと保存されたソルトでハッシュします。デフォルトのパスワードは「default_password」です。ただし、結果のハッシュはTEE(TrustZoneなど)を介して署名され、署名のハッシュを使用してマスターキーを暗号化します。

Android Open Source Project cryptfs.cファイルで定義されているデフォルトのパスワードを見つけることができます。

ユーザーがデバイスでPIN /パスまたはパスワードを設定すると、128ビットキーのみが再暗号化されて保存されます。(つまり、ユーザーPIN /パス/パターンの変更は、ユーザーデータパーティションの再暗号化を引き起こしません。)

デフォルトの暗号化で暗号化されたデバイスを起動する

これは、パスワードなしで暗号化されたデバイスを起動したときに起こることです。Android 5.0デバイスは初回起動時に暗号化されるため、パスワードを設定しないでください。したがって、これはデフォルトの暗号化状態です。

  1. パスワードなしで暗号化された/ dataを検出する

/ dataをマウントできず、フラグの1つencryptableまたはforceencrypt設定されているため、Androidデバイスが暗号化されていることを検出します。

voldに設定vold.decryptするtrigger_default_encryptionと、defaultcryptoサービスが開始されます。trigger_default_encryption暗号化タイプをチェックして、/ dataがパスワードありまたはパスワードなしで暗号化されているかどうかを確認します。

  1. / dataの復号化

dm-cryptデバイスが使用できるように、ブロックデバイス上にデバイスを作成します。

  1. / dataをマウント

vold次に、復号化された実/ dataパーティションをマウントし、新しいパーティションを準備します。プロパティvold.post_fs_data_doneをに設定して0からに設定vold.decrypttrigger_post_fs_dataます。これによりinit.rcpost-fs-dataコマンドが実行されます。必要なディレクトリまたはリンクを作成し、に設定vold.post_fs_data_done1ます。

いったんvoldそのプロパティに1を見て、それがプロパティを設定vold.decryptします:trigger_restart_framework。これによりinit.rc、クラス内のサービスがmain再び開始され、ブート後初めてクラスlate_startのサービスも開始されます。

  1. フレームワークを開始

これで、フレームワークは復号化された/ dataを使用してすべてのサービスを起動し、システムを使用する準備が整いました。

デフォルトの暗号化なしで暗号化されたデバイスを起動する

これは、パスワードが設定されている暗号化されたデバイスを起動すると発生します。デバイスのパスワードは、ピン、パターン、またはパスワードです。

  1. パスワードで暗号化されたデバイスを検出する

フラグが原因でAndroidデバイスが暗号化されていることを検出する ro.crypto.state = "encrypted"

vold/ dataはパスワードで暗号化されているために設定さvold.decrypttrigger_restart_min_frameworkます。

  1. tmpfsをマウントする

init5つのプロパティを設定して、/ dataに指定された初期マウントオプションを、から渡されinit.rcたパラメーターとともに保存します。voldこれらのプロパティを使用して暗号マッピングを設定します。

ro.crypto.fs_type

ro.crypto.fs_real_blkdev

ro.crypto.fs_mnt_point

ro.crypto.fs_options

ro.crypto.fs_flags (0xが前に付くASCII 8桁の16進数)

  1. フレームワークを起動してパスワードの入力を求めます

フレームワークが起動し、それvold.decryptがに設定されていることを確認しtrigger_restart_min_frameworkます。これは、フレームワークにtmpfs /dataディスク上で起動しており、ユーザーパスワードを取得する必要があることを伝えます。

ただし、最初に、ディスクが適切に暗号化されていることを確認する必要があります。コマンドcryptfs cryptocompleteをに送信しvoldます。vold暗号化が正常に完了した場合は0、内部エラーの場合は-1、暗号化が正常に完了しなかった場合は-2を返します。voldこれは、CRYPTO_ENCRYPTION_IN_PROGRESSフラグの暗号メタデータを調べることで決定します。設定されている場合、暗号化プロセスが中断され、デバイスに使用可能なデータがありません。

voldエラーが返された場合、UIはユーザーにデバイスを再起動して工場出荷時の状態にリセットするためのメッセージを表示し、ユーザーにボタンを押してそのようにします。

  1. パスワードでデータを復号化する

一度cryptfs cryptocomplete成功すると、フレームワークは、ディスクのパスワードを要求UIを表示します。UIは、コマンドcryptfs checkpwをに送信してパスワードを確認しますvold。パスワードが正しい場合(これは/data、一時的な場所に復号化されたものを正常にマウントしてからアンマウントすることで決定されます)、voldは復号化されたブロックデバイスの名前をプロパティに保存し、ro.crypto.fs_crypto_blkdevステータス0をUIに返します。パスワードが正しくない場合、UIに-1を返します。

  1. フレームワークを停止

UIは暗号化ブートグラフィックを作成し、コマンドでvoldを呼び出しますcryptfs restartvoldプロパティvold.decrypttrigger_reset_mainに設定init.rcしますclass_reset main。これmainにより、クラス内のすべてのサービスが停止し、tmpfs /dataアンマウントできるようになります。

  1. / dataをマウント

vold次に、復号化された実際の/dataパーティションをマウントし、新しいパーティションを準備します(最初のリリースではサポートされていないワイプオプションで暗号化された場合は準備されなかった可能性があります)。プロパティvold.post_fs_data_doneをに設定して0からに設定vold.decrypttrigger_post_fs_dataます。これによりinit.rc、が実行されますpost-fs-data commands。必要なディレクトリまたはリンクを作成し、に設定vold.post_fs_data_done1ます。一度vold見て1そのプロパティでは、プロパティを設定vold.decryptしますtrigger_restart_framework。これによりinit.rc、クラス内のサービスがmain再び開始されlate_start、起動後初めてクラス内のサービスも開始されます。

  1. 完全なフレームワークを開始する

これで、フレームワークは復号化された/ dataファイルシステムを使用してすべてのサービスを起動し、システムを使用する準備が整いました。

暗号化されたキーの保存

暗号化されたキーは、暗号化メタデータに保存されます。ハードウェアバッキングは、Trusted Execution Environment(TEE)署名機能を使用して実装されます。以前はscrypt、ユーザーのパスワードと保存されたソルトに適用して生成されたキーでマスターキーを暗号化しました。

キーをオフボックス攻撃に対して回復力のあるものにするために、保存されたTEEキーで結果のキーに署名することにより、このアルゴリズムを拡張します。次に、結果として生じる署名は、のもう1つのアプリケーションによって適切な長さのキーに変わりますscrypt。このキーは、マスターキーの暗号化と復号化に使用されます。このキーを保存するには:

  1. ランダムな16バイトのディスク暗号化キー(DEK)と16バイトのソルトを生成します。
  2. scryptユーザーパスワードとソルトに適用して、32バイトの中間キー1(IK1)を生成します。
  3. IK1にゼロバイトを埋め込み、ハードウェアバインドされた秘密キー(HBK)のサイズにします。具体的には、次のように埋め込みます:00 || IK1 || 00..00; 1つのゼロバイト、32 IK1バイト、223ゼロバイト。
  4. 256バイトのIK2を生成するために、IK1にHBKを埋め込みます。
  5. scryptIK2およびソルト(ステップ2と同じソルト)に適用して、32バイトIK3を生成します。
  6. IK3の最初の16バイトをKEKとして使用し、最後の16バイトをIVとして使用します。
  7. AES_CBC、キーKEK、および初期化ベクトルIVでDEKを暗号化します。

Android Nはどうですか?同僚は、デバイスの起動が以前のように保護されておらず、したがって攻撃者が以前よりも簡単にすることができるため、Android 7の暗号化は弱いと仮定していました。これは本当だと思いますか?
デビッド

この質問の範囲外の@Davidについては、Android Nougatについて別の質問をしてください。
タモフナチョードリー


リカバリモードでDATAパーティションを復号化するにはどうすればよいですか?init.recovery。<ro.hardware> .rc経由
ベニー

@ベニーはそれについて適切な質問をしてください
タモフナ・チョードリー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.