セキュリティレビュー

Question

EDIT

私はまだ私は私のモバイル通信デバイスのペアリング時に来たときに私は...私の意図を明確にする

を試してみましたが、この上でいくつかのアドバイスを望んでいますフレームワーク私はこのトピックに関する多くの論文を勉強し、以前の質問からいくつかの情報を得ました。しかし、私はプロトコルのソリューションを実装する準備ができていない - 私は派生物を発明し、私は暗号のオタクではないので、私は最終的な解決策のセキュリティの警告についてはわからない：

主な質問は

• SHA256はコミット機能として十分ですか？
• コミット文字列の安全な認証情報として共有秘密情報を追加しましたか？
• 1024ビットグループの全体的なセキュリティは何ですか？DH
• （24ビットチャレンジのため）成功した​​MITM攻撃の可能性は2^-24ビットと想定します。これは妥当？
（私の痺れオフデバイスをリッピング以外にも、冷たい手）最も有望な攻撃の可能性が何

これが初めてペアリング、で提案された解決策」については、アルゴリズムのスケッチ

• ですピアツーピア無線ネットワークにおける主要合意（DH-SC）が実施されている。
• （コミットメントの前に、プロトコルの開始時に送信される128ビット、）通信エンティティ/役割の修正、「UUID」
  • 、公開DHキー（192ビットの秘密鍵、ベース：私は由来のコミットメントにそれをベース1024年にオークリー基）
• はSHA256
  • C = SHA256（UUID || DHパブを使用して計算されコミット
  • 24ビットランダムチャレンジ|| CHALL）をビット
• 両当事者は、上記コミットメントを交換し、上記の値の平易な内容を開いて転送します。

 
    Alice         Bob 
    ca = commit()       
        -------^ ca 
              cb = commit() 
        cb ^----------- 
    open 
        ---^ DH pub a, chall a 
              open 
        DH pub b, chall b ^--- 

• 24ビットのランダムなユーザが永続するためのオプト場合

• DHセッション鍵を（128バイト、上記参照）

• 計算される手動認証のためにユーザに表示されますセッション鍵は、リモートUUIDを共有秘密として格納されます。

• 次回のデバイス接続、コミットはcompuランダムチャレンジの前に前のDHセッションキーをさらにハッシュすることによって、開封時に確実に移送されません。

  • C = SHA256（UUID || DHパブ|| DHのSES || CHALL）

• 地元の当事者が自分のを使用して同じコミットメントを引き出すことができます今、ユーザーが気にされていない認証 、保存された前のDHセッションキー。接続が成功すると、新しいDHセッションキーが新しい共有秘密になります。これは正確に（および、そのような彼らのセキュリティ証明など）私がこれまでに見つかったプロトコルに適合しないとして

、私はここにいくつかのより多くの暗号化が有効みんなから意見を得るために非常に興味があると思います。 BTW。私は "EKE"プロトコルについて読みましたが、私は余分なセキュリティレベルは何か分かりません。

Answer 1

"SHA256はコミット機能として十分ですか？"

SHA256の使用は問題ありません。私が聞いた唯一の問題は、ハッシュ拡張脆弱性があることです。同じデータを使用して複数のハッシュを作成する場合は、すでにハッシュしたデータの末尾にさらに多くのデータを連結するだけではありません。あなたのポストには2つのハッシュ "sha256（UUID || DHパブ||チャレンジ）と" sha256（UUID || DHパブ|| DHセス||チャレンジ）があります。その2番目が "sha256（UUID || DH pub || Chall || DH sess）"であれば、UUID、DH pub、およびChallが以前と同じ値であれば、ハッシュ値の間に関係があります。ハッシュ拡張の問題を回避するか、リンクを介してsaltを伝達するか、コードパスごとに異なる値を持つかのいずれかで、ハッシュされるデータにソルト値を含めるように注意する必要があります。

メモ：既に以前のセッションキーが保存されていて、チャレンジコードを手動で確認する必要はありません。

"コミット文字列の認証情報として共有秘密情報を追加するのは安全ですか？"

「公開されるハッシュに秘密情報を含めることは安全ですか？」と尋ねることを意味すると思います秘密が本当に推測が難しいもので、ブルートフォース攻撃を実行するのに本当に長い時間がかかる場合、それは安全です。秘密が推測するのが容易であるか、または可能な値がいくつかある場合、潜在的な盗聴者にそのような秘密を同時に推測させなければならない秘密を推測することができなければ、安全ではありません。 DHの共有シークレットのような大きくて効果的な乱数の場合は、ちょうど良いはずです。

私はDHグループ1024は、使用したいものであるかどうかわからないんだけど

「1024ビットグループDHの全体的なセキュリティは何ですか」。あなたが使用しているSHA256ハッシュアルゴリズムと同じくらい有効であると考えられる鍵交換は、521ビットECDHになります。ECDHの暗号強度は1/2と見なされます。したがって、256ビットのセキュリティが必要な場合は、521ビットのECDHが必要です。残念ながら、公開されている多くの個別の521ビットECDHグループのセキュリティについてはわかりません。

"24ビットチャレンジのために、成功したMITM攻撃の可能性は2^-24ビットであると仮定しますが、これは可能ですか？"

MITM攻撃を行う方法は複数あります。 Eveは彼女の処分のためにすべてのリソースを使用して攻撃を行い、慎重でない場合は、あなたが考えなかったものを悪用します。これが、ピアレビューが暗号化に必要な理由です。

Answer 2

あなた自身の暗号化ソリューションを作成すると、単純に弱いです。

小さな話のために、VISAの人は、それが十分に強くなる前に再び4回始める必要があります。

私はセキュリティ専門家ではありませんが、私の暗号教師が毎回教えてくれたのです。

Answer 3

これでも問題はありません。あなたは "修正された[編集] UUID"の意味を理解していませんか？ 不正なアプリケーションがUUIDとセッションキーにアクセスする可能性がありますか？システム全体またはサービスに格納されていますか？ SDKには、鍵を返す前にすべてのキーストアがユーザーの確認を常に待っていることを示すテキストがあります。

Answer 4

私は、この攻撃の可能性を思い付くプロトコルの私の理解に基づいて、Lowe's Attack to Needham-Shroeder Public Key Protocolに触発されました：

• アリスが再接続しようとしています。コミットメントcaを計算し、ボブに送信します。メッセージはMalloryによって捕捉されます。
• Malloryの回答。彼女は共有秘密を知らないので、彼女はそれを発明する。 cbを計算してAliceに送信します。
• このステップでは、Aliceはまだ共有秘密を検証できません。彼女はDHpubAとChallaを送ります。
• MalloryはAliceからのメッセージを無視して消えます。

マロリーには、有効なDHpubA、ChallA、対応する（有効な）ca.があります。

• MalloryはcaをBobに送信します。
• Bobがcbで応答します。
• マロリーはDhpubAの有効なセットを送信し、ChallA
• ボブは、ボブはマロリーのメッセージを検証することができますので、彼女はアリスと認証された彼のDhpubBとChallB

を送信します。明らかにMalloryはDHprivAを知らないが、現在のセッション鍵を計算することはできないが、Bobが彼がAliceと話していると考えるので、セキュリティ上の欠陥がある。

一般的なアドバイス：独自の暗号ソリューションを実装しないでください。確立されたセキュリティ会社以外からのセキュリティレビューは信頼できません。

標準のメインストリーム暗号でセキュリティ要件が満たされていないと思われる場合は、要件を説明し、それらに一致するセキュリティプロコトルがあるかどうかを尋ねてみてください。