EP1894342A2 - Authentification d'un serveur avant envoi de donnees d'identification d'un client - Google Patents

Authentification d'un serveur avant envoi de donnees d'identification d'un client

Info

Publication number
EP1894342A2
EP1894342A2 EP06778956A EP06778956A EP1894342A2 EP 1894342 A2 EP1894342 A2 EP 1894342A2 EP 06778956 A EP06778956 A EP 06778956A EP 06778956 A EP06778956 A EP 06778956A EP 1894342 A2 EP1894342 A2 EP 1894342A2
Authority
EP
European Patent Office
Prior art keywords
server
authentication
client
sending
data
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.)
Withdrawn
Application number
EP06778956A
Other languages
German (de)
English (en)
Inventor
Jean-Pierre Le Rouzic
Christian Barre
Vincent Barnaud
Thierry Leclercq
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.)
Orange SA
Original Assignee
France Telecom 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 France Telecom SA filed Critical France Telecom SA
Publication of EP1894342A2 publication Critical patent/EP1894342A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication

Definitions

  • the present invention relates to the general field of access by a client device to an available resource in a server device on a telecommunication network in which access to this resource requires the sending of client identification data to the server .
  • the client device when a client device wishes to access an available resource in a server device, the client device identifies (and possibly authenticates) before the server device.
  • the present invention has for main purpose to overcome the aforementioned drawbacks.
  • this process comprises:
  • the client identification data are sent to the server device only after an authentication step of this server.
  • client identification data may be contained in the access request to the resource, or sent separately.
  • the access method according to the invention further comprises:
  • the request for obtaining data from the client is answered by sending unmarked identification data.
  • an "unmarked data” is data that does not identify or authenticate the client. This is for example a data shared by a predetermined group of customers.
  • the server device requires client authentication data in addition to the aforementioned identification data.
  • the invention solves this particular problem.
  • the method according to the invention comprises;
  • a step of sending customer authentication data Following the step of sending the customer identification data, a step of sending customer authentication data.
  • the client is authenticated to the server with unmarked data so as to obtain the server authentication data sought.
  • the client When the server is finally recognized as being authorized to receive the customer's personal data, the client is authenticated with his own data to the server before requesting access to the desired resource.
  • This first variant is particularly easy to implement, but has a fairly low level of security, especially when the user of the client device carries the telecommunications network to access the server a limited confidence.
  • the server authentication data includes a server certificate whose validity is checked during the verification step.
  • This second variant makes it possible to guarantee the identity of the server device, but requires the use of a trusted third party for issuing this certificate.
  • the authentication request sent to the server device comprises a challenge, and during the step a challenge signature received among the authentication data of the server is checked.
  • This strong authentication mechanism also called “challenge-response” mechanism is based, in a known embodiment, on a cryptographic algorithm using a key pair, and more specifically a private key, on the server side to sign the challenge, and a public key associated with the private key stored by the authentication device to check the validity of this signature.
  • the access method according to the invention mentioned above is implemented in an authentication device.
  • This authentication device can thus obtain and verify the authentication data of the server before sending him identification and / or authentication data of the client.
  • the access method according to the invention preferentially comprises a preliminary step during which the aforementioned authentication device receives an access request from the client device.
  • the invention also relates to a device for authenticating a server device comprising a resource to which a client device wishes to access the access requiring the sending to the server of at least one customer identification data.
  • This device comprises:
  • the authentication device consists of a proxy server placed in a flow-off between the client device and the server device.
  • this proxy server replaces the client device for a first authentication, this first authentication having the sole purpose of obtaining authentication data of the server device.
  • the authentication device is incorporated in the client device.
  • the invention also relates to a telecommunications terminal that incorporates a client device and an authentication device as briefly mentioned above.
  • the different steps of the authentication method are determined by instructions of computer programs.
  • the invention also relates to a computer program on an information carrier, this program being capable of being implemented in a computer or an authentication device as mentioned above.
  • This program includes instructions adapted to the implementation of the steps of the authentication method mentioned above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.
  • the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as an RON, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1A schematically shows a telecommunication device according to the invention in a first preferred embodiment, and the various messages exchanged by this device with a server device and a client device in a preferred embodiment;
  • FIGS. 2A to 2C represent, in flowchart form, the main steps of an access method according to the invention in three preferred embodiments.
  • FIG. 3 shows schematically a computer adapted to implement an access method according to the invention.
  • FIG. 1A shows an authentication device 30 according to the invention, a client device 20 and a server device 40.
  • These three devices are for example constituted by separate computers interconnected by a telecommunication network not shown.
  • the client device 20 and the authentication device 30 are incorporated in the same computer.
  • the authentication device is an integral part of the client device 20.
  • the client device 20 is adapted to send and receive requests to the server 40.
  • the client device 20 and the server 40 communicate via an Internet-type network.
  • the client device 20 may be constituted by an HTTP client known to those skilled in the art.
  • the client device 20 is a mail client adapted to communicate with a mail server 40.
  • the authentication device 30 of FIG. 1A comprises means for implementing the computer program implementing the main steps of the authentication method according to the invention, represented under flowchart form in Figure 2A.
  • server is to be understood in the broadest sense, the invention applying for any type of access to server device including, to authenticate, redirect a request, request an electronic signature, make a request for execution of a software hosted by the server, require administration resources of the client device, ...
  • the client device 20 sends, during a step ElO, a request RACCJX to the authentication device 30 to access a resource.
  • This RACC_CL access request contains the address of the client device 20. It may be constituted for example by an HTTP request when the client device 20 and the authentication device 30 are connected to the Internet network.
  • This access request RACCJX is received by the authentication device 30 during the same step ElO.
  • This reception is followed by a step E20 during which the authentication device 30 sends an authentication request REQ_AUTH_SER to the server device 40.
  • the server device responds to this REQ_AUTH_SER authentication request by sending these authentication data ID_SER, these authentication data ID_SER being received by the authentication device 30 during a step E40.
  • this step is followed by a step E50 during which the authentication device 30 checks, from the IDJBER authentication data, whether the server 40 is authorized or not to receive the personal data. identification of the client device 20.
  • this verification is performed by comparing the ID_SER identity of the server device 40 with identities contained in a list stored by the authentication device 30.
  • step E50 terminates the access method according to the invention in this embodiment.
  • the verification step E50 is followed by a step E60 during which the authentication device 30 checks whether the data of identification ID CL of client device 20 are contained in the access request RACC_CL received from the client device 20 at step ElO.
  • test E60 is followed by a step E70 during which the authentication device 30 sends the access request RACC_CL to the client device 40.
  • the authentication device 30 requests and obtains these data ID_CL, for example by sending a request to the client device 20 during a step E80 .
  • This obtaining step is followed by a sending step E90, to the server device 40, of the access request RACC-CL obtained in step ElO and identification data ID_CL obtained in the previous step.
  • the steps E70 and E90 for sending personal data to the server device 40 complete the access method according to the invention in this embodiment.
  • server device 40 requires obtaining ID_CL identification data of the client device 20 before sending its ID_SER authentication data.
  • the server device 40 when the server device 40 receives the identification request REQ_AUTH_SER sent by the authentication device 30 in the step E20, it sends, to the authentication device 30, a request REQ_ID_CL to obtain at least one identification data ID_CL of the client 20. This obtaining request is received by the authentication device 30 in step E30A.
  • the authentication device 30 responds to this request for obtaining REQ_ID_CL by sending unidentified identification data ID-COMM (step E35).
  • the server device 40 On receipt of this unmarked data, the server device 40 returns, as previously described, these authentication data ID_SER during the step E40.
  • the access method in this second embodiment ends as the access method described above with reference to FIG. 2A.
  • FIG. 2C an access method according to the invention in a third variant embodiment.
  • server device 40 requests not only client identification data 20 but also authentication data from that client.
  • the server device 40 when the server device 40 receives the authentication request REQ_AUTH_SER sent by the authentication device 30 in step E20, it responds to this request by sending a request REQ_ID_AUTH_CL to obtain data. authentication and identification of the client device 20.
  • the authentication device 30 upon receipt of this request to obtain REQJD_AUTH_CL, the authentication device 30 sends during the step E35 already described identification data ID_COMM trivialized to the server device 40.
  • This step E35 of sending unmarked identification data is followed by a step E37 during which the authentication device 30 sends authentication authentication data AUThLCOMM to the server device 40.
  • the server device 40 On receipt of these authentication data AUTH_COMM and identification IDJZOMM, the server device 40 supplies its authentication data ID__SER to the authentication device 30.
  • the client device 20 must authenticate with its own data to the server device 40 to access the desired resource.
  • the authentication device 30 checks during a step E60B whether or not it has the identification data IC_CL and authentication AUTH -CL of the client device 20, this data having for example been received in the access request RACC-CL in step ElO.
  • the authentication device 30 sends, during the step E70 already described, the client request RACC-CL to the server device 40, this step being followed by a step E75 sending the Authentication data AUTH_CL of the client device 20 to the server device 40.
  • the step E60B is followed by a step E80B for obtaining these missing data from the client. customer 20.
  • This obtaining step is followed by the step E90 already described during which the authentication device 30 sends the access request and the identification data of the client 20 to the server device 40.
  • This sending step is followed by a step E95B in which the authentication device 30 sends the authentication data AUTH-CL of the client 20 to the server device 40.
  • This terminal 10 comprises a client device 20, an access device according to the invention adapted to implement a variant according to the invention of the access method described with reference to Figure 2C.
  • the authentication device 30 comprises a memory 50 in which are stored the identification data ID_CL and authentication AUTH_CL of the client device 20.
  • This memory 50 may for example be constituted by a smart card adapted to generate a challenge sent to the server device 40 during the previously described step E20 and calculation means adapted to verify a signature of this challenge received at the step E40 among the authentication data ID_SER of the server 40.
  • the authentication device 30 is incorporated in a proxy server placed in a flow-off between the client 20 and the server 40.
  • This proxy server is thus adapted, in known manner, to intercept an access request sent by the client 20 to the server 40, and to implement the access method according to the invention to verify that the server 40 is authorized to receive the identification data and authentication of the client 20 before the transmission of this request.
  • FIG. 3 shows a computer 100 adapted to implement an access method according to the invention, and in particular in the three embodiments previously described in FIGS. 2A to 2C.
  • This computer 100 comprises, in known manner, a processor 101, a ROM-type ROM 102 and a RAM RAM 103.
  • the processor 101, the read-only memory 102 and the random access memory 103 are connected by a bus system 104.

