Fonctionnement de la cryptographie à courbe elliptique dans TLS 1.3

Quelques avertissements au lecteur:

Afin de simplifier (autant que possible) le processus d'explication et de réduire le volume de publication, il vaut la peine de faire immédiatement une réservation clé - tout ce que nous écrivons sur le côté pratique du problème est correct pour le protocole TLS version 1.3. Cela signifie que bien que votre certificat ECDSA fonctionne, si vous le souhaitez, avec TLS 1.2, la description du processus de prise de contact, des suites de chiffrement et des tests de performance est basée sur la dernière version du protocole TLS - 1.3. Comme vous le savez, cela ne s'applique pas à la description mathématique des algorithmes qui sous-tendent les fondements des systèmes cryptographiques modernes.

Ce matériel n'a pas été écrit par un mathématicien ou même un ingénieur - bien qu'ils aient aidé à ouvrir la voie à travers la jungle mathématique. Un grand merci au personnel de Qrator Labs.

(Courbe elliptique) D iffie- H ellman (Ephémère)

L'héritage Diffie-Hellman du 21e siècle

Naturellement, ce sujet ne commence pas avec Whitfield Diffie et non avec Martin Hellman. Alan Turing et Claude Shannon ont apporté une énorme contribution à la théorie des algorithmes et de la théorie de l'information, ainsi qu'au domaine de la cryptanalyse. Diffie et Hellman, à leur tour, sont officiellement reconnus par les auteurs de l'idée de la cryptographie à clé publique (également appelée asymétrique) - bien qu'il soit désormais connu que des résultats sérieux dans ce domaine ont également été obtenus au Royaume-Uni. Cependant, ils sont restés secrets pendant longtemps - ce qui fait que les deux messieurs mentionnés dans les sous-titres pionniers.

Quoi exactement?

Cela peut sembler drôle, mais jusqu'au 6 novembre 1976, aucune connaissance n'était disponible concernant les systèmes cryptographiques à clé publique. Whitfield Diffie et Martin Hellman (et, en fait, Ralph Merkle) - les mathématiciens, les ingénieurs en informatique et les passionnés, ainsi que les cryptologues ont été les premiers à proposer un concept approprié.

Pendant la Seconde Guerre mondiale, la cryptographie a contribué à garder les informations secrètes et la cryptanalyse a contribué à les divulguer. Les États-Unis et le Royaume-Uni se considéraient comme les plus avancés dans le domaine de la cryptographie. Ces deux pays ont inclus des algorithmes cryptographiques dans la section des armes et ont opposé leur veto à leurs exportations. Dans le même temps, le cryptage disponible et destiné à un usage commercial ou domestique a été assoupli dans ces pays. Pour cette raison, les chercheurs britanniques travaillant sur un système de distribution de clés asymétriques au Government Communications Center (GCHQ) et développant un concept similaire n'ont été reconnus par la communauté qu'en 1997, lorsque les restrictions existantes sur les algorithmes cryptographiques et leur description ont perdu tout leur sens et, dans l'ensemble moralement dépassé.

Pour en revenir à notre paire d'inventeurs - qu'est-ce qui a exactement révolutionné Diffie et Hellman?

Pour expliquer cela, jetons un coup d'œil à l'illustration de la publication originale, qui reflète parfaitement le saut géant dans la compréhension du fonctionnement de la cryptographie - même si ce n'est que théoriquement:

Et maintenant pour ce qui suit:

Ces deux images montrent la principale innovation de Whitfield Diffie et Martin Hellman après des siècles de développement de la cryptographie et de la cryptanalyse - l'établissement d'un secret commun à la suite de calculs d'un certain type.

Regardons une autre image de Wikipedia, où différentes couleurs sont utilisées comme secrets:



Elle explique également bien ce qui se passe. Avant l'innovation Diffie et Hellman, il n'y avait qu'une seule clé commune sous la forme d'un schéma d'établissement de clé commune - elle était utilisée pour crypter et décrypter un message. Si vous souhaitez transférer une telle clé vers le deuxième côté, elle doit être transmise sur le canal initialement protégé. Toutes les limites d'un tel schéma deviennent immédiatement claires - vous avez besoin d'un canal de communication sécurisé (à l'écoute), vous ne pouvez pas utiliser la même clé plus d'une fois , et, idéalement, la longueur de la clé doit correspondre à la longueur du message.

Claude Shannon, dans son ouvrage déclassifié plus tard, «Théorie de la communication dans les systèmes secrets», a prouvé que tous les chiffrements théoriquement incassables devraient avoir les mêmes propriétés qu'un bloc de chiffrement à usage unique - également connu sous le nom de chiffrement Vernam, du nom du créateur de cet algorithme de chiffrement de flux polyalphabétique additif.

Et encore une fois, jetons un coup d'œil à la publication scientifique originale:


Avant d'aller plus loin, posons-nous une question évidemment simple - comment deux personnes, même très développées intellectuellement, ont-elles pu trouver quelque chose d'aussi révolutionnaire dans le domaine appliqué, en particulier compte tenu des énormes succès de la guerre? Très probablement en raison de la combinaison des domaines suivants qui se développaient activement à l'époque:

• Théorie de l'information formulée par Claude Shannon;
• La théorie des algorithmes , qui a été influencée, entre autres, par Alonzo Church, John von Neumann et Alan Turing;
• Et, surtout, la théorie de la calculabilité , basée principalement sur le travail de Turing.

