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

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).

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.

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

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

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.

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.

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.

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 WMAN1. Ces technologies sont à la fois concurrentes et complémentaires des technologies WPAN2, WLAN3, WRAN4, WWAN5 (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

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)

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.

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.

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.

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 OFDM6 classique. Elle supporte aussi le MIMO7. 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

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.

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.

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é.

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 AAA8, de type RADIUS9 ou TACACS10 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

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.

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.

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).

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é.

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.

28

Figure 10 - Processus de chiffrement par défaut

Figure 11 - Processus de chiffrement en AES-CCM

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).

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

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

0

10

20

30

40

50

60

70

32K 64K 128K 256K 512K

Taille du paquet à chiffrer en bits

Vite

sses

en

MB

/s SHA-1MD-5AES (128 bits)DES-EDE (112bits)DES-EDE (160 bits)Blowfish

Figure 12 - Comparatif des vitesses de chiffrement/hachage des principaux algorithmes

32

Temps de chiffrement/hachage

0

0,05

0,1

0,15

0,2

0,25

0,3

32K 64K 128K 256K 512K

Taille du paquet en bits

Tem

ps e

n se

cond

es SHA-1MD-5AES (128 bits)DES-EDE (112bits)DES-EDE (160 bits)Blowfish

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.

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.

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.

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.

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.

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.

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.

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

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.

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