cryptosec

Livres

cryptosec — 2004-05-09T22:00:00Z

Secrets et mensonges, Sécurité numérique dans un monde en réseau, de Bruce Schneier, éditions Vuibert Informatique.

La signature électronique, Transactions et confiance sur Internet, de Arnaud-F. Fausse, éditions Dunod.

Sécuriser ses échanges électroniques avec une PKI, de Thierry Autret, Laurent Bellefin et Marie-Laure Oble-Laffaire, éditions Eyrolles.

Digital Certificates, de Jalal Feghhi, Jalil Feghhi et Peter Williams, éditions Addison Wesley.

Initiation à la Cryptographie, de Gilles Dubertet, éditions Vuibert.

Cryptographie, théorie et pratique, de Douglas Stinson, éditions Thomson Publishing.

Cryptographie Appliquée, de Bruce Schneier, éditions Thomson Publishing.

Algorithmique et cryptographie, de Guy Robin, éditions Ellipses.

Cours de cryptographie, de Gilles Zémor, éditions Cassini.

Cryptography and Network Security, de William Stallings, éditions Prentice Hall.

Internet, Sécurité et Firewalls, de Karanjit Siyan et Chris Hare, éditions Mc Millan.

L'Ethique Hacker et l'esprit de l'ère de l'information, de Pekka Himanen, édition Exils.

Histoire des codes secrets, Simon Singh, éditions JC Lattès.

Enigma, de Robert Harris, éditions Pocket.

Les PKI

cryptosec — 2004-05-09T22:00:00Z

Généralités :

Suite à l'invention de la cryptographie à clés publiques, qui permettait de s'affranchir du problème de la distribution et de la gestion des clés symétriques, s'est posé le problème de la gestion des paires de clés.

J'ai des amis qui ont d'énormes trousseaux de clés (des vraies, en métal), et j'ai pu constater que c'est tout un art de bien les gérer : se souvenir laquelle correspond à quelle serrure, faire en sorte que le trousseau ne déchire pas les poches, être en bons termes avec son serrurier, avoir des doubles pour les refaire en cas de perte, ne pas les oublier dans un bar au petit matin... etc.

La notion de PKI (ICP, Infrastructure à Clés Publiques en français) prend tout son sens quand les clés (numériques) sont encapsulées dans des certificats.

Avant de poursuivre, une remarque, mais d'importance :
La mode est à la PKI.
C'était très vrai lorsque j'ai mis cette page en ligne en juillet 2000, ça l'est un peu moins aujourd'hui, en mars 2002. La mode est un peu tombée (je mesure l'intensité de la mode à la fréquence des articles sur le sujet parus dans des revues généralistes et au nombre de pilotes mis en place) ; les solutions ont aussi gagné en maturité et de vrais projets PKI commencent doucement à passer en production.

Pour en revenir aux modes, il en apparaît régulièrement en sécurité logique, dont l'objet est sensé résoudre tout les problèmes (il y eut les firewalls, le single sign-on, l'authentification par calculette, la carte à puce...) et initiées par certaines compagnies ou boites de conseil qui confondent souvent études techniques et marketing.
Il y a deux conclusions à en tirer :
Mettre en place une PKI n'apportera pas LA sécurité idéale.
Une PKI n'est pas forcément LA meilleure solution pour une situation donnée (tout comme la mise en place d'infrastructures de signature électronique sécurisée au sens des décrets n'est pas toujours nécessaire).

Il y a en gros deux modèles de PKI :

Le premier est celui dit ouvert, le plus connu et répandu. Ce sont les AC (Autorité de Certification, ou Emetteurs de Certificats) qui vendent des certificats et en assurent une certaine gestion. Dans ce cas, les clients PKI sont principalement les navigateurs (et serveurs Web associés), et on peut avoir une liste d'AC existantes en allant regarder les clés publiques de ces AC dans nos navigateurs.
Dans ce cas, les principales applications concrètes, pour ne pas dire uniques, des certificats sont SSL et S/MIME (sécurisation des transactions http et des courriels).
Les restrictions à l'export des US en matière de crypto brident les taillent de clés des navigateurs actuels (SSL 40 bits au lieu de 128 par exemple, à moins de l'augmenter sois-même. Ce n'est maintenant plus vrai en 2002), quand il n'y a pas des soupçons sur la conception de certains logiciels ou OS.
A strictement parler, ce modèle n'est en fait qu'une AC (Certification Authority en anglais) et pas vraiment une PKI, puisqu'elle ne prend pas en charge beaucoup des points listés plus bas.

Le deuxième modèle, proposé par quelques éditeurs spécialisés en sécurité et par quelques solutions OpenSource, consiste en un logiciel que l'on installe au centre du réseau d'une communauté d'utilisateurs. Contrairement au cas précédent, les administrateurs ont vraiment la main sur la gestion des clés.
De plus, les clients peuvent avoir dans ce cas beaucoup plus de fonctionnalités PKI que les navigateurs, puisqu'ils sont conçus à cet effet, et l'on peut plus facilement avoir de la crypto fiable... Le fait que les sources de la plupart des logiciels de crypto commerciaux ne soient pas disponibles marque cependant d'une tache d'ombre ce qui devrait être limpide...

Une PKI c'est un service de base, la gestion de certificats, plus un certain nombre d'autres services qui peuvent faciliter la vie des utilisateurs et des administrateurs, leur permettre d'utiliser au mieux les clés contenues dans les certificats et, biensûr, qui augmentent la sécurité du système.
Autrement dit, une PKI, c'est une AC plus d'autres fonctionnalités. Ca ne veut pas dire grand chose, mais c'est normal, c'est un concept :-)

Il y a cependant des RFC qui définissent les protocoles de gestion de certificats dans le cadre d'une PKI (celles du groupe PKIX) : une des plus importantes est la RFC 2510
Ce qui signifie bien que même les PKI sont en voie de standardisation, ce qui pourra à l'avenir améliorer l'interopérabilité entre PKI (quoique entre un standard et son implémentation... mais ceci est une autre histoire).

Quid de ce que fait une PKI :

Les PKI (l'ensemble client/serveur) devraient permettre de traiter les points suivants (d'un point de vue technique et non uniquement marketing) :

Etablissement d'une confiance commune à un groupe d'utilisateurs munis de certificats
Mise en pratique des politiques de certification
Enregistrement des utilisateurs
Génération des clés (optionnel)
Certification des clés publiques
Gestion de la durée de vie des certificats et des clés
Archivage des certificats
Renouvellement des clés et des certificats
Recouvrement des clés de chiffrement (optionnel)
Publication et accessibilité des certificats (ce point ne relève pas à strictement parler de la PKI, et est en général assuré par des annuaires)
Vérification des certificats et des signatures
Révocation des certificats (CRL : Liste de Certificats Révoqués)
Gestion des co-certificats
Horodatage
Journalisation

Selon les modèles de PKI et les implémentations concrètes des logiciels, les points précédents ne seront pas tous pris en charge.

Etablissement d'une confiance commune à un groupe de certificats :

C'est le propre d'une PKI. En signant des certificats qui contiennent une clé publique elle permet d'établir une confiance entre des utilisateurs ne se connaissant pas (en parlant d'utilisateurs, il peut tout aussi bien s'agir de personnes physiques que de dispositifs matériels comme des VPN ou de logiciels comme des firewalls). La signature se fait en passant toutes les données au travers d'une fonction de hachage et en chiffrant le résultat à l'aide de la clé privée de signature de l'AC.

Mise en pratique des politiques de certification :

Les politiques de certification (PC en français définissent les domaines d'application des certificats ainsi que les procédures selon lesquelles les certificats sont générés et gérés. Elle permettent entre autres d'étendre le lien de confiance jusqu'à l'utilisateur final (la procédure de délivrance de tel certificat est digne de confiance, parce que l'émetteur de certificats demande une pièce d'identité pour générer un certificat par exemple).
L'équivalent dans le système PGP, à la différence qu'il n'y a pas de tiers commun à qui l'on fait confiance est : " je fais confiance à telle clef publique parce que telle personne en qui j'ai entièrement confiance lui fait confiance ".
A la PC est en général jointe une DPC (Déclaration des Pratiques de Certification, CPS (Certificate Policy Statement en anglais) qui est un document qui détermine les moyens précis mis en oeuvre pour satisfaire aux exigences définies dans la PC.
Il existe en France deux PC de référence :

— La PC Type du MINEFI (qui en est à la troisième version)
— La PC2 de la DCSSI

Enregistrement des utilisateurs :

Dans une architecture PKI c'est en général un composant logiciel (RA, Registration Authority ou AE, Autorité d'Enregistrement) séparé de celui qui va effectivement faire la génération des certificats. Ce module permet de valider un enregistrement avant de générer le certificat, d'enregistrer les utilisateurs, d'être l'interface de révocation... etc.

Génération des clés :

Il y a en gros deux sous-modèles de PKI : ceux qui utilisent une seule paire de clé pour le chiffrement et la signature, et ceux qui séparent ces deux fonctionnalités en donnant à chaque utilisateur deux paires de clés (ou plus). L'une par exemple pour le chiffrement, l'autre pour la signature. Eventuellement d'autres pour l'authentification (ou des certificats d'attribut, de courte durée de vie).

Une seule paire de clé : Dans ce cas, celui des simples AC qui vendent des certificats par exemple, la paire de clés est générée sur le poste client de l'utilisateur qui veut un certificat, la clé privée est stockée localement (chiffrée avec une clé dérivée d'un mot de passe) et la clé publique est envoyée au serveur de certificats pour qu'il la certifie.

Deux paires de clés :
C'est dans ce cas que le concept de PKI commence à prendre du sens. S'il y deux paires de clés, c'est parce que celle privée de chiffrement doit éventuellement pouvoir être recouvrée (pour que toutes les données chiffrées d'un utilisateur ne soient pas définitivement perdues suite à un oubli de mot de passe ou une altération de la clé) et donc sauvegardée sur le serveur, et que la clé privée de signature doit, elle, rester rigoureusement en possession de l'utilisateur, ce qui est incompatible.
Voir la section "Recouvrement des clés de chiffrement symétriques" pour plus de précisions et les risques de cette procédure.
La paire de clés de chiffrement peut donc être générée sur le serveur. La clé privée sauvegardée est ensuite envoyée de façon sûre à l'utilisateur, la clé publique certifiée, et envoyée à l'utilisateur. Le certificat est posté dans un annuaire et envoyé à l'utilisateur.
La paire de clés de signature est générée chez le client, la clé publique envoyée au serveur pour certification et la clé privée gardée rigoureusement secrète. Le certificat de signature est ensuite renvoyé à l'utilisateur.

Certification des clés publiques :

Une PKI génère ou reçoit une clé publique et la certifie : elle génère un certificat contenant la clé publique et signe le tout avec sa clé privée de signature. Dans le cas ou elle reçoit la clé de la part de l'utilisateur, il doit exister une procédure pour en assurer l'authenticité et l'intégrité. Ce peut être un secret partagé généré au préalable et envoyé à l'utilisateur par un canal sûr (enveloppe cachetée, de la main à la main, par pigeon voyageur...).
Lorsqu'un utilisateur envoie une clé publique à certifier, c'est en général au format PKCS#10 (format pour la requête de certificats).
La PKI doit assurer que sa clé privée de signature demeure rigoureusement secrète : il existe des dispositifs matériels externes au serveur qui prennent en charge la génération de cette clé et les opérations de signature. Ces dispositifs peuvent en outre offrir la possibilité de sauvegarder la clé racine de l'AC (ou les clés).

Gestion de la durée de vie des certificats et des clés :

