Les certificats

Cycle de vie des certificats

Cet article est le second d’une série sur la PKI. Dans l’article précédent, nous avons décrit à quoi servait un certificat. Nous aborderons ici, dans les grandes lignes, le cycle de vie des certificats de la création à la révocation.

Emission des certificats

Pour obtenir un certificat, il faut d’abord en faire la demande. Cette demande appelée couramment CSR (Certificate Signing Request) doit contenir les éléments requis pour obtenir le certificat. C’est une requête au format PKCS#10 qui contient des données sur l’utilisateur et dans le cas d’une génération en mode décentralisé, la preuve de la possession de la clé privée. L’Infrastructure de Gestion de Clés (IGC) ne gère pas l’identification des utilisateurs, pour cela elle s’appuie sur un annuaire LDAP pour auto-remplir ces informations dans la demande. La requête est ensuite validée ou rejetée par un opérateur de l’Autorité d’Enregistrement (AE) en fonction du respect des critères définis dans les procédures. Une fois validée, la requête CSR est signée par l’Autorité de Certification (AC) et ainsi transformée en certificat.

Génération des clés

La clé publique est liée au certificat, elle est une partie de la bi-clé. Comment est-elle générée ? Les clés peuvent-être générées de façon décentralisée ou centralisée :

• en mode décentralisé, elles sont générées par l’utilisateur, c’est à dire que le programme ou la carte puce génère la bi-clé;
• en mode centralisé, elles sont générées par l’AC, ce qui permet d’en conserver une copie (pour du séquestre et du recouvrement).

Utilisation du mode :

• décentralisé pour les clés de signature et d’authentification;
• centralisé pour les clés de chiffrement.

Le mode centralisé pose le problème de la transmission de la clé, puisqu’il faut la distribuer à l’utilisateur sans qu’elle soit interceptée. La procédure de transfert du fichier PKCS#12 contenant le certificat et la clé privée, doit donc être sans faille, car comme nous l’avons dit précédemment, la base de l’infrastructure est la confiance dans l’association d’une clé et d’une identité. Une paire de clés est composée d’une clé privée et d’une clé publique.

• La clé privée doit être conservée avec précaution par l’utilisateur;
• La clé publique est contenue dans le certificat.

La génération de la clé peut s’effectuer dans :

• une carte puce : sécurisé (mais pas de séquestre possible);
• un Hardware Sécurity Module (HSM) : Sécurisé (le séquestre est possible);
• un PC : peu sécurisé (les clés peuvent-être séquestrées).

Le stockage de la clé peut s’effectuer dans :

• un datastore logiciel : Trousseau, Keystore;
• un HSM;
• une carte à puce.

Un Hardware Sécurity Module (HSM)

Un HSM génère et stocke des clés de façon sécurisée. C’est un boitier résistant aux attaques physiques et nécessitant plusieurs administrateurs.

Période de validité

Expiration

Un certificat qui a expiré ne peut plus être utilisé (sauf cas d’exception). La durée de validité s’applique également au certificat de l’AC (même l’AC Racine) ainsi qu’à tous les objets signés par l’AC. Une AC ne peut émettre un certificat dont la durée de vie excède la sienne.

Renouvellement

Le renouvellement d’un certificat doit-être organisé avant l’expiration de l’ancien pour éviter la rupture de service. Il est possible de faire du renouvellement automatique y compris pour les certificats d’AC. L’IGC envoi des messages pour proposer le renouvellement, c’est une bonne occasion de rencontrer l’utilisateur pour les rappels et les vérifications d’usage en matière de sécurité. Attention, quand on parle de renouvellement, on parle d’un nouveau certificat signé associé à une paire de clés existante. De nombreuses politiques de certification interdisent cette pratique. La réémission, elle, consiste à générer un nouveau certificat et une nouvelle paire de clés.

Révocation

La révocation permet d’invalider un certificat, elle est utile en cas de perte ou de compromission. Elle peut-être initiée par un opérateur ou un utilisateur. Elle fera l’objet d’une validation. Le certificat révoqué sera ajouté à la LCR.

LCR

La liste des certificats révoqués (LCR), est un fichier signé par l’AC. Pour chaque certificat révoqué, la LCR contient :

• un numéro de série;
• une date de révocation;
• une cause de révocation.

L’AC est la seule à pouvoir révoquer les certificats qu’elle a délivrés. L’adresse de publication de la LCR est contenu dans les certificats (attribut : CRLDistributionPoint). La LCR à une durée de validité. Elle peut être et doit être mise à jour périodiquement. Les applications doivent consulter cette liste régulièrement. Il faut être vigilant sur la durée validité et à la fréquence de mise à jour de la LCR pour éviter les interruptions de service.

Recouvrement

Lorsque l’on parle de recouvrement, on parle de certificat de chiffrement et également de séquestre. Seul un fichier séquestré, peut-être recouvré. Le but est de récupérer la bi-clé afin de pouvoir continuer à déchiffrer des fichiers. A l’issue de la procédure de recouvrement, le certificat lui est révoqué.

Publication

Les certificats à publier sont :

• Les certificats des autorités de certification;
• Les certificats des entités terminales;
• Les listes de révocations.

La publication se fait généralement en LDAP via des attributs standards Schéma core :

• ObjectClass : certificationAuthority;
• Attributs :
  • authorityRevocationList;
  • cACertificate;
  • certificateRevocationList.

Schéma inetOrgPerson

• ObjectClass : inetOrgPerson;
• Attribut : userCertificate.

Conclusion

Chaque étape de la vie d’un certificat doit faire l’objet d’une procédure détaillée. Ces moments de la vie du certificat sont des occasions de délivrer des messages aux utilisateurs. Les cas d’erreurs doivent être analysés, documentés et les procédures modifiées en conséquence. Car il ne faut jamais l’oublier, un certificat cela représente une garantie de confiance, qu’il faut protéger.

Philippe LEGRIS

Consultant Senior Sécurité