FR2923110A1 - Authentification securisee perfectionnee d'un client mobile. - Google Patents

Abstract

Pour permettre une authentification du client dans une communication sécurisée avec un serveur, l'invention met en place un challenge réalisé par des moyens sécurisés de type carte SIM du côté du client et selon un message de challenge émis par le serveur lors d'une négociation de session SSL/TLS. Les messages correspondant à la gestion de ce challenge sont transmis en utilisant des mécanismes internes du protocole SSL/TLS ce qui diminue l'impact de l'invention sur l'infrastructure du réseau.

Description

Authentification sécurisée perfectionnée d'un client mobile

L'invention a pour objet un procédé d'authentification d'un client via les protocoles TLS et WTLS. Le domaine de l'invention est celui de l'Authentification. Plus particulièrement le domaine de l'invention est celui de l'authentification sécurisée d'un Client par un serveur. Par sécurisé on entend ici l'obtention de deux garanties : -l'authentification des clients et serveur, extrémités du canal par lequel transitent les données échangées entre le client et le serveur ; - la sécurisation des données elle-même contre l'altération et l'interception. Par serveur on entend une application mise en oeuvre par un dispositif connecté à un réseau télématique. Le dispositif mettant en oeuvre le serveur est de type ordinateur qu'il soit de type domestique, professionnel ou durci en vue de l'obtention d'une qualité de service élevée. Les caractéristiques intéressantes d'un tel dispositif relativement à la description de l'invention sont que ledit dispositif comporte un microprocesseur, une mémoire de programme et des circuits de connexion au réseau télématique. La mémoire de programme comporte alors des codes instructions correspondant au serveur. Ces codes instructions sont exécutés par le microprocesseur qui est apte à commander au moins les circuits de connexion au réseau télématique. Le serveur est donc apte à traiter des requêtes lui parvenant sous forme de messages formatés selon un protocole via le réseau télématique. Le serveur est donc aussi apte à produire des messages de réponses à des requêtes reçues via le réseau télématique. Des exemples classiques de serveur sont des serveurs : - Web , c'est-à-dire des serveurs fonctionnant selon le protocole HTTP (hypertext transfer protocol, pour protocole de transfert hypertexte), - de messagerie, c'est-à-dire des serveurs fonctionnant selon des protocoles de type POP, SMTP, IMAP... - de streaming , c'est-à-dire de diffusion vidéo permettant la diffusion de programmes multimédia animés en temps réel à travers un réseau télématique, - applicatif, c'est-à-dire par exemple un serveur web dit dynamique 35 capable d'effectuer des traitements avancés en réponse aux requêtes reçues, cette liste n'étant bien entendu pas exhaustive. Par client on entend une application mise en oeuvre par un dispositif connecté à un réseau télématique. Le dispositif mettant en oeuvre le client est du type téléphone ordinateur personnel, téléphone mobile, assistant personnel et plus généralement tout dispositif capable de se connecter à un réseau télématique. Un tel dispositif comporte un microprocesseur et une mémoire de programme comportant des codes instructions correspondant à la mise en oeuvre de l'application client . Les clients les plus connus sont les navigateurs Internet et les clients de messageries permettant respectivement de se connecter à des serveurs web et à des serveurs de messagerie. D'une manière plus générale on appelle Client toute application capable de communiquer avec un serveur. Dans la pratique le client et le serveur sont confondus avec les dispositifs qui mettent en oeuvre ces applications. Ainsi dans ce document lorsque l'on parle d'une action réalisée par le client ou le serveur, celle-ci est en fait réalisée par un microprocesseur d'un dispositif comportant une mémoire de programme dans laquelle sont enregistrés des codes instructions correspondant au client ou au serveur.

L'exécution de ces codes instructions correspond à la mise en oeuvre du client ou du serveur. Dans l'état de la technique les dialogues entre un client et un serveur sont bien connus. Le plus commun de ces dialogues est celui qui s'établit entre un navigateur Internet, ou tout simplement navigateur, et un serveur web . On remarque ici que le réseau télématique envisagé est le réseau Internet. Dans la pratique le domaine de l'invention s'étend à tout type de réseau d'échange de données qu'il soit ouvert, comme Internet, ou fermé comme un réseau local domestique, un réseau local d'entreprise ou un réseau d'un opérateur de téléphonie fixe/mobile .