Les clés (privées et publiques) doivent avoir une durée de vie limitée, ainsi que les certificats associés. Accorder une durée de vie illimitée à une paire de clés peut permettre à un attaquant de se lancer dans une recherche exhaustive de longue durée, avec une quantité toujours croissante de textes chiffrés à analyser. De plus, si une clé est compromise, ce sont toutes le données chiffrées avec celle-ci depuis des années qui sont compromises, ce qui n'est pas le cas si la paire de clé est renouvelée chaque année par exemple.
Les durée de vie des certificats de chiffrement et de ceux de signature, dans le cas ou il y a deux paires de clés, n'est pas nécessairement la même : on peut par exemple considérer que les applications de signature sont plus critiques que celles de chiffrement et que les certificats associés nécessitent donc une durée de vie plus courte.
Si un certificat de signature, aussi appelé certificat de vérification, est expiré, il doit tout de même être possible de s'en servir, pour vérifier des signatures datant d'avant l'expiration (il faudra dans ce cas s'assurer qu'au moment de la signature le certificat n'étais pas périmé ou révoqué).
Si par contre un certificat de chiffrement est expiré, sont utilisation ne devrait plus être possible.
Une application cliente peut ignorer ou simplement avertir l'utilisateur que le certificat est expiré, sans pour autant en interdire l'utilisation (voir les champs des certificats X509v3).

Archivage des certificats :

Les certificats devraient en principe être sauvegardés ailleurs que dans un annuaire, ce qui doit permettre à un utilisateur les ayant perdu de les récupérer, même s'ils ne sont plus dans l'annuaire. Cette fonctionnalité peut aussi permettre de restaurer les informations dans l'annuaire, le cas échéant.

Renouvellement des clés et des certificats :

Puisque les certificats expirent, il faut pouvoir les renouveler. Pour éviter toute interruption de service, c'est à dire que l'utilisateur n'ait plus pendant une certaine période de certificat valide, le mécanisme de renouvellement doit commencer avant l'expiration.
Une PKI devrait permettre de fixer ces paramètres.
Dans le cas des simples AC, qui utilisent majoritairement les navigateurs comme clients (pour faire du SSL et du S/MIME) cette fonctionnalité n'est pas disponible parce que les clients ne savent pas gérer les requêtes de certificats avant expiration. Mais ça devrait bientôt changer (c'est promis, ça vient dans la version n en Qn de l'année 200n...).

Recouvrement des clés de chiffrement symétriques :

Comme je l'ai mentionné dans la section " génération des clés ", une PKI peut offrir la possibilité aux utilisateurs de recouvrer leurs documents chiffrés s'ils oublient le mot de passe libérant la clé privée par exemple. Il faut pour cela sauvegarder au niveau du serveur de PKI les clés privées de chiffrement.
Cela introduit biensur une faille, puisque un administrateur est théoriquement en mesure de lire des fichiers chiffrés.
On peut cependant limiter ce risque en mettant en place des systèmes d'autorisation multiples (plusieurs administrateurs doivent donner leur accord) ou d'avertissement de l'utilisateur en cas de recouvrement par exemple.
Ce qui chiffre les documents est une clé symétrique utilisée dans un algorithme de chiffrement par blocs (AES, DES, IDEA, CAST, Twofish...). Cette clé est ensuite chiffrée avec la clé asymétrique du destinataire (la sienne si on chiffre pour soi-même). Dans les cas standard, pour recouvrer un fichier chiffré, il faut donc déchiffrer la clé symétrique, et donc récupérer sa clé privée asymétrique de déchiffrement devenue inaccessible.
La PKI peut alors proposer un moyen sécurisé pour recouvrer cette clé, et en régénérer une paire et le certificat associé si nécessaire.
Il existe une autre possibilité : lors du chiffrement, une copie de la clé symétrique est chiffrée avec une clé (publique) maître de l'AC, qui pourra alors déchiffrer tous les documents sans recouvrer les clés des utilisateurs. Ce procédé, outre qu'il permet plus d'abus, pose en plus un autre problème : si la paire de clé maître est cassée, révélée ou aux mains d'un tiers, ce sont tous les documents de tous les utilisateurs de la PKI qui sont vulnérables.
Avant de décider si l'on va se donner la possibilité de recouvrer les clés privées de chiffrement il faut soigneusement considérer les deux aspects suivants :
Soit on est prêt à gérer et assumer les pertes de données consécutives à des oublis de mot de passe...
Soit on accepte la possibilité de recouvrement, avec les risques pour la confidentialité que cela peut supposer...

Publication et accessibilité des certificats :

