X.509

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

X.509 est une norme de cryptographie de l'Union internationale des télécommunications pour les infrastructures à clés publiques (PKI). X.509 établit entre autres un format standard de certificat électronique et un algorithme pour la validation de chemin de certification.

X.509 a été créé en 1988 dans le cadre de la norme X.500. Il repose sur un système hiérarchique d'autorités de certification, à l'inverse des réseaux de confiance (comme PGP), où n'importe qui peut signer les certificats des autres.

Certificats[modifier | modifier le code]

Dans le système X.509, une autorité de certification attribue un certificat liant une clé publique à un nom distinctif (Distinguished Name) dont le format est défini par la recommandation X.500, ou encore à un nom alternatif (Alternative Name) tel qu'une adresse électronique ou un enregistrement DNS.

Ce certificat place la signature d'une autorité de certification dans le dernier champ. Concrètement cette signature est réalisée par : Un condensat de tous les champs précédents du certificat, et un chiffrement de ce condensat par la clé privée de l'autorité de certification. N'importe qui possédant la clé publique de cette autorité de certification peut déchiffrer le condensat et le comparer au calcul de son propre condensat du certificat. Si les deux condensats sont identiques cela garantit que le certificat est intègre, il n'a pas été modifié. Le certificat de l'autorité de certification qui contient sa clé publique peut à son tour être signée par un autre certificat de plus haut niveau, formant ainsi une chaîne. Tout en haut de la chaîne on trouve les certificats les plus importants : les certificats racines.

Les certificats racines sont des clés publiques non signées, ou auto-signées, dans lesquelles repose la confiance. Les logiciels, comme les navigateurs Web ou les clients de messagerie détiennent des certificats racines de nombreuses autorités de certification commerciales ou gouvernementales. Quand un navigateur ouvre une connexion sécurisée (TLS/SSL) vers un site possédant un certificat émis par une autorité connue, il considère le site comme sûr dans la mesure où le chemin de certification est validé. Le passage en mode sécurisé est alors transparent.

Article détaillé : Certificat racine.

Si le logiciel (navigateur ou autre) ne connaît pas l'autorité de certification (certificat généré et auto-signé par un particulier ou autorité de certification pas encore connue ou volontairement retirée de liste des autorités acceptées), le navigateur propose d'examiner le certificat, puis de l'accepter ou de le refuser selon la confiance qu'on lui accorde.

X509 peut être utilisé avec S/MIME, TLS/SSL, SET et IPsec.

Structure d'un certificat[modifier | modifier le code]

La définition originelle est disponible dans la RFC 2459 (section 4) ou dans la dernière version (RFC 5280), qui contient une spécialisation de X.509 pour les applications Internet. La partie authentifiée contient les champs suivants :

  • Version
  • Numéro de série
  • Algorithme de signature du certificat
  • DN (Distinguished Name) du délivreur (autorité de certification)
  • Validité (dates limite)
    • Pas avant
    • Pas après
  • DN du détenteur du certificat
  • Informations sur la clé publique :
    • Algorithme de la clé publique
    • Clé publique proprement dite
  • Identifiant unique du signataire (optionnel, X.509v2)
  • Identifiant unique du détenteur du certificat (optionnel, X.509v2)
  • Extensions (optionnel, à partir de X.509v3)
    • Liste des extensions
  • Signature des informations ci-dessus par l'autorité de certification

Les noms de l'émetteur (également signataire) comme du titulaire sont des noms X.501, que l'on retrouve également dans les annuaires ISO et LDAP. Le contenu ci-dessus est suivi par une répétition de l'algorithme de signature et de la signature proprement dite.

Rien parmi les champs obligatoires ne permet de distinguer une autorité de certification (une organisation émettrice de certificats) d'un simple titulaire. L'extension basicConstraints définie dans X.509 version 3 comble cette limitation. Une autre imperfection du même type est que seul le nom permet de lier un certificat à celui de son émetteur alors que l'on ne peut pas garantir l'unicité des noms.

Liste de révocation[modifier | modifier le code]

Un certificat peut devenir invalide pour de nombreuses raisons telles que l'expiration naturelle (dépassement de la date de validité), la perte ou la compromission de la clé privée associée au certificat, le changement d'au moins un champ inclus dans le nom du titulaire / détenteur du certificat et cas extrême la perte ou la compromission de la clé privée de l'autorité de certification ayant signé le certificat en question.

C'est pourquoi la norme définit le format d'une liste indiquant les certificats devenus invalides pour une autorité de certification donnée. Cette liste est signée par l'autorité de certification pour en empêcher toute modification par une personne non autorisée.

Elle comprend une date d'émission, une date de mise à jour (toutes deux optionnelles) et la liste proprement dite sous la forme de paires (numéro de série du certificat révoqué ; motif éventuel de révocation). Le motif ne peut être présent que dans les CRL au format version 2.

Une limitation parfois gênante des CRL est le délai de propagation des informations de révocation. Pour le réduire, le protocole OCSP de validation de certificat a été développé. Défini dans la RFC 2560, il lui donne à peu près les mêmes informations que les CRL, mais potentiellement plus à jour.

Sécurité[modifier | modifier le code]

Suite à la publication d'une attaque de recherche de collisions complètes contre MD5 en 2004[1], Arjen Lenstra, Wang Xiaoyun et Benne de Weger s'intéressèrent au X.509 utilisant MD5 pour l'authentification du certificat. Leur attaque permet de forger deux certificats avec des signatures identiques.
L'utilisation de la fonction de hachage cryptographique SHA-1 ne résout que partiellement le problème car une attaque similaire est possible en théorie, même si la complexité de la recherche de collisions sur SHA-1 est bien plus grande que sur MD5.

Notes et références[modifier | modifier le code]

Voir aussi[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Liens externes[modifier | modifier le code]

Solution :

Autorité de certification :

Outil (gratuit) :