Protocole station à station (STS)

Le protocole Station-to-Station (STS) (Diffie, van Oorschot, Wiener, 1992) a été conçu pour fournir un accord de clés authentifié sans tiers de confiance. L'échange de clés Diffie-Hellman pur n'est pas authentifié : un homme du milieu peut remplacer ses propres valeurs DH, établissant des sessions distinctes avec chacune des parties, qui croient partager une clé. STS combine DH avec des signatures numériques et des certificats de clé publique pour fournir une authentification mutuelle. Les parties s'authentifient en signant la transcription DH, ce qui lie la clé de session à leurs identités. STS a directement influencé la conception de IKE (Internet Key Exchange pour IPsec) et de SSH.

Le protocole STS se déroule comme suit. Alice et Bob se mettent d'accord sur un groupe DH (nombre premier p, générateur g). (1) Alice envoie g^a mod p à Bob. (2) Bob envoie g^b mod p, Cert_B, Sig_B{g^b, g^a} à Alice. Bob signe la concaténation des deux valeurs DH à l'aide de sa clé privée. (3) Alice vérifie le certificat et la signature de Bob, puis envoie Cert_A, Sig_A{g^a, g^b} chiffrés avec la clé de session K = (g^ab mod p). L'identité et la signature d'Alice sont chiffrées, ce qui assure la protection de l'identité d'Alice — les observateurs passifs ne peuvent pas associer Alice à cette session. Les deux parties calculent K = g^ab mod p et s'authentifient mutuellement au moyen des signatures.

Comparer STS à DH non authentifié montre ce qu'apporte l'authentification. Avec DH simple, Mallory intercepte g^a et g^b, remplace g^m auprès d'Alice et g^m auprès de Bob, et établit K1 = g^am et K2 = g^bm. Mallory déchiffre tout le trafic. Dans STS, Bob signe {g^b, g^a} — cette signature porte sur les valeurs DH exactes de cette session. Même si Mallory remplace g^b par g^m, il ne peut pas forger une signature valide avec la clé associée au certificat de Bob. Alice rejette la session. Idée essentielle : l'authentification dans un échange de clés doit couvrir la transcription DH, et pas seulement les déclarations d'identité.

STS assure la confidentialité persistante parfaite (PFS), car la clé de session est dérivée de valeurs DH éphémères (g^a, g^b), qui sont supprimées après la session. Même si la clé de signature à long terme de Bob est compromise ultérieurement, les sessions STS précédemment enregistrées ne peuvent pas être déchiffrées — l'attaquant aurait besoin des exposants DH éphémères a et b, qui n'ont jamais été conservés. C'est la même propriété que celle recherchée dans TLS avec les suites de chiffrement ECDHE. Sans DH éphémère (par exemple, avec un transport de clé RSA où la clé de session est chiffrée avec la clé RSA statique du serveur), la compromission de la clé à long terme permet de déchiffrer toutes les sessions passées.

STS chiffre le certificat et la signature d'Alice à l'étape 3, ce qui protège l'identité de l'initiatrice contre les observateurs passifs. Un observateur passif ne voit que la valeur DH d'Alice et le certificat de Bob (que Bob envoie en clair à l'étape 2). L'identité d'Alice est ainsi dissimulée à l'écoute passive. Les attaquants actifs qui montent une attaque MITM sont détectés par l'échec de la vérification de la signature. Cette asymétrie (l'identité de l'initiatrice est révélée à l'attaquant actif, celle du répondant est protégée contre l'observateur passif) est un compromis de conception délibéré — une protection complète de l'identité des deux parties contre les attaquants actifs nécessite une complexité supplémentaire du protocole (partage préalable de valeurs DH ou utilisation d'éléments de groupe anonymes).

IKE (Internet Key Exchange), le protocole de gestion des clés pour IPsec, est directement dérivé de STS. IKEv1 (RFC 2409) a mis en œuvre une authentification par signature de type STS dans son mode principal. IKEv2 (RFC 7296) est une refonte plus claire avec quatre flux de messages : IKE_SA_INIT (échange DH, nonces), IKE_AUTH (identité, certificat, signature sur la transcription de IKE_SA_INIT). Le format de signature est AUTH = PRF(SK_pi, transcript) pour une PSK ou une signature numérique sur les octets de IKE_SA_INIT pour l'authentification par certificat. IKEv2 prend également en charge le protocole d'authentification extensible (EAP) pour l'authentification ancienne fondée sur un mot de passe, de manière analogue à la prise en charge par STS de diverses méthodes d'authentification.

