Autorités de certification et chaînes de confiance

Le chiffrement asymétrique n’est utile que si vous pouvez être certain qu’une clé publique appartient bien à la personne ou à l’organisation visée. Sans mécanisme de confiance, un attaquant peut intercepter votre demande de clé publique et la remplacer par la sienne : c’est une classique attaque de l’homme du milieu. La Public Key Infrastructure (PKI) résout ce problème de confiance en introduisant une Certificate Authority (CA), c’est-à-dire un tiers de confiance qui signe numériquement des certificats associant des clés publiques à des identités vérifiées. Si vous faites confiance à la CA, vous pouvez faire confiance à toute personne ou organisation qu’elle a certifiée.

Une Certificate Authority (CA) est une organisation qui émet des certificats numériques après avoir vérifié l’identité du demandeur. La CA signe chaque certificat avec sa propre clé privée, ce qui permet à toute personne qui lui fait confiance de vérifier l’authenticité du certificat à l’aide de la clé publique de la CA. Il en existe deux types : les Public CAs (comme DigiCert, GlobalSign et Let’s Encrypt), dont les certificats racine sont préinstallés dans les systèmes d’exploitation et les navigateurs ; et les Private (Internal) CAs, que les organisations gèrent elles-mêmes pour émettre des certificats internes (VPN, services internes, certificats d’appareils).

Une Root CA est l’autorité la plus élevée d’une hiérarchie PKI. Les certificats de Root CA sont auto-signés : aucune autorité supérieure ne peut les valider. Les certificats racine sont plutôt considérés comme fiables parce que les éditeurs de systèmes d’exploitation (Microsoft, Apple, Mozilla) évaluent les Root CAs au moyen de procédures d’audit rigoureuses et préinstallent leurs certificats dans des magasins de certificats de confiance. Le magasin de confiance d’un navigateur courant contient environ 130 à 150 Root CAs de confiance. Si une Root CA est compromise, tous les certificats qu’elle a déjà émis deviennent suspects ; c’est pourquoi les clés privées des Root CAs sont conservées dans des modules matériels de sécurité (HSM) hors ligne et isolés du réseau.

Les Root CAs émettent rarement des certificats directement pour les entités finales. Elles créent plutôt des Intermediate CAs (également appelées autorités de certification subordonnées) en émettant des certificats aux opérateurs de ces autorités intermédiaires. Les Intermediate CAs émettent ensuite les certificats des entités finales (comme les certificats de serveurs HTTPS). Cette hiérarchie de délégation a plusieurs objectifs : protéger les clés privées des Root CAs en les conservant hors ligne (si une Intermediate CA est compromise, seule sa chaîne de certificats est révoquée, et non toute la racine) ; permettre des autorités spécialisées selon les usages (signature de code ou TLS) ; et établir une hiérarchie organisationnelle au sein d’une PKI privée.

Une chaîne de certificats (ou chaîne de confiance) est la succession de certificats qui remonte du certificat de l’entité finale jusqu’à la Root CA de confiance. Pour un site HTTPS classique, la chaîne est la suivante : certificat de l’entité finale (par exemple, *.google.com) → certificat de l’Intermediate CA (par exemple, Google Trust Services WR2) → certificat de la Root CA (par exemple, Google Trust Services LLC). Lorsque votre navigateur consulte un site, il valide toute cette chaîne : il vérifie que la signature de chaque certificat a été produite par le niveau qui le précède et que la racine figure dans le magasin de confiance. Toute rupture de cette chaîne provoque une erreur de certificate.

Lorsque deux hiérarchies PKI distinctes doivent établir une confiance mutuelle, elles utilisent la certification croisée. Chaque CA émet un certificat pour la racine de l’autre, ce qui établit la confiance dans les deux directions. Une Bridge CA est une CA centrale qui effectue une certification croisée avec plusieurs CAs de domaine et crée ainsi un réseau de confiance entre différentes organisations ou agences gouvernementales. La US Federal Bridge CA relie plusieurs systèmes PKI du gouvernement fédéral. La certification croisée est complexe à gérer, mais elle est nécessaire lors de la fusion d’organisations ou de l’établissement d’une confiance entre agences sans les regrouper dans une seule hiérarchie.

