Principes de base des infrastructures à clés publiques (PKI)

Une infrastructure à clé publique comprend tous les composants (matériel, logiciel, personnes et processus) nécessaires à l'utilisation de certificats numériques. Une PKI se compose d'une ou de plusieurs autorités de certification (CA). Les tâches d'une PKI sont notamment les suivantes

garantir l'authenticité des clés, c'est-à-dire établir un lien compréhensible entre une clé et son origine afin d'empêcher tout abus
la révocation des certificats, c'est-à-dire s'assurer que les clés mises hors service ou compromises (par exemple volées) ne peuvent plus être utilisées
Garantie de l'obligation (non-répudiation), c'est-à-dire, par exemple, que le propriétaire d'une clé ne peut pas nier qu'elle lui appartient.
Imposer des directives (en anglais policies), c'est-à-dire des procédures standardisées pour l'utilisation des certificats.

Pour entrer dans le vif du sujet, voir aussi l'article "Bases de la cryptographie" prendre en compte.

Il est important de mentionner ici qu'une autorité de certification ne s'occupe en général que de la gestion des clés publiques, (à quelques exceptions près) mais pas de celles des clés privées.

Une autorité de certification se compose généralement d'un ou de plusieurs ordinateurs avec un logiciel installé en conséquence, des processus et des documents associés. Les autorités de certification sont des composants d'une infrastructure à clé publique (PKI). Leurs tâches principales consistent à

