Réseaux sans fils sécurisés WPA2 - Securité Réseau WIFI - WPA2

WPA2

Définition

802.11i   (WPA2)  est  une norme  tendant  à sécuriser  un accès  sans  fils   (Wi-Fi).  Dans  la version « WPA2-Enterprise », celle qui nous intéresse ici, il nous faut 802.1x pour assurer l'attachement du « supplicant » à point d'accès et RADIUS pour la partie authentification. RADIUS n'est pas obligé par la norme, mais c'est un standard de fait.

Risques à éviter

Dans une connexion sans fils, il convient de prendre un soin particulier à être sûr que :
            

• l'on s'adresse au bon serveur d'authentification,
• le point d'accès est bien celui que l'on croit,
• le client est bien autorisé,
• le client est bien celui qu'il prétend être,
• il n'y a pas de « man in the middle »,
• un point  d'accès « voleur » ne peut  prendre en cours de session la place du point  d'accès « officiel »,
• un espion ne pourra pas, dans un délai raisonnable, déchiffrer les informations qui circulent dans l'air.

              
Il y a donc du travail.

Principe de fonctionnement
                     

                 

Les   protocoles   d'authentification   (TLS,   PEAP,  TTLS...)   ne   sont   pas   du   domaine   de   802.1X, RADIUS non plus.

Cependant, compte tenu de ce qui a été déjà vu, il est clair qu'il n'y a pas d'alternative.
         

       
1. Quand  le  client   (supplicant)   et   le   serveur  d'authenticication  (AS)   s'authentifient,  un des derniers messages envoyés par le serveur, contient la « Master Key » (MK). Cette clé n'est connue que par le client et le serveur. La MK n'est valable que pour cette session, entre ce client et ce serveur.

2. Le client et le serveur calculent, à partir de la PMK, une nouvelle clé, nommée « Pairwise Master Key » (PMK)

3. La PMK est déplacée du serveur vers le point d'accès. Seuls le client et le serveur savent calculer cette PMK, sinon, le point d'accès pourrait prendre des décisions de contrôle d'accès à la place du serveur. La PMK est une nouvelle clé symétrique,  valable uniquement pour cette session, entre ce client et ce point d'accès.

4. La PMK et une poignée de main en quatre passes (« 4-way handshake ») sont utilisées entre le client et le point d'accès pour calculer et vérifier une « Pairwise Transcient Key » (PTK), qui sera utilisée uniquement dans cette session entre ce client et ce point d'accès. La PTK est en réalité un trousseau de trois clés :
        

• la « Key Confirmation Key » (KCK) qui, comme son nom l'indique, est utilisée pour prouver la possession de la PMK et pour attacher la PMK au point d'accès,
• la « Key Encryption Key » (KEK) est utilisée pour distribuer la « Group Transcient Key » (GTK), décrite plus loin,
• les « Temporal Key 1 & 2 » (TK1/TK2) sont utilisées pour le chiffrement.

           
5. la  KEK  et  un  autre  « 4-way handshake »  sont   alors  utilisés  pour   envoyer  une  « Group Transcient Key » (GTK) du point d'accès vers le client. La GTK est partagée par tous les clients  connectés   au même  point  d'accès.  Elle  est  utilisée uniquement  pour   sécuriser   le multicast et le broadcast.

En résumé :
               

             
1. La MK représente la décision d'accès (positive).
2. La PMK représente l'autorisation d'accès au medium 802.11.
3. La PTK, contient :
                         

