1

編集

私はまだこれについてのアドバイスを望んでいます、私は自分の意図を明確にしようとしました...

モバイル通信フレームワークでデバイスのペアリングに出会ったとき、このトピックに関する多くの論文を研究し、ここで以前の質問からいくつかの情報を得ました. しかし、私はプロトコルソリューションを実装する準備ができていなかったので、派生物を発明しました.私は暗号オタクではないので、最終的なソリューションのセキュリティ警告については確信が持てません:

主な質問は

  • コミット機能はSHA256で十分？
  • コミット文字列に認証情報として共有シークレットを追加することは安全ですか?
  • 1024 ビット グループ DH の全体的なセキュリティとは
  • MITM 攻撃が成功する可能性は最大でも 2^-24 ビットであると想定しています (24 ビット チャレンジのため)。これはもっともらしいですか？
  • 最も有望な攻撃は何ですか (私の麻痺した冷たい手からデバイスを引き裂く以外に)

これはアルゴリズムのスケッチです

  • 初めてのペアリングでは、「ピア ツー ピア ワイヤレス ネットワークにおける鍵合意」(DH-SC) で提案されているソリューションが実装されます。私はそれを、以下から派生したコミットメントに基づいています。
    • 通信エンティティ/ロールの修正「UUID」 (128 ビット、プロトコル開始時、コミット前に送信)
    • 公開 DH キー (1024 ビットの Oakley グループに基づく 192 ビットの秘密キー)
    • 24 ビットのランダム チャレンジ
  • コミットは SHA256 を使用して計算されます
    • c = sha256( UUID || DHパブ || チャル)
  • 両当事者はこのコミットメントを交換し、上記の値のプレーンなコンテンツを開いて転送します。
    アリス・ボブ
    ca = コミット()                        
                    -------^ 年
                                            cb = コミット()
                    cb ^-----------
    開いた
                    ---^ DH pub a, chall a
                                            開いた
                    DH パブ b、チャル b ^---
  • 手動認証用に 24 ビットのランダムがユーザーに表示されます。

  • DH セッション キー (128 バイト、上記を参照) が計算されます

  • ユーザーが永続的なペアリングを選択すると、セッション キーはリモート UUID と共に共有シークレットとして保存されます。

  • 次にデバイスが接続すると、ランダム チャレンジの前に以前の DH セッション キーを追加でハッシュすることによってコミットが計算されます。開いたときに転送されないことを確認してください。

    • c = sha256(UUID || DH pub || DH sess || Chall)

  • これで、ユーザーは、ローカル パーティが自分自身の保存済みの以前の DH セッション キーを使用して同じコミットメントを取得できる場合、認証に煩わされることはありません。接続が成功すると、新しい DH セッション キーが新しい共有シークレットになります。

これは私がこれまでに見つけたプロトコル (およびそのようなセキュリティ証明) に正確には適合しないため、ここで暗号化を有効にした人から意見を得ることに非常に興味があります. ところで。「EKE」プロトコルについて読みましたが、追加のセキュリティ レベルがどのようなものかわかりません。

4

4 に答える 4

2

「コミット機能はSHA256で十分？」

SHA256 の使用は問題ないはずです。私が聞いた唯一の問題は、ハッシュ拡張の脆弱性があるということです。同じデータを使用して複数のハッシュを生成する場合は、既にハッシュしたデータの末尾にさらにデータを単純に連結しないでください。あなたの投稿には、「sha256( UUID || DH pub || Chall)」と「sha256( UUID || DH pub || DH sess || Chall)」という 2 つのハッシュがあります。2 番目の値が「sha256( UUID || DH pub || Chall || DH sess)」の場合、UUID、DH pub、および Chall がすべて以前と同じ値であれば、ハッシュ値間に関係があります。ハッシュ拡張の問題を回避するように注意するか、リンクを介してソルトを通信するか、コードパスごとに異なる値を使用して、ハッシュするデータにソルト値を含める必要があります。

余談ですが、以前のセッション キーが既に保存されていて、ユーザーにチャレンジ コードを手動で確認するよう求める必要がない場合、Chall を送信する必要は本当にあるのでしょうか?

「コミット文字列の認証情報として共有シークレットを追加することは安全ですか?」

「公開するハッシュに機密情報を含めても安全ですか？」という質問だと思います。秘密が推測するのが非常に難しく、ブルートフォース攻撃を実行するのに非常に長い時間がかかるものである場合、はい、それは安全です. 秘密が推測しやすいものであるか、可能な値がわずかしかない場合は、いいえ、推測しにくい秘密を同時に含めて、潜在的な盗聴者にそのようなすべての秘密を同時に推測させなければならない場合を除き、安全ではありません。DH 共有シークレットのような大きくて効果的な乱数の場合は、問題ありません。

「1024 ビット グループ DH の全体的なセキュリティとは」

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

「MITM攻撃が成功する可能性は最大でも2^-24ビットだと思います(24ビットチャレンジのため)。これはもっともらしいですか?」

MITM 攻撃を実行する方法は複数あります。Eve はあらゆるリソースを使用して攻撃を実行します。注意しないと、思いもよらないことを悪用します。これが、暗号にピアレビューが必要な理由です。

于 2011-01-02T06:15:51.197 に答える
2

簡単に言えば、独自の暗号化ソリューションを作成した場合、それは脆弱です。

ちょっとした話ですが、VISA の連中は十分に強くなるまでに 4 回やり直さなければなりません。

私はセキュリティの専門家ではありませんが、私の仮想通貨の先生がいつも言っていたことです。

于 2010-12-29T09:42:06.753 に答える
1

Lowe の Attack to Needham-Shroeder Public Key Protocolに触発された、プロトコルの理解に基づいて、この可能な攻撃を考え出しました。

  • アリスは再接続を望んでいます。そのコミットメント ca を計算し、Bob に送信します。メッセージはマロリーによってキャプチャされます。
  • マロリーは答える。彼女は共有秘密を知らないので、それを発明します。cb を計算し、Alice に送信します。
  • このステップでは、Alice はまだ共有シークレットを確認できません。そこで彼女は DHpubA と ChallA を送ります。
  • マロリーはアリスからのメッセージを無視して姿を消す。

これで、マロリーは有効な DHpubA、ChallA、および対応する (有効な) ca を取得しました。

  • マロリーは ca をボブに送信します。
  • ボブは cb で答えます。
  • Mallory は、DhpubA、ChallA の有効なセットを送信します。
  • Bob は自分の DhpubB と ChallB を送信します

Bob は Mallory のメッセージを検証できるため、Alice として認証されます。明らかに、マロリーは DHprivA を知りません。彼女は現在のセッション キーを計算できませんが、ボブは自分がアリスと話していると考えているため、セキュリティ上の欠陥があります。

一般的なアドバイス: 独自の暗号化ソリューションを実装することは避け、確立されたセキュリティ会社以外からのセキュリティ レビューは信頼しないでください。

標準の主流の暗号ではセキュリティ要件が満たされていないと思われる場合は、要件を述べて、それらに一致するセキュリティプロトコルがあるかどうかを尋ねてみてください.

于 2011-01-02T11:03:53.173 に答える
0

大丈夫ですね。「fix[ed]UUID」の意味がわかりませんか？不正なアプリがUUIDとセッションキーにアクセスできますか？それらはシステム全体に保存されていますか、それともサービスに保存されていますか？SDKには、キーストアがキーを返す前に常にユーザーの確認を待つことを示唆するテキストがあります。

于 2010-12-29T09:56:20.580 に答える