Ces dialogues permettent le déploiement de services. Il s'agit d'un prestataire qui offre un service via un serveur. Parmi ces services on connaît : - les boutiques en ligne, - les portails thématiques, par exemple une encyclopédie générale et collaborative, un site spécialisé dans un domaine d'activité,... - les interfaces de consultation et de gestion de données administratives, parmi ces interfaces on retrouve les sites de souscription à un service. cette liste n'étant pas non plus exhaustive.

Pour rendre ces services attractifs on cherche à rassurer les utilisateurs potentiels sur leur efficacité et leur innocuité. En effet avec le développement des réseaux ouverts de type Internet de nouveaux types d'escroqueries sont apparus. L'une des plus nuisibles est actuellement connue sous le nom de Phishing . Elle consiste pour l'escroc à imiter un vrai site réputé et à attirer les utilisateurs sur ce site. Les utilisateurs du vrai site croient alors être sur le site habituel alors qu'en fait ils sont en communication avec une copie malveillante du vrai site. Toutes les informations que les utilisateurs saisissent alors sont accessibles à l'escroc. Des escroqueries moins communes consistent à intercepter les flux de données pour en lire le contenu. Dans ce cas, il n'est même plus la peine de se donner la peine d'imiter un site pour induire l'utilisateur en erreur. Un autre problème qui est apparu est relatif à la confiance que peuvent accorder les prestataires à leur client ou plus exactement aux utilisateurs de leurs services en ligne qui essaient de devenir leur client mais avec des intentions malveillantes ou en usurpant une identité. La personne dont l'identité a été usurpée porte alors plainte et obtient gain de cause dans la plupart des cas, ce qui constitue un dommage pour le prestataire qui doit indemniser la personne bien que le prestataire soit de bonne foi. Dans l'état de la technique, pour résoudre ces problèmes de sécurité les prestataires de service déploient leur serveur en utilisant des protocoles sécurisés permettant l'authentification des serveurs et clients, ainsi que le chiffrement des données échangées. Les protocoles utilisés sont alors SSL ou TLS. Ces protocoles sont décrits par de nombreuses sources, notamment et par exemple l'encyclopédie en ligne Wikipédia. On rappelle ici les bases de ces protocoles. Le protocole TLS (Transport Layer Security, Couche de transport sécurisée), anciennement nommé SSL (Secure Socket Layer, couche de connexion sécurisée), est un protocole de sécurisation des échanges sur Internet, développé à l'origine par Netscape (SSL version 2 et SSL version 3). Il a été renommé en Transport Layer Security (TLS) par l'IETF en 2001.

Le groupe de travail correspondant à l'IETF a permis la création de la RFC 2246. Il y a très peu de différence entre SSL version 3 et TLS version 1 (qui correspond à la version 3.1 du protocole SSL) suffisamment cependant pour rendre les deux protocoles non interopérables. Cependant TLS a mis en place un mécanisme de compatibilité ascendante avec SSL. En outre, TLS diffère de SSL pour la génération des clés symétriques. Cette génération est plus sécurisée dans TLS que dans SSL v3 dans la mesure où aucune étape de l'algorithme ne repose uniquement sur MD5 pour lequel sont apparues quelques faiblesses en cryptanalyse. Par abus de langage, on parle de SSL pour désigner indifféremment SSL ou TLS. TLS fonctionne suivant un mode client-serveur. Il fournit quatre objectifs de sécurité : -l'authentification du serveur, - la confidentialité des données échangées (ou session chiffrée), - l'intégrité des données échangées, - de manière optionnelle, l'authentification du client avec l'utilisation d'un certificat numérique.

