Cryptographie pour les néophytes : L’IGC (ou la PKI)

Dans le “monde virtuel” des réseaux informatiques, prouver son identité est loin d’être aisé. 0x0ff, Ô maître de ces lieux, a montré qu’il était possible de deviner votre mot de passe (guessing) et d’usurper votre identité (cf.gathering) . Et OUI! La preuve de votre identité se fait, aujourd’hui, principalement via mot de passe. Seulement gérer ne serait ce que 4 mots de passe avec 4 politiques différentes est déjà un vrai casse tête.

L’identité numérique est un enjeu croissant à mesure que notre société évolue dans le monde virtuel. Mais comment prouver son identité à un partenaire sur Internet ? Comment s’assurer que mon correspondant virtuel est bien celui qu’il prétend être ?

Nous avons vu les fondamentaux ainsi que le chiffrement symétrique et asymétrique. Voilà, à présent, l’application la plus complète de ces connaissances : L’Infrastructure de Gestion de Clé (IGC) ou Public Key Infrastructure (PKI).

Niveau Management : Pas facile mais indispensable au monde SSI
Niveau Technique : C’est utile…surtout pour les architectes SI

Pourquoi déployer une IGC ?

1 – Pour la simplicité

Si la mise en place initiale semble compliquée et que le renouvellement d’AC demande rigueur et qualités de management,  l’utilisation au quotidien facilite indéniablement ! la vie de l’utilisateur, ne serait ce que pour l’authentification.

Fini les ‘X’ mots de passe à sauvegarder “qques part”, fini les renouvellements tout les 3 mois. Vous entrez votre code une seule fois pour déverrouiller la clé privée et vous pourrez vous authentifier à toutes les applications qui font confiance à votre Autorité de Certification (AC).

Mieux, le renouvellement d’un certificat se fait généralement tout les 3 ans et de manière entièrement automatisée (si c’est bien fait), donc plus besoin de se casser la tête pour trouver des mots de passes répondant aux politiques de sécurité draconiennes.

2 – Pour la sécurité

Fini la peur que l’on vous vole votre mot de passe écrit quelque part dans un fichier texte, ou que l’on regarde par dessus votre épaule (shoulder-surfing). Votre clé n’appartient qu’à vous et est chiffrée !!

De plus, votre certificat peut vous permettre la signature de vos e-mail, afin d’éviter le spear-fishing au sein de votre société par exemple, ou le chiffrement de documents partagés.

Enfin, et surtout, une IGC permet de créer un véritable espace de confiance : seules les machines et les utilisateurs authentifiés peuvent discuter de manière sécurisé au sein de votre système d’information. Vous assurez ainsi l’Authenticité, l’Intégrité et la Confidentialité sur les nœuds et feuilles de votre système d’information, CISSP bonsoir.

Commençons par le certificat…

Ah que j’aime cet enthousiasme !!  Sachez, avant tout, que c’est un sujet vaste et que nous essaierons de simplifier au maximum. Ainsi, tu me pardonneras, toi lecteur attentif, d’omettre les standards PKCS 1,7,10,11 et 12, Ô combien importants ! Mais trop détaillés pour une compréhension générale. Cela étant dit, rappelons nous maintenant quelques notions de base : l’identité et l’authentification.

C’est quoi une identité ?

L’identité c’est ce que vous prétendez être. Par exemple, vous vous présentez à quelqu’un avec un “Salut, je m’appelle Michel“.  Votre identité c’est Michel. Facile…

C’est quoi une authentification?

Comme nous vivons dans un monde de prédateur et d’usurpateur nous conduisant à une paranoïa justifiée, la personne, celle à qui vous vous présentez, peut vous demander une preuve de qui vous êtes. Enfin… une preuve de qui vous prétendez être. Vous lui tendez donc votre carte d’identité contenant plein d’informations publiques : votre nom, prénom, photo, date de naissance, nationalité et votre signature. La signature est un élément de validation car, hypothétiquement, vous seul, êtes capable de réaliser cette signature.

Il vous défie alors de réaliser votre signature devant lui ! Le bougre! Si la signature que vous venez de réaliser est bien la même que celle présente sur votre carte d’identité, alors vous avez relevé et réussi ce défi: vous avez prouvé que vous êtes bien celui que vous prétendez être, vous vous êtes correctement authentifié.

Revenons au certificat

Le certificat, c’est votre carte d’identité numérique. Globalement, c’est votre identité associée à votre clé publique. Dans le détail, il doit, comme votre carte d’identité réelle, contenir des informations publiques dont un élément de validation:

• Votre Nom
• L’organisme auquel vous appartenez
• Un numéro de série
• Une date de validité
• Votre clé publique
• La signature de l’organisme qui vous a délivré ce certificat

D’autres informations sont, normalement, présentes sur  un certificat. Je n’ai présenté, ici, qu’un cas simplifié, l’objectif étant d’aborder sereinement la PKI. Pour les curieux, vous trouverez toutes les informations contenues dans un certificat X509 dans la RFC 5280.

Voici un petit exemple d’authentification simplifiée :

