Aller au contenu principal

5. Structures de données et calculs

Cette section spécifie les structures de données et les calculs utilisés par les mécanismes de clés basés sur ECC spécifiés dans les trois sections précédentes. Le langage de présentation utilisé ici est le même que celui utilisé dans TLS. Comme cette spécification étend TLS, ces descriptions doivent être fusionnées avec celles de la spécification TLS et toutes les autres qui étendent TLS. Cela signifie que les types enum peuvent ne pas spécifier toutes les valeurs possibles, et les structures avec plusieurs formats choisis par une clause select() peuvent ne pas indiquer tous les cas possibles.

5.1. Extensions Client Hello​

Cette section spécifie deux extensions TLS qui peuvent être incluses avec le message ClientHello comme décrit dans [RFC4366] : l'extension Supported Elliptic Curves et l'extension Supported Point Formats.

Quand ces extensions sont envoyées :

Les extensions DEVRAIENT (SHOULD) être envoyées avec tout message ClientHello qui propose des suites de chiffrement ECC.

Signification de ces extensions :

Ces extensions permettent à un client d'énumérer les courbes elliptiques qu'il supporte et/ou les formats de points qu'il peut analyser.

Structure de ces extensions :

La structure générale des extensions TLS est décrite dans [RFC4366], et cette spécification ajoute deux types à ExtensionType.

   enum {
       elliptic_curves(10),
       ec_point_formats(11)
   } ExtensionType;

  • elliptic_curves (Extension Supported Elliptic Curves) : Indique l'ensemble des courbes elliptiques supportées par le client. Pour cette extension, le champ opaque extension_data contient NamedCurveList. Voir section 5.1.1 pour les détails.

  • ec_point_formats (Extension Supported Point Formats) : Indique l'ensemble des formats de points que le client peut analyser. Pour cette extension, le champ opaque extension_data contient ECPointFormatList. Voir section 5.1.2 pour les détails.

Actions de l'expéditeur :

