---
title: "Sécurité des réseaux : sécurité des échanges"
date: 2022-10-04
tags: ["TLS", "IPSEC"]
categories: ["Sécurité des réseaux", "Cours"]
mathjax: true
---

Dans cette partie nous aborderons *TLS* (*Transport Layer Security*), *IPSec*
(*IP Security*) et les *PKI* (*Public Key Infrastructure*)

## Propriété à assurer

Pour sécuriser un échange, il faut assurer 4 points:

 1. la confidentialité: seul mon interlocuteur peut lire le message;
 2. l'authenticité: le message est authentique;
 3. l'intégrité: le message vient bien de mon interlocuteur, il n'a pas été
   modifié par un tiers;
 4. la non répudiabilité: mon interlocuteur ne peut pas réfuter ses messages;

## IPSec

C'est un protocole ancien (~1994) créé pour répondre aux 4 propriétés vu
précédemment. Il se positionne dans la couche IP, il est donc totalement
transparent pour les couches supérieures.

IPSec est composé de plusieurs parties:

 * **ESP (*Encapsulating Security Payload*)**: chiffrement;
 * **AH** (*Authentication Header*): authentification de l'origine des paquets, 
      contrôle des accès, rejet des paquets rejoués;
 * **Négociation**: établissement des paramètres de la communication
   avec**IKE** (*Internet Key Exchange*).

### Les défi des attaques par rejeu

Ces types d'attaques permettent de mettre à mal des protocoles réputés fiables
comme *WPA2*. Quelle solution est implémentée dans IPSec?

Au niveau du récepteur, un identifiant de paquet et une fenêtre de réception
sont utilisés. Une **fenêtre** est une intervalle de temps bornée pendant
laquelle les identifiants sont acceptés.

Le déroulé:

 * Une fenêtre de taille `W` est créée sur le récepteur;
 * Le numéro d'ordre le plus élevé, noté `N`, est placé à l'extrémité droite de
    la fenêtre;
 * Pour tout paquet reçu avec un numéro d'ordre compris entre `N - W +1` et `N`,
    la position correspondante est marquée;
 * Lors de la réception d'un nouveau paquet;
   * Si la position et la *MAC* sont corrects, la position est marquée
   * Si la *MAC* est correct et que le numéro d'ordre est à droite de la
      fenêtre, alors cette dernière est avancée de sorte que `N` prenne la 
      valeur du numéro d'ordre de ce paquet;
   * Si la *MAC* est invalide ou que le numéro d'ordre est à gauche de la
     fenêtre, **il est détruit**;

### Authentication Header

