Station-to-Station-Protokoll (STS)

Das Station-to-Station-Protokoll (STS) (Diffie, van Oorschot, Wiener, 1992) wurde entwickelt, um eine authentifizierte Schlüsselvereinbarung ohne vertrauenswürdige dritte Partei zu ermöglichen. Ein reiner Diffie-Hellman-Schlüsselaustausch ist nicht authentifiziert: Ein Man-in-the-Middle-Angreifer kann die eigenen DH-Werte einschleusen und getrennte Sitzungen mit beiden Parteien aufbauen, die glauben, einen gemeinsamen Schlüssel zu besitzen. STS kombiniert DH mit digitalen Signaturen und Public-Key-Zertifikaten, um eine gegenseitige Authentifizierung zu ermöglichen. Die Parteien authentifizieren sich, indem sie den DH-Protokollverlauf signieren und dadurch den Sitzungsschlüssel an ihre Identitäten binden. STS hat das Design von IKE (Internet Key Exchange für IPsec) und SSH direkt beeinflusst.

Das STS-Protokoll läuft wie folgt ab. Alice und Bob einigen sich auf eine DH-Gruppe (Primzahl p, Generator g). (1) Alice sendet g^a mod p an Bob. (2) Bob sendet g^b mod p, Cert_B, Sig_B{g^b, g^a} an Alice. Bob signiert die Verkettung beider DH-Werte mit seinem privaten Schlüssel. (3) Alice verifiziert Bobs Zertifikat und Signatur und sendet anschließend Cert_A, Sig_A{g^a, g^b}, verschlüsselt unter dem Sitzungsschlüssel K = (g^ab mod p). Alices Identität und Signatur sind verschlüsselt, wodurch Alices Identität geschützt wird – passive Lauscher können Alice nicht mit dieser Sitzung in Verbindung bringen. Beide Parteien berechnen K = g^ab mod p und sind durch die Signaturen gegenseitig authentifiziert.

Der Vergleich von STS mit nicht authentifiziertem DH zeigt, was durch Authentifizierung zusätzlich erreicht wird. Beim reinen DH fängt Mallory g^a und g^b ab, ersetzt g^b gegenüber Alice durch g^m und gegenüber Bob ebenfalls durch g^m und etabliert so K1 = g^am und K2 = g^bm. Mallory entschlüsselt den gesamten Datenverkehr. Bei STS signiert Bob {g^b, g^a} – diese Signatur bezieht sich auf genau die DH-Werte dieser Sitzung. Selbst wenn Mallory g^b durch g^m ersetzt, kann Mallory keine gültige Signatur mit Bobs Zertifikatsschlüssel fälschen. Alice weist die Sitzung zurück. Die zentrale Erkenntnis: Bei der Authentifizierung eines Schlüsselaustauschs muss der gesamte DH-Protokollverlauf abgedeckt sein, nicht nur Identitätsangaben.

STS erreicht Perfect Forward Secrecy (PFS), weil der Sitzungsschlüssel aus flüchtigen DH-Werten (g^a, g^b) abgeleitet wird, die nach der Sitzung verworfen werden. Selbst wenn Bobs langfristiger Signaturschlüssel später kompromittiert wird, können zuvor aufgezeichnete STS-Sitzungen nicht entschlüsselt werden – der Angreifer benötigt die flüchtigen DH-Exponenten a und b, die nie gespeichert wurden. Dies ist dieselbe Eigenschaft, die bei TLS mit ECDHE-Chiffrensammlungen geschätzt wird. Ohne flüchtiges DH (beispielsweise bei einem RSA-Schlüsseltransport, bei dem der Sitzungsschlüssel mit dem statischen RSA-Schlüssel des Servers verschlüsselt wird) entschlüsselt die Kompromittierung des langfristigen Schlüssels alle vergangenen Sitzungen.