Pour que tout utilisateur puisse trouver le certificat d'un correspondant, la PKI doit les rendre publiquement accessibles. Elle les poste pour cela dans des annuaires, X.500 ou simplement " LDAP ".
Lightweight Directory Access Protocol (LDAP) est un protocole de communication avec les annuaires. Les annuaires possèdent une structure en arbre qui facilite les recherches.
La PKI postera également dans les annuaires les Listes de Certificats Révoqués (CRL), qui permettront aux applications clientes de venir consulter l'état de validité d'un certificat.
Il est à la charge des applications d'implémenter LDAP pour aller chercher les certificats et consulter les CRL.
Un protocole pour consulter les CRL est OCSP (Online Certificate Status Protocol), via un serveur qui prend en charge cette vérification.
La PKI n'a pas à se soucier particulièrement de la sécurisation de ses communications avec l'annuaire : les certificats ne sont pas confidentiels, et ils sont signés (si un faux certificat remplace un vrai, les applications clientes n'en vérifieront pas correctement la signature). Il est cependant important de noter que la structure même de l'annuaire peut être de nature confidentielle.
Un standard, SASL, est pourtant en train d'émerger, qui permettra d'établir des communications sécurisées avec les annuaires.
Pour donner une idée, voici la structure typique d'un annuaire :

Révocation des certificats (CRL) :

Une PKI doit permettre de révoquer des certificats. Chaque certificat possède un champ Serial Number, c'est ce numéro qui est inscrit dans une liste des certificats révoqués (CRL) en cas de révocation. Lorsqu'une application cliente utilise un certificat, elle devrait aller consulter la CRL. Si le numéro de série du certificat n'est pas présent, c'est qu'il est valide.
Les CRL sont signées par l'AC et doivent être accessibles en LDAP dans un annuaire.
S'il n'y a pas de CRL ou qu'il faut faire un telnet sur une machine pour aller ensuite la chercher en FTP dans le 43ème répertoire d'une machine située à Panama, c'est que l'AC (la pseudo-PKI) fait mal son boulot : Panama c'est pas pour les CRL mais pour les pavillons de complaisance. Hélas.
Il faudra aussi prendre soin de bien spécifier les procédures organisationnelles pour procéder à une révocation :

— Qu'aucun certificat ne soit révoqué de façon non légitime,

— Prévoir la méthode d'authentification des requêtes de révocation...

— ...etc

Vérification des certificats et des signatures :

Normalement, lors de chaque utilisation d'un certificat (chiffrement, vérification de signature, authentification...) l'application qui l'utilise devrait en vérifier la validité. Cela consiste en :

Vérifier la signature que le CA y a apposé (intégrité et authenticité)
Vérifier qu'il est valide en vérifiant les dates de validité
Vérifier qu'il n'a pas été révoqué, en allant consulter la CRL correspondante.

Dans le cas des simples AC, les clients étant les navigateurs, ils n'ont pas aujourd'hui de fonctionnalités automatiques de consultation de CRL, elle doit se faire manuellement... et c'est laborieux. OCSP est apparu sur Netscape 6, désactivé par défaut.

Gestion des co-certificats :

Une autorité de certification peut se co-certifier avec une autre. Il peut alors s'établir entre les utilisateurs des deux CA un lien de confiance.
Cette confiance peut être unilatérale.
Techniquement une AC va certifier le certificat d'une autre AC (qui est en fait un certificat auto-émis... il faut bien que ça commence quelque part), et réciproquement.
Il y a plusieurs types d'architectures de co-certification : hiérarchique, à plat, mixte, pont...

Horodatage :

Une PKI devrait offrir des services d'horodatage. Une application cliente doit pouvoir accoler à la signature d'un document un sceau temporel (sic). L'application passe les données au travers d'une fonction de condensation, signe ce résultat et l'envoie à un serveur de temps. Celui-ci, éventuellement relié à une horloge atomique, à un réseau de type GPS ou à un coucou suisse, vérifie la signature et, si elle est bonne, y adjoint une date, signe à nouveau le tout et le renvoie à l'expéditeur. Celui-ci joint ce sceau à ses données.
Le destinataire vérifie la signature sur le sceau et est assuré que la date portée sur la signature est correcte.
Il est à noter que l'horodatage ne certifie que la date et l'heure de la signature, pas celle de l'expédition ou de la réception d'un message ou du pigeon voyageur (s'il est envoyé ou lâché).
Voir la page sur l'horodatage pour plus de détails.

Journalisation :

Une PKI devrait enfin journaliser tous les opérations, en protégeant ces données en intégrité et/ou confidentialité, comme la création d'utilisateurs, leur révocation... etc.

RSA

cryptosec — 2003-02-19T23:00:00Z

Généralités :
C'est l'algorithme à clé publique le plus répandu, et le plus populaire. Il a été inventé en 1977 par Ron Rivest, Adi Shamir et Leonard Adleman (le GCHQ anglais aurait eu en fait un peu d'avance).

Cet algorithme peut être utilisé pour :

- la confidentialité
- la signature électronique
- l'échange de clés symétriques.

Sa sécurité repose sur la difficulté de factoriser les grands nombres (bien que ça ne soit pas mathématiquement prouvé, ce n'est qu'une conjecture).

Une longueur de clé de 512 bits n'est aujourd'hui plus vraiment suffisante, on lui préférera du 1024 ou du 2048 bits. A vrai dire, même le 1024 commence à vieillir...
Mais des longueurs de clé telles que 2048 mettent probablement RSA à l'abri pour encore bien des années.
Ce qui pourrait complètement compromettre la sécurité de RSA serait une avancée mathématique qui aurait pour conséquence de faciliter la factorisation des grands nombres (mais il est possible qu'une telle avancée soit mathématiquement interdite). Ou bien la construction de "machines à factoriser" révolutionnaires.

Principe :
Choisir deux grands nombres premiers (au moins 200 chiffres, chacun d'une longueur d'à peu près la moitié de la taille de clé voulue, voir Miller-Rabin pour un test de primalité probabiliste) :

p et q

Calculer :

n = p*q

Pour obtenir la clé publique de chiffrement : choisir e tel que :

e et (p-1)(q-1) soient premiers entre eux.
phi(n) = (p-1)(q-1) est la fonction d'Euler qui donne le nombre d'entiers premiers à n et inférieurs à n)

Pour obtenir la clé privée de déchiffrement : choisir d tel que :

ed = 1mod[(p-1)(q-1)]

(ou encore d tel que (ed-1) soit divisible par (p-1)(q-1))

soit : d = e^(-1)mod[(p-1)(q-1)]

(on utilise pour cela l'algorithme d'Euclide étendu)

La clé publique est constituée de : e et n
(c'est la longueur en bits de n qui donne la longueur de la clé RSA utilisée)

La clé privée est : d et n

Chiffrement et signature sont mathématiquement les mêmes opérations, ce n'est que par convention que l'on choisit que telle clé sera celle de chiffrement et telle autre celle de déchiffrement.

Pour chiffrer un message m, on le découpe en blocs de taille plus petite que la clé et tels qu'ils aient une représentation unique modulo n
(en binaire on pourra prendre la plus grande puissance de 2 inférieure à n)
Les blocs Ci de texte chiffré se calculent à partir des blocs Mi du texte clair par (ils auront la même taille que la clé) :

Ci = (Mi^e)mod(n)

Pour déchiffrer les blocs chiffrés Ci, il suffit de les exponentier par d :

Mi = (Ci^d)mod(n)

Un démo de RSA en javascript

Utilisation dans la pratique :
Utilisation de certificats :
Afin de s'assurer de l'appartenance d'une clé publique on utilisera souvent des certificats X.509v3, bien que PGP et GPG (autres formats, et non signés par une Autorité) en soient des contre-exemples de poids. Le certificat contient une clé publique, et la signature d'une autorité reconnue par les protagonistes. Cette clé pourra aussi bien être une clé de chiffrement, une clé de vérification ou bien une clé qui remplira les deux fonctions.

Chiffrement :
Dans la pratique (voir plus bas) on utilise souvent une combinaison de RSA et d'un algorithme symétrique. On chiffre tout d'abord les données à l'aide d'une clé symétrique aléatoire, puis on chiffre cette clef à l'aide de la clé publique du destinataire et on joint enfin cette clé symétrique chiffrée aux données chiffrées. Le destinataire déchiffrera cette clé symétrique à l'aide de sa clé asymétrique privée, puis déchiffrera les données à l'aide de la clé symétrique.
S'il y a plusieurs destinataires, chacun aura sa copie de la clé symétrique chiffrées avec sa clé publique. Voir la page sur le chiffrement mixte.

Signature et intégrité :
Pour la signature et l'intégrité on passera tout d'abord les données à signer au travers d'une fonction de condensation (ou de hachage), puis on chiffrera à l'aide de la clé privée RSA le résultat (condensât ou "hashcode"). Ce dernier résultat sera ajouté aux données, ainsi par exemple que le certificat associé à la clé publique. Le destinataire déchiffrera ce résultat à l'aide de la clé publique, passera les données au travers de la même fonction de condensation, et comparera les deux résultats obtenus : s'ils sont égaux il aura l'assurance que les données n'ont pas été modifiées et que l'identité inscrite sur le certificat de l'expéditeur est bien la même que celle qui à signé.
Voir la page sur la signature.

Vitesse :
La vitesse de RSA, qui est imposée par la vitesse des exponentiations modulaires, est au mieux environ 1000 plus faible qu'un DES réalisé en matériel (si le DES est en soft, RSA est environ 100 fois plus lent).

Doubler la taille de la clé :

multiplie par 4 le temps des opérations utilisant la clé publique
multiplie par 8 le temps des opérations utilisant la clé privée
multiplie par 16 le temps de génération des clés (et dans les cartes à puces à microprocesseur, ça se sent...)

Si RSA est réalisé sur des cartes à puce, il sera encore plus lent (notamment la génération).

La faible vitesse de RSA le rend peu propice au chiffrement de grandes quantités de données, c'est pourquoi on adoptera souvent des cryptosystèmes mixtes constitués de la combinaison d'un algorithme symétrique et d'un algorithme asymétrique.

Pour augmenter la vitesse des processus, on peut choisir certaines valeurs particulières de e :
3, 17 ou 65537 par exemple.
Cette dernière valeur est celle recommandée par la norme X509.
Il n'y a aucune faiblesse connue à choisir ces données arbitraires de e (qui peuvent être partagées entre tout un groupe d'utilisateurs). Il faudra cependant veiller à ce que les p-1 et q-1 ne soient pas des multiples de la valeur choisie.

Trouver des nombres premiers est lent. La plupart des implémentations ont donc recours à des algorithmes probabilistes de test de primalité pour déterminer p et q, comme le test de primalité de Miller-Rabin. Les nombres p et q ont alors une probabilité d'être premiers. Il est possible de rendre cette probabilité aussi faible que l'on veut. Seul peu de nombres échouent aux tests de primalité : ce sont les nombres de Carmichael, il y en a peu et on peut facilement les écarter.

Sécurité et attaques :
La sécurité d'une clé RSA et d'une clé DES symétrique de même taille n'est pas comparable.

Il peut aussi être vulnérable si la même paire de clé est utilisée à la fois pour chiffrer et pour signer : l'attaquant peut faire signer à la victime des données, ce qui mathématiquement est équivalent à un chiffrement et disposer ainsi d'un texte clair connu... ce qui peut permettre certaines attaques... en théorie.

Bien que le nombre de nombres premiers soit infini, le nombre disponible pour une longueur de clé fixé est limité. Mais pour une clé de 512 bits par exemple, il y en a à peu près 10^150 de longueur égale ou inférieure, ce qui rend une attaque par essai exhaustif des nombres premiers... longue, très longue.

Standards et protocoles :
RSA est une composante de nombreux protocoles ou spécifications :

SSL/TLS
IPSec
S/MIME
Certains PKCS
...

RSA fait partie de nombreux staldards comme :

ISO 9796
ITU-T X.509 (standard sécurité)
ETEBAC 5 (standard français du secteur bancaire et financier)
ANSI X9.31 rDSA
X9.44 draft (standard américain du secteur bancaire et financier)
AS2805.6.5.3 (standard de gestion des clés australien)
SWIFT (standard interbancaire international)

Les principes de Kerckhoffs

cryptosec — 2003-02-19T17:25:32Z

En janvier 1883, Auguste Kerckhoffs (1835 - 1903) posa les principes de la cyptographie moderne dans l'article "La cryptographie militaire" paru dans le "Journal des Sciences Militaires". Ces principes, et en particulier le second qui stipule que la sécurité résultant de l'utilisation d'un cryptosystème ne doit pas reposer sur le secret de ses principes de conception ou du paramétrage du dispositif, suggérant (à la lecture des autres points) qu'elle doit uniquement reposer sur une clé secrète, restent de toute actualité.
A ce titre, par exemple, le choix du dernier standard de chiffrement par le NIST, l'algorithme symétrique AES, est exemplaire : il a été choisi suite à un appel à contribution public, et tous ses détails de conception sont publics (le choix et la conception du DES n'avait pas été aussi transparent).
Ainsi, ce principe explicite le fait qu'un algorithme sera d'autant plus résistant et pérenne qu'il aura été conçu, choisi et implémenté avec la plus grande transparence, s'offrant à l'analyse de l'ensemble de la communauté cryptographique.
Dit autrement, toute attaque doit être envisagée en supposant que l'attaquant connaît tous les détails du cryptosystème
De plus, ces principes, étape de la longue histoire des codes secrets, donnent un peu de perspective aux domaines de la cryptographie et de la sécurité logique, l'ancrent par leur actualité dans une réalité dont les dites "nouvelles technologies" ne sont qu'une étape après bien d'autres.

A l'adresse http://www.cl.cam.ac.uk/ fapp2/kerckhoffs/ vous pourrez trouver une version numérisée de l'article, dont je reproduit ci-après les six principes qui nous intéressent :

Seconde partie, "Desiderata de la cryptographie militaire" (p. 12) :
" 1- Le système doit être matériellement, sinon mathématiquement, indéchiffrable ;

2- Il faut qu'il n'exige pas le secret, et qu'il puisse sans inconvénient tomber entre les mains de l'ennemi ;

3- La clef doit pouvoir en être communiquée et retenue sans le secours de notes écrites, et être changée ou modifiée au gré des correspondants ;

4- Il faut qu'il soit applicable à la correspondance télégraphique ;

5- Il faut qu'il soit portatif, et que son maniement ou son fonctionnement n'exige pas le concours de plusieurs personnes ;

6- Enfin, il est nécessaire, vu les circonstances qui en commandent l'application, que le système soit d'un usage facile, ne demandant ni tension d'esprit, ni la connaissance d'une longue série de règles à observer. "

Pour illustrer l'actualité de ces principes, et sans craindre aucun anachronisme, passons en revue chacun des points en proposant des analogies qui pourraient être des principes à respecter de nos jours, avec nos technologies. Il s'agit bien de cryptosystèmes et non uniquement d'algorithmes, c'est à dire de l'ensemble constitué des algorithmes, des implémentations, des standards utilisés, des protocoles mis en place, des interfaces utilisateur, des modalités d'intégration, des support physiques ou logiciel, des cellules de support, veille et formation, des documentations... bref, de l'ensemble des composants (techniques et humains) qui constituent un cryptosystème au sens large du terme.

Premier point :
Le système doit offrir un niveau de sécurité suffisant au regard de celui voulu pour le traitement des informations. Il n'est pas nécessaire qu'il soit inconditionnellement sûr, mais toutes les garanties qu'il est possible de donner quant à la sécurité du système doivent être apportées affin de s'assurer qu'il atteint un niveau suffisant.

Deuxième point :
La sécurité du système ne doit pas reposer sur le secret de sa conception. Ses spécifications et détails de fonctionnement doivent pouvoir être rendus publics. C'est là un principe phare en cryptographie, puisque les spécifications de la plupart des algorithmes sont publiques. Dans le même ordre d'idée, on peut considérer qu'il doit être possible de révéler sans état d'âme le code source d'un cryptosystème.
Encore une fois, toute attaque contre le cryptosystème doit être envisagée en considérant que l'attaquant connaît tous les détails de conception du système cible.

Troisième point :
L'analogie que l'on peut voir ici est l'importance de faire en sorte que les utilisateurs disposent de codes d'authentification efficaces et ergonomiques (cartes à puces, bonne politique de mots de passe...). Pour ce qui est de l'échange des clés, l'apparition de la cryptographie asymétrique, puis des certificats qui encapsulent les clés publiques, apporte une solution élégante, sûre et efficace. Stricto sensu, ce troisième point fonde le principe de l'utilisation des clés secrètes, seul paramètre variable dont dépend la sécurité.

Quatrième point :
Biensur, nous sommes aujourd'hui passés à d'autres moyens de communication. Cependant, il faut faire en sorte que le système prenne en entrée et renvoie après traitement des données conformes aux formats et standards en vigueur. En particulier les standards et protocoles ouverts de l'IETF, les RFC.

Cinquième point :
Aujourd'hui, il ne s'agit biensur pas de transporter une machine. Cependant, l'idée sous-jacente est que le système doit pouvoir être utilisé quel que soit l'endroit ou l'on se trouve, ce qui fait écho à des notions telles que la mobilité des profils, l'utilisation de cartes à puce...

Sixième point :
Ce dernier point reste aujourd'hui tout a fait primordial. Il s'agit de s'attacher, lors de la conception, l'implémentation et l'intégration d'un système de sécurité à lui donner une ergonomie qui soit la meilleure possible. Un système qui donnera aux utilisateurs l'envie de l'utiliser, qui sera simple d'accès, qui ne bouleversera pas outre mesure ses habitudes de travail, sera d'autant mieux utilisé, et la sécurité effective en sera donc d'autant meilleure.

Conclusion
Qu'il s'agisse de concevoir des algorithmes, des cryptosystèmes, de les implémenter, de les développer, ou de les déployer, on voit bien l'intérêt qu'il y a, plus d'un siècle après leur définition, à considérer et essayer de respecter les principes de Kerckhoffs.

Certificats X509 v3

cryptosec — 2003-01-29T23:00:00Z

Généralités :
L'objet d'un certificat est de certifier une clé publique. Pour utiliser une clé publique il faut être sûr de l'identité de son détenteur. La première méthode est d'avoir une relation de confiance directe avec son détenteur, comme dans le modèle "web of trust" associé à PGP ou GPG. La deuxième méthode repose sur le principe que tous les interlocuteurs ont confiance en un tiers, qui certifiera les clés en les signant. X509 est un standard définissant le format des certificats émis par ces tiers, ou émetteurs de certificats (Certificate Authority, CA ne anglais). Il est à noter que l'utilisation de certificats ne fait que reporter la question de la confiance (en bout de chaîne, il y a forcément un émetteur qui s'auto-certifie, en qui la communauté cible des utilisateurs doit avoir confiance). Il appartient aux émetteurs de certificats, ou autorités de certification, de s'assurer que telle clé appartient bien à telle personne (ou entité), et de publier les procédures définissant cette assurance (politiques de certification). Lorsqu'un groupe précis d'utilisateurs n'a pas la main sur l'AC ou la PKI (ou encore ICP, Infrastructure à Clés Publiques), on peut émettre des réserves sur la sécurité de l'émission et de la gestion des certificats. Les émetteurs de certificats sur internet ne sont pas, selon moi, la panacée. En particulier lorsqu'ils n'émanent pas d'institutions légitimes, en qui l'on peut avoir confiance. Lorsqu'en plus ces émetteurs se retrouvent en situation de quasi monopole...

Les certificats X509, version 3, sont utilisés (entre autres) dans les applications, protocoles et standards suivants : SSL/TLS, IPSec, S/MIME, SET, chiffrement, authentification, signature, non-répudiation, horodatage...

Les certificats X.509 en sont à la troisième version. (quatrième maintenant ; 30.01.03) La première date de 1988 et la seconde de 1993. Avec la version 3 sont apparues les extensions, champs qui permettent de rendre l'utilisation des certificats beaucoup plus flexible. C'est aussi ce qui les rend bien souvent incompatibles entre eux.

Détail des certificats :
Un certificat contient les données suivantes : Version du certificat Numéro de série du certificat Description de l'algorithme de signature de l'AC Nom de l'AC qui a généré le certificat Période de validité Nom de l'utilisateur auquel appartient le certificat Valeur de la clé publique Description de l'algorithme à utiliser avec la clé publique Identification alternative de l'AC (optionnel) Identification alternative de l'utilisateur (optionnel) Extensions (optionnel) Signature de l'AC

Les champs exacts des certificats X.509v3 sont les suivants :

(les versions auxquelles sont apparus ces champs sont entre parenthèses) :

Certificate format version (v1)

Ce champ donne la version du certificat : 1, 2 ou 3. Dans la pratique, il n'a en général pas d'implications pour l'interprétation.

Certificate serial number (v1)

Numéro de série unique, dans le domaine de confiance auquel appartient le certificat, qui l'identifie de façon unique. C'est ce numéro de série qui sera posté dans la liste de révocation en cas de révocation.

Signature algorithm identifier for CA (v1)

Désigne le procédé utilisé par l'AC pour signer le certificat : (norme ISO). Il s'agit d'un algorithme asymétrique et d'une fonction de condensation. Un exemple est : RSA with SHA-1. Cette information étant répétée dans le champ CA signature (le dernier), il n'est pas forcément d'une grande utilité.

Issuer X.500 name (v1)

Spécifie le DN (Distinguished Name) dans la norme X.500 de l'AC qui a généré le certificat. Un exemple est : c=FR, o=Boite

Validity period (v1)

Donne les dates de début et de fin de validité du certificat. Un logiciel client utilisant les certificats doit impérativement vérifier ces dates avant utilisation, et rejeter le certificat s'il est expiré. Cela ne suffit cependant pas, car cela dépend de l'horloge de la machine cliente. On peut avoir recours à la consultation des CRL (ou LCR, Liste de Certificats Révoqués), où peut être mise l'information concernant l'expiration.

Subject X.500 name (v1)

Spécifie le DN dans la norme X.500 (... un reste -judicieux- des télécoms) de l'utilisateur possédant la partie privée de la clé publique contenue dans le certificat. Un exemple est : c=FR, o=Jussieu, cn=Marie Curie

Subject public key information (v1)

C'est le coeur du certificat. Ce champ contient la valeur de la clé publique du détenteur du certificat et les algorithmes avec lesquels elle doit être utilisée RSA with MD5 par exemple

Issuer unique identifier (v2)

Ce champ optionnel, qui est apparu en v2, permet de donner une seconde identification au Issuer X.500 name (l'AC) dans le cas ou celui-ci à un DN commun avec une autre AC.

Subject unique identifier (v2)

Ce champ optionnel, qui est apparu en v2, permet de donner une seconde identification au Subject X.500 name (l'utilisateur) dans le cas ou celui-ci à un DN en commun à un ou plusieurs autres utilisateurs.

Extensions : Type, Criticality, Value (v3)

Chaque extension est constituée de 3 champs :

Type : Décrit le format du champ Value. Ce peut être un nombre, une chaîne de caractères, des données complexes...

Criticality : C'est un flag d'un bit. Si une extension est marquée comme étant critique, une application qui ne saurait qu'en faire devrait en principe rejeter le certificat. Peut créer des problèmes d'interopérabilité.

Value : Contient la valeur des données de l'extension. Celle-ci peut être un texte, une date ou même une photo (mais là, c'est quand même du vice...).

CA signature (v1)

C'est la signature de l'autorité de certification (CA). Cette signature est effectuée en passant l'ensemble du certificat au travers d'une fonction de condensation puis en chiffrant le résultat à l'aide de la clé privée de l'autorité de certification.

Les extensions X.509v3 :

Dans le standard X.509v3, il y a des extensions dites standard. Les extensions sont très importantes dans les certificats, puisqu'elles les rendent flexibles et "ajustables" à souhait (tel certificat ne peut servir que pour telle application par exemple). Mais elles sont aussi source d'incompatibilité (telle application va rejeter un certificat si elle n'y trouve pas l'extension qu'elle attend). En développant un logiciel utilisant des certificats on peut cependant l'autoriser à ne pas prendre en compte telle ou telle extension.
Par "ajustable", on entend en fait la possibilité pour une AC ou une PKI de définir une politique de sécurité de l'AC ou de la PKI. Dans cette optique, la politique peut spécifier que tel certificat ne pourra être utilisé qu'à cet usage ou définir toute autre contrainte qui rendra incompatibles des certificats émis par d'autres AC.

On peut les grouper en quatre types :

1) Informations sur les clés

2) Informations sur l'utilisation du certificat

3) Attributs des utilisateurs et des AC

