# [TC3] TD4 - CSC
###### tags: `CSC`, `S2`, `TC3`

# Autorités de certifications

## Introchon d'inde


## Echange direct

Alice et Bob communiquent à travers un canal non sécurisé. La première façon pour Alice d’obtenir l’association attendue serait de la demander à Bob à travers ce canal. C’est ce qu’il se passe lorsque l’on parle, en HTTPS, de certificats auto-signés.

1. *Sans prendre en compte la sécurité, est-ce que cela peut fonctionner ?*
Oui si Alice accepte le risque que le certificat ne soit pas certifié.

2. *Si cela fonctionne, quel peut être le risque (en prenant maintenant en compte la sécurité) ? A-t-on gagné quelque chose par rapport à une communication en clair ?*
²Que le certificat soit généré par un attaquant au milieu, donc une attaque Man-in-the-middle. On a rien gagné par rapport au clair.

3. *Décrivez une attaque possible par man-in-the-middle.*
Un attaquant crée un site web, identique à celui de l'attaqué mais avec son propre certificat, il peut router les requêtes envoyée vers son site vers le site original. Cela lui permet de changer les informations envoyées à Bob.

## Ajout d’un nouvel acteur : la CA

Nous intégrons un troisième acteur C (CA), qui va agir comme un tiers de confiance, et ajoutons les connaissances suivantes :

+ C connaît PubC/PrivC (son couple de clés)
+ A connaît PubC et fait confiance à C
+ L’objectif est que C certifie beaucoup d’associations (identité, clé publique), afin de servir de pivot unique pour de nombreuses communications

1. *À partir du cours, refaites la cinématique de CA/HTTPS dans ce modèle : les échanges entre B et C, puis entre B et A (A et C ne communiquent jamais directement !). Quel élément est le certificat ? Vous utiliserez les notations présentées en début de sujet.*

    participant Certif
    Bob->Certif: Can i get a certificate ?
    Note left of Bob: Bob gives his PubB
    Note right of Certif: Certif signs certificate with PubB et PrivC
    Certif->Bob: Certif gives the certificate
    Alice->Bob: Requests something
    Bob->Alice: Answers with certificate

2. *Comment C vérifie-t-elle l'association déclarée (B, Pub~B~) ?*
Tu peux pas vérifier car C ne peut pas connaître B.

3. *Comment A vérifie-t-elle l'association obtenue (B, Pub~B~) ? Quelle est la chaîne de confiance ?*
A vérifie la signature du h((B,Pub~B~))~PrivC~. On fait confiance à C pour nous dire qu'il s'agit bien de B.

4. *Que déduire si le certificat reçu par A est bien signé mais pour une identité différente de B ? (en HTTPS, l'identité attendue, B par exemple, correspond au nom d'hôte de la requête, par exemple `www.insa-lyon.fr` pour une requête à `https://www.insa-lyon.fr/index.html`)*
Qu'il y a eu une attaque MiTM et que on ne peut pas vérifier (B, Pub~B~) avec h((B, Pub~B~))~PrivC~

## L'écosystème HTTPS

Ce modèle est tout à fait possible avec une unique CA. Cependant, en pratique, il s’est développé avec une multitude de CA, notamment pour HTTPS. Chaque serveur a le choix de quelle CA il veut être certifié. Du coup, un navigateur reconnaît typiquement de l’ordre d’une petite centaine de CA différentes.

Imaginez maintenant que l’une des autorités soit compromise (malveillante ou attaquée):

1. *Quel impact pour les clients reconnaissant cette autorité ?*
On ne peut pas garantir que les certificats ne soient pas compromis.
2. *Quel impact pour un site dont le certificat est émis par une autre autorité ?*
Comme les navigateurs reconnaissent cette CA compromise, ils peuvent accepter ce certificat même si Bob ne l'as pas demandé et donc on a plus de sécurité.

## Révocation

La certification est un processus hors-ligne, c’est-à-dire qu’une fois émis, un certificat reste valide jusqu’à une date fixée lors de la signature (typiquement en années). Il ne s’agit pas d’une validation interactive valable à l’instant de la requête HTTPS.

Dans ses processus, une CA doit donc permettre de révoquer des certificats lorsqu’un site se fait voler sa clé privée.