STS verschlüsselt in Schritt 3 Alices Zertifikat und Signatur und schützt dadurch die Identität der Antwortenden vor passiven Lauschern. Ein passiver Beobachter sieht nur Alices DH-Wert und Bobs Zertifikat, das Bob in Schritt 2 im Klartext sendet. Alices Identität bleibt vor passivem Abhören verborgen. Aktive Angreifer, die einen Man-in-the-Middle-Angriff durchführen, werden durch das Fehlschlagen der Signaturprüfung erkannt. Diese Asymmetrie (die Identität der Initiatorin wird dem aktiven Angreifer offengelegt, während die Identität des Antwortenden vor passiven Lauschern geschützt wird) ist ein bewusster Designkompromiss – ein vollständiger Identitätsschutz beider Parteien gegenüber aktiven Angreifern erfordert zusätzliche Protokollkomplexität (den Vorab-Austausch von DH-Werten oder die Verwendung anonymer Gruppenelemente).

IKE (Internet Key Exchange), das Schlüsselverwaltungsprotokoll für IPsec, ist direkt aus STS abgeleitet. IKEv1 (RFC 2409) implementierte eine STS-ähnliche Signaturauthentifizierung in seinem Main Mode. IKEv2 (RFC 7296) ist eine übersichtlichere Neuentwicklung mit vier Nachrichtenabläufen: IKE_SA_INIT (DH-Austausch, Nonces), IKE_AUTH (Identität, Zertifikat, Signatur über den Protokollverlauf von IKE_SA_INIT). Das Signaturformat lautet AUTH = PRF(SK_pi, transcript) für PSK oder eine digitale Signatur über die IKE_SA_INIT-Oktette bei der zertifikatsbasierten Authentifizierung. IKEv2 unterstützt außerdem das Extensible Authentication Protocol (EAP) für die Legacy-passwortbasierte Authentifizierung, ähnlich wie STS verschiedene Authentifizierungsmethoden unterstützt.

Die Schlüsselauthentifizierung von SSH verwendet einen Mechanismus, der Schritt 3 von STS ähnelt. Nach dem DH-Schlüsselaustausch (SSH_MSG_KEXDH_REPLY enthält den öffentlichen Schlüssel des Servers, den DH-Wert und eine Signatur über den Austausch-Hash) verifiziert der Client den Hostschlüssel des Servers. Bei der Clientauthentifizierung signiert der Client für SSH_MSG_USERAUTH_REQUEST mit der Methode publickey {session_id, username, service, method, key_algo, public_key} mit seinem privaten Schlüssel. Die session_id wird aus dem DH-Protokollverlauf abgeleitet und bindet die Authentifizierung an genau diese Sitzung – dadurch wird die sitzungsübergreifende Fälschung verhindert, die NS plagte. SSH verwendet standardmäßig keine Zertifikate, unterstützt sie für umfangreiche Bereitstellungen jedoch über ssh-keygen -s (Zertifikatsignierung).

STS gehört zur SIGMA-Familie (SIGn-and-MAc) authentifizierter Schlüsselvereinbarungsprotokolle (AKE), die von Hugo Krawczyk formalisiert wurde. SIGMA ergänzt STS um einen MAC: Jede Partei signiert den Protokollverlauf und versieht ihre Identität unter dem Sitzungsschlüssel mit einem MAC: MAC(K, identity). Der MAC bindet die Identität an den Sitzungsschlüssel und verhindert einen bestimmten Angriff, bei dem ein Angreifer Signaturen aus verschiedenen Sitzungen miteinander verknüpfen kann. SIGMA-I (Identität des Initiators geschützt), SIGMA-R (Identität des Antwortenden geschützt) und SIGMA-0 (kein Identitätsschutz) sind Varianten. IKEv2 und X3DH von Signal sind Protokolle der SIGMA-Familie. Der SIGMA-Formalismus liefert einen strengen Sicherheitsbeweis für STS-ähnliche Entwürfe.