On peut dire que tous ces domaines se sont développés et ont mûri vers la même période du XXe siècle. Diffie et Hellman ont également mentionné Claude Shannon comme une figure qui a influencé leur travail plus que d'autres.

Le concept de «sécurité universelle» par Arjen Lenstra montre combien d'énergie doit être dépensée pour «pirater» un cryptosystème symétrique avec des clés de différentes longueurs. Il s'est avéré que pour casser la clé de 228 bits de l'algorithme basé sur des courbes elliptiques, vous avez besoin d'autant d'énergie qu'il suffit de chauffer toute l'eau de la Terre au point d'ébullition. Cependant, cette affirmation n'est correcte que si nous considérons des algorithmes bien connus et utilisons des équipements modernes, car, à proprement parler, des algorithmes ou des équipements plus efficaces sont possibles, mais leur existence n'est pas encore connue. La clé de 228 bits de l'algorithme EC pour la complexité du piratage est comparable à la clé de 2380 bits dans RSA, mais plus à ce sujet plus tard. Dans cette comparaison, les clés RSA et EC sont utilisées dans un cryptosystème asymétrique, elles peuvent être considérées comme équivalentes à une clé de 128 bits dans un schéma symétrique.

Il est facile d'imaginer que quelque chose de «difficile à calculer» nécessitera beaucoup de temps et d'énergie pour être calculé. Nous avons tendance à penser que les ordinateurs peuvent «compter n'importe quoi», mais il s'avère que c'est loin de la vérité.

Premièrement, il existe des exemples de problèmes insolubles, tels que le problème d'arrêt. Cependant, dans le domaine de la cryptographie, ces tâches ne sont pas utilisées.

Deuxièmement, si nous considérons le temps d'exécution requis par un algorithme particulier, il peut être arbitrairement volumineux. C'est exactement ce que la cryptographie utilise. Une tâche est considérée comme «simple» sur le plan du calcul si le temps nécessaire au fonctionnement de l'algorithme correspondant dépend de la taille des données d'entrée (mesurées en bits) en tant que polynôme: $$$T (n) = O (n ^ k)$ pour certains positifs $$$k$ . Dans la théorie de la complexité de calcul, ces problèmes forment une classe de complexité P. Si le temps d'exécution de l'algorithme croît plus rapidement qu'un polynôme, par exemple, de façon exponentielle, alors une telle tâche est considérée comme «difficile» sur le plan du calcul.

La classe de complexité P comprend des tâches pour lesquelles il existe un algorithme déterministe qui fonctionne en temps polynomial. Une autre classe de complexité est NP (dans laquelle, vraisemblablement, des problèmes «difficiles» existent), qui est un problème de solvabilité - c'est-à-dire un problème nécessitant une réponse par «oui» ou «non», dont l'exactitude de la solution peut être vérifiée - c'est-à-dire, pour prouver la justesse de la solution - en temps polynomial. Vous voyez le mot "preuve" ici? C'est l'endroit où l'on passe aux fonctions unilatérales dont le problème d'inversion appartient à la classe de complexité NP.


Publié par: xkcd

(Fonctions unidirectionnelles (avec entrée secrète))

Par définition, une fonction unidirectionnelle est une fonction qui est facile à calculer pour n'importe quelle entrée, mais difficile à inverser, c'est-à-dire à obtenir l'entrée d'origine avec uniquement le résultat. «Facile» et «difficile» se réfèrent à la théorie de la complexité de calcul mentionnée ci-dessus. Il est intéressant de noter que l'existence de fonctions à sens unique (mathématiquement) n'a pas été prouvée, car une preuve rigoureuse de leur existence prouverait également l'inégalité des classes P et NP, l'un des problèmes du millénaire et un problème ouvert urgent, dont la solution promet une percée algorithmique. Par conséquent, il est nécessaire de garder à l'esprit que presque toute la cryptographie moderne est basée sur des hypothèses non prouvées.

Dans leur publication originale, Diffie et Hellman présentent une nouvelle génération de fonctions unidirectionnelles, les appelant "fonctions unidirectionnelles avec une entrée secrète" - en anglais trappe fonction. En quoi diffèrent-elles des fonctions à sens unique?

Regardons leur explication originale:

Dans un cryptosystème avec une clé publique, le chiffrement et le déchiffrement sont effectués par différentes clés - E et D, respectivement, de sorte que le calcul de D à partir de E est pratiquement impossible (par exemple, nécessitant $$ instructions). La clé de chiffrement E peut être divulguée publiquement sans compromettre la clé D. Cela permet à tout utilisateur du système d'envoyer un message à tout autre utilisateur, chiffré de telle manière que seul le destinataire attendu peut le déchiffrer. <...> La tâche d'authentification, peut-être, est un problème de télécommunication plus grave pour les transactions commerciales, par rapport à la distribution des clés, car c'est elle (l'authentification) qui est au cœur de tout système travaillant avec les contrats et la facturation des paiements.

Habituellement, les caractères cryptographiques Alice et Bob sont utilisés pour expliquer les principes de fonctionnement du cryptosystème (ils visent une communication sécurisée). Alice et Bob conviennent de choisir de grands nombres premiers $$$n$ et $$$g$ tel que $$$1 <g <n$ . Ce choix affecte la sécurité de l'ensemble du circuit. Numéro $$$n$ appelé module doit être simple; de plus, le nombre $$$(n-1) / 2$ devrait également être simple, mais $$$g$ doit être la racine primitive du groupe de résidus modulo $$$n$ ; en plus $$$n$ devrait être suffisamment grand - au moins 512 bits en représentation binaire. De plus, le protocole Diffie-Hellman peut être décrit en cinq étapes simples:

