6.2 KiB
| title | date | tags | categories | matjax | |||||
|---|---|---|---|---|---|---|---|---|---|
| Sécurité des réseaux : les certificats | 2022-10-18 |
|
|
true |
Un certificat est une pièce d'identité comprenant:
- une clé publique;
- un émetteur;
- des information sur le détenteur;
Le tout est signé par l'émetteur.
Lors de la réception d'un certificat, le client vérifie:
- l'autorité l'ayant signé (Certificate Authority)
- la validité
- l'identité
Dans le cas du CA, il est possible de se référer à une chaine de certification (on parle alors de certificats intermédiaire.)
La norme x509
x509 est une norme définissant les formats pour les certificats à clé publique, leus attributs, un algorithme de validation de chemin et les liste de révocation de certificat.
Cette norme fait parti de x500, elle repose sur une hiérarchie d'autorité de certification et la cryptographie asymétrique (clé publique / clé privée)
Anatomie d'un certificat
Un certificat se compose des élémemts suivants:
- la version du format de certificat
- un numéro de série unique pour l'autorité émettrice
- identifiant de l'algorithme de chiffrement utilisé
- nom de l'émetteur qui est donc celui de l'autorité de certification
- une période de validité composé d'une date de début et une date de fin
- nom du sujet qui peut être un nom d'utilisateur ou un sujet plus complexe respectant la norme x500
- clé publique du sujet ainsi que l'algorithme utilisé
- identifiant unique de l'émetteur, c'est un élément facultatif qui permet d'identifier sans ambiguïté l'autorité de certification émettrice.
- identifiant unique du sujet élément facultatif qui permet d'identifier sans ambiguïté le sujet du certificat
- un ensemble de champs permettant d'ajouter des extensions
- enfin la signature qui couvre tous les autres champs du certificat : ce champ contient le code de hachage de ces champs chiffrés avec la clé privée de l'autorité de certification.
La notation suivante est utilisée:
\[ CA << A >> = CA{V,SN,AI,CA,TA,A,Ap }\]
Dans cette notation, \(CA << A >>\) est le certificat de \(A\) émis par \(CA\) et \(CA{SN}\) représente la signature de \(SN\) par \(CA\)
L'autorité de certification signe le certificat avec sa clé privée. Si l'utilisateur détiens la clé publique correspondante dans son magasin de certificat, il pourra alors vérifier la validité.
Sécuriser les certificats et leurs chaînes
Lorsqu'un utilisateur reçoit un certificat depuis un serveur, il doit s'assurer que celui-ci est le bon.
HPKP - certificate pinning
Comme pour le SSH, il peu mémoriser son empreinte lors de la première connexion. Il peut utiliser HPKP -- HTTP Public Key Pinning -- pour la mémoriser, le tout couplé à HSTS -- HTTP Strict Transport Security.
Mais celle solution est loi d'être parfaite : quid du changement de certificat. En plus l'attaquant pourrait être présent dès la première connexion.
Certificate transparency
C'est une solution poussée par Google. Il reprend en quelque sorte le principe du HPKP en l'améliorant.
Dès qu'une autorité de certification émet un certificat, elle envoie un condensat de celui-ci sur un dépôt public contrôlé par un tiers (Google en fait). Le client peut demander au dépôt la validité du certificat.
Problème ici : les dépôts (Google donc) deviennent tout puissant en concentrant les pouvoirs. Ils pourraient par exemple refuser d'ajouter les certificats venant de telle autorité ou portant sur tel sujet.
Certificat Autority Authorization
Ce mécanisme prend la forme d'un enregistrement DNS CAA donnant la liste des
autorité de certification pouvant émettre des certificat pour la zone.
Cette protection est donc sensible aux attaque sur le DNS.
DANE -- DNS-based Authentication of Named Entities
Contrairement à Certificate Transparency ou la sécurité est déléguée à un tiers, avec DANE (et *DNSSEC) on en prend le contrôle. DANE dépends de DNSSEC qui se révèle compliqué à implémenter (et administrer).
DANE permet de se passer d'autorité de certification.
DNSSEC
DNSSEC permet de résoudre certains problèmes de sécurité liés à DNS. Il permet de sécuriser les données envoyées par le DNS.
chaque entité dispose d'un couple de clés (privé / publique, on parle bien de cryptographie asymétrique). Chaque enregistrement d'une zone est signé par la clé privée du détenteur. Cette signature peut être vérifiée par sa clé publique. Afin d'assurer l'authenticité de cette dernière, elle est signée par la clé privée de la zone au-dessus -- et non pas la clé privée du détenteur.
Dans la pratique, chaque zone dispose de deux paire de clés :
- la KSK: Key Signing Key
- la ZSK: Zone Signing Key
le lien entre les deux est réalisée par la fonction:
\[ crypt( priv_KSK, hash(ZSK) \]
La KSK sert à signer la ZSK. La KSK publique est envoyée au détenteur de la zone parente pour signature.
DNSSEC / DANE
Maintenant que DNSSEC est en place il est possible de stocker les certificats dans un enregistrement DNS: TLSA.
Le client peut alors vérifier la validité du certificat.
DoH, DoT
Ces deux mécanismes permettent de sécuriser le protocole DNS en le passant sur du HTTPS (DNS over HTTPS) ou en l'en capsulant dans TLS (DNS over TLS).
Les certificats assurent deux propriétés: l'authentification du résolvez qui répond et le chiffrement des messages.
PGP -- Pretty Good Privacy
PGP utilise la cryptographie asymétrique, chaque entité dispose donc d'une paire de clés. L'utilisation la plus courante de PGP et la signature (cryptographique) et le chiffrement de courriels. Il est aussi utilisé dans la distribution logicielle et notamment dans les dépôts de distributions GNU/Linux ou BSD.
Pour le chiffrement, PGP créé une clé symétrique aléatoire qui est ensuite chiffrée avec la clé publique du destinataire.
Chaque partie publique contient un espace où d'autres personnes peuvent apposier leurs signatures avec une note.