SlideShare une entreprise Scribd logo
1  sur  43
Télécharger pour lire hors ligne
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
•   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
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
Figure 10 - Processus de chiffrement par défaut




Figure 11 - Processus de chiffrement en AES-CCM




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

Contenu connexe

Tendances

Mémoire de fin d'étude: Migration de la téléphonie classique vers la téléphon...
Mémoire de fin d'étude: Migration de la téléphonie classique vers la téléphon...Mémoire de fin d'étude: Migration de la téléphonie classique vers la téléphon...
Mémoire de fin d'étude: Migration de la téléphonie classique vers la téléphon...Coulibaly Kidjomitchin Jean-Marc
 
NGN MULTIMEDIA/IMS UMTS DIMENSIONEMENT
NGN MULTIMEDIA/IMS  UMTS  DIMENSIONEMENTNGN MULTIMEDIA/IMS  UMTS  DIMENSIONEMENT
NGN MULTIMEDIA/IMS UMTS DIMENSIONEMENTMAGAYE GAYE
 
Rapport de Stage -Finale.pdf
Rapport de Stage -Finale.pdfRapport de Stage -Finale.pdf
Rapport de Stage -Finale.pdfWaelTOUMI2
 
Mise en place de la telephonie ip avec Asterisk
Mise en place de la telephonie ip avec AsteriskMise en place de la telephonie ip avec Asterisk
Mise en place de la telephonie ip avec AsteriskPape Moussa SONKO
 
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISKETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISKbamaemmanuel
 
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !Massimo Russo
 
éTude et mise_en_place_d'une_solution_voip_sécurisée
éTude et mise_en_place_d'une_solution_voip_sécuriséeéTude et mise_en_place_d'une_solution_voip_sécurisée
éTude et mise_en_place_d'une_solution_voip_sécuriséeSaad Jouhari
 
conception et réalisation d'une application de gestion des rapports téléphoni...
conception et réalisation d'une application de gestion des rapports téléphoni...conception et réalisation d'une application de gestion des rapports téléphoni...
conception et réalisation d'une application de gestion des rapports téléphoni...ismailbou
 
Rapport PFE-Implémentation de la solution Dual-Homing
Rapport PFE-Implémentation de la solution Dual-Homing Rapport PFE-Implémentation de la solution Dual-Homing
Rapport PFE-Implémentation de la solution Dual-Homing Hassane Sennouni
 
Rapport de stage TOIP/VOIP
Rapport de stage TOIP/VOIPRapport de stage TOIP/VOIP
Rapport de stage TOIP/VOIPMounir Kaali
 
La technique de transmission OFDM
La technique de transmission OFDMLa technique de transmission OFDM
La technique de transmission OFDMChiheb Ouaghlani
 
Projet haute disponibilité asterisk pdf
Projet haute disponibilité asterisk pdfProjet haute disponibilité asterisk pdf
Projet haute disponibilité asterisk pdfAbderahim Amine Ali
 
Concept et réalisation d’un système de communication unifiée multi-sites
Concept et réalisation d’un système de communication unifiée multi-sitesConcept et réalisation d’un système de communication unifiée multi-sites
Concept et réalisation d’un système de communication unifiée multi-sitesAmadou Dia
 
Rapport stage IP-MSAN Tunisie télécom
Rapport stage IP-MSAN Tunisie télécomRapport stage IP-MSAN Tunisie télécom
Rapport stage IP-MSAN Tunisie télécomSiwar GUEMRI
 
ETUDE DE L'EVOLUTION DU COEUR PAQUET 3G VERS L'EPC
ETUDE DE L'EVOLUTION DU COEUR PAQUET 3G VERS L'EPCETUDE DE L'EVOLUTION DU COEUR PAQUET 3G VERS L'EPC
ETUDE DE L'EVOLUTION DU COEUR PAQUET 3G VERS L'EPCOkoma Diby
 
Rapport de-stage-technecien
Rapport de-stage-technecienRapport de-stage-technecien
Rapport de-stage-technecienghazwanikhouloud
 

Tendances (20)

Mémoire de fin d'étude: Migration de la téléphonie classique vers la téléphon...
Mémoire de fin d'étude: Migration de la téléphonie classique vers la téléphon...Mémoire de fin d'étude: Migration de la téléphonie classique vers la téléphon...
Mémoire de fin d'étude: Migration de la téléphonie classique vers la téléphon...
 
NGN MULTIMEDIA/IMS UMTS DIMENSIONEMENT
NGN MULTIMEDIA/IMS  UMTS  DIMENSIONEMENTNGN MULTIMEDIA/IMS  UMTS  DIMENSIONEMENT
NGN MULTIMEDIA/IMS UMTS DIMENSIONEMENT
 
