Le rapport de stage analyse la norme 802.16e, ou wimax mobile, se concentrant sur son niveau de sécurité et son adaptabilité dans différents environnements. Les besoins en sécurité des réseaux sans fil étant croissants, l'étude examine comment la norme répond à ces exigences tout en identifiant des opportunités d'amélioration. En fin de compte, le travail vise à garantir un niveau de sécurité adéquat lors des transitions entre les réseaux.

1. Master 2 Réseaux et Télécommunications
Rapport de Stage. Avril à Septembre 2006
La sécurité du WiMax mobile
(802.16e)
Tuteurs :
Guy Pujolle (Guy.Pujolle@lip6.fr)
Pascal Urien (Pascal.Urien@enst.fr)
Encadrants :
Naceur Malouch (Naceur.Malouch@lip6.fr)
Elève :
Valentin Paquot : (Valentin.Paquot@gmail.com)
Septembre 2006
1

2. 2

3. RESUME
Le monde de la technologie filaire évolue chaque jour : augmentation des débits, amélioration
de la qualité du service et de la fiabilité des liens, augmentation du nombre de connections,
etc. Aussi le monde de la technologie sans fil se doit-il de suivre une évolution plus ou moins
équivalente.
Le 802.11 ayant atteint ses limites (en portée, en fiabilité, en sécurité, en débit, etc), un nouvel
environnement technologique est devenu nécessaire pour répondre à ces besoins croissants.
C’est pourquoi le 802.16 a vu le jour, le Worldwide Interoperability for Microwave Access.
Cette norme répond aux besoins de portée, de bande passante, de fiabilité, de facilité de
déploiement, de nombre possible d’applications, etc. Fort de l’expérience de l’échec du
802.11, la notion de sécurité a été prise en compte lors de la conception des protocoles
composant la famille du 802.16.
De plus en plus de personnes (et entreprises) utilisent des technologies réseaux et de plus en
plus d’informations cruciales sont transférées via ces technologies. Aussi les besoins de
sécurité dans les technologies de communications sont-ils devenus majeurs.
L’objectif de ce stage était :
- d’étudier le niveau de sécurité apporté par la norme 802.16e, communément appelée
WiMax mobile ;
- de le discuter (et d’essayer de le relever si besoin était) ;
- puis de voir comment garder ce niveau de sécurité lors de handover verticaux ;
- enfin, d’analyser les limites éventuelles des améliorations de sécurité imposées par le
nouveau Windows Vista dans un environnement plus restreint (les ordinateurs
portables).
3

4. 4

5. REMERCIEMENTS
Je tiens à remercier tout d’abord mes deux tuteurs, monsieur Pujolle et monsieur Urien, pour
m’avoir proposé ce sujet de stage et pour leurs conseils pendant tout son déroulement. La
réalisation de ce stage n’aurait pas été possible sans leur soutien.
Je tiens aussi à remercier l’ensemble de l’équipe professorale de l’UFR d’informatique de
l’Université Paris VI, et notamment monsieur Malouche, qui ont su tout au long de mon
cursus, m’enseigner non seulement de nombreuses connaissances en informatique de réseaux
et télécommunications, mais qui m’ont aussi appris à mieux lire et écrire un article
scientifique.
Merci aussi à mes camarades stagiaires au sein de l’équipe PHARE dont l’enthousiasme m’a
permis de travailler dans des conditions idéales.
Enfin, je tiens à remercier tous les membres de l’équipe PHARE qui m’ont fait profiter de
leurs expériences et ont toujours accepté de me prêter une oreille attentive et critique lors de
nos discussions et nos réunions.
J’espère que vous trouverez autant de plaisir à lire ce rapport que j’en ai eu à le concevoir et le
rédiger.
5

6. 6

7. SOMMAIRE
1ER CHAPITRE : INTRODUCTION.......................................................................................... 9
1.1 Historique ................................................................................................................... 9
1.2 Définition de la problématique ................................................................................. 10
1.3 Objectif du stage....................................................................................................... 10
1.4 Méthodes de recherche ............................................................................................. 10
1.5 Limites de la recherche ............................................................................................ 10
1.6 Structure du rapport de stage .................................................................................... 11
2EME CHAPITRE : ETAT DE L’ART ...................................................................................... 13
2.1 Historique ................................................................................................................. 13
2.2 Propositions de pré-normalisation ............................................................................ 16
2.3 Norme ....................................................................................................................... 17
2.3.1 Etablissement et validation de la norme 802.16e .............................................. 17
2.3.2 Survol technique de la norme 802.16e .............................................................. 18
2.3.3 802.16e – Couche sécurité : .............................................................................. 22
3EME CHAPITRE : LIMITES DES COMPROMIS SUR LA COUCHE SECURITE ........................ 29
3.1 Choix non optimaux : ............................................................................................... 29
3.2 Mise en avant de vulnérabilités (Wireless, expérience Wi-Fi) ................................ 29
3.2.1 Les failles qui ne se retrouvent pas en WiMax ................................................. 33
3.2.2 Les failles « classiques » du Wi-Fi dont le WiMax a hérité ............................. 34
3.2.3 Les failles spécifiques au WiMax...................................................................... 36
4EME CHAPITRE : HANDOVER VERTICAL ET DIAGONAL ................................................... 37
5EME CHAPITRE : QUID DU SUPPORT LOGICIEL ? ............................................................. 39
CONCLUSION...................................................................................................................... 41
BIBLIOGRAPHIE ................................................................................................................. 43
7

8. Table d’illustrations
Figure 1 - Réseaux sans fil, selon l'IEEE ................................................................................. 13
Figure 2 - Tableaux comparatifs des principales technologies ................................................ 14
Figure 3 - Illustration de la complémentarité des technologies de télécommunication (source
FT R&D) .................................................................................................................................. 14
Figure 4 - Déploiement complémentaire Wi-Fi/WiMax ......................................................... 15
Figure 5 - Couches protocolaires 802.16e ............................................................................... 19
Figure 6 - Etablissement d'une connexion ............................................................................... 21
Figure 7 - Couches des composants protocolaires de la sous-couche sécurité ........................ 23
Figure 8 - Schéma d'autorisation ............................................................................................. 24
Figure 9 - Distribution des clés TEKs ..................................................................................... 27
Figure 10 - Processus de chiffrement par défaut ..................................................................... 28
Figure 11 - Processus de chiffrement en AES-CCM ............................................................... 28
Figure 12 - Comparatif des vitesses de chiffrement/hachage des principaux algorithmes ...... 31
Figure 13 - Temps de chiffrement/hachage des algorithmes de base ...................................... 32
8

9. 1ER CHAPITRE : INTRODUCTION
1.1 Historique
Le WiMax (Worldwide Interoperability for Microwave Access) est une norme basée
sur le standard de transmission radio 802.16, validé en 2001 par l'organisme international de
normalisation IEEE (Institute of Electrical and Electronics Engineers). Le WiMax est une
famille de standards, dont certains sont encore en cours de développement. La norme 802.16e
a été adoptée le 8 décembre 2005 par l’IEEE.
La création du WiMax a pour origine l’augmentation des besoins en bande passante pour les
technologies non filaires et l’augmentation des besoins en zone de couverture. L’expansion de
la technologie du sans fil s’est traduite par un développement important des besoins du
nomadisme. De nombreuses études ont montré que plus une personne était connectée, plus sa
rentabilité augmentait [12]. La bourse anglaise a ainsi récemment salué l’action de Nomad
qui propose un pré Wimax sur les trains Southern Trains qui relient Brighton à Londres,
permettant ainsi aux travailleurs londoniens résidant à Brighton de gagner près de deux heures
de temps de travail.
Ces nouveaux besoins applicatifs entraînent de nouveaux besoins physiques. Les limites du
Wi-Fi (taille des cellules, des débits, des vitesses de déplacement, des technologies
supportées, QoS, faible nombre de canaux par cellules, etc) ont amené les professionnels à
créer un consortium à but non lucratif, le WiMax Forum (celui-ci est le pendant de la Wi-Fi
Alliance). Ce consortium s’est donné pour objectifs de définir les diverses normes du WiMax.
L’analyse de la sécurité de la norme WiMax mobile, 802.16e, constitue l’objet central de ce
stage. En effet une des principales raisons du manque de développement économique autour
du Wi-Fi provient de sa très faible sécurité et de l’image néfaste qui en découle. La question
de la sécurité constitue donc un des points essentiels du WiMax. De nombreux drafts ont été
publiés sur ce sujet pendant la phase de pré-normalisation du WiMax mobile et divers points
de vue s’y sont opposés : ceux des équipementiers, des constructeurs, des fournisseurs
d’accès, etc.
9

