web-dev-qa-db-ja.com

リプレイ攻撃から保護するためのナンスとしてDiffie-Hellman公開鍵を使用するのは安全ですか？

リプレイ攻撃からの保護に関して興味深い事例があります。アリスとボブがDiffie-Hellman鍵交換を使用して安全な一時セッションを確立したと仮定すると、リプレイ攻撃から保護するために、DH鍵の公開部分をノンスシーダーとしてHMACと組み合わせて使用​​しても安全ですか？擬似コードで-

セッションの確立：

a:
    (dhA, dhSecret) = DH_GEN(common)
    a->b (dhA)

b:
    (dhB, dhSecret) = DH_GEN(common)
    b->a (dhB)

a:
    a<-b (dhB)
    sessionKey = DH_KEY(dhB, dhSecret)

b:
    b<-a (dhA)
    sessionKey = DH_KEY(dhA, dhSecret)

アリスがボブにデータを送信したい場合：

a:
    data = ENCRYPT(sessionKey, data)
    dhA++
    hmac = HMAC(sessionKey, data | dhA)
    a->b (data, hmac)

そして、ボブの側では、プロセスが逆になります。

b:
    b<-a (data, hmac)
    if (hmac == HMAC(sessionKey, data | dhA+1)) {
        dhA++
        data = DECRYPT(sessionKey, data)
    }

同じことが反対方向にも起こります。

b:
    data = ENCRYPT(sessionKey, data)
    dhB++
    hmac = HMAC(sessionKey, data | dhB)
    b->a (data, hmac)

a:
    a<-b (data, hmac)
    if (hmac == HMAC(sessionKey, data | dhB+1)) {
        dhB++
        data = DECRYPT(sessionKey, data)
    }

そして2番目の質問-最初のナンスにかなり大きなDH公開鍵を使用する代わりに、固定数（たとえば0）から始まる自己インクリメントナンスを使用する方が簡単で安全ですか？

何らかの形式の認証済みDiffie-HellmanKEを使用して阻止できるセッション確立中のMITM攻撃の可能性を除いて、そのようなアプローチの危険性（ある場合）は何ですか（たとえば、交換中に信頼できる証明書によって生成された公開鍵に署名する） ？

ありがとう

diffie-hellmansession-managementnoncereplay-detection
1
BeagleEagle

ナンスは「一度使用した数」です。

これは、「毎回同じ値をノンスに使用する必要があるか」という質問です。答えはノーです。

予測できない数字から始めます。良いランダムソースから。

編集2：あなたは自分で答えを出しました。ナンスは秘密にしておく必要はありません。ただし、DH共有キーはである必要があります。ナンスのキーを使用する場合は、ナンスを秘密にしておく必要があります...

編集：ここにあるのは、「ドレメルの研磨ビットで歯をきれいにするのは安全ですか」と誰も尋ねたことがないのと同じように、誰も質問を考えたことがないということだと思います。質問について考えるのに時間を費やすのは時間の無駄です。

  • 歯をきれいにするには、歯ブラシを使用します。
  • ナンスの場合は、適切なランダムソースを使用します。

その後、次の仕事に取り掛かります。

または、少し卑劣なものにするために、番号が1回だけ使用されるようにする必要があります。優れたランダムソースは、統計的にそれを達成します。使用例：リモートIPがそれを物理的に達成する時間。どちらも秘密にしておかなければならない情報を使用していません。

1
Ben

2番目の質問に対して-0から始まる自己増分ナンスを使用します（たとえば）、ナンスは理想的には推測するのが難しいことではありませんか？直線的に増加するナンスは、本質的に予測可能です。

0
katrix