Rapport de Stage -Finale.pdf
Rapport de Stage -Finale.pdfRapport de Stage -Finale.pdf
Rapport de Stage -Finale.pdf
 
Mise en place de la telephonie ip avec Asterisk
Mise en place de la telephonie ip avec AsteriskMise en place de la telephonie ip avec Asterisk
Mise en place de la telephonie ip avec Asterisk
 
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISKETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
 
Etude de la VoIP
Etude de la VoIPEtude de la VoIP
Etude de la VoIP
 
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
 
éTude et mise_en_place_d'une_solution_voip_sécurisée
éTude et mise_en_place_d'une_solution_voip_sécuriséeéTude et mise_en_place_d'une_solution_voip_sécurisée
éTude et mise_en_place_d'une_solution_voip_sécurisée
 
conception et réalisation d'une application de gestion des rapports téléphoni...
conception et réalisation d'une application de gestion des rapports téléphoni...conception et réalisation d'une application de gestion des rapports téléphoni...
conception et réalisation d'une application de gestion des rapports téléphoni...
 
Rapport PFE-Implémentation de la solution Dual-Homing
Rapport PFE-Implémentation de la solution Dual-Homing Rapport PFE-Implémentation de la solution Dual-Homing
Rapport PFE-Implémentation de la solution Dual-Homing
 
Rapport de stage TOIP/VOIP
Rapport de stage TOIP/VOIPRapport de stage TOIP/VOIP
Rapport de stage TOIP/VOIP
 
La technique de transmission OFDM
La technique de transmission OFDMLa technique de transmission OFDM
La technique de transmission OFDM
 
Projet haute disponibilité asterisk pdf
Projet haute disponibilité asterisk pdfProjet haute disponibilité asterisk pdf
Projet haute disponibilité asterisk pdf
 
Concept et réalisation d’un système de communication unifiée multi-sites
Concept et réalisation d’un système de communication unifiée multi-sitesConcept et réalisation d’un système de communication unifiée multi-sites
Concept et réalisation d’un système de communication unifiée multi-sites
 
Rapport stage IP-MSAN Tunisie télécom
Rapport stage IP-MSAN Tunisie télécomRapport stage IP-MSAN Tunisie télécom
Rapport stage IP-MSAN Tunisie télécom
 
ETUDE DE L'EVOLUTION DU COEUR PAQUET 3G VERS L'EPC
ETUDE DE L'EVOLUTION DU COEUR PAQUET 3G VERS L'EPCETUDE DE L'EVOLUTION DU COEUR PAQUET 3G VERS L'EPC
ETUDE DE L'EVOLUTION DU COEUR PAQUET 3G VERS L'EPC
 
Rapport de-stage-technecien
Rapport de-stage-technecienRapport de-stage-technecien
Rapport de-stage-technecien
 
Rapport de stage bts
Rapport de stage btsRapport de stage bts
Rapport de stage bts
 
ToIP
ToIPToIP
ToIP
 
Présentation 5 g
Présentation 5 gPrésentation 5 g
Présentation 5 g
 

En vedette

wimax Ppt for seminar
wimax Ppt for seminarwimax Ppt for seminar
wimax Ppt for seminarPratik Anand
 
Wi Max Network Architecture V0.1 Pdf Version
Wi Max Network Architecture V0.1 Pdf VersionWi Max Network Architecture V0.1 Pdf Version
Wi Max Network Architecture V0.1 Pdf VersionDeepak Sharma
 
Présentation projet fin d'etude licence informatique 2009
Présentation projet fin d'etude licence informatique 2009Présentation projet fin d'etude licence informatique 2009
Présentation projet fin d'etude licence informatique 2009Aniss Bouraba
 
Rapport de stage de Licence 3 à la societé Tradex
Rapport de stage de Licence 3 à la societé TradexRapport de stage de Licence 3 à la societé Tradex
Rapport de stage de Licence 3 à la societé TradexJeff Hermann Ela Aba
 
Rapport de stage de fin d'etude l3 angelito & hasina
Rapport de stage de fin d'etude l3 angelito & hasinaRapport de stage de fin d'etude l3 angelito & hasina
Rapport de stage de fin d'etude l3 angelito & hasinaAngelito Mandimbihasina
 
Rapport de stage Fiduciaire3
Rapport de stage Fiduciaire3Rapport de stage Fiduciaire3
Rapport de stage Fiduciaire3Rapport de Stage
 
Rapport de stage bts finances comptabilite et gestion d entreprises
Rapport de stage  bts finances comptabilite et gestion  d entreprises Rapport de stage  bts finances comptabilite et gestion  d entreprises
Rapport de stage bts finances comptabilite et gestion d entreprises Constant Mousso
 