### CRL

La CRL (Certificate Revocation List) est une liste des certificats révoqués, émise et tenue à jour par la CA.

1. *En quoi l'utilisation de CRL va à l'encontre de l'approche hors-ligne (non interactive) et quel risque cela pose pour la CA ?*
On doit checker à chaque fois si le certificat a été révoqué et donc ça peut risque de charge trop élevé pour les CAs.
2. *Que faire en cas de CRL non à jour et de CA non disponible pour mettre à jour ?*
Il ne faut pas accepter le certificat. Mais en même temps il n'y a pas de vrai bonne réponse.

### OCSP

OCSP (Online Certificate Status Protocol) permet à un client de vérifier en temps réel la validité d’un certificat auprès de la CA émettrice.

1. *Cela résoud-il le risque que l'utilisation de CRL fait peser sur les CA ?*
Non car il faut tout de même faire une requête dans ce protocole et on a donc toujours un volume de trafic élevé.
2. *Avec l'agrafage OCSP (stapling), c'est le serveur web qui demande à la CA une preuve de validité valable 24h et la présente ensuite à ses clients. Cela résoud-il la surcharge de la CA ? Quelle différence par rapport à des certificats valables 24h ?*
Cela diminue la surcharge car il n'y a une requête par site que toute les 24 heures. Il n'y a pas de différence avec les certificats d'une durée de 24h.
3. *Que faire en cas d'absence d'agrafage OCSP ?*
Il faut refuser. En pratique, on accepte car sinon c'est trop galère.

## Organisation d’une CA à étages

Pour limiter les risques et impacts d’une compromission, chaque certificat a une durée de vie limitée, spécifiée dans l’association. Les CA emploient de plus plusieurs clés de niveaux de sensibilité différents. Cela permet d’avoir une ancre de confiance connue par A avec une longue durée de vie (par exemple 30 ans) tout en utilisant quotidiennement du matériel cryptographique avec une durée de vie plus courte (par exemple 1 an).

C a ainsi, à l’instant _t_ :

+ Pub~CL~/Priv~CL~, les clés longues, liées au certificat _racine_
+ Pub~CC~/Priv~CC~, les clés courtes, liées au certificat _intermédiaire_

Typiquement, un certificat racine avec une durée de vie longue (30 ans par exemple) est intégré aux navigateurs. La clé privée associée à ce certificat est stockée hors-ligne et est utilisée, chaque année, pour signer un certificat intermédiaire avec une durée de vie plus courte (1 an). C’est ensuite ce certificat intermédiaire qui est utilisé au quotidien.

1. *Formalisez cette organisation (matériel côté CA, matériel côté site, matériel côté client).*
Côté CA : Pub~CL~/Priv~CL~, Pub~CC~/Priv~CC~, Pub~CC~.{h(Pub~CC~)}~PrivCL~
Côté site : (B, Pub~B~).{h((B, Pub~B~))}~PrivCC~.Pub~CC~.{h(Pub~CC~)}~PrivCL~
Côté client : Pub~CL~
2. *Quel est le chemin de vérification pour le client ?*
Le serveur envoie (B, Pub~B~).{h((B, Pub~B~))}~PrivCC~.Pub~CC~.{h(PubCC)}~PrivCL~, qui contient : l'association (B, Pub~B~), sa signature avec la clé Priv~CC~, la clé publique Pub~CC~ et la signature de cette clé publique avec la clé Priv~CL~
Le client vérifie cette chaîne en partant de Pub~CL~, qui permet de vérifier que Pub~CC~ est valide, et ensuite utilise Pub~CC~ pour valider (B, Pub~B~)
3. *Comment remédier dans le cas où un certificat intermédiaire est compromis ? Dans le cas où le certificat racine est compromis ?*
Intermédiaire : on pourrait le révoquer, si la révocation marchait ;).
Racine : c'est ancré dans la distribution logicielle du navigateur, il faut que l'éditeur du navigateur propose une mise à jour puis que l'utilisateur applique cette mise à jour (assez efficace sur ordinateur, beaucoup moins sur smartphones avec les anciens qui ne reçoivent plus de mise à jour, pire sur l'équipement spécifique industriel/médical/IoT)

## Conclusion

On a bien fait le TD.