Un client qui propose des suites de chiffrement ECC dans son message ClientHello ajoute ces extensions (ainsi que d'autres éventuelles), énumérant les courbes qu'il supporte et les formats de points qu'il peut analyser. Les clients DEVRAIENT (SHOULD) envoyer à la fois l'extension Supported Elliptic Curves et l'extension Supported Point Formats. Si l'extension Supported Point Formats est effectivement envoyée, elle DOIT (MUST) contenir la valeur 0 (non compressé) comme l'un des éléments de la liste des formats de points.

Actions du destinataire :

Un serveur qui reçoit un ClientHello contenant l'une ou les deux de ces extensions DOIT (MUST) utiliser les capacités énumérées du client pour guider sa sélection d'une suite de chiffrement appropriée. L'une des suites de chiffrement ECC proposées ne doit être négociée que si le serveur peut réussir à compléter la poignée de main tout en utilisant les courbes et les formats de points supportés par le client (cf. Sections 5.3 et 5.4).

NOTE : Un serveur participant à un échange de clés ECDHE_ECDSA peut utiliser différentes courbes pour la clé ECDSA ou EdDSA dans son certificat et pour la clé ECDH éphémère dans le message ServerKeyExchange. Le serveur DOIT (MUST) considérer les extensions dans les deux cas.

Si un serveur ne comprend pas l'extension Supported Elliptic Curves, ne comprend pas l'extension Supported Point Formats, ou est incapable de compléter la poignée de main ECC tout en se limitant aux courbes et formats de points énumérés, il NE DOIT PAS (MUST NOT) négocier l'utilisation d'une suite de chiffrement ECC. Selon les autres suites de chiffrement proposées par le client et supportées par le serveur, cela peut entraîner une alerte d'échec de poignée de main fatal en raison de l'absence de suites de chiffrement communes.

5.1.1. Extension Supported Elliptic Curves​

La RFC 4492 définissait 25 courbes différentes dans le registre NamedCurve (maintenant renommé registre "TLS Supported Groups", bien que l'énumération ci-dessous soit toujours nommée NamedCurve) pour une utilisation dans TLS. Seules trois ont été beaucoup utilisées. Cette spécification rend obsolète le reste (avec les numéros 1-22). Cette spécification rend également obsolètes les courbes explicites avec les identifiants 0xFF01 et 0xFF02. Elle ajoute également les nouvelles courbes définies dans [RFC7748]. Le résultat final est le suivant :

        enum {
            deprecated(1..22),
            secp256r1 (23), secp384r1 (24), secp521r1 (25),
            x25519(29), x448(30),
            reserved (0xFE00..0xFEFF),
            deprecated(0xFF01..0xFF02),
            (0xFFFF)
        } NamedCurve;

Notez que d'autres spécifications ont depuis ajouté d'autres valeurs à cette énumération. Certaines de ces valeurs ne sont pas du tout des courbes, mais des groupes de corps finis. Voir [RFC7919].

secp256r1, etc : Indique le support de la courbe nommée ou des groupes correspondants. Les courbes nommées secp256r1, secp384r1 et secp521r1 sont spécifiées dans SEC 2 [SECG-SEC2]. Ces courbes sont également recommandées dans ANSI X9.62 [ANSI.X9-62.2005] et FIPS 186-4 [FIPS.186-4]. Le reste de ce document fait référence à ces trois courbes comme les "courbes NIST" car elles ont été initialement normalisées par le National Institute of Standards and Technology. Les courbes x25519 et x448 sont définies dans [RFC7748]. Les valeurs 0xFE00 à 0xFEFF sont réservées pour un usage privé.

Le prédécesseur de ce document supportait également des courbes explicites définies sur des nombres premiers et char2, mais celles-ci sont rendues obsolètes par cette spécification.

L'espace de noms NamedCurve (maintenant intitulé "TLS Supported Groups") est maintenu par l'IANA. Voir la section 9 pour des informations sur la manière dont les nouvelles assignations de valeurs sont ajoutées.

        struct {
            NamedCurve named_curve_list<2..2^16-1>
        } NamedCurveList;

Les éléments dans named_curve_list sont ordonnés selon les préférences du client (choix favori en premier).

À titre d'exemple, un client qui ne supporte que secp256r1 (alias NIST P-256 ; valeur 23 = 0x0017) et secp384r1 (alias NIST P-384 ; valeur 24 = 0x0018) et préfère utiliser secp256r1 inclurait une extension TLS constituée des octets suivants. Notez que les deux premiers octets indiquent le type d'extension (Extension Supported Elliptic Curves) :

        00 0A 00 06 00 04 00 17 00 18

5.1.2. Extension Supported Point Formats​

        enum {
            uncompressed (0),
            deprecated (1..2),
            reserved (248..255)
        } ECPointFormat;
        struct {
            ECPointFormat ec_point_format_list<1..2^8-1>
        } ECPointFormatList;

Trois formats de points étaient inclus dans la définition de ECPointFormat ci-dessus. Cette spécification rend obsolète tout sauf le format de point non compressé. Les implémentations de ce document DOIVENT (MUST) supporter le format non compressé pour toutes leurs courbes supportées et NE DOIVENT PAS (MUST NOT) supporter d'autres formats pour les courbes définies dans cette spécification. À des fins de rétrocompatibilité, l'extension de liste de formats de points PEUT (MAY) encore être incluse et contenir exactement une valeur : le format de point non compressé (0). La RFC 4492 spécifiait que si cette extension est manquante, cela signifie que seul le format de point non compressé est supporté, donc l'interopérabilité avec les implémentations qui supportent le format non compressé devrait fonctionner avec ou sans l'extension.

Si le client envoie l'extension et que l'extension ne contient pas le format de point non compressé, et que le client a utilisé l'extension Supported Groups pour indiquer le support de l'une des courbes définies dans cette spécification, alors le serveur DOIT (MUST) interrompre la poignée de main et renvoyer une alerte illegal_parameter.

L'espace de noms ECPointFormat (maintenant intitulé "TLS EC Point Formats") est maintenu par l'IANA. Voir la section 9 pour des informations sur la manière dont les nouvelles assignations de valeurs sont ajoutées.

Un client conforme à cette spécification qui ne supporte aucune autre courbe DOIT (MUST) envoyer les octets suivants ; notez que les deux premiers octets indiquent le type d'extension (Extension Supported Point Formats) :

        00 0B 00 02 01 00

5.1.3. L'extension signature_algorithms et EdDSA​

L'extension signature_algorithms, définie dans la section 7.4.1.4.1 de [RFC5246], annonce les combinaisons d'algorithme de signature et de fonction de hachage que le client supporte. Les formes pures (non pré-hachées) d'EdDSA ne hachent pas les données avant de les signer. Pour cette raison, il n'est pas logique de les combiner avec une fonction de hachage dans l'extension.

Pour la compatibilité binaire sur le fil avec TLS 1.3, nous définissons une nouvelle valeur fictive dans le registre "TLS HashAlgorithm" que nous appelons "Intrinsic" (valeur 8), signifiant que le hachage est intrinsèque à l'algorithme de signature.

Pour représenter ed25519 et ed448 dans l'extension signature_algorithms, la valeur doit être (8,7) et (8,8), respectivement.

5.2. Extension Server Hello​

Cette section spécifie une extension TLS qui peut être incluse avec le message ServerHello comme décrit dans [RFC4366], l'extension Supported Point Formats.

Quand cette extension est envoyée :

L'extension Supported Point Formats est incluse dans un message ServerHello en réponse à un message ClientHello contenant l'extension Supported Point Formats lors de la négociation d'une suite de chiffrement ECC.

Signification de cette extension :

Cette extension permet à un serveur d'énumérer les formats de points qu'il peut analyser (pour la courbe qui apparaîtra dans son message ServerKeyExchange lors de l'utilisation de l'algorithme d'échange de clés ECDHE_ECDSA, ECDHE_RSA ou ECDH_anon).

Structure de cette extension :

L'extension Supported Point Formats du serveur a la même structure que l'extension Supported Point Formats du client (voir section 5.1.2). Les éléments dans ec_point_format_list ici sont ordonnés selon la préférence du serveur (choix favori en premier). Notez que le serveur PEUT (MAY) inclure des éléments qui n'ont pas été trouvés dans la liste du client. Cependant, sans extensions, cette spécification autorise exactement un format de point, donc il n'y a pas vraiment d'opportunité pour des incohérences.

Actions de l'expéditeur :

Un serveur qui sélectionne une suite de chiffrement ECC en réponse à un message ClientHello incluant une extension Supported Point Formats ajoute cette extension (ainsi que d'autres) à son message ServerHello, énumérant les formats de points qu'il peut analyser. L'extension Supported Point Formats, lorsqu'elle est utilisée, DOIT (MUST) contenir la valeur 0 (non compressé) comme l'un des éléments de la liste des formats de points.

Actions du destinataire :

Un client qui reçoit un message ServerHello contenant une extension Supported Point Formats DOIT (MUST) respecter le choix de formats de points du serveur pendant la poignée de main (cf. Sections 5.6 et 5.7). Si aucune extension Supported Point Formats n'est reçue avec le ServerHello, cela équivaut à une extension autorisant uniquement le format de point non compressé.

5.3. Certificat Serveur​

Quand ce message est envoyé :

Ce message est envoyé dans tous les algorithmes d'échange de clés basés sur ECC non anonymes.

Signification de ce message :

Ce message est utilisé pour transmettre authentiquement la clé publique statique du serveur au client. Le tableau suivant montre le type de certificat serveur approprié pour chaque algorithme d'échange de clés. Les clés publiques ECC DOIVENT (MUST) être encodées dans les certificats comme décrit à la section 5.9.

NOTE : Le message Certificate du serveur est capable de transporter une chaîne de certificats. Les restrictions mentionnées dans le tableau 2 s'appliquent uniquement au certificat du serveur (premier de la chaîne).

AlgorithmeType de Certificat Serveur
ECDHE_ECDSALe certificat DOIT (MUST) contenir une clé publique capable de faire de l'ECDSA ou de l'EdDSA.
ECDHE_RSALe certificat DOIT (MUST) contenir une clé publique RSA.

Tableau 2 : Types de Certificats Serveur

Structure de ce message :

Identique au format de certificat TLS.

Actions de l'expéditeur :

Le serveur construit une chaîne de certificats appropriée et la transmet au client dans le message Certificate. Si le client a utilisé une extension Supported Elliptic Curves, la clé publique dans le certificat du serveur DOIT (MUST) respecter le choix de courbes elliptiques du client. Un serveur qui ne peut pas satisfaire cette exigence NE DOIT PAS (MUST NOT) choisir une suite de chiffrement ECC dans son message ServerHello.

Actions du destinataire :

Le client valide la chaîne de certificats, extrait la clé publique du serveur et vérifie que le type de clé est approprié pour l'algorithme d'échange de clés négocié. (Une raison possible d'un échec fatal de la poignée de main est que les capacités du client à gérer les courbes elliptiques et les formats de points sont dépassées ; cf. Section 5.1.)

5.4. Échange de clés serveur​

Quand ce message est envoyé :

Ce message est envoyé lors de l'utilisation des algorithmes d'échange de clés ECDHE_ECDSA, ECDHE_RSA et ECDH_anon.

Signification de ce message :

Ce message est utilisé pour transmettre la clé publique ECDH éphémère du serveur (et les paramètres de domaine de courbe elliptique correspondants) au client.

L'enum ECCurveType avait des valeurs pour les courbes explicites sur les nombres premiers et char2. Ces valeurs sont maintenant obsolètes, il ne reste donc qu'une seule valeur :

Structure de ce message :

        enum {
            deprecated (1..2),
            named_curve (3),
            reserved(248..255)
        } ECCurveType;

La valeur named_curve indique qu'une courbe nommée est utilisée. Cette option est maintenant le seul format restant.

Les valeurs 248 à 255 sont réservées pour un usage privé.

L'espace de noms ECCurveType (maintenant intitulé "TLS EC Curve Types") est maintenu par l'IANA. Voir la section 9 pour des informations sur la manière dont les nouvelles assignations de valeurs sont ajoutées.

La RFC 4492 avait une spécification pour une structure ECCurve et une structure ECBasisType. Ces deux structures sont maintenant omises car elles n'étaient utilisées qu'avec les courbes explicites maintenant obsolètes.

        struct {
            opaque point <1..2^8-1>;
        } ECPoint;

point : C'est la représentation en chaîne d'octets d'un point de courbe elliptique suivant la routine de conversion de la section 4.3.6 de [ANSI.X9-62.2005]. Cette chaîne d'octets peut représenter un point de courbe elliptique au format non compressé, compressé ou hybride, mais cette spécification rend obsolète tout sauf le format non compressé. Pour les courbes NIST, le format est répété à la section 5.4.1 pour plus de commodité. Pour les courbes X25519 et X448, la seule représentation valide est celle spécifiée dans [RFC7748], une représentation de 32 ou 56 octets de la valeur u du point. Cette structure NE DOIT PAS (MUST NOT) être utilisée avec des clés publiques Ed25519 et Ed448.

        struct {
            ECCurveType    curve_type;
            select (curve_type) {
                case named_curve:
                    NamedCurve namedcurve;
            };
        } ECParameters;

curve_type : Ceci identifie le type des paramètres de domaine de la courbe elliptique.

namedCurve : Spécifie un ensemble recommandé de paramètres de domaine de courbe elliptique. Toutes les valeurs de NamedCurve qui font référence à une courbe capable de faire du Diffie-Hellman sont autorisées. Avec l'obsolescence des courbes explicites, cela inclut désormais toutes les valeurs de NamedCurve.

        struct {
            ECParameters    curve_params;
            ECPoint         public;
        } ServerECDHParams;

curve_params : Spécifie les paramètres de domaine de la courbe elliptique associés à la clé publique ECDH.

public : La clé publique ECDH éphémère.

Le message ServerKeyExchange est étendu comme suit.

        enum {
            ec_diffie_hellman
        } KeyExchangeAlgorithm;
  • ec_diffie_hellman : Indique que le message ServerKeyExchange contient une clé publique ECDH.
      select (KeyExchangeAlgorithm) {
          case ec_diffie_hellman:
              ServerECDHParams    params;
              Signature           signed_params;
      } ServerKeyExchange;

  • params : Spécifie la clé publique ECDH et les paramètres de domaine associés.

  • signed_params : Un hachage des params, avec la signature appropriée à ce hachage appliquée. La clé privée correspondant à la clé publique certifiée dans le message Certificate du serveur est utilisée pour signer.

        enum {
            ecdsa(3),
            ed25519(7)
            ed448(8)
        } SignatureAlgorithm;
        select (SignatureAlgorithm) {
           case ecdsa:
                digitally-signed struct {
                    opaque sha_hash[sha_size];
                };
           case ed25519,ed448:
                digitally-signed struct {
                    opaque rawdata[rawdata_size];
                };
        } Signature;
      ServerKeyExchange.signed_params.sha_hash
          SHA(ClientHello.random + ServerHello.random +
                                 ServerKeyExchange.params);
      ServerKeyExchange.signed_params.rawdata
          ClientHello.random + ServerHello.random +
                                 ServerKeyExchange.params;

NOTE : SignatureAlgorithm est "rsa" pour l'algorithme d'échange de clés ECDHE_RSA et "anonymous" pour ECDH_anon. Ces cas sont définis dans TLS. SignatureAlgorithm est "ecdsa" ou "eddsa" pour ECDHE_ECDSA.

Les signatures ECDSA sont générées et vérifiées comme décrit à la section 5.10. SHA, dans le modèle ci-dessus pour sha_hash, peut désigner un algorithme de hachage autre que SHA-1. Selon ANSI X9.62, une signature ECDSA consiste en une paire d'entiers, r et s. L'élément signé numériquement est encodé sous forme d'un vecteur opaque <0..2^16-1>, dont le contenu est l'encodage DER correspondant à la notation ASN.1 suivante.

              Ecdsa-Sig-Value ::= SEQUENCE {
                  r       INTEGER,
                  s       INTEGER
              }

Les signatures EdDSA à la fois dans le protocole et dans les certificats conformes à [RFC8410] sont générées et vérifiées selon [RFC8032]. L'élément signé numériquement est encodé sous forme d'un vecteur opaque <0..2^16-1>, dont le contenu inclut la chaîne d'octets de sortie de l'algorithme de signature EdDSA.

Actions de l'expéditeur :

Le serveur sélectionne des paramètres de domaine de courbe elliptique et une clé publique ECDH éphémère correspondant à ces paramètres selon le schéma ECKAS-DH1 de IEEE 1363 [IEEE.P1363]. Il transmet cette information au client dans le message ServerKeyExchange en utilisant le format défini ci-dessus.

Actions du destinataire :

Le client vérifie la signature (lorsqu'elle est présente) et récupère les paramètres de domaine de courbe elliptique du serveur et la clé publique ECDH éphémère du message ServerKeyExchange. (Une raison possible d'un échec fatal de la poignée de main est que les capacités du client à gérer les courbes elliptiques et les formats de points sont dépassées ; cf. Section 5.1.)

5.4.1. Format de point non compressé pour les courbes NIST​

Ce qui suit représente le format de fil pour représenter ECPoint dans les enregistrements ServerKeyExchange. Le premier octet de la représentation indique la forme, qui peut être compressée, non compressée ou hybride. Cette spécification ne supporte que le format non compressé pour ces courbes. Ceci est suivi par la représentation binaire de la valeur X au format "big-endian" ou "network", suivie de la représentation binaire de la valeur Y au format "big-endian" ou "network". Il n'y a pas de marqueurs de longueur internes, donc chaque représentation numérique occupe autant d'octets que le suggèrent les paramètres de la courbe. Pour P-256, cela signifie que chacun de X et Y utilise 32 octets, remplis de zéros à gauche si nécessaire. Pour P-384, ils prennent 48 octets chacun, et pour P-521, ils prennent 66 octets chacun.

Voici une représentation plus formelle :

             enum {
                 uncompressed(4),
                 (255)
               } PointConversionForm;

             struct {
                 PointConversionForm  form;
                 opaque               X[coordinate_length];
                 opaque               Y[coordinate_length];
             } UncompressedPointRepresentation;

5.5. Demande de certificat​

Quand ce message est envoyé :

Ce message est envoyé lors de la demande d'authentification du client.

Signification de ce message :

Le serveur utilise ce message pour suggérer des méthodes d'authentification client acceptables.

Structure de ce message :

Le message CertificateRequest TLS est étendu comme suit.

           enum {
               ecdsa_sign(64),
               deprecated1(65),  /* was rsa_fixed_ecdh */
               deprecated2(66),  /* was ecdsa_fixed_ecdh */
               (255)
           } ClientCertificateType;
  • ecdsa_sign : Indique que le serveur aimerait utiliser la méthode d'authentification client correspondante spécifiée dans la section 3.

Notez que la RFC 4492 définissait également des certificats RSA et ECDSA qui incluaient une clé publique ECDH fixe. Ces mécanismes ont vu très peu de mise en œuvre, donc cette spécification les rend obsolètes.

Actions de l'expéditeur :

Le serveur décide quelles méthodes d'authentification client il souhaite utiliser et transmet cette information au client en utilisant le format défini ci-dessus.

Actions du destinataire :

Le client détermine s'il possède un certificat approprié pour être utilisé avec l'une des méthodes demandées et s'il doit procéder à l'authentification du client.

5.6. Certificat Client​

Quand ce message est envoyé :

Ce message est envoyé en réponse à une CertificateRequest lorsqu'un client possède un certificat approprié et a décidé de procéder à l'authentification du client. (Notez que si le serveur a utilisé une extension Supported Point Formats, un certificat ne peut être considéré comme approprié pour une utilisation avec la méthode d'authentification ECDSA_sign que si le point de clé publique spécifié dedans est non compressé, car c'est le seul format de point encore supporté.

Signification de ce message :

Ce message est utilisé pour transmettre authentiquement la clé publique statique du client au serveur. Les clés publiques ECC doivent être encodées dans les certificats comme décrit à la section 5.9. Le certificat DOIT (MUST) contenir une clé publique capable de faire de l'ECDSA ou de l'EdDSA.

NOTE : Le message Certificate du client est capable de transporter une chaîne de certificats. Les restrictions mentionnées ci-dessus s'appliquent uniquement au certificat du client (premier de la chaîne).

Structure de ce message :

Identique au format de certificat client TLS.

Actions de l'expéditeur :

Le client construit une chaîne de certificats appropriée et la transmet au serveur dans le message Certificate.

Actions du destinataire :

Le serveur TLS valide la chaîne de certificats, extrait la clé publique du client et vérifie que le type de clé est approprié pour la méthode d'authentification du client.

5.7. Échange de clés client​

Quand ce message est envoyé :

Ce message est envoyé dans tous les algorithmes d'échange de clés. Il contient la clé publique ECDH éphémère du client.

Signification du message :

Ce message est utilisé pour transmettre des données éphémères relatives à l'échange de clés appartenant au client (telles que sa clé publique ECDH éphémère).

Structure de ce message :

Le message ClientKeyExchange TLS est étendu comme suit.

           enum {
               implicit,
               explicit
           } PublicValueEncoding;
  • implicit, explicit : Pour les suites de chiffrement ECC, cela indique si la clé publique ECDH du client est dans le certificat du client ("implicit") ou est fournie, en tant que clé publique ECDH éphémère, dans le message ClientKeyExchange ("explicit"). L'encodage implicit est obsolète et est conservé ici uniquement pour la rétrocompatibilité.
           struct {
               ECPoint ecdh_Yc;
           } ClientECDiffieHellmanPublic;

ecdh_Yc : Contient la clé publique ECDH éphémère du client sous forme d'une chaîne d'octets ECPoint.point, qui peut représenter un point de courbe elliptique au format non compressé.

           struct {
               select (KeyExchangeAlgorithm) {
                   case ec_diffie_hellman: ClientECDiffieHellmanPublic;
               } exchange_keys;
           } ClientKeyExchange;

Actions de l'expéditeur :

Le client sélectionne une clé publique ECDH éphémère correspondant aux paramètres qu'il a reçus du serveur. Le format est le même que dans la section 5.4.

Actions du destinataire :

Le serveur récupère la clé publique ECDH éphémère du client à partir du message ClientKeyExchange et vérifie qu'elle est sur la même courbe elliptique que la clé ECDH du serveur.

5.8. Vérification de certificat​

Quand ce message est envoyé :

Ce message est envoyé lorsque le client envoie un certificat client contenant une clé publique utilisable pour les signatures numériques.

Signification du message :

Ce message contient une signature qui prouve la possession de la clé privée correspondant à la clé publique dans le message Certificate du client.

Structure de ce message :

Le message CertificateVerify TLS et le type de signature sous-jacent sont définis dans les spécifications de base TLS, et ce dernier est étendu ici dans la section 5.4. Pour les cas "ecdsa" et "eddsa", le champ signature dans le message CertificateVerify contient une signature ECDSA ou EdDSA (respectivement) calculée sur les messages de poignée de main échangés jusqu'à présent, exactement similaire à CertificateVerify avec d'autres algorithmes de signature :

           CertificateVerify.signature.sha_hash
               SHA(handshake_messages);
           CertificateVerify.signature.rawdata
               handshake_messages;

Les signatures ECDSA sont calculées comme décrit à la section 5.10, et SHA dans le modèle ci-dessus pour sha_hash peut en conséquence désigner un algorithme de hachage autre que SHA-1. Selon ANSI X9.62, une signature ECDSA consiste en une paire d'entiers, r et s. L'élément signé numériquement est encodé sous forme d'un vecteur opaque <0..2^16-1>, dont le contenu est l'encodage DER [X.690] correspondant à la notation ASN.1 suivante [X.680].

           Ecdsa-Sig-Value ::= SEQUENCE {
               r       INTEGER,
               s       INTEGER
           }

Les signatures EdDSA sont générées et vérifiées selon [RFC8032]. L'élément signé numériquement est encodé sous forme d'un vecteur opaque <0..2^16-1>, dont le contenu inclut la chaîne d'octets de sortie de l'algorithme de signature EdDSA.

Actions de l'expéditeur :

Le client calcule sa signature sur tous les messages de poignée de main envoyés ou reçus à partir du client hello et jusqu'à mais n'incluant pas ce message. Il utilise la clé privée correspondant à sa clé publique certifiée pour calculer la signature, qui est transmise dans le format défini ci-dessus.

Actions du destinataire :

Le serveur extrait la signature du client du message CertificateVerify et vérifie la signature en utilisant la clé publique qu'il a reçue dans le message Certificate du client.

5.9. Certificats à courbe elliptique​

Les certificats X.509 contenant des clés publiques ECC ou signés utilisant ECDSA DOIVENT (MUST) se conformer à [RFC3279] ou une autre RFC qui la remplace ou l'étend. Les certificats X.509 contenant des clés publiques ECC ou signés utilisant EdDSA DOIVENT (MUST) se conformer à [RFC8410]. Les clients DEVRAIENT (SHOULD) utiliser les paramètres de domaine de courbe elliptique recommandés dans ANSI X9.62, FIPS 186-4, et SEC 2 [SECG-SEC2], ou dans [RFC8032].

Les clés EdDSA utilisant l'algorithme Ed25519 DOIVENT (MUST) utiliser l'algorithme de signature ed25519, et les clés Ed448 DOIVENT (MUST) utiliser l'algorithme de signature ed448. Ce document ne définit pas l'utilisation des clés Ed25519ph et Ed448ph avec TLS. Les clés Ed25519, Ed25519ph, Ed448 et Ed448ph NE DOIVENT PAS (MUST NOT) être utilisées avec ECDSA.

5.10. Calculs ECDH, ECDSA et RSA​

Tous les calculs ECDH pour les courbes NIST (y compris la génération de paramètres et de clés ainsi que le calcul du secret partagé) sont effectués selon [IEEE.P1363] en utilisant le schéma ECKAS-DH1 avec la carte d'identité comme fonction de dérivation de clé (KDF) de sorte que le secret pré-maître soit la coordonnée x du point de courbe elliptique du secret partagé ECDH représenté sous forme de chaîne d'octets. Notez que cette chaîne d'octets (Z dans la terminologie IEEE 1363), telle qu'elle est sortie par FE2OSP (Field Element to Octet String Conversion Primitive), a une longueur constante pour tout champ donné ; les zéros en tête trouvés dans cette chaîne d'octets NE DOIVENT PAS (MUST NOT) être tronqués.

(Notez que cette utilisation de la KDF d'identité est une technicité. L'image complète est que l'ECDH est employé avec une KDF non triviale car TLS n'utilise pas directement le secret pré-maître pour autre chose que pour calculer le secret maître. Dans TLS 1.0 et 1.1, cela signifie que la fonction pseudo-aléatoire TLS (PRF) basée sur MD5 et SHA-1 sert de KDF ; dans TLS 1.2, la KDF est déterminée par la suite de chiffrement, et il est concevable que les futures versions TLS ou de nouvelles extensions TLS introduites à l'avenir puissent faire varier ce calcul.)

Un échange de clés ECDHE utilisant X25519 (courbe x25519) se déroule comme suit : (1) chaque partie choisit une clé secrète d uniformément au hasard et calcule la clé publique correspondante x = X25519(d, G) ; (2) les parties échangent leurs clés publiques et calculent un secret partagé comme x_S = X25519(d, x_peer) ; et (3), si l'une ou l'autre des parties obtient x_S tout à zéro, elle DOIT (MUST) interrompre la poignée de main (comme requis par la définition de X25519 et X448). ECDHE pour X448 fonctionne de manière similaire, en remplaçant X25519 par X448 et x25519 par x448. Le secret partagé dérivé est utilisé directement comme secret pré-maître, qui est toujours exactement de 32 octets lorsque ECDHE avec X25519 est utilisé et de 56 octets lorsque ECDHE avec X448 est utilisé.

Tous les calculs ECDSA DOIVENT (MUST) être effectués selon ANSI X9.62 ou ses successeurs. Les données à signer/vérifier sont hachées, et le résultat passe directement par l'algorithme ECDSA sans hachage supplémentaire. Une fonction de hachage sécurisée telle que SHA-256, SHA-384 ou SHA-512 de [FIPS.180-4] DOIT (MUST) être utilisée.

Tous les calculs EdDSA DOIVENT (MUST) être effectués selon [RFC8032] ou ses successeurs. Les données à signer/vérifier sont passées par l'algorithme EdDSA sans hachage (EdDSA passera en interne les données par la fonction "prehash" PH). Le paramètre de contexte pour Ed448 DOIT (MUST) être défini sur la chaîne vide.

La RFC 4492 prévoyait la normalisation d'un mécanisme pour spécifier la fonction de hachage requise dans le certificat, peut-être dans le champ parameters du subjectPublicKeyInfo. Une telle normalisation n'a jamais eu lieu, et par conséquent, SHA-1 est utilisé dans TLS 1.1 et les versions antérieures (sauf pour EdDSA, qui utilise la fonction d'identité). TLS 1.2 a ajouté un paramètre SignatureAndHashAlgorithm à la structure DigitallySigned, permettant ainsi une agilité dans le choix du hachage de signature. Les signatures EdDSA DOIVENT (MUST) avoir un HashAlgorithm de 8 (Intrinsic).

Toutes les signatures RSA doivent être générées et vérifiées selon la section 7.2 de [RFC8017].

5.11. Validation de la clé publique​

Avec les courbes NIST, chaque partie DOIT (MUST) valider la clé publique envoyée par son pair dans les messages ClientKeyExchange et ServerKeyExchange. Une partie réceptrice DOIT (MUST) vérifier que les paramètres x et y de la valeur publique du pair satisfont l'équation de la courbe, y^2 = x^3 + ax + b mod p. Voir la section 2.3 de [Menezes] pour les détails. Ne pas le faire permet aux attaquants d'obtenir des informations sur la clé privée au point qu'ils peuvent récupérer la clé privée entière en quelques requêtes si cette clé n'est pas vraiment éphémère.

Avec X25519 et X448, une partie réceptrice DOIT (MUST) vérifier si le secret pré-maître calculé est la valeur tout à zéro et interrompre la poignée de main si c'est le cas, comme décrit au chapitre 6 de [RFC7748].

Ed25519 et Ed448 effectuent en interne une validation de clé publique dans le cadre de la vérification de signature.

Dernière mise à jour le