Cours Securite Wi-Fi 2011 PDF

La scurit
des rseaux IEEE 802.11 Wi-Fi
Pascal Urien
Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 1
Table des matires

I- Le contrle daccs dans PPP ............................................................................ 5
1 Point to Point Protocol (PPP - RFC 1661 Juillet 1994) .............................. 5
1.1 Le protocole de contrle rseau (NCP) ................................................... 6
1.2 LCP le protocole de contrle de liaison .................................................. 6
1.3 PPP Internet Protocol Control (IPCP) RFC 1332 ................................... 7
1.4 Exemple dune session PPP .................................................................... 7
2 Password Authentication Protocol - RFC 1334 (1992) .................................. 9
2.1 Les PDUs LCP ........................................................................................ 9
3 Challenge Access Protocol (CHAP) RFC 1334 -1994 ................................... 9
3.1 Format des paquets CHAP .................................................................... 10
4 MS-CHAP-V1 RFC 2433 (1998) ................................................................ 10
4.1 Format des paquets MS-CHAP-V1 ....................................................... 11
5 MS-CHAP-V2, RFC 2759 (2000)................................................................ 13
5.1 Mcanismes dauthentification NT ...................................................... 14
II- La scurit des rseaux sans fil 802.11 .......................................................... 16
1 Introduction .................................................................................................. 16
2 IEEE 802.11 ................................................................................................. 18
3 IEEE 802.1X ................................................................................................ 20
4 EAP .............................................................................................................. 23
4.1 EAP-MSCHAPv2 ................................................................................. 25
4.2 EAP-SIM............................................................................................... 26
4.3 EAP-TLS............................................................................................... 26
5 Vers la carte puce EAP.............................................................................. 27
6 RADIUS....................................................................................................... 29
7 IEEE 802.11i ................................................................................................ 30
7.1 Protocoles de scurit radio .................................................................. 31
7.2 Elments dinformation ........................................................................ 32
7.3 Distribution des cls .............................................................................. 32
8 Une approche verticale................................................................................. 33
9 Conclusion ................................................................................................... 34
10 Bibliographie.............................................................................................. 35
III- WEP et les Architectures Alternatives .......................................................... 36
1. Introduction ................................................................................................. 36
2. Exemples darchitectures alternatives ......................................................... 39
2.1 WFG (Wireless Firewall Gateway) ....................................................... 39
2.2 SWITCHmobile .................................................................................... 39
IV- EAP .............................................................................................................. 40
1 Introduction .................................................................................................. 40
2 EAPoL ......................................................................................................... 40
2.1 Format dune trame EAPoL .................................................................. 40
2.2 Exemple dun paquet EAPOL-Start ...................................................... 41
Scurit Wi-Fi Pascal Urien - page 2
2.3 Exemple dun descripteur de cl. .......................................................... 42

3 Le protocole EAP (RFC 2284, RFC 3748) .................................................. 43
3.1 Le modle EAP ..................................................................................... 43
3.2 Format dun message EAP .................................................................... 44
3.3 Requtes et rponses ............................................................................. 44
4 Mthodes dauthentification diverses. ......................................................... 45
4.1 LEAP, Lightweight Extensible Authentication Protocol ...................... 46
4.2 EAP-FAST ............................................................................................ 47
4.3 EAP-SIM............................................................................................... 48
4.4 EAP-TLS............................................................................................... 50
5 EAP dans les systmes XP Windows ........................................................... 51
V- Le protocole RADIUS ................................................................................... 54
1 Introduction .................................................................................................. 54
1.1 RFC utiles ............................................................................................. 55
2 Format des paquets RADIUS ....................................................................... 56
2.1 Code ...................................................................................................... 56
2.2 Identifier ................................................................................................ 56
2.3 Length ................................................................................................... 56
2.4 Authenticator......................................................................................... 56
2.5 Attributes............................................................................................... 57
3 Scurit du protocole RADIUS.................................................................... 57
4 Exemple dune requte................................................................................. 58
4.1 Access-Request ..................................................................................... 58
4.2 Access-Response ................................................................................... 59
5 Exemple dune opration de facturation. ..................................................... 59
5.1 Access-Request ..................................................................................... 59
5.2 Access-Response ................................................................................... 59
6. Le transport du protocole EAP. ................................................................... 60
6.1 Lattribut vendor-specific...................................................................... 60
6.2 Quelques attributs dcrivant le NAS ..................................................... 60
6.3 Scnario dune session dauthentification EAP. ................................... 61
7 Exemple de code C socket. .......................................................................... 62
7.1 Client ..................................................................................................... 62
7.2 Server .................................................................................................... 62
VI- IEEE 802.1X ................................................................................................ 64
1. Introduction ................................................................................................. 64
2 Principe de fonctionnement ......................................................................... 65
3 Mcanismes de gestion des ports. ................................................................ 66
4 Etat machine du Supplicant PAE ................................................................. 67
4.1 Etats ...................................................................................................... 67
4.2 Constantes. ............................................................................................ 67
4.3 Variables ............................................................................................... 67
4.4 Procdures. ............................................................................................ 68
5 Etat machine de lAuthenticator PAE .......................................................... 69
5.1 Etats ...................................................................................................... 69
5.2 Variables ............................................................................................... 69

5.3 Constantes ............................................................................................. 69
5.4 Procdures. ............................................................................................ 69
VII- La norme IEEE 802.11i............................................................................... 71
1 Le modle IEEE 802.11i .............................................................................. 71
2 Ngociation de la police de scurit ............................................................. 72
2.1 Format des RSN Information Element (IE) .......................................... 73
2.2 Exemples dlments dinformation. .................................................... 75
3 Exchange des cls via EAP .......................................................................... 77
4-Way Handshake, Pairwise Transient Key .................................................... 77
4.1 La fonction PRF. ................................................................................... 78
5 Echange de la cl GTK (Groupe Transient Key) ......................................... 79
6 La hirarchie des cls ................................................................................... 80
6.1 Pairwise Transient Key ......................................................................... 80
6.2 Les messages EAPoL-Keys .................................................................. 80
6.3 Notation des messages EAPoL-Key .................................................... 83
6.3 Illustration dune procdure de four way handshake ............................ 83
6.4 Exemple dinstallation de cl GTK ....................................................... 84
7 Un aperu du protocole TKIP ...................................................................... 85
7.1 La trame TKIP ...................................................................................... 85
7.2 Le chiffrement TKIP ............................................................................. 85
8 Un aperu du protocole CCMP .................................................................... 86
8.1 La trame CCMP .................................................................................... 86
8.2 Le chiffrement CCMP ........................................................................... 87
VIII- WPA - Wi-Fi Protected Access ................................................................. 88
1. Introduction ................................................................................................. 88
2 Comparaison WPA RSN IE et IEEE 802.11i RSN IE ................................. 88
2.1 802.11i, RSN IE ................................................................................... 88
2.2 WPA, RSN IE ...................................................................................... 88
IX- Une trace CHAP avec PPP ........................................................................... 89
X- Une trace EAPoL ........................................................................................... 91
XI- Une trace RADIUS ....................................................................................... 95
I- Le contrle daccs
dans PPP
1 Point to Point Protocol (PPP - RFC 1661 Juillet 1994)
La trame PPP utilise en fait le format HDLC (ISO 3309). La structure de
la trame est la suivante :
Flag
7E
Addr
FF
Control
03
Protocol
2 octets
information
1500 octets max
CRC
2 octets
Flag
7E
Un champ Protocol (2 octets) identifie le type de PDU PPP inclus dans la

trame HDLC.
- 0x0021 : IP
- 0xC021 : Link Control Protocol (LCP)
- 0x8021 : Network Control Protocol (NCP)
- 0xC023 : Password Authentication Protocol (PAP)
- 0xC025 : Link Quality Report (LQR)
- 0xC223 : Challenge Handshake Authentication Protocol (CHAP)
+------+
+-----------+
+--------------+
|
| UP
|
| OPENED
|
| SUCCESS/NONE
| Dead |------->| Establish |---------->| Authenticate |--+
|
|
|
LCP
|
| Auth.Protocol| |
+------+
+-----------+
+--------------+ |
^
|
|
|
|
FAIL |
FAIL |
|
+<--------------+
+----------+
|
|
|
|
|
+-----------+
|
+---------+ |
|
DOWN |
|
|
CLOSING |
| |
+------------| Terminate |<---+<----------| Network |<-+
|
|
|
NCP
|
+-----------+
+---------+
1.1 Le protocole de contrle rseau (NCP)

Ce protocole permet de configurer des types de rseaux diffrents par
exemple IP ou DECnet.
1.2 LCP le protocole de contrle de liaison
Ce protocole permet de ngocier les options mises en oeuvre par PPP (la
taille des MTU par exemple). Il existe 11 types de paquets LCP identifis par
un code (8 bits). Les options sont encodes sous la forme Type (1 octet)
longueur (2 octets) valeur.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Data ...
+-+-+-+-+
Les diffrents PDUs LCP (identifies par le champ code) sont les suivantes
(1) Requte de configuration
(2) Accus (ACK) de configuration
(3) Non accus de configuration (NAK)
(4) Requte de terminaison
(6) Accus de terminaison
(7) Rejet de code
(8) Rejet de protocole
(9) Requte dcho
(10) Rponse dcho
(11) Requte dlimination
(12) Identification
(13) Temps Restant
1.2.1 Options de configurations de LCP
0
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Length
|
Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(1) MRU Maximum Receive Unit
(3) Protocole dauthentification

(4) Protocole de qualit - mesure de la qualit de la ligne utilise.
(5) Nombre magique - dtection de boucles (client et serveur sur le mme
systme hte).
(7) Compression du champ protocole (de 2 octets 1 - PFC )
(8) Compression des champs adresse et contrle de la trame HDLC (ACFC).
1.3 PPP Internet Protocol Control (IPCP) RFC 1332
Le paquet IP est encapsul dans une trame PPP, le numro du protocole
est 0x8021. IPCP utilise seulement les 7 premiers types de PDUs de LCP.
La compression de Van Jacobson peut tre utilise (dans ce cas le champ
protocole 0x002D sera utilis dans les trames PPP).
Une adresse IP peut tre attribue par le serveur au client.
1.4 Exemple dune session PPP
PPP[C021] state = starting
PPP[C023] state = starting
PPP[8021] state = starting
PPP[C021] SND
CONFREQ ID=01 LEN=24 MRU(0100) ACCM(00000000) MAGIC(0005E782)
PFC ACFC
SND[C021] 0000:01 01 00 18 01 04 01 00 02 06 00 00 00 00 05 06 00 05 E7 82
SND[C021] 0014:07 02 08 02
PPP[C021] state = reqsent
PPP[C021] RCV
CONFREQ ID=00 LEN=24 MRU(05DC) ACCM(00000000) MAGIC(28B03580)
PFC ACFC
RCV[C021] 0000:01 00 00 18 01 04 05 DC 02 06 00 00 00 00 05 06 28 B0 35 80
RCV[C021] 0014:07 02 08 02
PPP[C021] SND
CONFACK ID=00 LEN=24 MRU(05DC) ACCM(00000000) MAGIC(28B03580)
PFC ACFC
SND[C021] 0000:02 00 00 18 01 04 05 DC 02 06 00 00 00 00 05 06 28 B0 35 80
SND[C021] 0014:07 02 08 02
PPP[C021] state = acksent

PPP[C021] RCV
CONFACK ID=01 LEN=24 MRU(0100) ACCM(00000000) MAGIC(0005E782)
PFC ACFC
RCV[C021] 0000:02 01 00 18 01 04 01 00 02 06 00 00 00 00 05 06 00 05 E7 82
RCV[C021] 0014:07 02 08 02
PPP[C021] state = opened
PPP[8021]
SND
CONFREQ
ID=01
LEN=16
IPCP(002D0F01)
IPADDR(81B63301)
SND[8021] 0000:01 01 00 10 02 06 00 2D 0F 01 03 06 81 B6 33 01
PPP[8021] state = reqsent
PPP[8021] RCV CONFREQ ID=01 LEN=10 IPCP(002D0F01)
RCV[8021] 0000:01 01 00 0A 02 06 00 2D 0F 01
PPP[8021] SND CONFACK ID=01 LEN=10 IPCP(002D0F01)
SND[8021] 0000:02 01 00 0A 02 06 00 2D 0F 01
PPP[8021] state = acksent
RCV[8021] 0000:03 01 00 0A 03 06 C2 02 91 48
PPP[8021] RCV CONFNAK ID=01 LEN=10 IPADDR(C2029148)
My IP address = 194.2.145.72
PPP[8021]
SND
CONFREQ
ID=02
LEN=16
IPCP(002D0F01)
IPADDR(C2029148)
SND[8021] 0000:01 02 00 10 02 06 00 2D 0F 01 03 06 C2 02 91 48
RCV[8021] 0000:02 02 00 10 02 06 00 2D 0F 01 03 06 C2 02 91 48
PPP[8021]
RCV
CONFACK
ID=02
LEN=16
IPCP(002D0F01)
IPADDR(C2029148)
PPP[8021] state = opened
(ICMP.request == ping(Data = "0123456789")
SND[0021] 0000:45 00 00 28 00 02 00 00 3C 01 74 E9 C2 02 91 48 81 B6 34 E9
SND[0021] 0014:08 00 31 35 01 00 C0 C0 30 31 32 33 34 35 36 37 38 39 00 00
(ICMP.response)
RCV[0021] 0000:45 00 00 28 3F 87 00 00 EB 01 86 63 81 B6 34 E9 C2 02 91 48
RCV[0021] 0014:00 00 39 35 01 00 C0 C0 30 31 32 33 34 35 36 37 38 39 00 00
2 Password Authentication Protocol - RFC 1334 (1992)

La demande du protocole dauthentification est indique par la prsence
de loption 3 du protocole LCP.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3
| Length=4
| Authentication-Protocol C023 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1 Les PDUs LCP

0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Data ...
+-+-+-+-+
Code, identifie la nature du paquet PAP

1 - Authenticate-Request
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-ID Length| Peer-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+
| Passwd-Length | Password ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
2- Authenticate-Ack, 3- Authenticate-Nak
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg-Length
| Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
- Identifier, ce champ est le numro dune requte et de la rponse associe

- Length, est la longueur totale du paquet PAP
3 Challenge Access Protocol (CHAP) RFC 1334 -1994
de loption 3 du protocole LCP.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type=3
|
Length=5
| Authentication-Protocol= c223 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Algorithm=5 MD5|
+-+-+-+-+-+-+-+-+
3.1 Format des paquets CHAP

Code :
1- Challenge, 2- Response
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3- Success, 4- Failure
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Identifier, ce champ est le numro dune requte et de la rponse associe

Length, la longueur totale du paquet
4 MS-CHAP-V1 RFC 2433 (1998)
MS-CHAP-V1 est compatible avec la RFC 1994.
de loption 3 du protocole LCP, avec pour valeur du champ Algorithm 0x80.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type=3
|
Length=5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Algorithm=0x80 |
+-+-+-+-+-+-+-+-+
4.1 Format des paquets MS-CHAP-V1

0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Data ...
+-+-+-+-+
Code
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La taille dun challenge est de 8 octets.

La taille de la rponse est de 25 octets, 24 octets pour le format LAN
manager, 24 octets pour le format Windows NT, et 1 octet (Use Windows NT
compatible challenge response flag) indiquant la disponibilit du format
Windows NT.
Le champ name indique lidentifiant du compte utilisateur, c'est--dire
nom-de-domaine + "\" + nom -utilisateur.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

Length, la longueur totale du paquet PAP
Message, = "E=Error-Code R=retry allowed(1/0) C=new-challengevalue(16 hexadecimal value) V=decimal-version-code"
5- Change Password Packet (version 1)
Code (=5), Identifier, Length (=72)
16 octets: Encrypted LAN Manager Old password Hash
16 octets: Encrypted LAN Manager New Password Hash
16 octets: Encrypted Windows NT Old Password Hash
16 octets: Encrypted Windows NT New Password Hash
2 octets: Password Length
2 octets: Flags
6- Change Password Packet (version 2)
Code (=6), Identifier, Length (=)
516 octets : Password Encrypted with Old NT Hash
16 octets : Old NT Hash Encrypted with New NT Hash
516 octets : Password Encrypted with Old LM Hash
16 octets : Old LM Hash Encrypted With New NT Hash
24 octets : LAN Manager compatible challenge response
24 octets : Windows NT compatible challenge response
2-octet : Flags1
1 Bit 0, The "use Windows NT compatible challenge response" flag as described

in the Response packet.
Bit 1, Set (1) indicates that the "Password Encrypted with Old LM Hash" and
"Old LM Hash Encrypted With New NT Hash" fields are valid and should be used.
Clear (0) indicates these fields are not valid. This bit SHOULD always be clear (0).
5 MS-CHAP-V2, RFC 2759 (2000)

MS-CHAP-V2 est compatible avec MS-CHAP-V1 la RFC 2433.
de loption 3 du protocole LCP, avec pour valeur du champ Algorithm 0x81.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type=3
|
Length=5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Algorithm=0x81 |
+-+-+-+-+-+-+-+-+
5.1 Format des paquets MS-CHAP-V2

0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Data ...
+-+-+-+-+
Code
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La taille dun AuthenticatorChallenge est de 16 octets.

La taille de la rponse est de 49 octets, 16 octets (Peer-Challenge, un
nombre alatoire de 16 octets) ,8 octets (rservs et cods zro), 24 octets
pour le format de rponse NT (NT-Response), et 1 octet (rserv et cod
zro).
Le champ name indique lidentifiant du compte utilisateur, c'est--dire
nom-de-domaine + "\" + nom-utilsateur.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

Length, la longueur totale du paquet PAP
En cas de succs Message est un champ de 42 octets, dont le format est le
suivant,
S=<auth_string> M=<message>, auth_string est une chane de 20
caractres ASCII, message est un texte affichable et comprhensible pour un
humain
Message derreur = "E=Error-Code R=retry allowed(1/0) C=newchallenge-value(32 hexadecimal value) V=decimal-version-code"
5- Change Password Packet
Code (=7), Identifier, Length (=586)
516 octets : Encrypted-Password
16 octets : Encrypted-Hash
16 octets : Peer-Challenge
8 octets : Reserved
24 octets : NT-Response
2-octet : Flags (rserv et cod zro)
5.1 Mcanismes dauthentification NT
Le mot de passe est une chane Unicode de 256 caractres au plus.
Le NT-Response est gnr de la manire suivante. Une procdure
(ChallengeHash) base sur la fonction SHA-1, produit, partir du nombre
alatoire AuthenticatorChallenge, dun nombre alatoire PeerChallenge, et
du UserName, un nombre (challenge) de 8 octets.
Le Password est associ un hash MD4 de 16 octets (NTPasswordHash),

tendu 21 octets, et interprt comme une srie trois cls DES de 7 octets.
Le champ challenge (8 octets) est chiffr par les trois cls DES
(DES1(challenge), DES2(challenge), DES3(challenge)). Ces 24 octets
constituent le NT-Response.
Le PasswordHash (128 bits) est utilis comme cl RC4 de 128 bits pour le
chiffrement dun nouveau mot de passe.
Les deux premires cls DES dduite dun PassWordHash sont utilises
pour le chiffrement du NtPasswordHash associ au nouveau mot de passe.
II- La scurit des

rseaux sans fil 802.11
1 Introduction
Le succs du rseau Internet, vritable moteur de la nouvelle conomie
de la dernire dcennie, a impos le protocole IP comme un standard de
facto pour lchange des donnes numriques. Surfant sur cette vague les
entreprises ont adopte cette technologie pour le stockage et la diffusion de
leurs informations stratgiques ; intranet, courrier lectronique, bases de
donnes trois tiers, annuaires LDAP sont des services aujourdhui
indispensables la comptitivit et la survie de toute activit conomique.
Si la prdominance des rseaux IP est actuellement incontestable, il
convient galement de remarquer les technologies des rseaux locaux
tendent galement vers un standard de fait, le rseau Ethernet. Cette
technologie, initialement base sur le partage dun guide donde (un cble en
fait) a petit petit migr vers une infrastructure base sur des commutateurs
de trames (les switchs).
A la base les rseaux sans fil 802.11 ne sont que lextension naturelle des
rseaux Ethernet cbls. La croissance exponentielle de ce march sexplique
par un rel besoin des utilisateurs daccder au rseau de manire quasi
transparente, sans lobligation de connecter leur ordinateur personnel une
prise. Le rseau sans fil remplace le cble par un lien radio; cependant en
raison des lois de propagation des ondes lectromagntiques cette prise
virtuelle est utilisable dans un rayon de lordre de 100m, c'est--dire dans
certain cas lextrieur des murs de lentreprise. On introduit donc de

nouveaux risques dintrusion ou de fuite dinformation, parfois qualifis
[Arbaugh et al.2001] dattaque par le parking (parking lot attack).
Lapparition de lIP sans fil dans des architectures cbles prexistantes
implique donc la mise en place de nouvelles mesures de scurit. Jusqu
prsent les entreprises ont dploys leurs rseaux locaux sans protection
particulire des points daccs. Typiquement le rseau est organis autour
dun arbre de commutateur de paquets (HUB), auquel sont relies des
stations de travail, laide de prises marquant les points daccs au rseau
(souvent dnommes port daccs). Lentre de ltablissement tant contrl
et rserv au personnel autoris, les ports daccs ne sont pas usuellement
scuriss, en particulier pour permettre une libre connexion des ordinateurs
portables. La mobilit des usagers sappuie sur le protocole DHCP allouant
dynamiquemnet une adresse, compatible avec lorganisation logique et
gographique de lintranet. Celui ci ne conduisant pas en rgle gnrale une
procdure dauthentification avant lallocation des paramtres de
configuration2, il est trs facile daccder lintranet dune entreprise depuis
un port daccs.
En consquence le contrle des accs, quasi inexistant dans le cas des
rseaux cbls, devient un pr requis pour le dploiement des rseaux
802.11. De mme la signature des trames est galement indispensable, en son
absence, un pirate peut facilement usurper ladresse MAC dun utilisateur
authentifi (MAC spoofing) et accder aux ressources numriques
disponibles. Le chiffrement des donnes transitant sur le lien radio est
galement souhaitable afin de garantir la confidentialit des changes ;
cependant de nombreuses mthodes (IPSEC, SSL, SSH ) sont dj en
mesure dassurer ce service.
En rsum les services scuriss indispensables aux extensions IP sans fil
sont les suivants
- Identification et authentification des utilisateurs du rseau
- Signature des trames changes (intgrit, authentification).
- Chiffrement des donnes (confidentialit)
2 RFC 2131, Chapter 7 - Security Considerations, Therefore, DHCP in its

current form is quite insecure.
2 IEEE 802.11
Un rseau 802.11 (voir figure 1) est un ensemble de cellules de base (BSS,
Basic Set Service), chacune dentre elles comportant un point daccs (Access
Point, AP) matrialis par un dispositif dmission rception analogue aux
stations de base du GSM. Lensemble de ces cellules (cest dire les APs) est
reli par une infrastructure de communication fixe (Distribution System DS),
qui incorpore en particulier un portail (Portal) assurant linterface avec un
rseau local (Ethernet) classique.
Distribution
System
Service Set Identifier

SSID
WLAN
802.11 a/b/g
Access
Point
Basic
Set
Service
AP
Wireless
Plug
802.11
STAtion
PORTAL
Parking
Lot attack
RJ45
Plug
Mail Server
Internet
Firewall
DHCP
Server
Radius
Server
Figure 1. Une architecture typique 802.11
La norme 802.11 [IEEE Std 802.11, 1999] dfini un protocole de scurit

radio, le WEP3. Son principe consiste chiffrer les trames (voir figure 2)
laide de lalgorithme RC4 et dune cl, obtenue par la concatnation dun
secret partag (de 40 ou 104 bits) et dun index transport en clair dans
chaque paquet (un champ de 24 bits, not IV).
Wireless Equivalent Privacy

En Tte MAC
30 octets
IV
3 octets
IV
3 octets
KEY ID
1 octet
1
2
3
Secret Partag
4
40,104 bits
Corps de trame chiffr
MAC Service Data Unit

02312 octets
CRC
4 octets
OU Exclusif
Cl 64/128 bits
RC4
PRNG
KEYSTREAM
Suite pseudo alatoire doctets
Figure 2. Le protocole WEP.
RC4 ralise le chiffrement des donnes en mode flux octets (stream cipher),
partir dune cl de longueur comprise entre 8 et 2048 bits il gnre ( laide
dun pseudo random generator PRNG) une suite doctets pseudo alatoire
nomme KeyStream. Cette srie doctets (Ksi) est utilise pour chiffrer un
message en clair (Mi) laide dun classique protocole de Vernam, ralisant
un ou exclusif (xor) entre Ksi et Mi (Ci = Ksi xor Mi).
Le WEP prsente de nombreuses failles de scurit [Borisov et al. 2001],
en voici un bref rsum,
- Le nombre de KeyStream est limit 16 millions (224). Un pirate peut
facilement gnrer des trames, enregistrer leur forme chiffre puis dduire et
stocker les KeyStream identifis par leur index IV.
- Lintgrit des trames est assure par le chiffrement du CRC. Cette fonction
tant linaire par rapport lopration ou exclusif4 il est possible de modifier
un bit dans une trame chiffre tout en recalculant une valeur correcte du
CRC, cest la technique dattaque dite bit flipping.
- Lattaque dmontre par Fluhrer [Fluhrer et al.,2001] permet de recouvrer
un secret partag de 104 bits aprs lmission dapproximativement quatre
millions de trames chiffres. Elle utilise des valeurs IV dites rsolvantes, de la
forme (3+B,255,N) avec B un octet du secret partag et N une valeur
quelconque comprise entre 0 et 255. Environ 60 valeurs rsolvantes suffisent
retrouver un octet du secret partag. Un rapide calcul montre que lon
obtient une valeur rsolvante toutes les 216 trames, soit 60 occurrences aprs
environ 4 millions (222) de paquets.
- De manire optionnelle lauthentification est ralise par une mthode de
dfi (nomme Shared Authentication), le point daccs dlivre un nombre
4 Soit T1 et T2 deux trames de mme longueur, CRC(T1 exor T2) = CRC(T1)
exor CRC(T2).
alatoire, la station chiffre cette valeur. Cette mthode est inefficace car rejouable, lattaquant enregistre le couple (ala, ala chiffr) do il dduit la
valeur du KeyStream associ un index IV. Il peut utiliser ces paramtres
pour chiffrer correctement un nouveau dfi.
En raison des problmes voqus prcdemment, il est fortement
conseill de changer la cl WEP frquemment, par exemple tous les 10,000
trames. Cependant cette technique ne garantit pas lintgrit de
linformation et les attaques bit flipping restent possibles.
Une particularit du protocole 802.11 est que lauthentification est
obligatoire avant toute association avec un point daccs. Une station sans fil
se trouve en consquence dans lun des trois tats suivants,
- Non-Authentifi et Non-Associ
- Authentifi et Non-Associ
- Authentifi et Associ.
Lorsque la station ne souhaite pas utiliser une mthode (Shared
Authentication) base sur WEP, elle dispose dune procdure volontaire sans
aucun lment de scurit, baptise Open Authentication.
Une difficult de dploiement dune architecture base sur WEP est la
ncessit de partager un mme secret entre station et point daccs. Cette
contrainte freine considrablement le passage lchelle; elle souligne
limportance de la disponibilit dune infrastructure de distribution des cls
telle que par exemple dfinie par la norme 802.1X [IEEE Std 802.1X, 2001] .
3 IEEE 802.1X
Supplicant
System
Supplicant
Entity
Authenticator System
Network
Resources
EAP over
RADIUS
Authenticator
Internet
Unauthorized
Port
LAN WLAN (802.11)

EAP over LAN (EAPoL)
Figure 3. Larchitecture 802.1X
Authentication
System
Authentication
Server
Le protocole IEEE 802.1X (ou Port Based Network Access Control) tait
initialement conu pour la gestion scurise des accs des rseaux (cbls)
base de commutateurs de paquets (switchs). Lide centrale est de bloquer le
flux de donnes dun utilisateur non authentifi. Ce modle sappuie sur
trois entits fonctionnelles (voir figure 3),
- Le Supplicant, un terminal informatique dsirant utiliser les ressources
offertes par un rseau de communication.
- LAuthenticator, le systme qui contrle un port daccs au rseau. Le flux
de donnes du supplicant est divis en deux classes, la premire comprend
les trames utilises par le protocole dauthentification EAP 5, la deuxime
regroupe les autres paquets, qui sont bloqus lorsque le port se trouve dans
ltat non autoris. En cas de succs du processus dauthentification, le port
passe ltat authentifi et offre un libre passage toutes les trames.
- Le serveur dauthentification (RADIUS6), il ralise la procdure
dauthentification avec le supplicant. Durant cette phase lAuthenticator
ninterprte pas le dialogue entre ces deux entits, il agit comme un simple
relais passif.
Le protocole EAP est la cl de vote de cette approche. Il est tour tour
encapsul dans des trames MAC 802 (EAPoL7) ou par le protocole RADIUS
qui est routable (puisque transport par IP et UDP).
Schmatiquement linsertion dun terminal sans
environnement 802.1X se droule de la manire suivante,
fil
dans
un
- Dans un premier temps la station sauthentifie puis sassocie un point

daccs, identifi par son SSID (une chane de 32 caractres au plus).
- La station met alors priodiquement (toutes les 30 secondes) une trame
EAPoL-Start.
- Le point daccs transmet un message EAP-Request.Identity au Supplicant
qui produit en retour une rponse (EAP-Response.Identity) comportant
lidentit (EAP-ID) du terminal sans fil.
- A partir de ce paramtre le point daccs dduit ladresse (IP) du serveur
dauthentification et transmet ce dernier le message EAPResponse.Identity encapsul dans une requte RADIUS.
- Ds lors des messages EAP (requtes et rponses) sont changs entre
serveur RADIUS et Supplicant, le point daccs ne jouant quun rle passif de
relais.
5
6
7
EAP Extensible Authentication Protocol, RFC 2284, March 1998

RADIUS, Remote Authentication Dial In User Service, RFC 2865, June 2000
EAPoL - EAP Over LAN
- Le serveur RADIUS indique le succs ou lchec de cette procdure grce

un message EAP-Success ou EAP-Failure. En fonction de cette information le
port transite ltat autoris ou non autoris.
A la fin dun scnario dauthentification russi Supplicant et serveur
dauthentification calculent une cl baptise Unicast Key. Ce paramtre est
en fait un secret partag entre les deux entits. Dans lenvironnement
Microsoft cette valeur reprsente un couple de cls 8 (2 fois 32 octets) MSMPPE-Send-Key et MS-MPPE-Recv-Key. Une cl dite Global Key est
transporte (entre point daccs et Supplicant) de manire scurise dans une
trame EAPoL-Key, chiffre et signe laide de la cl Unicast. Grce au
protocole RADIUS le serveur dauthentification transmet la cl Unicast au
point daccs. Ce dernier choisit alors une cl globale (la cl WEP) et la
dlivre au Supplicant.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Version=1
| Packet Type=3 |Packet Body Length=44+KeyLength|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1(RC4) |
Key Length ( WEP=4 ou 13 ) |Replay Counter..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Replay Counter...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Replay Counter
|
Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key IV...
|F| Key Index
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key.Value..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Format dun descripteur EAPoL RC4.

8 Ces attributs sont dfinis dans la RFC 2548, Microsoft Vendor-specific
RADIUS Attributes, March 1999
La figure 4 prsente le format dun descripteur EAPoL-Key9. Le champ

ReplayCounter (8 octets) sinterprte comme un horodatage au format NTP 10;
le paramtre IV est un nombre alatoire cryptographique de 16 octets. La cl
distribue (KeyValue) est chiffre au moyen de lalgorithme RC4 et dune cl
de 48 octets (16+32) obtenue par la concatnation des attributs IV et MSMPPE-Recv-Key. Lensemble du descripteur est sign (KeySignature) au
moyen dun HMAC-MD511 (16 octets) dont la cl est MS-MPPE-Send-Key. Le
drapeau (F) indique si la cl transporte est globale (F=1) ou unicast.
4 EAP
Le problme de la gestion de la mobilit des utilisateurs est devenu
critique ds lors que les internautes ont massivement utilis des modems et
le protocole PPP pour accder aux ressources offertes par leur ISP (Internet
Service Provider). Les systmes dexploitation ont donc intgrs des
fonctionnalits renforant la scurit des nomades, telles que :
- Lauthentification des utilisateurs par des mthodes de dfi par exemple
CHAP12, MSCHAP13, MSCHAPv214.
- Le chiffrement des trames PPP, par exemple par laide de lalgorithme
MPPE15.
- Des mthodes de calcul16 des cls de chiffrement (MS-MPPE-Recv-Key et
MS-MPPE-Send-Key)
- La distribution17 de telles cls par le protocole RADIUS.
Le besoin de comptabilit avec des infrastructures dauthentification
diversifies et la ncessit de disposer de secrets partags dans ces
environnements multiples ont naturellement conduit la gense du
Daprs IEEE 802.1X Remote Authentication Dial In User Service (RADIUS)

Usage Guidelines RFC 3580, September 2003
10 Network Time Protocol, RFC 1305, March 1992
11 Keyed-Hashing for Message Authentication, RFC 2104, February 1997
12 PPP Challenge Handshake Authentication Protocol (CHAP), RFC 1994,
August 1996.
13 Microsoft PPP CHAP Extensions, RFC 2433, October 1998.
14 Microsoft PPP CHAP Extensions, Version 2, RFC 2759, January 2000
15 Microsoft Point-To-Point Encryption (MPPE) Protocol, RFC 3078, March
2001
16 Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE),
RFC 3079, March 2001
17 Microsoft Vendor-specific RADIUS Attributes, RFC 2548, March 1999.
protocole EAP, capable de transporter des mthodes dauthentification