On voit que le protocole TLS permet de résoudre tous les problèmes, à condition que l'utilisateur soit porteur d'un certificat numérique. Dans la majorité des cas, l'utilisateur authentifie le serveur TLS sur lequel il se connecte. Cette authentification est réalisée par l'utilisation d'un certificat numérique X509 délivré par une autorité de confiance (AC). Mais de plus en plus d'applications web utilisent maintenant l'authentification du poste client en exploitant TLS. Pour ce faire, il faut que le poste client dispose lui aussi d'un certificat. Il est alors possible d'offrir une authentification mutuelle entre le client et le serveur. Le certificat client peut être stocké en format software sur le poste client ou au format hardware (carte à puce, token USB) pour augmenter la sécurité du lien TLS. Cette solution permet d'offrir des mécanismes d'authentification forte. X.509 est un standard de cryptographie de l'Union internationale des télécommunications pour les infrastructures à clés publiques (PKI). X.509 établit, entre autres, les formats standard de certificats électroniques et un algorithme pour la validation de chemin de certification.

Ce standard pose un problème car il suppose qu'il existe autant de certificats que d'utilisateurs potentiels. Hors un certificat est basé sur : - une autorité de certification garantissant la validité du certificat, - une biclé de chiffrement pour réaliser un chiffrement asymétrique.

Ces deux caractéristiques sont bloquantes pour la généralisation de cette solution à un réseau de téléphonie mobile comptant des millions d'utilisateurs. En effet, il faudrait alors gérer une grosse liste de révocations, une liste dite CRL pour Certificate Revocation List , pour la gestion des certificats corrompus, en suspens ou non valides. Il faudrait aussi être capable de produire autant de biclés que d'utilisateurs. Cela est virtuellement impossible en considérant des moyens compatibles avec une exploitation commerciale devant permettre à tous d'adopter cette solution. Dans l'invention on résout ces problèmes existant de longue date en exploitant une particularité du protocole TLS présentant alors dans ce type d'application un effet technique inattendu puisque, correctement employé, cette caractéristique permet de ne pas avoir besoin de recourir au mécanisme des certificats numériques pour pouvoir authentifier le client. L'invention exploite donc la possibilité qu'offre le protocole TLS de pouvoir transmettre des informations en même temps que le certificat du serveur. Ici par en même temps il faut comprendre dans la même phase protocolaire. Une conséquence de cela est que le protocole TLS permet alors de réaliser une authentification du client ne se basant pas sur un certificat numérique de type X.509. Selon l'invention ces informations sont un challenge qui devra être correctement résolu par le client, cette résolution correcte permettant l'authentification du client par le serveur. Cette authentification est donc réalisée via le protocole TLS, mais sans avoir recours à un certificat client. Dans la pratique le challenge est résolu par une carte SIM (Subscriber Idenrification Module du dispositif mettant en oeuvre le client). L'invention a donc pour objet un procédé d'authentification, par un premier dispositif mettant en oeuvre une application serveur, d'un deuxième dispositif mettant en oeuvre une application client, les premier et deuxième dispositifs étant connectés via un réseau télématique en utilisant le protocole TLS, caractérisé en ce que : - après avoir émis son certificat numérique le premier dispositif émet, en utilisant le protocole TLS, un message de challenge, - le deuxième dispositif reçoit le message de challenge, - le deuxième dispositif résout le message de challenge, produit et émet via le protocole TLS un message de réponse au challenge, - le premier dispositif reçoit le message de réponse et, si le message de réponse et valide, poursuit la communication avec le deuxième dispositif. Dans une variante le procédé selon l'invention est également caractérisé en ce que le message de challenge est émis via le sous- protocole Handshake du protocole TLS. Dans une variante le procédé selon l'invention est également caractérisé en ce que la résolution du challenge est réalisée par une carte microcircuit embarquée par le deuxième dispositif. Dans une variante le procédé selon l'invention est également caractérisé en ce que la carte microcircuit est une carte d'identification internationale d'abonné délivrée par un opérateur de télécommunication.