• la KCK, utilisée pour attacher la PMK au point d'accès et pour prouver que le point d'accès dispose lui aussi de la PMK (authentification mutuelle entre le point d'accès et le client),
• la KEK, utilisée pour distribuer la GTK,
• les TK, utilisées pour sécuriser le transfert de données.

       
Au final, nous avons bien :
          

• le client authentifié par le serveur RADIUS,
• le serveur authentifié par le client,
• le client authentifié par le point d'accès,
• le point d'accès authentifié par le client,
• les   données   sont   sécurisées.  Chaque   paquet   (et  même   chaque   fragment   de   paquet)   est authentifié,   si   bien   qu'il   n'est   normalement   pas   possible   d'injecter   frauduleusement   des paquets forgés.

               
Le point  d'accès et le serveur sont reliés par le réseau filaire.  A priori,  il  y a moins de dangers.  L'authentification mutuelle se fait par un « secret partagé », comme nous le verrons dans la mise en oeuvre.

Authentifications
               

 
Autorité de certification

Il   en   existe   de   très   officielles,   leurs   services   coûtent   généralement   une   fortune.  Nous   nous contenterons,  au sein de notre système,  de créer notre propre CA.  Pratiquement,   il faut créer un certificat de CA, qui permettra d'authentifier tous les autres certificats que nous devrons créer.

EAP-TLS

TLS (Transport Layer  Security),  n'est  autre que SSL v3 (Secure Socket  Layer).  Ici,  nous aurons besoin d'un certificat x509 sur le serveur et sur le client. L'authentification se fait au moyen des clés privées (un message chiffré par une clé privée authentifie son auteur).

Avec cette méthode,   il   faut  donc créer un certificat  pour   le serveur mais aussi  un certificat  par client.   Le   client   n'a   pas   besoin   de   disposer   d'un   « login/password »,   le   certificat   suffit   à l'authentifier.

EAP-TTLS

Ici, seul le certificat du serveur suffit. Il permettra de construire un « tunnel chiffré » dans lequel voyagera le mot de passe du client. Une interception du trafic ne permettra que de récupérer un mot de passe chiffré.

EAP-PEAP

Très similaire à TTLS, mais en plus le mot de passe ne circule pas dans le tunnel. Il s'agit ici d'un « challenge », réalisé au moyen du protocole MSCHAP v2 (d'origine Microsoft). PEAP est réputé encore plus sûr que TTLS.

Cette méthode peut être employée si l'on dispose d'un domaine Microsoft, avec ActiveDirectory, et que  l'on souhaite que  les utilisateurs s'authentifient  avec  leur « login/password » du domaine.   Il « suffira » dans ce cas de configurer  convenablement   le serveur  FreeRADIUS pour  qu'il  puisse consulter l'annuaire de ActiveDirectory, ce qui, en contrepartie, dispense de créer un certificat par client.

Il existe d'autres méthodes supportées par 802.1x, mais ce sont ces trois méthodes réputées les plus sécurisées.

Les certificats

Nous allons créer tous les certificats nécessaires à l'utilisation de EAP-TLS. Il nous faudra :

• un certificat qui représentera notre autorité de certification, dont la partie publique devra être disponible pour   le serveur  RADIUS et  pour   tous  les clients.  Ce certificat  doit  permettre d'authentifier tous les autres certificats que nous devrons créer,
• un certificat pour le serveur RADIUS. La partie publique de ce certificat sera envoyée par le serveur à tous les supplicants lorsqu'ils voudront s'attacher au point d'accès,
• un certificat par client, dont la partie publique sera envoyée au serveur RADIUS, en guise de code d'accès.

Pour réaliser tout ceci, nous faisons appel à OpenSSL. Mais la ligne de commande n'est pas bien ergonomique. Fort heureusement, il existe un outil qui va nous aider grandement : TinyCA.

TinyCA est une application (perl/GTK) qui permet de manipuler plus facilement OpenSSL. Nous pourrons réaliser et gérer avec les divers certificats qui nous seront nécessaires. Il n'est ni utile ni même souhaitable d'effectuer cette opération sur le serveur FreeRADIUS. Au contraire, il est même vivement  conseillé de réaliser   les opérations qui  suivent  sur  une machine  inaccessible depuis  le réseau.

Création d'une CA

C'est bien sûr la première opération à réaliser. D'ailleurs la fenêtre qui suit est la première que vous verrez au premier lancement de tinyca :
           

Puis vient la configuration. Pour les tests, nous garderons les valeurs par défaut :
               

 

Le temps que les clés se construisent, et nous obtenons :
        

                 

Configuration des préférences
             

Le menu « préférences » va nous permettre de donner quelques directives fondamentales pour ce que nous avons à faire.

Pour les certificats du serveur, nous devons ajouter l'extension 1.3.6.1.5.5.7.3.1, ce qui, en français, signifie que le certificat est destiné à un serveur d'authentification. De même, choisissez la durée de validité du certificat (ici, un an). A échéance, il faudra penser faire un nouveau certificat.
           

Pour les certificats des clients, nous devons ajouter l'extension 1.3.6.1.5.5.7.3.2, qui signifie que les certificats sont destinés à authentifier les clients. Pensez aussi à leur durée de validité.
            

         

Création du certificat du serveur
            

La   création   des   divers   certificats   (serveur   et   clients)   suit   la  même   procédure,   en   utilisant   le paramétrage par défaut effectué plus haut. Il suffit de compléter les champs vides :
         

    

En réalité, nous n'avons créé qu'une requête de certificat. Cette requête doit maintenant être validée par la CA, ce qui se traduit par l'apposition de la signature de la CA. Il s'agit du mot de passe choisi lors de la création de la CA :
  

Notez que lors de cette opération, il est possible de modifier la durée de validité. C'est important surtout  pour  les certificats clients.   Il  est  en effet  possible d'envisager  la création de certificats à durée   très   courte,   dans   le   cas   de   clients   de   passage,   par   exemple,   ou   pour   des   autorisations ponctuelles.
     

 

A l'issue de la signature,  assurez-vous que le compte-rendu est positif.  Nous devons retrouver le certificat inscrit dans la liste :
           

        

Création d'un certificat client

Procédure identique :
          

Je passe les détails de signature. Au final, nous avons :
            

Exportation des certificats

Il nous faut maintenant exporter les certificats à installer sur le serveur et sur le(s) client(s).Certificat de la racine de confiance (CA)

Ce certificat, qui représente la racine de confiance, devra être présent sur le serveur RADIUS et sur tous les clients. Nous devons donc l'exporter dans des formats compatibles avec OpenSSL (pem) et Windows (der).

Rappelons que c'est ce certificat qui permettra :
        

• au serveur de s'assurer que les certificats présentés par les clients sont bien authentiques,
• aux clients de s'assurer que le certificat présenté par le serveur est bien authentique.

                      

Vérifions que l'exportation est réussie :
         

Et recommençons l'opération, mais au format .der (je passe les détails).

Certificat du serveur

Ce certificat ne sera installé que sur le serveur FreeRADIUS, donc le format pem (avec la clé privée et l'empreinte intégrées) suffira :

Certificat client
                

Ce certificat  servira à « user1 ».  Suivant qu'il utilisera Windows ou GNU/Linux,  il lui faudra un .pem ou un .pkcs#12 (clé privée intégrée). C'est un utilisateur bicéphale, son portable est en « dual-boot ».

L'exportation au format .pem se fait de la même manière que pour le serveur, passons les détails. En revanche, pour le format pkcs#12, c'est un petit peu plus compliqué :
       

Deux mots de passe sont demandés :
      

• le premier (Key password) correspond à celui qui a été saisi lors de la création du certificat,
• le second (Export Password) sera nécessaire lors de l'installation du certificat chez le client.

               

           
Au final, nous avons dans notre répertoire d'exportation :

           

• root_maison_CA-cacert.der
• root_maison_CA-cacert.pem (les certificats de l'autorité)
• sysop@maison.mrs-cert.pem (le certificat du serveur)
• user1@maison.mrs-cert.pem
• user1@maison.mrs-cert.p12 (le certificat du client, dans les deux formats nécessaires).

        
Et la révocation

Il peut se faire, pour de multiples raisons, que l'on doive rendre inopérant un certificat avant sa date d'expiration :
                

• la clé privée est compromise,
• le possesseur du certificat n'en a plus besoin plus tôt que prévu,
• le possesseur du certificat a enfreint les règles et doit se voir banni du réseau,
• et tant d'autres raisons.

                
Il  faut  donc disposer d'un moyen pour que  le serveur RADIUS puisse rejeter des certificats non expirés, mais désormais interdits d'accès.

Dans   un   tel   cas,   il   faut   alors   pouvoir   créer   un   certificat   de   révocations   qu'il   sera   nécessaire d'installer sur le serveur, et le configurer pour qu'il le consulte à chaque authentification. Tinyca sait réaliser de tels certificats. Ici, nous avons révoqué le certificat de « user2 » :
                

Il nous faut maintenant exporter un certificat des révocations :
        

Attention à la durée de validité d'un tel certificat. Bien entendu, ce certificat ne doit jamais expirer.

Nous retrouvons dans le répertoire d'exportation le certificat :

root_maison_CA-crl.pem
                  

--------------------------------------------------------------------------------------------

< Précédent : Réseaux sans fils sécurisés
          
                 Suivant > RADIUS