indpendamment de leurs particularits.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
| Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5. Format dun message EAP
Le protocole EAP fournit un cadre peu complexe pour le transport de

protocoles dauthentification; un message (voir figure 5) comporte un en tte
de cinq octets et des donnes optionnelles. Il existe quatre type de messages
identifis par un code (1 octet), requte (1=request), rponse (2=response),
succs (3=Success) et chec (4=Failure). Chaque message est tiquet laide
dun nombre Identifier compris entre 0 et 255, ltiquette dune rponse est
gale celle de la requte correspondante. La longueur totale du message,
code sur deux octets est comprise entre 4 et 65535. Le champ type (compris
entre 0 et 255) dsigne le protocole dauthentification transport ou des
oprations particulires :
- Type=1, message relatif lidentit (Identity)
- Type=3, notification dun erreur (NAK).
- Type=4, protocole dauthentification base de dfi MD5 (EAP-MD5)
- Type = 13, transport de TLS (EAP-TLS)
- Type = 18 mthode dauthentification base sur une carte SIM (EAP-SIM)
- Type = 26, transport de MSCHAPv2.
Lidentit de lutilisateur est indique par la valeur EAP-ID associe au
message EAP-Response.Identity. Lorsque ce paramtre est similaire une
adresse de courrier lectronique (NAI 18) le point daccs interprte la partie
gauche (avant le caractre @) comme un login utilisateur et la partie droite
comme le nom de domaine dun serveur RADIUS.
Une session dauthentification (voir figure 6) est initie par le point
daccs grce au message EAP-Request.Identity. Elle se poursuit par une suite
de requtes et de rponses (EAP-Request.Type et EAP-Response.Type),
relatives un type (scnario dauthentification) particulier et changs entre
18
The Network Access Identifier, RFC 2486, June 1999

le serveur RADIUS et le Supplicant. Elle se termine par un message EAPSuccess ou EAP-Failure.

EAP-Start
EAP-Request.Identity
Calcul
De la cl
Unicast
EAP-Response.Identity
Access-Request/EAP
EAP-Request.Type
Access-Challenge/EAP
EAP-Response.Type
Access-Request/EAP
EAP-Sucess
EAPoL-Key
Access-Accept/EAP +
Unicast Key
Calcul
De la cl
Unicast
Cl Globale
Figure 6. Une session typique dauthentification
Un des points faibles du protocole EAP est le dni de service [Mishra et

al, 2002], un pirate peut couter une session EAP et mettre lintention du
Supplicant un message EAP-Failure. Cependant il ne pourra pas obtenir la cl
globale dlivre par le message EAPoL-Key parce que cette dernire est
chiffre et signe par la cl unicast dont il ne connat pas la valeur.
Nous allons prsent examiner brivement trois types de mthodes
dauthentification lies des environnements diffrents.
4.1 EAP-MSCHAPv2
Dans lunivers Microsoft la scurit dun ordinateur personnel est
fortement corrle au mot de passe de son utilisateur. Ce dernier nest jamais
stock en clair dans la mmoire de la machine. A partir dun mot de passe
on calcule une empreinte MD4 de 16 octets, mmorise par le systme hte.
Cette valeur, parfois nomme cl NT ou NtPasswordHash est complte par
cinq octets nuls. On obtient ainsi 21 octets interprts comme une suite de
trois cls DES (de 56 bits chacune). La mthode MSCHAPv1 est une
authentification simple, le serveur dauthentification produit un nombre
alatoire de 8 octets, lauthentifi utilise ses trois cls DES pour chiffrer cet
ala, ce qui gnre une rponse de 24 octets. MSCHAPv2 est une extension
du protocole prcdent, le serveur dauthentification dlivre un nombre
alatoire de 16 octets (AuthenticatorChallenge), le Supplicant calcule un
nombre 8 octets partir de cette valeur, dun ala (PeerChallenge) quil gnre
et du nom de lutilisateur (login). Ce paramtre est chiffr de manire
analogue MSCHAPv1 par la cl NT et lon obtient une valeur de 21 octets.

Dans une plateforme Microsoft un annuaire stocke le nom des utilisateurs et
leur mot de passe.
4.2 EAP-SIM
Les oprateurs de tlphonie mobiles utilisent une carte puce SIM pour
identifier et facturer un abonn. Cette dernire stocke lidentit de
lutilisateur (IMSI) et une cl secrte note Ki. Le rseau authentifie un client
laide dun triplet RAND (16 octets) SRES (4 octets) et Kc (8 octets). RAND
est un nombre alatoire gnr par le serveur dauthentification.
Lalgorithme cryptographique A3/A8 associ la cl Ki et appliqu la
valeur dentre RAND fournit une valeur de 96 bits, qui reprsente la
concatnation des attributs SRES et KC. SRES est interprt comme une
signature prouvant lidentit de lutilisateur et KC est utilise pour le
chiffrement de la conversation tlphonique. Parce que les oprateurs
envisagent de prolonger le rseau GPRS par des hotspots Wi-Fi ils proposent
un protocole dauthentification EAP-SIM19, bas sur la carte SIM et se
droulant schmatiquement de la manire suivante :
- Lidentit (EAP-ID) est obtenue par la concatnation du caractre 1 de la
valeur exprime en ASCII de lIMSI (une suite de chiffres) du caractre @ et
du nom de domaine de loprateur (EAP_ID == 1IMSI@operator.com)
- Le Supplicant gnre un nombre alatoire (NONCE)
- Le serveur RADIUS dlivre une suite de valeurs RANDi, ce message est
sign par une empreinte (digest) prenant en compte la valeur NONCE
- Le Supplicant calculent les valeurs SRESi et KCi. Il prouve sa connaissance
de SRESi en incluant une empreinte, prenant en compte les valeurs SRESi,
dans le message de rponse. Le nombre NONCE et les attributs KCi sont
utiliss pour le calcul de la cl Unicast.
Grce la technologie EAP-SIM les oprateurs de tlphonie peuvent
utiliser leur base de donnes clients (Host Location Register) pour assurer la
facturation des services sans fil.
4.3 EAP-TLS
Le transport de messages TLS pose essentiellement un problme de
segmentation. La taille dun enregistrement TLS est dau plus 16384 octets, le
protocole RADIUS limite sa charge utile 4096 octets et de surcrot la taille
des trames 802.11 est limite 2312 octets. EAP-TLS20 supporte en
consquence un mcanisme de segmentation des enregistrements.
19
20
H. Haverinen, J. Salowey , EAP SIM Authentication, RFC 4186

PPP EAP TLS Authentication Protocol, RFC 2716, October 1999.
Contrairement lusage courant de TLS mettant en uvre une

authentification (simple) du serveur, EAP-TLS utilise une authentification
mutuelle entre serveur RADIUS et Supplicant (voir figure 7). Ce dernier doit
donc disposer dun certificat X509 et dune cl prive afin de prouver son
identit.
<- EAP-Request/Identity
EAP-Response/Identity (MyEAP-ID)-->
<- EAP-Request/EAP-Type=EAP-TLS/
TLS Start
EAP-Response/EAP-Type=EAP-TLS
(TLS client_hello)---------------->
<- EAP-Request/EAP-Type=EAP-TLS
TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
^PrivateKey
Digest
MD5+SHA-1
36 octets
TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)----------------------->
<-
% modulus
EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/EAP-Type=EAP-TLS ------>
<- EAP-Success
Figure 7. Le protocole EAP-TLS
Lusage dune cl priv par le Supplicant soulve le problme critique de

la scurit requise par stockage et de la mise en uvre dun tel composant.
Dans les plateformes informatiques usuelles cette scurit est assure par
des mots de passe permettant de dchiffrer et dutiliser la cl prive. La carte
puce constitue une alternative cette mthode, lorsque la scurit de la
plateforme informatique est juge insuffisante.
5 Vers la carte puce EAP
Dans la section prcdente nous avons voqu lusage de cartes puce
pour des rseaux lis aux oprateurs de tlphonie mobiles (cartes SIM), ou
utilisant des infrastructures cls publiques (PKI). Cette technologie a
permis aux oprateurs dexploiter leur rseau en limitant trs fortement le
nombre de fraudes (et par consquent dassurer une rentabilit financire);
elle est galement le support lgal de la signature lectronique reconnue par
de nombreux pays.
La carte puce EAP est un projet dcrit par un draft IETF21, auquel
participe les principaux industriels de ce secteur, qui propose de traiter
directement le protocole EAP dans la puce scuris. Bien que cette liste ne
soit pas exhaustive les principales applications vises sont EAP-SIM et EAPTLS.
Schmatiquement une carte EAP [Urien2 et al, 2003] assure quatre
services de base (voir figure 8),
- La gestion de multiples identits. Le porteur de la carte peut utiliser
plusieurs rseaux sans fil. Chacun dentre eux ncessite un triplet
dauthentification, EAP-ID (la valeur dlivre dans le message EAPResponse.Identity), EAP-Type (le type de protocole dauthentification
support par le rseau), et les crdits cryptographiques c'est--dire
lensemble des cls ou paramtres utiliss par un protocole particulier (EAPSIM, EAP-TLS, MSCHAPv2). Chaque triplet est identifi par un nom
(lidentit) dont linterprtation peut tre multiple (SSID, nom dun compte
utilisateur, mnmonique, )
- Laffectation dune identit la carte, en fonction du rseau visit.
- Le traitement des messages EAP.
- Le calcul de la cl unicast en fin de session dauthentification et sa mise a
disposition pour le terminal dsirant accder aux ressources du rseau sans
fil.
EAP Software
Entity
Supplicant
Operating
System
802.11
Interface
IN/OUT
EAP
Packets
Unicast Key
EAP
Packets
Identity
Management
RADIUS
Server
Figure 8. La carte puce EAP
21 P.Urien, G.Pujolle "EAP support in smartcards", draft-urien-eap-smartcardxx.txt, 2003-2011
6 RADIUS
Outre Atlantique les fournisseurs de services internet (ISP) utilisent
frquemment des pools de modem installs dans les centraux tlphoniques
urbains. Cette infrastructure, permettant des accs bon marchs est baptise
point de prsence ou POP (point of presence). Plutt que de dupliquer et de
mettre jour dans chaque POP la base donne des comptes clients, les ISPs
ont dploy une architecture centralise, assurant la gestion distance de
leurs clients (roaming) et sappuyant sur trois niveaux fonctionnels
- Lutilisateur muni dun login et dun mot de passe (un supplicant en fait)
- Le Network Access Server (NAS). Cette entit contrle lensemble des
modems et assure linterface avec le serveur dauthentification, elle est
analogue un authenticator 802.1X.
- Le serveur RADIUS, jouant le rle dun serveur dauthentification 802.1X.
Ce dernier systme assure linterface avec la base de donnes grant les
comptes utilisateurs. Le dialogue dauthentification usuellement bas sur les
protocoles PAP ou CHAP et relay par le NAS entre utilisateur et serveur
dauthentification.
Le NAS ralise un pont applicatif entre les protocoles PAP ou CHAP
(transports par PPP) et le serveur RADIUS. Par exemple, dans le cas de
PAP il transmet au serveur RADIUS, des fins de vrification, lidentit de
lutilisateur et son mot de passe. Le serveur RADIUS indique au NAS le
succs ou lchec de cette opration. Le NAS mesure galement le temps
dutilisation du service par le client et transmet une requte de facturation
lorsque ce dernier quitte le POP.
Supplicant
EAP
Authenticator
Access Point
RADIUS
Authentication
Server
Base de donnes
Comptes Clients
Packets
Filtering
EAP / LAN
EAP / RADIUS
NAS
802.1x
RADIUS
LDAP/ODBC/MAP
Figure 9.RADIUS et base de donnes clients.
Le transport22 quasi transparent du protocole EAP par RADIUS, permet

de mettre en place une architecture gnrique, indpendante des mthodes
dauthentification utilises par les ISPs.
La scurit des changes RADIUS est assure laide dun secret partag
entre serveur dauthentification et NAS. Le NAS produit des messages
Access-Request comportant un nombre alatoire de 16 octets, nomm
Authenticator. La rponse du serveur RADIUS est lun des trois messages
suivants, Access-Challenge, Access-Reject ou Access-Success. Ces derniers sont
signs par une empreinte MD5, le Response Authenticator calcule partir du
contenu du message, de lala Authenticator et du secret partag. Afin
dviter des attaques du type man in the middle , les requtes RADIUS
(dlivres par le NAS) sont signes par lattribut Message-Authenticator, un
HMAC23 du message dont la cl est gale au secret RADIUS.
En rsum la scurit du protocole RADIUS repose sur lalgorithme
MD5; certaines architectures sappuient sur IPSEC pour renforcer la scurit
du lien avec le serveur dauthentification.
Bien que non standardises, linterface entre le serveur RADIUS et la base
de donne des comptes clients (SGBD, annuaire LDAP, autre) est un point
essentiel. Dans certain cas ces deux entits sont loges par la mme machine;
des locaux scuriss sont cependant ncessaires pour viter le pillage des
donnes critiques. Lorsque la base cliente et le serveur RADIUS sont distants
un lien scuris est ncessaire (SASL24, SSL/TLS, IPSEC ).
7 IEEE 802.11i
Nous avons prcdemment soulign les faiblesses du protocole WEP. La
norme 802.1x dfinit un cadre pour lauthentification mais ne spcifie de
manire dtaille la mthode de distribution des cls. Dautre part le
Supplicant ne participe pas au calcul de la cl globale, il ny a pas de
procdure de mutuelle authentification entre Supplicant et point daccs
mettant profit lexistence dun secret partag (la cl unicast).
Le groupe de travail IEEE 802.11i [IEEE Std 802.11i/D5.0, 2003] tudie
une architecture destine combler ces lacunes. Bien que ce standard ne soit
encore pas encore finalis, un comit industriel a dj dit une
22
23
24
Ce transport est dcrit dans la RFC 2869, RADIUS extensions, June 2000
Keyed-Hashing for Message Authentication, RFC 2104, February 1997
Simple Authentication and Security Layer (SASL), RFC 2222, October 1997
recommandation (WPA25) base sur un sous ensemble de ce standard

mergeant.
Nous classerons les apports de la norme IEEE 802.11i en trois catgories,
dfinition de multiples protocoles de scurit radio, lments dinformation
permettant de choisir lun dentre eux et nouvelle mthode distribution de
cls.
Le standard sappuie sur les rseaux sans fil 802.11 et utilise 802.1x pour
lauthentification et le calcul dune cl matre nomme PMK (Pairwise Master
Key). Cependant dans le cas du mode adhoc, cette cl baptise PSK (Pre
Shared Key) est distribue manuellement. La hirarchie des cls
cryptographiques est prsente par la figure 10.
7.1 Protocoles de scurit radio
Trois protocoles de scurit sont proposs,
- WEP, import de la norme 802.11 originale.
- TKIP (Temporal Key Integrity Protocol), le successeur de WEP. Il met en
uvre lalgorithme de chiffrement RC4, et ajoute chaque SDU 26 MAC une
signature de 64 bits baptise MIC (Message Integrity Code). La cl RC4 (128
bits) est calcule partir dun compteur de 48 bits (Transmit Sequence)
transmis en clair dans chaque trame et dune cl TK (Temporal Key).
- CCMP (Counter-Mode/CBC-MAC), utilise lalgorithme de chiffrement
AES en mode CCM et une signature MIC. Les paramtres de chiffrement
(bloc initial) sont dduits dun compteur de 48 bits (Packet Number)
transmis en clair dans chaque trame et dune cl TK.
Pairwise Master Key PMK / Pre Shared Key PSK
Group Master Key GMK
Pairwise Temporal Key PTK
Group Transient Key (GTK)
KCK
EAPOL-Key
Confirmation Key
128 bits
KEK
EAPOL-Key
Encryption Key
128 bits
TK
Temporal Key
TKIP: 256 bits
CCMP:128 bits
TK
Temporal Key
TKIP 256 bits
CCMP: 128 bits
Figure 10.Hierarchie des cls 802.11i
25
26
Wi-Fi Protected Access, Version 2.0, April 29, 2003

Service Data Unit
7.2 Elments dinformation

Un point daccs diffuse dans ses trames Beacon ou Probe des lments
dinformation (IE, Information Element) afin de notifier au Supplicant les
indications suivantes,
- La liste des infrastructures dauthentification supportes (typiquement
802.1X)
- La liste des protocoles de scurit disponibles (TKIP, CCMP,)
- La mthode de chiffrement pour la distribution dune cl de groupe (GTK).
Une station 802.11 notifie son choix par un lment dinformation insr
dans sa demande dassociation.
7.3 Distribution des cls
802.1X
Calcul
de
PMK
EAP-Sucess
PMK
802.11i
EAPoL-Key/ANonce
Calcul
de
PTK
EAPoL-Key/SNonce
EAPoL-Key/Install
PTK = PRF(PMK, MAC_AP,

MAC_STA, ANonce, GNonce)
PTK = KCK || KEK || TK
EAPoL-Key/l
Protocole de scurit RADIO
WEP-TKIPCCMP
Figure 11 le protocole quatre passes 802.11i.
A la fin de la procdure dauthentification le Supplicant et le serveur

dauthentification partagent une cl PMK. Cette valeur est dlivre au point
daccs via le protocole RADIUS. A laide dun protocole quatre passes (4way Handshake), transport par des trames EAPoL-Key (voir figure 11) le
supplicant et le point daccs dduisent une cl PTK. Cette valeur est
calcule par la fonction PRF (Pseudo Random Function) avec comme

arguments dentre des nombres alatoires (ANonce et SNonce) fournis par
le supplicant et le point daccs, le secret partag PMK et les adresses MAC
du point daccs et du Supplicant.
PTK= PRF(PMK, Pairwise key expansion, MAC_AP, MAC_STA, ANonce, SNonce)
La valeur PTK se dcompose en plusieurs sous cls, KCK qui assure la

signature des messages EAPoL-Key, KEK associe au chiffrement de la cl
GMK, et TK utilise pour la scurit des trames de donnes.
Le point daccs dispose dune cl de groupe GMK. Un protocole deux
passes (2-way handshake) permet de dlivrer la valeur GMK (chiffre par
KEK) et de dduire laide dun nombre alatoire GNonce une cl
temporaire de groupe GTK
GTK= PRF(GMK, Group key expansion, MAC_AP, GNonce).
8 Une approche verticale.
VPN
Roaming
Filtrage des Paquets
Scurit Radio
Infrastructure d'Authentification
AAA
Authentification
Figure 12 : Modle cinq couches de la scurit des rseaux 802.11.
Nous avons rcemment introduit [Urien1 et all, 2003] un modle cinq

niveaux dcrivant larchitecture de scurit des environnements sans fil
802.11. Nous rappelons ici brivement les lments du modle.
La procdure d'authentification. C'est la cl de vote d'une
infrastructure scurise. Il y a deux choix de base. 1-L'utilisateur connat ses
cls d'authentification (symtriques, asymtriques), et les protge l'aide
de mot de passe (par exemple, de manire analogue au logiciel libre openssl
une cl RSA prive est chiffre par un triple DES, dont les cls sont dduites
d'une phrase). 2-L'utilisateur ne connat pas ses cls d'authentification qui
sont la proprit du prestataire de service. Une carte puce par exemple,
difficile cloner, ralise aprs renseignement d'un code PIN, les calculs
d'authentification.
L infrastructure d'authentification. La norme 802.1x recommande
l'usage de serveur RADIUS. L'authentification peut tre conduite par un
serveur situ dans le domaine visit ou l'extrieur de ce dernier. De
manire analogue PGP, cette architecture tablit un cercle de confiance,
grce auquel un message d'authentification est relay par plusieurs serveurs,
lis les uns aux autres par des associations de scurit.
La scurit radio. Elle assure la confidentialit, l'intgrit et la signature
des paquets. Ces services sont dlivrs par des protocoles tels que WEP ou
TKIP ou CCMP normaliss par le comit IEEE 802. Ils utilisent des cls
(chiffrement, signature trames), dduites d'une cl matre, au terme de la
procdure d'authentification.
Le filtrage des paquets. La fiabilit de cette opration repose sur la
signature des paquets ( l'aide de cls dduites de l'authentification). Grce
ce mcanisme, les trames qui pntrent dans le systme de distribution sont
sures (pas de risque de spoofing), les systmes de filtrages (point d'accs ou
portail) grent les privilges des paquets IP (destruction des paquets illicites)
et par exemple peuvent raliser et facturer des services de QoS.
Laccs des services distants (roaming) que nous dsignons
gnriquement sous l'appellation services VPN (Virtual Private Network).
Par exemple, on mettra en oeuvre des liens scuriss (inter domaine) laide
des protocoles IPSEC ou SSL.
9 Conclusion
Dans ce chapitre nous avons prsent les architectures de scurit qui
sont en cours de dploiement ou de dfinition pour les rseaux 802.11.
Compte tenu de lengouement du march sur lIP sans fil, il est trs probable
que ces technologies deviennent des standards incontournables et jouent un
rle prpondrant dans linformatique enfouie, qui ne pourra se dvelopper
sans normes de scurit prouves.
10 Bibliographie
Arbaugh, W., Shankar, N. and Wan J.Y.C., "Your 802.11 Wireless Network has No
Clothes", Department of Computer Science, University of Maryland, College Park,
March 2001, http://www.cs.umd.edu/~waa/wireless.pdf.
Borisov N, GoldBerg I, Wagner D, Intercepting Mobile Communications: The
Insecurity of 802.11, Proceeding of the Eleventh Annual International Conference on
Mobile Computing And Network, p180, July 16-21, 2001.
Fluhrer S, Mantin I, Shamir A, Weakness in the key scheduling algorithm of
RC4, 8th Annual Workshop on Selected Areas in Cryptography, August 2001.
IEEE Std 802.11, Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) specifications, 1999.
IEEE Std 802.1X, Standards for Local and Metropolitan Area Networks: Port
Based Access Control, June 14, 2001
IEEE Std 802.11i/D5.0, Draft Supplement to standard for Telecommunications
and Information Exchange, Between Systems LAN/MAN Specific Requirements Part
11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications:
Specification for Enhanced Security, August 2003
Mishra A, Arbaugh W, An Initial Security Analysis of the IEEE 802.1X
standard. February. 2002
Urien P, Pujolle G, Architecture scurise par cartes puces, pour des rseaux
sans fil sures et conomiquement viables, GRES2003, fvrier 2003 Fortaleza Brsil.
Urien P, Loutrel M, The EAP Smartcard, a tamper resistant device dedicated to
802.11 wireless networks, ASWN 2003, Third workshop on Applications and
Services in Wireless Networks, Berne Suisse Juillet 2003
III- WEP et les

Architectures
Alternatives
1. Introduction
Laccs un rseau en mode sans fil pose un problme de scurit dun
type nouveau puisque en mode filaire la prsence de lutilisateur dans
linfrastructure du rseau implique une vrification pralable de son identit
et de ses droits.
Conscient de ces enjeux la norme IEEE 802.11 a introduit un protocole de
scurit (WEP), qui a pour objectif dassurer les fonctions suivantes :
- Authentification dun utilisateur.
- Confidentialit des donnes changes sur les canaux radio.
- Garantie de lintgrit des donnes.
Cependant ce protocole prsente des failles importantes, et de nombreux
logiciels disponibles sur le WEB permettent dobtenir rapidement les cls
RC4 de chiffrement et dauthentification ; en ltat actuel les rseaux 802.11
offrent donc une scurit quasi nulle.
Le protocole WEP utilise lalgorithme de chiffrement RC4 dont nous
allons rappeler brivement quelques caractristiques. RC4 permet de chiffrer
des donnes en mode flux octets (stream cipher), partir dune cl de
longueur comprise entre 8 et 2048 bits on gnre ( laide dun pseudo
random generator PRNG) une suite doctets pseudo alatoire nomme
KeyStream. Cette srie doctets (Ksi) est utilise pour chiffrer un message en
clair (Mi) laide dun classique protocole de Vernam, ralisant un ou
exclusif (xor) entre Xsi et Mi (Ci = Xsi xor Mi).
Il nest pas recommand dutiliser plusieurs fois une cl RC4, parce que
la connaissance dun octet en clair (Mi) et chiffr (Ci) permet de dduire la
valeur du KeyStream (Xsi) correspondant (Ci xor Mi = Xsi xor Mi xor Mi =

Xsi).
Trame
MAC HEADER
IV
KeyID
Ciphered Block
2 bits
24 bits
Body
40 bits
IV
RC4
PRNG
Shared
Secret
CRC
XOR
KeyStream
RC4 key, 64 bits

Figure 1. Trame WEP
Une trame 802.11 comporte les lments suivants,

- Un entte (MAC header) qui dcrit la nature de la trame, les adresses des
entits source et destination et diverses informations.
- Un corps de trame (body), dont la longueur varie de 0 2312 octets.
- Un CRC (Cyclic Redundancy Code) de 4 octets assure le contrle
dintgrit des donnes.
Un bit de len tte MAC indique lventuel chiffrement du corps de trame
et du CRC laide du protocole WEP. La structure de la trame (figure 1) est
alors la suivante,
- Lentte MAC
- Un champ IV (Init Vector) large de 3 octets
- Un octet, dont les six premiers bits sont zro et dont les deux derniers
indiquent un index de cl (KeyID).
- Une zone chiffre par une cl RC4 de 64 bits dduite de la valeur IV et
de lindice KeyID. Ce bloc englobe le corps de trame et le CRC.
La cl de chiffrement RC4 dune trame, large de 64 bits, est obtenue par la
concatnation dune partie secrte de 40 bits (une parmi quatre, dont lindice
KeyID est compris entre 0 et 3) et le vecteur IV (24 bits).
Il existe seulement 224 (environ 16 millions) valeurs diffrentes du champ

IV, soit encore 224 keystreams distincts par secret partag. Un attaquant peut
facilement diffuser une trame dont il connat le contenu en clair (courrier
lectronique, URL, etc ) puis dduire des trames chiffres les diffrents
keystreams gnrs par le protocole WEP. Lattaque de base ne consiste pas
une attaque force brute, visant casser des cls RC4 de 64 bits, mais
enregistrer les 16 millions de keystreams qui ralisent lauthentification des
utilisateurs et la confidentialit des informations changes.
Remarquons galement que conformment au paradoxe des
anniversaires (dans un groupe de 23 personnes il y a 50 % de chance que
deux dates danniversaire soient identiques), un mme IV sera rutilis au
bout de 4823 trames avec une probabilit de 50%.
Le processus dauthentification se droule de la manire suivante. Un
point daccs (AP) met priodiquement une trame balise (beacon frame). Une
station qui dsire rejoindre la cellule met une demande dassociation
acquitte par le point daccs. Une fois le mcanisme dassociation ralis, la
station sauthentifie auprs du rseau grce un scnario en quatre passes,
- La station transmet une requte dauthentification (Authentication
Request).
- Le point daccs produit un challenge (Authentication Challenge) qui
comporte 128 octets en clair.
- La station encode ce nombre de 128 octets laide dune trame WEP
(Authentication Response), associe un IV 24 bits et un KeyID de 2 bits.
- Le point daccs notifie lchec ou la russite de lopration
(Authentication Result).
La connaissance du message en clair (challenge de 128 octets) et du
message chiffr, permet de dduire les 128 premiers octets du keystream
gnr partir du vecteur IV et du KeyID. Une consquence immdiate est
que lon peut par simple coute rcuprer un triplet (IV, KeyID, keystream)
rutilisable pour un autre processus dauthentification. Il est donc trivial
dusurper une identit (Authentication Spoofing).
Une proprit remarquable des CRCs est que le ou exclusif (octets
octets) de deux trames de mme longueur est associ un CRC obtenu par
un ou exclusif des deux autres CRCs. A partir dune trame en clair et de son
CRC, il est donc possible de modifier une trame chiffre tout en recalculant
un CRC correct (Mi xor Ksi xor Mi = Mi xor Mi xor Ksi est associ au CRC
chiffr CRCi xor Ksi xor CRCi = CRCi xor CRCi xor Ksi). Le protocole WEP
nassure donc pas lintgrit des donnes.
Le successeur de WEP, WEP2 proposait de mettre en uvre des vecteurs

IV de 128 bits, et des cls RC4 de 40, 104 ou 128 bits [2]. Cependant la grande
faiblesse de WEP provient de lutilisation de cls RC4 fixes et donc de
labsence darchitecture dauthentification et de distribution de cls de
session.
2. Exemples darchitectures alternatives
2.1 WFG (Wireless Firewall Gateway)
Ce concept issu dun projet de recherche de la NASA est frquemment

utilis par des oprateurs de hotspots, et sappuie sur quatre lments,
- La libre allocation dune adresse IP via un serveur DHCP
- Lauthentification du visiteur (grce un numro de compte et un mot
de passe) laide dune classique session HTTP, scurise par SSL.
- Le filtrage des adresses IP, les paquets dont ladresse IP nest pas
authentifie, sont bloqus par un pare-feu.
- La scurit de linformation change est assure au niveau applicatif,
par exemple grce aux protocoles SSH ou SSL.
2.2 SWITCHmobile
Le systme SWITCHmobile est ddi la gestion de la mobilit en milieu
universitaire; il est bas sur le filtrage des adresses MAC (Access Control
List). Le rseau sans fil visit (docking network) comporte un commutateur
muni dune liste dadresses autorises. Lallocation des adresses IP est libre,
cependant les privilges associs dpendent de ladresse (MAC) du
demandeur. De surcrot une passerelle VPN assure la scurit des paquets
destins des domaines distants.
IV- EAP
Extensible Authentication
Protocol
1 Introduction
EAP ralise une enveloppe pour de multiples mthodes
dauthentification. Il est transport par des trames 802 ou par le protocole
RADIUS.
Il est dfinit par les RFC 2284 et 3748 .
2 EAPoL
Les trames EAPoL (EAP over LAN) transportent les messages EAP et
dlivrent des services additionnels.
Lidentifiant de protocole Ethernet EAP (PID) est 888E. Ladresse de
groupe MAC est gale 01-80-C2-00-00-03.
2.1 Format dune trame EAPoL
- PID (888E), 2 octet.
- Version, 1 octet (1 est la version courante)
- Type du paquet, 1 octet
- Longueur de la charge du paquet 2 octet, une valeur 0 indique une
charge nulle.
Il existe cinq types de paquets,

- 0 (EAPOL-Packet), une trame transportant un message EAP
- 1 (EAPOL-Start), une trame mise par un supplicant, notifiant une
demande dauthentification. La rponse est un message EAPRequest.identity.
- 2 (EAPOL-Logoff), une trame mise qui force un port 802.1X ltat
UNAUTHORIZED.
- 3 (EAPOL-Key), une trame ralisant un protocole dchange de cl.
- 4 (EAPOL-Encapsulated-ASF-Alert), une trame mise lintention dun
port 802.1X, indiquant une alerte (trap au sens SMNP) particulire.
2.2 Exemple dun paquet EAPOL-Start
Frame Control: 0x0108
Version: 0
Type: Data frame (2)
Subtype: 0
Flags: 0x1
DS status: Frame is entering DS (To DS: 1 From DS: 0) (0x01)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = WEP flag: WEP is disabled
0... .... = Order flag: Not strictly ordered
Duration: 258
BSS Id: 00:02:2d:34:28:10 (Agere_34:28:10)
Source address: 00:05:3c:04:9f:94 (Xircom_04:9f:94)
Destination address: 00:02:2d:34:28:10 (Agere_34:28:10)
Fragment number: 0
Sequence number: 41
08 01 02 01 00 02 2d 34 28 10 00 05 3c 04 9f 94
00 02 2d 34 28 10 90 02 aa aa 03 00 00 00 88 8e
01 01 00 00 00
2.3 Exemple dun descripteur de cl.

