Station-to-Stationプロトコル（STS）

Station-to-Station（STS）プロトコル（Diffie、van Oorschot、Wiener、1992年）は、信頼された第三者なしで認証付き鍵共有を実現するために設計されました。純粋なDiffie-Hellman鍵交換には認証がありません。中間者は自身のDH値を差し替え、双方が相手と鍵を共有していると思い込んだまま、それぞれとの別個のセッションを確立できます。STSはDHとデジタル署名および公開鍵証明書を組み合わせ、相互認証を実現します。双方はDHトランスクリプトに署名することで認証を行い、セッション鍵を自身の識別情報に結び付けます。STSは、IKE（IPsec用のInternet Key Exchange）とSSHの設計に直接影響を与えました。

STSプロトコルは次のように進行します。AliceとBobはDHグループ（素数pと生成元g）に合意します。(1) Aliceはg^a mod pをBobに送信します。(2) Bobはg^b mod p、Cert_B、Sig_B{g^b, g^a}をAliceに送信します。Bobは自身の秘密鍵を使って、両方のDH値を連結したものに署名します。(3) AliceはBobの証明書と署名を検証し、セッション鍵K = (g^ab mod p)で暗号化したCert_A、Sig_A{g^a, g^b}を送信します。Aliceの識別情報と署名は暗号化されるため、Aliceの識別情報が保護され、受動的な盗聴者はAliceをこのセッションと結び付けられません。双方はK = g^ab mod pを計算し、署名によって相互認証されます。

STSと未認証DHを比較すると、認証によって何が加わるのかが分かります。通常のDHでは、Malloryがg^aとg^bを傍受し、Aliceにはg^mを、Bobにもg^mを差し替えて、K1 = g^amとK2 = g^bmを確立します。Malloryはすべての通信を復号できます。STSでは、Bobが{g^b, g^a}に署名します。この署名は、このセッションで使用された正確なDH値に対するものです。Malloryがg^bをg^mに差し替えても、MalloryはBobの証明書鍵による有効な署名を偽造できません。Aliceはセッションを拒否します。重要なのは、鍵交換における認証では、単なる識別情報の主張ではなく、DHトランスクリプトを対象にしなければならないということです。

STSは、セッション鍵が一時的なDH値（g^a、g^b）から導出され、それらがセッション後に破棄されるため、完全前方秘匿性（PFS）を実現します。Bobの長期署名鍵が後から漏洩しても、過去に記録されたSTSセッションを復号することはできません。攻撃者には一時的なDH指数aとbが必要ですが、それらは一度も保存されていないためです。これは、ECDHE暗号スイートを使用するTLSでも重視される性質です。一時的なDHを使用しない場合（たとえば、セッション鍵をサーバーの静的なRSA鍵で暗号化するRSA鍵転送を使用する場合）、長期鍵が漏洩すると過去のすべてのセッションが復号されてしまいます。

STSはステップ3でAliceの証明書と署名を暗号化し、受動的な盗聴者に対する応答者の識別情報保護を実現します。受動的な観測者に見えるのは、AliceのDH値とBobの証明書だけです（Bobはステップ2で証明書を平文で送信します）。そのため、Aliceの識別情報は受動的な盗聴から隠されます。MITM攻撃を仕掛ける能動的な攻撃者は、署名検証の失敗によって検出されます。この非対称性（開始者の識別情報は能動的な攻撃者に明らかになる一方、応答者の識別情報は受動的な盗聴者から保護されること）は、意図的な設計上のトレードオフです。能動的な攻撃者から双方の識別情報を完全に保護するには、さらなるプロトコルの複雑化（DH値の事前共有や匿名の群要素の使用）が必要になります。

IPsecの鍵管理プロトコルであるIKE（Internet Key Exchange）は、STSから直接派生したものです。IKEv1（RFC 2409）は、Main ModeでSTS形式の署名認証を実装しました。IKEv2（RFC 7296）は、4つのメッセージフローを持つ、より整理された再設計です。IKE_SA_INITではDH交換とノンスを、IKE_AUTHでは識別情報、証明書、IKE_SA_INITトランスクリプトに対する署名を扱います。署名形式は、PSKの場合はAUTH = PRF(SK_pi, transcript)、証明書認証の場合はIKE_SA_INITのオクテットに対するデジタル署名です。IKEv2は、従来のパスワードベース認証のためのExtensible Authentication Protocol（EAP）にも対応しています。これは、さまざまな認証方式をサポートするSTSと同様です。

