web-dev-qa-db-ja.com

Apple cryptochip in Androidデバイスに相当するものはありますか？

Appleには cryptochip があります。これは、暗号化キーの管理に加えて、認証をトンネリングし、失敗した試行のスロットリングを提供します。これにより、4桁のPINを使用して妥当なセキュリティを確保できます。

Androidベースのデバイスにこのようなハードウェアメカニズムが存在することに関する情報は見つかりませんでした。最も近いのは [〜＃〜] tee [〜＃〜] （Trusted Execution Environment）です。

TEEは、スマートフォン（または接続されたデバイス）のメインプロセッサの安全な領域です。隔離された信頼できる環境で機密データが保存、処理、保護されるようにします

私の理解では、これは本質的に [〜＃〜] tpm [〜＃〜] の実装であり、暗号化キーのみを保護し、特に認証自体は処理しません。

その場合、どのようにAndroidオフライン攻撃中に失敗した認証試行のスロットリングがバイパスされないようにしますか？

具体的には：

  • デバイスから抽出されたベアディスクの復号化は不可能です（TEEによって生成されたキーは堅牢です）
  • tEEの助けを借りてデバイス内のディスクを復号化することは、スロットリングまたは指定された回数の試行後のワイプによって保護する必要があります。

後者の実装の説明は私が探しているものです。

注：セキュリティ設定を回避するのに役立つセキュリティバグがあることを知っています。これはあらゆる場所ですべてのデバイスで発生し、うまくいけばパッチで修正されます。これは私の質問の主題ではありません-私は特に、安全ではないように見える認証メカニズム（これらのシステムがない場合は4桁のPINがその例です）から保護するために設計されたハードウェアメカニズムに特に興味があります。

編集：また、TEE自体について この回答 も参照してください（上記の質問の補足として）

encryptionandroidbrute-forcepassword-cracking
7
WoJ

Androidオフラインの攻撃中に失敗した認証試行のスロットリングが回避されないことをどのように保証しますか？

Android KeyStoresは、Android Nの前にハードウェアまたはソフトウェアベースである可能性があります。これにより、ハードウェアKeyStore a[〜＃ 〜] CTSでは必須[〜＃〜]。

[〜＃〜] edit [〜＃〜]：以下では用語を使用していますオンライン攻撃、プロパティを持つものとして

オンラインエンティティは、追加のセキュリティチェックを実行して、プロトコルをより安全にすることができます。たとえば、オンラインエンティティはログイン試行の数と速度を調整できます（ another SO q から））

...リモートネットワーク経由で行われるのではありません。多分私はそれを一般的な方法で使用していませんが、私にとってonline攻撃に関する興味深い特性は、攻撃者とデータの間に層があるということです攻撃者の制御下にない攻撃。この層がリモートWebサーバーであるか、一部のローカルハードウェアであるかは、物理的なチップが攻撃/検査されない限り、どちらもレート制限を実行できるため、この場合大きな違いはありません。

この SO回答 は、実際には私が使用しているものに近い定義を持っています

オンライン攻撃は、合法的なシステムに入力を提供する自動化ルーチンを試みます。彼らは、機能のエクスプロイトを作成しようとするのではなく、期待される機能を悪用しようとしています。

オフライン攻撃は、暗号化/ハッシュをエミュレートしようとし、そのプロセスの既知の出力を必要とします（つまり、システムを攻撃せず、すでにハッシュ/暗号化されたパスワードを持っています）

ハードウェアベースの場合、高度な物理的攻撃なしにKeyStoreから秘密鍵を抽出できる必要があります（電子顕微鏡またはTEE/TPMによって公開されたブラックボックスの脆弱性の可能性があります。これはonline攻撃。TEE/ TPMがスロットルを実装することを望みます。

[〜＃〜] edit [〜＃〜]：Iネクサス6p KeyStore implをテストしたところ、一般的なCipher操作でスロットルが行われませんでした（パディングOracleがRSAに公開されているかどうかを確認していました）。ただし、メインのロック解除のKeyStoreレート制限はテストしていません。

ソフトウェアベースの場合、rootを使用すると、KeyStore blobが持ち上げられ、ブルートフォースされる可能性があります。これはoffline攻撃であり、スロットリングは実行できません。

あなたの質問に答えて、それはその性質上、オフライン攻撃の抑制を確実にすることはできません。

4
Dori

私が知っている最も近いものは Googleのプロジェクトボールト です。これは、ロックダウンされたSDカード内にセカンダリCPUがあり、すべての機密プロセスとキー処理を実行するシステムです。 Googleは、システムをandroids APIにクックして、SDカードリーダーを備えたすべてのAndroidデバイスがチップを使用できるようにしたいと考えています。

彼らが同じことをしていると主張しているいくつかの会社がありますが、研究者がそれらのシステムにまだ欠陥を見つけているので、これはAndroidこれまでのところ強力なセキュリティを提供するための最も有望な手段のようです。

1
codykochmann