ソルトチャレンジレスポンス認証メカニズム

暗号学において、ソルトチャレンジレスポンス認証メカニズム（SCRAM ）は、サーバーに対するユーザーの認証を提供する、最新のパスワードベースのチャレンジレスポンス認証メカニズムのファミリーです。これは、 Simple Authentication and Security Layer （SASL）用に指定されているため、 LDAP、HTTP、SMTP、POP3、IMAP、JMAP（電子メール）、XMPP（チャット）、MongoDB、PostgreSQL （データベース）などのサービスへのパスワードベースのログインに使用できます。XMPPの場合、SCRAMのサポートは必須です。^[1]

アリスはボブのサーバーにログインしたいと考えています。アリスは自分が本人であることを証明する必要があります。この認証問題を解決するために、アリスとボブはパスワードについて合意しており、アリスはそれを知っており、ボブはそれを検証する方法を知っています。

ここで、アリスは暗号化されていない接続を介してパスワードを平文でボブに送信し、ボブが検証できるようにすることができます。しかし、そうすると、回線を盗聴しているマロリーがパスワードにアクセスできるようになります。アリスとボブは、接続を暗号化することでこれを回避しようとすることができます。しかし、アリスには、暗号化がボブによって設定されたのか、中間者攻撃を行うマロリーによって設定されたのかはわかりません。そのため、アリスは代わりに、 CRAM-MD5またはDIGEST-MD5などのハッシュ化されたパスワードを送信します。これはハッシュであるため、マロリーはパスワード自体を取得しません。ハッシュにはチャレンジがソルト化されているため、マロリーはそれを 1 回のログイン プロセスにしか使用できません。しかし、アリスはボブに機密情報を渡したいと考えており、それがマロリーではなくボブであることを確かめたいと考えています。

この問題を解決するために、ボブは証明機関(CA)に自分自身を登録し、証明書に署名してもらいました。アリスはその署名システムだけを頼りにすることもできますが、そのシステムに弱点があることはわかっています。中間者攻撃がないことをアリスにさらに保証するために、ボブはパスワード (またはそのソルト ハッシュ) を知っているという証明を作成し、この証明に自分の証明書を含めます。この組み込みはチャネル バインディングと呼ばれます。これは、下位の暗号化チャネルが上位のアプリケーション チャネルに「バインド」されるためです。

するとアリスはボブの認証を持ち、ボブはアリスの認証を持つことになります。これらを合わせると相互認証が成立します。DIGEST-MD5はすでに相互認証を可能にしていましたが、誤って実装されることがよくありました。^{[2] [3]}

マロリーが中間者攻撃を実行して CA 署名を偽造すると、パスワードのハッシュを取得できます。しかし、アリスがハッシュにマロリーの暗号化キーを含めたため、ボブのログインが失敗し、マロリーは 1 回のログイン セッションでもアリスになりすますことはできません。完全に透過的な攻撃を行うには、マロリーはアリスが使用するパスワード、またはボブの秘密の暗号化キーを知っている必要があります。

ボブは、サーバー データベースのデータ侵害について耳にし、ユーザーのパスワードを平文で保存したくないと決めました。CRAM-MD5 および DIGEST-MD5 ログイン スキームについては聞いたことがありますが、これらのログイン スキームをユーザーに提供するには、ハッシュが弱く、ソルトなしのパスワードを保存する必要があることを知っています。ボブはそのアイデアが気に入らないので、パスワードを平文で要求することにしました。次に、bcrypt、scrypt、PBKDF2などの安全なハッシュ スキームを使用してハッシュし、必要に応じてソルトを追加できます。ただし、ボブとアリスは、それでも上記の問題に直面します。この問題を解決するために、ボブは SCRAM を使用します。SCRAM では、ボブは PBKDF2 を使用して、ソルト付き形式でパスワードを保存できます。ログイン中に、ボブはアリスにソルトと PBKDF2 アルゴリズムの反復回数を送信し、アリスはこれらを使用して、ボブがデータベースに保存しているハッシュ パスワードを計算します。 SCRAM での以降の計算はすべて、両者が知っているこの値に基づいて行われます。