10. 1.2 Définition de la problématique
La normalisation WiMax mobile constitue donc l’illustration d’un compromis. Quel
est l’impact des nécessaires compromis sur la sécurité du WiMax ? Comment le WiMax peut-
il réagir avec les réseaux déjà existants (Wi-Fi, cellulaire, …) ? Le handover vertical peut-il
être géré au niveau de la couche applicative ? Une solution de chiffrement EAP est-elle par
exemple envisageable ?
Cette étude ne serait pas complète si elle ne prenait pas en compte les évolutions prochaines,
notamment celles des systèmes d’exploitation. Comment les futurs systèmes d’exploitation
géreront la sécurité des usagers ? A quel point délègueront-ils la sécurité aux couches
physiques ? Et plus spécifiquement, quels degrés de liberté en sécurité laissera Windows
Vista ?
1.3 Objectif du stage
Le but de ce stage est de mesurer le niveau de sécurité proposé par la norme 802.16e,
de suggérer des améliorations possibles et d’éprouver l’adaptabilité de ce protocole dans des
environnements variants.
1.4 Méthodes de recherche
Cette recherche possède une orientation assez théorique. Une importante phase de
recherche bibliographique a d’abord été nécessaire, aussi bien sur les principaux sites
concernés (IEEE, WiMax Forum, Microsoft…) que par la lecture des publications de
chercheurs, de stagiaires ou de professionnels du monde des télécommunications.
Un travail d’analyse, basé sur les drafts de pré-normalisation et sur la norme 802.16e, a
ensuite permis d’éprouver les limites de sécurité du WiMax mobile. Des justifications
mathématiques ont été utilisées ainsi que des simulations sous environnement JAVA.
Enfin, des suppositions ont été élaborées sur la partie Windows Vista. L’information
disponible est en effet à ce jour encore très incomplète et sujette à des modifications avant sa
commercialisation.
1.5 Limites de la recherche
La norme WiMax 802.16e étant une norme encore très jeune (elle a moins de 6 mois),
nous ne disposions pas de matériel certifié WiMax pour réaliser des tests, des mesures réelles
ou d’autres types d’expérimentation physique.
10

11. Aucune implémentation sur environnement WiMax n’était possible et les simulations sous
Java étaient limitées à la couche sécurité de la norme 802.16e. J’ai volontairement laissé de
côté l’analyse de la couche physique.
La majorité des comparaisons et estimations sont basées sur l’emploi du 802.11, seule
alternative exploitable.
1.6 Structure du rapport de stage
Après cette introduction qui présente rapidement les objectifs de ce stage, je dresse un
état de l’art sur la recherche en WiMax mobile. Cet état de l’art (chapitre 2) se composent de
trois parties majeures : un historique de la naissance de la norme 802.16e ; ensuite une
illustration succincte des discussions de pré-normalisation (l’étude des besoins en sécurité, les
compromis, les options stratégiques, etc) ; et enfin une étude de la couche sécurité de la
norme WiMax mobile.
Après cet état de l’art, je discuterai de la pertinence de certains des choix opérés lors de cette
normalisation, de l’absence actuelle de certaines solutions et je proposerai certaines
améliorations possibles (chapitre 3).
J’étudierai ensuite la faisabilité d’un handover vertical et je comparerai les différents moyens
envisageables, en essayant de montrer la transposabilité du projet carte à puce EAP/TLS
(chapitre 4).
Pour finir, j’étudierai l’évolution des systèmes d’opérations (Windows Vista et son TPM) et je
délimiterai les libertés qu’ils laisseront aux applications externes, aux clients et aux mediums
en matière de sécurité (chapitre 5).
En conclusion, j’évoquerai les limites de mon stage et je reprendrai les propositions les plus
pertinentes élaborées à l’occasion de ce travail.
11

12. 12

13. 2EME CHAPITRE : ETAT DE L’ART
2.1 Historique
Le standard WiMax 802.16 a été publié pour la première fois en décembre 2001. Cette
norme est très flexible et elle permet une implémentation dans des bandes de fréquences
variées. Cette flexibilité fait du WiMax, non pas une norme mais une classe de normes. Ainsi
il existe les norme 802.16a, 802.16-2004 et 802.16e basées toutes trois sur la technologie
WMAN 1. Ces technologies sont à la fois concurrentes et complémentaires des technologies
WPAN 2, WLAN 3, WRAN 4, WWAN 5 (des technologies sans fil 2 à 4G) et des réseaux
satellites.
Figure 1 - Réseaux sans fil, selon l'IEEE
Ce groupe de normes a été développé par le consortium WiMax Forum. Le consortium
WiMax Forum est composé de nombreux intervenants aux horizons et stratégies diverses :
équipementiers, fournisseurs d’accès, sociétés de service, etc. Aussi de nombreuses
discussions ont-elles été nécessaires avant d’arriver à un compromis définissant la norme
802.16e. Toutes ces discussions ont été présentées sous la forme de propositions puis de
drafts.
1
Wireless Metropolitan Area Network - Réseau d'Accès sans fil Métropolitain
2
Wireless Personal Area Network – Réseau d’Accès sans fil Personnel
3
Wireless LAN - Réseau d’Accès sans fil Local
4
Wireless RAN - Réseau d’Accès sans fil Régional
5
Wireless WAN - Réseau Etendu sans fil
13

14. La norme 802.16 a été publiée en 2001 (802.16-2001). Deux nouvelles révisions ont ensuite
suivi (802.16a et 802.16d), respectivement en 2003 et 2004. Ces normes utilisent la
technologie filaire. La norme WiMax mobile (802.16e) a été ratifiée le jeudi 8 décembre 2005
par l'institut américain d'ingénierie électrique et électronique (IEEE). Voici un tableau
comparatif des principales technologies sans fil :
Figure 2 - Tableau comparatif des principales technologies
La complémentarité des technologies nous amène à imaginer un déploiement futur de ce
type :
Figure 3 - Illustration de la complémentarité des technologies de télécommunication (source FT R&D)
14

15. Cette complémentarité repose sur une complémentarité des technologies et également sur la
prise en compte des coûts d’exploitation très différents de ces dernières. En effet
l’investissement pour déployer une antenne Wi-Fi n’est en rien comparable à celui d’une
antenne WiMax ou UMTS. Les prix varient respectivement de l’ordre de 100 € à 1 000 € et
10 000 €. De plus, en France, l’ARCEP, a interdit la mobilité au WiMax. Seul le nomadisme
sera permis, ce qui rend les services de téléphonie sur WiMax peu envisageables.
Un déploiement tel qu’illustré en figure 3 et 4 est des plus probables dans un futur proche :
Figure 4 - Déploiement complémentaire Wi-Fi/WiMax
Ainsi on assistera vraisemblablement au maintien local des réseaux Wi-Fi, et surtout à une
forte cohabitation inter-technologies. Ce qui bien sûr soulève nombre de questions quant à la
gestion des handovers verticaux ou diagonaux. Questions auxquelles j’essayerai d’apporter
une ébauche de réponse, tout du moins au niveau du maintien de la sécurité.
Avant d’étudier la norme 802.16e, je vais résumer les principaux points abordés lors des
nombreuses discussions de pré-normalisation. Je commencerai par illustrer les principales
caractéristiques générales de cette norme avant de me focaliser sur la couche sécurité de cette
dernière.
15

