Aller au contenu principal

2. Algorithme d'échange de clés

Ce document définit trois nouveaux algorithmes d'échange de clés basés sur ECC pour TLS. Tous utilisent l'ECDH éphémère (ECDHE) pour calculer le secret pré-maître TLS, et ils ne diffèrent que par le mécanisme (le cas échéant) utilisé pour les authentifier. La dérivation du secret maître TLS à partir du secret pré-maître et la génération subséquente des clés de chiffrement en masse/MAC et des vecteurs d'initialisation sont indépendantes de l'algorithme d'échange de clés et ne sont pas affectées par l'introduction de l'ECC.

Le tableau 1 résume les nouveaux algorithmes d'échange de clés. Tous ces algorithmes d'échange de clés assurent la confidentialité persistante (forward secrecy) si et seulement si des clés éphémères fraîches sont générées et utilisées, et également détruites après usage.

AlgorithmeDescription
ECDHE_ECDSAECDH éphémère avec signatures ECDSA ou EdDSA.
ECDHE_RSAECDH éphémère avec signatures RSA.
ECDH_anonECDH éphémère anonyme, pas de signatures.

Tableau 1 : Algorithmes d'échange de clés ECC

Ces échanges de clés sont analogues à DHE_DSS, DHE_RSA et DH_anon, respectivement.

Avec ECDHE_RSA, un serveur peut réutiliser son certificat RSA existant et se conformer facilement aux préférences de courbe elliptique d'un client contraint (voir section 4). Cependant, le coût de calcul encouru par un serveur est plus élevé pour ECDHE_RSA que pour l'échange de clés RSA traditionnel, qui ne fournit pas de confidentialité persistante.

L'algorithme d'échange de clés anonyme ne fournit pas d'authentification du serveur ou du client. Comme d'autres échanges de clés TLS anonymes, il est sujet aux attaques de l'homme du milieu. Les applications utilisant TLS avec cet algorithme DEVRAIENT (SHOULD) fournir une authentification par d'autres moyens.

          Client                                        Serveur
          ------                                        -------
          ClientHello          -------->
                                                   ServerHello
                                                  Certificate*
                                            ServerKeyExchange*
                                          CertificateRequest*+
                               <--------       ServerHelloDone
          Certificate*+
          ClientKeyExchange
          CertificateVerify*+
          [ChangeCipherSpec]
          Finished             -------->
                                            [ChangeCipherSpec]
                               <--------              Finished
          Données Applicatives <------->  Données Applicatives

               * message non envoyé sous certaines conditions
               + message non envoyé sauf si l'authentification client
                 est souhaitée

Figure 1 : Flux de messages dans une poignée de main TLS 1.2 complète

La figure 1 montre tous les messages impliqués dans le protocole d'établissement de clé TLS (alias poignée de main complète). L'ajout de l'ECC a un impact direct uniquement sur le ClientHello, le ServerHello, le message Certificate du serveur, le ServerKeyExchange, le ClientKeyExchange, le CertificateRequest, le message Certificate du client et le CertificateVerify. Ensuite, nous décrivons l'algorithme d'échange de clés ECC plus en détail en termes de contenu et de traitement de ces messages. Pour faciliter l'exposé, nous reportons la discussion sur l'authentification du client et les messages associés (identifiés par un '+' dans la Figure 1) à la section 3 et sur les extensions optionnelles spécifiques à l'ECC (qui impactent les messages Hello) à la section 4.

2.1. ECDHE_ECDSA​

Dans ECDHE_ECDSA, le certificat du serveur DOIT (MUST) contenir une clé publique capable de faire de l'ECDSA ou de l'EdDSA.

Le serveur envoie sa clé publique ECDH éphémère et une spécification de la courbe correspondante dans le message ServerKeyExchange. Ces paramètres DOIVENT (MUST) être signés avec ECDSA ou EdDSA en utilisant la clé privée correspondant à la clé publique dans le certificat du serveur.

Le client génère une paire de clés ECDH sur la même courbe que la clé ECDH éphémère du serveur et envoie sa clé publique dans le message ClientKeyExchange.

Le client et le serveur effectuent tous deux une opération ECDH (voir section 5.10) et utilisent le secret partagé résultant comme secret pré-maître.

2.2. ECDHE_RSA​

Cet algorithme d'échange de clés est le même que ECDHE_ECDSA, sauf que le certificat du serveur DOIT (MUST) contenir une clé publique RSA autorisée pour la signature et que la signature dans le message ServerKeyExchange doit être calculée avec la clé privée RSA correspondante.

2.3. ECDH_anon​

NOTE : Bien que le nom commence par "ECDH_" (pas de E), la clé utilisée dans ECDH_anon est éphémère tout comme la clé dans ECDHE_RSA et ECDHE_ECDSA. La dénomination suit l'exemple de DH_anon, où la clé est également éphémère mais le nom ne le reflète pas.

Dans ECDH_anon, les messages Certificate du serveur, CertificateRequest, Certificate du client et CertificateVerify NE DOIVENT PAS (MUST NOT) être envoyés.

Le serveur DOIT (MUST) envoyer une clé publique ECDH éphémère et une spécification de la courbe correspondante dans le message ServerKeyExchange. Ces paramètres NE DOIVENT PAS (MUST NOT) être signés.

Le client génère une paire de clés ECDH sur la même courbe que la clé ECDH éphémère du serveur et envoie sa clé publique dans le message ClientKeyExchange.

Le client et le serveur effectuent tous deux une opération ECDH et utilisent le secret partagé résultant comme secret pré-maître. Tous les calculs ECDH sont effectués comme spécifié dans la section 5.10.

2.4. Algorithmes dans les chaînes de certificats​

Cette spécification n'impose pas de restrictions sur les schémas de signature utilisés n'importe où dans la chaîne de certificats. La version précédente de ce document exigeait que les signatures correspondent, mais cette restriction, provenant des versions TLS précédentes, est levée ici car elle l'avait été dans la RFC 5246.

Dernière mise à jour le