スピーク

SPEKE ( Simple Password Exponential Key Exchange ) は、パスワード認証による鍵共有のための暗号化方式です。

このプロトコルは、Diffie-Hellman 鍵交換とほぼ同じもので、Diffie-Hellman ジェネレータgはパスワードのハッシュから作成されます。

SPEKE の簡単な形式を次に示します。

1. アリスとボブは、適切な大きさでランダムに選択された安全な素数 pとハッシュ関数H () を使用することに同意します。
2. アリスとボブは共有パスワードπに同意します。
3. アリスとボブは両方ともg = H ( π ) ² mod pを構築します。(平方すると、g はpを法とする整数の乗法群の素数位数部分群の生成元になります。)
4. アリスは秘密のランダムな整数a を選択し、ボブにg ^a mod p を送信します。
5. ボブは秘密のランダムな整数b を選択し、アリスにg ^b mod p を送信します。
6. アリスとボブは、受信した値が[2, p -2]の範囲外の場合、小サブグループ閉じ込め攻撃を防ぐためにそれぞれ中止します。
7. アリスはK = ( g ^b mod p ) ^a mod pを計算します。
8. ボブはK = ( g ^a mod p ) ^b mod pを計算します。

アリスとボブは、 πに同じ値を使用した場合にのみ、Kに同じ値に到達します。アリスとボブが共有秘密K を計算すると、それをキー確認プロトコルで使用して、同じパスワード π を知っていることを互いに証明し、安全で認証されたメッセージを互いに送信するための共有秘密暗号化キーを導出できます。キー確認プロトコルの使用は、IEEE P1363.2 および ISO/IEC 11770-4 標準で指定されているように、オプションです。

認証されていない Diffie-Hellman とは異なり、SPEKE はパスワードを組み込むことで中間者攻撃を防止します。Alice と Bob 間のすべてのメッセージを読み取って変更できる攻撃者は、共有キーK を知ることができず、パスワードを知っている相手とのやり取りごとにパスワードを複数回推測することはできません。

一般に、SPEKE は、楕円曲線暗号を含む公開鍵暗号に適した任意の素数位数群を使用できます。ただし、楕円曲線暗号を使用して SPEKE を実現する場合、指定された楕円曲線上のランダムな点にパスワードを安全にマッピングする必要がある追加のプリミティブが必要になるため、プロトコルは本質的に変更されます。(このプリミティブは、IEEE P1363.2 および ISO/IEC 11770-4 では IOP または Integer-to-Point 関数と呼ばれます。)

SPEKE は、比較的新しいパスワード認証鍵交換の分野における、古くからあるよく知られたプロトコルの 1 つです。これは、1996 年に David Jablon によって初めて説明されました。^[1]この論文で、Jablon は、プロトコルのステップ 2 で、定数g _qを使ってg = g _q ^Sとしてgが計算される変形も提案しました。しかし、この構成は辞書攻撃に対して安全でないことが判明したため、論文の改訂版では推奨されなくなりました。1997 年に Jablon は、B-SPEKE と呼ばれる拡張パスワード認証鍵共有方法を含む追加の変形で SPEKE を改良および拡張しました。^[2] 2001 年に MacKenzie によって発表された論文では、ランダム オラクル モデルで、Decision Diffie-Hellman 仮定のバリエーションに基づいて、SPEKE が安全な PAKE プロトコル (多少緩い定義を使用) であることを証明しています。^[3]しかし、この証明ではSPEKEの鍵確認関数を必須として扱っているが、これはIEEE P1363.2およびISO/IEC 11770-4規格でSPEKEが規定されている方法ではない。

1999 年以来、このプロトコルはさまざまな企業によってさまざまな製品に使用されており、通常は他の暗号化技術を補完するものとして使用されています。

2014 年には、1996 年の Jablon のオリジナル論文と IEEE P1363.2 (D26) および ISO/IEC 11770-4 (2006) 標準で指定されている SPEKE プロトコルに対して 2 つの攻撃が特定されました。^[4]最初の攻撃では、アクティブな攻撃者が被害者と 2 つの並行セッションを開始することにより、パスワードを知らなくてもユーザーになりすますことができます。2 番目の攻撃では、中間者攻撃者が 2 人の正直なユーザー間のセッション キーを、検出されることなく操作することができます。最初の攻撃はプロトコルの実際的な弱点を示していますが、2 番目の攻撃は SPEKE のセキュリティ証明に理論的な影響を及ぼします。2014 年 10 月にメキシコ シティで開催された ISO/IEC JTC 1/SC 27 会議では、2 つの攻撃が ISO/IEC SC 27/Work Group 2 の技術委員会で議論され、特定された問題に対処するために ISO/IEC 11770-4 (2006) の SPEKE 仕様を改訂することが合意されました。提案されたパッチには、セッションIDを明示的に定義し、プロトコルの対称性を変更しない方法でそれらのIDをキー導出関数に含めることが含まれます。パッチを当てたSPEKEはISO/IEC 11770-4（2017）で公開されています。^[5]ただし、IEEE P1363.2のSPEKE仕様はパッチを当てられていません。

米国特許 6,226,383 では、この方法のいくつかのバリエーションについて説明しています。この特許は 2017 年 3 月に失効しました。

SPEKE を規定する標準規格には、 IEEE P1363.2および ISO/IEC 11770-4 がある。最新の ISO/IEC 11770-4 (2017) 標準規格では、SPEKE 仕様が以前の ISO/IEC 11770-4 (2006) から改訂され、2014 年に Hao と Shahandashti によって報告された 2 つの攻撃に対処している。^[4]

• パスワードベースの暗号化に関するリンク
• IETF - SPEKE メソッド (進行中)