SSH鍵認証は、STSのステップ3に似た仕組みを使用します。DH鍵交換の後、SSH_MSG_KEXDH_REPLYにはサーバーの公開鍵、DH値、交換ハッシュに対する署名が含まれ、クライアントはサーバーのホスト鍵を検証します。クライアント認証では、クライアントが秘密鍵を使って{session_id, username, service, method, key_algo, public_key}に署名します（SSH_MSG_USERAUTH_REQUESTのpublickey方式）。session_idはDHトランスクリプトから導出されるため、認証がこの特定のセッションに結び付けられ、NSで問題となったセッション間の偽造を防ぎます。SSHはデフォルトでは証明書を使用しませんが、大規模な環境向けにssh-keygen -s（証明書署名）を通じて対応しています。

STSは、Hugo Krawczykによって形式化された、認証付き鍵交換（AKE）プロトコルのSIGMA（SIGn-and-MAc）ファミリーの一員です。SIGMAはSTSにMACを追加します。各当事者がトランスクリプトに署名し、セッション鍵の下で自身の識別情報に対するMACを計算します：MAC(K, identity)。このMACによって識別情報がセッション鍵に結び付けられ、攻撃者が異なるセッションの署名を関連付けられる特定の攻撃を防ぎます。SIGMA-I（開始者の識別情報を保護）、SIGMA-R（応答者の識別情報を保護）、SIGMA-0（識別情報を保護しない）というバリエーションがあります。IKEv2とSignalのX3DHはSIGMAファミリーのプロトコルです。SIGMAの形式体系によって、STSに似た設計に対する厳密な安全性証明が可能になります。

STSはKey Compromise Impersonation（KCI）に対して脆弱です。Aliceの長期鍵が漏洩すると、攻撃者は新しいセッションでAliceに対して任意の相手になりすませます。攻撃者は、どのようなトランスクリプトに対してもAliceの署名を偽造できるためです。つまり、一方の当事者の鍵が漏洩すると、攻撃者はその当事者に対して他の当事者になりすませます。KCIは署名ベースのAKEプロトコルに inherent な性質です。これを防ぐには、侵害された当事者が差し替えを行えない形で、セッション鍵が双方の寄与に依存する必要があります。HMQV（Hashed Menezes-Qu-Vanstone）とNAXOSは、さらなる複雑さを代償としてKCI耐性を提供します。

STSは否認防止を提供します。署名によって、誰が何を述べたのかを暗号学的に確実に証明できるためです。しかし、これは望ましくない場合もあります。私的な会話では、自分の発言について暗号学的な証拠を法廷で提示可能にしたくない参加者もいるためです。Off-the-Record（OTR）メッセージングとSignalのDouble Ratchetは、否認可能性を提供します。メッセージに署名する代わりに、送信者と受信者の双方が保持するMAC鍵を使用するためです。会話の後、双方が相手によるメッセージの捏造だと主張できます。どちらもMACを生成できる鍵を持っているためです。トレードオフとして、否認可能性は否認防止を犠牲にします。説明責任が必要な場合はSTSに似た設計が、否認可能性が重視される場合はOTRやSignalが適しています。

STSの安全性は原論文で非公式に解析されましたが、BellareとRogaway（1993年、1994年）が画期的なAKE安全性モデルにおいて形式的に証明しました。両者は、攻撃者が当事者を登録し、セッション鍵を明らかにし、長期鍵を明らかにし（対象セッションを除く）、ネットワークを制御できる場合でも、セッション鍵がランダムな値と見分けられないことを、鍵交換プロトコルが安全であることの定義としました。このシミュレーションベースの安全性モデルは、Canetti-Krawczykによって拡張され、その後UC（Universal Composability）へと発展しました。現在では、AKEプロトコルを証明するための標準となっています。TLS 1.3、Signal、Noiseはいずれも、このモデルの派生形における形式証明を持っています。

なぜSTSでは、署名対象のトランスクリプトに両方のDH値（g^aとg^b）を含める必要があるのでしょうか。

STSは、エフェメラルDH鍵交換とデジタル署名を組み合わせることで、TTPなしの認証付き鍵合意を実現します。両者がDHトランスクリプトに署名することで、認証をセッションに結び付けます。STSは、前方秘匿性（エフェメラルDH）、相互認証（署名）、レスポンダーの身元保護（Aliceのデータを送信前に暗号化）を実現します。STSはIKEv2やSSHの鍵認証に直接影響を与えました。SIGMAは、身元MACとセキュリティ証明によってSTSを形式化します。KCIはSTSに内在する弱点であり、HMQV/NAXOSによって緩和されます。Signalのような否認可能性を実現するには、メッセージレベルの真正性のために署名をMACへ置き換える必要があります。