4) Contraintes sur la co-certification

Dans le détail, ça donne :

1) Informations sur les clés :

Ce groupe d'extensions, qui renseigne sur l'utilisation qui doit être faite de la clé publique et du certificat, est constitué de quatre champs :

Authority Key Identifier : Ce champ identifie de façon unique la paire de clé utilisée par l'émetteur de certificats pour signer le certificat. Il peut être utilisé par une application pour faciliter le processus de vérification de la signature du certificat dans le cas ou l'AC à utilisé plusieurs clés depuis sa mise en service.

Subject Key Identifier :

Ce champ identifie de façon unique la paire de clé dont la clé publique est contenue dans le certificat. Il peut être utile si l'utilisateur possède un historique de clés (c'est à dire que ses clés ont été renouvelées une ou plusieurs fois). Par exemple, pour déchiffrer un document chiffré avec une clé qui n'est plus celle en cours de validité, ce champ permet de retrouver rapidement la bonne clé privée.

Key usage :

Ce champ renseigne sur l'utilisation qui doit être faite de la clé. Si le champ criticality de cette extension est à TRUE, alors la clé ne doit être utilisée que dans le but spécifié, et toute autre utilisation serait contrevenir à la politique de l'AC ou de la PKI. Si le champ criticality de cette extension est à FALSE, alors le champ Key usage est là à titre indicatif pour faciliter les processus par exemple. Le champs Key usage peut avoir les valeurs : non-repudiation certificate signing CRL signing digital signature data signature symetric key encryption for key transfer Diffie-Hellman key agreement Private Key Usage Period :

Ce champ donne la date d'expiration de la clé privée associée à la clé publique contenue dans le certificat. Il est en général utilisé pour les clés privées de signature (et donc contenu dans les certificats de signature dans le cas ou ils sont distincts de ceux de chiffrement), qui peuvent expirer, ce qui n'est pas le cas des clés privées de déchiffrement (il doit toujours être possible de déchiffrer des données, même si celles-ci ont été chiffrées avec une clé publique qui est maintenant expirée).

2) Informations sur l'utilisation du certificat :

Ce groupe d'extensions, qui contient deux champs, permet à un émetteur de certificats de spécifier les façons dont un certificat doit être utilisé, en accord avec la politique qu'il a définie (PC). Les deux champs sont : Certificate Policies et Policy Mappings.

Certificate Policies :

Ce champ peut donner, soit la politique de certification qui a présidé à l'émission du certificat, soit les utilisations qui doivent être faites du certificat. Il peut spécifier ces deux informations à la fois.
Les politiques de certificats sont représentées par des Object Identifier (OID), qui sont des séries de nombres séparées par des points. Ces OID sont enregistrées au niveau international, et leur utilisation est standardisée. Un certificat peut contenir plusieurs OID, pourvu qu'elles ne soient pas incompatibles.
Si ce champ est marqué comme étant critique, l'émetteur de certificats impose que le certificat soit utilisé conformément à la politique de certification. Dans le cas contraire, l'information est indicative ("ce certificat devrait être utilisé dans tel but" par exemple)... Libre à l'application cliente (son implémentation ou sa configuration) de respecter ou pas la criticité.

Policy Mappings :

Ce champ ne concerne que les co-certificats (le certificat émis par une AC pour certifier la clé publique (le certificat) d'une autre AC). Il permet d'associer la politique de certification de l'AC qui émet le certificat à la politique de certification indiquée dans le co-certificat. S'il est défini comme critique, il permet aux applications qui vérifient un certificat appartenant à une chaîne de certification de s'assurer qu'une politique de certification acceptable s'applique à tous les certificats.

3) Attributs des utilisateurs et des AC :

Ce groupe d'extensions (3 champs) permet de mieux spécifier l'identification des utilisateurs et des certificats.

Subject Alternative Name :

Ce champ spécifie un ou plusieurs noms uniques et supplémentaires pour le détenteur du certificat. Ils peuvent être utilisés dans les applications de messagerie, web, réseau où il peut être très utile d'identifier un utilisateur, ou une machine, autrement que par un DN. Les noms autorisés sont : Une adresse mail Un nom de domaine Une adresse IP Une adresse mail X.400 Un nom EDI Une URL Un nom défini par une OID Issuer Alternative Name :

Ce champ permet de donner un nom spécifique à une AC, et les noms autorisés sont les mêmes que ceux du champ précédent.

4) Contraintes sur la co-certification :

Les trois extensions de ce groupe permettent de limiter et contrôler la confiance envers d'autres AC en cas de co-certification.

Basic Constraints :

Ce champ indique si l'utilisateur est un utilisateur final ou s'il peut être une AC. S'il peut être AC, le certificat est alors un co-certificat. On définit alors une " distance de certification ". Elle spécifie jusqu'où doit remonter une application qui veut vérifier un certificat en consultant sa CRL, et jusqu'ou est étendue la confiance dans la chaîne. Si cette distance est par exemple à 1, les utilisateurs ne peuvent que vérifier les certificats émis par l'AC défini dans le co-certificat.

Name Constraints :

Ce champs n'est utilisé que dans les co-certificats, et permet aux administrateurs de restreindre les domaines de confiance dans un domaine de co-certification. Supposons que ce site émette des certificats à mes amis, avec des noms du type : c=FR, o=cryptosec, cn=[mes amis]. J'ai un ami qui fait de même. Il émet des certificats à ses visiteurs, avec des noms du type c=FR, o=mantis, o=amis, cn=[ses visiteurs] et à ses amis, avec des noms du type c=FR, o=mantis, o=amis, cn=[ses amis]. Je veux me co-certifier avec lui, et comme c'est un ami, je fais confiance à ses amis. Mais je ne fais pas confiance à ses visiteurs. Je vais donc émettre un co-certificat qui ne va être valide que pour les certificats émis dans la branche c=FR, o=mantis, o=amis, cn=[ses amis].

Policy Constraints :

Ce champ s'applique aux co-certificats, et permet de spécifier les politiques de certification acceptables pour les certificats dépendants du co-certificat.

Pour lire un certificat, il faut lire l'ASN.1 (Abstract Syntax Notation)

C'est une grammaire abstraite qui permet de représenter des objets ou des messages. ASN.1 permet de représenter des types de données simples comme des entiers ou des types plus complexes de données comme des séquences ou des données représentées par la combinaisons de types simples.
Le codage BER (Basic Encoding Rules), ou son dérivé DER (Distinguished Encoding rules), est utilisé pour représenter concrètement les données ASN.1 en tableaux d'octets. Les codages BER et DER sont indépendants des plate-formes utilisées, ce qui permet d'échanger sans problème des données. Pour développer il existe des " compilateurs " ASN.1, et l'on travaille souvent sur des objets ASN.1 sans avoir à se plonger dans le codage lui même (voir SSLeay qui fournit ce genre de librairies).

Dans le cas d'un certificat, le codage DER en réduit les champs de données à des listes d'éléments simples (comme des entiers, des chaînes de caractères) où à des combinaisons complexes de ces derniers. Chaque champ est ainsi décomposé en un triplet : tag, lenght et value.

tag donne le type de donnée par une convention définie par l'ISO.

lenght donne la longueur du champ " value "