1. Vous vous présentez à quelqu’un avec votre certificat
2. Ce quelqu’un vous envoie un message (généralement un aléa)
3. Vous signez cet aléa avec votre clé privée que seul vous possédez
4. Le correspondant vérifie cette signature avec votre clé publique présente sur votre certificat
5. Le correspondant valide, ou non, que vous êtes vous

De la même manière qu’un commerçant vérifie la signature du chèque que vous venez de lui faire avec celle de votre carte d’identité.

Certains diront “Oui mais moi quand je montre ma carte d’identité, on ne vérifie que ma photo !” . Merci jeunes furibonds de mettre ce point en avant. Votre photo et votre signature sont en fait deux éléments possibles de validation, il représente le “ce que je suis“. Pour simplifier, dites vous que votre signature et votre photo c’est pareil.

 L’organisme de validation

Oui parce que, en France, votre carte d’identité est de confiance si, et seulement si, elle a été réalisée par une préfecture sous l’égide de l’état français. Et bien votre certificat c’est pareil ! Il doit être sous l’égide d’un organisme de confiance et c’est cette autorité de confiance qui délivre et signe les certificats. Comme la préfecture délivre les cartes d’identité.

Délivrez ! Le Certificat !

Donc on résume! Pour obtenir un certificat il faut une autorité qui le signe et une autorité qui vérifie que les données que je fourni sont bien les bonnes. Bah oui, sinon je pourrais changer d’identité comme de chemise, plus aucun intérêt.

Les RA, CA (illes)

Pour ce faire, dans une IGC nous avons l’Autorité d’Enregistrement (AE) qui va vérifier que je suis  bien moi. Elle est aussi appelée RA comme Registration Authority. L’autorité qui va signer mon certificat est, elle, simplement appelée Autorité de Certification (AC) ou Certification Authority en anglais (CA).

L’enrôlement

Et pour bien  comprendre, une petite analogie simple : l’AE c’est la mairie et l’AC c’est la préfecture. Voilà donc un petit d’exemple d’enrôlement (ie. la demande et la création d’un certificat pour un utilisateur).

1. Je m’authentifie auprès de l’Autorité d’Enregistrement (AE)
2. J’envoie ma demande de certificat : Certificate Signing Request (CSR – PKCS10)
3. l’AE transfert ma CSR à l’Autorité de Certification (AC)
4. L’autorité signe le certificat et le renvoie (PKCS7) à l’AE qui me le renvoie.

Ce qui nous donne…

La petite variante

Il est possible de réaliser des enrôlements automatiques. Le protocole SCEP (Simple Certificate Enrollment Protocol), la mise en place d’un Auto-Enrollment Proxy (AEP) ou encore l’utilisation du protocole CMP (Certificate Management Protocol) sont des solutions très pratiques pour faire de l’enrôlement de machines.

 La chaîne d’autorité

Dans la vie, le préfet est sous l’autorité du ministère, enfin pas pour tout mais c’est pour l’exemple, il y a donc différentes autorités qui s’organisent de manière hiérarchique. Et bien dans une IGC c’est pareil. Il y a plusieurs niveaux de hiérarchie (généralement 1 ou 2) formant une chaîne d’autorités.

Ainsi lors de la création d’une IGC, nous allons créer une AC Racine. Nous allons utiliser cette AC Racine pour générer (ie. signer) des AC filles, aussi appelées AC Intermédiaires.

La clé privée de l’AC Racine est ensuite sortie du réseau et enfermée à double tour dans un coffre fort sécurisé. Les clés privées des AC filles sont, elles, protégées par un HSM (Hardware Secure Module). Ce module est une sorte de coffre fort informatique protégeant les clés à l’aide de modules cryptographiques.

Pourquoi tant de précaution ? Et bien tout simplement parce que si quelqu’un vole la clé privée d’une de vos AC, il sera capable de générer des certificats lui permettant de s’authentifier aux applications de votre entreprise et à toutes les applications qui font confiance à vos AC…. c’est embêtant…

 Toi tu rentres – Toi tu sors

Mettons nous dans la peau d’un utilisateur de mon IGC. Afin de gérer correctement les certificats, il faut que je puisse répondre à quelques questions pour comprendre comment mes applications vont me laisser entrer ou non.

Que se passe-t-il si je perds ou me fait voler ma clé privée ?

Et bien nous allons révoquer votre certificat. C’est à dire que nous allons ajouter son numéro de série (unique) à une longue liste noire : la CRL (Certificate Revocation List). Comme votre certificat a été signé par une AC, c’est cette AC qui va générer et signer sa CRL. A chaque AC sa CRL comme dirait l’autre.

Une fois votre certificat révoqué, il est inutilisable ! Il faudra donc vous enrôler une nouvelle fois…demander un nouveau certificat quoi.

La petite variante

Le problème de la CRL est souvent sa taille. En effet, la CRL doit être poussée sur toutes les applications qui réalisent des authentifications par certificat. Résultat : plus la CRL est grosse, plus elle consomme de bande passante.

