Dans le chapitre précédent, vous avez vu comment utiliser le chiffrement asymétrique pour envoyer des messages confidentiels et signés, sans partage de secret. Ce système repose sur le partage en clair de clés publiques, qui ne sont pas confidentielles. Cependant, il est crucial de pouvoir garantir à qui appartient une clé publique, sans quoi toute la sécurité du système est compromise par ce qu’on appelle l’attaque de l’homme du milieu (en anglais Man In The Middle, ou MITM).

Dans ce scénario, un attaquant, que l’on appellera Charlie, intercepte et modifie toutes les communications entre Alice et Bob, et ce en deux temps :

• quand Bob envoie sa clé publique à Alice, Charlie intercepte la communication et la remplace par sa propre clé publique ;

• quand Alice envoie sa clé publique à Bob, Charlie la remplace également par sa propre clé publique.

Lorsque Alice veut chiffrer un message pour Bob, elle utilise ce qu’elle croit être la clé publique de Bob, mais qui est en réalité la clé publique de Charlie. Charlie peut donc intercepter et déchiffrer le message avec sa propre clé privée. Il peut ensuite le chiffrer avec la vraie clé publique de Bob et l’envoyer à Bob. Bob reçoit le message et peut le déchiffrer avec sa clé publique. Bob a bien reçu le message d’Alice et ne se doute donc pas que l’échange est passé entre d’autres mains avant de lui arriver. Charlie, de son côté, a pu lire le message chiffré qui n’est donc plus confidentiel.

Résultat : la confidentialité est compromise !

De même, Alice peut choisir de signer son message avec sa clé privée, pour en assurer l’intégrité. Cependant, Charlie peut modifier le message et le signer avec sa propre clé privée. Quand Bob reçoit le message, il va vérifier la signature avec ce qu’il croit être la clé publique d’Alice, mais qui est en réalité la clé publique de Charlie. La vérification de la signature sera donc valide pour un message qui a en réalité été signé par Charlie et non par Alice.

Résultat : l’intégrité du message est compromise !

Cette attaque peut vous sembler complexe, mais est en réalité simple à mettre en place.

Pour se prémunir contre ce type d’attaque, vous devez vous assurer que la clé publique d’Alice appartienne bien à Alice et que la clé publique de Bob appartienne bien à Bob, et rejeter toutes les clés publiques dont vous ne pouvez pas prouver qui en est le propriétaire. Pour cela, vous allez utiliser des certificats numériques signés.

Qu’est-ce qu’un certificat numérique ?

Un certificat numérique, aussi appelé certificat électronique ou certificat de clé publique, est un fichier contenant des informations qui vont permettre d’identifier un utilisateur et de lui associer sa clé publique.

Ce fichier contient 4 informations importantes :

• l’identifiant de la personne ou du serveur à qui appartiennent la clé publique et le certificat. Pour une personne, cela peut être son adresse email. Pour un serveur web, c’est en général son nom de domaine ;

• la clé publique de la personne ou du serveur ;

• les dates de début et de fin de validité de la clé publique et du certificat ;

• la signature du certificat qui permet de prouver que la clé publique est bien celle de l’identifiant.

La signature du certificat utilise elle-même un protocole de signature à clé publique, avec la clé publique d’un tiers de confiance. Lorsqu’un certificat est signé avec sa propre clé publique, on dit que c’est un certificat autosigné.

Le format de certificat le plus courant est le standard X.509, utilisé notamment par HTTPS, IPsec, PGP et SSH. En plus des informations de base, un certificat X.509 contient des informations complémentaires :

• le nom de l’algorithme de chiffrement et de signature avec lesquels la clé publique du certificat est compatible ;

• le rôle du certificat.

Un certificat a une durée de vie limitée. En effet, un utilisateur peut changer de clé publique, parce qu’il a perdu ou compromis sa clé privée. Il peut aussi ne plus avoir de clé publique lorsqu’il quitte une entreprise. Lorsque vous créez un certificat, vous lui assignez une date de début de validité et une date de fin de validité.

Voici les étapes du cycle de vie d’un certificat :

Création

Le certificat est créé en associant la clé publique et une information d’identification de son propriétaire. Il contient une date de début de validité et une date de fin de validité. Ces informations sont signées avec la clé privée d’un serveur.

Révocation

Un certificat peut être révoqué, c’est-à-dire qu’il n’est plus considéré comme valide. Cela peut arriver si l’utilisateur a perdu sa clé privée, si un attaquant a eu accès à sa clé privée, ou encore si l’utilisateur quitte une entreprise. Comme un certificat est public, il ne peut pas être supprimé, car un attaquant pourrait conserver une copie du certificat signé pour le réutiliser. Pour révoquer un certificat, il faut l’ajouter à la liste de révocation de certificats (CRL) de l’organisation. La révocation peut être définitive ou temporaire. Lorsqu’un certificat est révoqué, il n’est plus valide et il ne faut plus lui faire confiance.