value est une série d'octets qui représente les données.

Afin de permettre l'édition des certificats, l'envoi de ceux-ci par des messageries simples ou les opérations de "copier-coller" requises par certaines applications, les octets ainsi obtenus sont codés en base-64.
Lorsqu'une application va utiliser un certificat, elle appliquera évidemment le processus inverse auparavant.

Attaques et failles

cryptosec — 2002-04-15T15:14:42Z

Généralités :
Il est difficile de dresser un panorama de la cryptanalyse ou des attaques sur les logiciels. Ce sont des domaines très éclectiques, qui bougent très rapidement. Chaque attaque est en général très liée au sujet de l'attaque : l'algorithme, le protocole, le logiciel... Ca ressemble plus à de l'artisanat qu'à de l'industrie, dans le sens que l'on refait rarement deux fois la même chose. Il n'y aura donc sur cette page que le principe de quelques attaques présentées de façon succincte, pour donner une idée.
Dans tous les cas on n'examine que les systèmes qui se conforment aux principes de Kerckhoff, qui stipulent que l'attaquant connaît tous les détails de l'algorithme : ils peuvent être considérés comme des principes de base pour la conception d'algorithmes et de cryptosystèmes, le contraire de la sécurité par l'obscurité.
Le but est de trouver la clé, ce qui est parfois équivalent à trouver le chiffré, mais souvent plus ambitieux.

Attaque ou l'on essaye de deviner le texte clair (en asymétrique) :
L'attaquant dispose d'un texte chiffré et choisit un texte clair. Il chiffre ce texte clair à l'aide de la clé publique de la victime, dans le cas d'un algorithme à clé publique. En comparant le résultat avec le texte chiffré dont il dispose, il peut déterminer si sa supposition était correcte.
La victime de ce type d'attaque peut s'en prémunir en ajoutant aux données qu'il chiffre des bits aléatoires. Ce procédé permet de se prémunir d'autres types d'attaques, comme celle exploitant le fait qu'un groupe d'utilisateurs partagent la même valeur de e pour RSA par exemple.