Une Registration Authority (RA) est une entité qui vérifie l’identité pour le compte d’une CA, mais qui n’émet pas elle-même de certificats. La RA reçoit les demandes de certificat, vérifie l’identité du demandeur (à l’aide de contrôles de documents, de la validation du domaine ou d’une vérification en personne, selon le type de certificat), puis transmet les demandes approuvées à la CA pour signature. Cette délégation permet aux CAs d’augmenter leur capacité d’émission sans effectuer elles-mêmes toutes les vérifications. Dans une PKI d’entreprise, la RA peut être le service des ressources humaines ou le support informatique chargé de valider les demandes de certificat des employés.

Les CAs proposent des certificats assortis de différents niveaux de validation, selon la profondeur de la vérification de l’identité du demandeur. Domain Validation (DV) : la CA vérifie uniquement que le demandeur contrôle le domaine (procédure automatisée réalisée en quelques minutes, utilisée par Let’s Encrypt). Organization Validation (OV) : la CA vérifie l’existence légale de l’organisation (de 1 à 3 jours ouvrés). Extended Validation (EV) : vérification la plus approfondie, portant sur l’identité légale, l’adresse physique et l’existence opérationnelle (de 1 à 2 semaines, utilisée pour afficher le nom de l’entreprise en vert dans la barre d’adresse du navigateur). Le DV convient au chiffrement de base ; l’EV est appropriée pour les cibles à forte valeur, comme les sites bancaires.

L’épinglage des certificats est une technique qui consiste à programmer une application pour qu’elle n’accorde sa confiance qu’à un certificat ou une CA spécifique, plutôt qu’à n’importe quel certificat provenant d’une Root CA de confiance. Cela empêche les attaques MITM, même si un attaquant obtient un certificat frauduleux auprès d’une CA de confiance. Les applications mobiles et les applications sensibles à la sécurité utilisent l’épinglage pour s’assurer qu’elles n’acceptent que les certificats de leurs propres serveurs. Inconvénient : si le certificat épinglé expire ou est renouvelé, l’application cesse de fonctionner jusqu’à sa mise à jour. HPKP (HTTP Public Key Pinning) était un mécanisme d’épinglage au niveau du navigateur, abandonné en raison des risques liés aux mauvaises configurations.

Les organisations gèrent leur propre CA privée pour leurs besoins internes en certificats : authentifier les clients VPN, émettre des certificats pour les services HTTPS internes, signer du code et authentifier des appareils. Les Active Directory Certificate Services (AD CS) de Microsoft constituent la solution de CA privée d’entreprise la plus courante. Les certificats d’une CA interne doivent être distribués à tous les appareils et navigateurs qui doivent faire confiance aux certificats émis en interne, généralement au moyen d’une stratégie de groupe. Les CAs privées ne peuvent pas émettre de certificats reconnus comme fiables sur l’Internet public ; leur utilisation est limitée aux appareils de l’organisation sur lesquels la racine de la CA privée est installée.

La compromission de DigiNotar (2011) est l’incident touchant une CA le plus important à connaître pour les candidats à Security+. La CA néerlandaise DigiNotar a été piratée par des attaquants qui ont émis des certificats frauduleux pour Google, Mozilla et des domaines gouvernementaux. Ceux-ci ont été utilisés en Iran pour mener des attaques de l’homme du milieu contre des citoyens. Résultat : tous les principaux éditeurs de navigateurs et de systèmes d’exploitation ont immédiatement supprimé DigiNotar de leurs magasins de racines de confiance, invalidant tous les certificats que DigiNotar avait émis jusque-là. DigiNotar a fait faillite en quelques semaines. Cet incident a montré qu’une compromission de CA est catastrophique et explique pourquoi les enregistrements DNS CAA, la transparence des certificats et l’authentification multifacteur des systèmes de CA sont désormais exigés.

Évaluez votre compréhension des concepts de CompTIA Security+ (SY0-701) abordés dans cette leçon.

Dans cette leçon, vous avez appris que les Certificate Authorities associent les clés publiques à des identités vérifiées ; la chaîne de confiance part de l’entité finale, passe par les CA intermédiaires et aboutit à une racine auto-signée ; les Root CAs sont conservées hors ligne dans des HSM et approuvées au préalable par les systèmes d’exploitation ; enfin, la compromission d’une CA (DigiNotar) peut invalider des millions de certificats. Nous allons maintenant étudier la structure d’un X.509 Certificate.