web-dev-qa-db-ja.com

SamyKamkarのAnti-MITMADiffie-Hellman鍵交換技術はどの程度安全ですか？

私は現在、Diffie-Hellmanを使用して、任意のリンク（イーサネット、Wi-Fi、USB、Bluetoothなど）を介して送信されるデータを暗号化していますが、DHがアクティブに対して脆弱である可能性については大ファンではありません。 MITMA。

私は Samy KamkarのAnti-MITMAテクニック に出くわしました。これがどれほど安全かについて誰かが考えたことはありますか？

私の理解では、上記の手法では、パスワードを取得し、共有シークレットをソルトとして使用し、それらを一緒にハッシュして、ハッシュをエンドホストに送信します。エンドホストがパスワードを知らない場合、特定の関数でハッシュするのは法外に費用がかかり、したがって十分に短い時間でブルートフォースするのに費用がかかると仮定すると、ハッシュを元に戻すことはできません。

または、少なくとも、生成されたハッシュを共有シークレットとして使用できるため、ハッシュを送信する手間が省けると思います。

diffie-hellman
2
Sal

簡単に見ると、これはネットワーク攻撃者に対してかなり安全です。ただし、サーバーはパスワードをプレーンテキストとして保存する必要があるため、お勧めしません。このサイトでは、安全なパスワードの保存が行われています 詳細に説明されています 。

やや似たプロトコルは [〜＃〜] srp [〜＃〜] で、サーバーにプレーンテキストのパスワードを保存せずにSamyKamkarと同じ目標を達成します。副次的な利点として、ログインに必要なラウンドトリップが1つ少なくなるため、実際にはわずかに高速になります。

より一般的な点として、SRPプロトコルは詳細な分析の対象となっており、安全であると考えられています。サミーのプロトコルは（私が知る限り）同じ厳密さにさらされていないので、微妙な問題があるかもしれません。 独自の暗号をロールする をしないようにSRPを使用する必要があります。

Update-もう1つの考慮事項は、Samyのプロトコルが、アクティブなMITM攻撃者にパスワードハッシュを公開し、それをブルートフォース攻撃する可能性があることです。これは非常に悪い弱点であり、SRPは脆弱ではありません。

3
paj28

直接的な答えではありませんが、コメントセクションが限られているため...

私は盲目かもしれませんが（眠れない夜はあなたのためにそれをすることができます）、その文書はあなたがDiffie-Hellman鍵交換を望まないか必要としない状況を説明しています。実際、それは全体のセキュリティに何も追加しません。

双方がすでに共有シークレット（この場合はpassword）を持っていて、そのシークレットが悪意のある敵（この場合はマロリー）に知られていない場合、そもそもなぜそのすべての問題を経験するのでしょうか。 ？結局のところ、DHKE *を使用しないことをすでに行っている場合、DHKEは安全でないチャネルを介して秘密を共有するために使用されます。その秘密から対称鍵を簡単に導き出すことができ、前述のpasswordを入手しない限り、誰もあなたをMITMできないと確信できます。擬似コードでは、簡単な例：

a:
    password = 54321
    kdfParams = [salt, iterations, other] // depends on the KDF, some or all may be random
    secretKey = KDF(password, kdfParams)
    data = ENCRYPT(secretKey, "Hello, Bob!")
    a->b (data, kdfParams)

m:
    b->m<-a (data, kdfParams)
    // Doesn't know the password and have no use for the publically transmitted kdfParams
    // Can derive the secretKey only through brute-force,
    // so choose your KDF and password carefully

b:
    b<-a (data, kdfParams)
    password = 54321
    secretKey = KDF(password, kdfParams)
    data = DECRYPT(secretKey, data) // << "Hello, Bob!"

逆にも機能します。

もちろん、マロリーがどういうわけかpasswordを見つけた場合、地獄全体が解き放たれますが、参照されているドキュメントもそれを助けません。前方および後方の機密性が心配な場合は、secretKeyを使用してDHKEの公開部分をHMACし、MITM攻撃を阻止し、毎回暗号化用の新しいsessionKeyを用意できます。

結論として、説明された「方法」はまったく説明ではなく、著者はDHKEが何に使用されているのか理解していないか、私は少し眠る必要があります。

*この特定の例では、CodesInChaosは、DHKEの一般的な有用性について有効なポイントを示しています。

1
BeagleEagle