16. 2.2 Propositions de pré-normalisation
De nombreuses discussions ont été menées avant l’établissement de la norme 802.16e.
En se basant sur l’expérience du 802.11, il était clair que la sécurité constituait un des points
essentiels du WiMax mobile. Afin d’éviter de reproduire les erreurs du 802.11 en matière de
sécurité, un panel d’objectifs a été dressé. Il constitue une liste des points essentiels en
sécurité mobile et nomade. Cette liste découle d’une analyse rigoureuse des principales failles
de la norme Wi-Fi et des besoins nouveaux induits par les nouveaux services liés à la
technologie 802.16e (notamment la téléphonie).
Il s’est avéré essentiel que les points suivants soient respectés :
• Authentification du terminal. Ce dernier doit être un WiMax certifié. C'est-à-dire agréé
par le fournisseur d’accès ou par l’entreprise. Un terminal non conforme à la norme
constituerait une source potentielle d’émission de paquets erronés et d’autres
problèmes techniques (cf. la chute en France des brasseurs France Télécom lors d’une
surcharge de VoIp mal translatés l’été passé).
• Authentification de l’utilisateur. Il convient de s’assurer que ce dernier a payé sa
facture, qu’il est bien un utilisateur légitime, qu’on lui confère les droits associés à son
statut à savoir : employé, client, invité, administrateur, etc.
• Confidentialité: Il est essentiel de garantir l’intimité des utilisateurs, d’empêcher le
rejeu et la falsification de données. Ce point est probablement le plus difficile à
garantir dans un environnement non filaire.
• Disponibilité. La plus grande zone de couverture du WiMax doit être assurée ainsi que
le plus grand nombre de clients supporté. Il va de soi qu’une période d’indisponibilité
aura un impact plus grand qu’en Wi-Fi. Il faut non seulement s’assurer d’un handover
rapide mais il faut aussi prévenir les attaques de type Deny of Service (DoS).
• Dernier point, il est nécessaire d’empêcher la Non Répudiation.
16

17. 2.3 Norme
2.3.1 Etablissement et validation de la norme 802.16e
La publication de 12 drafts s’est avérée nécessaire au cours des étapes de validation
qui ont débouché sur la norme 802.16-2005. Certains changements apportés dans ces drafts
successifs ont été très conséquents et ont donné lieu à de vifs débats au sein du WiMax
Forum. Le dispositif mis en place dans le cadre du processus de validation de l’IEEE a
néanmoins permis d’arriver à un compromis et de ratifier cette nouvelle norme.
En plus de la volonté de renforcer la sécurité, il a été décidé de construire la norme WiMax
mobile autour des orientations stratégiques suivantes :
• Haut débit (High Data Rate) : orientation technologique sur MIMO, division en
canaux avancée ainsi qu’un Codage et une Modulation de haut niveau.
• Qualité de Service (QoS) : architecture orientée autour de l’usage de code de
labellisation comme pour Diffserv et MPLS qui permettent une QoS IP de bout à bout.
De plus, la séparation en multi sous-canaux et la signalisation MAP permettent une
optimisation des ressources (temps, fréquence) et donc une meilleure
réservation/répartition.
• Scalabilité : les zones de couverture en technologie sans fil sont pour l’instant très
disparates, tout comme les fréquences allouées qui varient selon les technologies. Le
large spectre de fréquences utilisées pour les canaux WiMax (1.25 à 20 Mhz) permet
d’utiliser une seule technologie malgré les différentes réglementations internationales,
avant d’arriver un jour à harmoniser les fréquences mondiales. De plus, la grande
portée du WiMax permet d’atteindre à la fois les zones rurales et urbaines.
• Mobilité : le 802.16e supporte des handovers avancés qui permettent une latence
inférieure à 50 millisecondes, ce qui garantit l’utilisation de services comme la VoIP.
Bien entendu, la norme de sécurité doit répondre aux points développés précédemment et la
sécurité doit rester garantie lors des handovers.
17

18. 2.3.2 Survol technique de la norme 802.16e
L’architecture de la norme 802.16e est basée sur l’utilisation de deux types de
stations : les stations de base (BS) et les stations clientes (SS). La norme est basée sur la
technologie aérienne OFDM 6 classique. Elle supporte aussi le MIMO 7. Le WiMax mobile
fonctionne dans la bande de fréquence inférieure à 6 MHz. L’alignement des antennes n’est
pas nécessaire, on dit qu’elles sont déployées en Non Line of Sight, ce qui facilite leur
déploiement géographique.
S’affranchir des contraintes énormes qu’induisait le déploiement Line of Sight constitue une
avancée très importante dans la couverture maximale d’une zone. Chaque BS comporte
plusieurs antennes qui définissent des secteurs. Plusieurs canaux sont utilisés dans chaque
secteur, chacun étant géré par une BS unique. Chaque BS assure donc des liens de type Point
to MultiPoint. Quant aux clients, ils peuvent obtenir des liaisons MIMO en cumulant divers
canaux d’un secteur.
Les BS émettent périodiquement des messages de contrôle : les frames management. Ces
dernières peuvent concerner les voies montantes ou descendantes. Elles sont distinguées à
l’aide d’un message DL-MAP ou UL-Map.
Les canaux montants sont utilisés à la fois pour les communications de type administratif
(établissement de connexion, réservation de ressources, supervision du réseau…) et pour les
transmissions de données. Plusieurs méthodes de prévention de collisions ont été mises en
place pour assurer les transmissions multiples sur ces canaux.
6
OFDM- Orthogonal Frequency Division Multiplexing
7
MIMO - Multiple input multiple output
18

19. Figure 5 - Couches protocolaires 802.16e
La figure 5 présente l’architecture de la norme WiMax mobile. La couche MAC (Medium
Access Control) est séparée en trois entités :
• La couche CS SAP (Convergence Sublayer Service Access Points), qui gère l’interface
entre les réseaux extérieurs et les unités de services (Mac-SDU, Service Data Units)
sur le réseau 802.16e (MAC CPS). Elle supervise le service de classification (QoS) à
l’aide des CID et SFID (Service Flow ID).
• La couche Mac CPS (Mac Common Part Sublayer) qui gère les ressources physiques
(administration des connexions, application de la QoS, gestion des accès in/out).
• La Privacy Sublayer, couche où réside toute la sécurité de la norme WiMax mobile.
La connexion d’un client au réseau Wimax Mobile s’effectue ainsi :
Tout d’abord, le PHY écoute (scan) et capte un signal d’une station de base. Il écoute
sur sa fréquence de base, sauf s’il a été programmé pour écouter un canal d’une station de
base précise, il analyse alors le signal descendant afin de se synchroniser dessus.
19

20. Puis, le client attend de recevoir les messages UCD (Upload Channel Description) et DCD
qui sont émis par broadcast de manière périodique par la station de base, afin de connaître les
schémas FEC (Forward Error Correction) et les modulations utilisés par la porteuse de la
station qu’il écoute.
Une fois qu’il détient ces paramètres, il utilise les trames RNG-REQ (Ranging Request) et
RNG-RSP (Ranging Response) pour ajuster sa puissance d’émission. L’émission des RNG-
REQ commence au niveau le plus faible possible et incrémente la puissance petit à petit.
L’ajustement doit se faire impérativement au bon moment afin que plusieurs SS ne se
parasitent pas lors d’une tentative de connexion à un réseau, d’où l’importance de la
synchronisation préalable. Non seulement la station de base répond à l’ajustement de
puissance, mais elle donne aussi au client ses Basic et Primary Management CID (Connection
ID). Le client envoie les informations de ses capacités basiques et négocie l’ouverture d’un
canal correspondant à ses capacités et à celle de la station de base. Cette négociation se réalise
à l’aide des messages SBC-REQ et SBC-RESP.
S’ensuit alors une session d’authentification et d’échange de clés que je détaillerai à la section
2.3.3.
Une fois les divers protocoles de sécurité effectués, le client devient un usager officiel du
réseau. Grâce à l’échange de messages REG-REQ (Registration Request contient notamment
la version IP utilisée par le client) et REG-RSP, il obtient un Secondary Management CID qui
lui sera nécessaire pour l’utilisation des nombreux services IP (comme DHCP ou tout
protocole de QoS).
Après que la registration ait été complétée, la connexion IP est établie (une adresse IP est
obtenue via DHCP). Puis le client donne la date et l’heure, et télécharge son fichier de
configuration via le protocole TFTP (Trivial File Transfer Protocol).
La station de base envoie alors des messages DSA-REQ (Dynamic Service Addition Request)
afin d’activer (ou non) les services/connexions prépayés. Ces messages sont acquittés par le
client à l’aide des messages DSA-RSP. Le client peut initialiser la connexion s’il veut créer
une connexion avec certaines options.
20

