暗号化にPINコードを使用するのは合理的に安全ですか？

19

Android 4.0（Samsung Galaxy Nexus）には、電話を暗号化する可能性があります。Android 3.0の暗号化についてこれを見つけましたが、Android 4で使用されているアルゴリズムと同じですか？http://source.android.com/tech/encryption/android_crypto_implementation.html

私の主な質問は、PINコードを使用して電話を解読することです。 画面のロック解除と携帯電話の復号化に同じパスワードを使用することを強制されるのはなぜですか？ この制限では、単純な電話でロックを解除するために17文字を入力するのが難しいため、複雑性の低いパスワード（PIN番号など）のみを使用できます。

画面のロック解除に対するブルートフォース攻撃は、5回の試行ごとに強制的に再起動することで防止できます。そのため、非常に強力なパスワードは必要ありません。PINで十分です。
このタイプの保護はディスクでは使用できないため、より強力なパスワードが必要になります。（複雑なパスワードを持つユーザーは非常に少ないため、パスワードのエントロピーが増加してもあまり役に立ちません。したがって、攻撃者は単純にほとんどのパスワードを複雑さの低いもので試すことができます）。両方の機能に同じパスワードを使用せざるを得ない理由は何ですか？

security  encryption 
— クリストファー・ケック
ソース
3
はい。ただし、パスワードを使用する場合、単に画面のロックを解除するためにそれを使用する必要があります。すばやく電話をかけるために17文字を入力するのはあまり便利ではありません。したがって、ほとんどのユーザーはPIN番号を支払う必要があり、それが攻撃者が最初に試みることです。より良い方法は、おそらくディスク暗号化のパスフレーズを許可し、ロック画面で簡単なPIN番号を許可することです。ロック画面でのブルートフォース攻撃を回避するために、3回の試行が失敗した後に強制的に再起動すると、パスワードが要求されます。
— クリストファー・ケック
1
残念ながら、Google以外の誰かがあなたにその理由を伝えることができるとは知りません。おそらく、Androidバグトラッカーを使用して機能リクエストを提出できます。これはそこに提出するのが賢明なことのように思えます。
— eldarerathis
2
はい、ロック解除画面でのログイン試行に対しては可能ですが、ハードドライブの復号化に対してはそうではありません。それが私が言いたいことです、画面のロック解除はハードドライブ暗号化（4つの数字よりもはるかに長い必要がある）ほど長くする必要はなく、したがって両方に同じものを使用することを強制されるべきではありません
— クリストファー・ケック
1
+1、私は完全にあなたと一緒です@ChristopherKäckその決定は意味がありません、グーグルのエンジニアはもっとよく知っているべきでした、彼らはすぐにそれを修正することを望みます。
— ジョアンポルテラ
1
@Christopher：しかし、誤った前提に基づいて決定を下しているので、ディスク上の暗号化は4桁のPINではなく128ビットのAESでした。このスキームが安全であるか、本質的に欠陥があるかを判断することは、Android.SEの専門知識ではありません。
— ライライアン

回答:

4

私は解決策を見つけたと思います。このリンクを確認してください。これはハッキングであり、電話をルート化する必要がありますが、暗号化には英数字のパスワードを、画面ロック解除にはPINを使用できます。

— Oscar_6
ソース
1

パスワード/フレーズと4桁のピンを使用することで、デバイスのセキュリティを強化できます。その秘trickは、4文字のパスワードを持っている場合でも、次の2つの理由でセキュリティを強化したことです。

  • 利用可能なキャラクターを増やしました。
  • あなたは攻撃者のあなたのpwの長さの知識を奪い去った。

パスワードが14文字であることを攻撃者が知っている場合、4文字または8文字のパスワードよりも安全ですが、一般的な統計情報は範囲（1-4、1-8、1-14）を使用し、現実（単純に計算される）ではありません1つの長さの利用可能な組み合わせ）。

現在のところ、単にあるWAY TO EASYお使いの携帯電話のデータにアクセスします。あなたの祖母はそうする能力を持っています（あなたやあなたの家族への違反はありません：P）。この暗号化の限界があることをあなたがしている権利ながらだから、「壊れた」バージョンは、作品A LOTをより良い現在実施非暗号化データより。

データの機密性と機密性、およびそのようなデータが盗まれる対象の量を判断するのはあなた次第です。これらのリスクを評価したら、適切なパスワードを選択するのはあなたの責任です。

— earthmeLon
ソース
2
はい、しかし、画面のロック解除とデバイスの暗号化解除に異なるパスワードを使用することは、問題の簡単な解決策になると思います（ここでandroid.stackexchange.com/questions/17086/…で使用されているため）シナリオと異なる属性を持つ必要があります。
— クリストファー・ケック
1

