セキュアリモートパスワードプロトコル(SRP )は、既存の特許を回避するために特別に設計された、拡張パスワード認証鍵交換(PAKE)プロトコルです。 [1]
すべての PAKE プロトコルと同様に、盗聴者や中間者は、推測ごとに当事者とのやり取りを行わずに、パスワードを総当たりで推測したり辞書攻撃を適用したりするのに十分な情報を取得できません。さらに、拡張された PAKE プロトコルであるため、サーバーはパスワードに相当するデータを保存しません。 [2]つまり、サーバーのデータを盗んだ攻撃者は、最初にパスワードの総当たり検索を実行しない限り、クライアントになりすますことはできません。
簡単に言えば、SRP (またはその他の PAKE プロトコル) 認証では、一方の当事者 (「クライアント」または「ユーザー」) がもう一方の当事者 (「サーバー」) に対して、パスワード自体やパスワードを導出できるその他の情報を送信せずに、パスワードを知っていることを証明します。パスワードはクライアントから外部に漏れることはなく、サーバーには知られません。
さらに、安全な接続を確立するために、サーバーはパスワードも知る必要があります (パスワード自体を知る必要はありません)。つまり、サーバーはクライアントに対して自身を認証し、ユーザーが複雑な URL を解析しなくても フィッシングを防止します。
SRPの唯一の数学的に証明されたセキュリティ特性は、受動的な攻撃者に対してはDiffie-Hellmanと同等であるということである。[3] AuCPace [4]やOPAQUEなどの新しいPAKEはより強力な保証を提供する。[5]
概要
SRP プロトコルには、ユーザーがサーバーに対して自分自身を認証できること、盗聴者による辞書攻撃に耐性があること、信頼できる第三者を必要としないことなど、多くの望ましい特性があります。ユーザーからサーバーにゼロ知識パスワード証明を効果的に伝達します。プロトコルのリビジョン 6 では、接続試行ごとに推測できるパスワードは 1 つだけです。プロトコルの興味深い特性の 1 つは、使用する暗号化プリミティブの 1 つまたは 2 つが攻撃されても、依然として安全であることです。SRP プロトコルは数回改訂されており、現在はリビジョン 6a です。
SRP プロトコルは、クライアント側がユーザー パスワードを持ち、サーバー側がパスワードから導出された暗号化検証子を持つことに基づいて、 Diffie-Hellman 鍵交換に似た方法で、2 つの当事者間で共有される大きな秘密鍵を作成します。共有公開鍵は、ログイン試行に固有の 2 つの乱数 (1 つはクライアントによって生成され、もう 1 つはサーバーによって生成されます) から導出されます。暗号化された通信と認証が必要な場合、SRP プロトコルは代替のSSHプロトコルよりも安全で、署名されたメッセージでDiffie-Hellman 鍵交換を使用するよりも高速です。また、 Kerberosとは異なり、第三者に依存しません。
SRPプロトコルバージョン3は、RFC 2945で説明されています。SRPバージョン6aは、SSL/TLS [6] ( TLS-SRP )やEAP [7]、SAMLなどの他の標準での強力なパスワード認証にも使用され、IEEE 1363.2およびISO/IEC 11770-4の一部です。
プロトコル
プロトコル バージョン 6 のこの説明では、次の表記法が使用されます。
- qとN = 2 q + 1 は、両方とも素数となるように選択されます(qはソフィー・ジェルマン素数、N は安全素数になります)。Nは、 N を法とする離散対数の計算が実行不可能になるほど十分に大きくなければなりません。
- すべての算術はNを法とする整数の環で実行されます。つまり、以下のg xはg x mod Nと読み替えてください。
- g は乗法群の生成元です。
- H () はハッシュ関数です (例: SHA-256)。
- kは両側から導出されるパラメータである。SRP-6ではk = 3であるが、SRP-6aではNとgから導出される :k = H ( N , g )。これは、攻撃者がサーバーを偽装したときに2対1の推測を防ぐために使用される。[8] [9]
- s は塩です。
- I は識別用のユーザー名です。
- p はユーザーのパスワードです。
- v はホストのパスワード検証子で、v = g xであり、最低でもx = H ( s , p ) です。xはクライアント側でのみ計算されるため、より強力なアルゴリズムを自由に選択できます。実装では、ホストに必要な手順に影響を与えることなく、x = H ( s | I | p )を使用できます。標準 RFC2945 では、 x = H ( s | H ( I | ":" | p ) )と定義されています。x内でIを使用すると、悪意のあるサーバーが 2 人のユーザーが同じパスワードを共有しているかどうかを知ることができなくなります。
- AとB は、それぞれユーザーとホストのランダムな 1 回限りの一時キーです。
- | (パイプ) は連結を表します。
他のすべての変数はこれらに基づいて定義されます。
まず、サーバー Steve との間でパスワードp を確立するために、クライアント Carol はランダムなソルト s を選択し、x = H ( s , p )、v = g xを計算します。Steve は、Iでインデックス付けされたvとs をCarol のパスワード検証子とソルトとして保存します。Carol はx を誰とも共有してはならず、このステップで x を安全に消去する必要があります。これは、 x がプレーンテキストのパスワードpと同等であるためです。このステップは、システムが Steve とのユーザー登録の一部として使用される前に完了します。ソルトsは共有され、後でセッション キーをネゴシエートするために交換されるため、値はどちらの側でも選択できますが、これは Carol が単一の登録要求でI、s、v を登録できるようにするために行われることに注意してください。登録要求の送信と認証は SRP ではカバーされていません。
その後、後日パスワードの証明を実行するために、次の交換プロトコルが実行されます。
- キャロル → スティーブ: ランダムな値aを生成し、IとA = g aを送信します。
- スティーブ → キャロル: ランダムな値bを生成し、sを送信し、B = kv + g b
- 両方: u = H ( A , B )
- キャロル: Sキャロル= ( B − kg x ) ( a + ux ) = ( kv + g b − kg x ) ( a + ux ) = ( kg x − kg x + g b ) (a + ux) = ( g b ) ( a + ux )
- キャロル: Kキャロル= H ( Sキャロル)
- スティーブ:Sスティーブ= ( Av u ) b = ( g a v u ) b = [ g a ( g x ) u ] b = ( g a + ux ) b = ( g b ) (a + ux)
- スティーブ:Kスティーブ= H ( Sスティーブ) = Kキャロル
これで、2 つの当事者は強力なセッション キーK を共有できるようになりました。認証を完了するには、お互いにキーが一致していることを証明する必要があります。考えられる方法の 1 つは次のとおりです。
- キャロル → スティーブ: M 1 = H [ H ( N ) XOR H ( g ) | H ( I ) | s | A | B | Kキャロル]。スティーブはM 1を検証します。
- スティーブ → キャロル: M 2 = H ( A | M 1 | Kスティーブ)。キャロルはM 2を検証します。
この方法では、なりすましを成功させるためには、キーだけでなく共有状態をより多く推測する必要があります。追加状態のほとんどは公開されていますが、サーバーの秘密キーなどのプライベート情報はハッシュ関数の入力に安全に追加できます。[説明が必要]
あるいは、パスワードのみの証明では、Kの計算をスキップして、共有S を次のように証明できます。
- キャロル → スティーブ: M 1 = H ( A | B | Sキャロル)。スティーブはM 1を検証します。
- スティーブ → キャロル: M 2 = H ( A | M 1 | Sスティーブ)。キャロルはM 2を検証します。
SRP を使用して、ネゴシエーション後すぐに使用される共有キーK をネゴシエートする場合、 M 1とM 2の検証手順を省略したくなるかもしれません。サーバーは、復号化できないクライアントからの最初のリクエストを拒否します。ただし、以下の実装の落とし穴のセクションで示すように、これは危険な場合があります。
両当事者は、以下の安全策も講じています。
- Carol は、 B = 0 (mod N ) またはu = 0を受け取った場合は中止します。
- Steve は、 A (mod N ) = 0を受け取った場合は中止します。
- キャロルはまずK (またはS )の証明を示す必要があります。スティーブがキャロルの証明が間違っていることに気付いた場合、彼は自分のK (またはS )の証明を示すことなく中止する必要があります。
Python のサンプルコード
「 SRP認証の例」
警告: テスト以外の実際の暗号化目的には使用しないでください。
警告: 以下のコードには重要な安全策が欠けています。A、B、U がゼロでないかどうかはチェックされません。
http://srp.stanford.edu/design.html に基づく
"""
hashlib をインポートする ランダムをインポートする
# 注意: str はそのまま変換されますが、str([1,2,3,4]) は "[1,2,3,4]" に変換されます
def H ( * args ) -> int :
"""一方向ハッシュ関数。""" a = ":" . join ( str ( a ) for a in args ) return int ( hashlib . sha256 ( a . encode ( "utf-8" )) . hexdigest (), 16 )
def cryptrand ( n : int = 1024 ):
ランダム値を返す 。SystemRandom ( ) 。getrandbits ( n ) % N
# 大きな安全な素数 (N = 2q+1、q は素数)
# すべての演算は N を法として実行されます
# (「openssl dhparam -text 1024」を使用して生成)
N = """00:c0:37:c3:75:88:b4:32:98:87:e6:1c:2d:a3:32:
4b:1b:a4:b8:1a:63:f9:74:8f:ed:2d:8a:41:0c:2f:
c2:1b:12:32:f0:d3:bf:a0:24:27:6c:fd:88:44:81:
97:aa:e4:86:a6:3b:fc:a7:b8:bf:77:54:df:b3:27:
c7:20:1f:6f:d1:7f:d7:fd:74:15:8b:d3:1c:e7:72:
c9:f5:f8:ab:58:45:48:a9:9a:75:9b:5a:2c:05:32: 16:
2b:7b:62:18:e8:f1:42:bc:e2:c3:0 d:77:84:68:
9a:48:3e:09:5e:70:16:18:43:79:13:a8:c3:9c:3d:
d0:d4:ca:3c:50:0b:88:5f:e3"""
N = int ( "" . join ( N . split ()) . replace ( ":" , "" ), 16 )
g = 2 # N を法とするジェネレータ
k = H ( N , g ) # 乗数パラメータ(従来のSRP-6ではk=3)
F = '#0x' # 書式指定子
print ( "#. H、N、g、k はクライアントとサーバーの両方で事前に知られています:" )
print ( f ' { H = } \n { N = :{ F }} \n { g = :{ F }} \n { k = :{ F }} ' )
print ( " \n 0. サーバーは (I, s, v) をパスワードデータベースに保存します" )
# サーバーは最初にパスワード検証子を生成する必要があります
I = "person" # ユーザー名
p = "password1234" # パスワード
s = cryptrand ( 64 ) # ユーザーのソルト
x = H ( s , I , p ) # 秘密鍵
v = pow ( g , x , N ) # パスワード検証子
印刷( f ' { I = } \n { p = } \n { s = :{ F }} \n { x = :{ F }} \n { v = :{ F }} ' )
# 0. サーバーはパスワードデータベースに(I, s, v)を保存します
# I = 'person'
# p = 'password1234'
# s = 0x67bc8932cfd26a49
# x = 0x98a4bce8dde877762a90222f1a1161eba9248590a47eb83aa9e5bd7ecda5368d
# v = 0xa7e2038e675d577ac0f318999cab67bba7ec2daf45d2d09f7911b1b78d2fc7f963cd0ac8f17851e0516f059e453672c3b70fcecf5f6843180b271abdd01f552ccda7b 24fe4719336409cbc1352f8517be651b8935cc0b74ff2819fa07a3f031537d4cfd9f8df7b788a5f2f88e1cd4106b35c38b3d7205a
# <デモ> --- 停止 ---
print ( " \n 1. クライアントはユーザー名 I と公開一時値 A をサーバーに送信します" )
a = cryptrand ()
A = pow ( g , a , N )
print ( f " { I = } \n { A = :{ F }} " ) # client->server (I, A)
# 1. クライアントはユーザー名 I と公開一時値 A をサーバーに送信します
# I = 'person'
# A = 0x678556a7e76581e051af656e8cee57ae46df43f1fce790f7750a3ec5308a85da4ec4051e5cb74d3e463685ee975a2747cf49035be67c931b56e793f23ea3524af8909d cfbc8675d872361025bf884778587ac49454a57c53a011ac2be2839bfb51bf7847a49a483aba870dc7a8b467a81cec91b8ae7813
# <デモ> --- 停止 ---
print ( " \n 2. サーバーはユーザーのソルト s と公開一時値 B をクライアントに送信します" )
b = cryptrand ()
B = ( k * v + pow ( g , b , N )) % N
print ( f " { s = :{ F }} \n { B = :{ F }} " ) # server->client (s, B)
# 2. サーバーはユーザーのソルト s と公開一時値 B をクライアントに送信します
# s = 0x67bc8932cfd26a49
# B = 0xb615a0a5ea6abf138077bbd869f6a8da37dfc0b7e06a9f5fac5c1e4109c6302cb3e94dcc2cc76da7b3d87d7e9b68a1db998ab239cfde609f3f7a1ece4a491ce3d9a665c 20cf4e4f06730daaa8f52ed61e45bbb67cdc337bf648027ffa7f0f215d5ebe43f9f51832518f1142266aae0dfa960e0082b5154
# <デモ> --- 停止 ---
print ( " \n 3. クライアントとサーバーはランダムスクランブルパラメータを計算します" )
u = H ( A , B ) # ランダムスクランブルパラメータ
print ( f " { u = :{ F }} " )
# 3. クライアントとサーバーはランダムスクランブルパラメータを計算します
# u = 0x796b07e354c04f672af8b76a46560655086355a9bbce11361f01b45d991c0c52
# <デモ> --- 停止 ---
print ( " \n 4. クライアントがセッションキーを計算します" )
x = H ( s , I , p )
S_c = pow ( B - k * pow ( g , x , N ), a + u * x , N )
K_c = H ( S_c )
print ( f " { S_c = :{ F }} \n { K_c = :{ F }} " )
# 4. クライアントがセッションキーを計算します
# S_c = 0x699170aff6e9f08ed09a1dff432bf0605b8bcba05aadcaeea665757d06dbda4348e211d16c10ef4678585bcb2809a83c62b6c19d97901274ddafd4075f90604c06baf036af587af8540342b47867eaa22b9ca5e35ac14c8e85a0c4e623bd855828dffd513cea4d829c407137a0dd81ab4cde8a904c45cc
# K_c = 0x43f8df6e1d2ba762948c8316db5bf03a7af49391742f5f51029630711c1671e
# <デモ> --- 停止 ---
print ( " \n 5. サーバーがセッションキーを計算します" )
S_s = pow ( A * pow ( v , u , N ), b , N )
K_s = H ( S_s )
print ( f " { S_s = :{ F }} \n { K_s = :{ F }} " )
# 5. サーバーがセッションキーを計算します
# S_s = 0x699170aff6e9f08ed09a1dff432bf0605b8bcba05aadcaeea665757d06dbda4348e211d16c10ef4678585bcb2809a83c62b6c19d97901274ddafd4075f90604c06baf036af587af8540342b47867eaa22b9ca5e35ac14c8e85a0c4e623bd855828dffd513cea4d829c407137a0dd81ab4cde8a904c45cc
# K_s = 0x43f8df6e1d2ba762948c8316db5bf03a7af49391742f5f51029630711c1671e
# <デモ> --- 停止 ---
print ( " \n 6. クライアントはセッションキーの証明をサーバーに送信します" )
M_c = H ( H ( N ) ^ H ( g ), H ( I ), s , A , B , K_c )
print ( f " { M_c = :{ F }} " ) # client->server (M_c) ; サーバーは M_c を検証します
# 6. クライアントがセッションキーの証明をサーバーに送信します
# M_c = 0x75500df4ea36e06406ac1f8a8241429b8e90a8cba3adda3405c07f19ea3101e8
# <デモ> --- 停止 ---
print ( " \n 7. サーバーはセッションキーの証明をクライアントに送信します" )
M_s = H ( A , M_c , K_s )
print ( f " { M_s = :{ F }} " ) # server->client (M_s) ; クライアントは M_s を検証します
# 7. サーバーはセッションキーの証明をクライアントに送信します
# M_s = 0x182ed24d1ad2fb55d2268c46b42435d1ef02e0fc49f647c03dab8b2a48b0bd3d
実装の落とし穴
キー検証なしでサーバーファーストメッセージングによるオフラインブルートフォース攻撃
サーバーがクライアントからの検証を待たずに暗号化メッセージを送信した場合、攻撃者はハッシュクラッキングと同様のオフラインブルートフォース攻撃を仕掛けることができます。これは、サーバーが 2 番目のパケットでソルトとBと一緒に暗号化メッセージを送信した場合、またはキー検証がスキップされ、サーバー (クライアントではなく) が最初の暗号化メッセージを送信した場合に発生する可能性があります。最初のパケットの後、サーバーは共有キーK を計算するためのすべての情報を持っているため、これは魅力的です。
攻撃は次のようになります:
- キャロル → スティーブ: ランダムな値aを生成し、IとA = g aを送信します。
- スティーブ: u = H ( A , B ); S = Av u ; K = H ( S )
- スティーブ: メッセージmを生成し、それを暗号化してc =ENC( K , m )を生成します。
- スティーブ→キャロル: ランダムな値bを生成し、s、B = kv + g bおよびcを送信します。
キャロルはxもvも知りません。しかし、任意のパスワードpが与えられれば、次の式を計算できます。
- x p = H (塩、p )
- S p = ( B - kg x p ) ( a + ux p )
- Kp = H ( Sp )です。
K p は、 p が想定されるパスワードである場合に Steve が使用するキーです。K p を計算するために必要なすべての値は、Carol によって制御されるか、Steve からの最初のパケットから判明します。Carol はパスワードを推測し、対応するキーを生成し、Steve の暗号化されたメッセージc を復号化してキーを検証しようとします。プロトコル メッセージは構造化される傾向があるため、 cが適切に復号化されたことを識別するのは簡単であると想定されます。これにより、オフラインでパスワードを回復できます。
スティーブが、暗号化されたメッセージを送信する前に、キャロルが正しいキーを計算できることを証明するまで待っていたら、この攻撃は不可能だったでしょう。攻撃者はキー検証ステップを通過できないため、SRP の適切な実装はこの攻撃の影響を受けません。
タイミング攻撃に基づくオフラインブルートフォース
2021年にダニエル・デ・アルメイダ・ブラガ、ピエール・アラン・フーケ、モハメド・サブトはPARASITE [10]という論文を発表し、ネットワーク上でのタイミング攻撃の実際的な悪用を実証した。これは大きな数のモジュラー指数の非定数実装を悪用するもので、特にOpenSSLに影響を与えた。
実装
- SRP-6 変数 SRP-6 プロトコルを実装するために必要な暗号化プリミティブの Java ライブラリ。
- OpenSSLバージョン 1.0.1 以降。
- Botan(C++暗号ライブラリ)にはSRP-6aの実装が含まれています。
- TLS-SRP は、 SRP を使用するトランスポート層セキュリティ用の暗号スイートのセットです。
- srp-client SRP-6a 実装(RFC 5054 と互換性あり)、オープン ソース、Mozilla Public License (MPL) ライセンス。
- JavaScript 暗号ライブラリには、オープン ソースでBSDライセンスのSRP プロトコルの JavaScript 実装が含まれています。
- Gnu Crypto は、非フリー ソフトウェアと組み合わせてライブラリとして使用することを許可している「ライブラリ例外」付きのGNU 一般公衆利用許諾書に基づいてライセンスされたJava実装を提供します。
- Legion of the Bouncy Castle は、MIT ライセンスに基づいてJava およびC#実装を提供します。
- Nimbus SRP は、検証ジェネレータ、クライアント側およびサーバー側セッションを提供する Java ライブラリです。カスタム パスワード キー、クライアントおよびサーバー証拠メッセージ ルーチンのインターフェイスが含まれています。外部依存関係はありません。Apache 2.0 ライセンスに基づいてリリースされています。
- srplibcpp は MIRACL をベースにした C++ 実装です。
- DragonSRP は、現在OpenSSLで動作する C++ モジュール実装です。
- Json2Ldap は、LDAPディレクトリ サーバーに SRP-6a 認証を提供します。
- csrp SRP-6a の C での実装。
- Perlでの Crypt-SRP SRP-6a 実装。
- pysrp Pythonでの SRP-6a 実装(csrp と互換性あり)。
- py3srp 純粋なPython3での SRP-6a 実装。
- srptools Pythonでセキュア リモート パスワード (SRP) 認証を実装するためのツール。検証済みの互換性のあるライブラリ。
- Meteor Web フレームワークのアカウント システムは、パスワード認証用の SRP を実装します。
- srp-rb Rubyでの SRP-6a 実装。
- falkmueller デモ SRP-6a は、MIT ライセンスに基づいてJavaScriptとPHPでスタンフォードSRP プロトコル デザインの実装です。
- srp-6a-demo PHPおよびJavaScriptでの SRP-6a 実装。
- thinbus-srp-js SRP-6a のJavaScript実装。Spring Securityを使用したデモ アプリである Nimbus SRP を使用する互換性のあるJavaクラスが付属しています。PHPサーバーへの認証を実行するデモ アプリケーションもあります。Apache Licenseに基づいてリリースされています。
- Stanford JavaScript Crypto Library (SJCL) は、キー交換用の SRP を実装します。
- node-srp は、SRP の JavaScript クライアントおよびサーバー (node.js) 実装です。
- C# および Java での C# および Java 実装用の SRP6。
- ALOSRPAuth は、SRP-6a の Objective-C 実装です。
- go-srp は SRP-6a の Go 実装です。
- tssrp6a は SRP-6a の TypeScript 実装です。
- 暗号化ベースの Spring Boot アプリケーションを開発するための TheIceNet 暗号化 Java ライブラリ。SRP-6a を実装します。Apacheライセンスに基づきます。
- SRP-6a の .NET 実装における SRP-6a
- Apple Homekit Apple Homekitは、「スマート」ホームアクセサリやデバイスとペアリングする際にSRPを使用します
- 電子メール暗号化のための Proton メール認証
- SRP は SRP の Go 実装であり、Posterity でユーザーを認証するために使用されます。
歴史
SRP プロジェクトは 1997 年に開始されました。[11] SRP-1 のセキュリティ ホールを修正する 2 つの異なるアプローチの結果、SRP-2 と SRP-3 が生まれました。[12] SRP-3 は 1998 年に会議で初めて公開されました。[13] SHA1 を使用した SRP-3 を説明する RFC 2945 は 2000 年に公開されました。[14]「2 対 1」の推測攻撃とメッセージ順序付け攻撃を修正する SRP-6 は 2002 年に公開されました。[8] SRP-6a は、2005 年のバージョン 2.1.0 で公式の「libsrp」に登場しました。[15] SRP-6a は標準で次のように記載されています。
- ISO/IEC 11770-4:2006「鍵合意メカニズム 2」(この方法は「SRP-6」と呼ばれますが、kの計算は 6a です)
- 2007年のRFC 5054 TLS-SRP(再び「SRP-6」と呼ばれますが、正誤表[16]で修正されています)
- IEEE Std 1363.2-2008「DLAPKAS-SRP6」(以下「SRP-6」)[17]
IEEE 1363.2には、2001年にYongge Wangが寄稿した離散対数を楕円曲線に置き換えた変種である「SRP5」の説明も含まれています。[18]また、RFC 2945に記載されているSRP-3についても説明しています。
参照
参考文献
- ^ 「SRPとは何か?」スタンフォード大学。
- ^ シャーマン、アラン・T.; ラヌス、エリン; リスコフ、モーゼス; ジーグラー、エドワード; チャン、リチャード; ゴラシェフスキー、エニス; ヴヌク・フィンク、ライアン; ボニャディ、サイラス・J.; ヤクセティグ、マリオ(2020)、ニガム、ヴィヴェック; バン・キリギン、タヤナ; タルコット、キャロリン;ガットマン、ジョシュア(編)、「セキュアリモートパスワードプロトコルの形式手法分析」、ロジック、言語、セキュリティ:アンドレ・セドロフの65歳の誕生日に捧げるエッセイ、コンピュータサイエンスの講義ノート、Cham:Springer International Publishing、pp. 103–126、arXiv:2003.07421、doi:10.1007/978-3-030-62077-6_9、ISBN 978-3-030-62077-6
- ^ Green, Matthew (2018 年 10 月 18 日)。「SRP を使うべきか?」暗号工学に関するいくつかの考察。注意: ソースでは理由は不明ですが、SRP-6 を SRPv4 と呼んでいます。
- ^ Haase, Björn (2023年1月22日). 「(strong) AuCPace、拡張されたPAKE [draft-haase-aucpace-07]」。インターネットエンジニアリングタスクフォース。 2023年6月10日閲覧。
- ^ Stanislaw Jarecki、Hugo Krawczyk、Jiayu Xu。OPAQUE: 事前計算攻撃に対して安全な非対称 PAKE プロトコル(PDF)。Eurocrypt 2018。
- ^ Taylor, David; Tom Wu; Nikos Mavrogiannopoulos; Trevor Perrin (2007 年 11 月)。「TLS 認証に Secure Remote Password (SRP) プロトコルを使用する」。RFC 5054
- ^ Carlson, James、Bernard Aboba、Henry Haverinen (2001 年 7 月)。「EAP SRP-SHA1 認証プロトコル」。IETF。下書き。
- ^ ab Wu, Tom (2002 年 10 月 29 日). SRP-6: セキュア リモート パスワード プロトコルの改善と改良 (技術レポート).
- ^ 「SRP プロトコル設計」。
- ^ 「PARASITE: 実際の Srp 実装に対するパスワード回復攻撃」 。2023年11 月 8 日閲覧。
- ^ 「SRP: プロジェクトについて」。srp.stanford.edu。
- ^ 「SRP-2: 設計仕様」. srp.stanford.edu .
- ^ Wu, T.、「安全なリモート パスワード プロトコル」、1998 年インターネット協会ネットワークおよび分散システム セキュリティ シンポジウム議事録、pp. 97-111、1998 年 3 月。
- ^ 「SRP: 設計仕様」. srp.stanford.edu .
- ^ srp-2.1.2.tar.gz の CHANGES ファイル。http://srp.stanford.edu/download.html から入手可能。
- ^ Wang, Mingye. 「RFC Errata Report #7538」. RFC 編集者. 2023年10月15日閲覧。
- ^ IEEE 1363.2-2008: パスワードベースの公開鍵暗号化技術に関する IEEE 標準仕様
- ^ Wang, Y.、「IEEE P1363.2 Submission / D2001-06-21」、[P1363.2-ecsrp-06-21.doc] Yongge Wang による P1363.2 への寄稿で、SRP プロトコルの楕円曲線バージョンが提示されています (2001 年 6 月 21 日)。
外部リンク
- 公式サイト
- SRP ライセンス - BSD のようなオープンソース。
- US6539479 - SRP 特許 (維持費の未払いにより 2015 年 5 月 12 日に失効 (Google Patents による)。当初は 2018 年 7 月に失効する予定でした)。
マニュアルページ
- pppd(8): ポイントツーポイントプロトコルデーモン
- srptool(1): シンプルなSRPパスワードツール
RFC
- RFC 2944 - Telnet 認証: SRP
- RFC 2945 - SRP 認証および鍵交換システム (バージョン 3)
- RFC 3720 - インターネット小型コンピュータシステムインターフェース (iSCSI)
- RFC 3723 - IP 経由のブロック ストレージ プロトコルのセキュリティ保護
- RFC 3669 - 知的財産問題に関するワーキンググループ向けガイドライン
- RFC 5054 - TLS 認証にセキュア リモート パスワード (SRP) プロトコルを使用する
その他のリンク
- IEEE1363 規格
- SRP 知的財産スライド (2001 年 12 月 - 廃止される可能性あり) 言及されている EKE 特許は 2011 年と 2013 年に期限切れになりました。