21. Figure 6 - Etablissement d'une connexion
Lorsque la connexion (de management) est établie et la liaison opérationnelle, les
échanges de paquets peuvent commencer sur une connexion de transport. La connexion de
transport est sécurisée, comme nous allons le voir dans la prochaine section de ce rapport. Les
messages de management sont quant à eux authentifiés par des HMAC-tuples formés par
l’association d’une valeur HMAC et d’un index de clé.
21

22. 2.3.3 802.16e – Couche sécurité
Le problème de l’identification prend toute son ampleur avec l’utilisation du support
aérien. En effet, l’écoute est grandement facilitée sur ce medium, aussi une authentification
forte est-elle indispensable pour les réseaux sans fil. Les protocoles d’authentification forte
sont quasiment tous basés sur l’utilisation d’un serveur d’authentification AAA 8, de type
RADIUS 9 ou TACACS 10 de Cisco.
La couche sécurité du WiMax mobile se scinde en deux entités fonctionnelles. La première
supervise le chiffrement des trames MAC avec négociation des suites cryptographiques, et la
seconde supervise la gestion des clés via le protocole PKMv2.
Ces deux entités s’appuient sur les cinq composants suivants :
• Les associations de sécurité (SA) : elles contiennent la liste des paramètres de sécurité
d’une connexion.
• Les certificats X.509 : ils sont utilisés pour identifier les parties communicantes.
• Le protocole de gestion de clés privées pour l’autorisation (PKM) : il permet aux
stations de base d’identifier les clients.
• Le protocole de gestion de clés privées (PKM) : ce protocole établit une association de
sécurité entre une BS et une (ou plusieurs) SS.
• Les algorithmes de chiffrement : les données sont chiffrées selon la suite
algorithmique choisie.
La pile protocolaire de la couche sécurité est illustrée dans la figure 7 (page suivante). On
constate qu’il existe une certaine liberté au niveau de la couche authentication EAP. Cette
liberté dans la spécification constituera notre point d’ancrage pour le développement d’une
procédure de maintien de la sécurité lors d’un handover vertical.
Quant à la section RSA authentication, elle dépend des spécifications du client. Avec
l’apparition des TPM (Trusted Platform Module) il est fort probable que la gestion de cette
section soit déplacée dans les TPM pour une gestion optimale.
8
Authentication, Authorization and Accounting
9
Remote Authentication Dial-In User Service
10
Terminal Access Controler Access System
22

23. Figure 7 - Couches des composants protocolaires de la sous-couche sécurité
La couche de sécurité intervient pour la première fois au moment de l’authentification du
terminal, soit juste après la fin des négociations des capacités basiques. L’authentification se
fait via le composant PKM Authentication, opération qui se réalise en plusieurs étapes.
La station cliente envoie tout d’abord deux messages : une information d’authentification et
une requête d’autorisation. En retour, la station de base envoie une réponse d’autorisation.
Avant la fin de vie de la clé courante, la station cliente émet une nouvelle requête
d’autorisation et reçoit de la station de base une nouvelle réponse d’autorisation.
23

24. Figure 8 - Schéma d'autorisation
La composition des messages est la suivante :
• Auth_Info(SS_Cert[X509])
• Auth_Req(SS_Cert[X509], Liste des cryptos, CID Basique)
• Auth_reply(RSA(AK,SSclépub), n°_seq_clé (4 bits), durée vie clé, liste des SAID et
leurs propriétés)
Le message Auth_Info contient le certificat X509 v3 de la station client. Ce certificat lui a été
donné par le fabricant ou par une autre autorité externe.
Le message Auth_Req contient un certificat X509, qui est spécifique au client. Cette
distinction est importante si le client possède des liens particuliers avec le réseau qu’il essaye
de joindre, ce certificat contient la clé publique du client. Il contient aussi la liste des suites
cryptographiques qu’il supporte et le CID basique qui lui a été confié après les ajustements de
puissance. Ce basique CID est l’identifiant primaire de l’association de sécurité (ce point est
développé ultérieurement).
Le message Auth_Reply comporte une clé d’authentification (AK) chiffrée avec la clé
publique du client à la fois pour un challenge d’authentification mais aussi pour que la clé ne
soit pas visible pour un usager tierce. Le numéro de séquence de clé sert à indexer les AK
(lors de connexions de longue durée) de 4 bits, la durée de vie de la clé AK (par défaut 70
jours) et la liste des SAID (identité d’association de sécurité, l’identifiant des connexions
sécurisés) et de leurs propriétés.
24