L'entête d'authentification assure l'intégrité des données et authentifie
les paquets IP. Elle est basée sur MAC (*Message Authentication Code*)
([Wikipedia](https://fr.wikipedia.org/wiki/Code_d%27authentification_de_message)).

L'entête permet aussi la détection du rejeu (cf chapitre au dessus)

### Encapsulated Security Payload

Ce protocole assure la confidentialité des échange, l'authentification et
l'intégrité des messages. En opposition avec le protocole *AH*, *ESP* chiffre
les données et les encapsules et y ajoute su besoin du bourrage (*padding*) 
(voir schémas ci-dessous)

### Le mode transport

Deux hôtes se "parlent" via un tunnel sécurisé. Dans ce mode, le paquet
d'origine est inclus dans un autre. Le paquet d'origine est alors chiffré et /
ou authentifié.

![Encapsulation de la trame IP en mode transport](./images/ipsec_transport.svg)

Un champ AH est ajouté pour authentifier la trame. Cette authentification est 
assurée par une signature qui prend la forme:

\\[
hash(K || hash(K || M))
\\]

Ou `hash` est une fonction de hashage, `K` la clé et `M` le message.

En mode transport, **ESP** chiffre la charge utile du paquet d'origine, l'entête 
reste inchangée. *ESP* authentifie l'information utile et certaines parties de 
l'entête IP comme montré sur le schéma ci-dessous:

![Utilisation d'ESP en mode transport](./images/ipsec_transport_esp.svg)

Lors de l'utilisation du mode transport, il n'est pas possible de faire du *NAT*
sans compromettre l'intégrité du paquet. Il est tout de même possible de faire
du [NAT-Traversal](https://fr.wikipedia.org/wiki/NAT-T) qui en capsule les
paquets IPsec dans des paquets *UDP*

### Le mode tunnel

Deux réseaux se "parlent" via l'établissement d'un tunnel sécurisé.

![Encapsulation de la trame IP en mode tunnel](./images/ipsec_tunnel.svg)

Ce mode assure la protection du paquet IP dans sa totalité. 

En mode ESP, le message doit être **chiffré**.

![Utilisation d'ESP en mode transport](./images/ipsec_tunnel_esp.svg)

Le mode *ESP* supporte le *NAT*.

### IKE -- Gestion des clés

IKE sert à gérer et distribuer les clés, il est aussi chargé de négocier la
connexion. 4 clés sont nécessaire pour sécuriser le tunnel: une paire pour la
transmission et une autre pour le réception.

Deux type d'authentification sont possible :

 * *Pre-Shared Key* ou *PSK*, en somme un secret partagé
 * à l'aide de certificats, dans ce cas l'utilisation d'une autorité de
   certification assure la **non répudiation** des messages envoyés

IPsec propose deux mode de gestion des clés: manuelle -- chaque poste est
configuré manuellement -- ou automatique via *Internet Security Association and
Key Management* (ISAKPM).

**ISAKPM** fournit un cadre pour la création et la gestion des clés, pour
authentifier les communications et la gestion des *Security Associations*. Il
utilise *IKE* pour l'échange de clés.

### Diffie-Hellman

#### Principe de fonctionnement

Alice et Bob choisissent un nombre premier \\(q\\) et une racine primaire de 
\\(q\\) notée \\(a\\). Ils tirent chacun un nombre aléatoire, respectivement 
\\(X_{A}\\) et \\(X_{B}\\), ces nombres correspondent aux **clés privées** de
nos deux protagonistes.

 1. Alice transmet \\(Y_{A}\\) qui vaut \\(a^{X_{A}}mod(q) \\)
 2. Bob transmet \\(Y_{B}\\) qui vaut \\(a^{Y_{B}}mod(q) \\)
 3. Chacun des protagoniste calcule la clé de session :
    \\(K = (Y_{B})^{X_{A}}mod(q) = \(Y_{A})^{X_{B}}mod(q) = a^{X_{A}X_{B}}mod(q)\\)

#### Faiblesses

Cette algorithme permet d'assurer la *Perfect Forward Secrecy* : la
compromission de la clé n'entraine pas la compromission des échanges passés.
Mais DH est sensible aux **attaque par l'homme du milieu (MitM)**.

Il est alors nécessaire de signer les messages \\(Y_{A}\\) et \\(Y_{B}\\). Alice
et Bob ont alors besoin **d'échanger des informations avant leurs échanges**.

De plus la réception des premiers message est coûteuse en temps de calcul:
**risque de déni de service**.

### Oakley

Il intervient à plusieurs endroits pour sécuriser les échanges:

 * Utilisation des cookies pour éviter les attaques par déni de service;
 * Négociation d'un groupe de paramètres pour DH;
 * Authentification des échanges de clés DH;
 * Utilisation de **nonce** pour contrer les attaques par rejeu.

Un nonce est un nombre aléatoire  (ou pseudo aléatoire) à usage unique utilisé 
dans une communication afin de garantir qu'un ancien message ne puisse pas être
réutilisé.

### ISAKMP

C'est le plus populaire des IKE:

 * il négocie d'abords les associations de sécurité (*SA*)
 * Il utilise le protocole d'*Oackley*
 * Il nécessite deux phases : la première pour créer un canal sécurisé
   permettant à la phase deux d'échanger les véritables paramètre de sécurité

## SSL / TLS

Ici aussi il est question de respecter les 4 paramètres vu en introduction. Dans
TLS pour *Transport Layer Security*, il est toujours question de Client /
Serveur.

Avec la version 1.3 de *TLS*, il y a rupture dans la rétro-compatibilité afin de
se débarrasser des éléments problématiques.

### Poignée de main

#### Version simplifiée (RSA)

 1. Le client envoi un `hello` en clair. Ce message comprend:
    * la version du protocole qu'il souhaite utiliser
    * les suite de chiffrement prise en charge
    * un *client random*, courte chaine de donnée aléatoire
 2. Le serveur répond en clair :
    * son certificat x509
    * ses suites de chiffrement préférées
    * un *serveur random*, courte chaine de donnée aléatoire
 3. Le client créé un autre ensemble de données aléatoire : le *premaster
   secret*, la chiffre avec le certificat donné par le serveur.
 4. le serveur déchiffre le secret
 5. Les deux partie dispose maintenant du *client random*, *serveur random* et
    le *premaster secrets*. Ces trois éléments permettent de générer une clé de
    session.

#### Version avancée (DHE)

 1. le client envoi un `hello` avec les même éléments de la poignée de main RSA
 2. le serveur répond avec les même éléments, il y ajoute son paramètre
   *Diffie-Hellman*. Il chiffre le *client random*, le *server random* et les
   paramètres DH avec sa clé privée.
 3. le client déchiffre  et authentifie le message du serveur avec la clé 
   publique (certificat)
 4. en utilisant les paramètres DH du serveur et du client, les deux parties
   calculent la *premaster key*
 5. comme pour la poignée de main RSA, les deux parties créent les clé de
   session

### Les attaques sur TLS

#### CRIME

*Compression Ratio Info-leak Made Easy* porte sur la compression et touche les
protocoles *HTTP* et *SPDY*. Elle permet le vol du cookie d'authentification.

L'attaquant observe la taille du cyphertext envoyé par le navigateur pendant
qu'il force ce même navigateur à envoyer des requête spécialement forgée vers
des sites déterminés.

#### HEIST

*HTTP Encrypted Information Can Be Stolen Through TCP-Windows* est une attaque
qui n'utilise pas de MitM. Comme CRIME, l'attaque se joue dans le navigateur de
la victime et utilise pour partie la compression combinée à l'utilisation du
timing en side-channel (via *Javascript*).

#### FREAKS

*Factoring RSA Export Keys* est une attaque qui découle de faiblesses
délibérément introduites dans les implémentation des protocoles SSL/TLS. CEs
faiblesses sont dues aux législations des États-Unis d'Amériques sur
l'exportation des solution de chiffrement.

Ces faiblesses sont combinées à la possibilité de renégocier la suite de
protocole utilisée dans TLS permet donc l'attaquant à forcer la victime à
choisir les protocoles affaiblis.

#### Alpaca

TLS ne s'occupe pas de chiffrer les données annexes comme les adresses IP, les 
ports (source et destination) etc. Un attaquant peut alors rediriger le traffic
vers un serveur qu'il contrôle.