FR2923110A1 - Client device e.g. mobile telephone, authenticating method for internet network, involves receiving response message by server device, and continuing communication between server device and client device, if response message is valid - Google Patents

Client device e.g. mobile telephone, authenticating method for internet network, involves receiving response message by server device, and continuing communication between server device and client device, if response message is valid Download PDF

Info

Publication number
FR2923110A1
FR2923110A1 FR0758619A FR0758619A FR2923110A1 FR 2923110 A1 FR2923110 A1 FR 2923110A1 FR 0758619 A FR0758619 A FR 0758619A FR 0758619 A FR0758619 A FR 0758619A FR 2923110 A1 FR2923110 A1 FR 2923110A1
Authority
FR
France
Prior art keywords
server
client
response message
message
protocol
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0758619A
Other languages
French (fr)
Other versions
FR2923110B1 (en
Inventor
Ludovic Petit
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Societe Francaise du Radiotelephone SFR SA
Original Assignee
Societe Francaise du Radiotelephone SFR SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Societe Francaise du Radiotelephone SFR SA filed Critical Societe Francaise du Radiotelephone SFR SA
Priority to FR0758619A priority Critical patent/FR2923110B1/en
Publication of FR2923110A1 publication Critical patent/FR2923110A1/en
Application granted granted Critical
Publication of FR2923110B1 publication Critical patent/FR2923110B1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/069Authentication using certificates or pre-shared keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/166Implementing security features at a particular protocol layer at the transport layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

The method involves sending a challenge message by a server device using a transport layer security (TLS) protocol, after sending a digital certificate of the server device. The challenge message is received and resolved by a client device. A response message for the challenge is produced and sent via the protocol by the client device. The response message is received by the server device. Communication between the server device and the client device is continued, if the response message is valid.

Description

Authentification sécurisée perfectionnée d'un client mobile Advanced secure authentication of a mobile client

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. The subject of the invention is a method for authenticating a client via the TLS and WTLS protocols. The field of the invention is that of authentication. More particularly, the field of the invention is that of the secure authentication of a client by a server. By secure means here obtaining two guarantees: -authentification of clients and server, ends of the channel through which the data exchanged between the client and the server transit; - securing the data itself against tampering and interception. By server is meant an application implemented by a device connected to a telematic network. The device implementing the server is computer type that is domestic, professional or hardened to obtain a high quality of service. The interesting features of such a device relative to the description of the invention are that said device comprises a microprocessor, a program memory and connection circuits to the telematic network. The program memory then comprises instruction codes corresponding to the server. These instruction codes are executed by the microprocessor which is able to control at least the connection circuits to the telematic network. The server is therefore able to handle requests reaching it in the form of messages formatted according to a protocol via the telematic network. The server is therefore also able to produce response messages to requests received via the telematic network. Typical server examples are servers: - Web, ie servers operating according to the HTTP protocol (hypertext transfer protocol, for hypertext transfer protocol), - messaging, that is to say servers operating according to protocols of the POP, SMTP, IMAP type ... - streaming, that is to say of video broadcasting allowing the diffusion of animated multimedia programs in real time through a telematic network, - application, it that is to say, for example, a so-called dynamic web server 35 capable of performing advanced processing in response to requests received, this list not being of course not exhaustive. By client is meant an application implemented by a device connected to a telematic network. The device implementing the client is of the telephone personal computer type, mobile phone, personal assistant and more generally any device capable of connecting to a telematic network. Such a device comprises a microprocessor and a program memory comprising instruction codes corresponding to the implementation of the client application. The best-known customers are Internet browsers and email clients that connect to web servers and mail servers respectively. In a more general way, we call Client any application capable of communicating with a server. In practice the client and the server are confused with the devices that implement these applications. Thus, in this document, when speaking of an action performed by the client or the server, this is in fact carried out by a microprocessor of a device comprising a program memory in which instructions codes corresponding to the client are recorded. or to the server.

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 . The execution of these instruction codes corresponds to the implementation of the client or the server. In the state of the art the dialogues between a client and a server are well known. The most common of these dialogues is the one that is established between an Internet browser, or simply browser, and a web server. We note here that the envisaged telematic network is the Internet network. In practice, the field of the invention extends to any type of data exchange network that is open, such as the Internet, or closed like a home local area network, an enterprise premises network or a home network. a fixed / mobile telephone operator.

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. These dialogs allow the deployment of services. This is a provider that offers a service via a server. Among these services we know: - online shops, - thematic portals, for example a general and collaborative encyclopedia, a site specialized in a field of activity, ... - the interfaces of consultation and management of administrative data, among these interfaces are the sites of subscription to a service. this list is not exhaustive either.

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. To make these services attractive we seek to reassure potential users about their effectiveness and safety. Indeed with the development of Internet-type open networks new types of scams have emerged. One of the most harmful is currently known as phishing. It is for the scammer to imitate a real reputable site and attract users to this site. Users of the real site then believe to be on the usual site when in fact they are in communication with a malicious copy of the real site. All information that users enter then is accessible to the scammer. Less common scams involve intercepting data streams to read content. In this case, it is no longer worth bothering to imitate a site to mislead the user. Another problem that has arisen is the trust that providers can place in their client or, more accurately, the users of their online services who try to become their client but with malicious intent or by usurping an identity. The person whose identity was usurped then files a complaint and wins the case in most cases, which is an injury to the claimant who must compensate the person although the claimant is in good faith. In the state of the art, to solve these security problems service providers deploy their server using secure protocols for authentication of servers and clients, as well as the encryption of exchanged data. The protocols used are then SSL or TLS. These protocols are described by many sources, including for example the Wikipedia online encyclopedia. We recall here the bases of these protocols. The Transport Layer Security (TLS) protocol, formerly known as Secure Socket Layer (SSL), is a secure Internet exchange protocol, originally developed by Netscape (SSL version 2 and 2). SSL version 3). It was renamed Transport Layer Security (TLS) by the IETF in 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. The working group corresponding to the IETF has enabled the creation of RFC 2246. There is very little difference between SSL version 3 and TLS version 1 (which corresponds to version 3.1 of the SSL protocol), however enough to make both non-interoperable protocols. However, TLS has implemented an upward compatibility mechanism with SSL. In addition, TLS differs from SSL in symmetric key generation. This generation is more secure in TLS than in SSL v3 since no algorithm step relies solely on MD5 for which some weaknesses in cryptanalysis appeared. By abuse of language, we speak of SSL to denote either SSL or TLS. TLS operates in a client-server mode. It provides four security objectives: - server authentication, - confidentiality of exchanged data (or encrypted session), - integrity of data exchanged, - optionally, client authentication with the use of a digital certificate.

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. It can be seen that the TLS protocol solves all the problems, provided that the user carries a digital certificate. In the majority of cases, the user authenticates the TLS server to which he connects. This authentication is achieved through the use of an X509 digital certificate issued by a trusted authority (CA). But more and more web applications are now using client-side authentication using TLS. To do this, the client station must also have a certificate. It is then possible to offer mutual authentication between the client and the server. The client certificate can be stored in software format on the client computer or in hardware format (smart card, USB token) to increase the security of the TLS link. This solution makes it possible to offer strong authentication mechanisms. X.509 is a cryptographic standard of the International Telecommunication Union for Public Key Infrastructure (PKI). X.509 establishes, among other things, standard electronic certificate formats and an algorithm for certification path validation.

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. This standard poses a problem because it assumes that there are as many certificates as there are potential users. Except a certificate is based on: - a certificate authority guaranteeing the validity of the certificate, - an encryption key pair to achieve asymmetric encryption.

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. These two features are blocking the generalization of this solution to a mobile network with millions of users. Indeed, it would then be necessary to manage a large list of revocations, a so-called CRL list for Certificate Revocation List, for the management of corrupt, pending or invalid certificates. It should also be able to produce as many pairs as users. This is virtually impossible considering means compatible with a commercial exploitation to allow all to adopt this solution. In the invention, these long-standing problems are solved by exploiting a peculiarity of the TLS protocol which then presents in this type of application an unexpected technical effect since, properly used, this characteristic makes it possible not to have to resort to the mechanism of the certificates. to authenticate the client. The invention therefore exploits the possibility offered by the TLS protocol to be able to transmit information at the same time as the server's certificate. Here at the same time it is necessary to understand in the same protocol phase. One consequence of this is that the TLS protocol then makes it possible to perform client authentication that is not based on an X.509-type digital certificate. According to the invention, this information is a challenge that will have to be correctly solved by the client, this correct resolution allowing the authentication of the client by the server. This authentication is therefore performed via the TLS protocol, but without resorting to a client certificate. In practice the challenge is solved by a SIM card (Subscriber Idenrification Module of the device implementing the client). The subject of the invention is therefore a method of authentication, by a first device implementing a server application, of a second device implementing a client application, the first and second devices being connected via a telematic network using the TLS protocol, characterized in that: - after issuing its digital certificate the first device sends, using the TLS protocol, a challenge message, - the second device receives the challenge message, - the second device resolves the challenge message , produces and transmits via the TLS protocol a challenge response message, - the first device receives the response message and, if the response message and validates, continues the communication with the second device. In a variant, the method according to the invention is also characterized in that the challenge message is transmitted via the Handshake sub-protocol of the TLS protocol. In a variant, the method according to the invention is also characterized in that the resolution of the challenge is performed by a microcircuit card embarked by the second device. In a variant, the method according to the invention is also characterized in that the microcircuit card is an international subscriber identification card issued by a telecommunication operator.

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. In a variant, the method according to the invention is also characterized in that the response message is transmitted via the Handshake sub-protocol of the TLS protocol. The invention will be better understood on reading the following description and reading the figures that accompany it. These are presented as an indication and in no way limitative of the invention. The figures show: FIG. 1: an illustration of means allowing the implementation of the invention. Figure 2: an illustration of steps of the method according to the invention. Figure 1 shows a first device 101 server. The device 101 comprises at least: a microprocessor 102, a certificate memory 103, a program memory 104 and connection circuits 105. The elements 102 to 105 are interconnected via a bus 106. The circuits 105 enable the device 101 to be connected to a telematic network, here the Internet network 107. The circuits 105 provide the interface between the signals received via the network 107 and the signals received via the bus 106. The memory 104 is divided into several zones, each zone 35 comprising instruction codes corresponding to a function of the device 101. 104 comprises at least: a zone 104a corresponding to the implementation of the TLS protocol, a zone 104b corresponding to the implementation of a server application, for example a web server, a zone 104c corresponding to the management of the server. a challenge according to the invention. We talk about the TLS protocol, but we must understand SSL, TLS or equivalent, as every time we talk about TLS and SSL. Figure 1 shows a second device 108 client. The device 108 comprises at least: a microprocessor 109, a program memory 110 and connection circuits 111. The elements 109 to 111 are interconnected via a bus 112. The circuits 111 are equivalent to the circuits 105. They enable the device 108 to be connected to the network 107. The memory 110 is divided into several zones, each zone comprising instruction codes corresponding to a function of the device 108. The memory 110 comprises at least: a zone 110a corresponding to the implementation of the TLS protocol, a zone 110b corresponding to an implementation of a client application, for example a web browser. In our example, it is considered that the device 108 is a mobile device. A mobile device is a device connectable to a mobile telephone network, for example a mobile phone, a personal assistant or a computer comprising a modem enabling it to connect to a mobile telephone network. For the device 108, the circuits 111 are therefore circuits according to one of the mobile telephony standards, whether of the second generation (GSM), the second generation and a half, the third generation (UMTS) or a future generation. . Figure 1 also shows that the device 108 comprises a microcircuit card 112. The microcircuit card 112 comprises at least: a microprocessor 113, a program memory 114 and connection circuits 115. The elements 113 to 115 are interconnected via a bus 116. The memory 114 is divided into several zones, each zone comprising instruction codes corresponding to a function of the card 112. The memory 114 comprises at least: a zone 114a corresponding to the answer to a challenge. FIG. 1 does not illustrate other useful elements of the device 108 such as, inter alia, its input / output peripherals enabling a user to use the device 108. These devices are at least a keyboard and a screen. It is already noted that the invention proposes to perform client authentication, but that the device implementing the client does not include a certificate specific to authentication via the TLS protocol. Figure 2 illustrates a preliminary step 201 in which the client issues a ClientHello message to the server. In practice this action is triggered, for example, by an action of a user of the device 108 causing the implementation of the client 110b. This action is, for example, the activation of a URL (Universal Resource Locator) designating a secure server. Such a URL is in the form: https://mabanque.fr This URL implies that the protocol to use is the https protocol, that is to say the secure http protocol through the SSL / TLS protocol. Activation of this URL causes the client application to execute, which will interpret the link and initiate a dialogue with the server identified by mabanque.fr according to the https protocol. The first message in this dialog is the ClientHello message. This is the initiation of a dialogue according to the HandShake sub-protocol (handshake) of the TLS protocol. The purpose of this protocol is to determine the parameters of a dialog session between a client and a server. In a step 202, the server 104b receives a ClientHello message and responds with a ServerHello message. In a step 203 following step 202 the client 110b receives the response from the server.

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. The client and server now know that they can understand themselves according to the https protocol, a session is open on both sides. This session is, among other things, a memory resource allocation for saving communication parameters such as encryption keys or states informing about the status of the dialogue. In practice, a message has a header and a body. These are formatted according to a protocol. The header comprises at least: - an identifier of the recipient for routing the message in the network, - an identifier of the sender allowing the recipient to respond thereby becoming a sender, and - a protocol identifier also known as the port identifier name providing information on the processing to be applied to the message. After step 202 the server 104b continues the dialogue by issuing, in a step 204 and to the sender of the ClientHello message a Certificate message. The message Certificate contains the certificate of the server, that is to say the contents of the memory 103. After the step 202 the server 104b continues the dialogue by emitting, in a step 205, according to the invention and to the Transmitter of the message ClientHello a message RAND (random challenge). The RAND message comprises a challenge that will have to be passed by the client 110b so that the dialogue between said client and the server 104b can continue. After the steps 204 and 205, the server 104b continues the dialogue by sending, in a step 206 and to the sender of the ClientHello message, a ServerHelloDone message (the server said hello). This message indicates that the server 104b will not send any more messages and waits for responses from the client 110b. If this wait exceeds a predetermined time then the server 104b resets the session. In this case, to resume the dialogue a customer will have to start again at step 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. In a step 207 following step 204, the client 110b receives the digital certificate of the device 101 via the Certificate message and uses this digital certificate to: - carry out validity checks of said certificate with a Trust Authority, - secure its subsequent communications with the server 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. This security is achieved by encrypting the data using the public key of the certificate, so only a device knowing the private key of the certificate can read this information. In a step 208 following step 205 the client 110b receives the RAND message and stores the content therein. In a step 209 following step 206 the client 110 receives the ServerHelloDone message. After step 209, in a step 210, if the result of step 207 has proved satisfactory, then client 110b tries to resolve challenge 10 received in step 208. The result is satisfactory at least if the certificate submitted is not revoked. In step 210 the microprocessor 109 transmits the contents of the RAND message to the microprocessor 113. The microprocessor 113 then implements the instruction codes of the area 114a to produce the RES content of an SRES message. The RES content is provided to the client 110b which produces the SRES message sent in response to the RAND message. In a step 221 following step 210 the server 104b receives the message SRES is therefore access to the content RES. The RES content is a function F of the contents of the RAND message and of data identifying the SIM card 112. The processing of the SRES message by the server 104b thus makes it possible to authenticate the legitimate bearer of the card 112. The function F is a secret shared by the SIM cards and the server devices involved in the implementation of the invention. In one variant of the invention, the A3 / A8 algorithms which are natively present in a SIM card are used because they are the algorithms used for the authentication of the subscribers in the mobile telephone networks, as defined in the GSM documents. 03.20. In this case, the algorithm A3 is used to produce the RES content using an encryption key produced by the algorithm A8. After step 211, if the SRES message satisfies the server 104b the dialogue continues according to the HandShake sub-protocol by encryption key exchange steps and more generally encrypted message format parameters in order to define according to which encryption the data will be exchanged during the next 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. This handshake ends with a finished message after which the client and server continue the dialogue by applying the parameters determined in the previous steps. The invention is particularly interesting because the sending of the RAND and SRES messages is carried out using the TLS protocol without any need to modify it. There is no impact of deployment on the network or risk of incompatibility. In particular, in a variant these messages can be sent via the sub-protocol Alert (Alerte) not used the TLS protocol to issue asynchronous messages during the handshake. We note here that this is only a possibility, transmission of these messages. Another variant is to use frames. The invention is still interesting because the authentication of the client is linked to a smart card whose reputation for safety is second to none. Such a card is in particular a SIM card distributed by a mobile operator. The impact of the invention on a pre-existing mobile telephony network is therefore minimal. It suffices to adapt the protocol layers of the terminal devices implementing the invention, the rest of the network being already able to route frames according to the TLS protocol.

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. In the invention, the RAND message replaces the CertificateRequest message usually issued by the server when the server wishes to identify and authenticate the client. This phase is commonly called mutual authentication. The user no longer has to ask (a trusted authority different from his telecommunication operator) and install a certificate on his communication device. An authentication mechanism is provided with its SIM card without the operator producing the card needs to deploy a PKI infrastructure. The invention has been described in connection with a connection of a browser to a web server. Of course, since the SSLITLS protocol can be used by any type of client and server this example of implementation is not limiting of the 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.1 - Method of authentication, by a first device implementing a server application, of a second device implementing a client application, the first and second devices being connected via a telematic network using at least the TLS protocol, characterized in that: - after issuing its digital certificate the first device sends, using the TLS protocol, a challenge message, - the second device receives the challenge message, - the second device resolves the challenge message, produces and transmits via the TLS protocol a challenge response message, - the first device receives the response message and, if the response message and validates, continues the communication with the second device. 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.2 - Process according to claim 1, characterized in that the challenge message is transmitted via the Handshake sub-protocol of the TLS protocol. 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.3 - Process according to one of claims 1 or 2, characterized in that the resolution of the challenge is performed by a microcircuit card embarked by the second device. 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.4 - Process according to claim 3, characterized in that the microcircuit card is an international subscriber identification card issued by a telecommunication operator. 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. 5. Process according to one of claims 1 to 4, characterized in that the response message is transmitted via the TLS protocol Handshake sub-protocol.
FR0758619A 2007-10-26 2007-10-26 PERFECTED SECURE AUTHENTICATION OF A MOBILE CUSTOMER. Active FR2923110B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0758619A FR2923110B1 (en) 2007-10-26 2007-10-26 PERFECTED SECURE AUTHENTICATION OF A MOBILE CUSTOMER.

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0758619A FR2923110B1 (en) 2007-10-26 2007-10-26 PERFECTED SECURE AUTHENTICATION OF A MOBILE CUSTOMER.

