-2- Plusieurs technologies sont disponibles pour établir des sessions-2- Several technologies are available to establish sessions
sécurisées entre un client et un serveur. Nous citons ici le protocole SSL (Secure Sockets Layer), TLS (Transport Layer Security) et le protocole IPSec (Internet Protocol Security). Basé sur SSL qui est développé par Netscape, le protocole TLS, défini par le RFC 2246 est le principal protocole de sécurité au niveau Transport (couche OSI numéro 4 (Open Systems Interconnection)). Diverses applications telles que le commerce électronique sur Internet, les navigateurs WEB et les transactions bancaires supportent la sécurisation des transactions en utilisant le protocole TLS. TLS fournit un canal transparent. C'est-à- dire qu'il est simple de sécuriser le 10 protocole d'application en insérant TLS entre la couche Application (couche OSI numéro 7) et celle du Réseau (couche OSI numéro 3). Cependant, TLS nécessite un protocole fiable de transport comme TCP (Tranport Control Protocol). TLS est adapté à la sécurisation de différents types de trafic et d'échange. Parmi ces types, nous citons le transfert de fichiers, la transmission des emails, l'accès à 15 distance, l'accès aux répertoires et l'accès aux objets. Cependant, une version TLS adaptée aux protocoles de transport non fiables comme IJDP (User Datagram Protocol) est disponible. Cette version est appelée DTLS (Datagram TLS) et elle est décrite par le RFC 4347. Un autre contexte d'usage du protocole TLS est le contexte des réseaux sans fil 20 et mobiles, tels que WiFi, la famille de 802 et le WiMax. Par exemple, la série de 802 définit le protocole EAP (Extensible Authentication Protocol) comme un protocole d'authentification générique qui supporte plusieurs mécanismes d'authentification. L'extensibilité du EAP permet d'encapsuler tout mécanisme d'authentification à l'intérieur du message EAP. L'intégration de TLS avec EAP, définie par le RFC 2716, 25 est devenue une solution pour l'authentification et la distribution des clés dans les réseaux qui utilisent EAP dans leurs piles protocolaires. EAP-TLS est utilisé plus particulièrement pour l'authentification et le contrôle de l'accès au niveau Liaison ou MAC (couche OSI numéro 2). Les points forts de TLS lui permettent de s'intégrer facilement dans d'autres 30 environnements de communication ; notamment les réseaux de communications mobiles 3GPP (Third (aeneration Partnership Project) et 802.11 sans fil. TLS fournit un cadre extensible pour l'intégration de nouveaux services et des nouvelles méthodes de chiffrement et d'authentification en utilisant le RFC 3546. TLS définit des mécanismes d'authentification basés sur l'échange de certificats. 35 Durant la phase de la négociation TLS, le serveur envoie son certificat au terminal qui doit vérifier à son tour si ce certificat est valide et non révoqué. La consultation de la liste de révocation nécessite une connexion Internet. L'usage de ces certificats nécessite des infrastructures à clés publiques qui servent à établir une chaîne de certification ou de confiance entre les entités communicantes. Les fonctions requises par les PKI (Public Key Infrastructure) ou les infrastructures à clé publique (opérations cryptographiques, gestion de certificats, charge de données, ...) rendent extrêmement coûteux leur usage pour les réseaux mobiles, alors qu'il est déjà complexe pour les réseaux fixes. Afin de remédier à ce problème, nous définissons un mécanisme basé sur l'utilisation d'une clé partagée (PSK, Pre Shared Key) et de TLS, tel qu'il est décrit par le RFC 4279. Ce mécanisme ne nécessite pas l'utilisation des certificats et des PKI pour l'authentification ; il est mieux adapté pour certains réseaux sans fil et à petite échelle où les clients sont pré configurés ou personnalisés. La figure 2 illustre la phase de la négociation (Handshake) du TLS entre un client 15 (121) et un serveur (131). On divise cette phase en trois étapes. Dans une première étape (201, 202, 203, 204, 205, 206), le client et le serveur négocient les paramètres de sécurité (comme les valeurs aléatoires, l'algorithme d'échange de clés, l'algorithme de chiffrement, la fonction de hachage, secure between a client and a server. Here we mention SSL (Secure Sockets Layer), Transport Layer Security (TLS), and Internet Protocol Security (IPSec). Based on SSL which is developed by Netscape, the TLS protocol defined by RFC 2246 is the main security protocol at the Transport level (OSI layer 4 (Open Systems Interconnection)). Various applications such as e-commerce on the Internet, web browsers and banking transactions support secure transactions using the TLS protocol. TLS provides a transparent channel. That is, it is simple to secure the application protocol by inserting TLS between the Application layer (OSI layer number 7) and the Network layer (OSI layer number 3). However, TLS requires a reliable transport protocol such as TCP (Tranport Control Protocol). TLS is suitable for securing different types of traffic and exchange. These types include file transfer, email forwarding, remote access, directory access and object access. However, a TLS version adapted to unreliable transport protocols such as IJDP (User Datagram Protocol) is available. This version is called DTLS (Datagram TLS) and is described by RFC 4347. Another context of TLS is the context of wireless and mobile networks, such as WiFi, the 802 family, and WiMax. For example, the 802 series defines the Extensible Authentication Protocol (EAP) as a generic authentication protocol that supports multiple authentication mechanisms. The extensibility of the EAP makes it possible to encapsulate any authentication mechanism inside the EAP message. The integration of TLS with EAP, defined by RFC 2716, 25 has become a solution for authentication and key distribution in networks that use EAP in their protocol stacks. EAP-TLS is used more specifically for authentication and access control at the Link or MAC level (OSI layer 2). The strengths of TLS allow it to integrate easily into other communication environments; 3GPP (Thirdeneration Partnership Project) and 802.11 wireless communications networks provide an extensible framework for the integration of new services and new encryption and authentication methods using RFC 3546. TLS defines Authentication mechanisms based on certificate exchange During the TLS negotiation phase, the server sends its certificate to the terminal, which in turn must check whether the certificate is valid and not revoked. requires an Internet connection The use of these certificates requires public-key infrastructures that are used to establish a chain of certification or trust between communicating entities The functions required by Public Key Infrastructure (PKI) or Public Key Infrastructure (cryptographic operations, certificate management, data loading, ...) make it extremely expensive It is used for mobile networks, whereas it is already complex for fixed networks. To remedy this problem, we define a mechanism based on the use of a shared key (PSK, Pre Shared Key) and TLS, as described by RFC 4279. This mechanism does not require the use of certificates and PKI for authentication; it is better suited for certain wireless and small-scale networks where customers are pre-configured or customized. Figure 2 illustrates the phase of TLS handshake between a client (121) and a server (131). This phase is divided into three stages. In a first step (201, 202, 203, 204, 205, 206), the client and the server negotiate the security parameters (such as the random values, the key exchange algorithm, the encryption algorithm, the hash function,
.) afin d'établir une session sécurisée. Le paramètre "cipher spec" est utilisé pour négocier 20 l'algorithme d'échange de clés, l'algorithme de chiffrement et la fonction de hachage. La deuxième étape (207, 208, 209) consiste à authentifier le client auprès du serveur et à générer les clés cryptographiques de la session en utilisant la fonction PRF (Pseudo Random Function). Ces clés seront utilisées dans les opérations cryptographiques afin de protéger les données durant leurs transfert. Les opérations 25 cryptographiques utilisent les algorithmes cryptographiques négociés durant la première étape. Durant la troisième étape (210, 211, 212, 213), le client et le serveur vérifient l'intégrité de leurs échanges en calculant le condensât de tous les messages transmis et reçus et en chiffrant le résultat avec la clé de chiffrement calculée durant la deuxième 30 étape. Durant cette troisième phase, le serveur sera implicitement authentifié auprès du client. En effet, le client génère durant la deuxième phase une valeur aléatoire de 46 octets appelée "premaster secret' (208) et il la concatène avec la version négociée de TLS. Ensuite il chiffre le résultat avec la clé publique du serveur envoyée dans le message "Certificate" (203). La valeur chiffrée est envoyée au serveur qui la déchiffre 35 en utilisant sa clé privée pour obtenir le "premaster secret'. Ce secret est utilisé à la fois 2901438 -4-par le client et le serveur pour générer le même secret "master secret". Le "master secret' est utilisé dans la génération des clés symétriques utilisées dans le chiffrement et dans le calcul du MAC (Message Authentication Code). Les premiers messages chiffrés et signés avec les clés générées sont les messages "Finished' (211, 5 213). Par conséquent, il est impossible pour une entité n'ayant pas la clé privée correspondante à la clé publique envoyée par le serveur durant la deuxième étape, de découvrir le "premaster secret' en clair et de générer les mêmes clés. Les figures 3 et 4 illustrent deux méthodes pour achever la phase de la négociation (Handshake) du TLS avec une clé partagée. 10 Selon l'invention, les messages sont échangés en conformité avec le protocole TLS, tel que décrit par les RFC 2246, 3546 et 4279. Dans une première phase, le client ou le "senso?' indique au serveur qu'il souhaite établir une session TLS-PSK (session TLS en utilisant une clé partagée. Le client achève cette phase, soit en envoyant une liste des options cryptographiques supportées par le client (301) et basées sur l'usage des clés partagées, soit par l'usage d'une extension (401). Dans le premier cas (figure 3), le client utilise le paramètre "cipher spec" (301) pour envoyer sa liste de "cipher suite" spécifiée pour l'utilisation de la clé partagée avec TLS. Par exemple, TLS_DHE_PSK_WITH_RC4_128_SHA indique que le client supporte une méthode d'échange de clés basée sur le Diffie-Hellman en introduisant la clé partagée avec l'usage de la fonction de hachage SHA1 et du chiffrement symétrique RC4. Dans ce cas, le client informe implicitement le serveur qu'il supporte l'authentification à clé partagée et qu'il peut échanger les clés en utilisant l'algorithme de Diffie-Hellman. Ce mécanisme est décrit dans le RFC 4279. Le client génère le "premaster secret' (46 octets) et le concatène avec la version du TLS et chiffre le résultat la clé publique envoyée par le serveur dans le message "ServerKeyExchange" (303). Ensuite, le client envoi le résultat au serveur en utilisant le message "ClientKeyExchange" (305). Le "premaster secret' sera ensuite utilisé en conjoint avec le secret partagé pour calculer les clés de session et pour établir l'authentification mutuelle. Ensuite le client et le serveur vérifient l'intégrité de leurs échanges en calculant le condensât de tous les messages transmis et reçus et en chiffrant le résultat avec la clé de chiffrement calculée (306, 307, 308, 309). Dans le deuxième cas (figure 4), le client ajoute à son message "ClientHello" une extension (401) qui est définie en se basant sur RFC 3546. Lorsque cette extension est envoyée, elle peut transporter une ou plusieurs méthodes d'échange de clés en mode clé partagée, supportées par le client. Le contenu de l'extension transportera 2901438 -5-l'identificateur de la clé partagée. Si le serveur accepte I"utilisation de cette extension, il répond par le même type d'extension (402). Ensuite, le client et le serveur dérivent les clés de session en appliquant la fonction PRF (Pseudo Random Function) sur la clé partagée et les valeurs aléatoires "ClientHello.randorn" et "ServerHello.random" et 5 activent l'utilisation des paramètres négociés (403, 405). Enfin, ils s'authentifient via les messages "Finished' (404, 406). Notons que dans la figure 3 (deuxième cas), le client et le serveur impliquent l'usage du "premaster secret' dans le processus de la génération des clés de session. Comme il est décrit dans TLS, ces messages représentent une preuve que le client et le serveur ont dérivé les mêmes clés (de 10 chiffrement, de MAC, .) to establish a secure session. The "cipher spec" parameter is used to negotiate the key exchange algorithm, the encryption algorithm and the hash function. The second step (207, 208, 209) consists of authenticating the client to the server and generating the cryptographic keys of the session by using the PRF function (Pseudo Random Function). These keys will be used in cryptographic operations to protect the data during their transfer. The cryptographic operations use the cryptographic algorithms negotiated during the first step. During the third step (210, 211, 212, 213), the client and the server verify the integrity of their exchanges by calculating the condensate of all transmitted and received messages and encrypting the result with the encryption key calculated during the second step. During this third phase, the server will be implicitly authenticated to the client. In fact, the client generates during the second phase a random value of 46 bytes called "premaster secret" (208) and concatenates it with the negotiated version of TLS, then it encrypts the result with the public key of the server sent in the message "Certificate" (203) The encrypted value is sent to the decrypting server 35 using its private key to obtain the "secret premaster". This secret is used both by the client and the server to generate the same secret master secret. The "master secret" is used in the generation of the symmetric keys used in the encryption and in the calculation of the MAC (Message Authentication Code) The first messages encrypted and signed with the generated keys are the "Finished" messages (211, 213 ). Therefore, it is impossible for an entity that does not have the private key corresponding to the public key sent by the server during the second step, to discover the "secret premaster" and to generate the same keys. 4 illustrate two methods for completing the TLS handshake phase with a shared key, according to the invention the messages are exchanged in accordance with the TLS protocol as described by RFC 2246, 3546 and 4279. In a first phase, the customer or the "senso?" tells the server that it wants to establish a TLS-PSK session (TLS session using a shared key) The client completes this phase, either by sending a list of cryptographic options supported by the client (301) and based on the use of shared keys, either by the use of an extension (401) In the first case (Figure 3), the client uses the parameter "cipher spec" (301) to send its list of "cipher suite" specified for the use of the shared key with TLS For example, TLS_DHE_PSK_WITH_RC4_128_SHA indicates that the client supports a Diffie-Hellman based key exchange method by introducing the shared key with the use of SHA1 hash function and symmetric RC4 encryption In this case, the client implicitly informs the server that it supports shared key authentication and that it can exchange keys using the Diffie-Hellman algorithm.This mechanism is described in RFC 4279. The client generates the "secret premaster" (46 bytes) and concatenates with the TLS version and encrypts the result the public key sent by the server in the "ServerKeyExchange" message (303). Then, the client sends the result to the server using the "ClientKeyExchange" message (305). The "secret premaster" will then be used in conjunction with the shared secret to calculate the session keys and to establish the mutual authentication Then the client and the server check the integrity of their exchanges by calculating the condensate of all the transmitted messages and received and encrypting the result with the calculated encryption key (306, 307, 308, 309) In the second case (Figure 4), the client adds to its message "ClientHello" an extension (401) which is defined in based on RFC 3546. When this extension is sent, it can carry one or more shared key mode key exchange methods supported by the client .The contents of the extension will carry 2901438 -5-the identifier of the If the server accepts the use of this extension, it responds with the same extension type (402). Then, the client and the server derive the session keys by applying the PRF function (Pseudo Random Function) on the shared key and the random values "ClientHello.randorn" and "ServerHello.random" and 5 activate the use of negotiated parameters (403, 405). Finally, they authenticate via the "Finished" messages (404, 406) Note that in Figure 3 (second case), the client and the server imply the use of the "premaster secret" in the process of generating the session keys. As described in TLS, these messages represent evidence that the client and the server have derived the same keys (encryption, MAC,
.). Dans notre approche, les messages "Finished' représentent un service additionnel : les deux entités ont pris connaissance de la clé partagée. Autrement dit, personne ne peut calculer un "Finished' valide sans avoir la vraie clé partagée. D'où l'authentification mutuelle par le "Finished'. 15 Nous allons à présent décrire un moyen de mise en oeuvre du procédé d'authentification avec l'usage des clés partagées, à l'aide de module de sécurité, illustré dans la figure 5. Nous désignons sous le terme module de sécurité un circuit intégré de silicium (501a), qualifié usuellement d'un objet intelligent, d'un capteur ou d'un "Tamper Resistant Device". Ces derniers sont des composants qui résistent aux attaques et disponible sous différents formats tels que des cartes de PVC, cartes à puce (carte SIM, carte USIM, carte RUIM, carte UIM, ...) intégrés dans des jetons USB, dans des mémoires MMC (MultiMedia Caro, ou dans d'autres types de terminaux...DTD: Un module de sécurité incorpore tous les moyens sécurisés de stockage de données et permet également l'exécution de logiciels dans un environnement sûre et protégé. Plus précisément, il comporte une unité centrale (CPU, 501), une mémoire ROM stockant le code du système d'exploitation (502), de la mémoire RAM (503) et une mémoire non volatile (NVR, 504) utilisée comme dispositif de stockage analogue à un disque dur et qui contient par exemple un logiciel embarqué TLS, EAP-TLS, TLS avec une authentification basée sur une clé partagée ou EAP-TLS avec une authentification basée sur une clé partagée. Un bus système (500) relie les différents organes du module sécurisé. L'interface avec le monde extérieur (501 b) est assuré par un port IO d'entrée/sortie (505), conforme à des standards tels que ISO7816, USB, ISO7816-12, MMC, IEEE 802.3, IEEE 802.11, ... Nous nous référons à présent aux figures 6 et 7. Nous considérons un module de sécurité ((611) ou (612) ou (613)) qui comporte un logiciel EAP-TLS-PSK (615) et un logiciel TLS-PSK (616) avec une authentification basée sur une clé partagée (617). Ce module réalise le protocole TLS avec une clé partagée, il reçoit à travers un port IO (figure 5, 505) des messages EAP-TLS-PSK envoyés par le NAS (Network Access Server) (session EAP-TLS en utilisant une clé partagée pour l'authentification et produit les réponses appropriées. En outre le module stocke la clé partagée (617). L'identité du module ainsi que ses clés partagées sont également stockées de manière sécurisée. A la fin de la session EAP-TLS-PSK ((620, 621, 622, 623, 624, 625, 626, 627) ou (720, 721, 722, 723, 724, 725, 726, 727, 728, 729)), une clé MSK (Master Session Key) (619) est disponible pour l'entité utilisatrice du module, typiquement un système d'exploitation. La clé MSK est dérivée, entre autres, du "premaster secret" (figure 6, 618) ou de la clé partagée (figure 7, 718). La clé MSK 2901438 -7- est utilisée pour assurer la sécurité des communications d'un couple point d'accès et client d'un réseau sans fil. Il résulte de l'exécution, par un module de sécurité ((611) ou (612) ou (613)) d'un logiciel EAP-TLS-PSK (615) ou TLS-PSK (616), muni selon l'invention d'un mécanisme 5 d'authentification basé sur clés partagées, les avantages suivants : - Avec EAP-TLS, l'usage de certificats est obligatoire. Le client EAP-TLS ne peut pas avoir une connexion réseau qu'après son authentification avec succès. Durant la phase de l'authentification EAP-TLS, la consultation de la liste de révocation nécessite une connexion Internet. Comme le client n'aura pas cette connexion avant la fin avec 10 succès de la phase d'authentification, il doit supposer que le certificat du serveur est non révoqué et il peut vérifier son hypothèse dès que la connexion est fournie. Avec EAP-TLS-PSK, le client peut authentifier le serveur sans avoir une connexion réseau et cela durant la phase de l'authentification. - Les spécifications actuelles de TLS et de EAP-TLS permettent l'authentification 15 mutuelle entre les entités via l'utilisation des certificats. L'usage de ces certificats nécessite des infrastructures à clés publiques qui servent à établir une chaîne de certification ou de confiance entre les entités communicantes. Les fonctions requises par les PKI (opérations cryptographiques, gestion de certificats, charge de données, ...) rendent extrêmement coûteux leur usage pour les réseaux mobiles, alors qu'il est déjà 20 complexe pour les réseaux fixes. EAP-TLS-PSK est capable de réduire la charge protocolaire, la charge cryptographique et la charge de gestion tout en assurant le niveau de sécurité fourni par les actuelles spécifications de TLS et EAP-TLS. Par nature, les messages TLS échangés entre un serveur et un client peuvent être lus et analysés par tout observateur du réseau. Pour cela et dans le cas de EAP- 25 TLS-PSK, le serveur peut envoyer au client un nouvel identificateur de manière sécurisée après la phase de l'authentification. Cela empêche un observateur de capturer les données et de faire la corrélation entre l'identité de la clé et la personne communiquant. 30 -8-On considère une infrastructure réseau et plusieurs clients équipés chacun d'un module de sécurité EAP-TLS-PSK ou TLS-PSK. Ces clients sont administrés par un ou plusieurs serveurs RADIUS (Remote Authentication Cria/ ln User Service) ou AAA (Authentication, Authorization, and Accounting) en fonction des contraintes du réseau. .). In our approach, the "Finished" messages represent an additional service: the two entities have read the shared key, which means that no one can calculate a valid "Finished" without having the real shared key. Hence the mutual authentication by the "Finished." We will now describe a means of implementing the authentication method with the use of the shared keys, using a security module, illustrated in FIG. Figure 5. The term security module refers to a silicon integrated circuit (501a), usually referred to as a smart object, a sensor or a Tamper Resistant Device, which are components that are resistant to attacks and available in different formats such as PVC cards, smart cards (SIM card, USIM card, RUIM card, UIM card, ...) embedded in USB tokens, in memory MMC (MultiMedia Caro, or in other types of terminals ... DTD: A security module incorporates all secure means of data storage and also allows the execution of software in a secure and protected environment, more specifically, it comprises a central unit (CPU, 501). ), a ROM memory tockant the operating system code (502), the RAM memory (503) and a non-volatile memory (NVR, 504) used as a storage device analogous to a hard disk and which contains, for example, embedded software TLS, EAP -TLS, TLS with shared key-based authentication or EAP-TLS with shared key-based authentication. A system bus (500) connects the different members of the secure module. The interface with the outside world (501b) is provided by an IO input / output port (505), compliant with standards such as ISO7816, USB, ISO7816-12, MMC, IEEE 802.3, IEEE 802.11, .. We now refer to FIGS. 6 and 7. We consider a security module ((611) or (612) or (613)) which comprises EAP-TLS-PSK software (615) and TLS-PSK software ( 616) with authentication based on a shared key (617). This module realizes the TLS protocol with a shared key, it receives through an IO port (FIG. 5, 505) EAP-TLS-PSK messages sent by the NAS (Network Access Server) (EAP-TLS session using a shared key The module stores the shared key (617) and the identity of the module and its shared keys are also stored securely at the end of the EAP-TLS-PSK session. ((620, 621, 622, 623, 624, 625, 626, 627) or (720, 721, 722, 723, 724, 725, 726, 727, 728, 729)), a key MSK (Master Session Key) (619) is available for the user entity of the module, typically an operating system.The key MSK is derived from, among others, the "secret premaster" (FIG.6, 618) or the shared key (FIG. The MSK key 2901438 -7- is used to ensure the security of the communications of an access point and client pair of a wireless network. by a security module ((611) or (612) or (613)) of a software EAP-TLS-PSK (615) or TLS-PSK (616), equipped according to the invention with a mechanism 5 authentication based on shared keys, the following advantages: - With EAP-TLS, the use of certificates is mandatory. The EAP-TLS client can not have a network connection until successfully authenticated. During the EAP-TLS authentication phase, viewing the revocation list requires an Internet connection. Since the client will not have this connection until the successful completion of the authentication phase, he must assume that the server's certificate is unrevoked and he can verify his hypothesis as soon as the connection is provided. With EAP-TLS-PSK, the client can authenticate the server without having a network connection during the authentication phase. Current TLS and EAP-TLS specifications allow mutual authentication between entities through the use of certificates. The use of these certificates requires public key infrastructures that serve to establish a chain of certification or trust between the communicating entities. The functions required by PKIs (cryptographic operations, certificate management, data loading, etc.) make their use for mobile networks extremely expensive, whereas it is already complex for fixed networks. EAP-TLS-PSK is capable of reducing protocol load, cryptographic load, and management overhead while maintaining the level of security provided by the current TLS and EAP-TLS specifications. By nature, TLS messages exchanged between a server and a client can be read and analyzed by any observer in the network. For this and in the case of EAP-TLS-PSK, the server can send the client a new identifier securely after the authentication phase. This prevents an observer from capturing the data and correlating the identity of the key with the communicating person. 30 -8-Consider a network infrastructure and several clients each equipped with an EAP-TLS-PSK or TLS-PSK security module. These clients are managed by one or more RADIUS (Remote Authentication Cria / User Service) or AAA (Authentication, Authorization, and Accounting) servers based on network constraints.
Nous considérons à présent la figure 1. Des modules de sécurité ((111), (112)), qualifiés par un objet intelligent (101) ou une carte à puce (102) ou de capteurs ((103), (104)) et sont contrôlés par des NAS ou par des points d'accès (106). Ces modules comportent des logiciels EAP-TLS-PSK ou des logiciels TLS-PSK. Ces modules sont attachés à un terminal (105) muni d'au moins une interface de communication ou ils communiquent directement avec les NAS et les points d'accès en utilisant une interface radio ou sans fil. Les cartes à puce, les objets intelligents et les capteurs sont associés à un ou plusieurs serveurs d'authentification RADIUS ou AAA (108) munis d'au moins une interface de communication et implémentant un logiciel EAP-TLS-PSK ou un logiciel TLS-PSK. We now consider Figure 1. Security modules ((111), (112)), qualified by an intelligent object (101) or a smart card (102) or sensors ((103), (104)) and are controlled by NASs or access points (106). These modules include EAP-TLS-PSK software or TLS-PSK software. These modules are attached to a terminal (105) provided with at least one communication interface or they communicate directly with the NASs and the access points using a radio or wireless interface. Smart cards, smart objects and sensors are associated with one or more RADIUS or AAA authentication servers (108) provided with at least one communication interface and implementing EAP-TLS-PSK software or TLS software. PSK.
Nombreux logiciels libres tels que OPENRADIUS ou FREERADIUS offrent de services d'authentification RADIUS. La figure 8 détaille les informations échangées entre un point d'accès (801) et un serveur d'authentification RADIUS (802) implémentant EAP-TLS-PSK et TLS-PSK. Le serveur comporte, conformément aux descriptions précédentes, les clés partagées. Numerous free software such as OPENRADIUS or FREERADIUS offer RADIUS authentication services. Figure 8 details the information exchanged between an access point (801) and a RADIUS authentication server (802) implementing EAP-TLS-PSK and TLS-PSK. The server comprises, in accordance with the preceding descriptions, the shared keys.
Nous désignons sous le terme session RADIUS (801a) une suite de paquets (803, 804, 805, 806, 807, 808) échangés entre le point d'accès et le serveur d'authentification RADIUS. Ces paquets véhiculent des informations échangées entre un client EAP et un serveur EAP. Côté serveur RADIUS, une session commence par la réception d'un "EAP- Identity.response" inclus dans un paquet "Access-Requesf' (803), et se termine par la génération d'une notification typiquement un "EAP-Succ9ss" dans un paquet "Access-Accepf' (808). A la fin de la session, une clé MSK est disponible sur le serveur. Cette clé est dérivée de la même manière décrite auparavant.30 We designate under the term RADIUS session (801a) a sequence of packets (803, 804, 805, 806, 807, 808) exchanged between the access point and the RADIUS authentication server. These packets convey information exchanged between an EAP client and an EAP server. On the RADIUS server side, a session begins with the receipt of an "EAP-Identity.response" included in an "Access-Requesf" (803) package, and ends with the generation of a typical "EAP-Succ9ss" notification. in an "Access-Accepf" package (808). At the end of the session, an MSK key is available on the server. This key is derived in the same way previously described.30