cours/content/secu_reseaux/5_securite-echanges/index.md

10 KiB

title date tags categories mathjax
Sécurité des réseaux : sécurité des échanges 2022-10-04
TLS
IPSEC
Sécurité des réseaux
Cours
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 avecIKE (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).

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

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

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

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

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.