25. Nous allons maintenant étudier en détail la composition d’une association de sécurité (SA).
Une SA, comme nous l’avons vu précédemment, est une liste des paramètres de sécurité entre
une station de base et X stations clientes (X variant de 1 au nombre maximum de clients que
la station peut supporter). Il existe trois catégories de SA, les primary (primaires), les static
(statiques) et les dynamic (dynamiques).
Les associations de sécurité primaires sont celles qui ont été définies au moment de
l’établissement de la connexion, il n’y a pas d’authentification dans cette association. Les
associations de sécurité statique sont forcées par la station de base pour un client ne possédant
pas les droits nécessaires pour négocier des paramètres particuliers de sécurité. Quant aux
associations de sécurité dynamique, elles sont négociées par le client selon les besoins s’il en
possède les droits ou bien sont imposées par la station de base selon les services auxquels le
client fait appel.
En plus de ces trois catégories, les associations de sécurité se scindent en deux types : une SA
pour les connexions de données et une SA pour les connexions d’autorisations.
Une association de sécurité pour une connexion de données contient les informations
suivantes :
• Un identifiant de l’association de sécurité de 16 bits (SAID).
• Un algorithme de chiffrement libre, par défaut il s’agit de CBC-DES (DES in Cipher
Bloc Chaining).
• Deux clés de chiffrement de trafic : TEK (Traffic Encryption Key) avec un index de 2
bits. La première clé est la clé en cours d’utilisation et la seconde est celle qui sera
utilisée dès que la clé courante aura épuisé sa durée de vie.
• La durée de vie des deux clés TEK. Par défaut, cette valeur est de 30 minutes.
• Un vecteur d’initialisation par clé TEK (IV de 64 bits).
• Le type de l’association de sécurité de l’AS (Primary, Static, Dynamic).
Une association de sécurité pour une connexion d’autorisation contient les informations
suivantes :
• Un certificat X509 identifiant le client.
• Une clé d’autorisation (AK) de 160 bits.
• Un index de 4 bits pour identifier l’AK.
• La durée de vie de l’AK. Par défaut, cette durée est de 70 jours.
• Une clé de chiffrement de clé KEK (Key Encryption Key) créée selon le schéma
suivant : Truncate-128(SHA-1(((AK| 044) xor 5364).
25

26. • Une clé de lien descendant basée sur une fonction de hachage HMAC (Hash Message
Authentication Code). Cette clé sert à l’authentification des messages de distribution
de clé sur la liaison descendante (de la station de base vers la station cliente). La
construction de la clé se fait ainsi : SHA-1((AK|044) xor 3A64).
• Une clé de lien montant qui authentifie les messages de distribution de clé du client à
la station de base. Cette clé est construite sur le même principe que celle du lien
descendant sauf que le ou exclusif (ici il manque un mot ou un bout de phrase) se
fait avec une répétition des octets 5C au lieu de 3A : SHA-1((AK|044) xor 5C64).
• Une liste des SA autorisées.
La distribution des clés TEK suit le protocole illustré en figure 9, page suivante.
La requête de clé possède les attributs suivants : un numéro de séquence de clé correspondant
au numéro de séquence de l’AK en cours ; un SAID (ou un GSAID en cas de broadcast ou de
multicast) ; et enfin un Nonce (nombre aléatoire généré par le client). Le tout est signé par une
empreinte HMAC calculée à l’aide du AK.
La station de base répond à la requête par un message KeyReply ou KeyReject (en cas de
problème, la sécurité peut être compromise ou le client rejeté). Le message KeyReply contient
deux clés de chiffrement de trafic (TEK). Il est lui-même chiffré par 3-DES en mode EDE
(Encrypt-Decrypt-Encrypt). Ce chiffrement est associé à la clé KEK et il contient lui aussi une
durée de vie pour les deux clés TEK. Les clés KEK et TEK possèdent une taille de 128 bits ou
de 64 bits selon les suites de chiffrement négociées lors de la connexion.
Au milieu de la durée de vie de la clé TEK en cours d’utilisation, le client envoie une nouvelle
requête de clé. Le client peut envoyer cette nouvelle requête de clé plus tôt s’il pense que la
clé TEK en cours d’utilisation a été corrompue. La station de base répond à cette nouvelle
requête en envoyant deux clés TEK, la clé « ancienne génération » et une nouvelle clé.
26

27. Figure 9 - Distribution des clés TEKs
Le chiffrement dans la couche sécurité fonctionne par défaut en mode DES-CBC avec
une clé de 54 bits et une valeur initiale (IV) de 64 bits. Il est possible d’implémenter 255
suites de chiffrement. Seules les suites DES6CBC et AES-128 ont été implémentées pour
l’instant, ce qui laisse 253 champs à l’administrateur du réseau pour personnaliser sa sécurité.
Tous les paquets de type MAC PDU sont chiffrés, et seulement le Payload de ces paquets, pas
leurs entêtes. Il n’y a pas de contrôle d’intégrité des données par défaut. Le CRC n’est pas
chiffré.
L’uplink et le downlink utilisent un CBC IV différent (obtenu avec ou exclusif de leurs DL-
Map/UL-Map et le champ IV de la clé TEK). Le problème est que ce champ IV n’est pas
assez dynamique. Nous reviendrons sur ce point dans la partie critique des choix opérés dans
la normalisation du WiMax mobile.
27

28. Figure 10 - Processus de chiffrement par défaut
Figure 11 - Processus de chiffrement en AES-CCM
28

29. 3EME CHAPITRE : LIMITES DES COMPROMIS
SUR LA COUCHE SECURITE
Dans ce troisième chapitre je discute de la pertinence de certains choix et j’argumente
mes analyses par des tests ou par des projections. Des simulations virtuelles illustrent les
failles de sécurité que j’ai identifiées dans la norme 802.16e. Ces dernières sont classées en
deux catégories : tout d’abord, celles héritées des anciennes normes sans fil, plus
particulièrement du Wi-Fi ; et ensuite celles spécifiques au WiMax mobile.
3.1 Choix non optimaux
Comme évoqué précédemment dans ce rapport, les discussions sur la couche sécurité
lors de la normalisation du WiMax mobile ont débouché sur certains compromis. Ces
compromis étaient liés à des choix stratégiques (certains constructeurs défendant les
technologies où ils avaient déjà investi) ou bien à des choix économiques (certaines solutions
étaient plus faciles et moins chères à déployer).
Le premier des choix qui parait problématique est celui de la durée de vie des AK.
Le 802.16e est une norme qui induit fortement un usage du nomadisme ou de la mobilité. Or,
la durée de vie de 70 jours par défaut d’un AK est une durée bien trop grande pour un univers
nomade ou mobile. Certes, cette durée de vie est paramétrable par l’administrateur. Mais
pourquoi ne pas avoir choisi une durée plus courte par défaut ?
La compromission d’un AK entraînerait un effondrement de la sécurité. En effet, une fois
l’AK connue, un individu mal intentionné pourrait usurper l’identité d’un autre usager. Dès
lors, les signatures deviendraient inefficaces au sein du SAID corrompu.
Autre point faible : l’envoi des clés TEK par paire ne semble pas la meilleure
optimisation possible.
En effet, plus un secret est partagé, plus il y a de chances qu’il soit éventé. De plus, le fait de
savoir que la clé est renvoyée de manière redondante : message n = (TEKn, TEKn+1) puis
message n+1 = (TEKn+1, TEKn+2), affaiblit l’efficacité du chiffrement (avec IV identique,
ne l’oublions pas).
29

30. On pourrait imaginer plutôt le processus suivant :
• Lors de l’initialisation de la connexion, envoi d’une paire de TEK
• Lors des échanges suivants, si aucune diminution dans le niveau de confiance du
réseau (valeur que la BS maintient à jour de manière dynamique selon le nombre
d’usagers, la confiance de voisinage et d’autres facteurs comme pour les réseaux ITEA
Ambience et RNRT Infradio). Alors que se passe t il ? il manque une suite à la phrase
• Si perte de confiance, alors réinitialisation de la couche sécurité, création d’un
nouveau SA et renégociation des suites.
• Si désynchronisation, alors le client redemande un doublon de clés TEK.
Le dernier choix non optimal est probablement le plus problématique de tous.
Afin de réaliser des économies d’échange et de simplifier le déploiement, les responsables ont
décidé de n’imposer qu’une authentification simple et non pas une authentification mutuelle,
sauf dans le cas de broadcast. Cette absence d’authentification mutuelle crée une sécurité à
sens unique. La station de base s’assure de l’identité du client mais le client, lui, ne peut pas
vérifier l’identité de la station de base. Il ne peut donc pas échanger des informations avec un
autre client sans redouter une écoute passive, voire une attaque active du type man in the
middle.
En plus de ces choix non optimaux, on peut aussi regretter la validation de certains
compromis.
Ainsi, malgré l’opposition d’Intel, c’est DES-CBC qui a été choisi comme suite
cryptographique par défaut. Hors, non seulement DES-CBC est mathématiquement plus faible
qu’AES-128, mais il consomme davantage d’énergie et est plus lourd à traiter.
J’ai créé un petit programme Java pour mesurer le temps en passage processeur de divers
algorithmes de chiffrement, ainsi que la vitesse d’exécution de ces derniers. J’ai instancié
deux versions de DES-EDE : la version 112 bits et la version 160 bits. En effet cet algorithme
ne supporte pas la version 128 bits. Or, pour la comparaison avec AES 128 bits, il était
nécessaire de procéder à une estimation de taux de chiffrement et de vitesse de chiffrement de
paquets d’un pseudo DES-EDE.
Lors de mes tests, il est apparu très clairement (comme illustré en figures 12 et 13) que DES-
EDE 112 et 160 bits étaient très proches et qu’on pouvait donc en déduire qu’un pseudo DES-
EDE 128 bits aurait des performances quasiment identiques à celles du DES-EDE 112 bits.
Les résultats illustrés par les deux graphiques ci-dessous constituent des moyennes établies
sur 100 itérations de chiffrement d’un paquet de taille variable.
On voit clairement sur la figure 12 que la plupart de ces algorithmes disposent d’un taux de
chiffrement stable (les courbes sont quasiment horizontales). Seul MD-5 possède un taux de
hachage qui semble dépendre de la taille du paquet haché. On voit aussi que les taux de
30

31. chiffrement des algorithmes 3-DES sont largement inférieurs à ceux des algorithmes Blowfish
et AES. Cette infériorité en terme de vitesse est aussi visible sur la figure 13. En effet on voit
que le temps de chiffrement des paquets en DES-EDE est largement supérieur à celui des
autres algorithmes.
Or, l’AES est beaucoup plus fiable que le DES. En effet, dans l’hypothèse où on aurait une
machine capable de craquer une clé DES en une seconde (donc qui puisse calculer 255 clés par
seconde), pour craquer une clé AES (128 bits) cette même machine mettrait 149 000 milliards
d'années.
De plus, sur les attaques de type dictionnaire, l’AES 128 possède une plus grande résistance
que le DES-EDE. En effet, l’AES dispose d’une robustesse de 2128, alors que DES-EDE
possède une robustesse de (deux fois un chiffrement sur 56 bits) 2112.
L’AES-128 s’avère, de plus, résistant aux attaques de type cryptanalyse différentielle et
cryptanalyse linéaire, alors que le DES-EDE y est sensible. Certes, dans les deux cas, cela
nécessite une écoute de 243 textes clairs et 243 textes chiffrés pour briser la clé, ce qui
représente un certain nombre d’échanges mais néanmoins cet algorithme n’est pas robuste.
On pourrait imaginer que le choix de DES-EDE soit lié à la vitesse de ce dernier. Or, à
l’inverse, mes tests montrent que l’AES est bien plus rapide et léger à déployer. De plus, les
agences gouvernementales américaine et européenne privilégient l’AES.
Comparatif des vitesses de chiffrement/hachage
70
60
50
Vitesses en MB/s
SHA-1
40 MD-5
AES (128 bits)
DES-EDE (112bits)
30 DES-EDE (160 bits)
Blowfish
20
10
0
32K 64K 128K 256K 512K
Taille du paquet à chiffrer en bits
Figure 12 - Comparatif des vitesses de chiffrement/hachage des principaux algorithmes
31

32. Temps de chiffrement/hachage
0,3
0,25
0,2
Temps en secondes
SHA-1
MD-5
AES (128 bits)
0,15
DES-EDE (112bits)
DES-EDE (160 bits)
Blowfish
0,1
0,05
0
32K 64K 128K 256K 512K
Taille du paquet en bits
Figure 13 - Temps de chiffrement/hachage des algorithmes de base
Bien que plus rapide, MD-5 a été rejeté au profit de SHA-1. Ce choix s’explique par la
vulnérabilité de MD-5 qui rendait par héritage les certificats X509 sensibles aux attaques par
collision. Pourquoi ne pas avoir implémenté SHA-2 ? A l’époque de la rédaction de la norme
802.16e, les attaques sur SHA-1 étaient inexistantes. Depuis lors, des chercheurs belges (les
auteurs d’AES, MM Rijmen et Oswald) et des chercheurs chinois (MM Xiaoyun Wang,
Andrew Yao et Frances Yao) ont démontré qu’il était possible de réduire la complexité pour
trouver une collision avec SHA-1 à 263 bits. Pour l’instant, ce n’est pas inquiétant, mais si
d’aventure on arrivait à faire baisser cette complexité, cela pourrait compromettre la sécurité
de l’intégralité du WiMax mobile.
On devrait pouvoir associer SHA-2 aux certificats X.509 afin de palier ce risque. Et dans
l’absolu, comme SHA-2 est un héritier de SHA-0 et SHA-1, il se pourrait qu’il s’avère lui-
même sensible aux attaques par collision, c’est pourquoi, comme suggéré dans [13] on devrait
laisser une possibilité de choix de protocoles de hachage associés aux certificats.
Heureusement, le WiMax mobile est une norme assez jeune et un changement de ce type ne
sera pas difficile à mettre en place. En revanche, bien que nécessaires, ces changements dans
la structure d’IPSec, de S/Mime, de TLS et d’autres protocoles de sécurité basés sur
l’utilisation de certificats, vont s’avérer plus difficiles à réaliser.
Après cette étude critique de la pertinence de certains choix de sécurité décidés par le WiMax
Forum dans l’établissement de la norme 802.16e, je vais analyser les failles de sécurité à
proprement parler, qu’elles soient héritées ou non du Wi-Fi.
32

33. 3.2 Mise en avant de vulnérabilités (Wireless, expérience Wi-Fi)
En 2006, les réseaux sans fil sont loin de constituer une solution technique mineure.
La zone de couverture des réseaux sans fil s’est ainsi élargie de façon très importante et
rapide ces dernières années. Le développement de ces technologies wireless s’est fait dans
pratiquement tous les domaines, du monde du cellulaire à celui des IP, en passant par le
bluetooth. Le principal exemple de cette expansion est l’essor magistral des réseaux Wi-Fi, et
ce, malgré des contraintes de faible efficacité et de manque de sécurité. La qualité du support
physique en Wi-Fi laisse en effet à désirer. De nombreuses études ont été consacrées aux
possibilités d’implémenter un semblant de QoS dans le 802.11.
Les nombreuses évolutions de la norme 802.11 ont tenté de résoudre ces problèmes de
fiabilité et de sécurité. Le MIMO et le 802.11i ont permis d’apporter récemment des solutions
provisoires intéressantes. Mais, avec l’explosion des besoins, cette norme s’avèrera très
rapidement insuffisante.
La nécessité de répondre à ces besoins de plus en plus pressants constitue une des principales
raisons du développement de la norme WiMax mobile. Cependant, cette norme sans fil,
héritière spirituelle du 802.11, répond effectivement aux attentes de débit/couverture, mais
qu’en est-il des attentes de fiabilité et de sécurité ?
3.2.1 Les failles qui ne se retrouvent pas en WiMax
La synthèse des diverses études sur la sécurité des normes composant le 802.11 [14]
montre que les failles de sécurité du 802.11 peuvent êtres scindées en deux catégories : les
failles d’identité et les failles MAC (Media Access Control). Les failles d’identité regroupent
toutes les usurpations d’identité et les attaques par rejeu. Les failles MAC regroupent les
attaques de type DoS, truchement sur la QoS (par mensonge sur la taille ou sur le type de
paquets qu’il envoie, ce qui réserve plus de ressource que nécessaire)
Les attaques par dé authentification ne se retrouvent pas en WiMax. Ces attaques basées sur
l’usurpation d’identité permettent à un client malveillant de forcer un autre usager à se
déconnecter par rejet de son authentification. En se faisant passer pour un Access Point, il est
très facile dans le monde Wi-Fi d’envoyer des faux messages de rejet d’authentification.
Dans la norme 802.16e les messages de contrôle étant signé par HMAC, personne ne peut
usurper l’identité d’une BS au cours d’une connexion. En revanche, un utilisateur malveillant
peut se faire passer pour une BS, au moment où la connexion s’établit, sachant qu’il n’y a pas
d’authentification mutuelle. Ceci ne reste valable que tant que la fiabilité du HMAC peut être
garantie. Or, comme nous l’avons signalé précédemment, il existe des doutes sur la fiabilité à
long terme de SHA-1.
33

34. 3.2.2 Les failles « classiques » du Wi-Fi dont le WiMax a hérité
Malgré les nombreuses études sur les failles de sécurité du Wi-Fi, les membres du
WiMax Forum n’ont pas trouvé de solutions à toutes ses failles, ou ont négligé leur
importance. De façon générale, les membres du WiMax Forum ont eu tendance à aborder la
question de la sécurité du WiMax mobile selon une approche très orientée sur
l’administration. Tout est fait pour assurer la sécurité de la station de base, mais le niveau de
sécurité des stations clientes demeure assez bas. Le problème de l’absence d’authentification
mutuelle a déjà été signalé dans ce document. Il représente une bonne illustration du manque
d’intérêt pour la sécurité des stations clientes. L’exemple d’attaque suivant est tout aussi
éloquent.
1) Attaque par rejeu
Les attaques par rejeu dans le 802.16e sont bien moins efficaces qu’en 802.11. En effet, en
802.11, il n’existe aucune méthode pour détecter des messages rejoués, ce qui peut entraîner
d’importants dénis de service.
Dans le 802.16e, l’attaquant peut capturer un message entier (c'est-à-dire avec sa signature
HMAC) et le rejouer tant qu’il reste dans la durée de vie de la clé de chiffrement. Il est
possible que les messages provenant de la BS ou de la SS utilisent des fréquences différentes
ce qui complique la tâche de l’attaquant qui doit être capable de recevoir et d’émettre sur de
multiples fréquences variables. Pour parasiter un réseau WiMax, on ne peut pas y déposer un
simple automate d’attaques par rejeu comme on pourrait le faire pour ruiner l’intégrité d’un
réseau Wi-Fi.
Certains messages ne sont pas rejouables car ils possèdent des informations temporelles ou
des numéros de série. Cependant certains messages ne possèdent pas ce type d’informations.
Même si dans la plupart des cas, un attaquant ne pourra se faire passer pour une BS et forcer
le client à se déconnecter (via des messages RES-CMD par exemple), il peut rejouer
massivement les messages du SS vers la BS, ce qui poussera la BS à envoyer un vrai RES-
CMD au client car il jugera que sa connexion est compromise suite à la réception
d’ « anormalité continue »[1]. Dans ce cas, l’attaquant a partiellement gagné. Il a réussi à
briser la connexion entre le SS et la BS. On constate encore une fois que la sécurité est
assurée au niveau de la BS mais pas au niveau du client.
2) Spoofing (man in the middle)
Cette attaque est difficile à mettre en place dans un environnement filaire mais facile à
déployer dans un monde sans fil. Il suffit juste de placer un AP (Access Point) plus attractif
entre le client et le « vrai » AP. L’utilisateur malveillant peut capter tous les messages en
provenance du client et se faire passer pour lui auprès du vrai AP. Cette attaque est possible
en WiMax mobile car il n’existe pas d’authentification mutuelle. Ce qui rend possible
l’établissement d’une SA corrompue.
34

