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