Dans une variante le procédé selon l'invention est également caractérisé en ce que le message de réponse est émis via le sous- protocole Handshake du protocole TLS. L'invention sera mieux comprise à la lecture de la description qui suit et à la lecture des figures qui l'accompagnent. Celles-ci sont présentées à titre indicatif et nullement limitatif de l'invention. Les figures montrent : Figure 1 : une illustration de moyens permettant la mise en oeuvre de l'invention. Figure 2 : une illustration d'étapes du procédé selon l'invention. La figure 1 montre un premier dispositif 101 serveur. Le dispositif 101 25 comporte au moins : - un microprocesseur 102, - une mémoire 103 de certificats, - une mémoire 104 de programmes et, - des circuits 105 de connexion. 30 Les éléments 102 à 105 sont interconnectés via un bus 106. Les circuits 105 permettent de connecter le dispositif 101 à un réseau télématique, ici le réseau 107 Internet. Les circuits 105 assurent l'interface entre les signaux reçus via le réseau 107 et les signaux reçus via le bus 106. La mémoire 104 est divisée en plusieurs zones, chaque zone 35 comportant des codes instructions correspondant à une fonction du dispositif 101. La mémoire 104 comporte au moins : - une zone 104a correspondant à la mise en oeuvre du protocole TLS, - une zone 104b correspondant à la mise en oeuvre d'une application serveur, par exemple un serveur web , - une zone 104c correspondant à la gestion d'un challenge selon l'invention. On parle du protocole TLS, mais il faut comprendre SSL, TLS ou équivalent, comme à chaque fois que l'on parle de TLS et de SSL. La figure 1 montre un deuxième dispositif 108 client. Le dispositif 108 10 comporte au moins : -un microprocesseur 109, - une mémoire 110 de programmes et, - des circuits 111 de connexion. Les éléments 109 à 111 sont interconnectés via un bus 112. 15 Les circuits 111 sont équivalents aux circuits 105. Ils permettent de connecter le dispositif 108 au réseau 107. La mémoire 110 est divisée en plusieurs zones, chaque zone comportant des codes instructions correspondant à une fonction du dispositif 108. La mémoire 110 comporte au moins : 20 - une zone 110a correspondant à la mise en oeuvre du protocole TLS, - une zone 110b correspondant à une mise en oeuvre d'une application cliente, par exemple un navigateur web . Dans notre exemple on considère que le dispositif 108 est un dispositif mobile. Un dispositif mobile est un dispositif connectable à un réseau de 25 téléphonie mobile, par exemple un téléphone mobile, un assistant personnel ou encore un ordinateur comportant un modem lui permettant de se connecter à un réseau de téléphonie mobile. Pour le dispositif 108 les circuits 111 sont donc des circuits selon l'une des normes de téléphonie mobile que ce soit de deuxième génération 30 (GSM), de deuxième génération et demie, de troisième génération (UMTS) ou d'une génération à venir. La figure 1 montre aussi que le dispositif 108 comporte une carte 112 microcircuit. La carte 112 microcircuit comporte au moins : - un microprocesseur 113, 35 -une mémoire 114 de programmes et, - des circuits 115 de connexion. Les éléments 113 à 115 sont interconnectés via un bus 116. La mémoire 114 est divisée en plusieurs zones, chaque zone comportant des codes instructions correspondant à une fonction de la carte 112. La mémoire 114 comporte au moins : - une zone 114a correspondant à la réponse à un challenge. La figure 1 n'illustre pas d'autres éléments utiles du dispositif 108 comme, entre autres, ses périphériques d'entrées/sorties permettant à un utilisateur d'utiliser le dispositif 108. Ces périphériques sont au moins un clavier et un écran. On remarque déjà que l'invention propose de réaliser une authentification du client, mais que le dispositif mettant en oeuvre le client ne comporte pas de certificat propre à l'authentification via le protocole TLS. La figure 2 illustre une étape 201 préliminaire dans laquelle le client émet un message ClientHello (bonjour du client) vers le serveur. Dans la pratique cette action est déclenchée, par exemple, par une action d'un utilisateur du dispositif 108 provoquant la mise en oeuvre du client 110b. Cette action est, par exemple, l'activation d'une URL (Universal Resource Locator, localisation universelle d'une ressource) désignant un serveur sécurisé. Une telle URL est de la forme : https://mabanque.fr Cette URL implique que le protocole à utiliser est le protocole https, c'est-à-dire le protocole http sécurisé à travers le protocole SSL / TLS. L'activation de cette URL provoque l'exécution de l'application cliente qui va interpréter le lien et initier un dialogue avec le serveur identifié par mabanque.fr selon le protocole https. Le premier message de ce dialogue est le message ClientHello . Il s'agit de l'initiation d'un dialogue selon le sous-protocole HandShake (poignée de mains) du protocole TLS. L'objet de ce protocole est de déterminer les paramètres d'une session de dialogue entre un client et un serveur. Dans une étape 202 le serveur 104b reçoit un message ClientHello et produit en réponse un message ServerHello (bonjour du serveur). Dans une étape 203 suivant l'étape 202 le client 110b reçoit la réponse du serveur.

Les client et serveur savent maintenant qu'ils peuvent se comprendre selon le protocole https, une session est ouverte de part et autre. Cette session est, entre autres, une allocation de ressource mémoire permettant de sauvegarder des paramètres de communication comme des clés de chiffrage ou des états renseignant sur le statut du dialogue. Dans la pratique un message comporte un en-tête et un corps. Ceux-ci sont formatés selon un protocole. L'en-tête comporte au moins : - un identifiant du destinataire permettant l'acheminement du message dans le réseau, - un identifiant de l'émetteur permettant au destinataire de répondre devenant ainsi un émetteur, et - un identifiant de protocole aussi connu sous le nom d'identifiant de port renseignant sur les traitements à appliquer au message. Après l'étape 202 le serveur 104b poursuit le dialogue en émettant, dans une étape 204 et vers l'émetteur du message ClientHello un message Certificate (certificat). Le message Certificate comporte le certificat du serveur, c'est-à-dire le contenu de la mémoire 103. Après l'étape 202 le serveur 104b poursuit le dialogue en émettant, dans une étape 205, selon l'invention et vers l'émetteur du message ClientHello un message RAND (challenge aléatoire). Le message RAND comporte un challenge que devra passer le client 110b pour que le dialogue entre ledit client et le serveur 104b puisse se poursuivre. Après les étapes 204 et 205 le serveur 104b poursuit le dialogue en émettant, dans une étape 206 et vers l'émetteur du message ClientHello un message ServerHelloDone (le serveur a dit bonjour). Ce message indique que le serveur 104b n'enverra plus de message et attend des réponses du client 110b. Si cette attente dépasse une durée prédéterminée alors le serveur 104b réinitialise la session. Dans ce cas, pour reprendre le dialogue un client devra recommencer à l'étape 201.

Dans une étape 207 suivant l'étape 204, le client 110b reçoit le certificat numérique du dispositif 101 via le message Certificate et utilise ce certificat numérique pour : - effectuer des vérifications de validité dudit certificat auprès d'une Autorité de Confiance, - sécuriser ses communications ultérieures avec le serveur 104b.

Cette sécurisation est réalisée par un chiffrage des données en utilisant la clé publique du certificat, ainsi seul un dispositif connaissant la clé privée du certificat pourra lire ces informations. Dans une étape 208 suivant l'étape 205 le client 110b reçoit le 5 message RAND et en stocke le contenu. Dans une étape 209 suivant l'étape 206 le client 110 reçoit le message ServerHelloDone . Après l'étape 209, dans une étape 210, si le résultat de l'étape 207 s'est révélé satisfaisant, alors le client 110b essaie de résoudre le challenge 10 reçu à l'étape 208. Le résultat est satisfaisant au moins si le certificat présenté n'est pas révoqué. Dans l'étape 210 le microprocesseur 109 transmet le contenu du message RAND au microprocesseur 113. Le microprocesseur 113 met alors en oeuvre les codes instructions de la zone 114a pour produire le 15 contenu RES d'un message SRES . Le contenu RES est fourni au client 110b qui produit le message SRES envoyé en réponse au message RAND . Dans une étape 221 suivant l'étape 210 le serveur 104b reçoit le message SRES est a donc accès au contenu RES. 20 Le contenu RES est une fonction F du contenu du message RAND et de données identifiant la carte 112 SIM. Le traitement du message SRES par le serveur 104b permet donc d'authentifier le porteur légitime de la carte 112. La fonction F est un secret partagé par les cartes SIM et les dispositifs serveurs impliqués dans la mise en oeuvre de l'invention. 25 Dans une variante de l'invention on utilise les algorithmes A3/A8 qui sont nativement présents dans une carte SIM car il s'agit des algorithmes utilisés pour l'authentification des abonnés dans les réseaux de téléphonie mobile, comme défini dans les documents GSM 03.20. Dans ce cas, l'algorithme A3 est utilisé pour produire le contenu RES en utilisant une clé 30 de chiffrement produite par l'algorithme A8. Après l'étape 211, si le message SRES satisfait le serveur 104b le dialogue se poursuit selon le sous-protocole HandShake par des étapes d'échange de clés de chiffrement et plus généralement de paramètres de format de messages chiffrés afin de définir selon quel chiffrement les 35 données seront échangées durant la suite du dialogue.

Cette poignée de mains se termine par un message finished (fini) à la suite duquel client et serveur poursuivent le dialogue en appliquant les paramètres déterminés au cours des étapes précédentes. L'invention est particulièrement intéressante car l'envoi des messages RAND et SRES est réalisé en utilisant le protocole TLS sans qu'il soit besoin de le modifier. Il n'y a donc aucun impact de déploiement sur le réseau ou de risque d'incompatibilité. En particulier, dans une variante ces messages peuvent être envoyés via le sous-protocole Alert (Alerte) utilisé pas le protocole TLS pour émettre des messages asynchrones durant notamment la poignée de mains . On note ici qu'il ne s'agit que d'une possibilité, de transmission de ces messages. Une autre variante est d'utiliser des trames. L'invention est encore intéressante car l'authentification du client est liée à une carte à puce dont la réputation de sécurité n'est plus à faire. Une telle carte est en particulier une carte SIM distribuée par un Opérateur de téléphonie mobile. L'impact de l'invention sur un réseau de téléphonie mobile préexistant est donc minimal. Il suffit d'adapter les couches protocolaires des dispositifs terminaux mettant en oeuvre l'invention, le reste du réseau étant déjà apte à acheminer des trames selon le protocole TLS.

Dans l'invention le message RAND remplace le message CertificateRequest (demande de certificat) habituellement émis par le serveur lorsque celui-ci souhaite identifier et authentifier le client. Cette phase est communément appelée authentification mutuelle . L'utilisateur n'a donc plus à demander (à une autorité de confiance différente de son opérateur de télécommunication) et à installer un certificat sur son dispositif de communication. Un mécanisme d'authentification lui est fourni avec sa carte SIM et ce sans que l'opérateur produisant ladite carte n'ait besoin de déployer une infrastructure PKI. L'invention a été décrite dans le cadre d'une connexion d'un navigateur à un serveur web . Bien entendu dans la mesure où le protocole SSLITLS peut être employé par tout type de clients et de serveurs cet exemple de mise en oeuvre n'est pas limitatif de l'invention.

Claims (5)

REVENDICATIONS

1 û Procédé d'authentification, par un premier dispositif mettant en oeuvre une application serveur, d'un deuxième dispositif mettant en oeuvre une application client, les premier et deuxième dispositifs étant connectés via un réseau télématique en utilisant au moins le protocole TLS, caractérisé en ce que : - après avoir émis son certificat numérique le premier dispositif émet, en utilisant le protocole TLS, un message de challenge, - le deuxième dispositif reçoit le message de challenge, - le deuxième dispositif résout le message de challenge, produit et émet via le protocole TLS un message de réponse au challenge, - le premier dispositif reçoit le message de réponse et, si le message de réponse et valide, poursuit la communication avec le deuxième dispositif.

2 û Procédé selon la revendication 1, caractérisé en ce que le message de challenge est émis via le sous-protocole Handshake du protocole TLS.

3 û Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que la résolution du challenge est réalisée par un carte microcircuit embarquée par le deuxième dispositif.

4 û Procédé selon la revendication 3, caractérisé en ce que la carte microcircuit est une carte d'identification internationale d'abonné délivrée par un opérateur de télécommunication.

5 û Procédé selon l'une des revendications 1 à 4, caractérisé en ce 25 que le message de réponse est émis via le sous-protocole Handshake du protocole TLS.