85996899 berrada-fiduciaire-comptabilites-conseils-etudes
85996899 berrada-fiduciaire-comptabilites-conseils-etudes85996899 berrada-fiduciaire-comptabilites-conseils-etudes
85996899 berrada-fiduciaire-comptabilites-conseils-etudesSara Làtif
 
Radio ou Laser pour l’interconnexion de bâtiments
Radio ou Laser pour l’interconnexion de bâtimentsRadio ou Laser pour l’interconnexion de bâtiments
Radio ou Laser pour l’interconnexion de bâtimentsYves-Alain STORY
 
Synthèse des Réseaux
Synthèse des RéseauxSynthèse des Réseaux
Synthèse des RéseauxPaulin CHOUDJA
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Riadh K.
 

En vedette (20)

Wifi wimax
Wifi wimaxWifi wimax
Wifi wimax
 
Wimax
WimaxWimax
Wimax
 
WiMAX
WiMAXWiMAX
WiMAX
 
Wimax
WimaxWimax
Wimax
 
Wimax / ieee 802.16
Wimax / ieee 802.16Wimax / ieee 802.16
Wimax / ieee 802.16
 
Wimax
WimaxWimax
Wimax
 
wimax Ppt for seminar
wimax Ppt for seminarwimax Ppt for seminar
wimax Ppt for seminar
 
Wi Max Network Architecture V0.1 Pdf Version
Wi Max Network Architecture V0.1 Pdf VersionWi Max Network Architecture V0.1 Pdf Version
Wi Max Network Architecture V0.1 Pdf Version
 
Présentation projet fin d'etude licence informatique 2009
Présentation projet fin d'etude licence informatique 2009Présentation projet fin d'etude licence informatique 2009
Présentation projet fin d'etude licence informatique 2009
 
Rapport de stage de Licence 3 à la societé Tradex
Rapport de stage de Licence 3 à la societé TradexRapport de stage de Licence 3 à la societé Tradex
Rapport de stage de Licence 3 à la societé Tradex
 
Rapport de stage de fin d'etude l3 angelito & hasina
Rapport de stage de fin d'etude l3 angelito & hasinaRapport de stage de fin d'etude l3 angelito & hasina
Rapport de stage de fin d'etude l3 angelito & hasina
 
Wimax
WimaxWimax
Wimax
 
Wimax
WimaxWimax
Wimax
 
Rapport de stage Fiduciaire3
Rapport de stage Fiduciaire3Rapport de stage Fiduciaire3
Rapport de stage Fiduciaire3
 
Rapport de stage bts finances comptabilite et gestion d entreprises
Rapport de stage  bts finances comptabilite et gestion  d entreprises Rapport de stage  bts finances comptabilite et gestion  d entreprises
Rapport de stage bts finances comptabilite et gestion d entreprises
 
85996899 berrada-fiduciaire-comptabilites-conseils-etudes
85996899 berrada-fiduciaire-comptabilites-conseils-etudes85996899 berrada-fiduciaire-comptabilites-conseils-etudes
85996899 berrada-fiduciaire-comptabilites-conseils-etudes
 
Radio ou Laser pour l’interconnexion de bâtiments
Radio ou Laser pour l’interconnexion de bâtimentsRadio ou Laser pour l’interconnexion de bâtiments
Radio ou Laser pour l’interconnexion de bâtiments
 
WiMAX vs LTE
WiMAX vs LTEWiMAX vs LTE
WiMAX vs LTE
 
Synthèse des Réseaux
Synthèse des RéseauxSynthèse des Réseaux
Synthèse des Réseaux
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
 

Similaire à Rapport De Stage SéCurité Wimax Mobile

Wifi professionnel la norme 802.11, le déploiement, la sécurité 3ème edition
Wifi professionnel la norme 802.11, le déploiement, la sécurité   3ème editionWifi professionnel la norme 802.11, le déploiement, la sécurité   3ème edition
Wifi professionnel la norme 802.11, le déploiement, la sécurité 3ème editionelpunk
 
IRCAD, Internship Report
IRCAD, Internship ReportIRCAD, Internship Report
IRCAD, Internship ReportRaphaël Bils
 
Wifiprofessionnellanorme80211ledeploiementlasecurite
Wifiprofessionnellanorme80211ledeploiementlasecuriteWifiprofessionnellanorme80211ledeploiementlasecurite
Wifiprofessionnellanorme80211ledeploiementlasecuriteRiadh Briki
 
Chaire NewNet@Paris Cisco Télécom ParisTech : dossier de presse
Chaire NewNet@Paris Cisco Télécom ParisTech : dossier de presseChaire NewNet@Paris Cisco Télécom ParisTech : dossier de presse
Chaire NewNet@Paris Cisco Télécom ParisTech : dossier de presseTélécom Paris
 