0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Version=1
| Packet Type=3 |Packet Body Length=44+KeyLength|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1(RC4) |
Key Length ( WEP=4 ou 13 ) |Replay Counter..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Replay Counter.
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Replay Counter
|
Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key IV...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key IV...
|F| Key Index
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key Signature...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Key.Value..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Le format dune cl est identifi par un champ Type (1 indiquant par

exemple une cl RC4).
- Dans le cas du WEP la longueur dune cl est de 4 ou 13 octets. Lorsque
la longueur de la charge (Body Length) est gale 44 octets, la valeur de la cl
est absente, et donc connue implicitement (par exemple elle est dduite de
lattribut MS-MPPE-Send-Key, la cl globale par dfaut dans
limplmentation Microsoft).
- Replay Counter est un nombre unique de 8 octets, par exemple lheure
au format NTP.
- KeyIV est un nombre alatoire de 16 octets.
- Le bit F indique si la cl transporte est Unicast (F=1) ou globale
(broadcast, F=0). Chaque cl possde un index.
- Key Signature (16 octets) est une signature HMAC-MD5 portant sur la
totalit du descripteur ( partir du champ version), et ralise avec la cl
Unicast (soit MS-MPPE-Recv-Key).
- Dans limplmentation Microsoft la valeur de la cl est chiffre par une

cl RC4 de 48 octets obtenue par concatnation des champs Key-IV (16
octets) et de la cl Unicast (MS-MPPE-Recv- Key).
3 Le protocole EAP (RFC 2284, RFC 3748)
3.1 Le modle EAP
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP method | EAP method| | EAP method | EAP method|
|
Type = X | Type = Y | |Type = EAP-SC| Type = Y |
|
V
|
| |
^
|
|
+-+-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+
|
!
| |
!
|
| EAP ! Peer Layer
| | EAP ! Auth. Layer
|
|
!
| |
!
|
+-+-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+
|
!
| |
!
|
| EAP ! Layer
| | EAP ! Layer
|
|
!
| |
!
|
+-+-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+
|
!
| |
!
|
| Lower ! Layer
| | Lower ! Layer
|
|
!
| |
!
|
+-+-+-+-!-+-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+-+
!
!
!
Peer
! Server
+------------>---------------+
Le EAP multiplexing layer comporte 4 couches

- Lower Layer, niveau rseau (couches basses) qui met et reoit des
trames.
- EAP Layer, cette couche gre les re-missions des messages EAP
- Peer Layer, traitement des messages EAP, le champ type est utilis de
manire analogue un port UDP afin de slectionner la mthode
approprie.
- EAP method, traitement dune mthode EAP particulire.
3.2 Format dun message EAP

0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Data ...
+-+-+-+-+
- Code (1 octet), indique la nature du message. 1-Request, 2-Response, 3Success, 4-Failure

- Identifier, 1 octet, ltiquette dun message. Ltiquette dune rponse
(Code=2) est identique celle de la requte correspondante.
- Length, 2 octets, la longueur totale du message ( partir du champ code).
- Data, des informations optionnelles.
3.3 Requtes et rponses
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
| Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
| Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Les requtes et les rponses comportent un champ type (1 octet), qui

prcise la nature des informations transportes.
- 1 Identity, lidentit (ID) du supplicant.
- 2 Notification, ce message contient une information affichable. La
rponse une notification est obligatoirement une notification.
- 3 Nak (Response only). Cest la rponse une requte inacceptable.
- 4 MD5-Challenge.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
La requte comporte un nombre alatoire. La rponse est lempreinte

MD5 de cet ala, Response = MD5(EAP-Identifier || Challenge || Secret)
La trace ci-dessous est un exemple, obtenu avec un systme XP, le nom

dutilisateur est 1234, nom de domaine est ABCD.
EAP-Start, 00 30 ab 14 68 ef 00 30 ab 1a 07 8f 88 8e 01 01 00 00
Identity-Request, 00 30 ab 1a 07 8f 00 30 ab 14 68 ef 88 8e 01 00
00 05 01 a7 00 05 01
Identity-Response, 00 30 ab 14 68 ef 00 30 ab 1a 07 8f 88 8e 01 00
00 0e 02 a7 00 0e 01 41 42 43 44 5c 31 32 33 34
MD5-Request, 00 30 ab 1a 07 8f 00 30 ab 14 68 ef 88 8e 01 00 00 16
01 a8 00 16 04 10 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef.
MD5-Response, 00 30 ab 14 68 ef 00 30 ab 1a 07 8f 88 8e 01 00 00 1f
02 a8 00 1f 04 10 3d 92 48 f4 2b be 0f 81 05 4e d4 39 87 77 a3 82 41
42 43 44 5c 31 32 33 34
EAP-Success, 00 30 ab 1a 07 8f 00 30 ab 14 68 ef 88 8e 01 00 00 04
03 a8 00 04
5 One Time Password (OTP, RFC 1938). La requte comporte un message

affichable.
6 Generic Token Card (GTC). La requte comporte un message affichable.
4 Mthodes dauthentification diverses.
De nombreuses mthodes dauthentification sont en cours dtudes, telles
que,
- EAP-TLS (RFC 2716) bas sur TLS.
- IAKERB, adaptation des mcanismes dauthentification de Kerberos V5.
- EAP-SIM, utilisation des cartes puce SIM (GSM 11.11).
- EAP-AKA, mise en uvre des cartes puce USIM (dfinies pour
lUMTS).
- EAP-MSCHAPv2, transport de MSCHAPv2.
Afin de protger les procdures bases sur des mots de passes, divers
tunnels ont t proposs, citons par exemple,
- PEAP, Protected EAP. Une premire authentification EAP-TLS est
ralise, puis une seconde session EAP est scurise par ce tunnel.
- EAP-TTLS, EAP Tunneled TLS Authentication Protocol. Une premire
session EAP-TLS est ouverte; puis un second protocole dauthentification est
protg par ce tunnel (attribute-value pairs ou AVPs).
+----------+
+----------+
+----------+
+----------+
|
|
|
|
|
|
|
|
| client |<---->| access |<---->| TTLS AAA |<---->| AAA/H
|
|
|
| point
|
| server |
| server |
|
|
|
|
|
|
|
|
+----------+
+----------+
+----------+
+----------+
<---- secure password authentication tunnel --->
<---- secure data tunnel ---->
Format dun AVP

0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
AVP Code
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M r r r r r r|
AVP Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Vendor-ID (opt)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Data ...
+-+-+-+-+-+-+-+-+
4.1 LEAP, Lightweight Extensible Authentication Protocol

Cette architecture s'appuie sur la procdure d'authentification disponible
sur les plates-formes Windows. A partir du mot de passe utilisateur, on
calcule une empreinte MD4 de 16 octets. Cette dernire est complte par
cinq octets nuls, on obtient ainsi une suite de 21 octets interprte sous la
forme de trois cls DES de sept octets (soit 56 bits). Le mcanisme
d'authentification, de type CHAP consiste chiffrer un nombre alatoire de 8
octets l'aide des trois cls DES associes un utilisateur (ce qui produit une
rponse de 24 octets).
LEAP est associ au type EAP 17 (0x11); il ralise une double
authentification d'une part entre le serveur d'authentification et le supplicant
(utilisateur du rseau) et d'autre part entre l'Authenticator (point d'accs) et
le serveur d'authentification. Au terme d'un scnario d'authentification
russi, entre Supplicant et serveur RADIUS, les deux entits dduisent une
cl de session SK (Unicast) qui est transporte l'aide d'un attribut
propritaire ("cisco-avpair, leap:session-key") du protocole RADIUS.
LEAP supporte galement des mcanismes de mise jour de cls WEP,
soit par la ngociation dune session RADIUS limite (Session Timeout), soit
par des demandes priodiques de r-authentification par le supplicant (
l'aide des trames EAP_Logoff et EAP_Start).
AP
EAP_Identity.request
2
SK
RS
EAP_Identity.response
PR=LEAP_MS_CHAP_Peer_Response
4
AP: Access Point (the Aironet base station)

RS: Radius Server
APC: Access Point Challenge (8 bytes)
APR: Access Point Response (24 bytes)
PC: Peer Challenge (8 bytes)
PR: Peer Response 24 bytes)
SK: Session Key
SS: Shared Secret shared between AP (or
upstream proxy) and RS
AUTH: The 16 octet Radius authenticator
of the incoming request
PW: User Password
PC = LEAP_MS_CHAP_Peer_Challenge
3
SK
EAP_Success
5
APC LEAP_Access_Point_Challenge
6
APR=LEAP_Access_Point_Response
7
Encrypted SK = mppe_encrypt(SS,
AUTH, MD5Digest ( MPPEHASH
+ APC + APR + PC + PR))
8
SK
*MPPEHASH: 16 octets
NtPasswordHash(NtPasswordHash(Unicode(PW))))
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code 0x01 | Identifier
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type 0x11 | Version 0x01 | Unused 0x00
| Count 0x08
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Peer Challenge
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Peer Challenge
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
User Name .....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-
4.2 EAP-FAST
Le protocole LEAP bas sur la cl NT, par nature sensible des attaques
par dictionnaire ; plusieurs outils de cassage sont disponibles sur le WEB.
Pour cette raison la socit CISCO a introduit une nouvelle mthode
dauthentification EAP-FAST (Extensible Authentication Protocol-Flexible
Authentication via Secure Tunneling), intgre dans lensemble des produits
Aironet ainsi que dans son serveur VPN Cisco Secure ACS.
EAP-FAST chiffre une transaction EAP au moyen dun tunnel TLS. Cette
solution est assez semblable PEAP, la diffrence que le tunnel EAP-FAST
est tabli laide dun secret appel PAC (Protected Access Credentials). Ce
dernier est gnr par le serveur Cisco Secure ACS laide dune cl matre
connue uniquement du serveur.
EAP-FAST sexcute en deux phases :
- En phase 1, le serveur et le terminal tablissent un tunnel TLS (grce au
PAC). Le client indique son identit grce une extension du protocole
TLS, insr dans le message client-hello.
- En phase 2, une deuxime session EAP, scurise par le tunnel TLS,
ralise lauthentification de lutilisateur.
4.3 EAP-SIM
Client
Radius
Authentication
|
Server
Server AuC
|
|
|
|
EAP-Request/Identity
|
|
|<--------------------------------------------------|
|
|
|
|
| EAP-Response/Identity
|
|
| (Includes user's IMSI)
|
|
|-------------------------------------------------->|
|
|
|-------GetAuthInfo--->|
|
EAP-Request/SIM/Start
|<-----GSM_Triplet-----|
|<--------------------------------------------------|
(RANDi,SRESi,KCi)
|
|
| EAP-Response/SIM/Start
|
| (AT_NONCE_MT)
|
|-------------------------------------------------->|
|
|
|
EAP-Request/SIM/Challenge
|
|
(AT_RAND, AT_MAC)
|
|<--------------------------------------------------|
|
|
+-------------------------------------+
|
| Client runs GSM algorithms on SIM, |
|
| verifies AT_MAC,
|
|
| and computes session keys
|
|
+-------------------------------------+
|
|
|
| EAP-Response/SIM/Challenge
|
| (AT_MAC)
|
|-------------------------------------------------->|
|
|
|
EAP-Success |
|<--------------------------------------------------|
|
|
Les cartes SIM sont aujourdhui massivement produites (plusieurs milliards

dexemplaires par an) et des prix trs bas (de lordre du dollar par unit).
Le protocole EAP-SIM , propos (et brevet) par la socit NOKIA ralise
une authentification mutuelle laide dune carte SIM; lalgorithme GSM
A3/A8 ne permettant quun mcanisme de simple authentification, des
lments protocolaires additifs sont ncessaires.
Le protocole gre trois types didentits,
- Une identit permanente, un NAI dont la partie gauche est constitue

de lIMSI prcd du caractre 1, et dont la partie droite est le nom de
domaine de loprateur.
- Un pseudonyme, un alias de lidentit permanente destin prserver
lanonymat de lutilisateur, ce paramtre est analogue au Temporary Mobile
Subscriber Identity (TIMSI) mis en uvre dans le GSM.
- Une identit de re-authentification, permettant de transfrer le
processus dauthentification vers un serveur RADIUS diffrent de celui de
loprateur.
Deux mthodes dauthentification sont disponibles,
- Lauthentification complte est base sur des triplets GSM, et les
identits permanentes ou les pseudonymes. Une cl matre (MK) est calcule
en fin de session.
- La re-authentification est une mthode base de cryptographie
symtrique (AES) utilisant la cl MK (dfinie ci-dessus) et produisant une
nouvelle cl matre MK.
Schmatiquement un scnario dauthentification complet se droule de la
manire suivante,
1) Le point daccs met un message EAP-Request/Identity.
2) Le Supplicant notifie par un EAP-Response/Identity son identit
(EAP-ID).
3) Le Serveur
Request/SIM/Start.
dauthentification
produit
le
message
EAP-
4) Le Supplicant choisit un nombre alatoire (NONCE) et linclut dans le

message EAP-Response/SIM/Start.
5) Le serveur dauthentification dispose dun ou plusieurs triplets GSM
(RANDi, SRESi, KCi). Il encapsule dans la requte EAPRequest/SIM/Challenge une liste de valeur RANDi et signe ce message
laide dune empreinte HMAC dont la cl est dduite du nombre NONCE
pralablement reu, des valeurs n*Kci et de divers paramtres. De manire
optionnelle, ce message transporte une identit de re-authentification ou un
pseudonyme ; ces paramtres sont chiffrs.
6) Le Supplicant vrifie la signature de la requte. Il produit le paquet
EAP-Response/SIM/Challenge qui contient une empreinte HMAC du
message( ce dernier tant concatn aux valeurs n*SRESi) dont la cl est
dduite du nombre NONCE pralablement reu, des valeurs n*Kci et de
divers paramtres.
7) Le serveur dauthentification indique le succs des oprations par un

message EAP-Success
La cl MK est dduite dune empreinte SHA1 (160 bits) ralise partir
de lidentit courante du nombre alatoire NONCE et de la liste des cls
KCi.
4.4 EAP-TLS
EAP-TLS s'appuie sur une infrastructure de type PKI. Le serveur
RADIUS et le client du rseau sont munis de certificats dlivrs par une
autorit de certification ("Certificate Authority") commune.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
|
Identifier |
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Flags
|
TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
TLS Message Length
|
TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Le client dlivre un message TLS_Client_Hello qui comporte un nombre

alatoire.
- Le serveur RADIUS rpond par un message TLS_Server_Hello
(comportant galement un nombre alatoire), il transmet ses certificats X509
(message TLS_Certificate). Le message optionnel TLS_Certificate_Request est
une demande d'authentification adresse au client.
- Le client prsente ses certificats (message TLS_Certificate), communique
(message TLS_Client_Key_Exchange) une valeur du secret partag
(PreMasterSecret) chiffre avec la cl publique du serveur. De manire
optionnelle ce secret est sign par la cl prive du client (message
TLS_Certificate_Verify). Le message TLS_Change_Cipher_Spec notifie le
basculement en mode chiffr. L'intgrit du dialogue est garantie par le
message TLS_finished l'aide d'une double empreinte MD5 et SHA-1.
- Le serveur dlivre les messages TLS_Change_Cipher_Spec et
TLS_finished qui mettent fin la session TLS.
Les deux entits partagent un secret MasterSecret, partir duquel elles
dduisent une cl commune de 512 bits.
<- EAP-Request/Identity
EAP-Response/Identity (MyID)------>
<- EAP-Request/EAP-Type=EAP-TLS/
TLS Start
(TLS client_hello)---------------->
<- EAP-Request/EAP-Type=EAP-TLS
TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
TLS certificate,
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)----------------------->
<-
EAP-Request/
EAP-Type=EAP-TLS
(TLS change_cipher_spec,
TLS finished)
EAP-Response/EAP-Type=EAP-TLS ------>
<- EAP-Success
5 EAP dans les systmes XP Windows

Lintroduction des procdures dauthentification 802.1X dans les
plateformes informatiques standards, interagit avec les piles de
communications installes. Par exemple il existe un couplage entre le client
DHCP et ltat du Supplicant 802.1X ; de mme le dmarrage dune session
dauthentification peut impliquer labandon de toutes les connexions TCP
en cours. Les postes informatiques Windows implmentent un Supplicant
802.1X, ce dernier est supervis par un bloc logiciel, le Remote Access
Service (RAS) supervisant entre autre les connexions PPP. Le systme
dexploitation gre tous les tats machines et assure la coordination entre
Supplicant et services rseaux (TCP, DHCP, ) ; cependant lanalyse des
messages EAP est dlgue des bibliothques dynamiques particulires
(DLL) nommes EAP Provider. Un protocole dauthentification EAP
(identifi par le paramtre EAP-Type) est trait par un composant EAPProvider unique, pouvant par ailleurs prendre en charge plusieurs types
dauthentification.
Linterface logicielle (une API) dune bibliothque EAP comporte 8
mthodes, que nous rpartirons en deux classes,
- Classe 1, elle regroupe les fonctions obligatoirement incluses dans le

composant, telles que Ras-Eap-GetInfo, Ras-Eap-Initialize, Ras-Eap-Begin,
Ras-Eap-MakeMessage, Ras-Eap-End, Ras, Eap-Free-Memory
- Classe 2, les procdures pouvant tre fournies dans des bibliothques
additives
telles
que
Ras-Eap-InvokeConfigUI
ou
Ras-EapInvokeInteractiveUI.
RasEapEnd
RasEapInvokeConfigUI
5
2
4
RasEapMakeMessage
RasEapGetIdentity
*RAS
1
RasEapGetInfo
*Remote Access Service

RasEapBegin
EAP Provider
Initialization
Pour une procdure dauthentification particulire, il ne peut donc

exister quun seule instance des fonctions de classe 1. Cependant dans le cas
des cartes puce par exemple, les procdures de classe 2 permettent un
certain degr de libert quant la gestion de composants htrognes.
Linteraction entre systme dexploitation et EAP-Provider seffectue de la
manire suivante,
1) Lors du dmarrage du systme le composant est charg en mmoire.
La mthode RasEapGetInfo initialise cet ensemble, et met jour un jeu de
trois
pointeurs
sur
les
fonctions
RasEapBegin,
RasEapEnd,
RasEapMakeMessage.
2) Ds lors quune interface rseau utilise un protocole EAP un bouton
proprits permet dinvoquer la mthode RasEapInvokeConfigUI qui gre
une interface utilisateur (User Interface), cest dire une boite de dialogue.
3) Lors de la rception du premier message EAP-Request/Identity, le
systme slectionne le composant EAP-Provider correspondant (dduit du
champ EAP-Type). Il active la procdure RasEAPGetIdentity qui retourne la
valeur EAP-ID, incluse dans le message EAP-Response/Identity.
4) La rception dun message EAP-Request/Identity dmarre une
nouvelle session. Cet vnement est associ la mthode RasEapBegin qui
marque le dbut dune nouvelle session dauthentification, gre par un

processus spcifique.
5) Les messages EAP-Request et EAP-Notification sont relays par la
mthode RasEapMakeMessage, qui ralise tout ou une partie dun protocole
dauthentification particulier. Cette procdure re-dirige les paquets vers la
carte EAP laide de la commande EAP-Process. A ce point, il est possible
dutiliser la fonction RasEapInvokeInteractiveUI si lutilisateur doit fournir
des informations supplmentaires.
Aprs rception dun EAP-Notification (Success ou Failure), le systme
dexploitation met fin la session dauthentification grce la mthode
RasEapEnd.
V- Le protocole
RADIUS
1 Introduction
ISP
INTERNET
POP
USER
Le protocole Remote Authentication Dial In User Service est spcifi par la

RFC 2865. La RFC 2866 (RADIUS accounting) dfinit les attributs utiles la
facturation. Les messages sont transports par des paquets UDP, utilisant les
ports 1812 (radius) et 1813 (radacct).
Un fournisseur de service Internet (ISP) ralise/vend un lien entre un
terminal (PC) et son rseau IP. De manire logique le client est connect via
une liaison point point (PPP, ADSL) un intranet (domaine) gr par
lISP, qui loge les serveurs abritant les services (messagerie, site WEB, ) et
offre gnralement des lments de scurit (pare-feu, protection contre les

virus ).
Outre Atlantique le protocole RADIUS a t dvelopp pour la gestion
distante des utilisateurs connectant leur modem un point de prsence
(POP, Point Of Presence) un ensemble de ligne group, install dans un
central tlphonique local et associ un pool de modem. Plutt que de
rpliquer la base donnes client dans chaque POP, il est plus commode
dutiliser un site central.
Le Network Access Server (NAS) gre un pool de modem ou les ports
daccs rseau dans le modle 802.1X. Le NAS met des demandes
dauthentification vers le serveur RADIUS qui possde un lien avec la base
de donnes clients (annuaire LDAP, ODBC, JDBC). Lassociation NAS
server RADIUS est protge laide dun secret partag (le secret RADIUS).
Un serveur RADIUS peut se comporter comme un proxy routant un
message vers un autre serveur; dans ce cas on construit un cercle de
confiance, chaque arc tant scuris par un secret diffrent. Un serveur
proxy ne modifie que les paramtres lis la scurit c'est--dire le champ
Authenticator et lattribut Message-Authenticator.
Lorsque le protocole dauthentification est encapsul par PPP, le NAS
agit comme un pont protocolaire entre PPP et RADIUS ; par contre lorsque
EAP est utilis il ragit comme un rpteur passif des messages EAP.
Une requte dauthentification est transporte par un message accessrequest, laquelle le serveur rpond par lun des trois messages suivant
accept-accept, accept-reject ou access-challenge. Dans ce dernier cas le
serveur dauthentification demande des lments additionnels (rponse un
dfi, ), qui seront dlivrs par dans nouveau paquet access-request.
1.1 RFC utiles
RFC 2865 Remote Authentication Dial In User Service (RADIUS).
RFC 2866 RADIUS Accounting.
RFC 2869 RADIUS Extensions.
RFC 2548 Microsoft Vendor-specific RADIUS Attributes.
RFC 3580, IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) - Usage Guidelines
2 Format des paquets RADIUS

0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Code
Identifier
Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Authenticator
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
2.1 Code
1 Access-Request
2 Access-Accept
3 Access-Reject
4 Accounting-Request
5 Accounting-Response
11 Access-Challenge
2.2 Identifier
Identifiant dune requte et de la rponse associe.
2.3 Length
Longueur totale du paquet en tte incluse ( partir du champ code).
2.4 Authenticator
Un champ de 16 octets. Cest un nombre alatoire dans de la cas dun
message access-request.
Pour les paquets access-accept, access-reject, accept-challenge,

accounting-response cest lempreinte MD5 du message (en tte incluse,
partir de code) concatn aux valeurs RequestAuthenticator et secret
partag.
ResponseAuth =
MD5(Code||ID||Length||RequestAuth||Attributes||Secret)
2.5 Attributes
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
Type
Length
Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- Type, lidentifiant dun attribut (0..255)

- Length, la longueur, champ type inclus (2,255)
- Value, la valeur de lattribut
3 Scurit du protocole RADIUS
La scurit est base sur un mcanisme mot de passe, le secret partag
RADIUS. Cependant les requtes ne sont pas authentifies par une
empreinte MD5, il est donc indispensable dincorporer dans ces messages un
attribut de signature, le Message-Authenticator (#80).
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
Length
String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 80, Length: 18. String: le HMAC-MD527 du message RADIUS, dont

la cl a pour valeur le secret partag RADIUS.
Pour une requte, le calcul est ralis sur le message, avec les valeurs des
16 octets de lattribut codes zro.
27 Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for

Message Authentication", RFC 2104, February 1997.
Dans les autres cas, le calcul est ralis en remplaant le champ

Authenticator par celui de la requte, et les valeurs des 16 octets de lattribut
sont codes zro.
4 Exemple dune requte.
4.1 Access-Request
Lattribut #1 (Name) identifie le compte client associ la requte.
Lattribut #2 (Password) est une valeur chiffre du mot de passe de
lutilisateur. Soit S le secret partag, RA le champ Authenticator, pi le mot de
passe (ventuellement complt par une srie de 0 pour obtenir une
longueur multiple de 16)et ci la valeur chiffre
b1 = MD5(S + RA)
c(1) = p1 xor b1
b2 = MD5(S + c(1))
c(2) = p2 xor b2
bi = MD5(S + c(i-1))
c(i) = pi xor bi
Lattribut #6 (Service) indique le type de service requis (login).

1 Login. The user should be connected to a host.
2 Framed. A Framed Protocol should be started for the User, such as PPP or
SLIP.
3 Callback. Login The user should be disconnected and called back, then
connected to a host.
4 Callback. Framed The user should be disconnected and called back, then a
Framed Protocol should be started for the User, such as PPP or SLIP.
5 Outbound. The user should be granted access to outgoing devices.
6 Administrative. The user should be granted access to the administrative
interface to the NAS from which privileged commands can be executed.
7 NAS Prompt. The user should be provided a command prompt on the NAS
from which non-privileged commands can be executed.
8 Authenticate Only. Only Authentication is requested, and no authorization
information needs to be returned in the Access-Accept (typically used by proxy
servers rather than the NAS itself).
9 Callback. NAS Prompt The user should be disconnected and calledback, then
provided a command prompt on the NAS from which non-privileged commands can
be executed.
10 Call Check. Used by the NAS in an Access-Request packet to indicate that a

call is being received and that the RADIUS server should send back an AccessAccept to answer the call, or an Access-Reject to not accept the call, typically based
on the Called-Station-Id or Calling-Station-Id attributes. It is recommended that
such Access-Requests use the value of Calling-Station-Id as the value of the UserName.
11 Callback Administrative. The user should be disconnected and called back,
then granted access to the administrative interface to the NAS from which
privileged commands can be executed.
Les attributs #30 (Called-Station-id) #31 (Calling-station-id) identifient
respectivement lappel et lappelant.
Lattribut #80 est la signature du message
4.2 Access-Response
Lattribut #27 (Session Timeout) fixe la dure maximale de la session.
Lattribut #80 est la signature du message
5 Exemple dune opration de facturation.
Une opration de facturation est ralise par lchange de messages
Accounting-Request et Accounting-Reponse.
5.1 Access-Request
Lattribut #40 (acct-status-type) prcise la nature de lopration, 1 Start, 2
Stop, 3 Interim-Update, 7 Accounting-On, 8 Accounting-Off.
Les attributs #42 (acct-input-bytes) et #43 (acct-output-bytes) mesurent le
nombre doctets mis et reus.
Lattribut #44 (acct-session-id) est un identifiant de session.
5.2 Access-Response
Lattribut #27 (Session Timeout) fixe la dure maximale de la session.
Lattribut #80 est la signature du message.
6. Le transport du protocole EAP.

Les paquets EAP sont encapsuls par lattribut #79 (EAP-Message). La
taille dun message EAP est limite 253 octets (253+2=255). Un paquet de
taille suprieure 253 est dcoup en une srie dattributs #79.
6.1 Lattribut vendor-specific.
Il permet dintgrer aux messages RADIUS des informations
propritaires. Une compagnie industrielle est identifie par un nombre de 4
octets (6 pour Cisco, 311 pour Microsoft, ).
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
Length
Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont)
String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type 26 for Vendor-Specific.

Vendor-Id, identifiant du vendeur.
6.2 Quelques attributs dcrivant le NAS
Attribut #30, ladresse MAC de la station identifie.
Attribut #31, ladresse MAC du NAS.
Attribut #4 (NAS IP Address), laddresse IP du NAS
Attribut #32 (NAS identifier), un identifiant du NAS.
Attribut #5 (NAS port), le numro du port NAS ralisant lopration.
Attribut #61 (Port Type), le type de LAN gr par le port du AS.
Attribut #12, (Framed MTU), la valeur du Maximum Transmission Unit
la taille du plus grand paquet IP).
Attribut #19 (State), un identifiant optionnel transmis dans les messages
access-challenge et rpt dans la rponse access-request.
Attribut #27 (Session-Timeout), dure maximale dune session.
Attribut #28 (Iddle-Timeout), temps dattente maximale dinactivit

dune station 802.11 (temps de garde associ access-challenge, )
Attribut propritaire Microsoft #16, MS-MPPE-Send-Key, utilis comme
la cl UNICAST par dfaut.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Vendor-Type
| Vendor-Length |
Salt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor Type : 16
Vendor Length : typiquement 52 octets
Salt, un nombre de deux octets, qui doit tre unique dans un paquet
RADIUS. Le bit de poids fort doit tre mis un.
String : le premier octet indique la longueur de la cl (typiquement 32),
les octets suivant sont la valeur de la cl. Ce champ est complt par une
suite de zro (15 typiquement) pour que la longueur soit un multiple de 16.
Ce paramtre est chiffr de la manire suivante :
S le secret RADIUS, R le champ Authenticator du message accessrequest, A la valeur du champ salt, p la valeur en clair de STRING et c sa
valeur chiffre.
b(1) = MD5(S + R + A)
c(1) = p(1) xor b(1)
C = c(1)
b(2) = MD5(S + c(1))
c(2) = p(2) xor b(2)
C = C + c(2)
b(i) = MD5(S + c(i-1))
c(i) = p(i) xor b(i)
C = C + c(i)
Lattribut propritaire Microsoft #17, MS-MPPE-Recv-Key, est utilis cl

de signature dans les trames EAPoL-Key. Son format est similaire celui de
MS-MPPE-Send-Key.
6.3 Scnario dune session dauthentification EAP.
Le NAS transmet le message EAP-Response.identity dans un accessrequest.
Le serveur RADIUS recherche lutilisateur dans la base de donne client.
Il obtient le type du scnario dauthentification (type) et les lettres de crdits
ncessaires (mot de passe, secrets partags, certificats ).
Des paires de messages EAP-Request.type et EAP-Response.type sont

transmis par des paquets RADIUS access-challenge et access-request.
Le succs de lopration est notifi par un access-sucess (et le message
EAP-Sucess). Lchec est indiqu par un access-reject (et le message EAPFailure).
7 Exemple de code C socket.
7.1 Client
char * client(char *req)
{ static char resp[2048] ;
SOCKADDR_IN sin,csin ;
int err,len,namelen
;
int client
;
len =
len |=
req[3] & 0xFF ;

((req[2] << 8) & 0xFF00 );
client = socket (AF_INET,SOCK_DGRAM,0);

csin.sin_family = AF_INET
;
csin.sin_port
= 0 ;
csin.sin_addr.s_addr = INADDR_ANY;
err = bind (client,(LPSOCKADDR) &csin, sizeof (csin));
namelen = sizeof(csin);
err = getsockname(client, (SOCKADDR *)&csin, &namelen);
Printf("Client Port Assigned is %u\n", ntohs(csin.sin_port));
sin.sin_family = AF_INET
;
sin.sin_port = htons(1812) ;
sin.sin_addr.s_addr = inet_addr("127.0.0.1") ;
err= connect(client,(SOCKADDR *)&sin,sizeof(SOCKADDR));
err = send(client,req,len,0);
err = recv(client,resp,sizeof(resp),0);
closesocket(client);
return(resp);
}
7.2 Server
DWORD WINAPI Server_Daemon(LPVOID lpArg)
{ SOCKADDR_IN sin
;
SOCKADDR_IN csin
;
int err,len,lenrad ;
static char buf[2048];
char *resp;
server = socket (AF_INET,SOCK_DGRAM,0);
sin.sin_family = AF_INET
;
sin.sin_port = htons(port) ;
sin.sin_addr.s_addr = 0
;
err = bind ( server,(LPSOCKADDR) &sin, sizeof (sin));
for(;;)
// Waiting for a connection
{
len = sizeof(csin) ;
err =recvfrom(server, buf, sizeof(buf), 0, (LPSOCKADDR)&csin,&len)<0;
if (len <0) break ; // Sortie du serveur
resp= ProcessRadius(buf); // Analyse RADIUS
if (resp != NULL)
{
lenrad =
resp[3] & 0xFF
;
lenrad |= ((resp[2] << 8) & 0xFF00 );
len=sizeof(SOCKADDR);
err= sendto(server,resp,lenrad,0,(SOCKADDR *)&csin,len);
}
}
ExitThread(0xBEBED0D0) ;
return(0);
}
VI- IEEE 802.1X

