FR2901438A1 - Un procede d'embarquement d'un protocole securise dans des cartes a puces, des capteurs et des objets intelligents - Google Patents

Abstract

Un procédé d'embarquement d'un protocole sécurisé dans des cartes à puce, des capteurs et des objets intelligents.L'invention concerne un procédé d'établissement des sessions sécurisées entre un serveur et un usager de réseaux équipé d'une carte à puce, d'un capteur ou d'un objet intelligent. Les sessions sécurisées sont établies en utilisant le protocole TLS ou une des ses versions (SSL, DTLS, EAP-TLS, ...) avec une authentification basée sur l'usage des clés partagées.Elle décrit également les moyens de mise en oeuvre d'un tel procédé dans des modules de sécurité, par exemple des cartes à puces ou des capteurs.

Description

-2- Plusieurs technologies sont disponibles pour établir des 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,

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

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

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.

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.

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

Claims (3)

Revendications

1) Procédé d'établissement d'une liaison sécurisée par le protocole TLS ou par une de ses versions, notamment DTLS, SSL, EAP-TLS, caractérisé en ce que: - l'authentification est réalisée par une clé partagée et ; - le client est en soi ou intègre un objet intelligent, un capteur ou une carte à puce ou un de ses types, notamment SIM, USIM, UIM, RUIM, PIM, UICC.

2) Dispositif client pour la mise en oeuvre du procédé selon la revendication 1, muni d'au moins une interface de communication et en ce qu'il implémente le protocole TLS ou une des ses versions, notamment DTLS, SSL, EAP-TLS.

3) Dispositif serveur pour la mise en oeuvre du procédé selon la revendication 1, caractérisé en ce qu'il peut être ou pas ou bien intègre ou pas un capteur, un objet intelligent ou une carte à puce ou un de ses types, notamment SIM, USIM, UIM, RUIM, PIM, UICC, muni d'au moins une interface de communication et en ce qu'il implémente le protocole TLS ou une des ses versions, notamment DTLS, SSL, EAP-TLS, et/ou le protocole EAP et/ou les services du protocole RADIUS ou du protocole AAA.