X.509

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 les formats standard de certificats électroniques 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 (et donc valider) les certificats des autres.

Certificats

Dans le système X.509, une autorité de certification attribue un certificat liant une clé publique à un nom distinctif (Distinguished Name), à une adresse électronique ou un enregistrement DNS.

Ce certificat est signé à l'aide d'une paire clé publique/clé privée appartenant à l'autorité de certification. Cette nouvelle clé publique, pouvant à son tour être signée par un autre certificat, formant ainsi une chaine. Tout en haut 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 lesquels repose la confiance. Des autorités de certification commerciales détiennent des certificats racines présents dans de nombreux logiciels, par exemple les navigateurs Web. Quand le navigateur ouvre une connexion sécurisée (SSL) vers un site ayant acheté une certification auprès d'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.

Si le certificat est auto-signé (autorité de certification et créateur de la clé publique ne font qu'un), le navigateur propose de l'examiner, puis de l'accepter ou de le refuser selon la confiance qu'on lui accorde.

La durée de validité des certifications commerciales n'est pas infinie, elles expirent souvent au bout d'un an et doivent être renouvelées.

Structure d'un certificat

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 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

Un certificat peut devenir invalide pour de nombreuses raisons autres que l'expiration naturelle, telles que la perte ou la compromission de la clé privée associée au certificat ou le changement d'au moins un champ inclus dans le nom du titulaire / détenteur du certificat.

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é

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 pas le problème car une attaque similaire est possible en théorie (la complexité de la recherche de collisions sur SHA-1 est bien plus grande que sur MD5).

Note et références

1. ↑ (en) Colliding X.509 certificates, Arjen Lenstra, Wang Xiaoyun et Benne de Weger

Voir aussi

Articles connexes

• Authentification forte

Liens externes

Solution :

• EJBCA - PKI Open Source
• CERTEUROPE

Autorité de certification :

• Certinomis
• ChamberSign France Autorité de certification des CCI
• CERTEUROPE
• KEYNECTIS
• CAcert
• Thawte
• Certigna
• VeriSign
• Firmaprofesional
• ANCE

Outil (gratuit) :

• X509 Generator