> For the complete documentation index, see [llms.txt](https://sansong.gitbook.io/cyber/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sansong.gitbook.io/cyber/crypto/asymetrique.md).

# Asymétrique

## Chiffrement asymétrique

La clé de chiffrement est différente de celle de déchiffrement. → pas besoin de s'échanger la clé secrète

<figure><img src="https://1813806532-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZRRTPIEA4wb6exZozwS0%2Fuploads%2FGJus4B6BinGDrjNLV3o4%2Fchiffrement-asymetrique.svg?alt=media&amp;token=83b7b3d7-d729-4255-8439-d27936093dff" alt="" width="563"><figcaption><p>Chiffrement asymétrique</p></figcaption></figure>

La clé se décompose en 2 parties:

* clé publique (chiffrement)
* clé privée (déchiffrement)

Le destinataire dévoile sa clé publique, on l'utilise pour chiffrer un message lui étant destiné. Il le déchiffre avec sa clé privée.&#x20;

→ il y a donc un lien entre les clés&#x20;

→ en théorie la clé privée peut se déduire de la clé publique&#x20;

→ **toute la solidité du modèle repose donc sur la difficulté calculatoire**

{% hint style="success" %}
Alice et Bob possèdent chacun une clé publique et une clé privée, respectivement $$A\_{pub}, B\_{pub}$$ et $$A\_{p}, B\_{p}.$$ Chacun partage sa clé publique.

Pour envoyer un message à Bob:

1. Alice chiffre son message avec $$B\_{pub}$$
2. Bob le déchiffre avec $$B\_p$$
3. Le message chiffré est public mais il faut la clé privée $$B\_p$$ pour le déchiffrer
   {% endhint %}

Les 3 grandes familles d'algorithmes de chiffrement asymétrique sont:

* RSA (factorisation d'entiers)
* logarithme discret (exponentiation)
* courbes elliptiques

### RSA vs Log discret (LD) vs Courbes elliptiques (CE)

<table><thead><tr><th width="132" align="center">Sécurité</th><th align="center">Taille du n/p dans RSA/LD sur F_p</th><th align="center">Taille du p pour LD sur CE</th></tr></thead><tbody><tr><td align="center">2^80</td><td align="center">1024</td><td align="center">160</td></tr><tr><td align="center">2^128</td><td align="center">3072</td><td align="center">256</td></tr><tr><td align="center">2^256</td><td align="center">15360</td><td align="center">512</td></tr></tbody></table>

Avec les courbes elliptiques la taille de clé est inférieure pour une sécurité équivalente. Il n'existe pas de meilleur algorithme que les algorithmes génériques (brute force).

### Avantages et inconvénients du chiffrement asymétrique

1. Pas besoin de se passer le secret commun
2. Permet d'avoir moins de clés dans le système en cas de nombreux utilisateurs
3. MAIS est $$100$$ à $$1000$$ fois **plus lent que son équivalent symétrique**

→ utilisé pour chiffrer des messages de petite taille

{% hint style="success" %}
En pratique **chiffrement hybride utilisé:**

* chiffrer le message en symétrique avec une clé secrète
* chiffrer la clé secrète en asymétrique
  {% endhint %}

### Attaque du milieu (Man In The Middle)

**Comment s'assurer que la clé publique est bien celle de la personne avec qui on veut communiquer ?**

Le but de l'attaquant est de se faire passer pour un des $$2$$ interlocuteurs (voire les $$2$$)

TODO: schema

Ici Eve intercepte l'envoi de $$Bp$$ à Alice et envoie $$Ep$$ (sa clé privée) à la place.\
Alice chiffre son message avec $$Ep$$, Eve déchiffre et peut le modifier avant de chiffrer avec $$Bp$$ et d'envoyer le message potentiellement modifié à Bob.

Les clés publiques ne sont pas confidentielles mais doivent rester intègres, ce qui implique une gestion cryptographique par différents moyens. On ne peut donc pas éviter **l'infrastructure de gestion des clés (PKI: public key infrastructure)**. Notamment l'autorité de certification (tierce partie de confiance qui assure les clés publiques). Pour garantir l'authentification on utilise des certificats.

### Echange de clés de Diffie-Hellman

{% hint style="info" %}
Ce protocole doit son nom à ses auteurs: [Whitfield Diffie](https://fr.wikipedia.org/wiki/Whitfield_Diffie) et [Martin Hellman](https://fr.wikipedia.org/wiki/Martin_Hellman).
{% endhint %}

Le nom *échange de clés* est mal choisi car **aucun échange n'a lieu**. Il s'agit plutôt d'une **génération d'un secret commun**.

TODO: schema couleurs TODO: schema maths

{% hint style="danger" %}
Le canal doit être intègre ou une attaque du milieu existe.
{% endhint %}

TODO: schema

Eve possède ainsi une clé secrète avec Alice et une autre avec Bob. Alice et Bob croient avoir échangé une clé secrète alors qu'en réalité ils ont chacun échangé une clé secrète avec l'attaquant.

→ besoin d'intégrité

{% hint style="info" %}
**Pourquoi Diffie-Hellman alors qu'on a déjà RSA ?**&#x20;

Avant RSA était utilisé seul mais si la clé privée du serveur par exemple finie par être connue, un attaquant ayant enregistré l'intégralité des échanges peut tout déchiffrer d'un coup. Avec Diffie-Hellman on créé une clé à chaque session (en gros) et on chiffre avec un algorithme symétrique rapide (AES…). Difficile de faire ça avec RSA car plus de puissance de calcul nécessaire… RSA étant un algorithme de chiffrement et de signature, il est utilisé pour signer la clé publique afin de garantir l'intégrité.
{% endhint %}

#### Exemples d'applications de Diffie-Hellman

1. **Secure Shell (SSH):** protocole réseau utilisé pour transmettre des fichiers et se connecter à des machines distantes
2. **Transport Layer Security (TLS) / Secure Sockets Layer (SSL):** protocoles de chiffrement utilisés pour protéger les communications en ligne

### Certificats

Secure Socket Layer (SSL) et Transport Layer Security (TLS) garantissent une communication chiffrée sur (le S de HTTPS).

La sécurité du protocole SSL reposent sur la "chaîne de confiance" des certificats. Lorsqu'un expéditeur envoie un message, **le client vérifie le certificat SSL du serveur pour confirmer que l'autorité de certification de confiance a émis le certificat.**

Le certificat SSL combine la cryptographie symétrique et asymétrique pour établir une connexion sécurisée entre le client et le serveur. **Le serveur utilise son certificat SSL/TLS pour s'authentifier auprès du client** (pour garantir qu'il s'agit bien de lui), contenant la clé publique du serveur et d'autres informations d'identification. **Le client génère ensuite une clé symétrique pour chiffrer les données qui seront échangées avec le serveur**.

Au cours du SSL/TLS *handshake*, **le client et le serveur se mettent d'accord sur une suite de chiffrement pour les communications**. Cette suite comprend **l'algorithme de chiffrement, la méthode d'échange de clés et l'algorithme de code d'authentification des messages** (MAC).

Une fois le *handshake* terminée, le client et le serveur peuvent échanger des données chiffrées.
