SRP：Secure Remote Passwordプロトコル

Secure Remote Password（SRP）プロトコルは、StanfordのTom Wuによって開発され、2000年にRFC 2945として公開されました。その後、改良版のSRP-6aが定義されています。SRPでは、パスワード自体を暗号化した形でさえ送信することなく、共有パスワードに基づく相互認証を実現できます。

SRPの登録時に、クライアントはパスワード検証値 v = g^x mod N を計算します。ここで x = H(salt || password)、Nは大きな安全素数です。サーバーが保存するのはソルトと検証値 vだけです。サーバーのデータベースが侵害されても、保存された検証値からパスワードが直接明らかになることはありません。

SRPのログイン時には、クライアントとサーバーがDiffie-Hellmanに似た交換を行い、共有セッション鍵を生成します。双方の計算にはパスワードから導出された値が組み込まれるため、結果のセッション鍵を正しく計算できるのは、それぞれパスワードと検証値を知っている側だけです。

SRPは相互認証を提供します。クライアントはパスワードを知っていることを証明し、サーバーは正規の検証値を保持していることを証明します。偽サーバーは本物の検証値なしにはSRPの交換を正しく完了できないため、パスワード情報を収集しようとする偽サーバーを使ったフィッシング攻撃を防止できます。

検証値は v = g^x mod N として計算されます。ここで x = H(salt || password)、gは生成元、Nは2048ビット以上の安全素数です。離散対数問題により、vからxを復元することは計算上実行不可能です。パスワードを検証するには、SRPの交換全体を正常に完了する必要があります。

SRP-6aは、乗数パラメーター k = H(N, g)を導入し、クライアントとサーバーの計算順序を変更することで、元のSRP-3およびSRP-6の弱点に対処しています。これらの変更により、特定の二重推測攻撃を防ぎ、プロトコルの早い段階でサーバーの寄与を結び付けられます。

SRPは、実際のシステムにも広く導入されています。AppleはiCloud Keychainの同期にSRPを使用しており、アカウントのパスワードをAppleのサーバーに明かすことなく、デバイスがキーチェーンデータを取得できるようにしています。1Passwordも、サーバー側での認証情報の漏えいを防ぐため、認証モデルにSRPを使用してきました。

SRPは、パスワードとサーバーの検証値の両方に結び付いたセッション鍵を生成するため、フィッシング用サーバーはSRPハンドシェイクを正しく完了できません。ユーザーがSRP経由でフィッシングサイトに接続すると認証に失敗するため、従来のパスワード送信にはない、組み込みのフィッシング対策機能が得られます。

SRPは計算コストが高く、大きな整数（2048ビット以上）のべき乗剰余計算が必要です。また、パラメーター検証には細かな落とし穴が多く、正しく実装するのが難しいため、実装上の脆弱性につながってきました。さらに、交換自体を受動的な盗聴から守るため、安全な通信路（TLS）も必要です。

RFC 5054では、SRPによる相互認証をTLSハンドシェイクに直接統合するTLS-SRP暗号スイートが定義されています。これにより、サーバー証明書を必要とせずに、暗号化された相互認証を実現できます。ただし、FIDO2やOPAQUEというより現代的な代替手段が登場したため、TLS-SRPは実際には限定的な採用にとどまっています。

SRPは画期的なプロトコルでしたが、OPAQUEのような現代的な代替手段は、事前計算攻撃への耐性など、より強力なセキュリティ保証を提供します。また、FIDO2／パスキーはパスワード自体を不要にします。新しいシステムではOPAQUEまたはFIDO2が推奨されますが、フィッシングの脆弱性なしにパスワードベースの相互認証が必要なシステムでは、SRPも有効な選択肢です。

SRPでは、ユーザーのパスワードの代わりにサーバーが保存するものは何ですか？

SRPはパスワードではなくパスワード検証値を保存し、DHに似た交換によって共有セッション鍵を生成し、フィッシングに強い相互認証を提供します。SRP-6aは、推測攻撃への耐性によって元の仕様を改良しています。AppleのiCloud Keychainと1Passwordは、本番環境でSRPを使用しています。新しいシステムでは、OPAQUEとFIDO2が後継となる現代的な選択肢です。