rapport de stage 2021.docx
rapport de stage 2021.docxrapport de stage 2021.docx
rapport de stage 2021.docxAlexLissom
 
Rapport simo issam
Rapport simo issamRapport simo issam
Rapport simo issamsimomans
 
0108-formation-ccna-module-4.pdf
0108-formation-ccna-module-4.pdf0108-formation-ccna-module-4.pdf
0108-formation-ccna-module-4.pdfbessem ellili
 
Déportation d'une connexion Internet via WiFi
Déportation d'une connexion Internet via WiFiDéportation d'une connexion Internet via WiFi
Déportation d'une connexion Internet via WiFiSiriki Coulibaly
 
Déploiement efficace de réseaux de capteurs.pdf
Déploiement efficace de réseaux de capteurs.pdfDéploiement efficace de réseaux de capteurs.pdf
Déploiement efficace de réseaux de capteurs.pdfjackjohn45
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsUniversité de Rennes 1
 
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...yosra fraiji
 
Rapport Splunk.pdf
Rapport Splunk.pdfRapport Splunk.pdf
Rapport Splunk.pdfHichemKhalfi
 
Memoire de fin de cycle webrtc to ip (1)
Memoire de fin de cycle webrtc to ip (1)Memoire de fin de cycle webrtc to ip (1)
Memoire de fin de cycle webrtc to ip (1)AbdoulayeNdiaye54
 
Asterisk report
Asterisk reportAsterisk report
Asterisk reporttatbirt
 

Similaire à Rapport De Stage SéCurité Wimax Mobile (20)

Wifi professionnel la norme 802.11, le déploiement, la sécurité 3ème edition
Wifi professionnel la norme 802.11, le déploiement, la sécurité   3ème editionWifi professionnel la norme 802.11, le déploiement, la sécurité   3ème edition
Wifi professionnel la norme 802.11, le déploiement, la sécurité 3ème edition
 
Wifi pro
Wifi proWifi pro
Wifi pro
 
IRCAD, Internship Report
IRCAD, Internship ReportIRCAD, Internship Report
IRCAD, Internship Report
 
Wifiprofessionnellanorme80211ledeploiementlasecurite
Wifiprofessionnellanorme80211ledeploiementlasecuriteWifiprofessionnellanorme80211ledeploiementlasecurite
Wifiprofessionnellanorme80211ledeploiementlasecurite
 
siem.pdf
siem.pdfsiem.pdf
siem.pdf
 
Chaire NewNet@Paris Cisco Télécom ParisTech : dossier de presse
Chaire NewNet@Paris Cisco Télécom ParisTech : dossier de presseChaire NewNet@Paris Cisco Télécom ParisTech : dossier de presse
Chaire NewNet@Paris Cisco Télécom ParisTech : dossier de presse
 
rapport de stage 2021.docx
rapport de stage 2021.docxrapport de stage 2021.docx
rapport de stage 2021.docx
 
Reseaux
ReseauxReseaux
Reseaux
 
Rapport simo issam
Rapport simo issamRapport simo issam
Rapport simo issam
 
0108-formation-ccna-module-4.pdf
0108-formation-ccna-module-4.pdf0108-formation-ccna-module-4.pdf
0108-formation-ccna-module-4.pdf
 
Déportation d'une connexion Internet via WiFi
Déportation d'une connexion Internet via WiFiDéportation d'une connexion Internet via WiFi
Déportation d'une connexion Internet via WiFi
 
Déploiement efficace de réseaux de capteurs.pdf
Déploiement efficace de réseaux de capteurs.pdfDéploiement efficace de réseaux de capteurs.pdf
Déploiement efficace de réseaux de capteurs.pdf
 
Memoire license iii
Memoire license iiiMemoire license iii
Memoire license iii
 
Projet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objetsProjet Passerelle sécurisée intelligente pour l'internet des objets
Projet Passerelle sécurisée intelligente pour l'internet des objets
 
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
rapport de mémoire de mastère : sécurisation du réseau nan au sein des smart ...
 
Cours réseauxf
Cours réseauxfCours réseauxf
Cours réseauxf
 
Rapport Splunk.pdf
Rapport Splunk.pdfRapport Splunk.pdf
Rapport Splunk.pdf
 
Memoire de fin de cycle webrtc to ip (1)
Memoire de fin de cycle webrtc to ip (1)Memoire de fin de cycle webrtc to ip (1)
Memoire de fin de cycle webrtc to ip (1)
 
Routage adhoc
Routage adhocRoutage adhoc
Routage adhoc
 
Asterisk report
Asterisk reportAsterisk report
Asterisk report
 

Rapport De Stage SéCurité Wimax Mobile

  • 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