Vous êtes sur la page 1sur 7

S3L3

Infrastructures à clés publiques


Philippe JAILLON

Bonjour.
Lorsque vous aurez terminé de suivre cette leçon, vous aurez acquis les connaissances indispensables
au bon usage et à la bonne mise en œuvre des certificats. Cette leçon va vous présenter ce qui a amené
les utilisateurs de l'internet à massivement adopter les certificats. Vous apprendrez aussi quels sont
les différents types de certificats, quelles sont les informations qu'ils contiennent, de quelle manière
ces informations sont rendues infalsifiables et pourquoi il nous est possible d'y faire confiance. Pour
terminer, nous étudierons comment les processus de certififcation sont mises en oeuvre pour assurer
cette confiance et quelles en sont les limites.

Le problème

Le meilleur moyen pour assurer la confidentialité et l’intégrité d’un canal de communication est
d’utiliser un mécanisme de chiffrement, mais cela ne sert a rien si on ne sait pas avec qui on le fait.
Dans l’internet, les principales interactions ont lieu entre utilisateurs (comme par exemple le mail) et
entre utilisateurs et services (cas du web). Ces entités n’ayant pas de raisons de se connaître a priori,
il est très difficile d’être sûr que l’on est bien en communication avec le bon interlocuteur (il est en
effet très facile de se faire passer pour quelqu’un d’autre sur le web). Une des principales attaques
connues concernant ce problème s’appelle l’attaque « man in the middle » ou une personne (ou un
programme). Oscar sur cette figure se fait passer pour Bob auprès de vous (si vous êtes Alice) et se
fait passer pour vous auprès de Bob. Oscar prenant soin, au passage, de capturer tous les éléments
importants de votre conversation avec Bob (il aura pris connaissance de votre mot de passe par
exemple). S’assurer de l’identité de son correspondant devrait donc permettre d’éliminer ce type de
problème.

Les certificats X.509


La méthode retenue, et qui est massivement utilisée aujourd’hui dans l’internet, est d’utiliser les
propriétés des algorithmes de chiffrement à clé publique de type RSA. Si vous êtes capable d’apporter
la preuve que vous connaissez la clé privée alors on peut considérer que vous êtes le propriétaire
légitime de la clé publique associée. Mais cette preuve n’est pas suffisante, elle n’apporte aucune
information sur qui vous êtes réellement (vous n’êtes que le propriétaire de la clef privée). Il faut
donc associer à cette clé publique des informations supplémentaires sur son propriétaire : quel est son
nom (ou celui du service auquel on se connecte), est-ce que cette clé est utilisable pour n’importe
quel usage, jusqu’à quand est-elle valable, etc.
Pour avoir du sens, ces informations doivent avoir été renseignées sous le contrôle d’un tiers en qui
nous avons confiance, qui est désigné comme tiers de confiance ou plus généralement comme autorité
de certification. Ces informations sont signées cryptographiquement par cette autorité de certification
pour les rendre inaltérables. Tout ceci est fait à la manière par exemple de nos cartes d’identités ou
les informations (notre nom, notre photo, notre adresse, la date d’émission de la carte) sont
renseignées sous le contrôle d’un agent assermenté et scellées de manière inaltérable et infalsifiable
(avec du papier spécial, des hologrammes) par les services de l’État.

Les certificats que nous utilisons majoritairement aujourd’hui sont des certificats qui respectent la
norme X.509v3 décrite dans le RFC 5280. Ces certificats contiennent les informations suivantes :
1. le nom du sujet,
2. le nom de l’émetteur,
3. le numéro de série du certificat,
4. la version de X.509 utilisée ( 3 pour le moment),
5. l’algorithme de signature utilisé par l’émetteur,
6. la période de validité (représentée par deux dates,
7. le début et la fin de validité),
8. la clé publique (son type et ses coefficients),
9. les usages possibles du certificat (signature, chiffrement, etc.),
10. et de nombreuses extensions.
L’ensemble des informations contenues dans les certificats sont scellées par une signature
électronique qui est apposée par l’émetteur du certificat : l’autorité de certification (ici Google
Internet Authority G3).

Vérifier un certificat

Avant d’utiliser un certificat, il est impératif d’en vérifier la validité. On peut commencer de manière
naturelle par vérifier que le certificat concerne bien le service que l’on attend : le champ sujet
correspond-il par exemple bien à notre interlocuteur ? Ce certificat est-il valable pour l’action que
l’on veut entreprendre ? Est-il en cours de validité ? etc. Enfin, nous est-il possible de vérifier que la
signature de ce certificat a été apposée par une autorité de certification (CA) possédant elle-même un
certificat valide ?
On répète à nouveau cette opération de vérification sur le certificat de l’émetteur (Google Internet
Authority, dans notre exemple), puis sur le certificat de l’émetteur de cet émetteur et cela jusqu’à ce
que l’émetteur soit également le sujet du certificat lui même. On appelle alors ce dernier certificat :
la racine de certification. Cet ensemble de certificats s’appelle une chaîne de certification.

