PKI en action

Bob et le message en question est un ordre de bourse. Comme Secure MIME (S/MIME) est un protocole accepté pour la sécurité du courriel, Bob et Alice ont tous deux besoin d’un client e-mail conforme à S/MIME tel que Microsoft Outlook. Bob peut en option utiliser la clé privée qui correspond à son certificat pour signer son message. Cette signature est un hash (total de contrôle) du message crypté à l’aide de la clé privée de Bob. Le client e-mail de Bob envoie le message, la signature et le certificat à Alice. Le client e-mail d’Alice voit que le message est en format S/MIME et vérifie aussitôt la signature. A l’aide du même algorithme que la CA émettrice à utilisé, son client calcule son propre hash du message, décrypte le hash avec la clé publique qui se trouve dans le certificat de Bob, puis compare les deux hashes. S’ils correspondent, le client d’Alice sait que le message a été signé par la clé privée qui correspond à la clé publique du certificat.

Mais, direz-vous, comment Alice et son client e-mail savent que la clé publique est vraiment celle de Bob ? Après tout, la clé publique qui se trouve dans le certificat pourrait avoir été remplacée discrètement pendant le transit, ou le message et le certificat pourraient être tous deux faux. Avant de faire confiance à un message signé avec un certificat, le client e-mail d’Alice doit vérifier le certificat. Nous avons vu précédemment que, pour que PKI fonctionne, il faut que tous les utilisateurs du système fassent confiance à la CA. Pour garantir cette confiance, la CA a déjà donné à Alice sa clé publique. (Par exemple, Windows 2000 et les OS ultérieurs incluent les certificats autosignés de toutes les principales CA sur Internet et obtiennent automatiquement les certificats des CA Enterprise que vous établissez dans votre environnement d’AD.

Vous pouvez utiliser les stratégies de groupe pour spécifier d’autres CA de confiance ou supprimer les CA par défaut.) Par conséquent, le client e-mail d’Alice peut vérifier le certificat de Bob. Son client (celui d’Alice) calcule son propre hash du certificat de Bob et utilise la clé publique de la CA pour décrypter le hash de la signature numérique du certificat. Si les hashes correspondent, le client sait que la CA a utilisé sa clé privée pour signer le certificat. Moyennant quoi, le client e-mail d’Alice est certain que l’information dans le certificat – comme le nom, l’adresse de courriel et la clé de Bob – sont vraiment ceux de Bob, parce que la CA a authentifié Bob avant de signer sa demande de certificat. Et donc Alice sait que l’ordre de bourse est indiscutable.

Bien entendu, Alice ne fait confiance au message que parce qu’elle fait confiance à la CA. Si une CA est défaillante dans la protection de sa clé privée ou dans l’authentification d’un demandeur de certificat, la sécurité de la PKI s’effondre. En fait, les CA tierce partie comme VeriSign émettent différents niveaux de certificat qui correspondent au zèle qu’ils mettent à vérifier les demandeurs de certificat. Pour une lecture intéressante sur ce genre de procédures, voir « 4. VTN Certificates » sur le Verisign Relying Party Agreement.

Parallèlement, la sécurité d’un certificat individuel dépend du secret de la clé privée correspondant au certificat. Si la clé privée de Bob est volée, le voleur peut usurper l’identité de Bob. Dans un futur article, j’expliquerai comment les listes de révocation de certificats (CRL, certificate revocation lists) et les standards PKI affrontent cette situation et d’autres liées à l’utilisation des certificats et des clés privées.