すべてのクライアントとサーバーはSHA-1ハッシュアルゴリズムをサポートする必要がありますが、SCRAMはCRAM-MD5やDIGEST-MD5とは異なり、基礎となるハッシュ関数から独立しています。^[4] IANAによって定義された任意のハッシュ関数を代わりに使用できます。^[5]動機のセクションで述べたように、SCRAMはPBKDF2メカニズムを使用しており、サーバーでデータ漏洩が発生した場合にブルートフォース攻撃に対する強度を高めます。Hは、サーバーによってアドバタイズされ、クライアントによって選択されたアルゴリズムの名前で指定される、選択されたハッシュ関数とします。たとえば、「SCRAM-SHA-1」はハッシュ関数としてSHA-1を使用します。

クライアントは、次のように、パスワード、ソルト、および計算の反復回数からキーまたはソルト付きパスワードを導出します。

SaltedPassword = H(password, salt, iteration-count) = PBKDF2(HMAC, password, salt, iteration-count, output length of H)。

RFC 5802 では、サーバーとクライアント間の連続する 4 つのメッセージに名前を付けています。

顧客第一主義

クライアントファーストメッセージは、 GS2ヘッダー (チャネル バインディング フラグと、認証情報のオプションの名前で構成)、必要なusername、およびランダムに生成されたクライアント nonceで構成されますc-nonce。

サーバーファースト

サーバーは、このクライアント nonce に独自の nonce を追加しs-nonce、それをサーバーファーストメッセージに追加します。このメッセージには、saltユーザーのパスワード ハッシュをソルト化するためにサーバーが使用する と、反復回数 も含まれますiteration-count。

クライアント最終

その後、クライアントは、チャネル バインディング、Base64 でエンコードされた GS2 ヘッダーとチャネル バインディング データ、クライアントとサーバーの nonce の連結、およびクライアント証明を含むクライアント最終メッセージを送信します。proof

サーバー最終

通信は、サーバー署名を含むサーバー最終verifierメッセージで終了します。

クライアントとサーバーは、次の内容で構成される同じ変数を持っていることを互いに証明しますAuth。

Auth = client-first-without-header + , + server-first + , + client-final-without-proof（カンマで連結）

より具体的には、次の形式になります。

= n=username,r=c‑nonce,[extensions,]r=c‑nonce‖s‑nonce,s=salt,i=iteration‑count,[extensions,]c=base64(channel‑flag,[a=authzid],channel‑binding),r=c‑nonce‖s‑nonce[,extensions]

証明は次のように計算されます。

ClientKey = HMAC(SaltedPassword, 'Client Key')

ServerKey = HMAC(SaltedPassword, 'Server Key')

ClientProof = p = ClientKey XOR HMAC(H(ClientKey), Auth)

ServerSignature = v = HMAC(ServerKey, Auth)

ここで、XOR演算は同じ長さのバイト文字列に適用され、の通常のハッシュです。およびは逐語的な文字列です。 H(ClientKey)ClientKey'Client Key''Server Key'

ClientKeyサーバーは、計算して保存された値と ClientProof比較することでクライアントを認証できます。H(ClientKey)

クライアントは、直接計算して比較することでサーバーを認証できますServerSignature。

サーバーはユーザー名salt、、、、のみを保存します。サーバーは、で暗号化されiteration-countたユーザー名がクライアント証明から復元されるため、一時的にアクセスできます。 H(ClientKey)ServerKeyClientKeyH(ClientKey)

クライアントに必要なのは だけですpassword。

チャネル バインディングという用語は、相互認証を提供するアプリケーション層を下位層 (主に暗号化層) に「バインド」し、接続のエンドポイントが両方の層で同じであることを保証する、中間者攻撃防止戦略を表します。チャネル バインディングには、一意チャネル バインディングとエンドポイントチャネル バインディングの 2 つの一般的な方向性があります。最初の方向性では、特定の接続が使用されることが保証され、2 番目の方向性では、エンドポイントが同じであることが保証されます。

