--- title: "Sécurité des réseaux : les certificats" date: 2022-10-18 tags: ["TLS", "certificats", "PGP"] categories: ["Sécurité des réseaux", "Cours"] matjax: 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.