35. 3) Attaque par collision
En 802.11 le CSMA était utilisé pour éviter les collisions ce qui permettait à un client
malveillant d’empêcher assez facilement toute connexion d’autres clients dans sa zone
d’émission.
En 802.16e, la viabilité d’une transmission ne se calcule pas via l’écoute sur la porteuse, mais
à l’aide des DL-MAP et UL-MAP. La détection de collision est utilisée plutôt que la
prévention de collision. Au moment de la connexion, chaque client, avant authentification,
reçoit les messages UL-MAP et DL-MAP. Ces messages contiennent les informations de
transmission et de modulation de toutes les stations clientes de la station de base. Autrement
dit quasiment toutes les informations dont la station maligne a besoin pour mener son attaque.
La station maligne ne peut certes pas cibler un client particulier mais elle peut, à l’aide des
informations préalablement obtenues, une fois qu’elle a ajusté sa puissance d’émission pour
être bien entendue par la station de base, choisir un CID et émettre aux instants où la station
cliente correspondant à ce CID doit émettre. Selon les puissances émettrices des deux stations,
la station de base recevra alors, soit un message fortement bruité, soit un message
complètement corrompu.
Il va de soi qu’une station maligne peut s’en prendre à plusieurs stations clientes en même
temps. De plus, ces attaques sont peu coûteuses pour la station maligne. Il lui suffit d’envoyer
de courts messages aux moments clés. Ces messages peuvent être des messages parfaitement
légitimes, voire rejoués. Elle peut donc être difficile à traquer. Ce type d’attaque peut
entraîner la déconnexion forcée de nombreux clients, et la famine d’autres.
Le changement de puissance et le Forward Error Correction (FEC) que la BS mettra en place
dès qu’elle se rendra compte des problèmes sur le réseau seront inefficaces, car la station
maligne recevra elle aussi ces informations, et elle pourra donc dynamiquement ajuster sa
puissance et son timeur d’émission.
4) Usurpation d’adresse MAC
Le contrôle d’accès par adresse MAC, fréquemment utilisé dans les VLANs par exemple, est
une technique inefficace dans le monde Wi-Fi. Malheureusement elle est tout autant
inefficace dans le monde du WiMax mobile.
En effet, les adresses MAC des clients autorisés sont transmises en clair dans les messages
Ranging Request (RNG-REQ) tout comme les messages réponses associés (RNG-RSP), ce
qui donne deux chances à un utilisateur malveillant d’obtenir l’adresse MAC d’un client
autorisé. Une fois sur le downlink, puis une autre fois sur l’uplink.
La seule inconnue pour l’instant est la difficulté de changer la valeur de son adresse MAC.
Dans la mesure où je n’ai pas pu obtenir de terminal WiMax Certifié, il ne m’a pas été
possible de vérifier s’il est aussi trivial de changer une adresse MAC WiMax qu’une adresse
MAC Wi-Fi. Mais tout laisse à penser qu’un tel changement serait assez facile, et pourrait
même s’opérer au niveau de la couche logiciel du terminal.
35