Pire, à partir d’une certaines tailles (plusieurs Mo), certaines applications ne peuvent plus la traiter. Du coup, pour des populations de plusieurs milliers d’utilisateurs, on opte pour une version online : l’Online Certifiate Status Protocole (OCSP). Maintenant, au lieu de charger la CRL sur touuuutes les applications, seul le serveur OCSP charge la CRL. Les applications lui envoient, ensuite, une requête “Est ce que ce certificat est valide?“. L’OCSP vérifie et renvoie “Oui” ou “Non” …et quelque fois “je sais pas“, mais c’est une autre histoire.

Comment  marche mon authentification par certificat?

Supposons que vous vous authentifiez à un serveur Web. Et bien, pour vérifier votre signature, le serveur va réaliser les étapes suivantes :

1. Je vérifie que le certificat a été signé par une autorité que je connais (AC Intermédiaire)
2. Je vérifie que cette autorité est elle même signé par une autorité à qui je fais confiance (AC Racine)
3. Je vérifie que le certificat n’est pas expiré
4. Je vérifie que le certificat n’est pas révoqué (pas de numéro de série dans la CRL)
5. Je vérifie que celui qui signe est bien le possesseur du certificat

 

L’IGC / PKI en résumé

Pour fonctionner, une IGC doit donc posséder:

• Une ou des Autorités de Certification (AC)
• Une ou des Autorités d’Enregistrement (AE)
• Un CRL repository ou un OCSP
• Un HSM (facultatif mais c’est mieux quand même)

Et là on se pose plein de questions…

Bien ! Nous savons à présent comment réaliser une architecture IGC/PKI. Mais n’oublions pas !! Une IGC est un service, et qui dit service dit continuité ! N’essayez JAMAIS de réaliser une hiérarchie d’autorités sans connaitre les besoins et l’organisation des métiers de l’entreprise. Vous risquez de tout recommencer à la première mauvaise découverte. La création d’une IGC est un art ! Cela demande rigueur, méthode et ouverture d’esprit.

Lors de la création d’une AC, ou la création d’un gabarit de certificat, voici quelques questions que vous vous poserez certainement :

• Et si un utilisateur demande un certificat à la place d’un autre utilisateur ?
• Que peut faire un utilisateur avec son certificat ?
• Et si un utilisateur perd sa clé privé ?
• Et si quelqu’un lui vole sa clé privé ?
• Et si un utilisateur chiffre toutes ses données et détruit sa clé ?
• Et si un utilisateur quitte l’organisation ?
• Et si le certificat d’un utilisateur arrive à expiration ?
• Et si la clé privée de mon AC est corrompue ?
• Et si le certificat de mon AC passe à expiration ?

Ok, on se détend et on dé-serre les fesses ! En fait, chaque Autorité de Certification doit être associée à une population précise. Pour chaque AC, le gabarit de certificat utilisé (chiffrement, signature, horodatage,…), le processus de validation (authentification), le processus de recouvrement de clé et le processus de migration de l’AC doivent être réfléchis et mis sous la forme de deux documents sacrés : la “Politique de Certification” et la “Déclaration des Pratiques de Certification” connues aussi sous le nom de PC/DPC.

Les annexes A6-A12 du RGS de l’ANSSI vous donnerons des exemples et de bonnes pratiques pour la réalisation de PC.

Ces documents définissent donc:

• Les gabarits de certificats
  • Ici, nous allons définir à quoi vont servir nos certificats

• Les méthodes d’authentification avant la création d’un certificat
  • Ce sont les méthodes d’authentification en fonction des certificats demandés. Vais-je utiliser un enrôlement automatique via AEP, un portail d’authentification ou une vérification en vis-à-vis?

• Le cycle de vie des clés
  • Une clé privée suit un cycle de vie. Elle est créé puis détruite ou expire de sa belle mort. Nous définissons ici la taille de la clé, comment est-elle créé (via une cérémonie de clé, unitairement sur le poste utilisateur ou sur un serveur centralisé, etc.), si elle est stockée dans un magasin logicielle ou sur un support physique (carte à puce) et si il est possible de la recouvrer.

• Le cycle de vie d’un certificat utilisateur
  • Un certificat, comme la clé privée qui lui est associée, suit un cycle de vie. Il est créé puis révoqué ou expire de sa belle mort et enfin renouvelé. Nous définissons ici ces différentes étapes et leur condition d’application.

• Le cycle de vie d’une AC
  • Nous définissons les mêmes étapes que pour un certificat utilisateur. Les conditions sont cependant sensiblement différentes étant donné que le renouvellement d’une AC rend obsolète TOUS les certificats qu’elle a généré…imaginer que l’AC de votre carte bleue est révoqué et les 30 000 utilisateurs de votre banque se retrouve sans carte.

 

Pour conclure

Ce petit dossier spécial IGC est long mais Ô combien important surtout si vous travaillez sur des domaines sensibles comme la finance ou la cyber-défense. Et si cela vous semble un peu flou, rappelez vous seulement qu’une AR vérifie l’identité initiale de l’utilisateur, que l’AC délivre les certificats à cette utilisateur et que la CRL définit les certificats non valides.

En espérant que cet article vous ait plu, je vous dis à bientôt et vous souhaite une bonne année ! ;)