Pour considérer qu’un certificat est de confiance, il faut donc qu’il soit valide, mais aussi que tous
les certificats de sa chaîne de certification soient valides et que, en plus nous ayons confiance dans
l’autorité de certification ayant émis le certificat racine.
Comment faire confiance à un certificat racine ?
Lors de la vérification de la chaîne de certification, il est extrêmement important d’avoir confiance
dans le certificat racine, toute la sécurité du système reposant sur lui. Pour valider dans les meilleures
conditions la chaîne de certification, notre machine ou notre logiciel doit donc disposer, a priori, de
l’ensemble des autorités de certification qui pourraient nous être nécessaires pour valider les
certificats qui nous seront présentés. Nos ordinateurs disposent couramment de 100 à 200 certificats
racines. J’attire votre attention sur le fait qu’ajouter une racine de certification à votre système n’est
pas une opération anodine. Une fois ajouté, tout certificat signé (directement ou indirectement) par
cette nouvelle racine de certification sera considéré comme valide. Récupérer de manière automatique
le certificat de l’autorité de certification est dangereux : car cela permettrait de faire valider de
manière automatique n’importe quel certificat, et ce n’est pas l’objectif que l’on cherche à atteindre.
Pour faciliter l’étape de vérification, des protocoles comme TLS transmettent, à l’exclusion des
certificats racines, l’ensemble des certificats de la chaîne de certification.

Une infrastructure à clés publiques

L’objet d’une infrastructure de gestion de clés publiques (Public key infrastructure en anglais et que
l’on abrège par PKI) est de créer des certificats, de révoquer des certificats (lorsque que ceux-ci sont
compromis, ou que des informations qu’ils contiennent son devenues obsolètes), de gérer le statut
des certificats (sous forme d'annuaires, de listes de révocations), de conserver des copies des
certificats et même dans certaines situations des copies de certaines clés privées. Une PKI est en
général organisée de la manière suivante. Elle dispose : d’une autorité d’enregistrement à qui les
utilisateurs font leurs demandes de certificat ou de révocation, d’une autorité de certification qui se
charge des opérations de signature des certificats après en avoir vérifié les informations, d’un service
de séquestre de clefs si ce service est offert par la PKI, d'un service d’annuaire ou sont conservés les
certificats émis et d’un service de validation qui rend compte des révocations potentielles.
Une utilisation sûre des certificats

Avoir confiance dans le certificat d’une autorité de certification revient à avoir confiance dans la
structure qui l’a délivré. Et cette confiance est liée à plusieurs choses. En premier lieu, elle est liée ce
que l’on appelle la politique de certification qui couvre les conditions, les règles et les procédures de
délivrance d’un certificat. Ensuite, elle est liée à la rigueur de mise en œuvre des processus de
vérification des informations qui seront associées au certificat. Et enfin, au soin qui est apporté à la
protection de la clé privée associée au certificat racine, cette dernière étant l’élément le plus précieux
du système. En général, l’accès à un service sécurisé se décompose en un certain nombre d’étapes
qui dépendent des protocoles utilisés.
De manière générique, cela peut se passer de la manière suivante : L’utilisateur contacte le service
qui l’intéresse. Ce service tente de lui prouver son identité en lui transmettant son certificat et la
preuve qu’il possède bien la clé privée associée. L’utilisateur (ou son application) doit alors vérifier
le certificat comme nous l’avons vu précédemment et entre autres vérifier que ce certificat n’a pas été
révoqué. Lorsque toutes ces vérifications sont réalisées sans erreur, l’utilisateur peut accéder en toute
confiance au système. Dans le cas où cette vérification échouerait, l’utilisateur ne devrait pas tenter
de passer outre le message d’alerte, bien que, en général, son principal objectif soit d’accéder à
ce service. Si, malgré tout, il le fait, il s’expose à une attaque de type « man in the middle » et lors de
cette session, la confidentialité de tous ses échanges sera compromise. Si, de plus, il accepte de valider
ce certificat (il enregistre l’information que ce certificat est valide), toutes les communications futures
avec ce service peuvent être compromises. Le problème est encore bien plus crucial s’il valide un
certificat intermédiaire ou un certificat racine. Cette fois, toutes les communications de l’utilisateur
seront potentiellement compromises.

En conclusion de cette leçon, il ne faut jamais valider un certificat que votre système considère
comme invalide. Ne décidez jamais d’ajouter une autorité de certification si vous n’êtes pas à même
de faire une confiance absolue à son propriétaire, et même dans ce cas, prenez toutes les précautions
nécessaires pour vous assurer qu’il s’agit bien du bon certificat. N’oubliez pas que toute la confiance
que l’on peut avoir dans le système dépend de la confiance que l’on a dans tous les certificats racines
dont on dispose.

Vous aimerez peut-être aussi