36. 3.2.3 Les failles spécifiques du WiMax
Dans l’automate d’envoi de messages des stations de base du WiMax mobile, il existe
une étape de vérification de la conformité des messages avant l’envoi de ces derniers sur le
réseau. Cependant, il est possible de sauter cette étape en forçant l’accès via le port auxiliaire
qui renvoie alors directement à la SRAM sans passer par l’automate de validation. Il serait
ainsi possible d’écrire par-dessus les données validées, ce qui aboutirait à l’envoi d’un
message invalide et perturberait le réseau.
Dans la mesure où je ne dispose pas des spécifications sur les matériels certifiés
WiMax, je ne peux dire si cette attaque pourrait ou non être effectivement déployée. Mais, s’il
est possible d’accéder au firmware de son antenne, il sera alors possible de le flasher et de
forcer le passage sur le port auxiliaire de certains messages.
C’est pour l’instant le seul problème spécifique au WiMax Mobile que j’ai identifié. Mais il
est plus que probable que d’autres problèmes restent à découvrir et que cette recherche
gagnerait à être poursuivie après ce stage.
36

37. 4EME CHAPITRE : HANDOVER VERTICAL ET DIAGONAL
La durée impartie à ce stage ne m’a malheureusement pas permis d’approfondir cette
question autant que je l’aurai souhaité. D’après la littérature disponible, l’outil essentiel pour
s’assurer d’un handover vertical est l’utilisation de message Routers Advertisment (RA) ou les
Routers Sollicitation (RS). J’ai comparé rapidement les autres solutions (N-casting, Multicast,
contrôle bout en bout, division de la connexion) et je suis arrivé à la conclusion suivante.
Pour le WiMax Mobile, la gestion de handover via des mini groupes multicasts dans lesquels
on inclut, en plus du client et de la station de base, les antennes Wi-Fi/UMTS ou d’autres à
portée, semble être la solution la plus efficace en terme de rapidité, de coûts de messages et de
négociation de SA.
Il est possible de créer ce type de groupe sans changer l’implémentation de la norme. De plus,
on peut ajouter aux stations Wi-Fi ou UMTS ou GPRS, un module de gestion EAP/TLS pour
assurer la gestion des authentifications EAP ainsi que les transferts des clés de chiffrement.
Ceci garantirait (du moins pour le côté transport) le maintien de la sécurité à un niveau très
proche de celui de la SA en cours.
Il aurait été intéressant de disposer d’un temps suffisant pour analyser s’il était plausible de
créer un protocole de positionnement par puissance d’émission, où la BS estimerait une
position radiale du (des) client(s) selon leurs puissances, et choisirait un axe selon l’estimation
radiale des autres antennes (Wi-Fi, UMTS, GPRS). Je regrette de ne pas avoir disposé de
suffisamment de temps pour réfléchir à un tel protocole.
Dans le cas d’un handover diagonal, on revient sur un support filaire et donc la question du
maintien du niveau de sécurité ne se pose pas à partir du moment où le réseau rejoint possède
un niveau de sécurité et de confiance suffisant pour l’usager.
37

38. 38

