Add wifi lesson
This commit is contained in:
parent
558d71a640
commit
d8343980aa
1 changed files with 124 additions and 0 deletions
124
content/secu_reseaux/8_wifi/index.md
Normal file
124
content/secu_reseaux/8_wifi/index.md
Normal file
|
@ -0,0 +1,124 @@
|
|||
---
|
||||
title: "Sécurité des réseaux : les réseaux Wifi"
|
||||
date: 2022-11-15
|
||||
tags: ["authetification", "WPA", "wifi"]
|
||||
categories: ["Sécurité des réseaux", "Cours"]
|
||||
matjax: true
|
||||
---
|
||||
|
||||
Contrairement à un réseau filaire, tout le monde (avec une carte réseau Wifi)
|
||||
peut observer le trafic réseau. Il faut donc chiffrer les communication c'est le
|
||||
rôle des différents protocoles: WEP, WPA, WPA2 etc.
|
||||
|
||||
La contrainte énergétique est importante et guide les chois techniques.
|
||||
|
||||
## WEP -- Wired Equivalent Privacy
|
||||
|
||||
(Non! Non! ce n'est pas une blague)
|
||||
|
||||
Les clients et la borne partagent une clé statique de 64 ou 128 bits. Le
|
||||
chiffrement est basé sur *RC4* et la détection d'erreur sur CRC. C'est un
|
||||
protocole **cassé depuis longtemps**
|
||||
|
||||
Au niveau de l'émetteur:
|
||||
|
||||
1. Calculer la somme de contrôle du paquet et les ajouter à ce dernier
|
||||
2. Calculer un nouvel *Initialisation Vector* et l'ajouter à la clé pour former
|
||||
une clé
|
||||
3. Utiliser l'algorithme RC4 pour former une clé de flux donc la longueur est
|
||||
égale à celle de la trame (données + CRC)
|
||||
4. obtenir la trame chiffrée : \\(trame \xor cle_flux \\)
|
||||
5. Ajouter l'IV dans l'entête de la trame chiffrée.
|
||||
|
||||
Le récepteur récupère l'IV de l'entête pour reconstituer la clé de flux puis
|
||||
réalise les opération de l'émetteur dans le sens inverse.
|
||||
|
||||
La seule variable ici est l'*IV* d'une taille de 24 bits seulement. Un attaquant
|
||||
peut alors récupérer des trames et tester des collisions pour faire baisser
|
||||
l'entropie (attaque passive).
|
||||
|
||||
## WPA
|
||||
|
||||
Le changement est simple : on passe d'un *IV* statique à un *IV* dynamique et
|
||||
un meilleur algorithme de somme de contrôle (pour l'intégrité). Ce protocole est
|
||||
dérivé de la norme 802.1x.
|
||||
|
||||
Deux modes existes :
|
||||
|
||||
* **personnel**: la même clé est utilisé pour tous les protagoniste;
|
||||
* **entreprise**: établissement d'une connexion TLS puis identification.
|
||||
|
||||
### Poignée de main
|
||||
|
||||
Dans le cadre d'une connexion par **phrase de passe**, celle-ci est transformée
|
||||
en PSK (*Pre-Shared Key*). Ensuite le système génère une clé temporelle: la
|
||||
*PTK* :
|
||||
|
||||
\\(PTK = PSK, @MAC_{client}, @MAC_{borne}, N_{client}, N_{borne}\\)
|
||||
|
||||
L'*IV* est remplacé par le TSC, un compteur sur 128 bits
|
||||
|
||||
\\( keystream = f(TSC, PTK)\\)
|
||||
|
||||
*PTK* est renégociée lorsque *TSC* est au bout ou presque.
|
||||
|
||||
Pour garantir l'intégrité des messages, *WPA* utilise MIC don l'implémentation
|
||||
(*MIChael) est dérivée de *HMAC-SHA1*. Le MIC est calculé sur le paquet
|
||||
**avant** fragmentation.
|
||||
|
||||
## WPA2
|
||||
|
||||
C'est le même protocole que WPA mais avec des algorithme de cryptographie à
|
||||
jour: `AES` et `SHA-256`.
|
||||
|
||||
## Les attaques sur WPA 1/2
|
||||
|
||||
Le rejeu est casi-impossible à cause de *TSC*. Cependant en 2014, `Chop-Chop`
|
||||
est adaptée à WPA.
|
||||
|
||||
Avec l'arrivée des bornes multi-canaux, les constructeurs ont implémentés un
|
||||
*TSC* par compteur. Il est donc possible de rejouer un paquet provenant d'un
|
||||
canal avec un gros TSC sur un canal avec un TSC plus petit. Il suffit de choisir
|
||||
un petit paquet pour éviter la fragmentation et observer ensuite ce qui se
|
||||
passe.
|
||||
|
||||
### KRACK!
|
||||
|
||||
Ici l'attaquant se position en MitM sur un canal de la borne. Il commence à
|
||||
rejouer les paquets tel quel entre la borne et le client. Lors de l'installation
|
||||
de la *PTK* puis son envoi, l'attaquant de transmet pas les paquets au client.
|
||||
|
||||
Le serveur va redemander les paquets au client qu'il va lui envoyer **en
|
||||
clair**. L'attaquant dispose alors d'une version chiffrée et en clair d'un même
|
||||
paquet. Il est possible **d'en déduire la keystream*.
|
||||
|
||||
### WPA3
|
||||
|
||||
C'est globalement la même base que *WPA2*' mis à part la poignée de main.
|
||||
|
||||
Dans WPA2 nous avons \\(PSK \to PMK \to PTK\\), la PMK est commune à tous les
|
||||
clients (la *PTK* est propre à chacun d'eux). Dans WPA3 nous voulons que la
|
||||
*PMK* soit **différente** pour chaque client et aussi **se débarrasser de la
|
||||
phrase de passe dans la poignée** de main. Un peu la manière de *Kerberos*.
|
||||
|
||||
### poignée de main
|
||||
|
||||
3 modes de fonctionnement:
|
||||
|
||||
1. ouvert (chiffrement opportuniste);
|
||||
2. personnel SAE (dragonfly)
|
||||
3. entreprise
|
||||
|
||||
Avant le dq'ebut de la poignée de main, il y a un échange de clé *Diffie
|
||||
-Hellman*. Puis vien ensuite la poigné de main du type *4 way hanhshake*
|
||||
|
||||
Pour générer \\(g_{client}\\) et \\(g_{borne}\\) on applique fonction pour
|
||||
dériver la phrase de passe. La poignée de main est **maintenant chiffrée**.
|
||||
|
||||
L'inconvénient est la puissance de calcul nécessaire pour mettre en place le
|
||||
canal sécurisé est importante, surtout pour du matériel emparqué. Un attaque
|
||||
possible serait de bonbarder la borne de demande de poignée de main pour la
|
||||
saturer: une attaque par déni de service.
|
||||
|
||||
WPA3 reste tout de même compatible avec WPA2, une attaque **par downgrade** est
|
||||
donc possible.
|
Loading…
Add table
Add a link
Reference in a new issue