Renouvellement

Un certificat peut être renouvelé lorsque sa date de fin de validité est proche. Pour cela, vous remplacez la date de fin de validité par une date ultérieure. Il faut alors de nouveau signer le certificat à partir des nouvelles informations. Pour éviter toute interruption de service, il ne faut pas oublier de renouveler les certificats avant leur expiration !

Expiration

Quand le certificat dépasse la date de fin de validité et n’est pas renouvelé, il est expiré. Lorsqu’un certificat est expiré, il n’est plus valide et il ne faut plus lui faire confiance.

Validité d’un certificat

Valide

Un certificat est valide, c’est-à-dire digne de confiance, lorsque :

• il est signé par une clé à laquelle on fait confiance ;

• l’on se trouve entre la date de début de validité et la date de fin de validité ;

• le certificat n’a pas été révoqué, et donc ne se trouve pas dans la liste de révocation de certificats.

Non valide

Inversement, un certificat est non valide, c’est à dire non digne de confiance, s’il n’est pas signé par une clé à laquelle on fait confiance, que l’on ne se trouve pas entre la date de début de validité et la date de fin de validité, ou que le certificat a été révoqué et donc se trouve dans la liste de révocation de certificats.

il ne faut plus lui faire confiance, c’est-à-dire que l’on n’est plus assuré que la clé publique appartienne réellement à l’utilisateur.

Pour faire confiance à un certificat, il faut qu’il soit signé par une paire de clés privée/publique à laquelle vous faites confiance.

Pour vérifier la signature d’un certificat, il faut donc déjà faire confiance à la clé publique qui signe ce certificat. Cette clé publique est appelée l’autorité de certification (Certificate Authority, ou CA) ; elle est la clé de voûte de l’infrastructure de clé publique.

L’infrastructure de clé publique (Public Key Infrastructure, ou PKI) désigne l’ensemble des serveurs servant à signer, distribuer et valider les certificats. Une PKI est composée d’une autorité de certification (CA), d’une autorité de dépôt (Repository) et d’une liste de révocation de certificats. Je vous propose de les détailler ci-dessous.

L’autorité de certification

L’élément principal d’une PKI est l’autorité de certification, aussi appelée autorité de certification racine. Il s’agit d’un serveur qui possède une paire de clés privée/publique et un certificat autosigné appelé certificat racine (en anglais root certificate). Tous les utilisateurs de la PKI font confiance à ce certificat racine.

Lorsque vous créez un nouveau certificat, vous envoyez les informations du certificat au serveur et vous lui demandez de signer le certificat avec la clé publique du certificat racine. L’autorité de certificat utilise sa clé privée associée à la clé publique du certificat racine, pour créer la signature du certificat. L’utilisateur peut ensuite envoyer son certificat signé à un autre utilisateur de la PKI. Cet autre utilisateur peut vérifier que le certificat a bien été signé par l’autorité de certification racine, et fait donc confiance au nouveau certificat.

L’autorité de dépôt

Ce serveur fait office d’annuaire. Il contient tous les certificats signés par l’autorité de certification. Ainsi, lorsqu’Alice a besoin de la clé publique de Bob, elle peut faire une recherche auprès de l’autorité de dépôt.

L’autorité de dépôt héberge également la liste de révocation de certificats.

La liste de révocation de certificats

Cette liste contient tous les certificats révoqués. La liste est signée par l’autorité de certification et peut être consultée auprès de l’autorité de dépôt.

L’autorité de certification intermédiaire

Dans une grande organisation, il est possible d’avoir plusieurs autorités de certification intermédiaires. Ces serveurs possèdent un certificat signé par l’autorité de certification racine et peuvent signer les certificats des utilisateurs. Pour vérifier la signature d’un certificat utilisateur, vous vérifiez toute la chaîne de signatures de certificat, pour remonter au certificat racine de l’autorité de certification racine. C’est le principe de la chaîne de certification  ou chaîne de confiance. Ainsi, il n’y a pas besoin de communiquer directement avec l’autorité de certification racine pour signer ou vérifier un certificat.

• L’échange de clés publiques est vulnérable aux attaques de l’homme du milieu ;

• pour éviter cette attaque, on utilise un certificat signé pour échanger une clé publique ;

• un certificat signé contient des informations d’identification comme un email, la clé publique associée et la signature du certificat ;

• la signature du certificat est réalisée par une autorité de certification, dont la clé publique est déjà connue et validée par le destinataire du certificat ;

• une infrastructure de clés publiques (PKI) désigne l’ensemble des serveurs servant à créer et valider les certificats signés.