39. 5EME CHAPITRE : QUID DU SUPPORT LOGICIEL ?
Il est évident que la structure par TPM jouera un rôle majeur dans la sécurité dans un
futur proche. Cependant pour l’instant, cette structure n’est encore qu’émergente. Il faut aussi
noter la solution proposée par IBM : Secure Blue, censé protéger les données des mobiles, des
ordinateurs portables ou des PDA. Secure Blue peut supprimer les données si une tentative
d’intrusion est détectée (détectée via un changement dans la signature comportementale, ie
une altération de la base de registre, une utilisation suspecte de certains logiciels, des actions
sur la black liste, …). Secure Blue pourrait être lié aux DRM, et serait alors intégré
directement dans les processeurs.
Là où le TPM possède une architecture hors processeur et donc potentiellement accessible,
Secure Blue pourrait être une meilleure option. Cependant, comme nous l’avons vu lors de
cette étude, le poids des enjeux politico-économiques est très important dans l’établissement
d’une norme au profit d’une autre, d’un protocole ou même d’un algorithme. Les ténors
(Microsoft, Intel, etc) s’étant lancés sur le TPM, il est plus probable que ce soit ce dernier qui
l’emporte sur la solution d’IBM.
On a vu dans le monde du WiMax mobile, qu’une solution TPM pourrait prendre le contrôle
des actions et PKM, ce qui permettrait une protection au niveau logique et rendrait caduque
l’usage de spywares, trojans ou autres malwares.
Cependant, pour une question d’équité d’utilisation, tous les PDA, les mobiles voire les
ordinateurs portables ne supporteront pas forcément les TPM (AMD par exemple s’oppose
pour l’instant à cette solution). Aussi est-il plausible d’envisager une autre solution, par
exemple ne remonter que la gestion de l’authentification EAP au niveau logiciel avec
l’utilisation de modules types SmartCard EAP/TLS, ce qui serait équitable au niveau de tous
les terminaux possibles (étant donné que la gestion serait faite dans un module séparé).
Comme il a été expliqué au chapitre précédent, cette solution présente l’avantage d’apporter
également une assurance de sécurité au niveau handover verticaux.
39

40. 40

41. CONCLUSION
Durant ce stage, il a été mis en avant que la sécurité du WiMax mobile n’était pas garantie
dans tous les cas. Pour certaines de ces failles de sécurité j’ai proposé des améliorations,
quasiment toutes déjà existantes et donc éprouvées dans des contexte pseudo similaires.
Il aurait été préférable bien sûr de pouvoir disposer de matériel certifié WiMax pour éprouver
certaines de ces hypothèses et notamment mettre en place un protocole de gestion du
handover vertical. Malheureusement traiter d’un sujet aussi récent, frais, dans le monde de
l’informatique permet d’explorer énormément de pistes et de solutions mais pose des
difficultés de manque de rapports d’autres équipes, un manque de support matériel.
J’ai néanmoins pris beaucoup de plaisir à effectuer cette recherche et à réaliser ces
projections.
On peut résumer les points essentiels d’amélioration de la sécurité ainsi :
• Une authentification mutuelle imposée.
Les BS possèdent leurs certificats. Il est aisé de s’en servir dans tous les
cas de figure et non pas seulement dans les cas de multicast ou
broadcast.
• Indexer tous les messages pour se protéger du rejeu.
Certains messages étant rejouables, ils peuvent entraîner la déconnexion
de clients victimes d’attaques. Pour prévenir ceci, il faudrait pouvoir
identifier les messages rejoués. Un index temporel au sein de la partie
chiffré/signé du message est nécessaire.
• Protéger les adresses MAC.
Si l’on veut pouvoir se prévenir facilement des attaques par collision et
n’autoriser que les clients validés à tenter de se connecter au réseau, il
faut pouvoir s’assurer que leurs adresses MAC sont bien valides. Pour
l’instant ce n’est pas possible. On peut limiter les risques d’exposition
des adresses MAC en chiffrant via clé publique les adresses MAC des
clients dans les messages de Ranging. Clé publique client pour la
réponse et clé publique station de base pour la requête, ce qui suppose
qu’authentification mutuelle a été mise en place, ou du moins que la
station de base a communiqué son certificat X509.
• Ne plus transmettre toutes les informations de schéduleurs aux clients.
Se protéger des collisions semble pour l’instant impossible. On peut en
revanche rendre plus coûteuse pour l’attaquant, une attaque par
collision en ne lui communiquant que les temps et fréquences auxquels
il aura le droit d’émettre. Ainsi, lors d’une tentative d’attaque, il ne
41

42. pourra pas être sûr d’avoir émis au bon moment et à la bonne fréquence,
et provoquera dans la majorité des cas seulement un bruitage sur le
réseau et non plus un parasitage énorme.
• Utiliser des modules externes de gestion EAP/TLS.
La gestion des protocoles d’authentification EAP étant hors de
l’extension du 802.16e, il est possible de remonter cette gestion au
niveau de modules EAP/TLS. Ceci permettrait de rendre plus forte une
authentification mutuelle et de maintenir un niveau de sécurité
minimum lors de handover verticaux descendants.
De nombreuses suites des questions abordées lors ce stage m’apparaissent utiles. Bien
évidemment, dès que du matériel certifié WiMax mobile sera disponible, il sera essentiel
d’éprouver les résultats obtenus lors de ce stage.
Il faudrait aussi pousser les tests sur les architectures TPM, Secure Blue et toute nouvelle
solution qui sera proposée pour descendre au niveau physique, la gestion de chiffrement et les
autres protocoles de sécurité.
L’étude approfondie et la création d’un protocole de gestion de fast and seamlesse handover
verticaux, tel qu’évoqué trop rapidement dans le chapitre 4, constitueraient aussi un point très
important à développer dans un futur proche.
D’une manière plus large, il semble qu’on a atteint un niveau de sécurité assez fort pour les
algorithmes de chiffrement, surtout si l’on considère l’arrivée des fonctions de chiffrement
chaotiques et plus tard de modules de chiffrement quantiques. Une association des deux serait
en effet invulnérable à toutes les attaques connues à l’heure actuelle. En revanche, il reste
encore beaucoup de progrès à faire au niveau des algorithmes de hachage. Gageons que les
évolutions essentielles dans le monde de la cryptographie, dans les années à venir, se feront
autour de ces fonctions de hachage.
Je tiens encore une fois à remercier toute l’équipe du corps professoral du master réseaux &
télécommunication ainsi que tous les membres du LIP6 et tout particulièrement mes tuteurs
monsieur Pujole et monsieur Urien, pour m’avoir permis de mener ce stage dans des
conditions aussi agréables.
42

43. BIBLIOGRAPHIE
[1] Norme et drafts IEEE
[2] 802.16e Notes - Mitchell Group, Anupam Datta Changhua He John C. Mitchell Arnab
Roy Mukund Sundararajan
[3] Sécurité et nomadisme, C. Gross, L. Saccavini & L. Aublet-Cuvelier
[4] Cours de sécurité ENST, P. Urien
[5] Cours de sécurité ENST, M. Riguidel
[6] Cours de Réseaux de Télécommunications, G. Pujolle
[7] Mobile WiMAX – Part I: A Technical Overview and Performance Evaluation
[8] Correct Figure for TEK management in BS and MS, Sangwoo Doe, Sungsoo Oh, Sungho
Yoo
[9] Counter with CBC-MAC (CCM), R. Housley
[10] AES mode for 802.16, D. Johnston (Intel)
[11] IEEE 802.16e Security Review, Jeff Mandin, Streetwaves Networks Yoshihiro Ohba
Toshiba, Bernard Aboba Microsoft
[12] Do WLAN really pay? Brad Smith, Wireless Week.
[13] Deploying a New Hash Algorithm, S. Bellovin et E. Rescorla
[14] J. Bellardo and S. Savage. “802.11 Denial-of-Service Attacks: Real Vulnerabilities
and Practical Solutions.” Presented at 11th USENIX Security Symposium, 2003.
[15] Broadband Wireless Access with WiMax8O2.16 Current Performance, Arunabha Ghosh,
David R. Wolter, Jeffrey G. Andrews et Runhua Chen
[16] Enhancement of 802.16e to Support EAP-based Authentication / Key Distribution
Rev. 0, Jeff Mandin
[17] 802.16e Security Motivations and Needs, David Johnston
[18] Clarification of the AES-CBC mode, Sungcheol Chang, Eunkyung Kim, Seokheon
Cho et Chulsik Yoon
[19] Correct Figure for TEK management in BS and MS, Sangwoo Doe, Sungsoo Oh,
SungHo Yoo
[20] TEK delivery problem fix for related management message, Jun Zhang, Yongmao Li,
John Lee, Thomas Lee( Li Li )
[21] Security of IEEE 802.16, Arkoudi-Vafea Aikaterini
43