Port Based Network Access
Control
1. Introduction
EAP
RADIUS
TCP/UDP
IP
EAPOL
MAC 802
EAP over
RADIUS
EAPOL,
EAP pour les
LAN 802
La norme IEEE 802.1X propose un modle de contrle daccs au rseau

bas sur lauthentification des ports.
Un port contrle le flux dinformation (les trames) chang entre un

nud dun rseau et les ressources (services) accessibles depuis ce rseau
local (LAN).
LAuthenticator est une entit qui gre les ports daccs. Chaque port est
associ un Port Access Entity, un lment qui ralise le protocole de
contrle.
Le Supplicant est un nud du rseau local qui dsire accder aux
services offerts par lAuthenticator.
Le Serveur dAuthentification tablit en fonction des lettres de crdit du
Supplicant, ses droits daccs aux ressources gres par lAuthenticator.
2 Principe de fonctionnement
Un port se comporte comme un interrupteur associ deux tats. Dans
ltat unauthorized, seules les trames EAP ne sont pas bloques. Dans ltat
authorized le flux dinformation transite librement. Un port implmente donc
un filtre possdant deux modes de fonctionnement. La procdure
dauthentification est conduite directement entre le Supplicant et le serveur
dauthentification (RADIUS), lAuthenticator jouant dans ce cas le rle dun
relais passif, qui ninterprte pas les donnes protocolaire changes. Le
message RADIUS Access-Accept provoque une transition ltat authorized
du port concern ; le message RADIUS Access-Reject force le port concern
ltat unauthorized. Un port conserve son tat courant durant une session
dauthentification.
3 Mcanismes de gestion des ports.
Lentit Supplicant PAE marque le dbut dune session dauthentification

par une trame EAPoL-Start. Elle indique (optionnellement) la fin dune
session par une trame EAPoL-Logoff.
Lentit Authenticator PAE contrle la dure de ltat Authorized laide la
variable reAuthPeriod dont la valeur par dfaut est 3600s.
En rgle gnral lAuthenticator re-transmet les trames EAP perdues
(toutes les 30s). Cependant le Supplicant re-transmet (toutes les 30s) les
trames EAPoL_Start non acquittes (par un message identity.request).
4 Etat machine du Supplicant PAE

4.1 Etats
LOGOFF,
DISCONNECTED,
CONNECTING,
AUTHENTICATING, HELD, AUTHENTICATED.
ACQUIRED,
4.2 Constantes.
a) authPeriod. Valeur initiale de lhorloge authWhile, soit 30s par dfaut.
b) heldPeriod. Valeur initiale de lhorloge heldWhile soit 60s par dfaut.
c) startPeriod. Valeur initiale de lhorloge startWhen soit 30 s par dfaut.
d) maxStart. Nombre maximum de messages EAPOL-Start infructueux,
soit 3s par dfaut.
4.3 Variables
a) userLogoff, indique labsence dun utilisateur.
b) logoffSent, une trame LOGOFF a t gnre.
c) reqId. Rception dun message EAP Request/Identity.
d) reqAuth. Rception dun EAP Request autre que Request/Identity..
e) eapSuccess. Rception dun message EAP Success.
f) eapFail. Rception dun message EAP Failure packet.
g) startCount. Le nombre maximal de trames EAPOL-Start a t envoy.
h) previousId. Identificateur du dernier message mis.

4.4 Procdures.
a) txStart. Transmission dune trame EAPOL frame.
b) txLogoff. Transmission dune trame EAPOL-Logoff.
c) txRspId(receivedId, previousId). Transmission dun message EAP
Response / Identity. Si receivedId est identique previousId, il sagit dune
re-transmission.
d) txRspAuth(receivedId, previousId). Transmission dun message EAP
Response packet autre que EAP Response/Identity packet. Si receivedId est
identique previousId, il sagit dune re-transmission.
5 Etat machine de lAuthenticator PAE

5.1 Etats
INITIALIZE, DISCONNECTED, CONNECTING, AUTHENTICATING,
AUTHENTICATED, ABORTING, HELD, FORCE_AUTH,
FORCE_UNAUTH
5.2 Variables
a) eapLogoff. Rception dune trameEAPOL-Logoff.
b) eapStart. Rception dune trame EAPOL-Start.
c) portMode. Utilise conjointement avec la variable portControl pour
slectionner un des modes Auto ou non-Auto. Cette variable peut prendre
lune des valeurs suivantes :
1) ForceUnauthorized.
2) ForceAuthorized.
3) Auto. Le port est ltat Authorized or Unauthorized en fonction du
rsultat de la procdure dauthentification
d) reAuthCount. Le nombre de passage ltat CONNECTING. Lorsque
cette valeur est suprieure reAuthMax, le port est forc ltat
Unauthorized.
e) rxRespId. Rceptiondun message EAP Response/Identity.
5.3 Constantes
a) quietPeriod. Valeur dinitialisation (ente 0 et 65535s) de lhorloge
quietWhile timer. La valeur par dfaut est 60s.
b) reAuthMax. Le nombre maximum de re-authentification dun port
avant quil ne passe ltat Unauthorized. La valeur par dfaut est 2.
c) txPeriod. Valeur dinitialisation entre 0 et 65535s) de lhorloge txWhen.
La valeur par dfaut est 30 s.
5.4 Procdures.
a) txCannedFail(x). Transmission dun message EAP Failure, dont
lidentifiant est x.
b) txCannedSuccess(x). Transmission dun message EAP Success packet

dont lidentifiant de x.
c) txReqId(x). Transmission dun message EAP Request/Identity, dont
lidentifiant est x.
VII- La norme IEEE

802.11i
1 Le modle IEEE 802.11i
Un RSN (Robust Security Network) sappuie sur la norme IEEE 802.1X
pour les services dauthentification et de gestion de cls. Le modle 802.11i
prcise la manire dont le modle RSN interagit avec larchitecture 802.1X. Il
existe deux types de protocoles assurant la scurit au niveau MAC,
- Le Temporal Key Integrity Protocol (TKIP), qui utilise lalgorithme RC4
- Le Counter-Mode/CBC-MAC Protocol (CCMP), qui utilise lalgorithme
AES
STA
AP
AS
802.1X EAP Request

802.1X EAP Response
Access Request (EAP Request)
EAP Authentication Protocol Exchange
Accept/EAP-Success/Key Material
802.1X EAP Success
IEEE802.1XPort
Blocked f or STA;
Uncontrolled Port Open
f or EAPOL Messages
Un TSN (Transition Security Network) supporte les architectures

antrieures (c'est--dire pre-RSN), en particulier les mcanismes imports de
la norme IEEE-802.11-1999,
- Open Authentication
- Shared Key Authentication
- Wireless Equivalent Privacy (WEP).
Un rseau RSN doit supporter le protocole CCMP. Cependant un TSN

peut assurer une transition des rseaux de lart antrieur en implmentant
le protocole TKIP (migration de WEP).
- LAuthenticator (AP, le point daccs) et le serveur dauthentification (AS)
ralisent une mutuelle authentification et tablissent un canal scuris. Le
modle 802.11i ne prcise pas les mthodes utilises pour mener bien cette
opration, des protocoles tels que RADIUS, IPSEC ou TLS/SSL pourront
tre mis en uvre.
- Le Supplicant et le serveur dauthentification sauthentifient mutuellement
( laide du protocole EAP) et gnrent une cl matre (Pairwise Master Key
ou PMK). Les matriaux cryptographiques doivent tre diffrents pour
chaque Supplicant.
- La cl PMK (Pairwise Master Key) est partage entre le Supplicant et
lAuthenticator.
- Le Supplicant et lAuthenticator utilisent un protocole quatre passes (4-way
handshake), bas sur les messages EAPOL-Key qui ralise les oprations
suivantes,
- Confirmation de lexistence de la cl PMK.
- Confirmation de la mise en service de la cl PMK.
- Calcul la cl PTK (Pairwise Transient Key) partir de PMK.
- Mise en place des cls de chiffrement et dintgrit des trames
802.11.
- Confirmation de la mise en fonction des cls 802.11.
- La cl GTK (Group Transient Key) transmise, via des paquets EAPoL-Key,
depuis lAuthenticator vers le Supplicant, permet au Supplicant dchanger des
messages en mode de diffusion (broadcas)t , et optionnellement en mode
unicast.
Dans le cas du mode dit Pre Shared Key (PSK), la cl PMK est pre-installe
entre le Supplicant et lAuthenticator.
2 Ngociation de la police de scurit
Le point daccs (AP) indique grce des lments dinformation (IE,
information element) les politiques de scurit quil supporte (CCMP, TKIP,
WEP,). Le Supplicant notifie la politique choisie scurit dans sa requte

dassociation.
STA
AP
IEEE 802.11 Probe Request

IEEE 802.11 Probe Response (Security Parameters)
IEEE 802.11 Open System Authentication Request

IEEE 802.11 Open System Authentication Response
IEEE 802.11 Association Request (Security Parameters)

IEEE 802.11 Association Response (Security Parameters)
APs IEEE 802.1X Port Blocked for

STA; Uncontrolled Port Open for
EAPOL Messages
2.1 Format des RSN Information Element (IE)

Un Access Point indique les politiques de scurit quil supporte en
insrant un RSN IE dans ses trames Beacon ou Probe Response. Le STA
notifie son choix par un IE insr dans sa trame Association Request.
Un Information Element comporte les lments suivants :
Element
ID
Length
Version
Group
Key
Cipher
Suite
Pairwise
Key
Cipher
Suite
Count
Pairwise
Key
Cipher
Suite List
Authenticatio
n and Key
Management
Suite Count
Authenticatio
n and Key
Management
Suite List
RSN
Capabilities
KeyID
Count
KeyID
List
4m
4n
16n
octet
octet
octets
octets
octets
octets
octets
octets
octets
octets
octets
- Element ID 1 octet, 30 hex pour les RSN IE

- Length 1 octet, la longueur totale de lIE
- Version 2 octets, la version du protocole RSN, dans le cas de la version 1
- le STA supporte le mode Open System Authentication
- le STA gre le Privacy Bit de manire similaire WEP
- le STA gre les RSN IE
- le STA supporte le protocole CCMP

- le STA supporte la mise jour des cls via la commande EAPoLKey
Un Suite Selector est un champ de 4 octets, OUI (3 octets) + Suite Type (1
octet), qui indique la disponibilit dun protocole particulier.
OUI 3 octets
Suite Type 1 octet
Suite selector format

OUI
00:00:00
00:00:00
00:00:00
00:00:00
00:00:00
00:00:00
00:00:00
Vendor OUI
Other
Suite Type
Meaning
0
1
2
3
4
5
6-255
Other
Any
Use Group Key cipher suite

WEP-40
TKIP
Reserved deprecated
CCMP default in an RSNA
WEP-104
Reserved
Vendor Specific
Reserved
Cipher Suite Selectors

- Group Key Cipher Suite, 4 octets. Indique le type de chiffrement de
groupe GTK.
- Pairwise Key Cipher Suite Count, 2 octets. Indique le nombre de Cipher
Suite disponibles.
- Pairwise Key Cipher Suite List, 4.m octets, la liste des protocoles de
signature/chiffrement PMK.
- Authenticated Key Management Suite Count, 2 octets
- Authenticated Key Management Suite List, .n octets. La liste des modes
de gestion des cls supports.
-
00 :00 :00 :01, selon la norme 802.1X
00 :00 :00 :02, mode pre-shared-key
- RSN capabilities 2 octets
OUI
Suite
Type
Meaning
Authentication Type
Key Management Type
00:00:00
Reserved
Reserved
00:00:00
Authentication negotiated
over IEEE 802.1X RSNA
default
IEEE 802.1X Key

Management RSNA default
00:00:00
None
IEEE 802.1X Key

Management, using preshared key
00:00:00
3-255
Reserved
Reserved
Vendor
OUI
Any
Vendor Specific
Vendor Specific
Other
Any
Reserved
Reserved
Authentication and Key Management Suite Selectors

2.2 Exemples dlments dinformation.
2.2.1 Exemple 1
802.1X authentication, CCMP pairwise and group key cipher suites (WEP40, WEP-104, and TKIP not allowed).
30, // information element id, 48 expressed as Hex value
14, // length in octets, 20 expressed as Hex value
01 00, // Version 1
00 00 00 04, // CCMP as group key cipher suite
01 00, // pairwise key cipher suite count
00 00 00 04, // CCMP as pairwise key cipher suite
01 00, // authentication count
00 00 00 01 // 802.1X authentication
00 00 // No capabilities
2.2.2 Exemple 2
802.1X authentication, CCMP pairwise and group key cipher suites (WEP40, WEP-104 and TKIP not allowed), Pre-Authentication supported.
01 00, // Version 1
00 00 00 04, // CCMP as group key cipher suite
00 00 00 04, // CCMP as pairwise key cipher suite
01 00 // Pre-authentication capabilities
2.2.3 Exemple 3
802.1X authentication, Use Group key for unicast cipher suite, WEP-40
group key cipher suites, optional RSN Capabilities field omitted.
01 00, // Version 1
00 00 00 01, // WEP-40 as group key cipher suite
00 00 00 00, // Use Group key as pairwise key cipher suite
3 Exchange des cls via EAP

STA
AP
AS
802.1X EAP Request

802.1X EAP Response
Access Request (EAP Request)
EAP Authentication Protocol Exchange
Accept/EAP-Success/Key Material
802.1X EAP Success
IEEE802.1XPort
Blocked f or STA;
Uncontrolled Port Open
f or EAPOL Messages
Une authentification mutuelle est ralise via le protocole EAP entre

Supplicant et Authenticator. Les deux extrmits calculent la cl PMK. Cette
dernire est transmise lAuthenticator laide de lattribut MS-MPPE du
protocole RADIUS. LAuthenticator notifie au Supplicant le succs de
lopration dauthentification.
4-Way Handshake, Pairwise Transient Key
STA
AP
Key (PMK) is Known

Derive SNonce
Key (PMK) is Known

Derive ANonce
Message 1:EAPOL-Key (ANonce, Unicast)

Derive PTK
Message 2: EAPOL-Key(SNonce,Unicast,MIC,STA)
Derive PTK
Message 3: EAPOL-Key(Install PTK, MIC,Unicast, GTK)
Message 4: EAPOL-Key(Unicast,ANonce,MIC)
Install PTK and GTK
Install PTK
IEEE 802.1X Port Un-Blocked for

STA Data Traffic
La station et le point daccs partagent une cl secrte PMK. Une cl PTK

est calcule laide de deux nombres alatoires ANonce, SNonce, de la cl
PMK, et des adresses MAC de STA et AP.
PTK = PRF-X(PMK, "Pairwise key expansion", Min(AA,SA) ||
Max(AA,SA) || Min(ANonce, SNonce) || Max(ANonce, SNonce) )
AA = Authenticator Address
SA = Station Address
PRF-X(K,A,B)= Pseudo Random Function, cette fonction retourne, selon
les besoins, X bits (X=128, 192, 256, 384 ou 512 bits)
4.1 La fonction PRF.
/* * PRF -- Length of output is in octets rather than bits
* since length is always a multiple of 8 output array is
* organized so first N octets starting from 0 contains PRF output
* supported inputs are 16, 32, 48, 64
* output array must be 80 octets to allow for sha1 overflow
*/
void PRF(
unsigned char *key, int key_len,
unsigned char *prefix, int prefix_len,
unsigned char *data, int data_len,
unsigned char *output, int len)
{
int i;
unsigned char input[1024]; /* concatenated input */
int currentindex = 0;
int total_len;
memcpy(input, prefix, prefix_len);
input[prefix_len] = 0; /* single octet 0 */
memcpy(&input[prefix_len+1], data, data_len);
total_len = prefix_len + 1 + data_len;
input[total_len] = 0; /* single octet count, starts at 0 */
total_len++;
for(i = 0; i < (len+19)/20; i++) {
hmac_sha1(input, total_len, key, key_len,
&output[currentindex]);
currentindex += 20; /* next concatenation location */
input[total_len-1]++; /* increment octet count */
}
}
5 Echange de la cl GTK (Groupe Transient Key)

GMK = Group Master Key
GTK = PRF-X(GMK, "Group key expansion", AA || Gnonce)
AA = Authenticator Address
PRF-X(K,A,B)= Pseudo Random Function, une fonction retournant, selon les
besoins, X bits (X=128, 192, 256, 384 ou 512 bits)
La cl GTK est transmise chiffre laide de la cl EK.
STA
AP
Generate GTK
Encrypt GTK with PTK
Message 1: EAPOL-Key(Encrypted GTK, Group, MIC)

Install GTK
Message 2: EAPOL-Key(Group, MIC)
6 La hirarchie des cls

6.1 Pairwise Transient Key
Pairwise Master Key (PMK)
PRF-X(PMK, Pairwise key expansion,

Min(AA,SA) || Max(AA,SA) ||
Min(ANonce,SNonce) ||
Max(ANonce,SNonce))
Pairwise Transient Key (PTK)

(X bits)
EAPOL-Key
Key
Confirmation
Key
L(PTK,0,128)
(KCK)
EAPOL-Key
Key Encryption
Key
L(PTK,128,128)
(KEK)
Temporal Key
TKIP: L(PTK,256,256)
CCMP: L(PTK,256,128)
(TK)
La fonction PRF gnre 384 ou 512 bits selon le protocole slectionn.

La cl TK est utilise par TKIP et CCMP.
KCK (128 bits) est la cl de signature utilise pour gnrer la signature (MIC)
des messages EAPoL-Key.
KEK (128 bits) est la cl de chiffrement pour la transmission de GTK.
* L(Byte_Array, Length, Offset) retourne Length bits extraits de Byte_Array
partir de Offset.
6.2 Les messages EAPoL-Keys
Descriptor Type 1 octet

Key Information 2 octets
Key Length 2 octets
Key Replay Counter 8 octets

Key Nonce 32 octets
EAPOL-Key IV 16 octets
Key RSC 8 octets
Reserved 8 octets
Key MIC 16 octets
Key Data Length 2 octets
Key Data n octets
Descriptor Type (1 octets), 254 (dcimal) pour un RSN Key Descriptor

Key Information (2 octets)
3 bits Key
Descriptor
Version
b0
1 bit
Key
Type
b2
b3
2 bits
Reserved
b4 b5
1 bit
Install
b6
1bit
Key
Ack
b7
1 bit
Key
MIC
1 bit
Secure
1 bit
Error
b8
b9
b10
1 bit
Request
1 bit
Encrypted
Key Data
b11
b12
3 bits
Reserved
b13
b15
- Key Descriptor Version,

1- le MIC utilise HMAC-MD5, et un chiffrement RC4 pour la
distribution de GTK (RFCs 2104 et 1321)
2- le MIC utilise HMAC-SHA1, chiffrement AES-CBC-MAC pour la
distribution de GTK (HMAC est dfinie dans la RFC 2104).
- Key Type, 0- GTK, 1- PMK
- 2 bits Reserved,
- Install bit, Pour PMK, 1= installation des cls ; pour GTK, 0= cl pour
rception seulement, 1=cl valide pour transmission et rception.
- Ack bit, demande de rponse.
- MIC bit, indique la prsence dun MIC
- Secure bit, indique que le Handshake est termin, les cls sont
oprationnelles.
- Error bit, notification dune erreur
- Request bit, le Supplicant positionne ce bit afin que lAuthenticator
lance un Handshake.
- Encrypted Key Data, ce bit est positionn si la cl doit tre utilis pour
scuriser les changes. Usuellement ce paramtre vaut zro.
- Reserved bits, toujours 0.
Key Length
La longueur du message exprime en octet.
Cipher Suite
CCMP
TKIP
WEP-40
WEP-104
Key Length
16
32
13
Key Replay Counter (8 octets).

Numro de squence dun message EAPoL-Key.
Key Nonce
Nombre alatoire de 32 octets
Key IV
La valeur IV (16 octets) utilise avec le chiffrement de la cl GTK.
Key RSC
Ce champ de 8 octets contient la valeur du Receive Sequence Counter
(RSC). Loctet de poids faible de IV est le premier octet de RSC. Dans le cas
de TKIP le champ TSC (Transmit Sequence Counter) est gal aux 6 premiers
octets de RSC.
KeyRSC 0
KeyRSC 1
KeyRSC 2
KeyRSC 3
KeyRSC 4
KeyRSC 5
KeyRSC 6
TSC0
TSC1
TSC2
TSC3
TSC4
TSC5
PN0
PN1
PN2
PN3
PN4
PN5
Key ID
Ce champ de 8 octets est rserv et cod zro.
Key MIC
Le Message Integrity Code, une valeur de 16 octets, telles que spcifie
dans le Key Descriptor Version.
Key Data Length
Ce champ de 2 octets indique la valeur du paramtre Key Data.
Key Data.
KeyRSC 7
Ce champ transporte le RSN IE dans les messages 2 et 3 du 4-way

handshake. Dans le cas dun 2-way handshake (distribution de GTK) il contient
la valeur chiffre de GTK.
6.3 Notation des messages EAPoL-Key
EAPOL-Key(S, M, A, I, K, KeyRSC, ANonce/SNonce, MIC, RSN IE, GTK[N])
- S : le bit Secure, indique que la fin de lchange des cls.
- M : Prsence dun MIC dans le message.
- A : le bit ACK, le destinataire du message doit rpondre.
- I: Install bit, notifie linstallation dune cl PMK ou lusage dune cl
GTK.
- K : Key Type bit, P(Pairwise) ou G(Group)
- KeyRSC, le champ KeyRSC, la valeur du compteur TSC dans le cas de
TKIP.
- ANonce/SNonce, la valeur du champ Key Nonce.
- MIC, la valeur du Message Integrity Code
- RSN IE, le champ RSN IE
- GTK, le champ Data. Cest la valeur chiffre dune cl GTK.
6.3 Illustration dune procdure de four way handshake
Message 1. Authenticator Supplicant:
EAPOL-Key(0,0,1,0,P,0,ANonce,0,0,0)
Message 2. Supplicant Authenticator:
EAPOL-Key(0,1,0,0,P,0,SNonce,MIC,RSNIE,0)
Message 3. Authenticator Supplicant:
EAPOL-Key(1,1,1,1,P,KeyRSC,ANonce,MIC,RSN IE,GTK[N])
Message 4. Supplicant Authenticator:
EAPOL-Key(1,1,0,0,P,0,0,MIC,0,0)
6.4 Exemple dinstallation de cl GTK

Message 1: Authenticator Supplicant:
EAPOL-Key(1,1,1,0,G,Key RSC,0, MIC, 0,GTK[N])
Message 2: Supplicant Authenticator:
EAPOL-Key(1,1,0,0,G,0,0,MIC,0,0)
7 Un aperu du protocole TKIP

7.1 La trame TKIP
Encrypted (note)
MAC
Header
TSC1
Extended IV
4 octets
IV / KeyID
4 octets
WEPSeed
[1]
Expanded IV16
Ext
IV
Rsvd
TSC0
b4
b0
MIC
8 octets
Data >= 1 octets
Key
ID
b5 b6
TSC2
TSC3
b7
TSC4
ICV
4 octets
TSC5
IV32
Note: The encapsulation process has expanded the original MPDU size by 20 octets, 4 for the Initialization vector (IV) / Key ID
field, 4 for the extended IV field, 8 for the Message Integrity Code (MIC) and 4 for the Integrity Check Value (ICV).
- TSC, Transmit Sequence Counter = IV32+IV16 (48 bits)

- Rsvd, toujours zro
- Ext-IV; toujours un
- Key-ID: 00
- MIC: Message Integrity Control, utilise lalgorithme de Michael
7.2 Le chiffrement TKIP
Temporal
Key
TA
Phase 1
key mixing
Phase 2
key mixing
TTAK
TSC
WEP seed(s)
(represented as
WEP IV + RC4
key)
MIC Key
DA + SA + priority
+ Plaintext MSDU
Data
Plaintext
MSDU +
MIC
Michael
Fragment(s
)
Plaintext
MPDU(s)
WEP
Encapsulation
- TA; Transmitter Address.

- TTAK, TKIP mixed Transmit Address and Key.
- TSC, Transmit Sequence Counter.
- MIC, Message Integrity Code.
- MSDU, MAC Service Data Unit.
Ciphertext
MPDU(s)
- MPDU, MAC Protocol Data Unit.

8 Un aperu du protocole CCMP
8.1 La trame CCMP
Encrypted
CCMP Header
8 octets
MAC Header
PN0
PN1
Rsvd
Ext
IV
Rsvd
b0
b4
b5
Data (PDU)
>= 1 octets
Key
ID
b6
PN2
PN3
b7
- PN : Packet Number (48 bits)

- Rsvd, toujours zro
- Ext-IV; toujours un
- Key-ID : 00
- MIC : Message Integrity Control
PN4
PN5
MIC
8 octets
8.2 Le chiffrement CCMP
- PN : Packet Number
- DLEN : Data Length
- MPDU: MAC Protocol Data Unit
- TA: Transmitter Address
VIII- WPA - Wi-Fi

Protected Access
1. Introduction
WPA est un standard proche de IEEE 802.11i, mais cependant les deux
normes prsentent des diffrences significatives. Le protocole par dfaut de
WPA est TKIP et non CCMP.
2 Comparaison WPA RSN IE et IEEE 802.11i RSN IE
2.1 802.11i, RSN IE
Cipher Suite OUI = 00:00:00
ID=48
Length
PMK count
Version
Group Key Cipher Suite
Pairwise Key Cipher
Auth. Count
Suite
Auth Key Mgmt Suite List
RSN capabilities
2.2 WPA, RSN IE

Cipher Suite OUI = 00:50:F2
ID=221
Length
Group Key Cipher Suite
Pairwise Key
Cipher Suite (cont)
RSN capabilities
OUI 00:50:F2:01
PMK Count
Auth. Count
Version
Pairwise Key Cipher
Suite
Auth. Key Mgmt Suite List
IX- Une trace CHAP

avec PPP
Frame 7 (32 bytes on wire, 32 bytes captured)
Type: PPP Link Control Protocol (0xc021)
PPP Link Control Protocol
Code: Identification (0x0c)
Identifier: 0x03
Length: 18
Magic number: 0x1b84708a
Message (10 bytes)
0000
0010
20 53 45 4e 44 02 20 53 45 4e 44 02 c0 21 0c 03
00 12 1b 84 70 8a 4d 53 52 41 53 56 35 2e 31 30
SEND. SEND..!..
....p.MSRASV5.10

Type: PPP Link Control Protocol (0xc021)
PPP Link Control Protocol
Code: Identification (0x0c)
Identifier: 0x04
Length: 27
Magic number: 0x1b84708a
Message (19 bytes)
0000
0010
0020
20 53 45 4e 44 02 20 53 45 4e 44 02 c0 21 0c 04
00 1b 1b 84 70 8a 4d 53 52 41 53 2d 30 2d 50 41
53 43 41 4c 55 52 49 45 4e
SEND. SEND..!..
....p.MSRAS-0-PA
SCALURIEN

Type: Unknown (0xc223)
PPP Challenge Handshake Authentication Protocol
Code: Challenge (0x01)
Identifier: 0x7a
Length: 29
Data (25 bytes)
Value Size: 16 bytes
Value (16 bytes)
Name (8 bytes)
0000
0010
0020
20 52 45 43 56 02 20 52 45 43 56 02 c2 23 01 7a
00 1d 10 45 41 9a 49 11 79 e2 c4 f1 86 5d 3a c7
fb 66 e1 73 74 61 63 6b 73 74 67
RECV. RECV..#.z
...EA.I.y....]:.
.f.stackstg

Code: Response (0x02)
Identifier: 0x7a
Length: 38
Data (34 bytes)
Value Size: 16 bytes
Value (16 bytes)
Name (17 bytes)
0000
0010
0020
0030
20
00
81
66
53
26
df
2e
45
10
f9
66
4e 44 02 20 53 45 4e 44 02 c2 23 02 7a
6b b6 65 8e 71 a5 39 23 a0 fe 30 45 b5
31 32 33 34 35 36 37 38 40 6c 73 75 72
72
SEND. SEND..#.z
.&.k.e.q.9#..0E.
...12345678@lsur
f.fr

Code: Success (0x03)
Identifier: 0x7a
Length: 4
0000
0010
20 52 45 43 56 02 20 52 45 43 56 02 c2 23 03 7a
00 04
RECV. RECV..#.z
..
X- Une trace EAPoL

