Comprendre le SSL 2048 bits et le cryptage 256 bits
Sur la page de DigiCert, ils annoncent un SSL 2048 bits avec un cryptage 256 bits: http://www.digicert.com/256-bit-ssl-certificates.htm
Quelle est exactement la différence ici et pourquoi deux bits de chiffrement sont-ils référencés?
Voici une capture d'écran de l'annonce:
Sur l'annonce SSL Premium de Geotrust, ils l'annoncent comme:
Security: domain control validation, strong 256-bit encryption, 2048-bit root
Alors, quelle est la différence entre le cryptage 256 bits et la racine 2048 bits?
J'espère que cela clarifie la question.
Le 2048 bits concerne la paire de clés RSA: les clés RSA sont des objets mathématiques qui incluent un grand entier, et une "clé 2048 bits" est une clé telle que le grand entier est plus grand que 22047 mais plus petit que 22048.
Le 256 bits concerne SSL. En SSL, la clé du serveur est utilisée uniquement pour transmettre une clé aléatoire de 256 bits ( que on n'a pas de structure mathématique, c'est juste un tas de morceaux); en gros, le client génère une clé aléatoire de 256 bits, la chiffre avec la clé publique RSA du serveur (celle qui se trouve dans le certificat du serveur et est une "clé de 2048 bits"), et envoie le résultat au serveur. Le serveur utilise sa clé RSA privée pour inverser l'opération, et ainsi obtenir la clé 256 bits choisie par le client. Par la suite, le client et le serveur utilisent le 256 bits pour effectuer un chiffrement symétrique et des vérifications d'intégrité, et RSA n'est plus utilisé pour cette connexion.
Voir cette réponse pour plus de détails. Cette configuration est souvent appelée "cryptage hybride". Cela est dû au fait que RSA n'est pas approprié pour le chiffrement en masse, mais le chiffrement symétrique ne peut pas faire les affaires publiques/privées initiales qui sont nécessaires pour démarrer.
(SSL peut faire l'échange de clés avec d'autres algorithmes que RSA, j'ai donc simplifié un peu la description dans le texte ci-dessus, mais c'est l'essentiel de l'idée.)
Pour ajouter un peu plus de détails, la clé RSA à 2048 bits est appelée cryptographie asymétrique. Il est utilisé pour valider l'identité (signature) et garantir que seul un destinataire prévu peut accéder aux informations envoyées (cryptage). Il est composé de deux pièces, une clé publique et une clé privée. Les clés sont en fait liées les unes aux autres, mais comme elles sont liées par deux très grands nombres pseudo-premiers (premiers les uns par rapport aux autres), il est très difficile de déterminer la clé privée à partir du public.
Cela dit, parce que l'algorithme est basé sur quelque chose de vraiment difficile à comprendre (mais résoluble), il est moins sûr qu'un algorithme symétrique basé sur un secret partagé, qui n'est pas mathématiquement résoluble et ne repose pas sur la complexité d'un problème de mathématiques pour la sécurité (plus à ce sujet plus tard). C'est pourquoi la clé est tellement plus grande que la contrepartie symétrique (qui n'est que de 256 bits). Pour rendre l'équation difficile à résoudre, il faut une clé beaucoup plus grande et aussi, plus il y a d'informations transmises avec la clé asymétrique, plus il est probable qu'elles soient brisées (également, le cryptage/décryptage est plus intense pour le processeur).
Pour cette raison, SSL utilise uniquement RSA pour les phases de validation et d'échange de clés. Au lieu de cela, une clé symétrique (dans ce cas de 256 bits si pris en charge par le navigateur sur le client) est générée et retransmise au serveur via le cryptage RSA, puis le reste des données est échangé via la clé partagée et un algorithme symétrique.
Cela se produit lorsque le client décode d'abord la réponse à un défi que le serveur chiffre avec sa clé privée, le client peut ensuite consulter la clé publique du serveur (qui est signée par une clé racine connue que l'autorité de certification (dans ce cas, DigiCert ) a été inclus avec la plupart des navigateurs). Lorsque la réponse décodée correspond au défi, le client sait que le serveur a répondu à la demande (bien qu'un intermédiaire puisse la relayer). Le client génère ensuite la clé symétrique 256 bits et la chiffre avec la clé publique du serveur et l'envoie au serveur. Étant donné que la clé est chiffrée avec la clé publique du serveur, seul le serveur (qui connaît la clé privée) peut la déchiffrer. Cela signifie que tout intermédiaire de l'étape précédente ne peut pas connaître la nouvelle clé partagée. Le client peut désormais être sûr que toutes les informations envoyées via la clé partagée proviennent uniquement du serveur prévu.
Juste pour ajouter quelques détails aux réponses existantes ...
ma question est comment le client saurait-il générer une clé aléatoire de 256 bits? (Pourquoi pas 128?).
Cela dépend de la suite de chiffrement qui est négociée. La liste de ceux définis dans le cadre de TLS 1.1 se trouve dans RFC 4346 Annexe A.5 . Par exemple TLS_RSA_WITH_AES_128_CBC_SHA utilisera une clé de 128 bits, tandis que TLS_DHE_RSA_WITH_AES_256_CBC_SHA utilisera une clé de 256 bits.
La suite de chiffrement négociée dépendra de la configuration du client et du serveur, et non du certificat installé sur le serveur. Lorsque le client établit la connexion avec un Client Hello message, il envoie une liste des suites de chiffrement qu'il prend en charge. Le serveur choisit ensuite celui qu'il veut et le dit dans son Server Hello message.
Cette suite de chiffrement détermine ensuite comment ces clés symétriques sont finalement partagées. Le but immédiat de la négociation SSL/TLS est d'établir un partage de secret pré-maître entre le client et le serveur. Ceci est plus généralement appelé échange de clés (voir RFC 4346 Appendice F.1.1) .
Cela tombe dans deux catégories (à l'exclusion de l'échange de clés anonymes):
- Échange de clés RSA (par exemple
TLS_RSA_WITH_AES_128_CBC_SHA): le client crypte le secret pré-maître à l'aide de la clé publique du serveur (trouvée dans le certificat). - Échange de clés DH (E) (par exemple
TLS_DHE_RSA_WITH_AES_256_CBC_SHA): un échange de clés Diffie-Hellman a lieu. Le serveur signe ses paramètres DH et le client vérifie la signature par rapport à la clé publique dans le certificat de serveur. (La possession d'un certificat basé sur RSA n'implique pas un échange de clés RSA.)
À la fin de la prise de contact, selon l'une de ces deux étapes, le client et le serveur sont en possession d'un secret de pré-master commun , de dont ils dérivent un secret principal (voir RFC 4346 section 8.1 ).
À partir de ce secret principal , les deux parties peuvent dériver les clés de chiffrement (et les secrets MAC), comme décrit dans RFC 4346 Section 6. .
Outre le type de clé (RSA ou DSS), il n'y a rien dans cela qui fait que la taille de la clé de chiffrement dépend du certificat. De plus, les deux types ont des suites de chiffrement qui utilisent des clés de 256 bits: par exemple TLS_DHE_DSS_WITH_AES_256_CBC_SHA et TLS_DHE_RSA_WITH_AES_256_CBC_SHA. (DSS est un algorithme de signature uniquement, vous n'obtiendrez donc pas d'échange de clés de type RSA pour crypter le secret pré-maître.)
La taille de la clé dans le certificat n'a d'importance que pour empêcher la falsification de l'échange de clés (ou pour pouvoir déchiffrer le trafic enregistré): si quelqu'un a pu trouver la clé privée à partir de la clé publique dans le certificat, il pourrait agir comme un MITM pour usurper l'identité du serveur réel ou ils seraient en mesure de déchiffrer le secret pré-maître chiffré (et donc le trafic enregistré) lors de l'utilisation d'un échange de clés RSA (les suites de chiffrement DHE sont précisément conçues pour empêcher l'accès au secret pré-maître , même si l'attaquant s'empare de la clé privée et du trafic enregistré, voir cette question ). C'est pourquoi une clé asymétrique suffisamment importante est importante.
Les autorités de certification ont tendance à mettre "256 bits" sur leurs sites Web car cela semble bon d'un point de vue marketing.
Ce n'est pas faux, mais cela peut être trompeur pour les personnes qui ne comprennent pas que c'est la façon dont votre serveur est configuré et ce que vos clients prennent en charge qui comptent.