Cryptanalyse différentielle :
Cette méthode récente (1990) est une attaque à texte clair choisi, initialement faite sur le DES. On choisit deux textes clairs avec des différences connues (l'opérateur étant le XOR), puis on analyse l'évolution des différences entre les textes chiffrés avec une même clé à chaque ronde. En regardant les différences finales entre les paires de textes chiffrés on donne diverses probabilités aux clés testées. En affinant, on arrive à la clé la plus probable.
Cette attaque est d'autant plus efficace que le nombre de rondes est réduit (sur 8 au lieu de 16 pour le DES ça marche pas mal).
Evidemment, les détails sont un peu plus compliqués. Voir les bouquins pour plus de détails. La NSA, avec une dizaine d'années d'avance sur la recherche publique, connaissait ce type d'attaque. DES, que la NSA à contribué à concevoir (notamment les tables-S) avait notamment été protégé contre cette attaque.
Il est à noter que cette attaque nécessite un nombre impressionnant de couples clairs/chiffrés... ce qui la rend infaisable dans la plupart des cas réels.

Cryptanalyse linéaire :
Je n'ai pas regardé le sujet d'assez près. Ce qu'en dit Schneier c'est qu'elle "utilise des approximations linéaires pour décrire l'action d'un algorithme de chiffrement par blocs". La conception du DES ne le protège pas particulièrement contre cette attaque, encore plus récente que la différentielle.
Le nombre de textes clairs connus requis est faramineux, et rend aussi cette attaque malaisée dans le réalité.

Recherche exhaustive
C'est la méthode la plus répandue : on prend un couple clair/chiffré, et on essaye toutes les clés jusqu'à trouver la bonne.
Pour un DES simple (clé de 56 bits), on trouvera en moyenne la bonne clé au bout de 2^55 essais.
Cette attaque n'est efficace que dans le cas ou toutes les clés sont équiprobables : dans le cas de la factorisation ou de l'exponentiation modulaire (RSA ou Diffie-Hellman), ce n'est certainement pas l'attaque la plus efficace, parce ce que tous les éléments de l'espace des clés n'ont pas la même probabilité d'être des clés.
Trouver des couples clairs/chiffrés n'est pas si compliqué qu'il y parait : les entêtes des fichiers chiffrés, ou les premiers termes d'un protocole de communication sont souvent connus.
Pour la taille des clés et la recherche exhaustive, voir la FAQ de Thomas Pornin.
Pour la meilleure attaque contre le DES pour le moment, voir http://www.eff.org/descracker(ils ont construit une machine dédiée pour 250000 $ qui trouve une clé DES-56 en moins de 3 jours, et en 22 h 15 m accompagnée de 100000 PC sur internet...)
Pour les meilleures attaques contre RSA (qui ne sont pas des recherches exhaustives...), voir http://www.rsasecurity.com/rsalabs/challenges/factoring/faq.html

Attaques contre la conception des systèmes cryptographiques...
Les algorithmes au coeur d'un système cryptographique peuvent être sûrs et bien conçus, mais la façon de les agencer et de s'en servir peut être source de failles de sécurité. Nombre de sociétés, dont la crypto et/ou la sécurité n'est pas le métier, ne se privent par exemple pas de récupérer sur internet des sources libres d'algorithmes (fonctions de chiffrement par blocs, fonctions de chiffrement asymétrique, fonctions de hachage...) et des les implémenter rapidement, sans vérifications, conformément au business plan qui veut toujours que le produit aurait du sortir avant-hier...

Quelques points qui peuvent par exemple être considérés :

Le choix des algorithmes est-il judicieux ? (par exemple, prendre des algorithmes secrets ou faits "maison" prive de l'analyse de la communauté cryptographique, et l'algorithme contient peut-être des faiblesses qui pourraient rapidement être détectées...)
Les générateurs pseudo-aléatoires sont-ils sûrs et bien implémentés ? (les prochaines générations de processeurs devraient en contenir des physiques)
Les cas particuliers sont-ils écartés ? (clés faibles, protocoles initialisés à "algo = NULL"... ça arrive)

Tous les tests nécessaires ont-ils été effectués ? (conformité aux spécifications, résistance, comportement face à des valeurs d'entrée originales...)

Est-on sûr que les valeurs aléatoires ne sont jamais réutilisées ?

La gestion des clés est-elle bien faite (non réutilisées, effacées de façon sûre...)

Les tailles de clés utilisées sont-elles conformes aux besoins de sécurité et cohérentes (entre asymétrique et symétrique par exemple) ?

Les fichiers temporaires sont-ils toujours efficacement "nettoyés" en cas de chiffrement (par réécriture multiple par exemple) ?

Les protections par mot de passe sont-elles bonnes (imposition possible de règles strictes, bonne implémentation, activée par défaut...)

Comment réagit le système en cas de plantage de la machine au cours d'une opération cryptographique ? Les erreurs sont-elles bien gérées ? (j'ai vu des logiciels qui laissaient des copies temporaires en clair sans en avertir l'utilisateur)
Les protocoles et formats (IPSec, SSL, S/MIME...) sont-ils correctement choisis, implémentés et utilisés ?

Les environnements sont-ils sûrs et homogènes ? (à quoi bon protéger un site web par SSL sur le port 443 si le même contenu est accessible sans trop de difficultés sur un autre port... ?)

Les interfaces graphiques ne présentent-elles pas des failles fonctionnelles (des erreurs de configuration que pourrait faire l'utilisateur par exemple) ?

Attaques contre les systèmes obscurs
La vanité, la peur de révéler des secrets de conception, l'urgence ou l'ignorance pousse souvent des entreprises commerciales à tenir leurs sources et spécifications secrètes. Cela prive leurs algorithmes de l'analyse de la communauté cryptographique... et entraîne parfois de grosses bévues. Parmi les meilleurs exemples de cette calamiteuse "sécurité par l'obscurité" sont les algorithmes de chiffrement des GSM (A5/1) et celui des DVD (DeCSS DVD).

IPSec

cryptosec — 2002-04-04T22:00:00Z

Généralités :

C'est un protocole développé par l'IETF qui a pour but de sécuriser TCP/IP, de façon standardisée et donc intéropérable (c'est du moins un des buts du standard). Par l'authentification et le chiffrement des paquets IP, IPSec permet de sécuriser toute transmission de données reposant sur TCP/IP (contrairement à SSL, il n'est pas nécessaire de lancer des processus particuliers, sur des ports particuliers... https sur 443 et ftps 990 par exemple, correspondant aux couches supérieures).
IPSec est un protocole particulièrement complexe.

Les principales implémentations d'IPSec se retrouvent dans les logiciels et matériels de VPN (Virtual Private Network).
De plus en plus de logiciels et d'OS commencent cependant à implémenter IPSec comme fonctionnalité de base. La prochaine version d'IP, IPv6, inclura les mécanismes IPSec. Malgré sa complexité, IPSec semble pour l'instant amené à s'imposer pour ce qui relève de la sécurité réseau bas niveau (confidentialité, authentification, intégrité, filtrage...).
Il y a deux types de transformations qui constituent les éléments fondamentaux d'IPSec :
le Authentication header (AH) et l'ESP (Encapsulating Security Payload).
Ces transformations structurent les données IP sécurisées en une Security Association (SA).

Authentification Header (AH) :

Cette transformation authentifie, protège en intégrité les datagrammes IP (y compris les champs des entêtes qui ne varient pas lors de la transmission) et assure une protection " anti-replay " (chaque paquet est numéroté par le champ " Sequence Number " de l'entête AH), et les paquets rejoués ne sont pas pris en compte). Elle n'apporte cependant pas de confidentialité.
Coté expéditeur, cette transformation consiste en un MAC qui est calculé sur l'ensemble du datagramme, et dont le résultat est ensuite joint au datagramme.
Coté destinataire, il suffira de recalculer le MAC afin de vérifier l'authenticité et l'intégrité des données.
Les transformations AH peuvent se faire en mode transport ou en mode tunnel, et obéissent aux spécifications définies dans les Security Association.
En mode transport, l'entête originale du paquet IP sera celle du paquet sécurisé :

En mode tunnel, une nouvelle entête IP est créée pour chaque paquet sécurisé. C'est ce mode qui est typiquement utilisé dans les logiciels ou boîtiers VPN pour connecter deux réseaux par exemple.

Encapsulating Security Payload (ESP) :

La transformation ESP permet d'assurer la confidentialité, l'authentification et l'intégrité des datagrammes IP en les chiffrant conformément à ce qui est défini par les Security Association. ESP assure aussi une protection contre le rejeu des paquets, grâce au champ " Sequence Number " de l'entête ESP.
Les transformations ESP chiffrent des portions des datagrammes, peuvent encapsuler ces portions dans d'autres datagrammes IP et peuvent effectuer des contrôles d'intégrité via un Integrity Check Value (ICV).
Tout comme AH, l'ESP peut se décliner en mode transport. L'entête IP du datagramme original est conservé et les autres champs sont sécurisés et précédés d'une entête ESP :

En mode tunnel, une nouvelle entête IP est générée, précédent le datagramme sécurisé, et ne contenant aucune option IP, même si l'entête initiale en contenait. Ce mode est typiquement utilisé pour les communications d'hôte à hôte (gateway-to-gateway), où il permet de masquer les adresses IP des expéditeurs et destinataires originaux :

Security Association (SA) :
Une Security Association définit quelles sont les transformations IPSec qui devront être appliquées aux datagrammes, et comment elles devront être faites.
Une SA spécifie :

s'il s'agit d'une protection AH ou ESP

l'algorithme d'authentification pour AH et ESP

l'algorithme de chiffrement pour ESP

les clés d'authentification et de chiffrement

la durée de vie des clés de chiffrement

la durée de vie de la SA

l'authentification des parties

la période de modification des clés

la séquence des nombres anti-rejeu et la table des bits associée.

La taille et le contenu d'une SA sont spécifiées par les transformations. Une SA peut-être statique ou dynamique. Dans le premier cas elle ne contient que des données qui ne sont pas modifiées pas la transformation. Dans le second cas, les données peuvent être mises à jour par la transformation chaque fois qu'un datagramme est utilisé, comme par exemple dans la protection contre le rejeu par le numérotage des paquets ou les fonctionnalités de compression.

Lors de la négociation d'une SA, un nombre de 32 bits appelé Security Parameters Index (SPI) est attribué pour la désigner. Pour désigner une SA lors des transformations AH ou ESP on utilisera un SPI.

Un exemple typique d'une SA peut être :

SPI : 314159
Encryption algorithm : IDEA
HMAC algorithm : SHA1
Encryption key : 0x56d6eed...
HMAC key : 0xdd36fdd6...
Expiry : 22:22:22 17Aug2000

Algorithmes utilisés :

Pour le chiffrement, les algorithmes valides pour une négociation sont :

DES CBC

Triple DES

RC 5

IDEA

Blowfish

CAST

NULL (la possibilité de ne spécifier aucun chiffrement peut parfois être utile)

Pour l'authentification et l'intégrité, les algorithmes possibles sont :

HMAC-MD5

HMAC-SHA-1

HMAC-RIPEMD-160

HMAC-DES

Keyed MD5

ISAKMP/Oaklay :

Avant qu'une communication sécurisée puisse s'établir, il est nécessaire que les parties en présence en négocient les termes, qui seront définis dans la Security Association (SA). Le protocole utilisé pour négocier (établir, négocier, modifier et effacer) les SA est Internet Key Exchange (IKE).
IKE combine le Internet Security Association et le Key Management Protocol (ISAKMP) avec l'échange de clés Oaklay utilisant Diffie-Hellman.
ISAKMP est un ensemble de règles pour établir, négocier, modifier et effacer les paramètres spécifiques à une connexion (la SA, qui n'est en principe pas limité à IPSec mais c'est pour l'instant son seul domaine d'application).
Oaklay est une application de ISAKMP pour la génération des clés et des SA IPSec.

Les modes ISAKMP/Oaklay :
IKE se déroule en deux phases.
Le but de la première phase est d'établir un canal sûr et authentifié entre les parties qui s'apprêtent à négocier. Elle établit une SA pour ISAKMP.
La phase deux est utilisée pour établir une SA pour IPSec.
Elle est effectuée plus rapidement après que la première phase ait été faite, ce qui compense le désavantage d'avoir à effectuer deux phases.
Lors de la première phase, pour établir la SA, il y a deux modes possibles : le mode Général et le mode Agressif.
Ces deux modes font la même chose, le mode Agressif est plus rapide mais ne protège pas l'identité des parties qui négocient.
Le mode rapide est utilisé pour établir la SA de la deuxième phase, et est plus rapide après que la négociation de la phase un ait été faite.

Mode général ISAKMP/Oaklay :

Dans le mode général, les parties en présence utilisent les deux premiers messages pour négocier la politique de sécurité qui s'appliquera à l'échange. Les deux messages suivants établissent une clé Diffie-Hellman et échangent des valeurs aléatoires qui serviront à signer et s'authentifier. Les deux derniers messages servent à authentifier les parties grâce à des signatures, des condensâts et éventuellement par transmission de certificats.

Mode agressif ISAKMP/Oaklay :

En gros, ce mode ressemble beaucoup au précédent sauf qu'il y a moins d'échanges. La politique proposée, les données passées pour l'échange de clé et la valeur aléatoire sont passées lors du premier message. Le deuxième message est la réponse qui authentifie le répondeur, conclut la politique et l'échange de clé. Le dernier message authentifie l'initiateur de l'échange.

Mode rapide ISAKMP/Oaklay :

Le mode rapide est utilisé pour négocier les services de sécurité IPSec et générer de nouvelles clés. Un nouvel échange de clés Diffie-Hellman peut être réalisé, mais ce n'est pas obligatoire. Sinon, les parties génèrent simplement de nouvelles clés à l'aide de condensats et s'identifient mutuellement à l'aide de valeurs aléatoires

Les RFC : c'est parfois abscons mais (presque) tout y est spécifié...

RFC 2401 : Security Architecture for the Internet
RFC 2402 : IP Authentication Header
RFC 2403 : The Use of HMAC-MD5-96 within ESP and AH
RFC 2404 : The Use of HMAC-SHA-1-96 within ESP and AH
RFC 2405 : The ESP DES-CBC Cipher Algorithm
RFC 2406 : IP Encapsulating Security Payload (ESP)
RFC 2407 : The Internet IP Security Domain of Interpretation for ISAKMP
RFC 2408 : Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409 : The Internet Key Exchange (IKE)
RFC 2410 : The NULL Encryption Algorithm and Its Use With IPsec
RFC 2411 : IP Security
RFC 2412 : The OAKLEY Key Determination Protocol

SSL-TLS

cryptosec — 2002-04-03T09:56:44Z

Généralités :

SSL (Secure Socket Layer) est un protocole à négociation (on parle du " handshake " SSL), développé à l'origine par Netscape.
Il a pour but de sécuriser les transactions Internet, par authentification du client (un navigateur la plupart du temps) et du serveur, et par chiffrement de la session.

La sécurisation des connexions à l'aide du protocole SSL doit assurer que :
- La connexion assure la confidentialité des données transmises
- La connexion assure que les données transmises sont intègres
- L'identité des correspondants peut être authentifiée
- La connexion est fiable

La version 2.0 vient de Netscape et la version 3.0, qui est actuellement la plus répandue, à reçu les contributions de la communauté internationale.

TLS (Transport Layer Security protocol), développé par l'IETF, est la version 3.1 de SSL.

SSL ne dépend pas des applications utilisées lors des transactions et s'applique sous les protocoles HTTP, FTP, Telnet... etc.
Clients et serveurs commencent par s'authentifier mutuellement, puis négocient une clé symétrique de session qui servira à assurer la confidentialité des transactions. L'intégrité de ces dernières est assurée par l'application de HMAC (Hashed Message Authentification Code).

Principe :

Les clés asymétriques utilisées lors des transactions SSL sont encapsulées dans des certificats X.509 version 3, générés par bon nombre d'autorités de certification ou de PKI.

On distingue deux phases lors du déroulement du handshake SSL :

Authentification du serveur et authentification optionnelle du client.

Première phase :

Suite à la requête d'un client, le serveur envoie au client son certificat et lui liste les algorithmes qu'il souhaite utiliser. Le client vérifie la validité du certificat (à l'aide delà clé publique de l'AC contenue dans son navigateur, des dates de validité et, éventuellement, en consultant une CRL (rarement dans la pratique)), puis, si le certificat est valide, génère une clé maître (symétrique), la chiffre à l'aide de la clé publique du serveur et la lui envoie. Les données échangées par la suite entre le client et le serveur sont chiffrées et authentifiées à l'aide de clés dérivées de la clé maître.

Deuxième phase, optionnelle (et souvent non utilisée) :

Le serveur envoie au client un challenge (une petite série de bits) que le client doit signer, à l'aide de sa clé privée correspondant à son certificat, et le renvoyer au serveur pour s'authentifier. Il lui envoie de même son certificat, que le serveur vérifiera avant de poursuivre les transactions.

Les détails du protocole SSL :

Une session SSL est définie par les paramètres suivants partagés entre un client et un serveur :

Session identifier : un octet fixé par le serveur pour identifier la session
Peer certificat : un certificat pour le serveur, éventuellement un autre pour le client
Cipher Spec : définit l'algorithme de chiffrement symétrique et l'algorithme de condensation
Master secret : clé de 48 octets négociée entre le serveur et le client
Compression method : NULL pour l'instant (en SSLv3 ou TLS)
Is resumable : flag qui indique si de nouvelles connexions peuvent être créées à partir de cette session

Une connexion SSL est définie par les paramètres suivants partagés entre un client et un serveur :

Server and client random : des octets aléatoires déterminés par le client et le serveur pour chaque connexion
Server write (send) MAC secret : clé secrète utilisée par le serveur pour faire les MAC
Client write (send) MAC secret : clé secrète utilisée par le client pour faire les MAC
Server write (send) key : clé symétrique utilisée par le serveur pour chiffrer les données
Client write (send) key : clé symétrique utilisée par le client pour chiffrer les données
Initialization vectors : pour un algorithme de chiffrement par bloc en mode CBC. Le premier est fixé lors du handshake, les suivants sont les derniers blocs des précédents fragments chiffrés
Sequence number : chaque message est numéroté de part et d'autre

Le protocole SSL est constitué des sous-protocoles :

Le protocole SSL handshake
Le protocole SSL Change Cipher Spec (voir la fin du Handshake... c'est le plus court protocole que j'ai rencontré jusqu'à présent... 1 octet !)
Le protocole SSL Alert
Le protocole SSL Record

Le protocole SSL handshake
Ce protocole permet au client et au serveur de s'authentifier mutuellement, de négocier les algorithmes de chiffrement, de négocier les algorithmes de MAC et enfin de négocier les clés symétriques qui vont servir au chiffrement.

Chaque message échangé entre le client et le serveur contient trois champs :
Type, indique l'objet du message (1 octet)
Lenght, indique la longueur du message (3 octets)
Content, contient les données transmises (plus d'un octet)

Phase 1 : Etablissement des paramètres de sécurité
Cette phase à pour but d'établir le lien sécurisé. Les paramètres du premier message, client_hello, envoyé par le client, sont :

Version : la plus haute version de SSL que puisse utiliser le client.

Random : un horodatage de 32 bits et une valeur aléatoire de 28 octets générée par le client. Ces valeurs servent de sel et sont utilisées pour se prémunir contre les rejeux de paquets.

Session ID : Un nombre, qui identifie la connexion. Un zéro signifie la volonté du client d'établir une nouvelle connexion sur une nouvelle session. Un autre nombre signifie la volonté de changer les paramètres ou de créer une nouvelle connexion sur la session existante.

CipherSuite : Une liste, par ordre décroissant de préférence, des algorithmes que supporte le client. Il s'agit des algorithmes d'échange de clé et de chiffrement.
Key Exchange :
RSA (clé symétrique chiffrée avec clé RSA contenue dans un certificat)
Diffie-Hellman (si le certificat serveur contient des paramètres D-H (Diffie-Hellman). Le client n'est pas obligé de présenter un certificat si l'authentification du client n'est pas demandée par le serveur)
Diffie-Hellman temporaire (Une clé symétrique D-H est négociée, les transactions étant signées par des clés RSA ou DSS certifiées par une AC. C'est la plus sûre des méthodes parce que la clé générée est unique et authentifiée)
Diffie-Hellman anonyme (Un simple échange D-H est effectué, sans authentification des partenaires. Vulnérable à "l'attaque du milieu")
Fortezza

CipherSpec :

Cipher Algorithm : DES-40 ; DES, 3-DES, RC2, RC4, IDEA, Fortezza
MACAlgorithm : MD5 ou SHA-1
CipherType : Stream ou Block
IsExportable : True ou False
HashSize : 0, 16 (MD5) ou 20 octets (SHA-1)
Key Material : des octets contenant une partie des données utilisées pour générer les clés.
IV Size : Taille des Vecteurs d'Initialisation pour le chiffrement en mode CBC.

Compression Method : liste, par ordre décroissant de préférence, des algorithmes de compression supportés par le client.

Après avoir envoyé ces requêtes, le client attend que le serveur réponde en générant une valeur aléatoire, en indiquant la version, et les meilleurs algorithmes qu'il peut utiliser : ce sera la réponse server_hello du serveur.

Phase 2 : Authentification du serveur et échange des clés

Lors de cette phase, le serveur commence par envoyer son certificat. Ce message peut contenir une chaîne de certificats X.509. L'échange de clés entre serveur et client n'est possible sans que le serveur n'envoie son certificat que dans le cas d'un Diffie-Hellman anonyme ; dans tous les autres cas, le serveur présente son certificat.
Le serveur envoie un message server_key_exchange si le client et le serveur veulent utiliser du D-H anonyme (un nombre premier, un nombre qui lui est relativement premier et la clé publique D-H du serveur), du D-H temporaire (les paramètres D-H et une signature), du RSA key exchange (ou le serveur n'a qu'une clé RSA pour signer et veut établir une clé RSA temporaire) ou Fortezza. Les signatures sont effectuées en utilisant les fonctions de condensation, comprennent les sels initiaux et sont chiffrées grâce aux clés privées (ceci assure que le serveur détient la clé privée associée à la clé publique que contient le certificat).
Ensuite, le serveur peut demander au client un certificat : c'est le message certificate_request (rarement implémenté dans la réalité), qui comprend les champs certificate_type (algorithme public utilisé) et certificate_authorities (liste des AC valides).
Finalement, le serveur envoie le message server_done, qui signifie la fin de cette phase et que le serveur se met en attente.

Phase 3 : Authentification du client et échange des clés

Le client doit vérifier que le certificat envoyé par le serveur est valide (c'est souvent là que le système est bancal), et que les autres paramètres sont corrects. Si le serveur à demandé au client d'envoyer un certificat, le client envoie un message certificate, contenant le certificat (s'il n'a pas de certificat, il envoie un message no_certificate).
Le client envoie ensuite un message client_key_exchange, qui dépend de l'algorithme choisi :

RSA : le client génère une clé secrète de 48 octets qui servira à générer la définitive, et la chiffre avec la clé publique du serveur.
D-H anonyme ou temporaire : ce sont les paramètres D-H du client qui sont envoyés.
Diffie-Hellman : Dans ce cas les paramètres D-H ont été envoyés avec le certificat, et ce message est donc vide
Fortezza : les paramètres Fortezza...

Pour finir cette phase, le client envoie un message certificate_verify (sauf si le certificat ne contient que des paramètres D-H, i.e. certificat qui ne peut servir à signer). Ce message consiste en un condensât des messages échangés pendant le handshake, de la clé symétrique générée et des pad, le tout signé avec la clé privée du client. Le but de ce message est de s'assurer que le client est bien en possession de la clé privée correspondant à la clé publique envoyée dans le certificat (c'est bien beau de présenter un certificat... si on ne prouve pas que l'on possède la clé privée correspondante).

Phase 4 : Fin

Le client envoie le message (1 octet) change_cypher_spec, qui est en fait l'unique message du protocole Change Cipher Spec, et active pour la session courante les algorithmes, clés et sels du handshake. Puis le client envoie le message finished, qui authentifie le client et valide l'échange de clé (le message est constitué d'un condensât de la clé symétrique échangée, de l'ensemble des messages échangées durant le handshake, du pad et d'un identificateur de l'expéditeur).
Le serveur répond en envoyant son propre change_cypher_spec et clos le handshake.

Le protocole SSL Alert

Ce protocole spécifie les messages d'erreur que peuvent s'envoyer clients et serveurs. Les messages sont composés de deux octets, le premier est soit "warning" soit "fatal". Si le niveau est "fatal", la connexion est abandonnée. Les autres connexions sur la même session ne sont pas coupées mais on ne peut pas en établir de nouvelles.
Le deuxième octet donne le code d'erreur.

Les erreurs fatales sont :
unexpected_message : message non reconnu
bad_record_mac : MAC non correct
decompression_failure : la fonction de décompression à reçu une mauvaise entrée
handshake_failure : impossible de négocier les bons paramètres
illegal_parameter : un champ était mal formaté ou ne correspondait à rien

Les warnings sont :
close_notify : annonce la fin d'une connexion
no_certificate : réponse à une demande de certificat s'il n'y en a pas.
bad_certificate : le certificat reçu n'est pas bon (e.g. signature non valide)
unsupported_certificate : le certificat reçu n'est pas reconnu... vive la compatibilité !)
certificate_revoked : cert révoqué par l'émetteur
certificate_expired : ...
certificate_unknown : tous les problèmes concernant les certificats et non listés au dessus...

Le protocole SSL Record

Ce protocole permet de garantir :

La confidentialité des données transmises (c'est le Handshake qui permet de négocier une clé symétrique partagée)
L'intégrité des données transmises (c'est encore le Handshake qui négocie une clé partagée qui sert à faire des MAC sur les données)

Schématiquement, le protocole SSL Record ressemble à :

Dans l'entête qui est ajoutée :

Content Type : le plus haut protocole utilisé pour traiter ce fragment
Major Version : plus haute version de SSL utilisée (3 pour SSLv3)
Minor Version : plus basse version utilisée (0 pour SSLv3)
Compressed Lenght : la longueur en octets des données (éventuellement compressées) à chiffrer.

Le MAC est fait de la façon suivante (effectué avant chiffrement, puis chiffré) :

HASH(clé partagée||pad_2||HASH(clé partagée||pad_1||numéro de ce massage||protocole pour ce message||longueur de ce message||les données (compressées))

La fonction de condensation (HASH()) est soit MD5 soit SHA-1

pad_1 = 0x36 et pad_2 = 0x5C (répétés 40 fois pour SHA-1 et 48 fois pour MD5)

Les algorithmes autorisés sont :

3-DES 168
IDEA 128
RC4 128
Fortezza 80
DES 56
DES-40
RC4-40
RC2-40

Pour résumer, les protocoles s'assemblent de la facon suivante :

La pratique :

Pour accéder aux services SSL d'un serveur on ajoute habituellement un "s" lors de la spécification du protocole.
Exemple : https://www.monsite.org

Le trafic SSL ne s'accommode pas de l'utilisation de serveurs proxy classiques (cache et réplication) parce que SSL à été conçu pour contrer les attaques dites "de l'homme interposé", et que le proxy va être considéré comme un attaquant. Pour qu'un serveur proxy puisse gérer du trafic SSL, il doit supporter le protocole SOCKS (qui travaille au niveau socket) ou un protocole spécial de tunneling SSL. Netscape Proxy Server par exemple supporte les deux.

Liste des numéros de port associés à SSL :

Protocole Port TCP Description

nsiiops 261 IIOP Name Service sur TLS/SSL

https 443 http sur TLS/SSL

ddm-ssl 448 DDM-SSL

smtps 465 smtp sur TLS/SSL

nntps 563 nntp sur TLS/SSL

sshell 614 SSLshell

ldaps 636 ldap sur TLS/SSL

ftps-data 989 ftp données sur TLS/SSL

ftps 990 ftp controle sur TLS/SSL

telnets 992 telnet sur TLS/SSL

imaps 993 imap4 sur TLS/SSL

ircs 994 irc sur TLS/SSL

pop3s 995 pop3 sur TLS/SSL

Plutôt que des MAC, SSL utilise de HMAC, ou l'on ajoute la clé secrète au données avant de les hacher :

HASH(K,pad2,HASH(K,pad1,text))
Cela rend le hash beaucoup plus sûr.
pad1 et pad2 sont arbitraires (0x36 et 0x5C).

SSL v3 comporte dans la dernière transaction du handshake un condensât de tous les précédentes transactions (cela prémunit de l'attaque de l'homme interposé, qui peut par exemple forcer client et serveur à adopter du 40 bits SSLv2, niveau de chiffrement nettement insuffisant aujourd'hui).

SSL est un protocole de sécurisation des transactions, pas des données enregistrées. Les données obtenues par SSL enregistrées sur un disque local ne sont donc plus chiffrées.

Lors de l'établissement d'une connexion sécurisée SSL, beaucoup de clients SSL, comme Netscape Navigator, vérifient si le "CommonName" indiquant l'identité du site sur le certificat utilisé correspond au nom du site ; s'ils ne correspondent pas, l'application cliente avertit l'utilisateur. Le mieux est donc de donner comme CommonName aux serveurs web leur nom DNS (www.exemple.fr)
Mais toutes les AC n'acceptent pas ce genre de norme.

Il existe une implémentation OpenSource, et d'excellente qualité, de SSL v2.0, v3.0 et TLS 1.0, c'est SSLeay devenue OpenSSL.
La qualité de cette API en fait une des plus utilisée, notamment en conjonction avec Apache. Elle peut dans bien des cas remplacer avantageusement d'autres API (ou spécifications d'API comme GSS par exemple) pour sécuriser divers types de protocoles.

Les problèmes de SSL :

Problèmes liés au client SSL : le navigateur.

Les navigateurs n'ont pas (encore) de fonctionnalités évoluées de gestion des clés :
Les certificats ne peuvent par exemple pas être automatiquement renouvelés et l'historique des clés n'est pas conservé. Quand un certificat expire, l'utilisateur reçoit un message et doit obtenir manuellement un nouveau certificat, ce qui n'est pas forcément trivial pour un utilisateur lambda. Ces problèmes seront probablement résolus lorsque les navigateurs deviendront des clients de PKI à part entière ;-)

La cryptographie utilisée par les navigateurs peut être soumise à des restrictions d'exportation (hors des Etats-Unis par exemple pour Netscape et Microsoft) cela force les utilisateurs à utiliser des clés de longueur insuffisante. Dans le cas de Netscape, on peut renforcer la crypto chez www.fortify.com par exemple... tout en veillant à rester en conformité avec la législation... (on peut aussi y voir quel est la crypto utilisée par son navigateur)

La relation de confiance est définie par la liste préinstallée des autorités de certification :
Les navigateurs du commerce sont livrés avec de nombreuses clés publiques pré-installées (Netscape en contient 33). Celles-ci sont utilisées pour la vérification de la signature de l'autorité de certification pour les certificats d'autres navigateurs ou serveurs. Pour être confirmé, un certificat doit être signé par n'importe laquelle des AC présentes dans le navigateur. Par conséquent, si l'une quelconque parmi les autorités de certification certifie un site frauduleux, ce certificat sera vérifié correctement par des millions de navigateurs. En tant qu'utilisateur, il est important d'aller voir dans les propriétés "sécurité" de son navigateur et de valider la confiance que l'on attribue aux diverses autorités de certification. Par défaut, les navigateurs font confiance à toutes...

Les mots de passe :
Sur MSIE (jusqu'a la version 5.0) le mot de passe protégeant les certificats est optionnel (comme beaucoup de choses... :) alors que protéger sa clé privée est vital.

Problèmes intrinsèques au protocole :

Le système est fondé sur une seule paire de clés :
Le principal problème que cela pose vient de la différence entre les contraintes qui pèsent sur le clés de signature/authentification et celles de chiffrement.
Avoir la possibilité de sauvegarder en central les clés de chiffrement peut s'avérer très pratique (si un utilisateur oublie son mot de passe il n'est par exemple pas nécessaire de régénérer une paire de clé et de la certifier à nouveau, mais on peut simplement lui renvoyer ses clés, en l'obligeant à ressaisir un mot de passe). Si les services d'un tiers sont utilisés pour la sauvegarde d'une unique paire de clé (service offert par certaines autorités de certification ou Tiers de Confiance), le client ne sera plus le seul à avoir accès à sa clé privée de signature et la non-répudiation n'est alors plus assurée.
Certes, gérer deux paires de clés est plus lourd que d'en gérer une seule.
La sauvegarde des clés est importante là où celles-ci sont utilisées pour chiffrer des données stockées, comme des courriers électroniques par exemple. Si les clés ne sont pas sauvegardées et que l'accès aux clés est perdu, les données chiffrées n'ont plus aucune utilité (et si en essayant d'en briser la protection on les récupère quand même, c'est alors l'application crypto qui n'est d'aucune utilité...).
Ce défaut est un peu théorique parce que SSL, dans la pratique, ne chiffre que des flux. Pour un utilisateur "isolé", il est au contraire souhaitable qu'aucune de ses clés privées ne soit ailleurs qu'en sa possession. Mais il est probable que dans l'avenir un même certificat servira à plusieurs types d'opérations cryptographiques, auquel cas ce problème se posera.

Le protocole SSL ne prévoit pas de vérification systématique des CRL :
Lorsqu'un serveur Web présente un certificat, le navigateur en vérifie sa validité ; cela consiste pour lui à :

Vérifier que les dates de validité sont valides
Vérifier que la signature appliquée au certificat est valide

Mais le protocole SSL n'impose pas qu'un certificat ne soit utilisé que suite à la consultation de la CRL qui lui correspond. Un serveur Web peut donc présenter aux navigateurs un certificat révoqué. Netscape 6 permet de vérifier automatiquement les CRL, grâce au protocole OCSP (Online Certificate Status Protocol, désactivé par défaut...) La vérification manuelle des CRL est laborieuse et quasiment jamais faite.

Attaques possibles contre SSL

On peut imaginer de construire un site très similaire à un site que l'on souhaite abuser. Il est ensuite possible d'acheter un certificat chez l'une des autorités de certification reconnues par les navigateurs. Le site est mis en place en utilisant un DN similaire (par exemple " www.monsite.org " au lieu de " www.monsite.com "), voir même en trompant un serveur DNS pour créer un duplicata de " www.monsite.com ". Les utilisateurs ne verront aucune différence, ils croiront être sur le site valide puisque son certificat est vérifié avec succès par le navigateur, et ceci même si le site réel utilise un certificat valide. Vu l'absence de consultation automatique des CRL par les navigateurs, l'autorité de certification qui à émis le certificat pour le site contrefait peut même ensuite révoquer ce certificat sans que les utilisateurs cessent d'en vérifier la validité.

Sources :

SSL version 3 :

http://home.netscape.com/eng/ssl3/index.html

TLS :

http://www.ietf.org/html.charters/tls-charter.html

HMAC :

http://andrew2.andrew.cmu.edu/rfc/rfc2104.html

SSLeay :

http://www.psy.uq.oz.au/ ftp/Crypto

OpenSSL :

http://www.openssl.org

OpenSSL et Apache :

http://www.apache-ssl.org

Exemples de certificats

cryptosec — 2002-03-28T23:00:00Z

Quelques exemples de certificats X.509.
Le premier est simplement l'apparence d'un certificat en base-64. Le formats DER et PKCS#7 ne sont pas très lisibles...

En bas de page, on peut voir à quoi ressemble un certificat de l'intérieur.

Certificat en base-64 :

Comme le codage en base-64 n'est toujours pas très explicite, le voici en langage naturel. Pour intepreter, après décodage base-64, le codage DER et ASN.1, on peut utiliser les fonctionnalités des navigateurs, ou bien les fonctions de n'importe quelle API de crypto/PKI digne de ce nom (SSLeay propose par exemple ce genre de routines).
J'ai modifié quelques champs.

Le même certificat en langage naturel :

Version :
V3

Numéro de série :
37A5 9078

Algorithme de signature :
sha1RSA

Emetteur :
O = cryptosec
C = fr

Valide à partir du :
lundi 2 août 1999 13:10:48

Valide jusqu'au :
vendredi 2 août 2002 13:40:48

Objet :
CN = leredacteur
O = cryptosec
C = fr

Clé publique (RSA 1024 bits en hexa) :
3081 8702 8181 00D6 21BE 8C1D 1653 735C D424 A3D9 7415 678A 7B6C 55CE BFFB 6CED 7ED2 2D03 FFBD 1D95 42E3 26F0 4A79 FFEF 7BE3 DCC8 17B1 C907 EDCF 1D59 30CD C418 D997 F4A3 C2B0 9CED 8A99 CEF6 5EEF 7F0F AF41 E1CD 96DC B434 BDEE E54A A99B 0B81 B14C B14D 5A9A 242A 8D8E 2C28 9DB2 4BBC 49E2 DAA1 14D7 9A4A ABD7 99A1 62B2 13EB 2151 5433 0BB7 8702 0103

Point de distribution de la CRL (extension) :
[1]Point de distribution de la liste de révocation de certificats
Nom du point de distribution :
Nom complet
Adresse d'annuaire :
CN=CRL-1
O=cryptosec
C=fr

Utilisation de la clé (extension) :
Chiffrement de la clé(20)

Identificateur de la clé de l'autorité (extension) :
ID de la clé=D433 6276 E35E 426C 7DC0 8BFB BAAD 7835 6892 5E12

Identificateur de la clé du sujet (extension) :
54AB BE12 F475 60EC B057 453C F092 8BC8 E056 E719

Contrainte de base (extension) :
Type d'objet=Entité finale
Contrainte de longueur de chemin d'accès=Aucun(e)

1.2.840.113533.7.65.0 (extension)
30 0A 1B 04 56 34 2E 30 0...V4.0
03 02 04 90...

Algorithme de hachage :
sha1

Signature :
DACA 58CB 6D01 E968 1526 906E A2BA B947 6D4F DAF5

Bon, maintenant qu'on a vu un certificat client, on va voir à quoi ressemble un certificat d'AC. Le certificat d'AC doit être présent dans l'application cliente (le navigateur par exemple) parce que c'est la clé publique de l'AC qui y est contenue qui va servir à vérifier les signatures des certificats émis par cette autorité de certification.
Dans ce cas c'est un certificat auto-émis par l'AC. Il y a quelques champs en moins, et le champs le plus intéressant à regarder est "utilisation de la clé".

Le certificat de l'autorité de certification qui à émis le précédent certificat :

Version :
V3

Numéro de série :
2712 F125 590F C2BF 4124 4841 7E3C 0323

Algorithme de signature :
sha1RSA

Emetteur :
CN = cryptosec
O = cryptosec
C = fr

Valide à partir du :
lundi 20 décembre 1999 17:15:51

Valide jusqu'au :
jeudi 20 décembre 2001 17:25:24

Objet :
CN = cryptosec
O = cryptosec
C = fr

Clé publique (RSA 512 bits en hexa) :
3048 0241 00DA D767 0AC6 D92F 87D2 A03D 641A 63F6 9AB7 08F1 2680 64D0 758F 2A32 02B1 6F45 5A29 B5EB E4C0 5252 BDEE D5F4 AF2A A885 F356 EC7B ED3D 39C6 DACA 1458 15AE 467E C702 0301 0001

Point de distribution de la CRL (extension) :
[1]Point de distribution de la liste de révocation de certificats
Nom du point de distribution :
Nom complet :
URL=http://serveur/CertEnroll/cryptosec.crl

[2]Point de distribution de la liste de révocation de certificats
Nom du point de distribution :
Nom complet :
URL=file ://serveurCertEnrollcryptosec.crl

Utilisation de la clé (extension) :
Signature numérique , Non-répudiation , Signature du certificat , Signature de la liste de révocation de certificats hors connexion, Signature de la liste de révocation de certificats(C6)

Identificateur de la clé du sujet (extension) :
5033 490A 8643 A83E C1E5 CFDB E08B 7274 99AA D62E

Version de l'autorité de certification (extension) :
V6.0

Contrainte de base (extension critique, pour la co-certification) :
Type d'objet=Autorité de certification
Contrainte de longueur de chemin d'accès=Aucun(e)

Algorithme de hachage :
sha1

Signature :
231F F1F7 63A8 EFE7 5972 7EA2 60A4 BC67 568D C5FB

Le coeur d'un certificat :

Le certificat suivant ThawtePersPremCA.cer est un certificat racine de l'AC Thawte que l'on trouve dans la plupart des navigateurs.
Après l'avoir fait passer au travers de dumpasn1, on peu en voir ici sa structure ASN.1

Signature électronique et chiffrement mixte

cryptosec — 2002-03-28T23:00:00Z

Intégrité et authentification :
L'utilisation de la cryptographie asymétrique peut servir à garantir l'intégrité de données transmises ou stockées et à l'authentification du signataire (qui n'est pas forcément l'expéditeur).
On peut assurer l'intégrité de données et l'authentification du signataire en combinant algorithmes asymétriques et algorithmes de condensation (ou de hachage). On supposera pour l'instant que l'on ne souhaite pas assurer la confidentialité des données.
On passe les données à signer et à protéger en intégrité au travers d'une fonction de condensation. Le condensât obtenu est une empreinte unique des données. Rien n'empêche cependant un attaquant de modifier les données et de recalculer un condensât.
On va donc chiffrer le condensât à l'aide de ce qui aura été défini comme étant la clé privée de signature.
Pour s'assurer que les données n'ont pas été modifiées, pendant un transfert par exemple, le destinataire recalcule un condensât des données. Puis il déchiffre le condensât qui accompagnait les données lorsqu'il les a reçues grâce à la clé publique de l'expéditeur (qui est en général jointe aux données signées).
Il compare ensuite ces deux résultats.
S'ils sont différents, cela signifiera que les données ont été modifiées ou que la clé privée utilisée pour signer ne correspond pas à la clé publique utilisée pour vérifier.
Si les résultats sont égaux, outre la garantie d'intégrité, il sera assuré du fait que les données ont été signées avec la clé privée associée à la clé publique qu'il a utilisé pour déchiffrer le condensât. Il ne pourra être assuré de l'identité du signataire que si sa clé publique était encapsulée dans un certificat (qui associe de façon certaine un identifiant à une clé publique), ou bien qu'un lien de confiance direct lui permet de considérer la clé publique comme appartenant à telle personne comme ce peut être le cas avec PGP ou GPG).

Sur le schéma suivant, la fonction de condensation est SHA-1 et l'algorithme asymétrique est RSA.

Non-répudiation de la signature :
Dans le cas ou le signataire est le seul à posséder sa clé privée, et seulement dans ce cas, la signature électronique assure la non-répudiation car le signataire ne peut nier avoir fait cette opération si elle a été faite.
Il est à noter que beaucoup d'éditeurs ou de vendeurs de certificats clament qu'ils sont en mesure d'assurer la non-répudiation, mais en regardant de plus près on s'aperçoit parfois qu'il ne s'agit que d'arguments commerciaux sans fondements techniques (par exemple parce qu'ils offrent la possibilité de recouvrer les clés tout en confondant clé de signature et clé de chiffrement...)

Chiffrement mixte :
Le chiffrement mixte se définit par l'utilisation conjointe d'algorithmes symétriques et asymétriques pour chiffrer des données.
Pourquoi procède-t-on ainsi ?
Premièrement parce que les algorithmes symétriques sont plus rapides que les algorithmes asymétriques (voir la page sur RSA). De plus, comme on va le voir, dans le processus de chiffrement mixte, l'algorithme asymétrique ne chiffre qu'une clé symétrique... ce qui représente peu de bits.
Deuxièmement, cette méthode permet de chiffrer un même document pour plusieurs destinataires sans doubler à chaque fois la taille des données chiffrées. Si on ne chiffrait qu'avec les clés asymétriques, il faudrait en effet rechiffrer les données pour chaque nouveau destinataire.

La procédure de chiffrement :
L'expéditeur chiffre tout d'abord ses données à l'aide d'un algorithme symétrique dont la clé est aléatoire.
Il chiffre ensuite cette clé symétrique avec la clé publique du destinataire. S'il y a plusieurs destinataires, il fait des copies de la clé symétrique et les chiffre avec les clés publiques des destinataires respectifs.
Il envoie ensuite les données chiffrées, auxquelles il joint les clés symétriques chiffrées des destinataires : le tout est formaté (en un format comme CMS ou PKCS#7).
Chaque destinataire déchiffre la clé symétrique qui lui correspond à l'aide de sa clé privée correspondant à la clé publique utilisée par l'expéditeur.
Ayant obtenu la clé symétrique en clair, il déchiffre ensuite les données en utilisant l'algorithme symétrique spécifié dans le format envoyé par l'expéditeur.

Sur le schéma suivant, l'algorithme asymétrique est RSA et l'algorithme symétrique est CAST-128

Protocole	Port TCP	Description
nsiiops	261	IIOP Name Service sur TLS/SSL
https	443	http sur TLS/SSL
ddm-ssl	448	DDM-SSL
smtps	465	smtp sur TLS/SSL
nntps	563	nntp sur TLS/SSL
sshell	614	SSLshell
ldaps	636	ldap sur TLS/SSL
ftps-data	989	ftp données sur TLS/SSL
ftps	990	ftp controle sur TLS/SSL
telnets	992	telnet sur TLS/SSL
imaps	993	imap4 sur TLS/SSL
ircs	994	irc sur TLS/SSL
pop3s	995	pop3 sur TLS/SSL