チャネルバインディングには複数のタイプがあり、各タイプにはチャネルバインディングの一意のプレフィックスがあります。^{[6]すべてのチャネルバインディングタイプは、}チャネルバインディングデータの内容を指定します。これは、チャネルとエンドポイントに固有の情報を提供します。たとえば、tls-server-end-pointチャネルバインディングの場合、これはサーバーのTLS証明書です。^[7] SCRAMをアプリケーション層として使用するチャネルバインディングの使用例としては、トランスポート層セキュリティ（TLS）を下位層として使用することが考えられます。TLSは通信が暗号化されているため、受動的な盗聴から保護します。ただし、クライアントがサーバーを認証しない場合（サーバーの証明書を検証するなど）、中間者攻撃を防ぐことはできません。このため、エンドポイントは互いにIDを保証する必要があり、これはSCRAMによって提供されます。

gs2 -cbind-flag SCRAM 変数は、クライアントがチャネル バインディングをサポートしているかどうか、またはサーバーがチャネル バインディングをサポートしていないと認識しているかどうかを指定します。また、 c-bind-input には、 gs2-cbind-flagとチャネル バインディングの一意のプレフィックス、およびチャネル バインディング データ自体が含まれます。

SCRAM ではチャネル バインディングはオプションであり、gs2-cbind-flag変数はダウングレード攻撃を防ぎます。

サーバーがチャネル バインディングをサポートする場合、アドバタイズされた SCRAM アルゴリズム名に文字シーケンス「-PLUS」が追加されます。

• 強力なパスワード保存：正しく実装すると、サーバーはパスワードをソルト付きの反復ハッシュ形式で保存できるため、オフライン攻撃が困難になり、データベース侵害の影響が減少します。^[8]
• シンプルさ：SCRAMの実装はDIGEST-MD5よりも簡単です^{[9] 。 [10]}
• 国際的な相互運用性：RFCでは、 CRAM-MD5とは異なり、ユーザー名とパスワードにUTF-8を使用することが義務付けられています。^{[9] [11]}
• ログインプロセス全体ではソルトとハッシュが付加されたパスワードのみが使用され、サーバ上のソルトは変更されないため、パスワードを保存するクライアントはハッシュ化されたバージョンを保存でき、クリアテキストのパスワードを攻撃者に公開することはありません。このようなハッシュ化されたバージョンは1つのサーバにバインドされるため、パスワードの再利用に役立ちます。^[12]

• RFC 5802、ソルトチャレンジレスポンス認証メカニズム (SCRAM) SASL および GSS-API メカニズム
• RFC 5803、ソルト チャレンジ レスポンス認証メカニズム (SCRAM) シークレットを保存するための軽量ディレクトリ アクセス プロトコル (LDAP) スキーマ
• RFC 6120、拡張メッセージングおよびプレゼンスプロトコル (XMPP): コア
• RFC 6331、DIGEST-MD5 を Historic に移行
• RFC 7677、SCRAM-SHA-256 および SCRAM-SHA-256-PLUS: 簡易認証およびセキュリティ層 (SASL) メカニズム
• RFC 7804、ソルトチャレンジレスポンス HTTP 認証メカニズム
• RFC 8600、セキュリティ情報交換のための拡張メッセージングおよびプレゼンスプロトコル (XMPP) の使用
• RFC 8621、メール用 JSON メタ アプリケーション プロトコル (JMAP)
• RFC 9051、インターネット メッセージ アクセス プロトコル (IMAP) - バージョン 4rev2
• RFC 9266、TLS 1.3 のチャネル バインディング
• draft-ietf-sasl-crammd5-to-historic-00 および draft-zeilenga-luis140219-crammd5-to-historic-00、CRAM-MD5 から Historic
• draft-melnikov-scram-sha-512、SCRAM-SHA-512、および SCRAM-SHA-512-PLUS シンプル認証およびセキュリティ層 (SASL) メカニズム
• draft-melnikov-scram-sha3-512、SCRAM-SHA3-512、および SCRAM-SHA3-512-PLUS シンプル認証およびセキュリティ層 (SASL) メカニズム
• draft-melnikov-scram-bis、ソルトチャレンジレスポンス認証メカニズム (SCRAM) SASL および GSS-API メカニズム
• draft-ietf-kitten-scram-2fa、2 要素認証のための Salted Challenge Response (SCRAM) の拡張
• draft-melnikov-sasl2、拡張可能な簡易認証およびセキュリティ層 (SASL)
• 現状、SCRAM SASL サポートの詳細