Ethernet II, Src: 00:40:00:09:5b:4c, Dst: 00:09:5b:4c:35:fc
Destination: 00:09:5b:4c:35:fc (Netgear_4c:35:fc)
Source: 00:40:00:09:5b:4c (PciCompo_09:5b:4c)
Type: 802.1X Authentication (0x888e)
802.1x Authentication
Version: 1
Type: EAP Packet (0)
Length: 51
Extensible Authentication Protocol
Code: Request (1)
Id: 5
Length: 51
Type: Identity [RFC2284] (1)
Identity (46 bytes): networkid=Ucopia2,nasid=AP350577748,portid=0
0000
0010
0020
0030
0040
00
00
64
41
74
09
33
3d
50
69
5b
01
55
33
64
4c
05
63
35
3d
35
00
6f
30
30
fc
33
70
2d
00
01
69
35
40
00
61
37
00
6e
32
37
09
65
2c
37
5b
74
6e
34
4c
77
61
38
88
6f
73
2c
8e
72
69
70
01
6b
64
6f
00
69
3d
72
..[L5..@..[L....
.3...3..networki
d=Ucopia2,nasid=
AP350-577748,por
tid=0

Ethernet II, Src: 00:09:5b:4c:35:fc, Dst: 00:40:96:57:77:48
Destination: 00:40:96:57:77:48 (Ciron_57:77:48)
Source: 00:09:5b:4c:35:fc (Netgear_4c:35:fc)
Version: 1
Length: 9
Code: Response (2)
Id: 5
Length: 9
Identity (4 bytes): marc
0000
0010
00 40 96 57 77 48 00 09 5b 4c 35 fc 88 8e 01 00
00 09 02 05 00 09 01 6d 61 72 63
.@.WwH..[L5.....
.......marc

Version: 1
Length: 26
Code: Request (1)
Id: 3
Length: 26
Type: ?? RESERVED ?? (7)
Type-Data (21 bytes) Value: 1483D972D101F40973DEC8E32068B1DE...
0000
0010
0020
00 09 5b 4c 35 fc 00 40 00 09 5b 4c 88 8e 01 00
00 1a 01 03 00 1a 07 14 83 d9 72 d1 01 f4 09 73
de c8 e3 20 68 b1 de 58 16 41 ea 76
..[L5..@..[L....
..........r....s
... h..X.A.v

Ethernet II, Src: 00:09:5b:4c:35:fc, Dst: 00:40:96:57:77:48
Destination: 00:40:96:57:77:48 (Ciron_57:77:48)
Source: 00:09:5b:4c:35:fc (Netgear_4c:35:fc)
Version: 1
Length: 26
Code: Response (2)
Id: 3
Length: 26
Type-Data (21 bytes) Value: 14BA14A809C8B0D30E55DAD38A0093E2...
0000
0010
0020
00 40 96 57 77 48 00 09 5b 4c 35 fc 88 8e 01 00
00 1a 02 03 00 1a 07 14 ba 14 a8 09 c8 b0 d3 0e
55 da d3 8a 00 93 e2 a4 80 bd de 3b
.@.WwH..[L5.....
................
U..........;

Version: 1
Length: 4
Code: Success (3)
Id: 4
Length: 4
0000 00 09 5b 4c 35 fc 00 40 00 09 5b 4c 88 8e 01 00
..[L5..@..[L....
0010 00 04 03 04 00 04

Version: 1
Type: Key (3)
Length: 49
Descriptor Type: RC4 Descriptor (1)
Key Length: 5
Replay Counter: 7318349497237533
Key IV: 69665AC4714362114CD2564936BF6734
Key Index: broadcast, index 0
0... .... = Key Type: Broadcast
.000 0000 = Index Number: 0
Key Signature: 2AACA0DE2C9DBDD6F2ED4ECAC076077D
Key: D1989260DE
0000
0010
0020
0030
0040
00
00
c4
a0
92
09
31
71
de
60
5b
01
43
2c
de
4c
00
62
9d
35
05
11
bd
fc
00
4c
d6
00
1a
d2
f2
40
00
56
ed
00
00
49
4e
09
06
36
ca
5b
20
bf
c0
4c
00
67
76
88
1d
34
07
8e
69
00
7d
01
66
2a
d1
03
5a
ac
98
..[L5..@..[L....
.1........ ..ifZ
.qCb.L.VI6.g4.*.
..,.....N..v.}..
.`.
XI- Une trace RADIUS

Ethernet II, Src: 00:40:96:57:77:48, Dst: 00:08:02:66:51:ba
Internet Protocol, Src Addr: 192.168.200.199 (192.168.200.199), Dst Addr:
User Datagram Protocol, Src Port: 1062 (1062), Dst Port: radius (1812)
Radius Protocol
Code: Access Request (1)
Packet identifier: 0x26 (38)
Length: 147
Authenticator
Attribute value pairs
t:User Name(1) l:6, Value:"marc"
t:Vendor Specific(26) l:20, Vendor:Cisco(9)
t:Cisco AV Pair(1) l:14, Value:"ssid=Ucopia2"
t:NAS IP Address(4) l:6, Value:192.168.200.199
t:Called Station Id(30) l:14, Value:"004096577748"
t:Calling Station Id(31) l:14, Value:"00095b4c35fc"
t:NAS identifier(32) l:14, Value:"AP350-577748"
t:NAS Port(5) l:6, Value:37
t:Framed MTU(12) l:6, Value:1400
t:NAS Port Type(61) l:6, Value:Wireless IEEE 802.11(19)
t:Service Type(6) l:6, Value:Authenticate Only(8)
t:EAP Message(79) l:11
Code: Response (2)
Id: 5
Length: 9
Identity (4 bytes): marc
t:Message Authenticator(80) l:18,
Value:5617D6C8FF51C65C58C98092ECABD7CC
0000
0010
0020
0030
0040
0050
0060
0070
0080
0090
00a0
00b0
00
00
c8
74
6d
3d
30
30
30
00
4f
c8
08
af
64
e3
61
55
30
39
2d
00
0b
ff
02
21
04
54
72
63
34
35
35
05
02
51
66
14
26
e0
63
6f
30
62
37
78
05
c6
51
00
07
c1
1a
70
39
34
37
3d
00
5c
ba
00
14
05
14
69
36
63
37
06
09
58
00
40
00
7c
00
61
35
33
34
00
01
c9
40
11
9b
a2
00
32
37
35
38
00
6d
80
96
46
7d
ea
00
04
37
66
05
00
61
92
57
ad
b6
5d
09
06
37
63
06
13
72
ec
77
c0
01
13
01
c0
34
20
00
06
63
ab
48
a8
26
a6
0e
a8
38
0e
00
06
50
d7
08
c8
00
89
73
c8
1f
41
00
00
12
cc
00
c7
93
71
73
c7
0e
50
25
00
56
45
c0
ce
01
69
1e
30
33
0c
00
17
00
a8
d8
06
64
0e
30
35
06
08
d6
...fQ..@.WwH..E.
..!...@.F.......
.d.&....}..&....
t.T...|..]...q..
marc........ssid
=Ucopia2........
004096577748..00
095b4c35fc .AP35
0-577748.....%..
...x=...........
O......marcP.V..
..Q.\X.......

Ethernet II, Src: 00:08:02:66:51:ba, Dst: 00:40:96:57:77:48
192.168.200.199 (192.168.200.199)
User Datagram Protocol, Src Port: radius (1812), Dst Port: 1062 (1062)
Radius Protocol
Code: Access challenge (11)
Length: 116
Authenticator
t:Session Timeout(27) l:6, Value:60
t:Idle Timeout(28) l:6, Value:20
Code: Request (1)
Id: 3
Length: 26
Type-Data (21 bytes) Value:
1483D972D101F40973DEC8E32068B1DE...
Value:03AF202CDDBD5FA10B0BC9539EEA800A
t:State(24) l:38,
Value:ACBFAF9BF34A77ACC66E2B77F58F531349D0C62459687280985E75D43F5F5DB8C39
AE157
0000
0010
0020
0030
0040
0050
0060
0070
0080
0090
00
00
c8
3e
00
07
de
0b
77
72
40
90
c7
da
00
14
58
0b
ac
80
96
f8
07
17
00
83
16
c9
c6
98
57
1d
14
8f
3c
d9
41
53
6e
5e
77
00
04
1e
1c
72
ea
9e
2b
75
48
00
26
d3
06
d1
76
ea
77
d4
00
80
00
e0
00
01
50
80
f5
3f
08
11
7c
37
00
f4
12
0a
8f
5f
02
2f
d4
17
00
09
03
18
53
5d
66
c2
f4
d1
14
73
af
26
13
b8
51
c0
0b
91
4f
de
20
ac
49
c3
ba
a8
26
ff
1c
c8
2c
bf
d0
9a
08
c8
00
97
01
e3
dd
af
c6
e1
00
64
74
bc
03
20
bd
9b
24
57
45
c0
e4
1b
00
68
5f
f3
59
00
a8
88
06
1a
b1
a1
4a
68
.@.WwH...fQ...E.
......../....d..
.....&.|...&.t..
>......7........
...<......O.....
....r....s... h.
.X.A.vP... ,.._.
...S.....&.....J
w..n+w..S.I..$Yh
r..^u.?_]....W

Src Addr: 192.168.200.199 (192.168.200.199), Dst Addr: 192.168.200.100
Radius Protocol
Length: 202
Authenticator
t:User Name(1) l:6, Value:"marc"
t:Vendor Specific(26) l:20, Vendor:Cisco(9)
t:Cisco AV Pair(1) l:14, Value:"ssid=Ucopia2"
t:NAS IP Address(4) l:6, Value:192.168.200.199
t:Calling Station Id(31) l:14, Value:"00095b4c35fc"
t:NAS identifier(32) l:14, Value:"AP350-577748"
t:NAS Port(5) l:6, Value:37
t:Framed MTU(12) l:6, Value:1400
t:State(24) l:38,
Value:ACBFAF9BF34A77ACC66E2B77F58F531349D0C62459687280985E75D43F5F5DB8C39
AE157
t:NAS Port Type(61) l:6, Value:Wireless IEEE 802.11(19)
t:Service Type(6) l:6, Value:Authenticate Only(8)
Code: Response (2)
Id: 3
Length: 26
Type-Data (21 bytes) Value:
14BA14A809C8B0D30E55DAD38A0093E2...
Value:870F1411453D54B203D5FF4E5906D450
0000
0010
0020
0030
0040
0050
0060
0070
0080
0090
00a0
00b0
00c0
00d0
00e0
00f0
00
00
c8
0d
6d
3d
30
30
30
00
2b
75
06
a8
de
59
08
e6
64
86
61
55
30
39
2d
00
77
d4
06
09
3b
06
02
21
04
13
72
63
34
35
35
05
f5
3f
00
c8
50
d4
66
15
27
83
63
6f
30
62
37
78
8f
5f
00
b0
12
50
51
00
07
7c
1a
70
39
34
37
18
53
5d
00
d3
87
ba
00
14
a1
14
69
36
63
37
26
13
b8
08
0e
0f
00
40
00
ed
00
61
35
33
34
ac
49
c3
4f
55
14
40
11
d2
d1
00
32
37
35
38
bf
d0
9a
1c
da
11
96
46
37
17
00
04
37
66
05
af
c6
e1
02
d3
45
57
75
3d
f1
09
06
37
63
06
9b
24
57
03
8a
3d
77
c0
01
b3
01
c0
34
20
00
f3
59
3d
00
00
54
48
a8
27
3b
0e
a8
38
0e
00
4a
68
06
1a
93
b2
08
c8
00
8a
73
c8
1f
41
00
77
72
00
07
e2
03
00
c7
ca
17
73
c7
0e
50
25
ac
80
00
14
a4
d5
45
c0
92
01
69
1e
30
33
0c
c6
98
00
ba
80
ff
00
a8
28
06
64
0e
30
35
06
6e
5e
13
14
bd
4e
...fQ..@.WwH..E.
..!...@.Fu......
.d.'....7=.'...(
....|......;....
marc........ssid
=Ucopia2........
004096577748..00
095b4c35fc .AP35
0-577748.....%..
...x.&.....Jw..n
+w..S.I..$Yhr..^
u.?_]....W=.....
......O.........
......U.........
.;P.....E=T....N
Y..P

Ethernet II, Src: 00:08:02:66:51:ba, Dst: 00:40:96:57:77:48
192.168.200.199 (192.168.200.199)
Source port: radius (1812)
Destination port: 1063 (1063)
Length: 174
Checksum: 0x0689 (correct)
Radius Protocol
Code: Access Accept (2)
Length: 166
Authenticator
Code: Success (3)
Id: 4
Length: 4
t:Vendor Specific(26) l:58, Vendor:Microsoft(311)
t:MS MPPE Send Key(16) l:52,
Value:ECA42F8C202DEA0C24AB6AA395EBCB4A5A93B1DDDCA0CBA95F6D3C74ABFFDE9283C
B19E34A9646985B99371D458D39CB99BE
t:Vendor Specific(26) l:58, Vendor:Microsoft(311)
t:MS MPPE Recv Key(17) l:52,
Value:9569A3980A08CB97C0AE4497B86D2FC33FADF0D2E8F149C52643EC631E6FBAF81B9
EFB5223FF049C7D38A586AB6F5DF09A68
Value:4EF2643B9A6E786EB21DD940F35589E6
0000
0010
0020
0030
0040
0050
0060
0070
0080
0090
00a0
00b0
00c0
00
00
c8
cb
00
10
cb
de
39
0a
e8
23
4e
40
c2
c7
45
00
34
4a
92
cb
08
f1
ff
f2
96
f8
07
b5
00
ec
5a
83
99
cb
49
04
64
57
44
14
bf
3c
a4
93
cb
be
97
c5
9c
3b
77
00
04
1f
4f
2f
b1
19
1a
c0
26
7d
9a
48
00
27
68
06
8c
dd
e3
3a
ae
43
38
6e
00
80
00
1c
03
20
dc
4a
00
44
ec
a5
78
08
11
ae
da
04
2d
a0
96
00
97
63
86
6e
02
2f
06
47
00
ea
cb
46
01
b8
1e
ab
b2
66
69
89
0f
04
0c
a9
98
37
6d
6f
6f
1d
51
c0
02
a7
1a
24
5f
5b
11
2f
ba
5d
d9
ba
a8
27
fe
3a
ab
6d
99
34
c3
f8
f0
40
08
c8
00
0d
00
6a
3c
37
95
3f
1b
9a
f3
00
64
a6
ab
00
a3
74
1d
69
ad
9e
68
55
45
c0
1a
1b
01
95
ab
45
a3
f0
fb
50
89
00
a8
f2
06
37
eb
ff
8d
98
d2
52
12
e6
.@.WwH...fQ...E.
...D..../i...d..
.....'.....'....
.E...h..G.......
...<O......:...7
.4../. -..$.j...
.JZ......._m<t..
......J.F.[.7.E.
9....:...7.4.i..
......D..m/.?...
..I.&C.c.o.....R
#...}8...o]..hP.
N.d;.nxn...@.U..
Exemple de facturation
Ethernet II, Src: 00:50:ba:b9:2d:df, Dst: 00:30:bd:61:ee:24
192.168.0.140 (192.168.0.140)
Radius Protocol
Length: 118
Authenticator: 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13
t:User Name(1) l:8, Value:"urienp"
t:User Password(2) l:18, Value: 0e 84 ed 60 51 d5 78 89
39 47 0b 14 8e 13 7c 05
t:Calling Station Id(31) l:10, Value:"62750114"
t:Service Type(6) l:6, Value:Login(1)
t:Framed IP Address(8) l:6, Value:255.1.2.3
t:Acct Input Octets(42) l:6, Value:100
t:Acct Output Octets(43) l:6, Value:1000
t:Acct Session Id(44) l:10, Value:"idurienp"
Value:E74D5CDDF18088FD0760C7EC73BBBC44
0000
0010
0020
0030
0040
0050
0060
0070
0080
0090
00
00
00
06
75
39
31
00
00
e7
30
92
8c
07
72
47
35
01
00
4d
bd
01
0b
08
69
0b
1f
08
03
5c
61
8f
cf
09
65
14
0a
06
e8
dd
ee
00
07
0a
6e
8e
36
ff
2c
f1
24
00
14
0b
70
13
32
01
0a
80
00
80
00
0c
02
7c
37
02
69
88
50
11
7e
0d
12
05
35
03
64
fd
ba
b6
7c
0e
0e
1e
30
2a
75
07
b9
ee
5e
0f
84
0a
31
06
72
60
2d
c0
01
10
ed
38
31
00
69
c7
df
a8
01
11
60
34
34
00
65
ec
08
00
00
12
51
30
06
00
6e
73
00
01
76
13
d5
39
06
64
70
bb
45
c0
04
01
78
30
00
2b
50
bc
00
a8
05
08
89
32
00
06
12
44
.0.a.$.P..-...E.
................
.......~|^...v..
................
urienp.....`Q.x.
9G....|...840902
15..62750114....
........*....d+.
....,.idurienpP.
.M\......`..s..D

Ethernet II, Src: 00:30:bd:61:ee:24, Dst: 00:50:ba:b9:2d:df
192.168.0.1 (192.168.0.1)
Radius Protocol
Code: Access Accept (2)
Length: 44
Authenticator: 35 6b b6 ea d8 2e 51 c2 f1 03 a0 11 00 0b f0 12

Value:2CB6E360EF71F768B339CEAEEEFFC8FA
0000
0010
0020
0030
0040
0050
00
00
00
b6
00
ce
50
48
01
ea
03
ae
ba
06
07
d8
09
ee
b9
29
14
2e
e4
ff
2d
00
0b
51
50
c8
df
00
cf
c2
12
fa
00
80
00
f1
2c
30
11
34
03
b6
bd
b2
2b
a0
e3
61
9e
48
11
60
ee
c0
02
00
ef
24
a8
01
0b
71
08
00
00
f0
f7
00
8c
2c
12
68
45
c0
35
1b
b3
00
a8
6b
06
39
.P..-..0.a.$..E.
.H.)............
.......4+H...,5k
....Q...........
....P.,..`.q.h.9
......
RADIUS, Dbut de facturation

192.168.0.140 (192.168.0.140)
User Datagram Protocol, Src Port: 3023 (3023), Dst Port: radacct (1813)
Radius Protocol
Code: Accounting Request (4)
Length: 106
t:Acct Status Type(40) l:6, Value:Start(1)
Value:8D975E9CEA54F1A5B0CC6329A9574CF7
0000
0010
0020
0030
0040
0050
0060
0070
0080
0090
00
00
00
06
75
1f
06
00
6e
a9
30
86
8c
07
72
0a
06
64
70
57
bd
01
0b
08
69
36
00
2b
50
4c
61
90
cf
09
65
32
00
06
12
f7
ee
00
07
0a
6e
37
00
00
8d
24
00
15
0b
70
35
01
00
97
00
80
00
0c
1e
30
08
03
5e
50
11
72
0d
0a
31
06
e8
9c
ba
b6
53
0e
38
31
ff
2c
ea
b9
f9
c8
0f
34
34
01
0a
54
2d
c0
04
10
30
28
02
69
f1
df
a8
01
11
39
06
03
64
a5
08
00
00
12
30
00
2a
75
b0
00
01
6a
13
32
00
06
72
cc
45
c0
04
01
31
00
00
69
63
00
a8
05
08
35
01
00
65
29
.0.a.$.P..-...E.
................
.......rS....j..
................
urienp..84090215
..62750114(.....
............*...
.d+.....,.idurie
npP...^..T....c)
.WL.


192.168.0.1 (192.168.0.1)
User Datagram Protocol, Src Port: radacct (1813), Dst Port: 3023 (3023)
Radius Protocol
Code: Accounting Response (5)
Length: 20
Authenticator: b3 d2 7a 50 30 d2 2a c6 dc 41 2f a1 6e bc c0 17
0000
0010
0020
0030
00
00
00
7a
50
30
01
50
ba
06
07
30
b9
2a
15
d2
2d
00
0b
2a
df
00
cf
c6
00
80
00
dc
30
11
1c
41
bd
b2
a1
2f
61
b5
6c
a1
ee
c0
05
6e
24
a8
01
bc
08
00
00
c0
00 45 00
8c c0 a8
14 b3 d2
17
.P..-..0.a.$..E.
.0.*............
.........l......
zP0.*..A/.n...
RADIUS: Mise jour de la facturation

192.168.0.140 (192.168.0.140)
Radius Protocol
Length: 106
t:Acct Status Type(40) l:6, Value:Interim Update(3)
Value:3093B4535DF458F64EEF9031A814EA0C
0000
0010
0020
0030
0040
0050
0060
0070
0080
0090
00
00
00
06
75
1f
06
00
6e
a8
30
86
8c
07
72
0a
06
64
70
14
bd
01
0b
08
69
36
00
2b
50
ea
61
d4
cf
09
65
32
00
06
12
0c
ee
00
07
0a
6e
37
00
00
30
24
00
15
0b
70
35
01
00
93
00
80
00
0c
1e
30
08
03
b4
50
11
72
0d
0a
31
06
e8
53
ba
b6
19
0e
38
31
ff
2c
5d
b9
b5
26
0f
34
34
01
0a
f4
2d
c0
04
10
30
28
02
69
58
df
a8
01
11
39
06
03
64
f6
08
00
00
12
30
00
2a
75
4e
00
01
6a
13
32
00
06
72
ef
45
c0
04
01
31
00
00
69
90
00
a8
05
08
35
03
00
65
31
.0.a.$.P..-...E.
................
.......r.&...j..
................
urienp..84090215
..62750114(.....
............*...
.d+.....,.idurie
npP.0..S].X.N..1
....

192.168.0.1 (192.168.0.1)
Radius Protocol
Length: 20
0000
0010
0020
0030
00
00
00
7a
50
30
01
50
ba
06
07
30
b9
2d
15
d2
2d
00
0b
2a
df
00
cf
c6
00
80
00
dc
30
11
1c
41
bd
b2
a1
2f
61
b2
6c
a1
ee
c0
05
6e
24
a8
01
bc
08
00
00
c0
00 45 00
8c c0 a8
14 b3 d2
17
.P..-..0.a.$..E.
.0.-............
.........l......
zP0.*..A/.n...
RADIUS: Fin de facturation

192.168.0.140 (192.168.0.140)
Radius Protocol
Length: 106
t:Acct Status Type(40) l:6, Value:Stop(2)
Value:E3F541359186545DC8B280C207BF918E
0000
0010
0020
0030
0040
0050
0060
0070
00
00
00
06
75
1f
06
00
30
86
8c
07
72
0a
06
64
bd
01
0b
08
69
36
00
2b
61
d3
cf
09
65
32
00
06
ee
00
07
0a
6e
37
00
00
24
00
15
0b
70
35
01
00
00
80
00
0c
1e
30
08
03
50
11
72
0d
0a
31
06
e8
ba
b6
38
0e
38
31
ff
2c
b9
b6
69
0f
34
34
01
0a
2d
c0
04
10
30
28
02
69
df
a8
01
11
39
06
03
64
08
00
00
12
30
00
2a
75
00
01
6a
13
32
00
06
72
45
c0
04
01
31
00
00
69
00
a8
05
08
35
02
00
65
.0.a.$.P..-...E.
................
.......r8i...j..
................
urienp..84090215
..62750114(.....
............*...
.d+.....,.idurie
0080
0090
6e 70 50 12 e3 f5 41 35 91 86 54 5d c8 b2 80 c2
07 bf 91 8e
npP...A5..T]....
....

192.168.0.1 (192.168.0.1)
Radius Protocol
Length: 20
0000
0010
0020
0030
00
00
00
7a
50
30
01
50
ba
06
07
30
b9
2c
15
d2
2d
00
0b
2a
df
00
cf
c6
00
80
00
dc
30
11
1c
41
bd
b2
a1
2f
61
b3
6c
a1
ee
c0
05
6e
24
a8
01
bc
08
00
00
c0
00 45 00
8c c0 a8
14 b3 d2
17
.P..-..0.a.$..E.
.0.,............
.........l......
zP0.*..A/.n...
La scurit du WiMAX1
1. Introduction
La norme IEEE 802.16 adresse une classe dinfrastructure dite last mile (ou
dernier kilomtre) destine la construction de rseaux mtropolitains (Wireless
Metropolitan Area Network, en abrg WMAN), indoor ( lintrieur des btiments)
ou outdoor ( lextrieur des btiments), ddis des usages fixes, nomades, ou
grande mobilit (comme par exemple une automobile se dplaant une vitesse
normale). Cest un standard flexible, compatible avec de multiples plages de
frquences, telles que 10-66 GHz ou 2-11 GHz.
1.1 Un bref historique
La premire version approuve en 2001 et baptise IEEE 802.16-2001 [IEEE802.16 01] utilise la bande 10-66 GHz (cf. figure 1.1.1). de telles frquences les
dispositifs dmission rception sont quasi aligns (cest--dire Line Of Sight, LOS)
et la liaison ne fonctionne plus lorsquun obstacle tel que arbre ou btiment
sintercale entre ces deux extrmits. Pour des frquences plus basses, entre 2 et 11
GHz cette contrainte nest plus indispensable, (on parle alors de Non Line Of Sight,
NLOS). La deuxime version du standard publie en 2004, et nomme IEEE
802.16-2004 [IEEE-802.16 04] intgre les deux plages de frquences pralablement
voques et permet donc des dploiements de type LOS et NLOS. La version la plus
rcente, finalise en fvrier 2006 [IEEE-802.16e 06] sapplique plus
particulirement la bande 5-6 GHz, le codage de linformation prend en compte les
problmes spcifiques induits par la vitesse des usagers, tels que par exemple leffet
DOPPLER.
Enfin la technologie MIMO (Multiple Input, Multiple Output) emploie de
multiples antennes dmission et de rception, et facilite lintgration et le
dploiement du WiMAX.
1 Chapitre rdig par Pascal URIEN
La scurit du WiMAX
Norme
Disponible
Bande
Dbit
IEEE 802.16-2001
Dcembre 2001
IEEE 802.16-2004
Octobre 2004
IEEE 802.16e
Fvrier 2006
10 - 66 GHz
2-11 GHz
< 6 GHz
32-134 Mbits dans des Jusqu 75 Mbits dans Jusqu 15 Mbits dans
canaux de 28MHz des canaux de 20MHz des canaux de 5 MHz
Technique
de
Modulation
QPSK, 16QAM,
64QAM
OFDM 256 sous

porteuses
OFDMA 2048 sous
porteuses
Fixe, Nomade
Mobilit
Fixe
Largeur des
canaux
Rayon de la
cellule
S-OFDMA
Grande Mobilit
20, 25 et 28 MHz
Variable
1.5 20 MHz
Identique 802.16-2004
des sous canaux UL
2-5 km
7-10 km
Maximum 50 km
2-5 km
Figure 1.1.1. Rcapitulatif des normes IEEE 802.16
1.2 Quelques marchs

De manire schmatique, les rseaux WiMAX adressent cinq classes de services.
En premier lieu la fourniture de services de tlphonie en mode sans fil tels que T1
en Europe (2,048 Mbits/s) ou E1 (2,000 Mbits/s) aux Etats-Unis; cest une
opportunit de prestations alternatives aux offres des oprateurs tlphoniques
classiques, utilisant une infrastructure cble. Le haut dbit la demande (ou
broadband on demand) permet une entreprise dtablir des connexions
performantes entre ses agences, pour organiser par exemple des vidoconfrences.
Cette technologie fournit galement aux zones mal desservies des accs internet haut
dbits, analogues aux modems ADSL mais bass sur des liens hertziens. De mme
des sites gographiques isols, pour lesquels les cots de cblage sont importants,
peuvent bnficier de cette technique, qualifie dans ce cas de boucle locale radio
(BLR), dlivrant des services de type voix ou donnes. Enfin le rseau WiMAX est
un complment naturel aux hotspots Wi-Fi, il assure la continuit des connexions IP
pour un utilisateur nomade ou un automobiliste. Un abonn peut tre gr par un
unique fournisseur de services IP sans fil (Wireless Internet Service Provider,
WISP) ou bnficier daccords entre diffrents WISPs afin de conserver de manire
transparente ses services (cest le mcanisme de roaming).
La scurit du WiMAX
1.3 Topologie
Larchitecture du WiMAX (cf. figure 1.3.1.) comporte des stations de base BS
(Base Station) munies de plusieurs antennes directionnelles, grant des secteurs, et
tablissant des liens de type PMP (Point to Multi Point). Dans un secteur donn, les
voies descendantes (mission dinformation vers les clients) et montantes (rception
des donnes mises par les clients) sont gres par une station de base unique.
Downlink
Secteur
Station
de Base
BS
Uplink
Client
(SS Subscriber
Station)
Figure 1.3.1. Illustration de larchitecture PMP
La station de base met priodiquement des trames (management frames)

dcrivant la structure :
des voies descendantes (downlink frames, donnes mises par le BS), laide
du message Downlink Map (DL-MAP) ;
des voies montantes (upstream frames, pour les donnes reues par le BS),
laide du message Uplink Map (UL-MAP).
Plus prcisment, une voie est organise en une srie de rafales (bursts), chacune
dentre elle tant identifie par un code DIUC (Downlink Interval Usage Code) ou
UIUC (Uplink Interval Usage Code), et caractrise par des paramtres de
modulation et de codage radio spcifiques, permettant dobtenir des dbits adapts
aux niveaux de signal et de bruit prsents entre un client et une station de base. Un
canal de transmission est associ un ou plusieurs bursts, lesquels sont organiss en
plusieurs canaux logiques.
La scurit du WiMAX
Figure 1.3.2. Architecture MESH
Le rcepteur, Subscriber Station (SS) dans 802.16 ou Mobile Station (MS) dans
802.16e, analyse les trames reues et utilise les canaux (montants) de
communication pour diffrentes classes de service telles que administration du
systme (demande de connexion, allocation de qualit de service,) ou
transmission de donnes (en mode Best effort par exemple). La gestion des
collisions daccs aux canaux montants, est ralise par plusieurs types
dalgorithmes. Une deuxime variante permet des rseaux de type MESH (cest-dire maills). Une station de base relie au backbone WiMAX est qualifie de Mesh
BS, les autres lments de linfrastructure sont nomms Mesh SS.
1.4. Evolution de la scurit dans les normes
La scurit du WiMAX a volu au fur et mesure des applications envisages.
Bien que larchitecture rseau soit diffrente, le WiMax puise ses racines dans le
projet, aujourdhui abandonn, IEEE 802.14 ("Cable-TV access method and physical
layer specification"), dmarr en 1996. Ce dernier se proposait de dfinir un
protocole MAC, bas sur une infrastructure ATM, et ddi la distribution de
programmes de tlvision par cble. La tte du rseau (HeadEnd) est dune part
connect au rseau dun oprateur et dautre part une grappe dutilisateurs quips
de modems (appels cable modem, CM). La scurit des changes entre abonns et
La scurit du WiMAX
tte de rseau, sappuie sur un secret statique (baptis cookie), un secret dynamique
K (appel cl principale ou Main Key) obtenu au terme dune classique procdure
Diffie Hellman, et deux nombres alatoires gnrs par chaque entit. Les trames
MAC sont chiffres laide de lalgorithme DES muni dune cl de 40 ou 56 bits.
Outre atlantique le modem cble est une technologie de connexion la toile
mondiale, propose par de nombreux fournisseurs daccs Internet. Il existe des
dizaines de fabricants de tels dispositifs (on peut en trouver une liste non exhaustive
sur le site http://www.cable-modems.org). Le standard dominant est le DOCSIS
(abrviation de Data-Over-Cable Service Interface Specifications), il est dit par le
consortium cablelabs (http://www.cablelabs.com) fond en 1998 par des oprateurs
amricains de tlvision cble. Cette association est galement reprsente
lIETF, par le groupe de travail ipcdn (IP over Cable Data Network) qui dfinit la
structure des bases de donnes (Management Information Base) embarques dans
les modems cble. Larchitecture DOCSIS est assez similaire aux infrastructures de
type DSLAM, un HUB de distribution (encore dnomm tte de rseau - headend)
accde simultanment au rseau tlphonique commut (RTC) classique et aux
rseaux des oprateurs. Cette entit est par ailleurs relie de multiples utilisateurs
quips de modem cble. Le protocole BPKM (abrviation de Baseline Privacy Key
Management Protocol ) fournit deux types de services, lauthentification des
usagers, et la confidentialit des donnes changes avec le HUB de distribution. La
scurit est base sur une infrastructure cl publique; chaque modem cble est
muni dun certificat X509 et dune cl RSA prive. Lautorit de certification racine
(le DOCSIS root CA) attribue des certificats aux fabricants, qui a leur tour dlivrent
des certificats de conformit leurs quipements. Le HUB de distribution
authentifie un modem cble laide de son certificat associ une cl priv. Les
trames sont chiffres par un classique algorithme DES.
Les mcanismes de scurit introduit par la norme IEEE 802.16-2001 sont trs
proche de la norme DOCSIS, dune part sur le plan fonctionnel, et dautre part au
niveau de lencodage binaire. Dans ce standard, en mode LOS, les faisceaux
hertzien sont dploys laide de points hauts tels que grattes ciel ou pylnes; la
scurit des donnes est alors succincte : un simple chiffrement avec lalgorithme
DES, muni dune cl de taille modeste (56 bits). Chaque station dabonn
(Subscriber Station) est munie dun certificat qui atteste sa conformit, cest en
quelque sorte un modem pour lequel le cble a t remplac par un lien radio trs
directif.
Avec le standard de 2004, les dploiements NLOS deviennent possibles, ce qui
augmente le risque dcoute, en raison des multiples rflexions possibles du signal
radio. En consquence la protection des donnes est renforce grce par exemple au
chiffrement AES, muni dune cl de 128 bits; lintgrit des trames dinformation
est galement assure. Cependant lauthentification reste base sur la prsence, ct
La scurit du WiMAX
abonn, dun certificat, et elle nest pas mutuelle : le rseau authentifie son usager,
mais la rciproque nest pas vraie.
La grande mobilit introduite dans la norme 802.16e, implique la mise en place
dune architecture similaire celle pralablement dfinie pour le Wi-Fi (IEEE
802.1x) et comportant typiquement un ou plusieurs serveurs dauthentification. De
mme lauthentification mutuelle devient ncessaire en raison des faibles prix des
stations de base, qui permettent aux pirates de dployer facilement des leurres (ou
rogue base station).
2. Couches basses du WiMAX
Conformment au modle des rseaux locaux IEEE 802, larchitecture logique
dun noeud se dcompose en deux sous ensembles (cf. figure 2.1.), la couche MAC
(Medium Access Control) et la couche physique (PHY). Loriginalit de ces blocs
est dincorporer des couches dites de convergence, qui effectuent les oprations
ncessaires aux services dfinis de manire abstraite, cest--dire indpendamment
des caractristiques des technologies radio dployes.
CS Convergence Sublayer
CPS Common Part Sublayer MAC
802.16-2001
802.16e
PS Privacy Sublayer
TDMA
TDD/FDD
802.16a
CS Convergence Sublayer
PHY SOFDMA
PMD
SCa
OFDM-256
OFDMA-2048
Figure 2.1. Rsum des couches basses IEEE 802.16
Single
Carrier
La scurit du WiMAX
2.1. La couche MAC

La couche MAC se divise en trois lments, une couche de convergence, une
couche dite commune, et une couche de scurit.
La couche de convergence (CS - Convergence Sublayer) ralise linterface entre
un rseau extrieur (ATM, Ethernet) et les units de service (MAC-SDU)
changes avec le rseau radio local (MAC-CPS, Common Part Sublayer). Elle gre
un mcanisme de classification, en charge de la qualit de service, en associant
chaque identifiant de connexion 802.16 local (le Connection IDentifier ou CID, un
nombre de 16 bits), un flux de donnes vers le rseau extrieur (identifi par un
Service Flow IDentifier, SFID, un nombre de 32 bits).
Figure 2.1.1. Concept de classification

La couche commune (CPS, Common Part Sublayer) est lie aux ressources
physiques. Elle administre les connexions locales, applique les mcanismes de
qualit de service et gre les accs (mission/rception) au niveau physique. Elle
change des SDUs avec plusieurs classes de CSs.
La couche de scurit, (PS, Privacy Sublayer) est en charge des mcanismes
dauthentification et dchange de cls, elle assure galement le chiffrement et
lintgrit des trames.
La scurit du WiMAX
2.2. La couche Physique

La couche physique (PHY) se divise en deux parties, une couche de convergence
(Convergence Sublayer, CS) et une couche grant la radio (Physical Medium
Dependant, PMD). Cependant lorsque le PMD ralise tous les services ncessaires
lentit MAC-CPS, la couche de convergence est vide. Les normes 802.16 emploient
pour lessentiel quatre types de couches physiques :
le WirelessMAN-SC PHY layer. Cest une technologie employant une
porteuse unique (Single Carrier) ;
le WirelessMAN-OFDM PHY layer, utilise un procd de transmission
talement de spectre (Orthogonal Frequency Division Multiplexing), comportant
256 porteuses. Laccs concurrent de plusieurs stations dabonn (SS) est gr par
un algorithme TDMA (Time Division Multiple Access) ;
le WirelessMAN-OFDMA PHY layer est bas sur un talement de spectre
2048 porteuses (Orthogonal Frequency Division Multiple Access). Laccs multiple
est obtenu grce lallocation dun sous ensemble de porteuses, un mme
rcepteur (cest une combinaison de procds TDMA et OFDMA) ;
le WirelessMAN-SOFDMA (Scalable OFDMA). Ce procd utilise une
transforme de Fourier (Fast Fourier Transform, FFT) dont la taille varie de 128
2048 chantillons, lintervalle entre sous porteuses ayant une valeur constante de
10,94 Khz.
2.3. Connexions et primitives
Convergence Sublayer
Request
4
Mac Sublayer
Confirmation
Response
2
Mac Sublayer
Indication
Figure 2.3.1. Primitives de connexion OSI
Une connexion est un lien unidirectionnel entre une station de base et une station
fixe (ou mobile) identifi par un CID (Connection IDentifier, 16 bits). Il existe deux
types de connexions : transport et management. Une connexion de transport possde
une association de scurit (SA) et un identifiant de flux (SFID). Une connexion de
management nutilise aucune association de scurit et ne possde pas de SFID.
La scurit du WiMAX
MAC_CREATE_CONNECTION.request
( scheduling service type,
convergence sublayer,
service flow parameters,
payload header suppression indicator,
length indicator,
encryption indicator,
Packing on/off indicator,
Fixed-length or variable-length SDU indicator,
SDU length,
CRC request,
ARQ parameters, sequence number)
.confirmation
( Connection ID,
response code,
response message,
sequence number)
Figure 2.3.2. Dtails des primitives de cration de connexion IEEE 802.16
Conformment au modle de rfrence OSI, linterface MAC supporte quatre

classes de primitives (cf. figure 2.3.1.) pour chaque procdure de gestion de
connexion :
la cration de connexions, MAC_CREATE_CONNECTION.request,
indication, response, confirmation. La figure 2.3.2. prcise les diffrents paramtres
inclus dans une requte de connexion, on remarque en particulier, le type de
mcanisme de classification (scheduling service type), la slection dune couche de
convergence particulire (convergence sublayer) et la demande de qualit de service
QoS (service flow parameters). La valeur du CID de la rponse, associe aux attributs
prcdents, un identifiant de connexion ;
la modification de connexions, MAC_CHANGE_CONNECTION.request,
indication, response, confirmation ;
lannulation de connexions, MAC_TERMINATE_CONNECTION.request,
indication, response, confirmation ;
lmission/rception de donnes, MAC_DATA.request, indication,
confirmation, et response. Lenvoi et la rception dun paquet data est toujours
associ un CID (cf. figure 2.3.4).
La scurit du WiMAX
MAC_DATA.request
10
MAC_DATA.indication
( Connection ID,
length,
data,
discard-eligible flag,
encryption flag)
( Connection ID,
length,
data,
reception status)
Figure 2.3.3. Primitives de transfert de donnes
2.4 Structure des trames MAC

Une trame MAC comporte trois parties (cf. figure 2.4.1.) : un entte (header),
une charge utile (payload) et un CRC (Cyclic Redundancy Check).
MAC Header
Payload (optionnel)
CRC (optionnel)
Figure 2.4.1. La trame MAC de lIEEE 802.16
Un entte est une structure de 48 bits, soit de type generic, suivie dune charge
utile (payload) et dun CRC, soit de type bandwidth request, pour lequel aucune
charge ni CRC ne sont prsents.
Un entte MAC gnrique comporte pour lessentiel les informations suivantes :
- Le CID (Connection IDentifier) du destinataire de linformation. En fonction
du CID, la charge utile contiendra des donnes ou bien des informations
dadministration (cf. section 2.5).
- Un bit (Encryption Control, EC) indiquant si la charge est chiffre.
- Deux bits (Encryption Key Control, EKC) prcisant lindex (compris entre 0 et
3) de la cl de chiffrement de trafic (Traffic Encryption Key, TEK).
- La longueur (code sur 11 bits) du MAC_PDU, comprise entre 0 et 2047
octets.
- Un champ type de largeur 6 bits, indique la prsence denttes optionnels,
utiliss pour divers services, par exemple pour la segmentation de messages longs.
La scurit du WiMAX
11
2.5. Les trames dadministration (Management)

Management
Message Type
Management
Message Payload
Figure 2.5.1. Structure des trames dadministration IEEE 802.16
Les trames dadministration (management frames) jouent un rle fondamental

tant lors des procdures daccs au rseau WiMAX que pour le transport des
protocoles dauthentification. Elles sont associes des CIDs particuliers, et utilisent
un entte MAC gnrique. Un message dadministration comporte un premier octet
dfinissant sa fonction (MngtType), cest--dire la nature de lopration dsire, et
une charge dont la structure dpend du type de message (le paramtre MngtType).
2.6. Procdure de connexion dun client dans un rseau WiMAX
Un client analyse la liaison descendante, et tablit une premire connexion avec
la station de base (le Primary Management Connection). Celle ci est utilise pour les
oprations relatives lauthentification et la gestion des cls cryptographiques. Au
terme dune opration dauthentification et denregistrement russie, la connexion
secondaire (le Secondary Management Connection) est tablie et permet aux deux
entits SS et BS douvrir des connexions de transport laide des primitives
MAC_create_connection (cf. 2.3). La procdure dinsertion dune station dans un
rseau WiMAX se dcompose en une dizaine dtapes dcrites la figure 2.6.1 :
1- Recherche et synchronisation avec la voie descendante. Le module de
rception PHY du client analyse le signal descendant et se synchronise avec ce
dernier. Cette opration est ralise en analysant les caractristiques de la voie
descendante fournies priodiquement par la station de base par le biais des messages
dadministration DL-MAP (MngtType=2). Le module MAC du client dduit, grce
DL-MAP le nombre de bursts de la voie descendante, puis obtient la structure des
canaux, renseigne dans le message DCD (DownLink Channel Descriptor,
MngtType=1) ;
2- Acquisition des paramtres de la voie montante. Le client dduit des messages
UL-MAP (MngtType=3) et UCD (Uplink Channel Descriptor, MngtType=0)
lorganisation des canaux de transmission ;
3- Etalonnage et ajustement de la puissance dmission. laide des messages
Ranging Request (RNG-REQ) et Ranging Response (RNG-RSP), le client ajuste sa
puissance dmission et obtient diverses informations de la station de base. En
La scurit du WiMAX
12
particulier, les paramtres Basic Connection ID et le Primary Management CID sont

affects au client par la station de base et notifis dans la rponse RNG-RSP ;
Scan for
Downlink
Channel
Static SA
Optional Primary SA
Downlink
Synchro
Established
Obtain
Uplink
Parameters
SS Authorization
and
Key Exchange
Basic CID
Primary CID
PHY is
Ready
Ranging &
Automatic
Adjustments
Ranging &
Automatic
Adjustments
Complete
Negotiate
Basic
Capabilities
Time of Day
Established
SS
Authentication
complete
Uplink
Parameters
Acquired
Establish
Time of
Day
Register
With
BS
Transfer
Complete
Registration
Complete
Basic
Capabilities
Negotiated
Establish
IP
Connectivity
IP
Complete
Secondary CID
Transfer
Operational
Parameters
10
Establish
Provisioned
Connections
Operational
Optional Secondary SA
Figure 2.6.1. Procdure dinsertion dun nud client dans un rseau WiMAX
4- Ngociation des paramtres de transmission. Au terme de la procdure

dtalonnage le client informe la station de base de ses capacits laide du message
dadministration SBC-REQ (SS Basic Capability Request) acquitt par un SBCRESP (SS Basic Capability Response) ;
5- Autorisation et change de cls. Le client et la station de base ralisent une
squence dauthentification et dchange de cls laide des messages
La scurit du WiMAX
13
dadministration PKM-REQ (Privacy Key Management Request, MngtType=9) et

PKM-RESP (Privacy Key Management Response). Ce protocole utilise le Primary
Management CID ;
6- Enregistrement. Grce cette procdure le client devient un membre actif du
rseau. Les messages Registration Request (REG-REQ) et Registration Response
(REG-RSP), authentifis par un HMAC-tuple (un couple valeur HMAC, index dune
cl HMAC) lui permettent dobtenir un Secondary Management CID, utilis en
particulier pour des services IP tels que DHCP ;
7- Etablissement de la connectivit IP. La version IP utilise par le client est
indique dans le message REG-REQ. Le client obtient une adresse IP laide du
classique protocole DHCP (dcrit par la RFC 2131 [RFC 2131]) ;
8- Acquisition de la date et de lheure. Le client obtient ces paramtres grce au
protocole dfini par la RFC 868 [RFC 868] ;
9- Tlchargement des paramtres de configuration. Le client obtient un fichier
de configuration laide du protocole TFTP (Trivial FTP, RFCs 1123 et 2349 [RFC
1123, RFC 2349]) ;
10- Activation des services prpays. La station de base dlivre des messages
DSA-REQ (Dynamic Service Additional Request) au client afin dtablir les
connexions ncessaires lactivation des services. Ces messages sont acquitts par
le client laide de rponses DSA-RESP (Dynamic Service Additional Response).
Lactivation dune connexion par la station de base est obligatoire. De manire
optionnelle, le client cre dynamiquement une connexion, dote dune certaine
qualit de service. Les messages MAC (DSA-REQ, DSA-RESP, ) sont
authentifis par des HMAC-Tuples, ils permettent dobtenir les informations
indispensables lusage des services rseaux, tels que les paramtres CID et SFID.
La figure 2.6.2. illustre un scnario de connexion. Une demande de connexion
est traduite par un message DSA-REQ, authentifi par un HMAC-Tuple associ
une cl de signature obtenue lors de la phase dautorisation. Lacceptation de cette
requte est notifie par un DSA-RESP, sign par un HMAC-Tuple. Ce dernier
message comporte des attributs prcisant le type de qualit de service disponible
(Service Flow) ainsi que lidentifiant de la connexion (CID) ; il est acquitt par un
DSA-ACK.
La scurit du WiMAX
Requestor
CS
Requestor
MAC
MAC_CREATE_CONNECTION
confirmation
Responder
CS
Responder
MAC
request
DSA-REQ
* HMAC-Tuple
DSA-RESP
* Service Flow
Parameters (CID)
* HMAC-Tuple
14
indication
response
DSA-ACK
* HMAC-Tuple
Station de base
Client
Figure 2.6.2. Obtention de services prpays
3. La scurit selon 802.16-2004

Toute la scurit de la norme 802.16-2004 repose sur le protocole PKM (Privacy
Key Management) qui ralise lauthentification dun client et permet de ngocier
une suite dalgorithmes cryptographiques et de cls associes. Le protocole PKM est
un hritage des normes IEEE 802.14 (Cable-TV access method and physical layer
specification) puis DOCSIS (Data-Over-Cable Service Interface Specifications). Il
est transport dans des messages MAC dadministration de type PKM-REQ ou
PKM-RESP (respectivement des requtes et des rponses).
Suite cette ngociation dalgorithmes, les trames MAC suivantes sont
protges entre le client et la station de base :
- les trames MAC de donnes sont chiffres, et optionnellement protges en
intgrit ;
- les trames MAC dadministration sont protges en intgrit/authentification.
Ces fonctions de scurit sappuient sur un jeu de quatre cls AK, KEK, TEK
et HMAC - dont les caractristiques sont rsumes dans le tableau 3. La cl AK joue
un rle fondamental puisquelle sert de base au calcul des cls KEK et HMAC.
La scurit du WiMAX
15
Les procdures dauthentification et de distribution de cls cryptographiques sont

gres par deux machines dtat distinctes, la machine dtat dauthentification et la
machine dtat de distribution des cls TEK.
Cls
Caractristiques
Authorization Key
AK
Cette cl est transmise par la station de base, chiffre laide

de la cl RSA publique du client. Les cls KEK et HMAC sont
directement calcules partir de la valeur de AK
Key Encryption Key

KEK
La valeur de cette cl est dduite de AK par la station de base

et le client. Elle est utilise pour le chiffrement et le
dchiffrement des cls TEK
Traffic Encryption Key

TEK
Cette cl est dlivre chiffre par la station de base au client.

Le chiffrement fait intervenir la cl KEK et un algorithme
ngoci lors des changes PKM. Elle est utilise pour le
chiffrement des trames de donnes
Cls HMAC :
HMAC_KEY_D
HMAC_KEY_U
HMAC_KEY_S
Les cls HMAC sont dduites de la valeur de AK. Elles sont

associs lalgorithme HMAC et permettent dauthentifier les
trames de management des voies montantes
(HMAC_KEY_U) et descendantes (HMAC_KEY_D). La cl
HMAC_KEY_S est exclusivement utilise dans les
architectures de type MESH
Tableau 3. Rcapitulatif des cls symtriques dfinies dans 802.16-2004
3.1 Authentification, autorisation et distribution de cls

3.1.1 Procdure dauthentification et autorisation par le protocole PKM
Cette procdure (PKM Authentication) ralise lauthentification dun client et
permet en cas de succs dobtenir une cl dauthentification AK dlivre par la
station de base. Elle intervient aprs que le mobile ait fini de ngocier les paramtres
de transmission (capabilities) avec la station de base. Elle correspond ltape 5 de
la figure 2.6.1. Elle change trois messages PKM (cf. figure 3.1.1.1.) :
1- Le premier message (Authorization Information Message) contient le certificat
X.509 [RFC2459] du client SS ;
2- Le deuxime message est une requte dautorisation (Authorization Request
Message) qui comporte les lments suivants :
- le certificat X.509 du client SS ;
- une liste des suites cryptographiques supportes par le client qui identifient
chacune trois types dalgorithmes (algorithme de chiffrement des trames, algorithme
dauthentification des trames, et algorithme de chiffrement de cl TEK par la cl
KEK) ;
La scurit du WiMAX
16
- le Basic CID du client, cest--dire le premier CID dlivr par la station de

base lors de ltablissement du primary management channel . Ce paramtre
constitue galement lidentifiant primaire (ou primary SAID ) de lassociation de
scurit ;
3- Le troisime message est la rponse la requte dautorisation (AuthReply)
produit de la station de base. Il transporte :
- la cl AK (Authorization Key) chiffre avec la cl publique du client,
conformment au standard RSAES-OAEP [PKCS 1] (cf. section 3.3.1.) ;
- un nombre de 4 bits (Key-Sequence-Number) utilis comme un identifiant de
la cl AK ;
- la dure de vie de la cl AK ;
- une liste dassociations de scurit (identifies par leur SAID respectif) pour
lesquelles le client peut obtenir des cls de chiffrement de trames TEK.
BS
SS AuthInfo
AuthRequest
AuthReply{AK0}
AuthRequest
AK0
Lifetime
AK0
Lifetime
AuthReply {AK1}
Figure 3.1.1.1. Procdure dAutorisation
lexpiration de la dure de vie de la cl AK (AK lifetime), la premire cl AK

tant note AK0 une nouvelle session dautorisation est lance aboutissant une
nouvelle cl AK1.
3.1.2 Procdure de distribution de cls TEK
Comme lillustre la figure 3.1.3.1., cette procdure de distribution de cls TEK
un client se base sur deux messages dadministration comme suit :
1- Le client met le message KeyRequest associ un SAID (Security
Association IDentifier) particulier, afin dobtenir une paire de cls TEK (TEK0,
TEK1) lies une association de scurit SAID particulire ;
La scurit du WiMAX
17
2- La station de base rpond par le message dadministration KeyReply (ou

KeyReject en cas de problmes). Le message KeyReply contient la liste
dinformations suivantes :
- un index de cl AK (Key-Sequence-Number) ;
- un identifiant SAID ;
- deux cls TEK (chiffres), chaque cl servant au chiffrement des donnes
dans les deux sens de communication ;
- un index pour chaque cl TEK (Key-Sequence-Number);
- la dure de vie de chaque cl TEK (Key-Lifetime) ;
- le vecteur dinitialisation de chaque cl TEK (IV) car les algorithmes de
chiffrement utiliss se basent sur le mode chan (CBC) ;
- une empreinte HMAC.
Les cls TEK sont mises chiffres par la station de base laide de lalgorithme
prcis par lassociation de scurit (SAID) associ un index de cl AK.
Le CBC-IV des liens descendant et montant sont obtenus par le ou exclusif du
champ IV inclus dans les informations relatives la cl TEK, avec le champ de
synchronisation de messages DL-MAP.
Notez que les deux messages prcdents (KeyRequest et KeyReply) sont
authentifis et prouvs intgres grce la prsence du champ HMAC calcul avec la
cl HMAC_KEY_U/D.
Lorsquune cl TEK arrive expiration, une nouvelle session de distribution de
cls est initie.
SS
Key Request
BS
Key Reply{TEK0, TEK1}

TEK0
Lifetime
TEK0
Lifetime
TEK1
Lifetime
Key Request
Key Reply{TEK1, TEK2}
Figure 3.1.3.1. Procdure de distribution des cls TEK.
La scurit du WiMAX
18
3.2. Associations de scurit

On dsigne par association de scurit un ensemble dlments permettant de
mettre en uvre les procdures dauthentification ou de protection des trames
changes sur les liens radios. Ces paramtres comprennent entre autres les
algorithmes cryptographiques, les cls, et leurs dures de vie.
3.2.1. Association de scurit pour lauthentification des trames dadministration
Pour assurer lauthenticit et lintgrit des trames de donnes, les associations
de scurit partages entre client et station de base comportent les informations
suivantes :
le certificat X.509 du client ;
une cl AK de 160 bits ;
un index de 4 bits de la cl AK, le Key-Sequence-Number ;
la dure de vie de la cl AK (70 jours par dfaut) ;
une cl de chiffrement KEK associe un algorithme de transport de cl TEK
(par exemple 3-DES) ;
deux cls de signature de 160 bits pour les liaisons descendantes et montantes,
associes un algorithme HMAC ;
une cl de signature de 160 bits pour les infrastructures MESH.
Dans ce chapitre nous ne dcrivons pas, par souci de concision, le mode de
fonctionnement dun rseau WiMAX en mode MESH, La cl de signature MESH
est calcule partir dune valeur secrte appele OperatorSharedSecret (cf. section
3.3.2), elle intervient pour garantir lauthenticit et lintgrit de certains messages
dadministration tels que par exemple Key Request (cf. section 3.1.2).
3.2.2. Association de scurit pour le chiffrement des donnes
Il sagit dune liste de paramtres assurant la scurit des changes entre un ou
plusieurs clients et une station de base. Il existe trois types de SA, primaire
(primary), dfinie lors de la procdure dinitialisation du client (et identifie par le
Basic CID), statique (static) attribue par la station de base, et dynamique (dynamic)
alloue pour des services de donnes particuliers.
Lassociation de scurit comporte les lments suivants :
un identifiant de 16 bits (SAID) ;
un algorithme de chiffrement, par exemple DES-CBC est lunique alternative
offerte par la version 802.16-2001 ;
deux cls de chiffrement TEK;
deux index (Key-Sequence-Number) de 2 bits pour les TEKs ;
La scurit du WiMAX
19
la dure de vie des cls TEK (30 minutes par dfaut) ;

les vecteurs dinitialisation CBC-IV (64 bits) associs une TEK puisque les
algorithmes utiliss sont de type chan ;
le type de lassociation de scurit : primaire, statique ou dynamique.
3.3. Elments cryptographiques
La norme [IEEE-802.16 04] repose sur plusieurs lments cryptographiques
permettant de driver des cls entre elles, mais aussi de procder au chiffrement des
trames de donnes ou au calcul de HMAC sur les trames dadministration.
3.3.1. Chiffrement/dchiffrement de la cl AK
20B
Hash (87B)
AK (20B)
PS
lHash
DB=
20B
0000.01 Message
107B
Seed
DB
MaskDB
MGF
00
MaskSeed
maskedSeed = Seed + MGF(maskedDB)
MGF
00 maskedSeed
maskedDB = DB + MGF(seed)
maskedDB
128B
Figure 3.3.1.1. Algorithme RSAES-OAEP
La cl AK joue un rle fondamental dans la mise en uvre de la scurit. Elle est

chiffre avec lalgorithme RSAES-OAEP dfini par la norme [PKCS 1].
Lalgorithme RSA ralise un chiffrement laide de lexposant de la cl prive ou
publique. Le nombre dont on ralise lexponentiation doit tre grand , cest dire
de lordre de grandeur du modulo.
La scurit du WiMAX
20
Par exemple si lexposant publique est gal 3, le nombre AK3 est de lordre de
2 , ce qui est infrieur 21024. Il est donc trivial de retrouver la valeur AK en
calculant la racine cubique de AK3.
La norme RSAES-OAEP est une mthode pour fabriquer partir dun nombre
petit (tel que AK) une grande valeur, cest dire un nombre de 127 octets.
Ce procd, dans le cas dun modulo de 128 octets, est ralis conformment la
figure 3.3.1.1. :
la cl AK (20 octets) est complte par une liste (PS) de 67 octets tous nuls
(00) sauf le dernier dont la valeur est gale 01 ;
une empreinte SHA1 (lHash) est calcule pour lensemble prcdent PS|AK o
la notation | dsigne lopration de concatnation. On obtient ainsi un nombre
DB = lHash| PS|AK, de 107 octets ;
un nombre alatoire (Seed) de 20 octets est utilis comme valeur dentre
dune fonction inversible MGF (Mask Generator Function) afin de produire une
suite de 107 octets, le MaskDB. Une opration de ou exclusif entre MaskDB et DB
permet dobtenir la valeur maskedDB ;
la fonction MGF est nouveau applique sur le paramtre maskedDB et
retourne une valeur MaskSeed. Une opration de ou exclusif entre MaskSeed et Seed
produit les 20 octets maskedSeed ;
un octet nul (00) est concatn aux valeurs maskedSeed et maskedDB. Un
calcul RSA utilisant la cl publique du client est alors excut sur le nombre
(00|maskedSeed|maskedDB) pralablement form.
- le rsultat final est chiffr avec la cl publique du client.
480
Lopration de dchiffrement consiste en un premier calcul utilisant la cl prive

du client, qui permet dobtenir la valeur 00|maskedSeed|maskedDB. La fonction
MGF(maskedDB) permet de retrouver la valeur MaskSeed, et donc de Seed. Do
lon dduit MaskDB= MGF(Seed), puis DB.
3.3.2. Calcul de la cl KEK et des cls HMAC
La cl de chiffrement de cl KEK, ainsi que les cls associes aux algorithmes
HMAC, sont dduites de la cl dauthentification AK laide des procdures
suivantes :
KEK= Truncate(SHA1(K_PAD_KEK | AK),128), la valeur K_PAD_KEK est
un nombre de 512 bits fixs. SHA1 retourne une valeur de 20 octets et KEK
correspond donc aux 128 bits (soit 16 octets) les plus gauche du hash obtenu par
SHA1. En effet, Truncate(x,n) indique une opration de troncature des n bits les plus
gauche dune liste de x bits ;
HMAC_KEY_D= SHA1(H_PAD_D | AK) ;
HMAC_KEY_U= SHA1(H_PAD_U | AK) ;
La scurit du WiMAX
21
HMAC_KEY_S= SHA1(H_PAD_D | OperatorSharedSecret).

Les valeurs H_PAD_D et H_PAD_U sont des valeurs de 512 bits fixes.
La cl HMAC_KEY_S ncessite pour son calcul le partage pralable dun secret
avec loprateur (OperatorSharedSecret).
3.4. Crypto-Suites de chiffrement de la cl TEK avec KEK
On dsigne par Crypto Suite un ensemble dalgorithmes de chiffrement
associ une cl TEK de longueur particulire. Deux crypto suites habituellement
utilises pour chiffrer la cl TEK avec KEK (16 octets) sont rsumes dans le
tableau 3.4.1.
Crypto-Suites
Algorithmes de
chiffrement
Tailles de cls TEK
Crypto-Suite 01
Triple DES (3-DES)
64 bits
Crypto-Suite 03
AES-128
128 bits
Tableau 3.4.1. Exemples de Crypto-Suites de chiffrement de cls TEK
3.5. Crypto-Suites de chiffrement de trames de donnes avec la cl TEK

3.5.1. Crypto Suite 01, algorithme DES-CBC
Le chiffrement sapplique uniquement la charge utile dune trame MAC. La
norme 802.16-2001 utilise le DES-CBC (cl de 56 bits et valeur initiale IV de 64
bits) et ne propose aucun mcanisme dintgrit des donnes.
Entte MAC
Charge utile (optionnelle)
CRC (optionnel)
Zone Chiffre
Figure 3.4.1.1. Chiffrement DES dune trame de donnes MAC
3.5.2. Crypto Suite 02, algorithme AES

Les donnes sont chiffres avec le mode CCM associ lalgorithme AES, tel
que dfini par la norme NIST Special Publication 800-38C, FIPS-197. Comme
lillustre la figure 3.4.2.1., les charges utiles MAC chiffres sont munies dun
La scurit du WiMAX
22
suffixe ICV (Integrity Check Value) destin contrler leur intgrit et dun prfixe
PN (Packet Number) pour dtecter les rejeux.
L octets
Entte MAC
Charge utile
CRC (optionnel)
L+12 octets
PN
Charge utile chiffre
4 octets
ICV
8 octets
Figure 3.4.2.1. Chiffrement AES-CCM dune trame MAC
3.5. Un rapide aperu des vulnrabilits de la norme 802.16-2004

Le WiMAX est un rseau radio dont les vulnrabilits sont similaires celles du
Wi-Fi. En 2006 les infrastructures mises en place par des entreprises telles que
Alvarion sont conformes la norme de 2001. De nombreux industriels des
tlcommunications travaillent activement sur le standard 802.16e, beaucoup plus
attractif en terme de services que la version 2004 ; ainsi un premier rseau 802.16e,
dnomm WiBRO (pour Wireless Broadband) a t dploy en Core du Sud et
utilise une authentification base sur le protocole EAP-AKA [RFC 4187]. Cette
section prsente un rapide aperu des faiblesses potentielles du WiMAX, cependant
en raison du faible retour dexprience, les attaques efficaces ne sont pas encore
observes ou connues.
Nous classerons les attaques en deux catgories, attaques au niveau physique
(PHY) et au niveau MAC.
3.5.1 Attaques au niveau physique
Il est possible de brouiller les signaux radio des voies montantes et descendantes,
laide de source de bruits adaptes. On distingue deux types de procds, le
jamming et le scrambling.
- Le jamming est un brouillage total des voies montantes et/ou descendantes ; il
provoque un dni de service sur le rseau, qui devient alors non fonctionnel.
Cependant il est facile de localiser la position gographique de lattaquant par des
classiques techniques de gionomtrie. Ce dernier sexpose donc des poursuites
judicaires.
La scurit du WiMAX
23
- Le scrambling consiste brouiller un faible portion des voies montantes ou

descendantes, il peut crer une dgradation de la qualit de service (QoS) entranant
par exemple la retransmission de certaines trames MAC.
3.5.2 Attaques au niveau MAC
Au niveau MAC on peut distinguer plusieurs classes dattaques, gnration de
trames de donnes errones, mascarade dun abonn, dploiement de leurres (rogue
base station). Cependant la plupart de ces faiblesses sont corriges par la norme
802.16e.
- Gnration de trame de donnes errones. Lorsque lassociation de scurit
relative aux trames ne comporte pas de mcanisme dintgrit, lattaquant forge des
trames, dont le contenu, une fois dchiffr en labsence de contrle dintgrit, sera
pratiquement alatoire, et peut entraner un incident dexcution pour le logiciel en
qui analyse le paquet. Cette faiblesse ne concerne que le mode de chiffrement DES
sans intgrit de trame, import de la norme IEEE 802.16-2001.
- Mascarade dun abonn. Certains messages dadministration tels que AuthInfo
ou AuthRequest ne sont pas authentifis (ils ne comportent pas dempreinte HMAC).
Un attaquant peut forger de tels paquets, puis les mettre. Il espre par exemple
inonder le rseau dinformations, crant une surcharge doprations de vrification
de certificats, ce qui peut provoquer un dni de service dautorisation. Remarquons
galement que le certificat dun abonn est mis en clair, ce qui permet dassocier
identit et position gographique, et qui prsente un risque potentiel pour le respect
de la vie prive (privacy). Cependant ce dernier problme est corrig avec des
techniques telles que la double session EAP, mise en uvre par le standard IEEE
802.16e.
- Dploiement de leurres. Les normes IEEE 802.16-2001 et IEEE 802.16-2004
nexigent quune authentification simple de labonn par le rseau. Le faible cot
probable de la technologie WiMAX permet aux pirates de dployer leurs propres
stations de base (rogue base station) dans le but dintercepter les communications
des clients du rseau, cest une attaque du type man in the middle. Les premires
infrastructures Wi-Fi, scurises selon lIEEE 802.1x [IEEE 802.1x 04] ont t
galement confrontes ce type de problme. Pour cette raison le standard IEEE
802.16e rend obligatoire lauthentification mutuelle entre abonn et station de base.
La scurit du WiMAX
24
4. La scurit selon 802.16e

Le standard [IEEE-802.16e 06] apporte des amliorations (mutuelle
authentification entre client et station de base, algorithmes cryptographiques plus
solides, serveur dauthentification) la prcdente version 802.16-2004, et
sadapte des stations clientes se dplaant des vitesses automobiles usuelles; il
introduit des accs rseaux hauts dbits destins des applications fixes ou mobiles.
Il intgre galement des recommandations permettant de grer des mcanismes de
handover, cest--dire le changement rapide de stations de base. Cette norme utilise
des bandes de frquences infrieures 6 GHz, dont lusage est soumis lobtention
dune licence.
Rseau
de lOprateur
Serveur
ASA
Liens avec le
rseau de loprateur
BS#1
BS#2
Figure 4.1. Larchitecture IEEE 802.16e
Larchitecture du rseau (cf. figure 4.1.) comporte des stations mobiles (mobile
station, MS), communiquant avec des stations de base (Base Station BS). Ces
dernires sont relies un rseau doprateur (Operator Backbone Network) qui
possde gnralement un centre dauthentification et dautorisation (Authentication
and Service Authorization Server, ASA), cest--dire une base de donnes qui
centralise toutes les informations des comptes clients ainsi que les paramtres
utiliss pour leur identification.
U
MS
BS
A
IB
U
MS
ASA
Serveurs
BS
Figure 4.2. Interfaces fonctionnelles IEEE 802.16e
La scurit du WiMAX
25
Le standard introduit des interfaces fonctionnelles (cf. figure 4.2.) lies la

mobilit sans toutefois dcrire de manire prcise les protocoles sous jacents.
Linterface U gre les services entre mobile et station de base. Linterface IB
transporte des messages entre stations de base destins grer les procdures de
handover. Enfin linterface A achemine des paquets dauthentification entre stations
de base et serveurs ASAs.
La norme identifie deux classes dinfrastructures, la premire nest pas lie un
oprateur ; la deuxime est typiquement gre par un oprateur de tlphonie
mobile. En fonction de ces contraintes, mais galement pour des raisons de
compatibilit avec les versions antrieures, deux types de mcanismes
dauthentification sont dfinis, PKM-RSA import de IEEE 802.16-2004 et PKMEAP permettant la rutilisation du protocole EAP (Extensible Authentication
Protocol), plus prcisment dcrit par le RFC 3748 [RFC 3748].
Deux versions du protocole de gestion de cls PKM (Privacy Key Management)
sont proposes ; la premire PKMv1 est compatible avec des environnements
conformes lIEEE 802.16-2004 ; la deuxime PKMv2 intgre de nouveaux
lments tels que :
Une authentification mutuelle entre station de base et mobile ;
Lusage de mcanismes bass sur RSA et/ou sur le protocole EAP ;
Une hirarchie de cls modifie (voir la section 4.1. pour plus de prcisions) ;
Le remplacement de la procdure HMAC-SHA1, base sur une empreinte
SHA1 (dont la solidit cryptographique est incertaine) par lalgorithme AES-CMAC
(dfini plus prcisment par les document [NIST05] et [RFC 4493] ) ;
Une nouvelle mthode de chiffrement, AES-key-wrap pour le transport des cls
TEK. Cet algorithme, qui fait lobjet dune recommandation NIST, ralise un
chiffrement AES avec une cl de 128 bits et intgre de surcrot une valeur dintgrit
(ICV, Integrity Check Value), ce qui renforce la scurit du procd de distribution
des cls TEK ;
La notion de pr authentification, cest dire un protocole permettant un
mobile et une station de base de partager une cl dauthentification sans procdure
dauthentification mutuelle. Le standard 802.16e ne dfinit pas de mthode
particulire pour le calcul de AK, mais nous remarquerons quil pourrait tre bas
sur les valeurs de ladresse MAC du client et de lidentifiant de la station de base ;
Le service MBS (Multicast Broadband Service). Comme son nom lindique, il
est destin la diffusion dinformations, typiquement multimdia. Les mcanismes
de scurit permettent par exemple de dployer efficacement des infrastructures de
type Pay TV (tlvision payante).
La scurit du WiMAX
26
Dans cette section, nous ne dcrirons que les apports du protocole PKMv2.
Notons que ce protocole suppose uniquement que le mobile soit initialis avec un
jeu de cls publique/prive et un certificat X.509. Un grand nombre de cls sont
changes ou drives entre mobile et station de base. Pour une meilleure lecture de
cette section, nous recommandons aux lecteurs de commencer par les procdures
dauthentification PKMv2-RSA et PKMv2-EAP et de se rfrer au tableau
rcapitulatif des cls dans le tableau 4.1.1. En rsum de ces procdures
dauthentification, des cls seront partages entre mobile et station de base. Plus
prcisment, avec PKMv2-RSA, une cl pre-Primary AK (pre-AK) est envoye par
la station de base, et avec PKMv2-EAP, une cl MSK (Master Session Key) est
terme gnre entre station de base et mobile. La cl dautorisation AK est obtenue
laide de ces lments et de lalgorithme Dot16KDF. Les cls ncessaires au
service MBS sont dduites dune cl MAK (cl dauthentification MBS AK),
distribue par des moyens non prciss par la norme IEEE 802.16e.
4.1. Hirarchie des cls
Le rcapitulatif des cls et de leur calcul est fourni dans le tableau 4.1.1 et le dtail
de la fonction Dot16KDF utilise est prsent la section 4.1.1.
Cls
Pre Primary AK
Pre-PAK
Caractristiques
Cette cl est gre par la station de base et transmise
chiffre par la cl RSA publique du client lors dune
phase optionnelle PKM-RSA
Primary AK
PAK
La cl PAK est dduite de la cl pre-PAK laide dune

fonction Dot16KDF et de paramtres dentre tels que
ladresse MAC du client et lidentifiant de la station de
base. Cette valeur intervient dans le calcul de la cl
dauthentification AK
Master Session Key

MSK
Cette cl est obtenue au terme dune premire session

dauthentification EAP. Elle intervient dans le calcul des
cls EIK et PMK
EAP Integrity Key

EIK
Cette cl est calcule partir de la cl pre-PAK ou

partir dune cl MSK. Elle est utilise pour authentifier
les messages EAP lors dune premire occurrence
(EIK=f(pre-PAK)), ou dune deuxime occurrence
(EIK=f(MSK)) dune session dauthentification .
Master Session Key 2

MSK2
Cette cl est obtenue au terme dune deuxime session

dauthentification EAP. Elle intervient dans le calcul de
la cl PMK2
Pairwise Master Key
Cette cl est dduite de MSK. Elle intervient dans le
La scurit du WiMAX
PMK
27
calcul de la cl dautorisation AK
Pairwise Master Key 2

PMK2
Cette cl est dduite de MSK2. Elle intervient dans le

calcul de la cl dauthentification AK
Authorization Key
AK
La cl AK est obtenue laide dune fonction

Dot16KDF et de paramtres additionnels tels que les
cls PAK, PMK, PMK2, ladresse MAC du client et
lidentifiant de la station de base
Key Encryption Key

KEK
La cl de chiffrement de cl KEK est dduite de la

valeur AK. Elle est utilise pour le chiffrement des cls
TEK

TEK
La cl de chiffrement de trafic TEK est gnre par la

station de base et transmise chiffre au client au moyen
de la cl KEK. Elle est utilise pour le cryptage des
trames de donnes
Cl CMAC ou HMAC de la voie

montante
C/HMAC_Key_U
Cette cl est en rgle gnrale dduite de AK, de

ladresse MAC du client et de lidentifiant de la station
de base. Elle authentifie les messages de la voie
montante
Cl CMAC ou HMAC de la voie

descendante
C/HMAC_Key_D
Cette cl est en rgle gnrale dduite de AK, de

ladresse MAC du client et de lidentifiant de la station
de base. Elle authentifie les messages de la voie
descendante
Group Key Encryption Key

GKEK
Cette cl est gnre par la station de base et transmise

chiffre au client, laide de la cl TEK. Elle est utilise
pour le chiffrement dune cl de groupe GTEK (Group
Traffic Encryption Key)
Cl de groupe de la voie
descendante
C/HMAC_Key_GD
Cette cl est obtenue partir de la valeur GKEK. Elle

est utilise par certains messages du protocole PKMv2
Group Traffic Encryption Key

GTEK
La cl GTEK est produite de manire alatoire par la

station de base et diffuse aux clients chiffre par la cl
GKEK. Elle est utilise pour transmettre des
informations aux membres dun groupe
MBS Transport Key

MTK
La cl MTK est dduite dune cl GTEK et dune cl

secrte MAK (MBS AK) dont le mode de distribution
nest pas prcis par le standard. Cette valeur peut tre
utilise pour des services de diffusion, telle que
tlvision page
Tableau 4.1.1. Rcapitulatif des cls symtriques dfinies dans 802.16e
La scurit du WiMAX
28
4.1.1. La fonction Dot16KDF

Lalgorithme Dot16KDF (Key Derivation Function) est bas sur les procdures
CMAC ou HMAC en fonction de la politique dauthentification.
Le pseudo code prsent aux figures 4.1.1.1. et 4.1.1.2. montre les dtails du
calcul avec les fonctions CMAC et HMAC. Le caractre | indique une opration
de concatnation. La fonction Truncate(valeur binaire, n) ralise lextraction des (n)
bits les plus significatifs (partie gauche) dune valeur binaire.
Dot16KDF(key, astring, keylength), utilisant lalgorithme CMAC
{ result = null;
Kin = Truncate (key, 128);
for (i = 0;i <= int((keylength-1)/128); i++) {
result <= result | Truncate (CMAC(Kin, i | astring | keylength), 128); }
return Truncate (result, keylength); }
Figure 4.1.1.1. Pseudo-code de Dot16KDF bas sur la fonction CMAC
Dot16KDF(key, astring, keylength), utilisant lalgorithme HMAC

{ Kin = Truncate (key, 160);
return Truncate (SHA-1(astring | Kin), keylength); }
Figure 4.1.1.2. Pseudo-code de Dot16KDF bas sur la fonction HMAC
4.1.2. La cl dauthentification AK et les cls pre-PAK, MSK, EIK, PMK et PMK2

Quatre scnarii dauthentification sont possibles dans un contexte PKMv2, (1)
une authentification mutuelle RSA (sans session EAP), (2) une session EAP simple
ou (4) double (sans pr authentification RSA), (4) une pr authentification RSA avec
une session EAP simple.
Au terme dune procdure dauthentification de type PKMv2-RSA (cf. section
4.2.), une cl pre-PAK (Primary Authentication Key) est dlivre par la station de
base (BS) au mobile (MS), chiffre avec la cl RSA publique de ce dernier.
laide de la fonction Dot16KDF, on dduit deux cls, respectivement PAK
(Primary Authentication Key, 160 bits) et EIK (EAP Integrity Key, 160 bits)
calcules selon la formule suivante :
La scurit du WiMAX
29
EIK | PAK = Dot16KDF(pre-PAK, SS_MAC_Address | BSID | "EIK+PAK",

320)
dans laquelle SS_MAC_Address dsigne ladresse MAC du mobile et BSID
lidentifiant de la station de base.
Si une authentification RSA est ralise avant une session EAP, les messages
EAP sont protgs par la cl dintgrit EIK pralablement obtenue. la fin dune
session dauthentification PKMv2-EAP (cf. section 4.3.) et conformment aux
rgles du protocole EAP, une cl MSK (Master Session Key, 512 bits) est
disponible. Un couple de cls EIK (160 bits) et PMK (Pairwise Master Key, 160
bits) est construit laide du calcul suivant :
EIK | PMK = Truncate (MSK, 320)
Lorsquune deuxime session EAP est mise en uvre, elle produit une cl MSK2
(512 bits) partir de laquelle on obtient une cl PMK2 (160 bits) telle que :
PMK2 = Truncate (MSK, 160)
En fonction des cls disponibles (PAK, PMK, PMK2) la cl dautorisation AK
(160 bits) est produite selon le pseudo code dcrit la figure 4.1.5.1. (le signe +
indique une opration de OU EXCLUSIF).
4.1.2. Les cls KEK et TEK
La cl KEK (128 bits) est calcule laide de la fonction Dot16KDF. Elle est
utilise par exemple pour le chiffrement des cls TEK et GKEK (Group Key
Encryption Key) dlivres par la station de base. Le dtail du calcul est prsent la
section 4.5.1. La cl TEK est gnre de manire alatoire par la station de base,
puis chiffre par la cl KEK.
4.1.3. Les cls GKEK et GTEK
La cl GKEK (Group Key Encryption Key - 128 bits) est gnre de manire
alatoire par la station de base puis chiffre par lalgorithme cryptographique
associ TEK.
La cl GTEK (Group Traffic Encryption Key) est produite alatoirement par la
station de base puis chiffre par les cls GKEK ou TEK, dans des messages adresss
soit en mode diffusion (multicast) soit un destinataire unique (unicast).
La scurit du WiMAX
30
4.1.4. La cl MTK
La cl MTK (MBS Transport Key) est dduite dune cl MAK (MBS AK) dont la
mthode de distribution nest pas dcrite par le standard IEEE 802.16e.
MTK = Dot16KDF(MAK, MGTEK | "MTK", 128)
MGTEK est la cl GTEK courante, associe au MBS. MTK est utilise pour le
chiffrement du trafic MBS, cest ,dire pour tout type de service bas sur des
mcanisme de diffusion (Pay TV, etc).
4.1.5. Les cls MAC
Les cls associes lalgorithme CMAC (CMAC_KEY_U et CMAC_KEY_D)
sont dduites par la relation suivante :
CMAC_KEY_U | CMAC_KEY_D | KEK =
Dot16KDF(AK, SS_MAC_Address | BSID | "CMAC_KEYS+KEK", 384)
Une cl additionnelle est utile pour certains messages PKMv2 (par exemple
PKMv2 Group-Key-Update-Command).
CMAC_KEY_GD = Dot16KDF(GKEK, "GROUP CMAC KEY",128).
Les cls associes lalgorithme HMAC sont dduites par la relation suivante :
HMAC_KEY_U | HMAC_KEY_D | KEK =
Dot16KDF(AK, SS_MAC_Address | BSID | "HMAC_KEYS+KEK", 448)
Une cl additionnelle est utile pour certains messages PKMv2 ( par exemple
PKMv2 Group-Key-Update-Command).
HMAC_KEY_GD = Dot16KDF(GKEK, GROUP HMAC KEY, 160).
Les messages EAP peuvent tre associs des signatures CMAC ou HMAC
dont les cls (128 ou 160 bits) sont dduites dune cl dintgrit EIK, laide des
procdures suivantes (respectivement lorsque les algorithmes CMAC ou HMAC
sont slectionns).
CMAC_KEY_U | CMAC_KEY_D =
Dot16KDF(EIK, SS_MAC_Address | BSID | "CMAC_KEYS", 256) ou
La scurit du WiMAX
31
HMAC_KEY_U | HMAC_KEY_D =
Dot16KDF(EIK, SS_MAC_Address | BSID | "HMAC_KEYS", 320)
Le protocole SA-TEK 3-Way Handshake utilise un identifiant de cl AK,
nomm AKID (64 bits), obtenu par la relation suivante :
AKID = Dot16KDF(AK, AK_SN | SS_MAC_Address | BSID | "AK", 64),
loctet AK_SN est obtenu en rajoutant quatre bits nuls, lindex de la cl AK.
La scurit du WiMAX
Authentification RSA
RSA(pre-PAK,SSpk)
Pre-PAK
Authentification EAP
(simple ou double session)
Calcul de EIK et PAK

EIK | PAK = Dot16KDF(pre-PAK, SS_MAC_Address| BSID | "EIK+PAK", 288)
Calcul de EIK, PMK, PMK2
EIK | PMK = truncate (MSK,320)
PMK2 = Truncate(MSK,160)
Calcul de AK
If (PAK and PMK) // Pr authentification et simple session EAP
AK = Dot16KDF (PAK+PMK, SS_MAC_Address| BSID | PAK | "AK", 160)
Else If (PMK and PMK2) // Double session EAP
AK= Dot16KDF(PMK+PMK2,SS_MAC_Address|BSID | PAK | AK,160)
Else // Pr authentification OU (EXCLUSIF) simple session EAP
If (PAK) // Pr authentification uniquement
AK = Dot16KDF (PAK, SS_MAC_Address | BSID | PAK | "AK", 160)
Else // Simple session EAP uniquement
AK = Dot16KDF(PMK, SS_MAC_Address | BSID | "AK", 160)
Endif
Endif
TEK{KEK}, GKEK{KEK}, GTEK{GKEK}

MTK = Dot16KDF(MAK, MGTEK| "MTK ", 128)
Calcul de cls CMAC et HMAC
CMAC_KEY_U | CMAC_KEY_D | KEK = Dot16KDF(AK, SS_MAC_Address | BSID |
CMAC_KEYS+KEK", 384)
CMAC_KEY_GD = Dot16KDF(GKEK, "GROUP CMAC KEY",128)
CMAC_KEY_U | CMAC_KEY_D =
Dot16KDF(EIK,BS_MAC_Address|BSID|CMAC_KEYS,256)
HMAC_KEY_U | HMAC_KEY_D | KEK = Dot16KDF(AK, SS_MAC_Address | BSID |
"HMAC_KEYS+KEK", 448)
HMAC_KEY_GD = Dot16KDF(GKEK, "GROUP HMAC KEY", 160)
HMAC_KEY_U | CMAC_KEY_D =
Dot16KDF(EIK,BS_MAC_Address|BSID|HMAC_KEYS,320)
Figure 4.1.5.1. Rsum du calcul des cls IEEE 802.16e
32
La scurit du WiMAX
33
4.2. Authentification de type PKMv2-RSA
Figure 4.2.1. Le protocole PKMv2-RSA
Le protocole PKMv2 RSA utilise quatre types de messages, PKMv2 RSARequest, PKMv2 RSA-Reply, PKMv2 RSA-Acknowledgement, ou PKMv2 RSAReject.
Le mobile client MS gnre un nombre alatoire (MS_Random) et linsre dans
un message RSA-Request qui transporte galement son certificat X.509, un
identifiant dassociation de scurit (SAID) et une signature RSA (SigSS), ralise
laide de sa cl prive.
La station de base vrifie la validit de la signature du message prcdent et
produit un message RSA-Reply qui comprend le nombre MS_Random fourni
prcdemment par le client, un nombre alatoire (BS_Random) produit par la station
de base, son certificat X.509, une cl pre-PAK chiffre avec la cl publique du
mobile client et une signature (SigBS) ralise laide de la cl prive de cette
dernire. Le fait de retourner le mme nombre MS_Random va assurer le client que
le message a bien t produit en rponse sa demande.
Le mobile analyse le message RSA-Reply, et indique le succs de lopration
dauthentification par un message RSA-Acknowledgement identifi par le champ
BS-Random, qui comporte le statut de lopration (AuthResult), une information
optionnelle (Display-String), et une signature SigSS.
En cas de succs de la procdure, les deux parties calculent une cl dintgrit
EIK (utilise pour scuriser les changes EAP) et une cl PAK.
La scurit du WiMAX
34
4.3. Authentification de type PKMv2-EAP

Dans le cas dune session simple PKMv2-EAP, les paquets sont transports par
des messages PKMv2 Authenticated-EAP-Transfer (signs par une cl EIK) ou
PKMv2 EAP-Transfer si la procdure dauthentification mutuelle RSA na pas t
pralablement employe (puisque dans ce cas aucune cl EIK nest disponible).
Figure 4.3.1. Une simple authentification EAP.
Lorsque lusage dune double session a t ngocie entre les deux parties
(mobile et station de base), le client indique, de manire optionnelle, le dbut du
dialogue par un message PKMV2 EAP-Start, ne comportant aucun attribut.
La double session est une technique qui typiquement utilise une premire
authentification du serveur laide du protocole TLS (la version standardise du
clbre protocole de scurit SSL, le cadenas des navigateurs), puis met profit le
canal scuris pralablement cr, pour une excution dune deuxime session,
protge des coutes indiscrtes, par des mcanismes garantissant la confidentialit
et l intgrit des information changes.
La premire session utilise des messages PKMv2 EAP-Transfer sans empreinte
HMAC ou CMAC. Lindication EAP-Success, marquant la fin de ce dialogue, est
transmise par la station de base laide de PKMv2 EAP-Complete, qui inclut une
signature base sur la cl EIK. Le mobile vrifie la validit de ce message et calcule
PMK ainsi quune nouvelle valeur EIK.
La deuxime session dbute par un message PKMV2 EAP-Start sign, laide
de lalgorithme HMAC ou CMAC, par la cl EIK. Par la suite, les paquets EAP sont
transports dans des messages PKMv2 Authenticated-EAP-Transfer protgs par
HMAC ou CMAC (associs la cl EIK).
La scurit du WiMAX
35
En cas de succs de la deuxime authentification, le mobile et la station de base

gnrent la cl dauthentification AK, puis dmarrent une procdure SA-TEK 3 way
handshake.
Figure 4.3.2. Une double session EAP.
Aprs la premire occurrence dune double session EAP, les instances suivantes,
qualifies de re-authentification, utilisent des mcanismes de scurit lgrement
diffrents.
Un dialogue de r-authentification se produit lorsque une cl AK est dj
disponible, cest dire que la double session EAP prcdente sest acheve avec
succs.
La premire session dbute par le message PKMv2 EAP-Start sign par la cl
CMAC_KEY_U ou HMAC_KEY_U dduite de la valeur courante de AK
(H/CMAC_KEY_U{AK}). Par la suite les paquets EAP sont transports par des
messages EAP-Transfer. Lindication EAP-Success, marquant la fin de cette
session, est transmise par la station de base laide de PKMv2 EAP-Complete, qui
comporte une signature dduite de la cl AK (H/CMAC_KEY_U{AK}).
La deuxime session commence par un message PKMV2 EAP-Start sign,
laide de lalgorithme HMAC ou CMAC par la cl H/CMAC_KEY_U{AK}. Par la
suite les paquets EAP sont transports par des messages PKMv2 AuthenticatedEAP-Transfer munis dempreintes HMAC ou CMAC (lies la cl AK courante).
La scurit du WiMAX
36
Figure 4.3.3. R Authentification.
En cas de succs de la deuxime session EAP, le mobile et la station de base

gnrent une nouvelle cl dauthentification AK, et entament une procdure SA-TEK
3 way handshake.
4.4. SA-TEK 3-way Handshake
Ce protocole ralise un mcanisme de handover (changement de station de base
rapide). Avant son excution, le mobile et la station de base doivent tre en
possession dune cl AK commune et des cls ncessaires aux calculs HMAC ou
CMAC.
Pour la premire instance du TEK 3-way Handshake ou lors dune r
authentification, la station de base gnre un nombre alatoire (BS_Random) et
transmet un message PKMv2 SA-TEK-Challenge, qui comporte la valeur
BS_Random, un identifiant AKID de cl de session (AK), et une signature
HMAC/CMAC.
AKID est lidentifiant de la cl AK courante (associe lattribut Sequence-KeyNumber) ou de la nouvelle instance de AK, dans le cas dune r authentification. La
norme prcise la procdure ncessaire pour lobtention de cette valeur. Les cls des
algorithmes HMAC/CMAC sont dduites de AK.
La scurit du WiMAX
37
Figure 4.4.1 Le SA-TEK 3-ways handshake
Le mobile rpond cette sollicitation par un message PKMv2 SA-TEK sign par
des cls dduites de AK, identifi par AKID. Ce message comporte galement la
liste des algorithmes cryptographiques (les Security Capabilities) supports par le
client.
La station de base dlivre alors le dernier message PKMv2 SA-TEK-Response,
qui inclut dans le cas dun handover (changement de la station de base), un attribut
SA_TEK_Update contenant, pour chaque association de scurit, les valeurs des
cls TEK, GKEK et GTEK, les deux premiers lments tant chiffrs par KEK et le
la dernier par GKEK.
4.5 Procdure de distribution de cls TEK
Figure 4.5.1. La distribution des cls TEK
La scurit du WiMAX
38
Les cls TEK sont alloues de manire analogue la version IEEE-802.16-2004,

et la distribution repose sur les messages PKMv2 Key-Request, PKMv2 Key-Reply
et PKMv2 Key-Reject. Lattribut TEK-Parameters comporte les cls TEK et GKEK
chiffres KEK.
4.6 Algorithme (optionnel) de mise jour des cls GTEK
La cl GTEK est en premier lieu distribue laide des messages Key-Request et
Key-Reply. La mise jour optionnelle est ralise par le message PKMv2 GroupKey-Update, associ une empreinte HMAC ou CMAC qui fait intervenir une des
cls H/CMAC_KEY_U ou H/CMAC_KEY_D selon la valeur de lattribut KeyPush-Modes.
Figure 4.6.1 Mise jour des cls GTEK
4.7. Association de scurit

Il existe trois classes dassociation de scurit, lies plusieurs types de
connexions, unicast, multicast et MBS :
SA unicast est associe une connexion unicast et comporte les lments
suivants : un SAID (16 bits), la cl KEK obtenue partir de AK, deux cls de
chiffrement de donnes TEK0 et TEK1 (128 bits) et leur dure de vie, les numros de
paquets PN0 et PN1 et les compteurs de rception de trames RxPN0 et RxPN1 (de 32
bits) utiliss pour le chiffrement des trames ;
SA multicast est associe une connexion multicast (ou Groupe Security
Association) et utilise les cls GKEK et GTEK ;
SA MBS est associe un MBS et inclus les trois cls MAK (160 bits),
MGTEK (128 bits), et MTK (128 bits).
La scurit du WiMAX
39
4.8. Algorithmes de chiffrement de donnes

La liste des algorithmes de chiffrement de donnes (et de leur identifiant) est la
suivante; pas de chiffrement (0), DES en mode CBC avec une cl de 56 bits (1),
AES en mode CCM avec une cl de128 bits (2), AES en mode CBC avec une cl de
128 bits (3), AES en mode CTR avec une cl de 128 bits (128).
4.9. Algorithmes associs aux cls TEK
La liste des algorithmes associs la cl TEK (et de leur identifiant) est la
suivante : Rserv (0), 3-DES en mode EDE avec une cl de 128 bits (1), RSA avec
une cl de 1024 bits (2), AES en mode ECB avec une cl de 128 bits (3), AES en
mode Key-Wrap, avec une cl de 128 bits (4).
4.10. En rsum
Le client obtient deux types de CIDs au terme de la procdure de ranging, le
Basic CID utilis pour le transport des messages PKM et le Primary CID associ
aux messages assurant ltablissement des connections. Un troisime CID (le
Secondary CID), dlivr par la station de base au terme de la procdure
denregistrement, est utilis pour des services tels que lallocation dune adresse IP
(DHCP).
Au terme de la phase dautorisation et dchange de cls, le client possde une
cl dautorisation AK (ainsi que diverses cls de signature) et son index, le KeySequence-Number.
Trois types dinformations (Unicast, Multicast, MBS) sont protges laide
dassociations de scurit (identifies par des index SAID), qui mmorisent les cls
de chiffrements ainsi que les algorithmes utiliss. Ces associations de scurit sont
mises jour par des procdures de distribution de cls, dans lesquelles le client est
authentifi grce ses cls de signature (C/HMAC), que la station de base retrouve
laide des paramtres BasicCID, Key-Sequence-Number et SAID.
La scurit du WiMAX
40
5. Le rle de la carte puce dans les infrastructures WiMAX

Dans les rseaux GSM et UMTS, les oprateurs identifient leurs abonns et
grent leurs forfaits laide de cartes puce SIM ou USIM. Ces modules de scurit
stockent pour lessentiel une identit du client (un IMSI) et ralisent
lauthentification de lusager laide dun algorithme cryptographique symtrique
(A3/A8 ou Milenage) muni dune cl secrte, qui est intgralement excut dans
lespace protg et sr du module de scurit.
Les infrastructure WiMAX et plus particulirement Wi-Mobile utilisent des
bandes de frquences soumises licence, il est donc probable que, contrairement
aux rseaux Wi-Fi, leur accs ne sera pas libre mais contrl, ce qui implique en
particulier un niveau de scurit suffisant pour viter des fraudes massives et assurer
une exploitation commerciale.
Cependant aucun module de scurit nest actuellement dfini par les normes
IEEE 802.16. Le but de cette section est dintroduire quelques services, qui de
manire analogue au rseau GSM, pourraient tre fournis par une carte puce
spcifiquement adapte aux standards IEEE 802.16.
En premier lieu les normes IEEE 802.16 utilisent ct client un certificat X.509
et une cl RSA prive. Une cl dauthentification AK ou Pre-PAK est dlivre par la
station de base et chiffre avec la cl publique du client.
Figure 5.1. Services scuriss par carte puce pour IEEE-802.16-2004
Ainsi, une carte puce 802.16-2004 peut par exemple assurer le stockage du
certificat X.509 du client et raliser le dchiffrement des cls AK (802.16-2004)
dans un environnement informatique sr. A partir de la cl AK, dont la valeur nest
pas exporte par la carte, cette dernire calcule les valeurs KEK, HMAC_KEY_D,
HMAC_KEY_U, et HMAC_KEY_S. Schmatiquement la carte gre donc
lassociation de scurit dautorisation. Nous soulignerons galement que lidentit
du client est clairement reprsente par un certificat X.509.
La scurit du WiMAX
41
La synthse dune carte pour lIEEE 802.16e est plus complexe. Tout dabord, la
procdure didentification et dauthentification du client est base sur un certificat
X.509 et/ou dautres paramtres associs aux protocole EAP, comme par exemple
un IMSI (import du GSM) utilis par le protocole EAP-SIM [RFC 4186].
Figure 5.2. Services scuriss par carte puce pour IEEE-802.16e
Dans le cas du protocole PKMv2-RSA (cf. figure 5.2), la carte dcrypte la cl

pre-PAK chiffre par la station de base laide de la cl publique du client. Elle
calcule galement les valeurs de signatures SigSS(Message) insres dans les
messages PKMv2-RSA-Request et PKMv2-RSA-Acknowledgment (cf. section 4.2).
A partir de la valeur pre-PAK elle produit les paramtres EIKRSA et PAK. La cl
EIKRSA est exporte afin de permettre au terminal de vrifier et de calculer des
valeurs dempreintes HMAC ou CMAC utilisant des cls dduites de EIK.
Lorsque le protocole EAP est employ avec une session simple ou double, la
carte gre de manire autonome les messages EAP. On trouvera dans [LCN 03]
[PUJ 04] des informations plus dtailles sur cette technologie, couramment
dsigne Carte EAP.
Requtes EAP
Rponses EAP
Collecte de la cl MSK
Figure 5.3. La carte EAP
La scurit du WiMAX
42
La carte 802.16e produit, au terme de la premire session, une paire de cls

EIKEAP et PMK, et en fin dune possible deuxime instance, une valeur PMK2. Le
paramtre EIKEAP est export afin de permettre au terminal de vrifier et de calculer
des valeurs dempreintes HMAC ou CMAC utilisant des cls dduites de la valeur
EIK. A laide des valeurs secrtes PAK, PMK et PMK2 la carte calcule et exporte
les cinq valeurs H/CMAC_KEY_U, H/CMAC_KEY_D, et KEK, dduites de la cl
AK. A partir de la cl AK, stocke dans la carte, et donc secrte, cette dernire
calcule des valeurs AKID qui sont par nature publiques et donc exportables. La cl
MTK (dduite de la valeur secrte MAK) est calcule en fonction de la valeur
courante GTEK.
6. Conclusion
Dans ce chapitre nous avons tent de raliser une prsentation concise des
mcanismes de scurit, dfinis pour les rseaux mergents WiMAX. On constate
lexistence de multiples options, permettant de mettre en oeuvre des infrastructures
dauthentification de type PKI, ou au contraire des architectures bases sur des cls
symtriques, similaires aux environnements actuels GSM ou UMTS.
Le dploiement du WiMAX tablira probablement un standard de facto, nous
pensons cependant que des modules de scurit, plus prcisment des cartes puce,
seront indispensables pour assurer un fonctionnement sr et conomiquement viable,
de cette nouvelle gnration de linternet sans fil.
La scurit du WiMAX
43
Bibliographie
[DOCSIS 05] Data-Over-Cable Service Interface Specifications, Baseline Privacy Plus

Interface Specification, DOCSIS 1.1, 2005.
[IEEE-802.16 01] Institute of Electrical and Electronics Engineers, IEEE Standard for Local
and metropolitan area networks part 16: Air Interface for Fixed and Mobile Broadband
Wireless Access System, IEEE 802.16 Std 2001.
[IEEE-802.16 04] Institute of Electrical and Electronics Engineers, IEEE Standard for Local
Wireless Access System, IEEE 802.16 Std 2004.
[IEEE-802.16e 06] Institute of Electrical and Electronics Engineers, IEEE Standard for Local
Wireless Access Systems Amendment 2: Physical and Medium Access Control Layers for
Combined Fixed and Mobile Operation in Licensed Bands and Corrigendum 1, 2006.
[IEEE-802.1x 04] Institute of Electrical and Electronics Engineers, IEEE Standard for Local
and metropolitan area networks part 11: Port-Based Network Access Control, IEEE 802.1x
Std 2004
[LCN 03] Les cahiers du numrique Volume 4 n3-4/2003, La scurit lre du
numrique, chapitre Les rseaux sans fil 802.11 , Herms, 2003.
[NIST05] NIST, Special Publication 800-38B Draft, Recommendation for Block Cipher
Modes of Operation: The CMAC Method for Authentication, Mars 2005.
[PKCS 1] RSA Laboratories, PKCS #1, RSA Cryptography Standard, Juin 2002.
[PUJ 04] PUJOLLE G., LOUTREL M., URIEN P., BORRAS P., PLATEAU D., Scurit Wi-Fi,
Eyrolles 2004.
[RFC 868] The Internet Engineering Task Force, IETF, RFC 868, Time Protocol, Mai 1983.
[RFC 1123] The Internet Engineering Task Force, IETF, RFC 1123, Requirements for
Internet Hosts -- Application and Support, Octobre 1989.
La scurit du WiMAX
44
[RFC 2104] The Internet Engineering Task Force, IETF, RFC 2104, HMAC: Keyed-Hashing
for Message Authentication, Fvrier 1997.
[RFC 2131] The Internet Engineering Task Force, IETF, RFC 2131, Dynamic Host
Configuration Protocol, Mars 1997.
[RFC 2349] The Internet Engineering Task Force, IETF, RFC 2349, TFTP Timeout Interval
and Transfer Size Options, Mai 1998.
[RFC 2459] The Internet Engineering Task Force, IETF, RFC 2459, Internet X.509 Public
Key Infrastructure Certificate and CRL Profile Time Protocol, Janvier 1999.
[RFC 3748] The Internet Engineering Task Force, IETF, RC 3748, Extensible Authentication
Protocol (EAP), Mars 2004.
[RFC 2716] The Internet Engineering Task Force, IETF, RFC 2716, PPP EAP TLS
Authentication Protocol, Octobre 1999.
[RFC 4186] The Internet Engineering Task Force, IETF, RFC 4186, Extensible
Authentication Protocol Method for Global System for Mobile Communications (GSM)
Subscriber Identity Modules (EAP-SIM), Janvier 2006.
[RFC 4187] The Internet Engineering Task Force, IETF, RFC 4187, Extensible
Authentication Protocol Method for 3rd Generation Authentication and Key Agreement
(EAP-AKA), Janvier 2006.
[RFC 4493] The Internet Engineering Task Force, IETF, RFC 4493, The AES-CMAC
Algorithm, Juin 2006.
La scurit du WiMAX
Glossaire
3-DES
AES
AK
AKID
ASA
BS
BSID
CMAC
CBC
CBC-MAC
CCM
CID
CTR
CPS
CS
DCD
DES
DL-MAP
EAP
ECB
EDE
EIK
FDD
FFT
GKEK
GMH
GTEK
HMAC
Triple Digital Encryption Standard

Advanced Encryption Standard
Authorization Key
AK IDentifier
Authentication and Service Authorization
Base Station
Base Station IDentification
Cipher-based Message Authentication Code
Cipher Block Chaining
Cipher Block Chaining Message Authentication Code
CTR mode with CBC-MAC
Connection IDentifier
CounTeR mode encryption
Common Part Sublayer
Downlink Channel Descriptor
Digital Encryption Standard
Downlink Map
Extensible authentication protocol
Electronic Code Book
Encrypt Decrypt Encrypt
EAP Integrity Key
Frequency Division Duplexing
Fast Fourier Transform
Group Key Encryption Key
Generic MAC Header
Group Traffic Encryption Key
Hashed Message Authentication Code
45
La scurit du WiMAX
HO
KEK
LOS
MAC
MAK
MBS
MIMO
MS
MSK
MTK
NLOS
OFDM
OFDMA
PAK
PHY
PMD
PKM
PMK
PS
Pre-PAK
QAM
QPSK
SAID
SC
SFID
SOFDMA
SN
SS
TDD
TEK
TLV
UL-MAP
UCD
HandOver
Key Encryption Key
Line Of Sight
Medium Access Control
MBS AK
Multicast and Broadcast Services
Multiple Input Multiple Output
Mobile Station
Master Session Key
MBS Transport Key
Non Line Of Sight
Orthogonal Frequency Division Multiplexing
Orthogonal Frequency Division Multiplexing Access
Primary Authorization Key
PHYsical Layer
Physical Medium Dependant
Privacy Key Management
Pairwise Master Key
Privacy Sublayer
Pre Primary AK
Quadrature Amplitude Modulation
Quadrature Phase Shift Keying
Security Association Identifier
Single Carrier
Service Flow IDentifier
Scalable Orthogonal Frequency Division Multiplexing Access
Sequence Number
Subscriber Station
Time Division Duplexing
Type Longueur Valeur
Uplink Map
Uplink Channel Descriptor
Index [Style : parties annexes]
46
La scurit du WiMAX
WiMAX
Base Station, 3
WiMAX
Basic CID, 15
WiMAX
Basic Connection ID, 11
BLR Voir boucle locale radio
boucle locale radio, 2
Connection IDentifier, 7
WiMAX
couche MAC, 6
WiMAX
couche Physique, 7
WiMAX
Couches basses, 4
Line Of Sight, 1
Non Line Of Sight, 1

WiMAX
PKM, 14
WiMAX
Primary Management CID, 11
WiMAX
Primary Management CID, 10
Secondary Management CID, 12
WiMAX
Secondary Management CID, 10
WiMAX
cl HMAC, 16
WiMAX
BS Voir Base Station
WiMAX
CID, 7
47
La scurit du WiMAX
48
1. Introduction ............................................................................................................ 1
1.1 Un bref historique............................................................................................. 1
1.2 Quelques marchs............................................................................................. 2
1.3 Topologie.......................................................................................................... 3
1.4. Evolution de la scurit dans les normes ......................................................... 4
2. Couches basses du WiMAX ................................................................................... 6
2.1. La couche MAC .............................................................................................. 7
2.2. La couche Physique ......................................................................................... 8
2.3. Connexions et primitives ................................................................................. 8
2.4 Structure des trames MAC.............................................................................. 10
2.5. Les trames dadministration (Management) .................................................. 11
2.6. Procdure de connexion dun client dans un rseau WiMAX ...................... 11
3. La scurit selon 802.16-2004.............................................................................. 14
3.1 Authentification, autorisation et distribution de cls ...................................... 15
3.1.1 Procdure dauthentification et autorisation par le protocole PKM......... 15
3.1.2 Procdure de distribution de cls TEK .................................................... 16
3.2. Associations de scurit................................................................................. 18
3.2.1. Association de scurit pour lauthentification des trames
dadministration................................................................................................ 18
3.2.2. Association de scurit pour le chiffrement des donnes ....................... 18
3.3. Elments cryptographiques............................................................................ 19
3.3.1. Chiffrement/dchiffrement de la cl AK ................................................ 19
3.3.2. Calcul de la cl KEK et des cls HMAC ................................................ 20
3.4. Crypto-Suites de chiffrement de la cl TEK avec KEK ................................ 21
3.5. Crypto-Suites de chiffrement de trames de donnes avec la cl TEK ........... 21
3.5.1. Crypto Suite 01, algorithme DES-CBC .................................................. 21
3.5.2. Crypto Suite 02, algorithme AES ........................................................... 21
3.5. Un rapide aperu des vulnrabilits de la norme 802.16-2004...................... 22
3.5.1 Attaques au niveau physique ................................................................... 22
3.5.2 Attaques au niveau MAC......................................................................... 23
4. La scurit selon 802.16e ..................................................................................... 24
4.1. Hirarchie des cls......................................................................................... 26
4.1.1. La fonction Dot16KDF........................................................................... 28
4.1.2. La cl dauthentification AK et les cls pre-PAK, MSK, EIK, PMK et
PMK2 ............................................................................................................... 28
4.1.2. Les cls KEK et TEK ............................................................................. 29
4.1.3. Les cls GKEK et GTEK........................................................................ 29
4.1.4. La cl MTK ............................................................................................ 30
4.1.5. Les cls MAC ......................................................................................... 30
4.2. Authentification de type PKMv2-RSA.......................................................... 33
4.3. Authentification de type PKMv2-EAP .......................................................... 34
4.4. SA-TEK 3-way Handshake ........................................................................... 36
4.5 Procdure de distribution de cls TEK ........................................................... 37
4.6 Algorithme (optionnel) de mise jour des cls GTEK................................... 38
4.7. Association de scurit .................................................................................. 38
La scurit du WiMAX
49
4.8. Algorithmes de chiffrement de donnes ........................................................ 39

4.9. Algorithmes associs aux cls TEK............................................................... 39
4.10. En rsum .................................................................................................... 39
5. Le rle de la carte puce dans les infrastructures WiMAX ................................. 40
6. Conclusion............................................................................................................ 42
Annexes
1- La machine dtats dauthentification.

Cette machine comporte six tats.
Elle est initialise ltat start dans lequel toutes les horloges sont hors service et
aucune session dauthentfication nest active.
Au terme de la procdure dtablissement de communication, le client a termin ses
ngociations (basic capabilities) avec la station de base et possde un Basic CID. Il
bascule alors dans ltat Autorize Wait, et transmet les deux messages
dadministration AuthInfo et AuthRequest.
Si le message AuthReply est reu, la machine transite ltat Authorized, qui
dclenche le dmarrage dune nouvelle procdure de distribution de cls TEK.
Lorsquune nouvelle session dauthentfication est ncessaire, le client passe ltat
Reauthorize Wait et dlivre alors un nouveau message AuthRequest. La bonne
rception dun message AuthReply permet de basculer ltat Authorized.
Dans ltat Authorize Reject Wait le client a reu une notification (Auth Reject)
indiquant un problme dauthentication temporaire ou dfinitif.
2 Pascal Urien
Figure 3.1.2.1 Machine dtat dauthentification.
En cas de problme dauthentfication permanent (notifi par un message

dadministration Auth Reject) la machine dtat est gele dans ltat Silent, et
indique cette situation la station de base, via un message dadministration Perm
Auth Reject.
2- La machine dtats de distribution de cls TEK

Cette machine comporte six tats.
Dans ltat Start aucune session de distribution de cl nest active.
Ltat Operationnal-Wait marque lmission dun message dadministration
KeyRequest, dont le but est lobtention dune paire de cls TEKs lies une
association de scurit SAID.
La rception dun message KeyReply provoque une transition ltat Operationnal.
Ltat Operational-Reauthorize-Wait est activ si aucune cl TEK nest disponible,
et quune session dautorisation est en cours.
La scurit du WiMAX
Le client transite ltat Rekey-Reauthorize-Wait lorsquil possde des cls TEK

valides et quune procdure dautorisation est en progrs.
Lorsquune cl TEK atteint sa dure de validit, le client passe ltat RekeyWait et
transmet un message KeyRequest vers la station de base.
Figure 3.1.4.1. Machine dtat de distribution des cls TEK.
3- Structure des messages PKM

Les messages PKM sont insrs dans des paquets PKM-REQ et PKM-RESP. Ils
comportent un entte de 2 octets indiquant un code du message (1 octet) et une
tiquette (identifier, 1 octet) telle que la valeur incluse dans la rponse soit gale
celle de la requte correspondante.
PKM-REQ_Message_Format(){
Management Message Type (1 octet) = 9 (requte) ou 10 (rponse)
Code (1 octet)
PKM identifier (1 octet)
Attributs encods sous forme TLV (Type Longueur Valeur) }
4 Pascal Urien
3.1 Les attributs de la norme 802.16- 2004
La liste des types des attributs TLV dfinis par la norme 2004 est la suivante,
Display-String (6), AUTH-Key (7), TEK (8), Key-Lifetime (9), Key-SequenceNumber (10), HMAC-Digest (11), SAID (12), TEK-Parameters (13), CBC-IV(14),
Error- (16), CA-Certificate (17), SS-Certificate (18), Security-Capabilities (19),
Cryptographic-Suite (20), Cryptographic-Suite-List (21), Version (22), SADescriptor (23), SA-Type (24), PKM Configuration Settings (27).
3.1.1 Display String (6)
Cest une chane de caractres en mode texte, informant lutilisateur dun problme
particulier.
3.1.2 AUTH-Key (7)
La cl dautorisation AK est un nombre binaire de 20 octets, partir de laquelle on
drive la cl de chiffrement de cl KEK et les cls dempreintes (HMAC) mises en
uvre pour les voies montantes et descendantes. Elle est transporte chiffre par la
cl RSA (128 octets) publique du client.
3.1.3 TEK (8)
Cest la cl de chiffrement des trames, chiffre par la cl de chiffrement de cl KEK.
La longueur est de 8 octets pour un chiffrement DES, 16 octets pour un chiffrement
AES, 24 octet pour un chiffrement AES Key Wrap.
3.1.4 Key-Lifetime (9)
Une valeur de 32 bits, indiquant la dure de vie dune cl cryptographique,
exprime en secondes.
3.1.5 Key-Sequence-Number (10)
Cet attribut reprsente lindex dune cl de chiffrement de trame TEK (cod sur 2
bits) ou dune cl dautorisation AK, PAK ou PMK (cod sur 4 bits).
3.1.6 HMAC-Digest (11)
Le rsultat (soit 20 octets) dune empreinte associe une cl (keyed SHA1 HMAC,
RFC 2104).
3.1.8 SAID (12)
La scurit du WiMAX
Lidentifiant de 16 bits dune association de scurit.

3.1.9 TEK-Parameters (13)
Cest une collection dattributs (TEK, Key-Lifetime, Key-Sequence-Number, CBCIV) dfinissant les paramtres fonctionnels lies une cl TEK, relativement une
association de scurit.
La version IEEE 802.16e comporte un cinquime lment
Sequence Number.
Associated GKEK
3.1.10 CBC-IV (15)

La valeur dun vecteur initial IV, associ un algorithme de chiffrement en mode
bloc. La taille du paramtre est gal la taille du bloc utilis par lalgorithme de
chiffrement.
3.1.11 Error-Code (16)
Un code derreur, cod sur un octet.
3.1.12 CA-Certificate (17)
Le certificat X.509 de lautorit de certification CA.
6 Pascal Urien
3.1.13 SS-Certificate (18)
Le certificat X.509 du client.
3.1.14 Security-Capabilities (19)
Une liste dattributs (Cryptographic-Suite-List, Version) indiquant les capacits
cryptographiques dun client et la version du protocole PKM quil supporte.
3.1.15 Cryptographic-Suite (20)
Un nombre de 3 octets identifiant lalgorithme de chiffrement des trames (Nul=0,
DES-CBC=1, AES-CCM=2,), lalgorithme authentification des trames (Nul=0),
et lalgorithme utilis par la cl de chiffrement de cl KEK (Nul=0, 3-DES EDE=1,
RSA 1024 bits=2, AES 128 bits=3).
3.1.16 Cryptographic-Suite-Liste (21)
Une liste de suite cryptographiques soit 5.n octets si n choix sont disponibles.
3.1.17 Version (22)
La version du protocole PKM est exprime laide dun octet.
3.1.18 SA-Descriptor (23)
Cest une liste dattributs (SAID, SA-Type, Cryptographic-Suite) prcisant les
proprits dune association de scurit (SA) identifie un SAID.
3.1.19 SA-Type (24)
Cet attribut dont la taille est gale un octet indique le type dune association de
scurit cest dire primaire (0 primary), statique (1 static) ou dynamique (2
dynamic).
3.1.20 PKM Configuration Settings (27)
Cest une liste de temps de garde (timeout) utiliss par les diffrentes machines
dtats du protocole PKM.
La scurit du WiMAX
3.2 Les attributs supplmentaires de la norme IEEE 802.16e- 2005

La version 802.16e 2005 incorpore de nouveaux attributs TLV, Configuration
Setting (27), EAP Payload (28), Nonce (29), Auth Result (30), SA Service Type
(31), Frame Number (32), SS_RANDOM (33), BS_RANDOM (34), pre-PAK (35),
PAK/AK Sequence Number (36), BS-Certificate (37), SigBS (38), MS-MAC
Address (39), CMAC-Digest (40), Key Push Modes (41), Key Push Counter (42),
GKEK (43), SigSS (44), AKID (45), Associated GKEK Sequence Number (46),
GKEK-Parameters (47).
3.2.1 PKMv2 Configuration Setting (27)
Cet attribut (un octet) spcifie le type de paramtre (Auth Reply, PKMv2 SA-TEKresponse) associ une opration PKMv2.
3.2.2 EAP-Payload (28)
Cet attribut transporte de manire transparente un paquet EAP.
3.2.3 Nonce (29)
Un nombre de 32 bits utilis pour protger les messages des attaques par re-jeu.
3.2.4 Auth result code (30)
Cette valeur code sur un octet indique le rsultat (succs, chec,) dune opration
dauthentification RSA.
3.2.5 SA Service type (31)
Cet attribut cod sur un octet dsigne le type de service (Unicast, Group multicast,
MBS, ) li une association de scurit.
3.2.6 Frame Number (32)
Un numro de trame de 24 bits.
3.2.7 SS_RANDOM (33)
Un nombre alatoire de 64 bits gnr par le mobile.
3.2.8 BS_RANDOM (34)
Un nombre alatoire de 64 bits gnr par la station de base.
8 Pascal Urien
3.2.9 Pre-PAK (35)
Une valeur de 128 octets chiffre par la cl RSA publique de 1024 bits du mobile.
3.2.10 BS_Certificate (37)
Le certificat X.509 de la station de base.
3.2.11 SigBS (38)
La signature RSA (ralise selon la norme PKCS#1 RSAES OAEP 1.5) dun
message, laide de la cl prive de la station de base.
3.2.12 MS-MAC address (39)
Ladresse MAC (6 octets) du mobile.
3.2.13 CMAC Digest (40)
Cet attribut comporte un numro de paquet (CMAC_PN, 32 bits) et une empreinte
CMAC (selon la norme SP 800-38B) de 64 bits, utilisant un algorithme AES muni
dune cl de 128 bits.
3.2.14 Key Push Mode (41)
Cette valeur code sur un octet identifie le type de cl (GKEK ou GTEK) prsente
dans un message PKMv2 Group Key Update.
3.2.15 Key Push Counter (42)
Un compteur de 16 bits destin viter les attaques de type re-jeu.
3.2.16 GKEK (43)
Une valeur (16 octets) chiffre de la cl GKEK laide de la cl KEK obtenue
avec la cl dauthentification AK.
3.2.17 SigSS (44)
La signature RSA (ralise selon le standard PKCS#1 RSAES OAEP 1.5) dun
message, laide de la cl prive du mobile.
La scurit du WiMAX
3.2.18 AKID (45)

Lidentifiant (8 octets) dune cl AK.
3.4 Les messages de la norme 802.16-2004
Les principaux types de messages de la norme 2004 sont les suivants, SA Add (3),
Auth Request (4), Auth Reply (5), Auth Reject (6), Key Request (7), Key Reply (8),
Key Reject (9), Auth Invalid (10), TEK Invalid (11), Auth Info (12).
3.4.1 Le message SA Add (code 3)
Ce message est insr dans un PKM-RESP dlivr par une station de base. Il permet
dtablir dynamiquement des associations de scurit. Un client ragit cette
notification par la demande dun cl de chiffrement de trafic (TEK) pour chaque
association de scurit.
Ce message contient les attributs suivants
- Key-Sequence-Number, le numro de la cl dautorisation AK
- Un ou plusieurs SA-Descriptor,
- HMAC-Digest
3.4.2 Le message AuthRequest (code 4)
Le message Authorization Request est envoy par le client la station de base. Il
transporte les attributs suivants,
- SS-Certificate, le certificat X.509 du client.
- Security Capabalities, la description des algorithmes cryptographiques supports
par le client.
- SAID, le SAID primaire du client gal au basic CID obtenu lors de la phase
dtalonnage (ranging).
3.4.3 Le message AuthReply (code 5)
Le message Autorization Reply est la rponse AuthRequest. Il comporte les
attributs suivants
- AUTH-Key, la cl dautorisation AK chiffre avec la cl publique du client.
10 Pascal Urien
- Key-Lifetime, la dure de vie de la cl AK.
- Key-Sequence-Number, un index de la cl AK.
- un ou plusieurs SA-Descriptor(s), une liste dassociations de scurit pour
lesquelles le client peut obtenir des cls de chiffrements (TEKs).
3.4.4 Le message AuthReject (code 6)
Ce message est typiquement mis par la station de base lorsque le client prsente un
certificat incorrect. Il inclut les attributs suivants
- Error-Code, un code derreur prcisant la nature du problme rencontr.
- Display-String, une indication optionnelle prcisant la nature de lerreur.
3.4.5 Le message KeyRequest (code 7)
Ce message est une demande de cl TEK associ avec un SAID particulier et
comprend les attributs suivants,
- Key-Sequence-Number, lindex dune cl AK.
- SAID, identifiant de lassociation de scurit.
- HMAC-Digest, une empreinte de type keyed-SHA1.
3.4.6 Le message KeyReply (code 8)
Cest une rponse KeyRequest, elle contient la valeur dune cl de chiffrement de
trafic (TEK) chiffre avec la cl de chiffrement de cl (KEK).
- Key-Sequence-Number, lindex de la cl AK
- SAID, lidentifiant de lassociation de scurit
- TEK-Parameters, les nouveaux paramtres TEK
- TEK-Parameters, les prochains paramtres TEK
La scurit du WiMAX
11
3.4.7 Le message KeyReject (code 9)

Ce message est dlivr par la station de base, lorsquun SAID nest plus valide,
typiquement parce que sa dure de vie est dpasse. Il comporte les informations
suivantes,
3.4.8 Le message Auth Invalid (code 10)
Le message Autorization Invalid est dlivr par la station de base pour notifier la
rception dun prcdent message utilisant une cl TEK errone. Il inclut les
attributs suivants
- Error-Code, un code derreur prcisant la nature du problme rencontr
3.4.9 Le message TEK Invalid Attribut (code 11)
Ce message indique une erreur dtecte par la station de base, provoqu par une
valeur incorrecte de lindex dune cl dautorisation AK. Il contient les attributs
suivants
- Key-Sequence-Number, un index de cl AK
- Error-Code, un code derreur prcisant la nature du problme rencontr
3.4.10 Le message Auth Info (code 12)
Le message Authentication Info est envoy par le client vers la station de base. Il ne
contient quun seul attribut, CA-Certificate, le certificat X.509 du client encod sous
une forme binaire brute (selon la syntaxe ASN.1).
12 Pascal Urien
3.5 Les messages supplmentaires de la norme 802.16e-2005
Le standard 802.16e 2005 a introduit de nouveaux messages, PKMv2 RSA-Request
(13), PKMv2 RSA-Reply (14), PKMv2 RSA-Reject (15), PKMv2 RSAAcknowledgment (16), PKMv2 EAPStart (17), PKMv2 EAP-Transfer (18), PKMv2
Authenticated EAP-Transfer (19), PKMv2 SA TEK Challenge (20), PKMv2 SA TEK
Request (21), PKMv2 SA TEK Response (22), PKMv2 Key-Request (23), PKMv2
Key-Reply (24), PKMv2 Key-Reject (25), PKMv2 SA-Addition (26), PKMv2 TEKInvalid (27), PKMv2 Group-Key-Update-Command (28), PKMv2 EAP-Complete
(29), PKMv2 Authenticate EAPStart (30).
3.5.1 Le message PKMv2 RSA-Request (code 13)
Le mobile envoie ce message la station de message lors du dbut dune session
dautorisation en mode RSA. Les attributs sont les suivants
- MS_Random, un nombre alatoire de 64 bits gnr par le mobile
- MS_Certificate, le certificat X.509 du mobile
- SAID, lidentifiant de lassociation de scurit (le Basic CID dans ce cas)
- SigSS, une signature RSA des autres attributs du message.
3.5.2 .Le message PKMv2 RSA-Reply message (code 14)
Cest une rponse PKMv2 RSA-Request, elle contient les informations suivantes
- BS_Random, un nombre alatoire de 64 bits gnr par la station de base
- Encrypted pre-PAK, la valeur de la cl pre-PAK, concatne ladresse MAC du
mobile et chiffre par la cl publique RSA de ce dernier
- Key Lifetime, la dure de vie de la cl PAK
- Key-Sequence-Number, lindex de la cl PAK
- BS_Certificate, le certificat X.509 de la station de Base
- SigBS, une signature RSA des attributs du message.
La scurit du WiMAX
13
3.5.3 Le message PKMv2 RSA-Reject (code 15)

Ce message indique labandon dune prcdente requte dautorisation par la station
de base.
- BS_Random, un nombre alatoire de 64 bits gnr par la station de base.
- Error-Code, un code derreur
- Display-String, un message derreur optionnel
- SigBS, une signature RSA des attributs du message.
3.5.4 Le message PKMv2 RSA-Acknowledgement (code 16)
Ce message dlivr par le mobile est une rponse PKMv2 RSA-Reply ou PKMv2
RSA-Reject. Il comporte les attributs suivants
- BS_Random, un nombre alatoire de 64 bits gnr par la station de base
- Auth Result Code, indique le rsultat (russite ou chec) de lautorisation RSA
- SigSS, une signature RSA des autres attributs du message.
3.5.5 Le message PKMv2 EAP Start (code 17)
Ce message notifie linitialisation dune session EAP. En cas de re-authentification
(uniquement) une empreinte et un index de cl doivent tre inclus.
- Key-Sequence-Number, index dune cl dauthentification AK
- HMAC Digest / CMAC Digest, empreinte du message.
3.5.6 Le message PKMv2 EAP Transfer (code 18)
Ce message transporte un paquet EAP. En cas de re-authentification (seulement)
une empreinte et un index de cl doivent tre inclus.
- EAP Payload, un paquet EAP
14 Pascal Urien
- Key-Sequence-Number, index dune cl dauthentification AK
- HMAC Digest / CMAC Digest, empreinte du message.
3.5.7 Le message PKMv2 Authenticated EAP Transfer (code 19)
Ce message transporte un paquet EAP, il est protg par la cl EIK
- Key-Sequence-Number, lindex de la cl PAK (optionnel)
- EAP Payload, un paquet EAP
- HMAC/CMAC Digest, une empreinte associe la EIK.
3.5.8 Le message PKMv2 SA-TEK-Challenge (code 20)
La station de base met ce premier message du protocole 3-ways SA-TEK
handshake lors de la premire autorisation ou avant toute procdure de reauthentification.
- BS_Random, un nouveau nombre alatoire de 64 bits gnr par la station de base
- AKID, lidentifiant de la cl AK
- Key-Lifetime, la dure de vie de la cl PMK
- HMAC/CMAC Digest, lempreinte dauthentification de ce message.
3.5.9 Le message PKMv2 SA-TEK-Request (code 21)
Cest le deuxime message, dlivr par le mobile, du protocole 3-ways SA-TEK
handshake, il est prcd par un PKMv2 SA-TEK-Challenge.
- MS_Random, un nombre alatoire choisi par le mobile pour chaque nouveau 3way handshake
- BS_Random, une valeur alatoire de 64 bits gnre par la station de base et reu
dans un prcdent PKMv2 SA-TEK-Challenge
La scurit du WiMAX
15
- Security-Capabilities, les capacits cryptographiques du mobiles.

- Security Negociation Parameters, les capacits cryptographiques du mobile
ngociables
- PKMv2 configuration settings, la configuration du protocole PKMv2
- HMAC/CMAC Digest, lempreinte dauthentification du message.
3.5.10 Le message PKMv2 SA-TEK-Response (code 22)
Cest le dernier message du protocole 3-way SA-TEK handshake. Il transporte les
attributs suivants
- MS_Random, nombre alatoire gnr par le mobile
- BS_Random, nombre alaoitre gnr par la station de base
- SA_TEK_Update, une liste dattributs lis une association de scurit, incluant
des paramtres tels que TEK, GTEK, GKEK
- Frame Number, un numro de trame
- un ou plusieurs SA-Descriptor(s)
- Security Negotiation Parameters, confirmation des paramtres dauthentification
et dintgrit de donnes utiliser.
- HMAC/CMAC Digest, empreinte du message
3.5.11 Le message PKMv2 Key-Request message (code 23)
Le mobile gnre ce message pour obtenir une nouvelle cl TEK ou dautres
paramtres tels que GTEK ou GKEK.
- Key-Sequence-Number, lindes de la cl AK
- Nonce, un nombre alatoire gnr par le mobile
16 Pascal Urien
- HMAC/CMAC Digest, lempreinte du message
3.5.12 Le message PKMv2 Key-Reply (code 24)
Cest la rponse de la station de base au message PKMv2 Key-Request dlivr par le
mobile.
- SAID, lidentifiant de lassociation de scurit, le GSAID dans le cas dun service
broadcast ou multicast.
- TEK-Parameters, ancienne liste des paramtres TEK ou GTEK
- TEK-Parameters, nouvelle liste des paramtres associs SAID
- GKEK-Parameters, ancienne liste des paramtres GKEK
- GKEK-Parameters, nouvelle liste des paramtres GKEK
- Nonce, cette valeur est gale celle du PKMv2 Key-Request.
- HMAC/CMAC Digest, lempreinte du message associe la cl AK
3.5.13 Le message PKMv2 Key-Reply (code 25)
Ce message, mis par la station de base, notifie une erreur dtecte dans un PKMv2
Key-Request.
- Error-Code, un code derreur
- Display-String, un message optionnel derreur.
- Nonce, le nombre alatoire contenu dans la requte.
- HMAC/CMAC Digest , lempreinte du message associe la cl AK.
La scurit du WiMAX
17
3.5.14 Le message PKMv2 SA-Addition message (code 26)

Ce message est envoy par la station de base au mobile pour tablir une ou plusieurs
nouvelles associations de scurit.
- un ou plusieurs SA-Descriptors
- HMAC/CMAC Digest, lempreinte du message associe la cl AK.
3.5.15 Le message PKMv2 TEK-Invalid (code 27)
La station de base gnre ce message lors dun usage de cl TEK incorrect.
- Key-Sequence-Number, index de la cl dautorisation AK
- SAID, identifiant de lassociation de scurit
- Error-Code, un code indiquant la nature de lerreur
- HMAC/CMAC Digest, lempreinte du message utilisant la cl AK.
3.5.16 Le message PKMv2 Groupe-Key-Update-Command (code 28)
La station de base utilise ce message pour dlivrer au mobile des cls GTEK et/ou
GKEK pour des services multicat ou unicast.
- GSAID, lidentifiant de lassociation de scurit
- Key Push Modes, le code dusage du message
- Key Push Counter, un compteur de messages
- GTEK-Parameters
- GKEK Paramters
- HMAC/CMAC Digest, empreinte du message.
18 Pascal Urien
3.5.17 Le message PKMv2 EAP Complete (code 29)
Dans le mode EAP double, cest dire une deuxime session dauthentification
EAP aprs une premire session EAP, la station de base dlivre ce message au
mobile accompagne de la notification EAP-Success pour informer ce dernier du
succs de la premire session.
- EAP Payload, un paquet EAP-Success
- HMAC/CMAC Digest, lempreinte du message associe la cl AK
3.5.18 Le message PKMv2 Authenticated EAP Start (code 30)
Dans un mode double EAP, le mobile envoie la station de base ce message pour
indiquer le dmarrage de la 2ime session.
- MS_Random, un nombre alatoire gnr par le mobile
- HMAC/CMAC Digest, lempreinte du message associe la cl EIK.

Cours Securite Wi-Fi 2011 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Cours Securite Wi-Fi 2011 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

La scurit

des rseaux IEEE 802.11 Wi-Fi

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 1

Table des matires

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 2

2.3 Exemple dun descripteur de cl. .......................................................... 42

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 3

5.2 Variables ............................................................................................... 69

Scurit Wi-Fi Pascal Urien - page 4

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 4

Un champ Protocol (2 octets) identifie le type de PDU PPP inclus dans la

Scurit Wi-Fi Pascal Urien - page 5

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 5

1.1 Le protocole de contrle rseau (NCP)

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 6

(3) Protocole dauthentification

Scurit Wi-Fi Pascal Urien - page 7

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 7

PPP[C021] state = acksent

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 8

2 Password Authentication Protocol - RFC 1334 (1992)

2.1 Les PDUs LCP

Code, identifie la nature du paquet PAP

- Identifier, ce champ est le numro dune requte et de la rponse associe

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 9

3.1 Format des paquets CHAP

Identifier, ce champ est le numro dune requte et de la rponse associe

Scurit Wi-Fi Pascal Urien - page 10

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 10

4.1 Format des paquets MS-CHAP-V1

La taille dun challenge est de 8 octets.

Scurit Wi-Fi Pascal Urien - page 11

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 11

Identifier, ce champ est le numro dune requte et de la rponse associe

1 Bit 0, The "use Windows NT compatible challenge response" flag as described

Scurit Wi-Fi Pascal Urien - page 12

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 12

5 MS-CHAP-V2, RFC 2759 (2000)

5.1 Format des paquets MS-CHAP-V2

La taille dun AuthenticatorChallenge est de 16 octets.

Scurit Wi-Fi Pascal Urien - page 13

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 13

Identifier, ce champ est le numro dune requte et de la rponse associe

Scurit Wi-Fi Pascal Urien - page 14

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 14

Le Password est associ un hash MD4 de 16 octets (NTPasswordHash),

Scurit Wi-Fi Pascal Urien - page 15

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 15

II- La scurit des

Scurit Wi-Fi Pascal Urien - page 16

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 16

certain cas lextrieur des murs de lentreprise. On introduit donc de

2 RFC 2131, Chapter 7 - Security Considerations, Therefore, DHCP in its

Scurit Wi-Fi Pascal Urien - page 17

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 17

Service Set Identifier

Figure 1. Une architecture typique 802.11

La norme 802.11 [IEEE Std 802.11, 1999] dfini un protocole de scurit

Wireless Equivalent Privacy

Pascal Urien, Tlcom ParisTech, Scurit Wi-Fi WiMax, 18

Corps de trame chiffr

MAC Service Data Unit

Figure 2. Le protocole WEP.