Abstract

Ce procédé d'accès a pour but de garantir que les données d'identification (ID-CL) d'un dispositif client (20) ne sont envoyées à un dispositif serveur (40) qu'après une étape (E50) d'authentificatîon de ce serveur.

Description

Authentîfication d'un serveur avant envoi de données d'identification d'un client.
Arrière-plan de l'invention
La présente invention se rapporte au domaine général de l'accès par un dispositif client à une ressource disponible dans un dispositif serveur sur un réseau de télécommunication dans lequel l'accès à cette ressource nécessite l'envoi de données d'identification du client au serveur.
On rappelle tout d'abord les définitions suivantes :
- "identification" : étape au cours de laquelle un premier équipement ou utilisateur déclare son identité à un deuxième équipement ou utilisateur ; et
- "authentîfication" : étape au cours de laquelle le deuxième équipement vérifie l'identité déclarée par le premier équipement.
De façon connue, lorsqu'un dispositif client souhaite accéder à une ressource disponible dans un dispositif serveur, ce dispositif client s'identifie (et éventuellement s'authentifie) avant le dispositif serveur.
Mais cette technique présente un inconvénient majeur car elle impose l'envoi de données d'identification (et éventuellement d'authentification) personnelles du dispositif client à un dispositif serveur qui n'est pas encore authentifié.
Cet inconvénient est d'autant plus critique lorsque les moyens mis en œuvre par le dispositif client pour s'authentifier sont des moyens qui ne sont pas spécifiques à une application particulière.
C'est notamment le cas lorsque le dispositif client est un navigateur de type web.
En effet, lorsqu'un client web souhaite accéder à un serveur, ce dernier a la possibilité d'imposer au client web un protocole de communication et l'envoi de données personnelles d'identification et d'authentification, à savoir par exemple des cookies temporaires ou permanents.
L'homme du métier comprendra qu'il est souhaitable d'authentifier le dispositif serveur avant l'envoi de ces données personnelles notamment pour empêcher un fournisseur de service de profiter des moyens d'authentification mis en œuvre par un client pour s'authentifier auprès d'un autre fournisseur de service, sans avoir à développer des moyens d'authentification propres, ou à payer une licence d'utilisation de ces moyens.
Par ailleurs, il peut être tout à fait préjudiciable à un dispositif client de fournir ses données personnelles d'identification et d'authentification à un serveur non autorisé, car celui-ci pourrait les fournir à un tiers malintentionné, ce tiers pouvant par la suite utiliser ces données pour se faire passer pour l'utilisateur du dispositif client.
Objet et résumé de l'invention
La présente invention a pour but principal de pallier les inconvénients précités.
A cet effet, et selon un premier aspect, elle vise un procédé d'accès à un dispositif serveur, par un dispositif client souhaitant accéder à une ressource de ce serveur, cet accès nécessitant l'envoi au serveur, d'au moins une donnée d'identification du client. Ce procédé comporte :
- une étape d'envoi d'une requête d'authentification au dispositif serveur ;
- une étape d'obtention de données d'authentification du serveur ;
- une étape au cours de laquelle on vérifie, à partir des données d'authentification du serveur, si ce serveur est autorisé ou non à recevoir la donnée d'identification du client ;
- et, en fonction du résultat de l'étape de vérification, une étape d'envoi au dispositif serveur, d'une requête d'accès à la ressource et de la donnée d'identification du client.
Ainsi, conformément à l'invention, les données d'identification du client ne sont envoyées au dispositif serveur qu'après une étape d'authentification de ce serveur.
L'homme du métier comprendra que les données d'identification du client peuvent être contenues dans la requête d'accès à la ressource, ou envoyées séparément.
De façon connue, certains serveurs refusent d'envoyer leurs données d'authentification avant d'avoir identifié ou authentifié le dispositif citent qui les réclame,
L'invention permet de résoudre ce problème particulier. A cet effet, dans un mode préféré de réalisation, le procédé d'accès selon l'invention comporte en outre :
- une étape de réception, en réponse à l'envoi de la requête d'authentification du dispositif serveur, d'une requête d'obtention d'au moins une donnée d'identification du client ;
- une étape d'envoi, au dispositif serveur, de données d'identification banalisées en réponse à la requête d'obtention de la donnée d'identification du client, les données d'authentification du serveur étant obtenues en réponse à l'envoi des données d'identification banalisées.
Dans ce mode de réalisation, afin de ne pas divulguer les données d'identification du client avant d'avoir authentifié le serveur, on répond à la requête d'obtention de données du client par l'envoi de données d'identification banalisées.
Dans ce document, une "donnée banalisée" est une donnée qui ne permet ni d'identifier, ni d'authentifier le client. Il s'agit par exemple d'une donnée partagée par un groupe de clients prédéterminé.
Parfois, le dispositif serveur requiert des données d'authentification du client en plus des données d'identification précitées. L'invention permet de résoudre ce problème particulier.
A cet effet, le procédé selon l'invention comporte ;
- consécutivement à l'étape d'envoi de données d'identification banalisées, une étape d'envoi de données d'authentification banalisées ; et
- consécutivement à l'étape d'envoi de la donnée d'identification du client, une étape d'envoi de données d'authentification du client.
Ainsi, dans ce mode préféré de réalisation, on authentifie le client auprès du serveur avec des données banalisées de façon à obtenir les données d'authentification du serveur recherchées.
Lorsque le serveur est finalement reconnu comme autorisé à recevoir les données personnelles du client, on authentifie le client, avec ses propres données, auprès du serveur avant de requérir l'accès à la ressource souhaitée.
Différentes méthodes peuvent être utilisées pour authentifier le serveur.
Dans une première variante, on obtient l'identité du serveur (par exemple son adresse web) et on compare cette identité avec une liste d'identités des serveurs autorisés (liste blanche) ou avec une liste d'identités des serveurs interdits (liste noire).
Cette première variante est particulièrement facile à mettre en œuvre, mais présente un niveau assez faible de sécurité, notamment lorsque l'utilisateur du dispositif client porte au réseau de télécommunication pour accéder au serveur une confiance limitée.
Dans une deuxième variante, les données d'authentification du serveur comportent un certificat du serveur dont on vérifie la validité au cours de l'étape de vérification.
Cette deuxième variante permet de garantir l'identité du dispositif serveur, mais nécessite de recourir à un tiers de confiance pour la délivrance de ce certificat.
Dans une troisième variante, la requête d'authentification envoyée au dispositif serveur comporte un défi, et on vérifie au cours de l'étape une signature du défi reçue parmi les données d'authentification du serveur.
Ce mécanisme d'authentification forte appelé aussi mécanisme "défi-réponse" repose, dans un mode de réalisation connu, sur un algorithme cryptographique utilisant une paire de clés, et plus précisément une clé privée, du côté du serveur pour signer le défi, et une clé publique associée à la clé privée mémorisée par le dispositif d'authentification pour vérifier la validité de cette signature.
Dans un mode préféré de réalisation, le procédé d'accès selon l'invention mentionné ci-dessus est mis en œuvre dans un dispositif d'authentification.
Ce dispositif d'authentification peut ainsi obtenir et vérifier les données d'authentification du serveur avant de lui envoyer des données d'identification et/ou d'authentification du client.
Dans ce mode particulier de réalisation, le procédé d'accès selon l'invention comporte préférentiellement une étape préliminaire au cours de laquelle le dispositif d'authentification précité reçoit une requête d'accès en provenance du dispositif client.
Corrélativement, l'invention concerne également un dispositif d'authentification d'un dispositif serveur comportant une ressource à laquelle souhaite accéder un dispositif client l'accès nécessitant l'envoi au serveur d'au moins une donnée d'identification du client. Ce dispositif comporte :
- des moyens pour envoyer une requête d'authentification au dispositif serveur ;
- des moyens pour obtenir des données d'authentification du serveur ;
- des moyens pour vérifier, à partir desdites données d'authentification du serveur, si ce serveur est autorisé ou non à recevoir la donnée d'identification du client ; et,
- des moyens pour, le cas échéant, envoyer au dispositif serveur, une requête d'accès à la ressource et la donnée d'identification du client.
Dans un mode préféré de réalisation, le dispositif d'authentification est constitué par un serveur proxy placé en coupure de flux entre le dispositif client et le dispositif serveur.
Lorsque le dispositif client souhaite accéder aux ressources sur le serveur, ce serveur proxy se substitue au dispositif client pour une première authentiflcation, cette première authentification ayant pour seul but d'obtenir des données d'authentification du dispositif serveur.
Dans un autre mode préféré de réalisation, le dispositif d'authentification est incorporé dans le dispositif client.
L'invention vise aussi un terminal de télécommunication qui incorpore un dispositif client et un dispositif d'authentification tels que mentionnés brièvement ci-dessus.
Les caractéristiques particulières et les avantages du dispositif d'authentification et du terminal de télécommunication étant les mêmes que ceux du procédé mentionné ci-dessus, ils ne seront pas rappelés ici.
Selon une implémentation préférée, les différentes étapes du procédé d'authentification sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou un dispositif d'authentîfication tel que mentionné ci-dessus. Ce programme comporte des instructions adaptées à la mise en œuvre des étapes du procédé d'authentification mentionné ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une RON, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
- la figure IA représente schématiquement un dispositif de télécommunication conforme à l'invention dans un premier mode préféré de réalisation, et les différents messages échangés par ce dispositif avec un dispositif serveur et un dispositif client dans un mode préféré de réalisation ; et
- la figure IB représente schématiquement un terminal de télécommunication conforme à l'invention dans un mode préféré de réalisation et les différents messages échangés par ce terminal avec un dispositif serveur dans un mode préféré de réalisation ; - les figures 2A à 2C représentent, sous forme d'organigrammes, les principales étapes d'un procédé d'accès conforme à l'invention dans trois modes préférés de réalisation ; et
- la figure 3 représente, de façon schématique, un ordinateur adapté à mettre en œuvre un procédé d'accès conforme à l'invention.
Description détaillée de modes de réalisation
Sur la figure IA on a représenté un dispositif d'authentification 30 conforme à l'invention, un dispositif client 20 et un dispositif serveur 40.
Ces trois dispositifs sont par exemple constitués par des ordinateurs distincts reliés entre eux par un réseau de télécommunication non représenté.
En variante, le dispositif client 20 et le dispositif d'authentification 30 sont incorporés dans le même ordinateur.
Dans une autre variante, le dispositif d'authentification fait partie intégrante du dispositif client 20.
De façon connue, le dispositif client 20 est adapté à envoyer et à recevoir des requêtes au serveur 40.
Dans le mode préféré de réalisation décrit ici, le dispositif client 20 et le serveur 40 communiquent via un réseau de type Internet. Dans ce cas, le dispositif client 20 peut être constitué par un client HTTP connu de l'homme du métier.
Dans un autre mode de réalisation de l'invention, le dispositif client 20 est un client mail adapté à communiquer avec un serveur de mail 40.
Dans le mode préféré de réalisation décrit ici, le dispositif d'authentification 30 de la figure IA comporte des moyens pour mettre en œuvre le programme d'ordinateur mettant en oeuvre les principales étapes du procédé d'authentification conforme à l'invention, représentées sous forme d'organigramme à la figure 2A.
On supposera dans l'exemple décrit ici que l'utilisateur du dispositif client 20 souhaite accéder à une ressource disponible dans le serveur 40.
Dans ce document, le terme "ressource" est à comprendre au sens le plus large, l'invention s'appliquant pour tout type d'accès au dispositif serveur notamment, pour s'authentifier, rediriger une requête, demander une signature électronique, faire une demande d'exécution d'un logiciel hébergé par le serveur, requérir des ressources d'administration du dispositif client,...
Quoi qu'il en soit, on supposera ici que le dispositif client 20 envoie, au cours d'une étape ElO, une requête RACCJX à destination du dispositif d'authentification 30 pour accéder à une ressource.
Cette requête d'accès RACC_CL comporte l'adresse du dispositif client 20. Elle peut être constituée par exemple par une requête HTTP lorsque le dispositif client 20 et le dispositif d'authentification 30 sont connectés au réseau Internet.
Cette requête d'accès RACCJX est reçue par le dispositif d'authentification 30 au cours de la même étape ElO.
Cette réception est suivie par une étape E20 au cours de laquelle le dispositif d'authentification 30 envoie une requête d'authentification REQ_AUTH_SER au dispositif serveur 40.
On supposera ici que le dispositif serveur répond à cette requête d'authentification REQ_AUTH_SER en envoyer ces données d'authentification ID_SER, ces données d'authentification ID_SER étant reçues par le dispositif d'authentification 30 au cours d'une étape E40.
Dans le mode de réalisation préféré décrit ici, cette étape est suivie par une étape E50 au cours de laquelle le dispositif d'authentification 30 vérifie, à partir des données d'authentification IDJBER si le serveur 40 est autorisé ou non à recevoir les données personnelles d'identification du dispositif client 20.
Dans l'exemple décrit ici, cette vérification s'effectue en comparant l'identité ID_SER du dispositif serveur 40 avec des identités contenues dans une liste mémorisée par le dispositif d'authentification 30.
Si le dispositif serveur 40 n'est pas autorisé à recevoir les données d'authentification du dispositif client 20, l'étape E50 termine le procédé d'accès selon l'invention dans ce mode de réalisation.
En revanche, si le dispositif serveur 40 est autorisé à recevoir les données d'authentification du dispositif client 20, l'étape de vérification E50 est suivie par une étape E60 au cours de laquelle le dispositif d'authentification 30 vérifie si les données d'identification ID CL du dispositif client 20 sont contenues dans la requête d'accès RACC_CL reçue en provenance du dispositif client 20 à l'étape ElO.
Si tel est le cas, le test E60 est suivi par une étape E70 au cours de laquelle le dispositif d'authentification 30 envoie la requête d'accès RACC_CL au dispositif client 40.
Au contraire, si la requête RACC_CL ne comporte pas ces données d'identification, le dispositif d'authentification 30 demande et obtient ces données ID_CL, par exemple par l'envoi d'une requête au dispositif client 20 au cours d'une étape E80.
Cette étape d'obtention est suivie par une étape d'envoi E90, au dispositif serveur 40, de la requête d'accès RACC-CL obtenue à l'étape ElO et des données d'identification ID_CL obtenues à l'étape précédente.
Les étapes E70 et E90 d'envoi de données personnelles au dispositif serveur 40 terminent le procédé d'accès selon l'invention dans ce mode de réalisation.
On va maintenant décrire en référence à la figure 2B un procédé d'accès selon l'invention dans une deuxième variante de réalisation.
On supposera dans cette variante que le dispositif serveur 40 requiert l'obtention des données d'identification ID_CL du dispositif client 20 avant d'envoyer ses données d'authentification ID_SER.
Ainsi, plus précisément, lorsque le dispositif serveur 40 reçoit la requête d'identification REQ_AUTH_SER envoyée, par le dispositif d'authentification 30 à l'étape E20, il envoie, au dispositif d'authentification 30, une requête REQ_ID_CL pour obtenir au moins une donnée d'identification ID_CL du client 20. Cette requête d'obtention est reçue par le dispositif d'authentification 30 à l'étape E30A.
Conformément à l'invention, dans ce cas, le dispositif d'authentification 30 répond à cette requête d'obtention REQ_ID_CL par l'envoi de données d'identification banalisées ID-COMM (étape E35).
Sur réception de ces données banalisées, le dispositif serveur 40 renvoie, comme décrit précédemment, ces données d'authentification ID_SER au cours de l'étape E40.
Le procédé d'accès dans ce deuxième mode de réalisation se termine comme le procédé d'accès décrit précédemment en référence à la figure 2A, Nous allons maintenant décrire, en référence à la figure 2C, un procédé d'accès selon l'invention dans une troisième variante de réalisation.
Nous supposerons ici que le dispositif serveur 40 demande non seulement des données d'identification du client 20 mais aussi des données d'authentification de ce client.
Dans ce mode de réalisation, lorsque le dispositif serveur 40 reçoit la requête d'authentification REQ_AUTH_SER envoyée par le dispositif d'authentification 30 à l'étape E20, il répond à cette requête par l'envoie d'une requête REQ_ID_AUTH_CL pour obtenir des données d'authentification et d'identification du dispositif client 20.
Conformément à l'invention, sur réception de cette requête d'obtention REQJD_AUTH_CL, le dispositif d'authentification 30 envoie au cours de l'étape E35 déjà décrite des données d'identification ID_COMM banalisées au dispositif serveur 40.
Cette étape E35 d'envoi de données d'identification banalisées est suivie par une étape E37 au cours de laquelle le dispositif d'authentification 30 envoie des données d'authentification banalisées AUThLCOMM au dispositif serveur 40.
Sur réception de ces données d'authentification AUTH_COMM et d'identification IDJZOMM, le dispositif serveur 40 fournit ses données d'authentification ID__SER au dispositif d'authentification 30.
L'homme du métier comprendra que dans ce mode de réalisation, le dispositif client 20 doit s'authentifier avec ses données propres auprès du dispositif serveur 40 pour accéder à la ressource recherchée.
A cet effet, si le dispositif serveur 40 est un dispositif autorisé à recevoir ses données personnelles, le dispositif d'authentification 30 vérifie au cours d'une étape E60B s'il possède ou non les données d'identification IC_CL et d'authentification AUTH-CL du dispositif client 20, ces données ayant par exemple été reçues dans la requête d'accès RACC-CL à l'étape ElO.
Si tel est le cas, !e dispositif d'authentification 30 envoie, au cours de l'étape E70 déjà décrite, la requête client RACC-CL au dispositif serveur 40, cette étape étant suivie par une étape E75 d'envoi des données d'authentification AUTH_CL du dispositif client 20 au dispositif serveur 40.
Lorsque le dispositif d'authentification 30 ne connaît pas au moins l'une des données d'identification ID_CL et d'authentification AUTH_CL du dispositif client 20, l'étape E60B est suivie par une étape E80B d'obtention de ces données manquantes auprès du client 20.
Cette étape d'obtention est suivie par l'étape E90 déjà décrite au cours de laquelle le dispositif d'authentification 30 envoie la requête d'accès et les données d'identification du client 20 au dispositif serveur 40.
Cette étape d'envoi est suivie par une étape E95B au cours de laquelle le dispositif d'authentification 30 envoie les données d'authentification AUTH-CL du client 20 au dispositif serveur 40.
Nous allons maintenant décrire en référence à la figure IB un terminal 10 conforme à l'invention dans un mode préféré de réalisation.
Ce terminal 10 comporte un dispositif client 20, un dispositif d'accès conforme à l'invention adapté à mettre en œuvre une variante conforme à l'invention du procédé d'accès décrit en référence à la figure 2C.
En effet, dans ce mode préféré de réalisation, le dispositif d'authentification 30 comporte une mémoire 50 dans laquelle sont stockées les données d'identification ID_CL et d'authentification AUTH_CL du dispositif client 20.
Cette mémoire 50 peut par exemple être constituée par une carte à puce adaptée à générer un défi envoyé au dispositif serveur 40 au cours de l'étape E20 précédemment décrite et des moyens de calcul adaptés à vérifier une signature de ce défi reçue à l'étape E40 parmi les données d'authentification ID_SER du serveur 40.
Dans un mode préféré de mise en œuvre de l'invention, le dispositif d'authentification 30 selon l'invention est incorporé dans un serveur proxy placé en coupure de flux entre le client 20 et le serveur 40. Ce serveur proxy est ainsi adapté, de façon connue, à intercepter une requête d'accès envoyée par Ie client 20 au serveur 40, et à mettre en œuvre Ie procédé d'accès selon l'invention pour vérifier que le serveur 40 est autorisé à recevoir les données d'identification et d'authentification du client 20 avant la transmission de cette requête. Sur la figure 3, on a représenté un ordinateur 100 adapté à mettre en œuvre un procédé d'accès conforme à l'invention, et notamment dans les trois modes de réalisation décrits précédemment aux figures 2A à 2C.
Cet ordinateur 100 comporte de façon connue un processeur 101, une mémoire morte de type ROM 102 et une mémoire vive de type RAM 103.
Le processeur 101, la mémoire morte 102 et la mémoire vive 103 sont reliés par un système de bus 104.

Claims

REVENDICATIONS
1. Procédé d'accès à un dispositif serveur (40), par un dispositif client (20) souhaitant accéder à une ressource de ce serveur (40), ledit accès nécessitant l'envoi (E70, E80) au serveur (40), d'au moins une donnée d'identification (ID_CL) du client (20), ce procédé étant caractérisé en ce qu'il comporte :
- une étape (E20) d'envoi d'une requête d'authentification (REQ_AUTH_SER) au dispositif serveur (40) ;
- une étape (E40) d'obtention de données d'authentification (ID_SER) du serveur (40) ;
- une étape (E50) au cours de laquelle on vérifie, à partir desdites données d'authentification (ID_SER) du serveur (40), si ce serveur (40) est autorisé ou non à recevoir ladite au moins une donnée d'identification (ID_CL) du client (20) ;
- et, en fonction du résultat de ladite étape (E50) de vérification, une étape (E70, E90) d'envoi au dispositif serveur (40), d'une requête (RACC_CL) d'accès à ladite ressource et de ladite au moins une donnée d'identification (ID_CL) du client (20).
2. Procédé d'accès selon la revendication 1, caractérisé en ce qu'il comporte en outre :
- une étape (E30A, E30B) de réception, en réponse à l'envoi (E20) de la requête d'authentification (REQ_AUTH_SER) du dispositif serveur (40), d'une requête (REQJDJX, REQ_ID_AUTH_CL) d'obtention d'au moins une donnée d'identification (ID_CL) dudit client (20) ;
- une étape (E35) d'envoi, au dispositif serveur (40), de données d'identification banalisées (ID-COMM) en réponse à ladite requête (REQ_ID_CL, REQ_ID_AUTH_CL) d'obtention de la donnée d'identification (ID_CL) dudit client (20), lesdites données d'authentification (ID_SER) du serveur (40) étant obtenues (E40) en réponse à l'envoi (E35) desdites données d'identification banalisées (IDJZQMM).
3. Procédé d'accès selon Ia revendication 2, dans lequel ladite requête d'obtention (REQ_ID_Airmj:L) reçue (E30B) en réponse à l'envoi (E20) de Ia requête d'authentification (REQ_AUTH_SER) du dispositif serveur (40), constitue aussi une requête d'authentification dudit client (20), caractérisé en ce qu'il comporte :
- consécutivement à ladite étape (E35) d'envoi de données d'identification banalisées (IDJX)MM), une étape (E37) d'envoi de données d'authentification banalisées (AUThLCOMM) ; et
- consécutivement à ladite étape (E70, E90) d'envoi de ladite au moins une donnée d'identification (ID_CL) du client (20), une étape (E85) d'envoi de données d'authentification (AUTH_CL) dudit client (20).
4. Procédé d'accès selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, au cours de ladite étape (E50) de vérification, on compare lesdites données d'authentification (ID_SER) du serveur (40) avec une liste d'identités de serveurs autorisés ou interdits.
5. Procédé d'accès selon l'une quelconque des revendications 1 à 3, caractérisé en que lesdites données d'authentification (ID_SER) du serveur (40) comportent un certificat dudit serveur (40) dont on vérifie la validité au cours de ladite étape de vérification (E50).
6. Procédé d'accès selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite requête d'authentification (REQ_AUTH_SER) envoyée (E20) au dispositif serveur (40) comporte un défi, et en ce que, on vérifie, au cours de ladite étape (E50) une signature dudit défi reçue (E40) parmi lesdites données d'authentification (ID_SER) du serveur (40).
7. Procédé d'accès selon l'une quelconque des revendications 1 à 6, mis en œuvre dans un dispositif d'authentification (30) pour obtenir (E40) et vérifier (E50) des données d'authentification (IDJSER) du serveur (40) avant de lui envoyer (E70, E90) des données d'identification (IDJl) du dispositif client (20), ce procédé étant caractérisé en ce qu'il comporte en outre une étape préliminaire (EiO) de réception, par ledit dispositif d'authentification (30) d'une requête d'accès (RACCLCl) en provenance dudit client (20).
8. Dispositif (30) d'authentification d'un dispositif serveur (40) comportant une ressource à laquelle souhaite accéder un dispositif client ledit accès nécessitant l'envoi (E70, E80) au serveur (40), d'au moins une donnée d'identification (ID_CL) du client (20), ce dispositif (30) étant caractérisé en ce qu'il comporte :
- des moyens pour envoyer (E20) une requête d'authentification (REQ_AUTH_SER) au dispositif serveur (40) ;
- des moyens pour obtenir (E40) des données d'authentification (ID_SER) du serveur (40) ;
- des moyens pour vérifier (E50), à partir desdites données d'authentification (ID_SER) du serveur (40), si ce serveur (40) est autorisé ou non à recevoir ladite au moins une donnée d'identification (ID_CL) du client (20) ;
- et, des moyens (E70, E90) pour, le cas échéant, envoyer au dispositif serveur (40), une requête (RACC_CL) d'accès à ladite ressource et ladite au moins une donnée d'identification (ÏD_CL) du client (20).
9. Terminal de télécommunication (10) caractérisé en ce qu'il incorpore un dispositif client (20) et un dispositif d'authentification (30) selon la revendication 8.
10. Programme d'ordinateur comportant des instructions pour l'exécution des étapes du procédé d'accès selon l'une quelconque des revendications 1 à 7 lorsque ledit programme est exécuté par un ordinateur.
11. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé d'accès selon l'une quelconque des revendications 1 à 7.
EP06778956A 2005-06-20 2006-06-19 Authentification d'un serveur avant envoi de donnees d'identification d'un client Withdrawn EP1894342A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0506209 2005-06-20
PCT/FR2006/050610 WO2006136750A2 (fr) 2005-06-20 2006-06-19 Authentification d'un serveur avant envoi de donnees d'identification d'un client

Publications (1)

Publication Number Publication Date
EP1894342A2 true EP1894342A2 (fr) 2008-03-05

Family

ID=35045127

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06778956A Withdrawn EP1894342A2 (fr) 2005-06-20 2006-06-19 Authentification d'un serveur avant envoi de donnees d'identification d'un client

Country Status (2)

Country Link
EP (1) EP1894342A2 (fr)
WO (1) WO2006136750A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3053814B1 (fr) * 2016-07-11 2021-11-12 Oberthur Technologies Procede de controle d'un dispositif electronique pour traiter une transaction

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
MXPA02002018A (es) * 1999-08-31 2002-09-18 Ericsson Telefon Ab L M Seguridad dce gsm para redes de datos por paquete.
US20050254652A1 (en) * 2002-07-16 2005-11-17 Haim Engler Automated network security system and method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006136750A2 *

Also Published As

Publication number Publication date
WO2006136750A2 (fr) 2006-12-28
WO2006136750A3 (fr) 2007-05-03

Similar Documents

Publication Publication Date Title
EP3008872B1 (fr) Procédé d'authentification d'un terminal par une passerelle d'un réseau interne protégé par une entité de sécurisation des accès
EP1909462B1 (fr) Procédé de mise à disposition cloisonnée d'un service électronique
EP3085133B1 (fr) Système et procédé pour fournir un service a l'utilisateur d'un terminal mobile
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
US20210226794A1 (en) Access control using proof-of-possession token
EP2912818B1 (fr) Procede d'authentification mutuelle entre un terminal et un serveur distant par l'intermediaire d'un portail d'un tiers
FR3053203A1 (fr) Technique de telechargement d'un profil d'acces a un reseau
FR2987529A1 (fr) Procede de verification d'identite d'un utilisateur d'un terminal communiquant et systeme associe
WO2012131268A1 (fr) Authentification forte par presentation du numero
FR2964812A1 (fr) Procede d'authentification pour l'acces a un site web
EP1400056B1 (fr) Procede d'authentification cryptographique
FR3050348A1 (fr) Procede d'obtention par un terminal mobile d'un jeton de securite
FR3081654A1 (fr) Procede, dispositif et serveur de distribution securisee d'une configuration a un terminal
EP3219077B1 (fr) Procédé et système de gestion d'identités d'utilisateurs destiné à être mis en oeuvre lors d'une communication entre deux navigateurs web
WO2013034865A1 (fr) Procede d'authentification
EP1894342A2 (fr) Authentification d'un serveur avant envoi de donnees d'identification d'un client
WO2019053376A1 (fr) Accès à un service avec authentification basée sur un terminal mobile
EP3732852B1 (fr) Procédé d'authentification à l'aide d'un terminal mobile utilisant une clé et un certificat stockés sur un support externe
CN113824691A (zh) 一种移动端第三方h5应用静默登录策略实现方法
FR3053549A1 (fr) Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants.
FR2975518A1 (fr) Procede de securisation d'une architecture d'authentification, dispositifs materiels et logiciels correspondants
FR2961328A1 (fr) Dispositif et procede de securisation de l'acces a une fonction
FR2943482A1 (fr) Procede et systeme de securisation de demandes applicatives
EP3820112A1 (fr) Procédé de configuration d accès à un service internet
EP3643035A1 (fr) Procédé de contrôle de l'obtention par un terminal d'un fichier de configuration

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20071217

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20100517

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20120103