Publications (2)

Publication Number Publication Date
FR2923110A1 true FR2923110A1 (en) 2009-05-01
FR2923110B1 FR2923110B1 (en) 2009-11-20

Family

ID=39537444

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0758619A Active FR2923110B1 (en) 2007-10-26 2007-10-26 PERFECTED SECURE AUTHENTICATION OF A MOBILE CUSTOMER.

Country Status (1)

Country Link
FR (1) FR2923110B1 (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030200431A1 (en) * 2002-04-18 2003-10-23 Nokia Corporation Method and apparatus for providing peer authentication for a transport layer session
US20070162958A1 (en) * 2005-12-29 2007-07-12 Min-Chih Kao Method and system for secure authentication in a wireless network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030200431A1 (en) * 2002-04-18 2003-10-23 Nokia Corporation Method and apparatus for providing peer authentication for a transport layer session
US20070162958A1 (en) * 2005-12-29 2007-07-12 Min-Chih Kao Method and system for secure authentication in a wireless network

Also Published As

Publication number Publication date
FR2923110B1 (en) 2009-11-20

Similar Documents

Publication Publication Date Title
EP1909462B1 (en) Method of compartmentalised provision of an electronic service
EP2484084B1 (en) Method and devices allowing communication secure against denial of services (dos) and against flooding attacks in a telecommunications network
FR2916592A1 (en) INFORMATION EXCHANGE SECURING METHOD, DEVICE, AND CORRESPONDING COMPUTER PROGRAM PRODUCT
EP3375133B1 (en) Method for securing and authenticating a telecommunication
EP1400056B1 (en) Cryptographic authentication process
WO2018234675A1 (en) Method of activating processes applied to a data session
WO2018130796A1 (en) Methods and devices for checking the validity of a delegation of distribution of encrypted content
CN105471896B (en) Proxy Method, apparatus and system based on SSL
EP3568964B1 (en) Method for end-to-end transmission of a piece of encrypted digital information and system implementing this method
EP1227640B1 (en) Method and system for communicating a certificate between a security module and a server
EP2056565A1 (en) Method of authenticating a user accessing a remote server from a computer
WO2014191683A1 (en) Technique for distributing a piece of content in a content distribution network
EP2630765B1 (en) Method for optimizing the transfer of a stream of secure data via an autonomic network
FR2923110A1 (en) Client device e.g. mobile telephone, authenticating method for internet network, involves receiving response message by server device, and continuing communication between server device and client device, if response message is valid
EP1418702B1 (en) Secure exchange method between two communications units, control system and server for the set-up of the method
WO2004017269A1 (en) Method and system for the secure transmission of a confidential code through a telecommunication network
EP3041192B1 (en) Authentication infrastructure for ip phones of a proprietary toip system by an open eap-tls system
FR2858497A1 (en) Documents providing process for e.g. Internet, involves decomposing sections of document and identifier set into projections by Mojette transform, and gradually sending sections to client machine that confirms reception by its signature
WO2006134072A1 (en) Method for protection against tampering of a client terminal using a secure connection with a server on a public network
FR2823929A1 (en) Internet network digital word certification having identification operation first terminal/communications network certificate transmitting representing unique address and second terminal certificate decoded and server/link established.
EP1484895A1 (en) Process of access to a network or a service by using a protocol of the family of PPPoX protocols, and architecture implementing such a process
FR2862170A1 (en) Confidential data transfer process for Internet network, involves executing encryption of data maintained at access provider and relative to user and inserting encrypted data in information service request to be sent to information provider
WO2007012786A2 (en) Method for using a sequence of authentications
FR2885464A1 (en) METHOD AND DEVICE FOR CONTROLLING ACCESS

Legal Events

Date Code Title Description
GC Lien (pledge) constituted

Effective date: 20150310

PLFP Fee payment

Year of fee payment: 10

GC Lien (pledge) constituted

Effective date: 20160930

PLFP Fee payment

Year of fee payment: 11

GC Lien (pledge) constituted

Effective date: 20180111

PLFP Fee payment

Year of fee payment: 12

PLFP Fee payment

Year of fee payment: 13

PLFP Fee payment

Year of fee payment: 14

PLFP Fee payment

Year of fee payment: 15

PLFP Fee payment

Year of fee payment: 16

PLFP Fee payment

Year of fee payment: 17