web-dev-qa-db-ja.com

公開鍵暗号方式を使用したパスワードベースのチャレンジレスポンス認証方式はありますか?

私は認証について考えていました

  • ユーザーはパスワードを知っているだけです
  • しかし、塩はありません、クライアントがサーバーから取得する他のすべて
  • それでもユーザーのパスワードはサーバー上のデータから取得できません
  • 通信からも、サーバーもパスワードを取得しないことを意味します

私はこのようなものが解決策に近いかもしれないと思いました:

セットアップ:

  1. クライアントはe = hash(password)、p、qの素数、n = p * qを計算します
  2. このハッシュを使用して、RSA復号鍵を計算しますd =(e ^(-1)mod phi(n))
  3. 途中の人を避ける方法でdとnをサーバーに渡します

認証:

  1. サーバーはc = random()チャレンジと保存されたnをクライアントに送信します
  2. クライアントはそれを暗号化し、応答としてr =(c ^(hash(password))mod n)を送信します
  3. サーバーはa =(r ^ d mod n)の解答を復号化し、a == cの場合、ユーザーは認証されています

これに似た実績のある認証方式はありますか?そうでない場合、暗号化指数は従来の65537ではありませんが、実際にはプロトコルの中間キーですが、OAEPのような適切なRSA実装で上記は安全でしょうか?

2
yacrc

あなたが話しているのは、RSA-PAKEに似た ゼロ知識証明 (より具体的には [〜#〜] zkpp [〜#〜] )です。

RSAを安全に実装する一般的な問題を無視すると、提案したスキームにいくつかの問題があります。

  1. 鍵交換を見ている攻撃者はcを知っているので、cの値がh nより小さい場合は、r = ch mod n = ch。これから攻撃者はcを回復しますh、ログを計算できますc(ch)hを回復してオフラインでクラックする。
  2. サーバーは認証されないため、攻撃者はおそらく上記の攻撃や他の攻撃に有利なcの値を選択する可能性があります。
  3. Eはφ(n)に対して比較的素である必要があるため、ハッシュ関数の生の結果を使用してeを選択することはできません。したがって、eが安全な値であることを確認するには、何らかの操作を行う必要があります。この操作によってハッシュの安全性が過度に低下しないことを確認する必要があります。
  4. サーバーmustクライアントから送信された初期設定値を検証します。検証しない場合、不正なキーの生成または操作が原因でスキーム全体が壊れる可能性があります。ゼロ知識を維持しながらこれを行うのは困難です。
  5. E-residue攻撃など、攻撃者がeの値をインタラクティブに選択できるスキームには、いくつかの潜在的な攻撃があります。
  6. これらの操作の一部では、エラーサイドチャネルとタイミングサイドチャネルに注意する必要があります。

おそらく見たいのは [〜#〜] srp [〜#〜] のようなプロトコルで、これらの問題のほとんどを回避しながらZKPP認証を処理します。

2
Polynomial