Explication de la technique de chiffrement client-serveur (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, clés de 128 bits)
J'ai ouvert une page Web en utilisant https.
Quand j'ai regardé les informations de page fournies par mon navigateur (Firefox), j'ai vu ce qui suit:
Connexion cryptée: cryptage de haut niveau (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, clés 128 bits).
J'ai une question - que signifie cette technique de cryptage? Afin de le comprendre, j'ai décidé de trouver des données sur chaque partie:
TLS_ECDHE signifie éphémère courbe elliptique Diffie-Hellman et comme Wikipedia dit il permet deux parties d'établir un secret partagé sur un canal non sécurisé.
[~ # ~] rsa [~ # ~] est utilisé pour prouver l'identité du serveur comme décrit dans cet article .
AVEC _ AES_128_GCM_SHA256 : Si je comprends bien - AES_128_GCM est une technique qui fournit un cryptage authentifié comme décrit sur cette page .
SHA256 est un algorithme de hachage - fonction à sens unique.
Mais maintenant, j'essaie de comprendre comment mettre toutes ces choses ensemble. Comment cela fonctionne-t-il ensemble dans son ensemble et pourquoi a-t-il été configuré de cette manière?
Dans cette vidéo YouTube Alice et Bob utilisent l'algorithme d'échange de clés Diffie-Helman pour se mettre d'accord sur une clé secrète qu'ils vont utiliser (c'est TLS_ECDHE dans notre cas). N'est-ce pas suffisant d'établir une connexion sécurisée (à part la partie RSA qu'Alice et Bob n'ont pas faite)? Pourquoi existe-t-il également cette partie WITH_AES_128_GCM_SHA256 existe?
Cryptographie asymétrique
La création d'une session TLS comporte deux parties différentes. Il y a la partie cryptographie asymétrique , qui est un échange de clés publiques entre deux points. C'est ce que vous avez vu dans votre exemple Alice et Bob. Cela permet uniquement l'échange de clés asymétriques pour un chiffrement/déchiffrement asymétrique. Il s'agit de la partie [~ # ~] ecdhe [~ # ~] . La partie [~ # ~] rsa [~ # ~] décrit le algorithme de signature utilisé pour authentifier l'échange de clés. Ceci est également effectué avec une cryptographie asymétrique. L'idée est que vous signez les données avec votre clé privée, puis l'autre partie peut vérifier avec votre clé publique.
Cryptographie symétrique
Vous chiffrez les clés de chiffrement/déchiffrement symétriques avec votre clé asymétrique. Le chiffrement asymétrique est très lent (relativement parlant). Vous ne voulez pas avoir à crypter constamment avec. C'est à cela que sert Cryptographie symétrique . Alors maintenant, nous sommes à AES_128_GCM .
- AES est l'algorithme symétrique
- 128 fait référence à la taille de clé en bits
- GCM est le mode de fonctionnement
Alors, que chiffre exactement notre clé asymétrique? Eh bien, nous voulons chiffrer essentiellement la clé symétrique (dans ce cas, 128 bits, 16 octets). Si quelqu'un connaissait la clé symétrique, il pourrait déchiffrer toutes nos données. Pour TLS, la clé symétrique n'est pas envoyée directement. Quelque chose appelé le secret pré-maître est crypté et envoyé. À partir de cette valeur, le client et le serveur peuvent générer toutes les clés et IV nécessaires au chiffrement et à l'intégrité des données. Regard détaillé sur l'échange de clés TLS
Intégrité des données
Intégrité des données est nécessaire tout au long de ce processus, ainsi qu'avec le canal crypté. Comme vous l'avez vu lors de la recherche dans GCM, le mode de fonctionnement de chiffrement lui-même assure l'intégrité des données chiffrées. Cependant, la poignée de main à clé publique elle-même doit également être confirmée. Si quelqu'un au milieu a changé des données pendant la transmission, alors comment pourrions-nous savoir que rien n'a été falsifié? C'est dans ce cas que la fonction de hachage négociée est utilisée, SHA256 . Chaque morceau de la poignée de main est haché ensemble, et le hachage final est transmis avec le secret pré-maître chiffré. L'autre côté vérifie ce hachage pour s'assurer que toutes les données qui devaient être envoyées ont été reçues.
SHA256 , comme mentionné par une autre affiche, est également utilisé pour la fonction pseudo-aléatoire (PRF). C'est ce qui étend le secret pré-maître envoyé entre les deux parties dans les clés de session dont nous avons besoin pour le chiffrement.
Pour les autres modes de fonctionnement, chaque message serait également haché avec cet algorithme d'intégrité. Lorsque les données sont déchiffrées, le hachage est vérifié avant d'utiliser le texte en clair.
Rassemblez toutes ces pièces et vous disposez d'un mode de communication sécurisé!
Vous pouvez répertorier tous les chiffrements possibles pris en charge par OpenSSL avec openssl ciphers. Vous pouvez aller plus loin et imprimer les détails de l'une de ces suites de chiffrement avec le -V
Par exemple:
$ openssl ciphers -V ECDHE-RSA-AES256-GCM-SHA384
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x30Représente l'identifiant à deux octets de la suite de chiffrementKx=ECDHReprésente l'algorithme d'échange de clésAu=RSAReprésente l'algorithme d'authentificationEnc=AESGCM(256)représente l'algorithme de chiffrement symétriqueMac=AEADReprésente l'algorithme de vérification de l'authentification des messages utilisé
Vous avez raison: ECDHE est utilisé pour l'échange de clés et RSA est utilisé pour vérifier l'identité du serveur. Mais qu'allez-vous faire de la clé échangée? Vous devrez utiliser un certain algorithme pour crypter/décrypter la communication avec l'utilisation de cette clé échangée.
AES 128 bits est utilisé dans ce cas, en mode GCM.
Normalement, l'algorithme de hachage, SHA256 dans ce cas, est utilisé pour le code d'authentification de message basé sur le hachage (HMAC). Il s'agit de fournir un cryptage authentifié. Cependant, comme vous l'avez mentionné, AES-GCM fournit déjà un cryptage authentifié, il n'est donc pas utilisé ici.
Depuis TLS1.2, l'algorithme de hachage mentionné à la fin d'une suite de chiffrement est également utilisé pour la fonction pseudo-aléatoire (PRF) dans TLS.