Dans l’épisode précédent…
Dans le précédent article, nous avons vu que la PKI a rendu le chiffrement, la signature et l’authentification transparentes pour les utilisateurs. Elle permet la gestion et la protection de certificats numériques. Le tout en vue de protéger l’information dématérialisée (chiffrement, signature, authentification, etc).
Nous avons aussi vu la première étape d’un projet de déploiement d’une Infrastructure de Gestion de Clés: L’analyse et la conception. Durant cette étape, on apporte la réponse aux questions liées aux usages de la PKI, à la documentation qui sera mise en place, aux coûts, sécurité, architecture etc.
Voyons maintenant l’étape suivante:
Etape 2: Implémentation de la PKI
Installation de l’autorité de certification (CA)
Validité des certificats
Lors de l’installation de la CA, il faut choisir la période de validité de son certificat: Elle sera au plus de 20 ans pour une CA racine, environ 10 ans pour une CA intermédiaire. Attention à bien choisir des valeurs de validité et la politique de renouvellement pour les certificats. Le point clé est qu’il faut éviter qu’une CA délivre un certificat ayant une validité qui excède sa propre validité (même si en théorie le standard l’autorise).
Taille des clés
Concernant la taille de clés: Celle-ci augmente avec la durée de validité du certificat. Choisir 4096 bits pour une sécurité maximale et 2048 bit pour une compatibilité accrue. Au fait, savez-vous pourquoi des valeurs si grandes alors qu’une clé AES est à « seulement » 256 bits? En fait c’est dû au mode de chiffrement qui est derrière: le chiffrement RSA est asymétrique, alors que le chiffrement AES est symétrique. Du coup, pour les « casser » on n’utilisera pas les mêmes techniques. En effet, ce sera de la force brute dans le cas d’une clé AES, mais pour casser une clé RSA, il faut simplement résoudre une problème mathématique: la décomposition en facteurs premiers. Cette opération, simple avec des petits nombres, devient compliquée avec des grandes valeurs. D’où la différence de taille. Mais refermons la parenthèse pour revenir au sujet principal. D’autres choix sont à faire à cette étape:
AIA, CRL
- AIA (Authority Information Access): C’est une extension de certificat X503v3 qui permet de savoir où trouver l’information de révocation de ce certificat
- CRL, delta CRL: Durée de validité, période de « overlap » entre CRL n et n+1. Note: la CRL est la Certificate Revocation List. C’est une liste de certificats qui ont été révoqués ou invalidés et qui ne sont donc plus dignes de confiance. Cette liste doit être consultable par tout service qui veut vérifier la validité d’un certificat utilisateur.
- Utilisation ou non de delta CRL (recommandée si la liste des certificats révoqués devient grande)
Service d’enregistrement de la PKI (Registration Authority)
Pour une PKI interne: Qui jouera ce rôle: le service informatique? Le service sécurité? Dans tous les cas, il faudra prévoir la formation du personnel. Combien de RA prévoir? C’est selon la taille de l’entreprise et le nombre d’utilisateurs finaux. Si il y a à la fois des utilisateurs internes (employés) et externes (clients, fournisseurs…) alors il faudra prévoir plusieurs RA avec des procédures de vérifications différentes (accès à une base de données ressources humaines, base de données clients etc). Dans le cas d’une multinationale, on pourra prévoir un RA par site.
En ce qui concerne une PKI externe, le service d’enregistrement pourra être un point de vente physique, un site web… Dans ce cas de figure, on aura également besoin de vérifier l’identité du demandeur: Cela pourra se faire par envoi de pièce d’identité, confirmation d’email, réception d’un code SMS, authentification sur un portail gouvernemental…
Service d’annuaire
Dans les PKI internes, on y publie les certificats. On peut avoir un annuaire central, des annuaires locaux et dans ce cas il faudra prendre en compte les problématiques de synchronisation, réplication, haute dispo etc. En outre, les annuaires sont aussi utilisés par la CA pour obtenir les informations à insérer dans le certificat (d’où l’importance de disposer d’informations à jour). Exemple: le champ « subject DN ».
Stockage des certificats
Les supports physiques (carte à puce, token USB etc) fournissent une meilleure protection mais ce format sera plus contraignant. On pourra aussi opter pour un support logique (ordinateur, fichier PKCS12 etc). Attention, dans la cas de la signature qualifiée on utilisera un dispositif SSCD (Secure Signature Creation Device) et un certificat qualifié (délivré par une autorité de certification agréé ANSSI).
Cérémonie de clés
C’est une garantie que l’étape de génération de clés de la CA se déroule en toute sécurité. On utilisera une procédure détaillée et suivie pas-à-pas. En fonction des contraintes règlementaires liées à l’activité de l’entreprise/entité juridique, on prévoira un enregistrement vidéo, la signature de procès verbal, la présence du représentant juridique de l’entité concernée. Enfin, si la clé est stockée dans un HSM, elle sera découpée et répartie sur plusieurs supports différents.
Dans le dernier article, nous verrons les 2 autres étapes de déploiement d’une PKI. N’hésitez pas à lire les autres articles de notre blog! ACE MULTIPASS peut vous accompagner dans votre projet de PKI. Contactez-nous ici.