L'authentification par clé de SSH utilise un mécanisme semblable à l'étape 3 de STS. Après l'échange de clés DH (SSH_MSG_KEXDH_REPLY contient la clé publique du serveur, la valeur DH et une signature sur le haché de l'échange), le client vérifie la clé d'hôte du serveur. Pour l'authentification du client (SSH_MSG_USERAUTH_REQUEST avec la méthode publickey), le client signe {session_id, username, service, method, key_algo, public_key} à l'aide de sa clé privée. Le session_id est dérivé de la transcription DH, ce qui lie l'authentification à cette session précise et empêche la falsification entre sessions qui affectait NS. SSH n'utilise pas de certificats par défaut, mais les prend en charge via ssh-keygen -s (signature de certificat) pour les déploiements à grande échelle.

STS appartient à la famille SIGMA (SIGn-and-MAc) des protocoles d'échange de clés authentifiés (AKE), formalisée par Hugo Krawczyk. SIGMA ajoute un MAC à STS : chaque partie signe la transcription et calcule un MAC sur son identité avec la clé de session : MAC(K, identity). Le MAC lie l'identité à la clé de session, empêchant une attaque particulière dans laquelle un adversaire peut associer des signatures provenant de sessions différentes. SIGMA-I (identité de l'initiatrice protégée), SIGMA-R (identité du répondant protégée) et SIGMA-0 (aucune protection de l'identité) sont des variantes. IKEv2 et X3DH de Signal sont des protocoles de la famille SIGMA. Le formalisme SIGMA fournit une preuve de sécurité rigoureuse pour les conceptions de type STS.

STS est vulnérable à l'attaque KCI (usurpation après compromission de clé) : si la clé à long terme d'Alice est compromise, un attaquant peut usurper l'identité de n'importe quelle partie auprès d'Alice dans une nouvelle session (car l'attaquant peut forger la signature d'Alice sur n'importe quelle transcription). Cela signifie que la compromission de la clé d'une partie permet à un adversaire d'usurper l'identité d'autres parties auprès de celle-ci. La KCI est inhérente aux protocoles d'échange de clés authentifiés fondés sur les signatures — s'en défendre exige que la clé de session dépende des contributions des deux parties d'une manière qui empêche la partie compromise de faire une substitution. HMQV (Hashed Menezes-Qu-Vanstone) et NAXOS offrent une résistance à la KCI au prix d'une complexité supplémentaire.

STS fournit la non-répudiation : les signatures prouvent avec une certitude cryptographique qui a dit quoi. Cela est parfois indésirable — dans les conversations privées, les participants peuvent ne pas vouloir que la preuve cryptographique de leurs propos puisse être produite devant un tribunal. La messagerie Off-the-Record (OTR) et le Double Ratchet de Signal fournissent le déni plausible : au lieu de signer les messages, ils utilisent des clés MAC détenues à la fois par l'expéditeur et le destinataire. Après la conversation, les deux parties peuvent prétendre que l'autre a fabriqué les messages, puisque chacune détient la clé permettant de produire les MAC. Le compromis est le suivant : le déni plausible sacrifie la non-répudiation. Les conceptions de type STS conviennent là où la responsabilité est requise ; OTR/Signal là où le déni plausible est privilégié.

La sécurité de STS a été analysée de manière informelle dans l'article original, mais a été démontrée formellement par Bellare et Rogaway (1993, 1994) dans leur modèle de sécurité AKE de référence. Ils ont défini ce que signifie la sécurité d'un protocole d'échange de clés : l'indistinguabilité des clés de session par rapport à des clés aléatoires, même lorsque l'adversaire peut enregistrer des parties, révéler des clés de session, révéler des clés à long terme (sauf celle de la session cible) et contrôler le réseau. Ce modèle de sécurité fondé sur la simulation, étendu par Canetti-Krawczyk puis par UC (composabilité universelle), est désormais standard pour démontrer la sécurité des protocoles AKE. TLS 1.3, Signal et Noise disposent tous de preuves formelles dans des variantes de ce modèle.

Pourquoi STS exige-t-il que les deux valeurs DH (g^a et g^b) soient incluses dans la transcription signée ?

STS combine un échange de clés DH éphémères avec des signatures numériques afin de fournir un accord de clés authentifié sans TTP. Les deux parties signent la transcription DH, ce qui lie l'authentification à la session. STS assure la confidentialité persistante (DH éphémère), l'authentification mutuelle (signatures) et la protection de l'identité du répondant (les données d'Alice sont chiffrées avant leur envoi). STS a directement influencé IKEv2 et l'authentification des clés dans SSH. SIGMA formalise STS avec des MAC d'identité et des preuves de sécurité. KCI est une faiblesse inhérente à STS, atténuée par HMQV/NAXOS. La déniabilité, comme dans Signal, exige de remplacer les signatures par des MAC pour assurer l'authenticité au niveau des messages.