1. Alice choisit $$$x$ (grand premier) et calcule $$$X = g ^ x \ bmod n$
2. Choix de Bob $$$y$ (aussi un grand premier) et calcule $$$Y = g ^ y \ bmod n$
3. Alice envoie $$$X$ Bob, Bob envoie $$$Y$ Alice ( $$$x$ et $$$y$ chacun d'eux reste un secret)
4. Alice calcule $$$k = Y ^ x \ bmod n$
5. Bob calcule $$$k '= X ^ y \ bmod n$

En conséquence, Alice et Bob obtiennent le même résultat dans la construction. $$$k = k '$ - un secret partagé.

Ainsi, une fonction unidirectionnelle avec une entrée secrète est une telle fonction unidirectionnelle qui peut être inversée en ayant une information spéciale appelée «entrée secrète». Cela semble simple, mais dans la pratique, trouver une telle fonction s'est avéré être une tâche non triviale - la première méthode décente s'est avérée être l'ancêtre de toute une famille d'algorithmes basés sur une clé publique nommée RSA par les noms de ses créateurs: Ron Rivesta, Adi Shamira et Leonard Adleman.

RSA

Dans RSA, la complexité de l'inversion d'une fonction est basée sur le fait que la factorisation (factorisation d'un nombre) prend beaucoup plus de temps que la multiplication ou, plus précisément, on peut affirmer qu'aucune méthode de factorisation de grands nombres en temps polynomial n'a été trouvée sur un ordinateur classique, bien qu'elle n'ait pas été Il est prouvé qu'un tel algorithme ne peut pas exister.

Dans RSA, comme dans tout autre système cryptographique à clé publique, il existe deux clés: publique et privée. L'algorithme RSA prend un message d'entrée représenté par une chaîne de bits et lui applique une opération mathématique (élevant à un module de puissance un grand nombre) afin d'obtenir un résultat indiscernable du hasard. Pour le déchiffrement, le résultat est pris et une opération similaire est effectuée pour recevoir le message d'origine. En cryptographie asymétrique, le cryptage est effectué avec une clé publique et le décryptage avec une clé privée.

Comment est-ce possible? Du fait que les valeurs utilisées appartiennent à un groupe cyclique fini (l'ensemble des entiers avec multiplication en arithmétique modulaire). Les ordinateurs ne fonctionnent pas très bien avec des nombres arbitrairement grands, mais la propriété du groupe cyclique est «envelopper» - un nombre supérieur au maximum autorisé est «encapsulé» à une valeur de l'ensemble autorisé. Cela nous permet d'utiliser des clés d'une longueur "pas plus de" un certain nombre de bits. En cryptographie basée sur des courbes elliptiques, des groupes cycliques (multiplicatifs) sont également utilisés, mais sont construits légèrement différemment, comme nous le verrons plus loin.

À un niveau très primitif, tout ce que RSA fait est de prendre deux grands nombres premiers, en les multipliant pour obtenir le soi-disant module. Tous les autres nombres avec lesquels les opérations seront effectuées doivent être compris entre zéro et la valeur du module. Le module lui-même fera partie de la clé publique - sa longueur détermine la longueur de la clé. La deuxième partie de la clé publique est le nombre choisi entre zéro et la valeur de la fonction Euler (les implémentations RSA modernes utilisent la fonction Carmichael au lieu d'Euler) du module, avec quelques restrictions supplémentaires. Enfin, vous pouvez calculer la clé privée en résolvant l'équation modulaire. Pour crypter le message, nous prenons le nombre qui représente le message et le montons simplement à la puissance égale à la valeur de la clé publique, et pour le décrypter - pour recevoir le message d'origine, le hausser à la puissance égale à la valeur de la clé privée. En raison de la nature cyclique du groupe, nous obtenons la même signification.

Aujourd'hui, RSA a deux problèmes principaux, dont l'un est la conséquence de l'autre. À mesure que la longueur de clé augmente, la complexité ne croît pas aussi vite que nous le souhaiterions. En effet, il existe un algorithme de factorisation sous- exponentiel (mais toujours superpolynomial ). Par conséquent, afin de maintenir le niveau de protection nécessaire, la longueur de la clé RSA devrait augmenter un peu plus rapidement que celle de la clé ECC. Pour cette raison, les longueurs de clé RSA les plus courantes aujourd'hui sont assez grandes: 2048 et 3072 bits.

Un peu plus tard, nous verrons sur des figures spécifiques comment la longueur de clé affecte les performances finales du cryptosystème en comparant les certificats signés par Let's Encrypt RSA et ECDSA.

E lliptique C urve Algorithmes de S ignature numérique

À la recherche de fonctions plus fiables avec une entrée secrète, au milieu des années 80, les cryptographes ont utilisé une branche des mathématiques consacrée aux courbes elliptiques.

Il serait trop difficile de décrire tous les détails de la cryptographie sur la base de courbes elliptiques dans un seul texte, nous ne le ferons donc pas. Examinons plutôt une fonction d'entrée secrète unidirectionnelle basée sur des courbes elliptiques et le problème du logarithme discret.

Il existe un grand nombre de documents de révision et des introductions plus détaillées à ce domaine de la cryptographie. Nous tenons à souligner "ECC: une introduction en douceur" par Andrea Corbellini, surtout si vous êtes intéressé par l'appareil.

Nous, dans ce document, nous intéressons à une explication beaucoup plus «simple».
Une courbe elliptique est définie par une équation qui ressemble à ceci: $$$y ^ 2 = x ^ 3 + hache + b$ .

Le deuxième objet est un sous-groupe cyclique sur un champ fini. Les paramètres suivants sont utilisés dans l'algorithme ECC:

• Nombre premier $$$p$ , qui détermine la dimension du champ final;
• Cotes $$$a$ et $$$b$ équations de la courbe elliptique;
• Point de base $$$G$ générer le sous-groupe déjà mentionné;
• Commander $$$n$ sous-groupes;
• Cofacteur $$$h$ sous-groupes.

En conséquence, l' ensemble des paramètres de nos algorithmes est représenté par six $$$(p, a, b, G, n, h)$ .

Les points d'une courbe elliptique appartiennent à un champ fini $$$\ mathbb {F} _p$ où $$$p$ c'est un nombre premier assez grand. Donc, nous avons de nombreux entiers modulo $$$p$ où des opérations telles que l'addition, la soustraction, la multiplication, la prise du contraire sont possibles. L'addition et la multiplication fonctionnent de manière similaire à la façon dont nous l'avons décrit en termes d'arithmétique modulaire de la section RSA (wrap-around).

Comme la courbe est symétrique par rapport à l'axe des x, pour tout point $$$P$ on peut prendre $$$−P$ et obtenir le point opposé. Nous stipulons immédiatement que le point $$$−O$ correspond à zéro, c'est-à-dire $$$−O$ sera simple $$$O$ .

L'ajout de points sur une courbe est défini de telle sorte que, connaissant les points $$$P$ et $$$Q$ , nous pouvons tracer une ligne passant par ces deux points, ainsi qu'un troisième - $$$R$ pour que $$$P + Q = -R$ et $$$P + Q + R = 0$ .

Jetons un coup d'œil à l' illustration illustrée de Mark Hughes :

Nous voyons une ligne droite étirée le long de la surface du tore. La ligne coupe deux points sélectionnés au hasard sur la courbe.



Afin de trouver $$$R$ , nous dessinons une ligne à partir du premier point sélectionné $$$P$ au deuxième $$$Q$ continuer la ligne jusqu'à ce qu'elle croise la courbe au troisième point $$$-R$ .

Après l'intersection, réfléchissez le point par rapport à l'axe des abscisses afin de trouver le point $$$R$ .

La multiplication par un scalaire est déterminée bien évidemment: $$$n \ cdot P = P + P + P + \ points + P$ .

La fonction unidirectionnelle avec une entrée secrète dans ce cas repose sur le problème du logarithme discret pour les courbes elliptiques, et non sur la factorisation, comme c'est le cas avec RSA. Le problème du logarithme discret dans ce cas est formulé comme suit: s'il est connu $$$P$ et $$$Q$ , alors comment trouver $$$k$ tel que $$$Q = k \ cdot P$ ?

Le problème de factorisation (RSA sous-jacent) et le logarithme discret pour les courbes elliptiques (qui sont le fondement de l'ECDSA et de l'ECDH) sont considérés comme difficiles - en d'autres termes, il n'y a pas d'algorithmes pour résoudre ces problèmes en temps polynomial pour une longueur de clé donnée.

Bien que, généralement, je serais bombardé de chiffons sales (au mieux) pour mélanger les algorithmes de distribution de signature (ECDH) avec la signature (ECDSA), je dois encore expliquer comment ils fonctionnent ensemble.Un certificat TLS moderne contient une clé publique, dans notre cas, à partir d'une paire générée à l'aide d'un algorithme basé sur des courbes elliptiques, généralement signé par une organisation faisant autorité. Le client vérifie la signature du serveur et génère un secret partagé. Ce secret est utilisé dans un algorithme de chiffrement symétrique tel que AES ou ChaCha20. Cependant, les principes de base restent les mêmes: se mettre d'accord sur un ensemble (six) de paramètres, obtenir une paire de clés, où la clé privée est un entier sélectionné au hasard (un facteur de$$Q = k ⋅ P ), et la clé publique est un point sur la courbe. Les algorithmes de signature utilisent un point de base$Q=k\cdot P$$$G , qui est un générateur d'un sous-groupe d'ordre$G$$$$n$ ( $$n est un grand premier), donc$n$$$n ⋅ G = 0 , où 0 est l'élément neutre du groupe. La signature prouve qu'une connexion sécurisée est établie avec une partie authentifiée - un serveur qui a un certificat TLS (clé publique) signé par une organisation faisant autorité pour un nom de serveur donné.$n\cdot G=0$

(EC) DH (E) + ECDSA = Forme de poignée de main moderne

Dans la version 1.3 de TLS moderne, le client et le serveur génèrent une paire de clés à la volée, établissant une connexion. C'est ce qu'on appelle la version "éphémère" de l'algorithme d'échange de clés. Les bibliothèques TLS les plus populaires prennent en charge une telle version de protocole. Pour la plupart, la courbe elliptique Edwards 25519 , proposée par Daniel Bernstein Jr. (djb), qui fournit un niveau de protection de 128 bits , est utilisée aujourd'hui . Depuis 2014, cette courbe est disponible pour créer des paires de clés dans la bibliothèque openssh. Cependant, à la fin de 2019, les navigateurs n'établissaient toujours pas de session TLS avec des serveurs utilisant la clé publique de l'algorithme de signature EdDSA.

Voyons comment tout fonctionne dans TLS 1.3.

Dans la dernière version du protocole, les mécanismes de distribution des clés sont limités à (EC) DH (E) - x25519 est la fonction la plus courante pour obtenir une clé commune - elle est prise en charge par la plupart des bibliothèques TLS du navigateur et du serveur. La suite de chiffrement comprend seulement trois entrées: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 et TLS_CHACHA20_POLY1305_SHA256. Pour ceux d'entre vous qui connaissent le nom des suites de chiffrement dans la version précédente du protocole - TLS 1.2, il est évident que l'indication du mécanisme d'échange de clés a été «séparée» de la suite de chiffrement lors de la transition vers TLS 1.3. De plus, les méthodes d'échange de clés statiques RSA et DH ont été supprimées de la spécification. Même la récupération de session dans TLS 1.3 avec l'aide de PSK et des tickets de la session précédente a lieu selon le protocole ECDHE, où la dernière E-éphéméralité est particulièrement importante.De plus, dans TLS 1.3, il n'est pas possible de définir vos propres valeurs pour le mécanisme Diffie-Hellman - seul un ensemble prédéfini est laissé dans les spécifications du protocole, il existe un consensus concernant la sécurité de cet ensemble.

Le fait que les mécanismes de chiffrement asymétriques modernes fonctionnent différemment est particulièrement intéressant. Dans ECC (en particulier, lors de l'utilisation de certificats ECDSA), nous utilisons des clés de longueur relativement courte par rapport à RSA afin d'atteindre des niveaux de sécurité acceptables. Cela vous permet d'utiliser une cryptographie asymétrique forte et des schémas d'échange de clés, même sur des appareils qui, semble-t-il, ne devraient pas avoir suffisamment de puissance pour les opérations nécessaires - par exemple, les cartes à puce.

Tout d'abord, il est nécessaire de clarifier ce que le terme «cryptosystème hybride» signifie tel qu'il s'applique à la description de TLS 1.3. Le cryptosystème hybride utilise un schéma de cryptage asymétrique (avec une clé publique) pour établir un secret partagé, qui est ensuite utilisé comme clé dans un bloc symétrique ou un algorithme de cryptage de flux.

Deuxièmement, il existe une infrastructure de clés publiques (PKI) et de certificats (CA). Il est intéressant de noter qu’en 2004, Martin Hellman a mentionné l’ un des «héros méconnus» - Lauren Könfelder, dont la thèse pour défendre le diplôme du baccalauréat du MIT était la possibilité de créer une structure arborescente - ce que nous connaissons aujourd’hui sous le nom d’ICP. Mais revenons aux certificats.

Le fait que le serveur possède réellement la clé privée est vérifié par sa signature, qui peut être vérifiée à l'aide de la clé publique. Et le fichier de certificat sur le serveur certifie qu'une clé publique spécifique appartient à un serveur spécifique. Cela signifie que vous établissez une connexion sécurisée avec l'interlocuteur souhaité, et non un imposteur - votre banque, pas une cyber-fraude.

TLS 1.3 a considérablement amélioré le schéma de négociation par rapport aux versions précédentes du protocole. Maintenant, le serveur signe toutes les informations reçues lors de la prise de contact au moment de la création d'une telle signature: bonjour client et bonjour bon serveur, ainsi qu'un ensemble de chiffres sélectionnés pour être utilisés. Jetons un coup d'œil à la section correspondante de la description de l'interaction de la RFC 8446 :

Client Server Key ^ ClientHello Exch | + key_share* | + signature_algorithms* | + psk_key_exchange_modes* v + pre_shared_key* --------> ServerHello ^ Key + key_share* | Exch + pre_shared_key* v {EncryptedExtensions} ^ Server {CertificateRequest*} v Params {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data] 

Dans TLS 1.3, le client envoie sa partie de la clé (avec les paramètres nécessaires) et la liste des signatures disponibles dans le premier message (Client Hello). Les clés nécessaires à ce stade sont créées par le client à la volée - l'utilisateur ne le remarque même pas. Ensuite, le client et le serveur échangent ces informations pour créer un secret partagé - une clé de session qui est créée (ou, plus précisément, est dérivée) de la paire de pré-maître reçue après que le serveur a répondu au client avec son message (Server Hello).
Du côté «Server Hello», vous pouvez voir l'enregistrement correspondant au transfert du certificat au client (Certificat *), ainsi que la vérification CertificateVerify *, qui confirme que la partie a vraiment une clé privée liée à l'enregistrement de clé publique correspondant, puis en créant une paire de clés de session (symétrique) dans cas de succès. En d'autres termes, le demandeur de données (client) a réussi à vérifier l'authenticité du répondant (serveur) en passant à l'utilisation d'un secret partagé.

Les deux principales opérations cryptographiques sont protégées dans ce transfert - création d'une signature et vérification de la signature. Ces opérations sont généralement effectuées à différentes extrémités de la connexion, car le plus souvent, les clients vérifient l'authenticité du serveur. La signature est essentiellement une confirmation de la propriété de la clé privée correspondant à la clé publique. Autrement dit, nous recevons des données du signataire et nous assurons que le message n'a pas été modifié pendant le transfert.

Lors de l'utilisation de l'algorithme RSA, comme nous le démontrerons un peu plus loin sur les chiffres, l'opération de création d'une signature est la plus coûteuse. Comme nous signons avec une clé de 2048 ou 3072 bits, une telle opération charge considérablement le serveur - beaucoup plus fort que le client lors de sa vérification (de signature).

Dans ECDSA, nous fonctionnons avec des clés relativement courtes (dans l'exemple de référence, nous examinerons ECDSA en utilisant la courbe NIST P-256 (ou secp256v1), mais ces clés sont impliquées dans des opérations plus complexes. Par conséquent, l'utilisation d'ECC peut être représentée comme un RSA «inversé» avec points de vue performances: le client est chargé beaucoup plus durement de l'opération de vérification de signature, tandis que le serveur gère facilement l'opération de création de signature, comme en témoignent les mesures que nous fournissons dans la section benchmark.

Cet effet aide à faire évoluer Internet - puisque les clients modernes sont presque aussi puissants que les serveurs (si l'on ne considère que la vitesse d'horloge du cœur du processeur), ils peuvent efficacement entreprendre sans problème une opération de calcul difficile. Le serveur, à son tour, peut utiliser la puissance de calcul libérée pour créer plus de signatures et, par conséquent, établir plus de sessions.

Signature du certificat chez Let's Encrypt

Nous fournirons à notre lecteur une instruction simple et compréhensible sur laquelle vous pouvez créer indépendamment un serveur capable d'établir une session TLS en utilisant une paire de clés ECDSA dans laquelle Let's Encrypt est signé publiquement et est inclus dans la chaîne de certificats de confiance en tant que certificat.
Nous avons décidé d'afficher le chemin complet de la création des clés, de la création d'une demande de signature de certificat (CSR) pour Let's Encrypt et de son envoi pour signature à l'aide de l'utilitaire certbot, qui renvoie les chaînes nécessaires et le certificat ECDSA lui-même.

Vous devez d'abord créer une paire de clés. Pour cela, nous utiliserons la bibliothèque OpenSSL. Le Guide de l'utilisateur d'OpenSSL indique que la création de clés d'algorithmes basés sur des courbes elliptiques se fait à l'aide d'une commande spéciale dédiée à la famille d'algorithmes basés sur des courbes elliptiques.

 openssl ecparam -genkey -name -secp256v1 -out privatekey.pem 

Pour vérifier que notre équipe fonctionne correctement, nous exécutons la commande ec indiquant le chemin d'accès au fichier nouvellement créé contenant la clé privée.

 openssl ec -in privatekey.pem -noout -text 

La sortie devrait nous montrer la courbe utilisée, avec laquelle la clé a été générée.

La prochaine étape est assez importante lors de la création d'un CSR - afin de ne pas remplir à chaque fois le questionnaire nécessaire à la signature d'un certificat, nous avons besoin d'un fichier de configuration. Heureusement, presque tout le travail pour nous a été fait par Mozilla, créant le « générateur de configuration SSL ». Dans ce document, vous pouvez choisir parmi une variété d'options pour les modes de serveur avec lesquels vous pouvez établir une connexion TLS. La configuration OpenSSL propre, manquant pour une raison quelconque dans le générateur Mozilla, ressemble à ceci:

 [ req ] prompt = no encrypt_key = no default_md = sha256 distinguished_name = dname req_extensions = reqext [ dname ] CN = example.com emailAddress = admin@example.com [ reqext ] subjectAltName = DNS:example.com, DNS:*.example.com 

Remarque: vous n'avez pas besoin d'avoir un fichier de configuration - s'il n'est pas là, il vous sera demandé de remplir tous les champs de la ligne de commande. Avec le fichier de configuration, le chemin vers lequel nous spécifions dans la commande suivante, le processus est simplifié.

Vient ensuite la création de la demande de signature de certificat (CSR) elle-même. Pour cela, nous avons une équipe OpenSSL pratique.

 openssl req -new -config -pathtoconfigfile.cnf -key privatekey.pem -out csr.pem 

Nous pouvons également vérifier l'exactitude du CSR nouvellement créé.

 openssl req -in csr.pem -noout -text -verify 

Enfin, nous arrivons à l'étape finale - en utilisant le client ACME, certbot, nous transférerons notre demande de signature du certificat d'organisation Let's Encrypt.

Certbot vous aidera non seulement à obtenir un certificat, mais il propose également de nombreuses autres options intéressantes. Nous ajoutons que si vous êtes nouveau dans la cryptographie avec une clé publique et que vous ne comprenez pas vraiment l'infrastructure de clé publique qui existe à l'heure actuelle, il est préférable d'utiliser l'option --dry-run avant d'essayer d'obtenir un vrai certificat pour l'un de vos domaines.

 certbot certonly --dry-run --dns-somednsprovider --domain “example.com” --domain “*.example.com” --csr csr.pem 

Dans ce cas, le client certbot vérifie que la liste des domaines requis demandés sur la ligne de commande correspond à la liste dans la demande de signature de certificat (CSR). À l'intérieur de l' --dns-somednsprovider nous avons --dns-somednsprovider peu, car il existe de nombreuses façons de confirmer Let's Encrypt que vous possédez une certaine partie du trafic Internet. Mais si vous utilisez une sorte de fournisseur de cloud, tel que DigitalOcean, AWS, Azure, Hetzner, peu importe - vous avez peut-être déjà un moyen plus simple de fournir les informations dont vous avez besoin pour la certification, car votre fournisseur a pris en charge l'outil d'intégration.

Après cela, si vous êtes sûr que les paramètres transmis à la CSR à l'aide du certbot pour Let's Encrypt sont corrects, supprimez simplement le paramètre --dry-run de la commande et continuez.

En cas de succès, le client vous renverra plusieurs certificats: le certificat signé lui-même, les certificats intermédiaires et racine, ainsi qu'une combinaison de ces derniers sous la forme d'une chaîne de certificats, le tout au format .pem.

OpenSSL a une commande que nous utilisons pour regarder à l'intérieur du certificat:

 openssl x509 -in chainfilepath.pem -noout -text 

Il doit maintenant être clair que Let's Encrypt a signé le certificat à l'aide de l'algorithme de hachage SHA256. En plus de cela, Let's Encrypt ne prévoit que d'ajouter des signatures racine et intermédiaires à ECDSA, donc pour l'instant il reste à se contenter de signatures RSA intermédiaires. Mais ce n'est pas effrayant, car dans tous les cas, vous utiliserez la clé publique ECDSA.

À la fin de cette section, nous aimerions ajouter quelques informations sur la comparaison des longueurs de clé de divers algorithmes. En sécurité de l'information, il est habituel de dire que le niveau de sécurité est 2 ^ x, où x est la longueur de bit (RSA est une exception, car il se développe un peu plus lentement que l'exposant). Pour approximer la façon dont les clés de divers algorithmes sont comparées, nous nous référons à la page wiki OpenSSL :

Comme vous pouvez le voir, les différences sont perceptibles. Bien que pour l'instant, Let's Encrypt vous permet de recevoir des certificats signés uniquement sur les clés de seulement deux courbes elliptiques - 256 (secp256v1) et 384 (secp384r1).

Difficultés connues ainsi que la NSA

Publié par: xkcd

Le problème central de l'utilisation de la cryptographie basée sur des courbes elliptiques était peut-être le besoin d'un générateur de nombres aléatoires très bien implémenté, qui est nécessaire pour créer des clés d'un certain niveau de sécurité.

Un énorme scandale a été associé à l'algorithme Dual_EC_DRBG - il a fallu de nombreuses années pour le résoudre. Il y a une incertitude sur la base de brevets autour de l'ECC - on sait que de nombreux brevets appartenaient à Certicom, qui a été acquis par Blackberry. Il existe également plusieurs cas de certification Blackberry ECC connus. Enfin, il existe une certaine méfiance à l'égard des normes du NIST, qui pourraient être influencées par la NSA ou toute autre agence de renseignement américaine.

Les erreurs dans la mise en œuvre des normes cryptographiques est un sujet complètement orthogonal. En 2010, la PlayStation 3 a souffert d'une fuite de la clé privée de Sony en raison d'une implémentation incorrecte de l'algorithme ECDSA - Sony n'a pas pu faire face au RNG et a fourni le même nombre aléatoire, ce qui a permis de résoudre la fonction avec une entrée secrète. OpenSSL a souffert l'année suivante, cependant, il a rapidement corrigé une vulnérabilité qui lui permettait d'obtenir une clé privée à l'aide d'une attaque temporelle - plus de détails peuvent être trouvés dans la publication de recherche originale .

Lors d'une conférence RSA en 2013, un groupe de chercheurs a présenté un document de recherche intitulé « Randomly Failed! »Dédié aux vulnérabilités de classe Java SecureRandom. Six mois plus tard, les choses ont commencé avec les portefeuilles Bitcoin créés à l'aide d'un générateur de nombres pseudo aléatoires cryptographiquement dangereux.

En raison du fait que plusieurs vulnérabilités graves ont été découvertes en peu de temps, le même août 2013, l'IETF a publié la RFC 6979 , qui décrit la génération déterministe de k lors de la création d'une clé. Nous pourrions écrire que le problème a été résolu de cette façon, mais nous ne le ferons pas - à tout moment, les chercheurs peuvent trouver de nouvelles erreurs dans la mise en œuvre en raison d'écarts inutiles par rapport aux spécifications du protocole.

Et quelques mots sur la NSA. Si vous ne connaissiez pas l'histoire de Dual_EC_DRBG - prenez le temps de lire les documents pertinents, vous ne regretterez pas d'avoir compris les détails. Edward Snowden est devenu une partie de cette histoire, car c'est à cause de ses fuites en 2013 que tous les doutes qui ont existé ont été confirmés. Cela a entraîné le fait que de nombreux cryptographes éminents ont perdu confiance dans le NIST, car c'est cette organisation qui a créé et décrit de nombreuses courbes elliptiques et algorithmes qui fonctionnent dans ECDSA.

La courbe 25519 créée par Daniel Burnshite et la fonction Diffie-Hellman pour la distribution des clés est la réponse à bon nombre des questions ci-dessus. Et, comme nous l'avons déjà écrit, il y a un mouvement constant vers EdDSA. Dans le cas des courbes NIST, aucune confirmation de leur vulnérabilité n'a encore été trouvée, et quant à l'expérience des nombres aléatoires, elle a été assez douloureuse et a contribué à l'assimilation rapide.

Pour conclure cette partie, nous aimerions citer John von Neumann: "Quiconque a une faiblesse pour les méthodes arithmétiques pour obtenir des nombres aléatoires est sans péché sans aucun doute."

Quelques repères

Nous avons utilisé le serveur NGINX 1.16.0 avec la bibliothèque OpenSSL version 1.1.1d pour effectuer des tests avec deux certificats. Comme mentionné précédemment, pour le moment, Let's Encrypt vous permet d'utiliser uniquement les algorithmes prime256v1 et secp384r1 pour créer une demande de signature de certificat, ainsi que de ne pas fournir de certificats racine et intermédiaire avec une signature ECDSA, traitant probablement de cette fonctionnalité pendant que vous lisez cette note.

Comme vous pouvez le voir, sur un seul cœur du processeur Intel® Xeon® Silver 4114 à 2,20 GHz (publié au troisième trimestre de 17), la différence totale entre les performances ECDSA et le RSA généralement accepté avec une longueur de clé de 2048 bits est de 3,5 fois.

Examinons les résultats de l'exécution de la commande openssl -speed pour ECDSA et RSA sur le même processeur.

Ici, nous pouvons trouver la confirmation d'une thèse précédemment écrite sur la façon dont les opérations de calcul d'une signature et sa vérification diffèrent entre ECC et RSA. Actuellement, armée de TLS 1.3, la cryptographie basée sur des courbes elliptiques permet une augmentation significative des performances du serveur avec un niveau de protection supérieur à RSA. C'est la raison principale pour laquelle nous, chez Qrator Labs, recommandons et encourageons fortement les clients qui sont également prêts à utiliser les certificats ECDSA. Sur les processeurs modernes, le gain de performances en faveur de l'ECDSA est 5x.

Si vous souhaitez savoir comment votre processeur (domestique ou serveur) gère l'informatique cryptographique, exécutez la commande openssl speed. Les -rsa , -ecdsa et -eddsa vous permettent de spécifier les algorithmes d'intérêt pour l'analyse comparative.

L'avenir (en superposition)

Ironiquement, Google a annoncé " en train de rédiger ce document " d'atteindre la supériorité quantique " . Est-ce à dire que nous sommes déjà en danger et que tous les progrès réalisés jusqu'à présent ne sont plus en mesure d'assurer le secret?

Non.

Comme Bruce Schneier l'a écrit dans l'essai «Cryptography after Alien Landing» pour la circulaire de sécurité et de confidentialité de l'IEEE, un ordinateur quantique ne peut vraiment porter un coup sérieux qu'à la cryptographie asymétrique avec une clé publique. Les algorithmes symétriques resteront persistants.

Mais pour continuer, nous allons donner la parole à M. Schneier lui-même:

Il existe un autre scénario futur qui ne nécessite pas d'ordinateur quantique. Bien que nous ayons maintenant plusieurs théories mathématiques qui sous-tendent le caractère unilatéral utilisé en cryptographie, la preuve de la validité de ces théories est en fait l'un des plus grands problèmes ouverts en informatique. Tout comme un cryptographe intelligent peut trouver une nouvelle astuce qui facilite le piratage d'un algorithme particulier, nous pouvons imaginer des extraterrestres avec suffisamment de théorie mathématique pour casser tous les algorithmes de cryptage. Aujourd'hui, cela semble ridicule. La cryptographie à clé publique est une théorie des nombres et est potentiellement vulnérable aux extraterrestres soucieux des mathématiques. La cryptographie symétrique est si non linéaire, si simple à créer et à compliquer, et aussi à quel point il est facile d'allonger les clés, quel avenir est inimaginable. Un exemple est la variante AES avec un bloc de 512 bits et une taille de clé, ainsi que 128 tours. Si les mathématiques ne sont pas fondamentalement différentes de notre compréhension actuelle, alors un tel algorithme sera sûr jusqu'à ce que les ordinateurs soient faits d'autre chose que de la matière et occupent autre chose que de l'espace.

Mais si l'inimaginable se produit, il ne nous restera plus qu'une cryptographie basée uniquement sur la théorie de l'information: les blocs-notes chiffrés jetables et leurs variantes.

Bruce Schneier décrit parfaitement le domaine où, outre les erreurs d'implémentation, se trouvent les principales vulnérabilités de la cryptographie moderne. S'il y a quelque part un groupe de mathématiciens, cryptanalystes et cryptographes aisés, ainsi que des ingénieurs informaticiens travaillant sur la preuve ou la réfutation de certains problèmes mathématiques particulièrement complexes (tels que P? = NP), qui ont réussi à progresser actuellement dans cette activité - notre position est vulnérable. En rejetant les théories du complot, on peut dire que de tels progrès dans les domaines de l'informatique, de la théorie de l'information et de la théorie de la calculabilité peuvent difficilement être cachés. Un tel événement aurait inscrit les noms de leurs propres créateurs sur les pages de l'histoire et, en particulier, dans les manuels d'histoire de l'Internet, ce qui est inestimable pour tout individu ou groupe aussi intelligent. Un scénario similaire peut donc être rejeté comme impossible.

Il est également difficile de savoir si de tels succès dans l'informatique quantique seront réalisés au cours des 5 prochaines années - et il existe déjà des primitives cryptographiques pouvant être utilisées dans le monde post-quantique: réseaux, utilisant l'isogénéisation supersingulaire des courbes elliptiques, fonctions de hachage, codes de correction d'erreur. Maintenant, les experts en sécurité ne font que les expérimenter, mais il ne fait aucun doute que, si nécessaire, l'humanité trouvera un moyen de déployer rapidement de nouveaux algorithmes à n'importe quelle échelle.

Il reste seulement à ajouter que pour la prochaine décennie, la cryptographie basée sur des courbes elliptiques semble être parfaitement adaptée aux objectifs et aux besoins que la plupart de ses utilisateurs se fixent, offrant sécurité et hautes performances.