STS ist anfällig für Key Compromise Impersonation (KCI): Wenn Alices langfristiger Schlüssel kompromittiert wird, kann ein Angreifer sich in einer neuen Sitzung Alice gegenüber als beliebige Partei ausgeben (weil der Angreifer Alices Signatur für jeden beliebigen Protokollverlauf fälschen kann). Das bedeutet, dass die Kompromittierung des Schlüssels einer Partei einem Angreifer ermöglicht, sich gegenüber dieser Partei als andere Parteien auszugeben. KCI ist signaturbasierten AKE-Protokollen inhärent – der Schutz davor erfordert, dass der Sitzungsschlüssel von den Beiträgen beider Parteien so abhängt, dass die kompromittierte Partei keinen Ersatz einschleusen kann. HMQV (Hashed Menezes-Qu-Vanstone) und NAXOS bieten KCI-Resistenz, allerdings um den Preis zusätzlicher Komplexität.

STS bietet Nichtabstreitbarkeit: Die Signaturen beweisen mit kryptografischer Gewissheit, wer was gesagt hat. Das ist manchmal unerwünscht – in privaten Gesprächen möchten die Beteiligten möglicherweise nicht, dass kryptografische Beweise ihrer Aussagen vor Gericht vorgelegt werden können. Off-the-Record-Messaging (OTR) und der Double Ratchet von Signal bieten Abstreitbarkeit: Statt Nachrichten zu signieren, verwenden sie MAC-Schlüssel, die sowohl der Absender als auch der Empfänger besitzen. Nach dem Gespräch können beide behaupten, die jeweils andere Partei habe die Nachrichten gefälscht, da beide den Schlüssel zur Erzeugung der MACs besitzen. Der Kompromiss: Abstreitbarkeit verzichtet auf Nichtabstreitbarkeit. STS-ähnliche Entwürfe eignen sich dort, wo Verantwortlichkeit erforderlich ist; OTR und Signal dort, wo Abstreitbarkeit wichtig ist.

Die Sicherheit von STS wurde im Originalpapier informell analysiert, aber von Bellare und Rogaway (1993, 1994) in ihrem wegweisenden AKE-Sicherheitsmodell formal bewiesen. Sie definierten, was es bedeutet, dass ein Schlüsselaustauschprotokoll sicher ist: Sitzungsschlüssel müssen von Zufallswerten ununterscheidbar sein, selbst wenn der Angreifer Parteien registrieren, Sitzungsschlüssel offenlegen, langfristige Schlüssel offenlegen (mit Ausnahme des Zielschlüssels) und das Netzwerk kontrollieren kann. Dieses simulationsbasierte Sicherheitsmodell, das von Canetti-Krawczyk und später durch UC (Universal Composability) erweitert wurde, ist heute Standard für den Sicherheitsbeweis von AKE-Protokollen. Für TLS 1.3, Signal und Noise existieren Varianten dieses Modells entsprechende formale Beweise.

Warum verlangt STS, dass beide DH-Werte (g^a und g^b) in das signierte Transkript aufgenommen werden?

STS verbindet einen ephemeren DH-Schlüsselaustausch mit digitalen Signaturen, um eine authentifizierte Schlüsselvereinbarung ohne eine TTP zu ermöglichen. Beide Parteien signieren das DH-Transkript und binden damit die Authentifizierung an die Sitzung. STS bietet Forward Secrecy (ephemeres DH), gegenseitige Authentifizierung (Signaturen) und den Schutz der Identität des Responders (Alices Daten werden vor dem Senden verschlüsselt). STS hat IKEv2 und die SSH-Schlüsselauthentifizierung direkt beeinflusst. SIGMA formalisiert STS mit Identitäts-MACs und Sicherheitsnachweisen. KCI ist eine inhärente Schwachstelle von STS, die durch HMQV/NAXOS abgemildert wird. Abstreitbarkeit (wie bei Signal) erfordert, Signaturen für die Authentizität auf Nachrichtenebene durch MACs zu ersetzen.