---
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.