vérifier l'identité des demandeurs et veiller à ce que les certificats ne soient délivrés qu'aux demandeurs autorisés
de délivrer des certificats (c'est-à-dire de les signer) et de confirmer ainsi l'identité vérifiée.
de gérer et de faire connaître le statut de révocation des certificats délivrés

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Dans les réseaux d'entreprise, il est courant d'établir une hiérarchie de plusieurs autorités de certification. Cela augmente d'une part la sécurité et d'autre part l'évolutivité. Le modèle le plus courant est celui à deux niveaux : Au sommet d'une telle hiérarchie se trouve une seule autorité de certification racine (Root CA), à laquelle sont subordonnées plusieurs autorités de certification intermédiaires (Intermediate CA) et des autorités de certification émettrices (Issuing CA).

De cette manière, l'autorité de certification racine peut par exemple être protégée efficacement contre les attaques provenant du réseau en n'étant jamais connectée à un réseau (d'où l'expression "Offline Root CA"). Dans de rares cas, une hiérarchie à trois niveaux est utilisée ; dans ce cas, un autre niveau d'autorités de certification intermédiaires est utilisé entre l'autorité de certification racine et les autorités de certification émettrices, qui peuvent par exemple être utilisées pour imposer des directives organisationnelles (en anglais Policy CA).

Le composant technique le plus critique d'une autorité de certification est sa clé privée. Si un attaquant parvient à de détourner ou d'usurper la clé privéeSi l'autorité de certification n'est pas en mesure de fournir un certificat, toute la chaîne de confiance en aval (c'est-à-dire y compris tous les certificats qu'elle a émis par le passé et qu'elle émettra à l'avenir) est compromise. C'est pourquoi la clé privée de chaque autorité de certification doit être traitée avec une sensibilité particulière et protégée par des mesures appropriées. Sans mesures de protection particulières, elle se trouve à la fois sur le disque dur et dans la mémoire de l'ordinateur de l'autorité de certification pendant l'exécution du logiciel de l'autorité de certification et peut potentiellement être dérobée à partir de là.

Pour remédier à ce problème, il convient de prendre les mesures de sécurité suivantes :

Les AC racines et les AC de politique ne devraient jamais être connectées à un réseau (c'est-à-dire en fait à aucun moment, même pendant l'installation ou la maintenance) afin d'éviter qu'elles puissent être attaquées et compromises par ce biais. Contrairement à tous les autres certificats d'une PKI, celui de l'AC racine ne peut pas être révoqué dans la plupart des cas, car il est signé par lui-même (en anglais : self-signed).
Une AC ne devrait être exécutée dans un environnement virtuel (p. ex. VMware, Xen, Hyper-V), si tant est qu'elle le soit, qu'en appliquant des mesures de sécurité séparées. Outre le risque de vol de données sensibles, il existe un risque élevé de manipulation non détectée en raison de la fonction "snapshot" présente dans la plupart des environnements de virtualisation. Les hôtes de virtualisation devraient être protégés séparément contre l'accès de personnes non autorisées, par exemple par une armoire de serveur supplémentaire verrouillable, des contrôles d'accès étendus et l'utilisation d'un cryptage intégral des disques durs.
La clé privée d'une CA doit être associée à un Module de sécurité matériel (angl. Hardware Security Module, HSM) sont sécurisés. Il s'agit d'appareils dédiés qui gardent la clé privée sous clé (non-exportabilité) et qui peuvent garantir, grâce à un modèle de droits échelonné, que seules les personnes et les ordinateurs autorisés peuvent utiliser la clé privée. Les opérations cryptographiques ne peuvent être effectuées que via le HSM.

Utilisation de certificats avec Microsoft Windows

Les applications qui fonctionnent sur le système d'exploitation Microsoft Windows ont en principe deux possibilités d'utiliser des certificats :

Microsoft Windows comprend les Microsoft CryptoAPIUne interface de programmation qui peut effectuer des opérations cryptographiques pour le compte de l'application appelante. L'un des principaux avantages est que les certificats peuvent être partagés par les applications et gérés de manière centralisée.
L'application peut implémenter ses propres opérations cryptographiques, et ainsi contourner la CryptoAPI de Microsoft. Un exemple populaire est le navigateur Mozilla Firefox, qui utilise sa propre implémentation cryptographique.

Dans les considérations qui suivent, nous supposons que les applications utilisées ont recours à la CryptoAPI de Microsoft.

Validation des certificats

La validation des certificats peut être divisée en plusieurs processus interdépendants, qui sont décrits plus en détail ci-dessous :

La recherche de certificats décrit le processus consistant à identifier tous les certificats d'autorité de certification nécessaires à la vérification d'un certificat.
La validation du chemin de certification décrit le processus d'établissement de la chaîne de confiance en vérifiant tous les certificats de la chaîne jusqu'à ce qu'elle se termine par un certificat d'une autorité de certification racine jugé digne de confiance. Les deux processus sont décrits dans l'article "Principes de base : recherche de certificats et validation du chemin de certification" décrit.
La vérification de l'état de révocation décrit le processus de vérification de l'état de révocation pour tous les certificats au sein d'une chaîne de confiance. Il est décrit dans l'article "Principes de base : vérification du statut de révocation des certificats" décrit.
La validation des certificats décrit le processus consistant à vérifier la validité du contenu de tous les certificats de la chaîne.

Vérification de la validité des certificats

La fiabilité d'un certificat numérique se mesure entre autres selon les critères suivants :

Si le certificat se trouve dans un format valide (c'est-à-dire que son codage correspond aux normes courantes et peut être lu sans erreur par le destinataire) ?
L'identité confirmée par le certificat (Subject Name, resp. Subject Alternative Name) est-elle valable ?
La chaîne de certificats est-elle complète ?
La chaîne de certificats se termine-t-elle par un certificat d'autorité de certification racine considéré comme fiable ?
Le certificat se trouve-t-il dans sa période de validité ?
La valeur de hachage signée du certificat correspond-elle à sa valeur de hachage réelle (calculée lors de la vérification du certificat) ?
Si le certificat a été délivré par l'autorité de certification révoquer ou est-il stocké dans la liste des certificats non fiables ?
Si le certificat a été validé pour l'utilisation prévue ("Utilisation des clés" et/ou "Utilisation étendue des clés" Attributs) ?
Le certificat est-il soumis à certaines Contraintes (angl. Constraints)par exemple sur certains Noms de domaine ou Niveaux hiérarchiques?
Werden alle als kritisch markierten Erweiterungen des Zertifikats von der das Zertifikat prüfenden Anwendungen verstanden?

Ce processus est effectué pour chaque certificat d'une chaîne de certificats à vérifier. Ce n'est que lorsque tous les certificats d'une chaîne ont passé ce processus avec succès et sont donc reconnus comme étant dignes de confiance que le certificat à vérifier est finalement reconnu comme étant digne de confiance.

Liens complémentaires :

Sources externes

Qu'est-ce qui se trouve dans une chaîne de certificats et pourquoi ? (Ryan Hurst)