電源がオフのデバイス、またはメモリチップのみがあるシナリオで、デバイスの残りの部分から独立してディスク暗号化を解読しようとしている場合、これは電源がオンの場合とは異なる攻撃ベクトルです復号化キーがメモリに保持されるパスワード保護デバイス（TPMタイプモジュールではなく、古いFDE暗号化ソフトウェアを使用するPCで一般的なFirewire暗号化キースティーラーなどが使用する脆弱性につながる）またはロック解除画面強制（または独自の脆弱性を持っている）。

ディスクを直接攻撃している場合、この場合、デバイスを暗号化している4桁のPINまたはユーザーパスワードを攻撃していません。攻撃しているのは128ビットAESキーです。

マスターキーは、/ dev / urandomから読み取って作成された128ビットの数値です。SSLライブラリのPBKDF2関数で作成されたユーザーパスワードのハッシュで暗号化されます。フッターには、PBKDF2からのハッシュにエントロピーを追加し、パスワードに対するレインボーテーブル攻撃を防ぐために使用されるランダムソルト（/ dev / urandomからも読み取られます）も含まれています。

リンクしたAndroid 3.0での暗号化の実装に関する注意事項の「デバイスでの暗号化の有効化」の下のポイント4 から。

（コメントになる予定だったが、結局は長すぎる）

— GAThrawn
ソース
1
この素敵なコメントをありがとう！ただし、一つだけ。128ビットを復号化するためのユーザーパスワード（おそらく4桁のピンであるため、画面のロック解除でキーを共有しなければならず、他のものは入力するのが面倒になるため）を探していませんか？ AESキー？（キーを直接検索する代わりに）。PBKDF2関数+ saltを使用してすべての10000ピンをハッシュすると、10000の復号化試行だけで試行できませんか？
— クリストファー・ケック
@Melpomene彼らが言う「レインボーテーブル攻撃」は、10,000個すべての組み合わせを事前に暗号化して、それらが暗号化されているように見えるかどうかを確認し、ディスク上の内容とレインボーテーブル内の内容を比較するだけです。「ランダムソルト」は、推測する必要がある10,000を超える組み合わせを作成することにより、これを防ぐために使用されるものです（最初に「塩」をうまく処理できない場合）。
— GAThrawn
1
レインボーは、暗号化されたパスワードを保存する賢い方法です。また、ソルトを使用する場合は、そのソルトでパスワードをクラックするためだけに特別に構築する必要があります。選択できるパスワードが10,000個しかない場合、これはそれほど難しい操作ではありません。ソルトは常に攻撃者に知られていると見なされることに注意してください（ドキュメントの/ dev / urandomから読み取られるように見えるので、これはクリアテキストで保存されるか、ユーザーパスワードで暗号化されます）。いずれにせよ、ユーザーパスワードは弱いリンクです。
— クリストファー・ケック
しかし、10,000個のハッシュを保存（または計算）することは私のメモリ（プロセッサ）でそれほど難しくないので、レインボーテーブルを構築する必要さえありません。
— クリストファー・ケック
PBKDF2のようなキー派生関数を使用することは良いニュースのように思えますが、一般的な4桁のピンはまだ10000通りの組み合わせにすぎません。
— ジョアンポルテ
0

リモートワイプを有効にしている場合（暗号化されたデバイスで引き続き機能すると仮定）、PINはデバイスを永久に保護しない可能性がありますが、デバイスをワイプする時間を確保するのに十分な時間がかかる場合があります。

— チャンス
ソース
2
問題は、短いPINは、デバイスがオンの場合にのみデバイスを保護できることです。したがって、盗まれたデバイスのスイッチをオフにすると、デバイスがワイプされるのを防ぎ、さらにオフラインのブルートフォース攻撃でPINが破られる可能性があります。したがって、このような状況では短いPINを使用しても役に立ちません。
— ロバート
@Robert、リモートワイプの仕組みについてはあまり詳しくありません。Exchange経由で行う場合、リモートワイプコマンドが発行されるのと同じタイミングで電話をオンにする必要がありますか？私の考えでは、電話を紛失して30分ほどでリモートワイプを発行できれば十分ですが、財務データはありませんが、主な懸念はGMailの仕事用メールです。
— チャンス
2
リモートワイプコマンドを発行した後、しばらくして電話をオンにしてオンラインにする必要があります。電話機の電源がオフになっている（オフのままになっている）場合、ワイプコマンドは役に立ちません。
— ロバート
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.