sécurité du wimax

SÉCURITÉ DU WIMAX
Par Rocio Ruz San Roman
France Telecom
[email protected]
Juillet 2008
INTRODUCTION
Le standard 802.16e est très riche sur maints aspects : flexibilité du traitement des canaux de
communication, solutions adaptatives pour le codage et les fréquences… Néanmoins, l’aspect sécurité fut
reconnu comme une des principales faiblesses des premières versions. Le dernier 802.11e a amélioré ces
aspects en introduisant intégrité, authentification et confidentialité sur les réseaux sans fil haut débit.
De plus, la sous-couche sécurité apporte aux utilisateurs une protection forte contre le détournement du
service. La station émettrice (BS – Base Station) se protège des accès illicites en sécurisant les flux de
service associés dans le réseau. La sous-couche sécurité introduit également des mécanismes
d’authentification dans le protocole client/serveur de gestion des clés, par lequel la BS contrôle la
distribution des éléments de chiffrement aux stations mobiles (MS – Mobile Station). En plus, les
mécanismes de sécurité de base sont renforcés en ajoutant une authentification des équipements basée
sur un certificat numérique.
PROTOCOLE DE GESTION DES CLÉS PKM V2
Le protocole (Privacy Key Management) de gestion des clés PKM fut introduit en 802.16d et mis à jour
dans une seconde version incluse dans 802 .16e. Cette seconde version permet à la fois l’authentification
mutuelle et l’authentification unilatérale.
Le protocole de gestion des clés utilise dans son processus d’authentification :
-
des certificats numériques X. 509 [IETF RFC 3280] associés à un algorithme de
chiffrement à clés publiques RSA [PKCS # 1].
-
le protocole EAP [IETF RFC 3748], en processus simple ou double.
- une séquence commençant par une authentification RSA suivie d’une authentification EAP.
Il utilise des algorithmes de chiffrement fort pour exécuter l’échange de clés entre une station mobile et la
station émettrice. Le protocole d’authentification PKM établit un secret partagé : la clé d’autorisation
(Autorisation Key – AK) entre la station mobile et la station émettrice. Le secret partagé est alors utilisé
pour les échanges sécurisés PKM subséquents de la clé de chiffrement de trafic (Traffic Encryption Key –
TEK)
Ce mécanisme à deux étages pour la distribution des clés permet de rafraîchir les TEK sans risquer une
surcharge par des opérations gourmandes en temps de calcul.
La station émettrice (BS) authentifie un client mobile MS durant la transaction initiale d’autorisation.
Chaque MS présente ses certificats, soit un certificat numérique X. 509 délivré par le constructeur du
mobile (dans le cas de l’authentification RSA, soit un certificat spécifié par l’opérateur (en cas
d’authentification EAP). La BS associe une identité authentifiée de MS à un usager et donc aux services de
données auxquels cet usager a droit. Ainsi, avec la transaction AK, la BS détermine l’identité authentifiée
d’un MS client et les services (par exemple TEK spécifiques) autorisés.
Un livre blanc
1/9
Puisque la BS authentifie la MS, il est possible de se protéger contre un attaquant en employant un MS
clone qui se ferait passer pour un vrai MS d’abonné.
La partie du traitement de la clé de trafic du protocole PKM est conforme à un modèle client/serveur dans
lequel la MS (le client) demande les éléments de chiffrement, et la BS (le serveur) répond à ces requêtes,
garantissant qu’un MS donné ne reçoit que les éléments de chiffrement auxquels il est autorisé.
PROCESSUS D’AUTHENTIFICATION
CERTIFICAT NUMÉRIQUE MUTUEL RSA – X. 509.
Le protocole d’authentification RSA utilise des certificats numériques X. 509 [IETF RFC 3280] et
l’algorithme de chiffrement sur clé publique RSA [PKCS # 1] qui lie les clés publiques de chiffrement RSA
aux adresses MAC des stations mobiles.
Un mobile MS initialise le processus d’autorisation en envoyant un message Authentication Information à
sa station émettrice (BS). Ce message contient le certificat X. 509 délivré par le constructeur du mobile ou
par une Autorité externe. Le message Authentication Information est purement informatif, la BS peut
décider de l’ignorer. Cependant, il fournit à la BS un moyen de connaître le certificat constructeur du
mobile client.
Le mobile envoie un message Authorisation Request à sa BS, immédiatement après avoir envoyé le
message Authentication Information. Ceci est une demande de clé d’authentification AK. Ce message est
signé par la clé privée du mobile suivant un échange RSA. A la réception, la BS va utiliser la clé publique
du certificat pour vérifier la signature du message. Le message Authorisation Request contient :
-
Un certificat X. 509, avec la clé publique du mobile que la BS va utiliser ensuite pour
vérifier la signature du message
-
Une description des possibilités cryptographiques que supporte le mobile. Celles-ci sont
présentées à la BS sous la forme d’une liste d’identifiants, chacun indiquant les
algorithmes de chiffrement et les algorithmes d’authentification que supporte le mobile.
-
Un nombre aléatoire de 64 bits pour caractériser chaque parcelle du message
Message d’authentification/autorisation avec signature RSA
Quand la BS reçoit ce message, elle procède à une vérification du code MAC avec la clé publique du
certificat du mobile. Si correct, la BS utilise la clé publique du mobile pour chiffrer une clé Pre-PAK
aléatoire (Pre-Primary AK, clé qui est utilisée ensuite pour obtenir la clé d’authentification AK). Cette PrePAK est envoyée avec le certificat X. 509 de la BS, encapsulée dans un message RSA Autorisation Reply.
Tous les attributs de ce message sont signés avec la clé privée de la BS, suivant un chiffrement RSA. A la
réception, le mobile fait une vérification MAC avec la clé publique de la BS qui vient d’être envoyée dans le
message RSA Autorisation Reply et, si tout est correct, le mobile utilise sa propre clé privée pour déchiffrer
le Pre-PAK (chiffré auparavant avec la clé publique du mobile). La figure ci-dessous résume tout le
processus.
Un livre blanc
2/9
Message Authorisation Reply avec signature RSA
Le processus se termine quand le mobile envoie le message RSA Authorisation ACK. Ce message indique si
l’authentification a été concluante ou non et, en cas d’erreur, la cause d’échec. Ce message est de
nouveau signé RSA avec la clé privée du mobile, comme le RSA Autorisation Request.
Message RSA Autorisation ACK avec signature RSA
Grâce à cet échange de messages, les deux extrémités ont la Pre-PAK. Celle-ci est utilisée pour obtenir
l’AK finale (qui sera utilisée ensuite dans les signatures HMAC des procédures TEK d’échange et de
transport de messages.
Clé d’authentification AK issue de la Pre-PAK
Un livre blanc
3/9
PROTOCOLE EAP [IETF RFC 3748]
L’authentification EAP de la PKM utilise l’Extensible Authentication Protocol [IETF RFC 3748] conjointement
à un mode d’EAP choisi par l’opérateur, par exemple EAP-TLS [IETF RFC 2716]. Le mode d’EAP va utiliser
un type particulier de certificat, comme un certificat X. 509 pour EAP-TLS ou le Subscriber Identity Module
pour EAP- SIM.
Les références particulières et modes d’EAP utilisés (dont la description est en dehors du cadre de ce
document) doivent satisfaire les « critères obligatoires » indiqués dans la section 2.2 de la RFC 4017
(principalement, elles doivent garantir une authentification mutuelle sûre). L’utilisation d’un type d’EAP qui
ne satisferait pas ces critères introduirait des vulnérabilités de sécurité dans le réseau.
Le produit de la transaction EAP (d’un type qui garantit l’authentification mutuelle) qui est transmis à la
couche 802.16 est la Master Session KEY (MSK) de 512 bits. Une clé servant à l’authentification est
dérivée de la clé maître MSK Le mobile et le processus d’authentification en déduisent une PMK (Pairwise
Master Key) et une EIK (EAP Integrity Key) optionnelle en tronquant la MSK à 2*160 bits.
Authentication Key dérivée de MSK
Après authentification réussie par EAP, si le mobile ou la BS négocient une règle d’autorisation comme
« authentification EAP après EAP », une seconde authentification EAP intervient.
La première authentification EAP s’est déroulée sans vérification de signature HMAC mais néanmoins, la
seconde authentification va utiliser les procédures HMAC avec l’EIK (EAP Integrity Key) qui résulte de
l’authentification EAP précédente.
Clé d’authentification dérivée de MSK dans une double authentification EAP
Un livre blanc
4/9
AUTHENTIFICATION RSA PLUS EAP
Si RSA plus EAP est choisi, la première authentification RSA intervient dans les mêmes conditions que cidessus.
L’authentification EAP qui suit utilise un type qui satisfait les « critères obligatoires » décrits dans le
section 2.2 de la RFC 4017, mais cette fois, les messages EAP sont protégés avec les procédures HMAC en
utilisant l’EIK issu de la précédente authentification. La figure suivante montre comment obtenir la clé
d’authentification AK dans un processus d’authentification RSA + EAP.
Clé d’authentification issue de Pre-PAK et de la clé MSK dans l’authentification RSA + EAP
INTEGRITE : MAC/CMAC/SIGNATURES
Pour
garantir
l’intégrité
HMAC/CMAC/signatures.
des
messages,
WiMAX
préconise
l’utilisation
de
procédures
L’algorithme de hachage HMAC utilisé est défini dans l’IETF RFC 2104 et utilise SHA-1 (FIPSb180-1)
comme fonction logique.
Le tableau suivant précise les clés HMAC/signature dans le processus d’authentification.
Type d’Authent.
Signature
HMAC
Clé
RSA
Oui
Non
MS ou BS
Publique/privée
EAP
Non
Non
-
Oui
Non
MS ou BS
Publique/privée
EAP
Non
Oui
EIK issu de RSA
EAP
Non
Non
-
Non
Oui
EIK issu d’EAP
RSA
+
+
EAP
1
De tels mécanismes pour valider l’authenticité des messages ne sont pas seulement utilisés pendant le
processus d’authentification, mais ils le sont aussi pendant l’échange de messages de distribution de clés
et pendant l’échange de messages normaux de transport.
Après le processus d’authentification (RSA, EAP, RSA + EAP) les deux extrémités (BS et mobile) ont reçu
la clé d’authentification AK. A partir de celle-ci, la BS et le mobile vont tous deux obtenir trois autres clés :
-
1
CMAC/HMAC_KEY_U : clé utilisée dans les procédures HMC/CMAC pour les messages
montants (uplink)
Excepté la réauthentification. Dans ce cas, l’AK issue de l’authentification précédente est utilisée comme clé HMAC
Un livre blanc
5/9
-
CMAC/HMAC_KEY_D : clé utilisée dans les procédures HMC/CMAC pour les messages
descendants (downlink)
-
KEK (Key Encryption Key) : c’est la clé qui est utilisée pour chiffrer la TEK (Traffic
Encryption Key). La TEK doit être connue du mobile pour pouvoir décoder les messages.
Ainsi cette clé doit elle être transportée sur l’interface air, mais ceci ne pouvant se faire en
clair, la KEK est utilisée pour la chiffrer.
Clés HMAC/CMAC et KEK issues de l’AK
VUE D’ENSEMBLE DE L’ÉCHANGE TEK
1
Au moment où s’achève la phase d’autorisation, le mobile démarre une machine d’état TEK . Chaque
machine TEK envoie périodiquement des messages Key Request à la BS, demandant un rafraîchissement
de leurs moyens de chiffrement respectifs. Ces messages sont signés HMAC avec la HMAC_KEY_U. La
figure ci-dessous explique le processus :
Key Request du mobile avec procédure HMAC
La BS répond au Key Request par un message Key Reply. La TEK doit être chiffrée avec la KEK (les TEK et
KEK peuvent être de 64 ou 128 bits). Le message Key Reply est signé HMAC avec la HMAC_KEY-D. La
figure ci-dessous explique le processus :
Key Reply vers le mobile avec procédure HMAC
1
La machine d’états TEK est un automate qui gère les demandes et réactualisations de la TEK (Cf. IEEE Std 802.16e7.2.2.5)
Un livre blanc
6/9
Pour les connections qui utilisent un chiffrement DES-CBS, la TEK dans le Key Reply est chiffré avec une
triple-DES (Encrypt-Decrypt-Encrypt ou mode EDE), 3-DES KEK dérivée de l’AK, qui utilise une double clé
(clé 1 et 3 égales).
Pour les connexions utilisant un chiffrement avec une clé de 128 bits, comme le mode AES-CMM, la TEK
du Key Reply est chiffrée AES avec une clé de 128 bits issue de l’AK et des blocs de 128 bits.
Notons que la BS maintient en permanence deux jeux du générateur de clés de chiffrement par type de
connexion sécurisée. La durée de vie des deux générations se recouvrent afin que chaque génération
devienne active à la moitié de la vie de la précédente et expire à la moitié de la vie de la suivante.
Pour les connexions qui utilisent le mode de chiffrement CBC (Cypher Block C), le Key Reply fournit au
mobile, en plus de la TEK et du vecteur d’initialisation CBC, la durée de vie résiduelle de chacun des deux
jeux de générateurs de clés.
Pour les connexions qui utilisent un chiffrement AES-CMM, le message Key Reply fournit au mobile
demandeur, en plus de la TEK, la durée de vie résiduelle de chacun des deux jeux clés. Le mobile utilise
ces durées de vie résiduelles pour estimer à quel moment la BS va invalider la TEK et par conséquent à
quel moment elle doit programmer un Key Request afin de recevoir une nouvelle clé avant que la BS ne
dévalide celle actuellement détenue par le mobile.
Une machine d’état TEK reste active tant que les deux conditions suivantes sont satisfaites :
-
Le mobile est autorisé à opérer dans le domaine de sécurité de la BS, c'est-à-dire, tant
qu’il a une AK valide
-
Le mobile est autorisé à participer aux échanges de sécurité, c'est-à-dire tant que la BS
continue à lui renouveler les clés chiffrement durant les phases de rafraîchissement
CHIFFREMENT
Pour garantir la confidentialité des messages au travers du réseau, plusieurs services de chiffrement sont
définis dans 802.16e.
Toutes les implémentations de BS et MS doivent supporter plusieurs modes de chiffrement : chiffrement
données paquet et TEK (avec la KEK correspondante)
CHIFFREMENT DONNÉES PAQUET
Plusieurs méthodes de chiffrement de données paquet sont définies dans le standard WiMAX. On donne ici
une brève introduction. Pour plus de détails consulter IIIE Std 802.16e 7.5 Cryptographic methods.

Chiffrement de données avec DES (Data Encryption Standard) en CBS (Cipher Block
Chaining Mode)
L’algorithme est DES Data Encryption Standard (FOPS 46-3, FIPS 74, FIPS 81) utilisé pour chiffrer les
données utilisateur MAC PDU (les en-têtes ne sont pas chiffrés).
Le CBC IV (initialisation Vector) est initialisé avec un OU exclusif (XOR) du paramètre IV contenu dans
l’information de chiffrement TEK et le numéro de la trame courante.

Chiffrement avec AES (Advanced Encryption Standard) en CMM (CTR-Counter Mode
encryption with CBS-MAC) mode
Cet algorithme est le standard américain AES (Advanced Encryption Standard) – (NIST Special Publication
800-38C, FIPS – 197) utilisé pour chiffrer les données utilisateur MAC PDU (les en-têtes ne sont pas
chiffrés)
Les données utilisateur PDU (Packet Data Unit) sont accompagnées d’un numéro de paquet (Packet
Number = PN) de 4 octets non chiffré. Le PDU est chiffré et authentifié au moyen de la TEK active,
conformément aux spécifications CMM. Ceci inclut un ICV (Integrity Check Value) de 8 octets à la fin des
données utilisateur et le chiffrement des données utilisateur et de l’ICV.

Chiffrement de données avec AES en CTR (Counter Mode Encryption)
Cette méthode de chiffrement est utilisée pour les services multicast et broadcast Security Association
(MBS-SA). Dans ces deux cas, on doit utiliser le mode CTR de l’algorithme AES (US Advanced Encryption
Standard) [NIST Special Publication 800-38A, FIPS 197, RFC 3686] pour chiffrer les données utilisateur
MAC PDU.
La taille du bloc AES est 128 bits.

Chiffrement de données avec AES en mode CBS
Le compteur de paquets est remis à zéro quand le Message Key Reply est reçu et mis à jour chaque fois
que le numéro de trame PHY repasse à zéro ou que des données MAC PDU sont reçues dans une trame. Il
est incrémenté de 1 si le numéro de trame PHY précédent est supérieur ou égal au numéro de trame PHY
courant.
Un livre blanc
7/9
Le vecteur d’initialisation IV généré est le résultat de l’algorithme de chiffrement de bloc AES avec la clé
de TEK. Sa valeur pour la génération de vecteur IV CBC est calculée en faisant le OU exclusif (XOR) de :
-
La valeur du paramètre IV CBC inclus dans l’information de chiffrement TEK
-
128 bits qui sont une concaténation des 4 en-têtes MAC PDU, des 32 bits de valeur de
synchronisation du protocole MAP (Media Access Protocol) et le OU exclusif des 48 bits de
l’adresse MAC du mobile avec le compteur de paquets.
Le vecteur d’initialisation CBC doit être mis à jour à chaque PDU
CHIFFREMENT TEK
Plusieurs modes de chiffrement TEK sont définis dans le standard WiMAX. On donne ici un bref aperçu.
Pour plus de détails, cf. IEEE Std 802.16e - 7.5: Cryptographic Methods

Chiffrement de la TEK avec 3-DES
La BS chiffre les champs de valeurs de la TEK dans le message Key Reply qu’il envoie au mobile client. Ces
champs sont chiffrés avec la double clé 3-DES dans le mode EDE (Schneier [B42]).

Chiffrement avec RSA
Le mode RSA pour chiffrer la TEK (PKC #1 v2.0) est utilisé avec l’identifiant d’algorithme de chiffrement
TEK égal à 0*02

Chiffrement de TEK-128 avec AES
La BS chiffre le champ de valeur de la Tek-128 dans le message Key Reply qu’il envoie au mobile client.
Ce champ est chiffré avec AES 128 bits en mode ECB

Chiffrement de TEK-128 avec ARS Key Wrap
La BS chiffre les champs de valeur de la TEK-128 dans le message Key Reply qu’il envoie au mobile client.
Ce champ est chiffré avec l’algorithme AES Key Wrap
CONCLUSION
Comme il a été vu ci-dessus, 802.16e présente un solide système de sécurité basé sur :
-
L’authentification mutuelle + signatures et procédures HMAC
-
Un chiffrement puissant des messages
Malheureusement, l’inconvénient de cette robustesse a un prix. Les signatures HMAC et les clés évoluées,
si elles fournissent un haut degré de sécurité, impliquent des tailles de messages qui peuvent devenir très
importantes, voire prohibitives pour des canaux de communications étroits avec un faible débit et le poids
de ces messages peut induire d’importants délais de transmission.
GLOSSAIRE
AK
Authorisation Key
DES
Data Encryption Standard
EAP
Extensible Authentication Protocol
KEK
Key Encryption Key
MAK
Medium Access Control
Couche MAC C’est elle qui est responsable de l'établissement et le maintien de la connexion (accès
multiple, ordonnancement, etc.)
MSK
Master Session Key
PMK
Key Management Protocol
RSA
Rivest-Shamir-Adleman (ses inventeurs)
TEK
Traffic Encryption Key
WiMAX
Worldwide Interoperability for Microwave Access
Un livre blanc
8/9
RÉFÉRENCES
<Réf. 1> WiMAX à l’usage des communications haut débit (Collection ATENA)
A PROPOS DE L’AUTEUR
Rocio Ruz San Roman est ingénieur en télécommunications, diplômée de l’ENSTTélécom
ParisTech
et
de
l’École
Technique
Supérieure
d'Ingénieurs
de
Télécommunications de l’Université Polytechnique de Madrid (ETSIT-UPM), avec la
spécialisation Réseaux.
Son stage de fin d'études chez EADS Secure Networks avait pour sujet l'étude et
analyse de la technologie WiMAX et son applicabilité aux réseaux PMR (Private Radio
Mobile Network).
Actuellement Rocio travaille chez France Telecom dans le domaine de la VoIP et des
plateformes de services, concrètement sur la conception et déploiement de nouveaux
services à valeur ajoutée sur les plateformes de VoIP France résidentielles.
Les idées émises dans ce livre blanc n’engagent que la responsabilité de leurs auteurs et pas celle de Forum ATENA.
La reproduction et/ou la représentation sur tous supports de cet ouvrage, intégralement ou partiellement est autorisée à
la condition d'en citer la source comme suit :
© Forum ATENA 2008 – Sécurité du WiMAX
Licence Creative Commons
-
Paternité
Pas d’utilisation commerciale
Pas de modifications
L'utilisation à but lucratif ou commercial, la traduction et l'adaptation sous quelque support que ce soit sont interdites
sans la permission écrite de Forum ATENA.
Un livre blanc
9/9