WO2012107369A1 - Procede et dispositif de connexion a un service distant depuis un dispositif hote - Google Patents

Procede et dispositif de connexion a un service distant depuis un dispositif hote Download PDF

Info

Publication number
WO2012107369A1
WO2012107369A1 PCT/EP2012/051896 EP2012051896W WO2012107369A1 WO 2012107369 A1 WO2012107369 A1 WO 2012107369A1 EP 2012051896 W EP2012051896 W EP 2012051896W WO 2012107369 A1 WO2012107369 A1 WO 2012107369A1
Authority
WO
WIPO (PCT)
Prior art keywords
security device
authentication
browser
page
user
Prior art date
Application number
PCT/EP2012/051896
Other languages
English (en)
Inventor
Cyrille Pepin
François LECOCQ
Original Assignee
Morpho
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 Morpho filed Critical Morpho
Publication of WO2012107369A1 publication Critical patent/WO2012107369A1/fr

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/0853—Network 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
    • 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/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan

Definitions

  • the present invention relates to the field of computer security and more specifically the field of protection of confidential personal information allowing encrypted access to a remote service.
  • Fig. 1 illustrates the architecture of the network.
  • the user typically uses a host device 1.1 such as a personal computer or any similar device such as a personal assistant or smartphone ⁇ smartphone in English).
  • This host device is connected to an information exchange network 1.2, typically the Internet network.
  • an information exchange network 1.2 typically the Internet network.
  • On this network are also connected 1.3 servers hosting remote services. The user can therefore access from his host device to services hosted on 1.3 servers via the information exchange network 1.2.
  • This securing generally involves providing the user with secret connection information that he must produce to establish the connection to the service. Typically this is an associated username and password. Upon login, the user is asked to enter this name and password which are used to authenticate and establish an encrypted connection to ensure the confidentiality of information exchanges between the user and the user. user and the remote service. It is common to secure these exchanges of connection information to prevent them from being stolen during transport between the host device and the server. This securing is typically done by creating an encrypted connection or an encrypted tunnel between the host device and the server.
  • This encrypted connection or tunnel can, for example, be created using the SSL (Secure Socket Rent) protocol, or its successor TLS (Transport Loyer Security in English).
  • Fig. 2 illustrates the use of these techniques.
  • the host device sends a connection request 2.1, usually using its Internet browser to the server hosting the service. This request is not encrypted. It is interpreted by the server during a step 2.2 which responds with the message 2.3 comprising a public key corresponding to the certificate identifying the server or service.
  • the host device determines a pseudo-random symmetric key in a step 2.4. It encrypts it using the public key of the server received in the message 2.3 and sends it to the server in the message 2.5.
  • this method makes it possible to secure exchanges between the host device and the server.
  • the data exchanged are handled in clear by the server and the terminal. It is assumed a priori that the server is safe because of management by professionals. On the other hand, the security of the host device is problematic.
  • the invention aims to solve the above problems using a security device connectable to the host device.
  • This security device is in charge of the security of the transaction. It relies advantageously on a chip card component which stores the list of accessible services and the associated authentication credits.
  • the browser used to connect with the remote service obtains the list of services and then the authentication credit corresponding to a chosen service. The connection to the service is then done using the authentication credit provided by the security device.
  • a method of connecting to a remote service from a host device that includes a step of authenticating the user to a security device connected to the host device; a step of obtaining a list of remote services from said security device; a step of choosing a service from the list of remote services obtained; a step of connecting and authenticating the user to the chosen remote service using an authentication credit stored in said security device.
  • the method further comprises a step of loading an authentication page available on said security device in a browser launched on the host device; a step of entering authentication parameters in said authentication page; a step of validating said authentication parameters by said security device.
  • the authentication of the user to said security device comprises a step of authenticating a biometric parameter of the user by a biometric sensor integrated with said security device.
  • the step of obtaining a list of remote services comprises a step of loading into a browser launched on the host device of a page available on said security device, said page comprising a list of links on said remote services.
  • the step of connecting and authenticating the user to the selected remote service comprises within a browser:
  • the step of connection to the remote service comprises a step of loading a page available in said security device, said page comprising a first frame dedicated to the communication with the remote service and a second frame dedicated to communication with said security device when said page is loaded into a browser launched on the host device.
  • connection and communication step with said security device is done according to a particular protocol implemented within the browser and the device.
  • the authentication credit is transmitted from the security device to the browser in the form of a data page.
  • the authentication credit is transmitted from the security device to the browser in the form of a sequence of codes simulating the pressing of the keys of a keyboard.
  • the method further comprises a prior step of loading the browser used for the connection from a storage memory of said security device.
  • the method further comprises a step of encryption / decryption of at least a portion of the data exchanged between the browser and the remote service made by said security device.
  • the invention also relates to a security device connectable to a host device for the secure connection to a remote service, which comprises a chip card component for the secure storage of authentication credits and cryptographic calculations; a communication protocol stack for communicating with the host device; a list of remote services with the addresses of these services and the authentication credits of the user with these services;
  • means for authenticating a user means for transmitting to the host device the list of remote services; means for transmitting to the host device the authentication credit of a chosen service.
  • the device further comprises an authentication page that makes it available from a browser launched on the host device and means for validating authentication parameters entered by a user. using said authentication page.
  • the device further comprises a biometric sensor for the authentication of the user.
  • the device further comprises a page available on said security device, said page comprising a list of links on said remote services.
  • the device further comprises a page available in said security device, said page comprising a first frame dedicated to the communication with the remote service and a second frame dedicated to the communication with said device when said page is loaded into a browser launched on the host device.
  • the device further comprises means for communicating with the host device according to a particular protocol.
  • the device further comprises means for transmitting to the host device a sequence of codes simulating the support on the keys of a keyboard.
  • the device further comprises a storage memory for storing the browser intended to be used for connection to the remote service from the host device.
  • the device further comprises means for encrypting / decrypting at least part of the data exchanged between the remote service and the browser.
  • Fig. 1 illustrates the architecture of the network.
  • Fig. 2 illustrates an example of connection to a secure service according to the prior art.
  • Fig. 3 illustrates the principle architecture of an exemplary embodiment of the invention.
  • Figs. 4a and 4b illustrate the protocol architecture of two exemplary embodiments of the invention.
  • Fig. 5 illustrates the process of using a secure service according to an exemplary embodiment of the invention.
  • the weak point from the point of view of security is the terminal of the user. Indeed, the user is rarely aware of the security rules to guard against contamination of the post by malware. In particular, it is not uncommon for the user terminal to be invaded by software such as computer viruses or spyware. Some of these malware, once operational on the terminal, are able to spy on the actions of the user and take note of the potentially confidential information of the latter. Sensitive confidential information may include information allowing the user to connect to secure remote services such as the site of his bank, e-commerce sites or other. Once in possession of this sensitive data, these malicious software may use the network connection of the post to send this sensitive information to third parties who may use it fraudulently.
  • Fig. 3 illustrates the architecture of an exemplary embodiment of the invention.
  • This example shows a host device 3.1.
  • This host device is typically a personal computer or any type of information processing system such as a personal organizer (PDA in English), smartphone ⁇ smartphone in English), or other.
  • PDA personal organizer
  • This host device is provided with communication capabilities with a data communication network, typically the Internet. This network allows him to connect using a browser software or browser 3.2 to a remote service 3.3.
  • a security device 3.4 is connected to the host device. This connection can be done according to various communication protocols.
  • the exemplary embodiment is based on a USB connection ⁇ Universal Serial Bus in English).
  • the security device is then like a USB stick connectable to the host device.
  • the security feature contains features that go well beyond a simple USB key. It includes means 3.5 for securely storing authentication credits for connection to at least one remote service.
  • authentication credit a data set that allows a user to authenticate with a remote service.
  • This data set may for example consist of a pair of login name and password, a solution widely used for authentication to remote services. Any other solution can also be used here, such as a digital certificate that offers more security than a name and password.
  • these authentication credits are stored in a chip card component that offers the advantage of offering a component whose security is proven.
  • a chip card component also has encryption and decryption means that can also be used for cryptographic calculations during communications between the host device and the remote service if necessary.
  • the device can also advantageously have a mass memory 3.6.
  • This mass memory can then store service for example a version of the browser 3.2 dedicated to communication with the remote service.
  • This browser will then typically be adapted to integrate communication protocols with the security device when executed by the host device.
  • the device can also advantageously have a module 3.7 simulating the operation of a keyboard when connected to the host device.
  • this module simulates a USB compatible keyboard and is therefore compliant with the HID protocol (Human Interface Device in English) that normalizes the operation of the USB output input devices.
  • This module allows the sending of code sequences simulating the keyboard entry of a name and a password in some embodiments of the invention.
  • the security device when connected to a host device, appears to it as a triple device.
  • a mass storage device such as a standard USB key thanks to the mass memory module 3.6.
  • a security module 3.5 with which the host device can communicate.
  • a keyboard connected through the keyboard simulation module 3.7.
  • the security module 3.5 communicates with the host device such as an independent host accessible on the local network of the host device. For this purpose, it implements a stack 4.1 of complete communication protocols such as the stack illustrated in FIG. 4a.
  • the RNDIS protocol 4.6 Remote Network Driver Interface Specification in English
  • the IP 4.5 protocol is focused on RNDIS. It supports the TCP 4.4 control layer.
  • TCP connections can be secured by the Transport Layer Security (TLS) layer to, among other things, enable HTTP (Hyper Text Transport Protocol) requests.
  • TLS Transport Layer Security
  • HTTP Hyper Text Transport Protocol
  • the safety device is therefore seen with regard to security module as a WEB server accessible on the local network of the host device.
  • the IP to HTTP layers can be replaced by a proprietary protocol with the same function, see Fig. 4b.
  • Fig. 5 illustrates the typical operation of a connection according to the invention.
  • the user connects the security device to the host device. He must then launch the browser to access on the one hand the list of services and then to the services themselves. According to a first embodiment, it launches the browser available on the host device. This poses the problem that this browser is not safe, it may have been infected by spyware or other.
  • the mass memory module 3.6 is seen by the operating system of the host as a USB key.
  • this memory is read-only and then offers a version of the browser to the user. It is then this browser saved in a write-protected space that is launched by the user.
  • a step 5.2 the user is prompted to authenticate with the security appliance.
  • This authentication is intended to prevent the use of the device by an unauthorized person.
  • this device is used to secure access to a set of services for a user and must therefore be used only by it.
  • This authentication can be done by various means.
  • a first embodiment uses authentication by login name and password. The user connects to the WEB server hosted by the security appliance and loads an authentication page. He enters his login name and password. The device validates authentication and, if it is valid, it unlocks the security device to allow its use.
  • the device integrates a biometric sensor, for example a fingerprint reader, but any other sensor can be used as an iris reader or other. The authentication of the user is then made using this biometric sensor.
  • the security device implements authentication protocols such as TLS or RADIUS (Remote Authentication Dial In User Service).
  • a step 5.3 the user obtains the list of available services offered by the security device.
  • This list can be reduced to a single service.
  • this list is provided in the form of a WEB page served by the WEB server embedded on the security device.
  • Another protocol can be used to transmit this list of the security device to the host device.
  • a service access link typically a WEB address.
  • This list is submitted to the user who can then choose one of the services from the list during a step 5.4.
  • This choice causes the initialization of a connection process to the selected service.
  • These services being typically secure, the initialization begins with a step of authentication of the user with the chosen service.
  • the user To perform this authentication, the user must obtain from the security device the authentication credit associated with the service. This credit is typically associated with it. It is stored in the device within the security module, typically a chip card component.
  • the browser is a standard browser that can be the usual browser of the user on the security device.
  • a page is made available on the security device for access to the service.
  • This page includes two frames (frames in English).
  • a first frame is called a service frame and serves as the connection between the browser and the remote service. It is this framework that is visible to the user. This frame corresponds to the usual window for accessing a remote service.
  • a second frame called security framework, is used for communication between the browser and the security device.
  • This framework implements a communication script with the device. It is typically not visible in the browser window.
  • the communication between the security framework and the security device can be done for example in HTTP with the WEB server of the device.
  • the communication is encrypted, for example by using the HTTPS protocol or by a proprietary protocol.
  • This security framework also communicates with the service framework.
  • the service framework When connecting to the remote service, the service framework loads the authentication page to the remote service. When this loading is complete, it warns the security framework. The latter then requires the authentication credit with the security device, typically a login name and a password. when has received them, he fills the appropriate fields of the service frame with the information transmitted. The user validates these fields and authentication can then take place in the usual way.
  • the transmission of the authentication credits of the security device to the host device is made by the module 3.7 for simulating a keyboard.
  • the login name and password are then sent to the service frame as a sequence of codes simulating the pressing of the corresponding keys on the keyboard.
  • the type of operating system is detected by the security device by means of the HTTP headers of requests made by the browser to the security device. Indeed, the code sequences are dependent on the operating system of the host device.
  • use is made of one-time passwords generated by the token.
  • the use of the keyboard simulation module gives the user some control over what the security device does.
  • the one-time password generation function can be triggered by pressing a button on the security device, then it is possible for the user to generate this type of password when the desire. It can also be used to prevent the expiration of a remote service page by simulating an activity in the form of a key press. It can still be used to log off or restart the host computer as needed.
  • This embodiment offers the advantage of allowing the use of an unmodified browser at the cost of a page integrating the two appropriately programmed frames available on the security device.
  • the browser is modified to integrate natively in its code a communication module with the security device.
  • the choice of protocols between the browser and the security device is free. It is then allowed to secure this protocol. You can also ease communication by developing a lighter communication protocol stack because you have control over both parties. However, it is no longer possible to use an unmodified browser. It is therefore necessary that the modified browser is accessible to the user.
  • it is made available in the memory module of the security device.
  • This embodiment is related to the protocol stack in the device illustrated in FIG. 4b. Whatever the embodiment used to transmit the authentication credit to the browser, when it has it, it can perform step 5.6 of connection to the service. The communication is then carried out in a conventional manner between the remote service and the browser. Only the authentication has been secured by the security device. The user can use the service, step 5.7.
  • all or part of the communication between the remote service and the browser is encrypted. It can be a partial encryption of the most sensitive data or the total encryption of the communication, it is called a secure tunnel between the browser and the service.
  • this encryption is performed by the security device using encryption credits which will remain stored within the security module of said security device.
  • the exchange of the data to be encrypted or decrypted by the security device is then supported either by the security framework or by the module that manages the communication with the security device according to the adopted embodiment.
  • a disconnection step 5.8 This step can be triggered by the user through the browser interface or by disconnecting the security device from the host device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

Dans le domaine de la sécurité informatique et plus précisément le domaine de la protection des informations personnelles confidentielles permettant l'accès chiffré à un service distant est décrit un dispositif de sécurité connectable au dispositif hôte. Ce dispositif de sécurité est en charge de la sécurité de la transaction. Il repose avantageusement sur un composant de carte à puce qui stocke la liste des services accessibles ainsi que les crédits d'authentification associés. Le navigateur servant à la connexion avec le service distant obtient la liste des services puis le crédit d'authentification correspondant à un service choisi. La connexion au service se fait alors en utilisant le crédit d'authentification fourni par le dispositif de sécurité.

Description

Procédé et dispositif de connexion à un service distant depuis un dispositif hôte
La présente invention concerne le domaine de la sécurité informatique et plus précisément le domaine de la protection des informations personnelles confidentielles permettant l'accès chiffré à un service distant.
Aujourd'hui, grâce au développement important du réseau Internet, l'utilisateur peut accéder à un nombre grandissant de services dits « en ligne ». La plupart de ces services nécessitent une authentification de l'utilisateur pour lui permettre l'accès à des données qui le concernent. On peut citer comme exemple de tels services, l'accès aux données de son compte bancaire, le suivi de ses opérations de remboursement de prestations médicales ou encore la déclaration d'impôts en ligne.
La Fig. 1 illustre l'architecture du réseau. L'utilisateur utilise typiquement un dispositif hôte 1.1 tel qu'un ordinateur personnel ou tout dispositif similaire tel qu'un assistant personnel ou un téléphone intelligent {smartphone en anglais). Ce dispositif hôte est connecté à un réseau d'échange d'informations 1.2, typiquement le réseau Internet. Sur ce réseau sont également connectés des serveurs 1.3 hébergeant les services distants. L'utilisateur peut donc accéder depuis son dispositif hôte aux services hébergés sur les serveurs 1.3 par l'intermédiaire du réseau d'échange d'informations 1.2.
Nombre de ces services traitent d'informations confidentielles et il est important de sécuriser l'accès à ces services. Cette sécurisation passe généralement par la mise à disposition de l'utilisateur d'informations de connexion secrètes qu'il doit produire pour établir la connexion au service. Typiquement il s'agit d'un nom d'utilisateur et d'un mot de passe associé. Lors de la connexion, l'utilisateur se voit demander d'entrer ce nom et ce mot de passe qui servent à l'authentification et à l'établissement d'une connexion chiffrée permettant d'assurer la confidentialité des échanges d'informations entre l'utilisateur et le service distant. Il est courant de sécuriser ces échanges d'informations de connexion pour éviter qu'elles puissent être dérobées lors de leur transport entre le dispositif hôte et le serveur. Cette sécurisation se fait typiquement par la création d'une connexion chiffrée ou d'un tunnel chiffré entre le dispositif hôte et le serveur. Cette connexion chiffrée ou tunnel peut, par exemple, être créé en utilisant le protocole SSL (Secure Socket Loyer en anglais), ou son successeur TLS {Transport Loyer Security en anglais). La Fig. 2 illustre l'utilisation de ces techniques. Le dispositif hôte envoie une requête en connexion 2.1, généralement à l'aide de son navigateur Internet au serveur hébergeant le service. Cette requête n'est pas chiffrée. Elle est interprétée par le serveur lors d'une étape 2.2 qui répond par le message 2.3 comportant une clé publique correspondant au certificat identifiant le serveur ou le service. Le dispositif hôte détermine une clé symétrique pseudo aléatoire lors d'une étape 2.4. Il la chiffre à l'aide de la clé publique du serveur reçue dans le message 2.3 et il l'envoie au serveur dans le message 2.5. Seul le serveur est à même de déchiffrer cette clé symétrique à l'aide de sa clé privée associée à sa clé publique. Il effectue ce déchiffrement lors de l'étape 2.6. A ce moment, le dispositif hôte et le serveur partagent une même clé secrète, la clé symétrique et sont donc à même d'établir une connexion chiffrée 2.7 à l'aide de cette clé partagée. Cette connexion chiffrée permet ensuite l'échange d'informations entre le dispositif hôte et le serveur de manière sécurisée. Toutes les données échangées sont chiffrées à l'aide de la clé secrète partagée et ne sont donc déchiffrables que par les deux extrémités de la connexion chiffrée, le dispositif hôte et le serveur, qui partagent le même secret.
On voit que ce procédé permet de sécuriser les échanges entre le dispositif hôte et le serveur. Par contre, les données échangées sont manipulées en clair par le serveur et le terminal. On suppose a priori que le serveur est sûr du fait d'une gestion par des professionnels. Par contre, la sécurité du dispositif hôte pose problème.
En effet, les utilisateurs sont rarement au fait des techniques permettant d'assurer la sécurité d'un poste de traitement de l'information. De plus, il est extrêmement difficile d'obtenir de leur part un strict respect des règles de sécurité. Il n'est pas rare que le dispositif hôte de l'utilisateur soit infecté par des virus, des logiciels espions ou tout type de logiciels malicieux (malware en anglais). Ces logiciels malicieux sont susceptibles de découvrir les informations confidentielles manipulées par le dispositif hôte et de les envoyer à des tiers pouvant en faire un mauvais usage. Et ceci, même lorsque des techniques de sécurité comme celles précédemment décrites sécurisent le lien entre le dispositif hôte et le serveur. Il s'avère que le point faible du système, en ce qui concerne la sécurité, est le dispositif hôte de l'utilisateur. L'utilisateur peut également être vu comme un point faible de sécurité du fait, par exemple, d'un choix de mot de passe simple, peu robuste ou d'une communication volontaire ou non de celui-ci à une personne malveillante.
Ces problèmes de sécurité posent un réel problème au développement des services en ligne. Ils provoquent des préjudices importants pour les acteurs économiques de ce secteur et pour les utilisateurs.
L'invention vise à résoudre les problèmes précédents à l'aide d'un dispositif de sécurité connectable au dispositif hôte. Ce dispositif de sécurité est en charge de la sécurité de la transaction. Il repose avantageusement sur un composant de carte à puce qui stocke la liste des services accessibles ainsi que les crédits d'authentification associés. Le navigateur servant à la connexion avec le service distant obtient la liste des services puis le crédit d'authentification correspondant à un service choisi. La connexion au service se fait alors en utilisant le crédit d'authentification fourni par le dispositif de sécurité.
L'invention concerne un procédé de connexion à un service distant depuis un dispositif hôte qui comprend une étape d'authentification de l'utilisateur auprès d'un dispositif de sécurité connecté sur le dispositif hôte ; une étape d'obtention d'une liste de services distants auprès dudit dispositif de sécurité ; une étape de choix d'un service parmi la liste de services distants obtenue ; une étape de connexion et d'authentification de l'utilisateur auprès du service distant choisi à l'aide d'un crédit d'authentification stocké dans ledit dispositif de sécurité. Selon un mode particulier de réalisation de l'invention, le procédé comprend en outre une étape de chargement d'une page d'authentification disponible sur ledit dispositif de sécurité dans un navigateur lancé sur le dispositif hôte ; une étape d'entrée de paramètres d'authentification dans ladite page d'authentification ; une étape de validation desdits paramètres d' authentification par ledit dispositif de sécurité.
Selon un mode particulier de réalisation de l'invention, l'authentification de l'utilisateur auprès dudit dispositif de sécurité comprend une étape d'authentification d'un paramètre biométrique de l'utilisateur par un capteur biométrique intégré audit dispositif de sécurité.
Selon un mode particulier de réalisation de l'invention, l'étape d'obtention d'une liste de services distants comprend une étape de chargement dans un navigateur lancé sur le dispositif hôte d'une page disponible sur ledit dispositif de sécurité, ladite page comprenant une liste de liens sur lesdits services distants.
Selon un mode particulier de réalisation de l'invention, l'étape de connexion et d'authentification de l'utilisateur auprès du service distant choisi comprend au sein d'un navigateur :
- une étape de connexion avec ledit dispositif de sécurité;
- une étape de connexion au service distant ;
- une étape de communication au service distant de crédit d'authentification obtenu dudit dispositif de sécurité ;
Selon un mode particulier de réalisation de l'invention, l'étape de connexion au service distant comprend une étape de chargement d'une page disponible dans ledit dispositif de sécurité, ladite page comprenant un premier cadre dédié à la communication avec le service distant et un second cadre dédié à la communication avec ledit dispositif de sécurité lorsque ladite page est chargée dans un navigateur lancé sur le dispositif hôte.
Selon un mode particulier de réalisation de l'invention, l'étape de connexion et de communication avec ledit dispositif de sécurité est faite selon un protocole particulier implémenté au sein du navigateur et du dispositif.
S el on un mode parti culi er de réali sati on de l ' invention, le crédit d'authentification est transmis du dispositif de sécurité au navigateur sous la forme d'une page de données. S el on un m ode particulier de réalisation de l'invention, le crédit d'authentification est transmis du dispositif de sécurité au navigateur sous la forme d'une séquence de codes simulant l'appui sur les touches d'un clavier.
Selon un mode particulier de réalisation de l'invention, le procédé comprend en outre une étape préalable de chargement du navigateur utilisé pour la connexion depuis une mémoire de stockage dudit dispositif de sécurité.
Selon un mode particulier de réalisation de l'invention, le procédé comprend en outre une étape de chiffrement/déchiffrement d'au moins une partie des données échangées entre le navigateur et le service distant faite par ledit dispositif de sécurité.
L'invention concerne également un dispositif de sécurité connectable à un dispositif hôte pour la connexion sécurisée à un service distant, qui comprend un composant de carte à puce pour le stockage sécurisé de crédits d'authentification et les calculs cryptographiques; une pile de protocoles de communication pour communiquer avec le dispositif hôte ; une liste de services distants avec les adresses de ces services et des crédits d'authentification de l'utilisateur auprès de ces services ;
- des moyens d'authentifier un utilisateur ; des moyens de transmettre au dispositif hôte la liste des services distants ; des moyens de transmettre au dispositif hôte le crédit d'authentification d'un service choisi.
Selon un mode particulier de réalisation de l'invention, le dispositif comprend en outre une page d'authentification qu'il rend disponible auprès d'un navigateur lancé sur le dispositif hôte et des moyens de valider des paramètres d'authentification entrés par un utilisateur à l'aide de ladite page d'authentification.
Selon un mode particulier de réalisation de l'invention, le dispositif comprend en outre un capteur biométrique pour l'authentification de l'utilisateur.
Selon un mode particulier de réalisation de l'invention, le dispositif comprend en outre une page disponible sur ledit dispositif de sécurité, ladite page comprenant une liste de liens sur lesdits services distants.
Selon un mode particulier de réalisation de l'invention, le dispositif comprend en outre une page disponible dans ledit dispositif de sécurité, ladite page comprenant un premier cadre dédié à la communication avec le service distant et un second cadre dédié à la communication avec ledit dispositif de sécurité lorsque ladite page est chargée dans un navigateur lancé sur le dispositif hôte. Selon un mode particulier de réalisation de l'invention, le dispositif comprend en outre des moyens pour communiquer avec le dispositif hôte selon un protocole particulier.
Selon un mode particulier de réalisation de l'invention, le dispositif comprend en outre des moyens de transmettre au dispositif hôte une séquence de codes simulant l'appui sur les touches d'un clavier.
Selon un mode particulier de réalisation de l'invention, le dispositif comprend en outre une mémoire de stockage pour mémoriser le navigateur destiné à être utilisé pour la connexion au service distant depuis le dispositif hôte.
Selon un mode particulier de réalisation de l'invention, le dispositif comprend en outre des moyens de chiffrer/déchiffrer au moins une partie des données échangées entre le service distant et le navigateur.
Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels :
La Fig. 1 illustre l'architecture du réseau.
La Fig. 2 illustre un exemple de connexion à un service sécurisé selon l'art antérieur.
La Fig. 3 illustre l'architecture de principe d'un exemple de réalisation de l'invention.
Les Fig. 4a et 4b illustrent l'architecture protocolaire de deux exemples de réalisation de l'invention.
La Fig. 5 illustre le processus d'utilisation d'un service sécurisé selon un exemple de réalisation de l'invention.
Dans l'architecture d'accès à un service sécurisé distant par un utilisateur, le point faible du point de vue de la sécurité est le terminal de l'utilisateur. En effet, l'utilisateur est rarement au fait des règles de sécurité permettant de se prémunir d'une contamination du poste par des logiciels malveillants. En particulier, il n'est pas rare que le terminal des utilisateurs soit envahi par des logiciels tels que des virus informatiques ou des logiciels espions. Certains de ces logiciels malveillants, une fois opérationnels sur le terminal, sont à même d'espionner les actions de l'utilisateur et de prendre connaissance des informations potentiellement confidentielles de celui-ci. Parmi les informations confidentielles sensibles, on peut citer les informations permettant à l'utilisateur de se connecter à des services distants sécurisés tels que le site de sa banque, des sites de commerces électroniques ou autres. Une fois en possession de ces données sensibles, ces logiciels malveillants sont susceptibles d'utiliser la connexion réseau du poste pour expédier ces informations sensibles à des tiers pouvant en faire un usage frauduleux.
Outre le préjudice direct dû à ces actes de piraterie, l'existence même de la menace est un frein considérable à l' essor des services en ligne dû à la perte de confiance de l'utilisateur. Il est donc particulièrement important de fournir à l'utilisateur le moyen d'accéder de manière sécurisée à des services distants.
La Fig. 3 illustre l'architecture d'un exemple de réalisation de l'invention. Cet exemple montre un dispositif hôte 3.1. Ce dispositif hôte est typiquement un ordinateur personnel ou encore tout type de système de traitement de l'information tel qu'un organiseur personnel (PDA en anglais), téléphone intelligent {smartphone en anglais), ou autre. Ce dispositif hôte est doté de capacités de communication avec un réseau de communication de données, typiquement Internet. Ce réseau lui permet de se connecter à l'aide d'un logiciel de navigation ou navigateur 3.2 à un service distant 3.3. Selon l'exemple de réalisation de l'invention, un dispositif de sécurité 3.4 est connecté au dispositif hôte. Cette connexion peut se faire selon divers protocoles de communication. L'exemple de réalisation est basé sur une connexion de type USB {Universal Sériai Bus en anglais). Le dispositif de sécurité se présente alors comme une clé USB connectable au dispositif hôte.
Toutefois, le dispositif de sécurité renferme des fonctionnalités allant bien au- delà d'une simple clé USB. Elle renferme des moyens 3.5 de stocker de manière sécurisée des crédits d'authentification pour la connexion à au moins un service distant. Nous appelons crédit d' authentification un j eu de données permettant authentification d'un utilisateur auprès d'un service distant. Ce jeu de données peut consister par exemple en un couple nom de connexion et mot de passe, solution largement utilisée pour rauthentification à des services distants. Toute autre solution peut également être utilisée ici, comme un certificat numérique offrant plus de sécurité qu'un nom et un mot de passe. Avantageusement, ces crédits d'authentification sont stockés dans un composant de carte à puce qui offre l'avantage d'offrir un composant dont la sécurité est éprouvée. De plus, un composant de carte à puce dispose également de moyens de chiffrement et de déchiffrement pouvant être également utilisés pour les calculs cryptographiques lors des communications entre le dispositif hôte et le service distant si nécessaire.
Le dispositif peut également avantageusement disposer d'une mémoire de masse 3.6. Cette mémoire de masse peut alors service à stocker par exemple une version du navigateur 3.2 dédiée à la communication avec le service distant. Ce navigateur sera alors typiquement adapté pour intégrer des protocoles de communication avec le dispositif de sécurité lorsqu'il sera exécuté par le dispositif hôte.
Le dispositif peut également avantageusement disposer d'un module 3.7 simulant le fonctionnement d'un clavier lorsqu'il est connecté au dispositif hôte. Dans l'exemple de réalisation, ce module simule un clavier compatible USB et est donc conforme au protocole HID (Human Interface Device en anglais) qui normalise le fonctionnement des dispositifs d'entrée sortie USB. Ce module permet l'envoi de séquences de codes simulant l'entrée au clavier d'un nom et d'un mot de passe dans certains modes de réalisation de l'invention.
Selon les modes de réalisation de l'invention, le dispositif de sécurité, lorsqu'il est connecté à un dispositif hôte, apparaît à celui-ci comme un périphérique triple. D'une part, il apparaît comme un dispositif de stockage de masse, tel une clé USB standard grâce au module de mémoire de masse 3.6. D'autre part, il apparaît comme un module de sécurité 3.5 avec lequel le dispositif hôte peut communiquer. Et finalement, il apparaît comme un clavier connecté grâce au module de simulation de clavier 3.7.
Le module de sécurité 3.5 communique avec le dispositif hôte tel un hôte indépendant accessible sur le réseau local du dispositif hôte. Pour cela, il implémente une pile 4.1 de protocoles de communication complète telle la pile illustrée par la Fig. 4a. Selon cet exemple de réalisation, le protocole RNDIS 4.6 (Remote Network Driver Interface Spécification en anglais) est utilisé pour produire un lien Ethernet virtuel au dessus de la couche USB 4.7. Le protocole IP 4.5 est porté sur RNDIS. Il supporte la couche de contrôle TCP 4.4. Les connexions TCP peuvent être sécurisées par la couche TLS (Transport Loyer Security en anglais) pour, entre autres, permettre l'établissement de requêtes HTTP (Hyper Text Transport Protocol en anglais). En particulier, il est avantageux de disposer d'un serveur HTTP implémenté dans le dispositif de sécurité qui va être en mesure de servir des requêtes en authentification ainsi que de fournir des informations comme la liste des services distants disponibles. Selon l'exemple de réalisation, le dispositif de sécurité est donc vu pour ce qui est du module de sécurité comme un serveur WEB accessible sur le réseau local du dispositif hôte. Alternativement, les couches IP à HTTP peuvent être remplacées par un protocole propriétaire ayant la même fonction, voir Fig. 4b.
La Fig. 5 illustre le fonctionnement typique d'une connexion selon l'invention. Lors d'une étape 5.1, l'utilisateur connecte le dispositif de sécurité au dispositif hôte. Il doit alors lancer le navigateur pour accéder d'une part à la liste des services et ensuite aux services eux-mêmes. Selon un premier mode de réalisation, il lance le navigateur disponible sur le dispositif hôte. Ceci pose le problème que ce navigateur n'est pas sûr, il peut avoir été infecté par des logiciels espions ou autres. Avantageusement, lors de la connexion du dispositif de sécurité, le module mémoire de masse 3.6 est vu par le système d'exploitation de l'hôte comme une clé USB. Avantageusement, cette mémoire est en lecture seule et propose alors une version du navigateur à l'utilisateur. C'est alors ce navigateur sauvegardé dans un espace protégé en écriture qui est lancé par l'utilisateur.
Lors d'une étape 5.2, l'utilisateur est invité à s'authentifier auprès du dispositif de sécurité. Cette authentification vise à éviter l'utilisation du dispositif par une personne non autorisée. Typiquement, ce dispositif est utilisé pour sécuriser l'accès à un ensemble de services pour un utilisateur et ne doit donc pouvoir être utilisé que par celui-ci. Cette authentification peut se faire par différents moyens. Un premier mode de réalisation utilise une authentification par nom de connexion et mot de passe. L'utilisateur se connecte sur le serveur WEB hébergé par le dispositif de sécurité et charge une page d' authentification. Il entre son nom de connexion et son mot de passe. Le dispositif valide authentification et, si celle-ci est valide, il déverrouille le dispositif de sécurité pour en autoriser l'utilisation. Dans un second mode de réalisation, le dispositif intègre un capteur biométrique, par exemple un lecteur d'empreinte digitale, mais tout autre capteur peut être utilisé comme un lecteur d'iris ou autre. L' authentification de l'utilisateur est alors faite à l'aide de ce capteur biométrique. Dans d'autres modes de réalisation, le dispositif de sécurité implémente des protocoles d' authentification tels que TLS ou RADIUS (Remote Authentication Dial In User Service en anglais).
Lors d'une étape 5.3, l'utilisateur obtient la liste des services disponibles offerts par le dispositif de sécurité. Cette liste peut être réduite à un seul service. Avantageusement cette liste est fournie sous la forme d'une page WEB servie par le serveur WEB embarqué sur le dispositif de sécurité. Un autre protocole peut être utilisé pour transmettre cette liste du dispositif de sécurité au dispositif hôte. Associé au nom du service est également transmis un lien d'accès au service, typiquement une adresse WEB.
Cette liste est soumise à l'utilisateur qui peut alors choisir l'un des services parmi la liste lors d'une étape 5.4. Ce choix provoque l'initialisation d'un processus de connexion au service sélectionné. Ces services étant typiquement sécurisés, l'initialisation débute par une étape d'authentification de l'utilisateur auprès du service choisi.
Pour réaliser cette authentification, l'utilisateur doit obtenir du dispositif de sécurité le crédit d'authentification associé au service. Ce crédit lui est typiquement associé. Il est stocké dans le dispositif au sein du module de sécurité, typiquement un composant de carte à puce.
D'une manière générale, c'est donc le navigateur qui va requérir et obtenir le crédit associé au service auprès du dispositif de sécurité lors de l'étape 5.5. La communication entre le navigateur et le dispositif peut être implémentée de plusieurs manières.
Selon un premier mode de réalisation, le navigateur est un navigateur standard qui peut être le navigateur usuel de l'utilisateur sur le dispositif de sécurité. Dans ce mode, une page est rendue disponible sur le dispositif de sécurité pour l'accès au service. Cette page comprend deux cadres (frames en anglais). Un premier cadre est appelé cadre de service et sert à la connexion entre le navigateur et le service distant. C'est ce cadre qui est visible pour l'utilisateur. Ce cadre correspond à la fenêtre habituelle d'accès à un service distant. Un second cadre, dit cadre de sécurité, sert à la communication entre le navigateur et le dispositif de sécurité. Ce cadre implémente un script de communication avec le dispositif. Il n'est typiquement pas visible dans la fenêtre de navigation. La communication entre le cadre de sécurité et le dispositif de sécurité peut être faite par exemple en HTTP avec le serveur WEB du dispositif. Avantageusement la communication est chiffrée, par exemple en utilisant le protocole HTTPS ou par un protocole propriétaire. Ce cadre de sécurité communique également avec le cadre de service.
Lors de la connexion au service distant, le cadre de service charge la page d'authentification au service distant. Lorsque ce chargement est terminé, il prévient le cadre de sécurité. Ce dernier requiert alors le crédit d'authentification auprès du dispositif de sécurité, typiquement un nom de connexion et un mot de passe. Lorsqu'il les a reçus, il remplit les champs idoines du cadre de service avec les informations transmises. L'utilisateur valide ces champs et l'authentification peut alors avoir lieu de manière habituelle.
Selon un mode particulier de réalisation, la transmission des crédits d'authentification du dispositif de sécurité vers le dispositif hôte est faite par le module 3.7 de simulation d'un clavier. Le nom de connexion et le mot de passe sont alors envoyés vers le cadre de service sous la forme d'une séquence de codes simulant l'appui sur les touches correspondantes du clavier. Il est à noter ici que le type de système d'exploitation est détecté par le dispositif de sécurité grâce aux en-têtes HTTP des requêtes faites par le navigateur au dispositif de sécurité. En effet, les séquences de codes sont dépendantes du système d'exploitation du dispositif hôte. Avantageusement, selon ce mode de réalisation, il est fait usage de mots de passe à usage unique générés par le token. L'utilisation du module de simulation de clavier donne un certain contrôle à l'utilisateur sur ce que fait le dispositif de sécurité. De plus, si la fonction de génération de mots de passe à usage unique peut être déclenchée par l'appui sur un bouton sur le dispositif de sécurité, il est alors possible pour l'utilisateur de générer ce type de mot de passe lorsqu'il le désire. Il peut également être utilisé pour éviter l'expiration d'une page du service distant en simulant une activité sous la forme d'un appui sur une touche. Il peut encore servir à fermer une session ou redémarrer l'ordinateur hôte au besoin.
Ce mode de réalisation offre l'avantage de permettre l'usage d'un navigateur non modifié au prix d'une page intégrant les deux cadres programmés de manière appropriée disponible sur le dispositif de sécurité.
Selon un autre mode de réalisation, le navigateur est modifié pour intégrer nativement dans son code un module de communication avec le dispositif de sécurité. Dans ce mode de réalisation, le choix des protocoles entre le navigateur et le dispositif de sécurité est libre. Il est alors permis de sécuriser ce protocole. On peut aussi alléger la communication en développant une pile de protocoles de communication plus légère du fait que l'on a le contrôle des deux interlocuteurs. Par contre, il n'est plus possible d'utiliser un navigateur non modifié. Il faut donc que le navigateur modifié soit accessible à l'utilisateur. Avantageusement, il est rendu disponible dans le module de mémoire du dispositif de sécurité. Ce mode de réalisation est lié à la pile de protocoles dans le dispositif illustré à la Fig. 4b. Quel que soit le mode de réalisation utilisé pour transmettre le crédit d'authentification au navigateur, lorsqu'il en dispose, il peut réaliser l'étape 5.6 de connexion au service. La communication se réalise alors de manière classique entre le service distant et le navigateur. Seule l'authentification ayant été sécurisée par le dispositif de sécurité. L'utilisateur peut utiliser le service, étape 5.7.
Selon une variante de réalisation, tout ou partie de la communication entre le service distant et le navigateur est chiffré. Il peut s'agir d'un chiffrement partiel des données les plus sensibles ou du chiffrement total de la communication, on parle alors de tunnel sécurisé entre le navigateur et le service. Avantageusement, ce chiffrement est effectué par le dispositif de sécurité à l'aide de crédits de chiffrement qui resteront stockés au sein du module de sécurité dudit dispositif de sécurité. L'échange des données à chiffrer ou à déchiffrer par le dispositif de sécurité est alors pris en charge soit par le cadre de sécurité soit par le module qui gère la communication avec le dispositif de sécurité selon le mode de réalisation adopté.
Lorsque l'utilisateur a terminé d'utiliser le service, intervient une étape de déconnexion 5.8. Cette étape peut être déclenchée par l'utilisateur au travers de l'interface du navigateur ou par déconnexion du dispositif de sécurité du dispositif hôte.

Claims

REVENDICATIONS
1 / Procédé de connexi on à un service di stant depuis un dispositif hôte caractérisé en ce qu'il comprend les étapes suivantes :
- une étape d' authentification de l'utilisateur auprès d'un dispositif de sécurité connecté sur le dispositif hôte ;
- une étape d'obtention d'une liste de services distants auprès dudit dispositif de sécurité ;
- une étape de choix d'un service parmi la liste de services distants obtenue ; - une étape par ledit dispositif hôte de connexion et d' authentification de l'utilisateur auprès du service distant choisi à l' aide d'un crédit d'authentification stocké dans ledit dispositif de sécurité ;
- une étape de transmission du crédit d'authentification depuis le dispositif de sécurité au navigateur sous la forme d'une séquence de codes simulant l'appui sur les touches d'un clavier.
21 Procédé de connexion selon la revendication 1, caractérisé en ce que l'authentification de l'utilisateur auprès dudit dispositif de sécurité comprend les étapes suivantes :
- une étape de chargement d'une page d' authentification disponible sur ledit dispositif de sécurité dans un navigateur lancé sur le dispositif hôte ;
- une étape d'entrée de paramètres d'authentification dans ladite page d'authentification ;
- une étape de validation desdits paramètres d'authentification par ledit dispositif de sécurité.
3/ Procédé de connexion selon la revendication 1, caractérisé en ce que l'authentification de l'utilisateur auprès dudit dispositif de sécurité comprend une étape d'authentification d'un paramètre biométrique de l'utilisateur par un capteur biométrique intégré audit dispositif de sécurité.
4/ Procédé de connexion selon l'une des revendications 1 à 3, caractérisé en ce que l'étape d'obtention d'une liste de services distants comprend une étape de chargement dans un navigateur lancé sur le dispositif hôte d'une page disponible sur ledit dispositif de sécurité, ladite page comprenant une liste de liens sur lesdits services distants.
5/ Procédé de connexion selon l'une des revendications 1 à 4, caractérisé en ce que l'étape de connexion et d'authentification de l'utilisateur auprès du service distant choisi comprend au sein d'un navigateur :
- une étape de connexion avec ledit dispositif de sécurité;
- une étape de connexion au service distant ;
- une étape de communication au service distant de crédit d'authentification obtenu dudit dispositif de sécurité ;
6/ Procédé de connexion selon la revendication 5, caractérisé en ce que l'étape de connexion au service distant comprend une étape de chargement d'une page disponible dans ledit dispositif de sécurité, ladite page comprenant un premier cadre dédié à la communication avec le service distant et un second cadre dédié à la communication avec ledit dispositif de sécurité lorsque ladite page est chargée dans un navigateur lancé sur le dispositif hôte.
7/ Procédé de connexion selon la revendication 5, caractérisé en ce que l'étape de connexion et de communication avec ledit dispositif de sécurité est faite selon un protocole particulier implémenté au sein du navigateur et du dispositif.
8/ Procédé de connexion selon l'une des revendications 6 ou 7, caractérisé en ce que le crédit d'authentification est transmis du dispositif de sécurité au navigateur sous la forme d'une page de données.
91 Procédé de connexion selon l'une des revendications 1 à 8, caractérisé en ce qu'il comprend une étape préalable de chargement du navigateur utilisé pour la connexion depuis une mémoire de stockage dudit dispositif de sécurité.
10/ Procédé de connexion selon la revendication 9, caractérisé en ce qu'il comprend en outre une étape de chiffrement/déchiffrement d'au moins une partie des données échangées entre le navigateur et le service distant faite par ledit dispositif de sécurité. 11/ Dispositif de sécurité connectable à un dispositif hôte pour la connexion sécurisée à un service distant, caractérisé en ce qu'il comprend :
- un composant de carte à puce pour le stockage sécurisé de crédits d'authentification et les calculs cryptographiques ;
- une pile de protocoles de communication pour communiquer avec le dispositif hôte ;
- une liste de services distants avec les adresses de ces services et des crédits d'authentification de l'utilisateur auprès de ces services ;
- des moyens d'authentifier un utilisateur ;
- des moyens de transmettre au dispositif hôte la liste des services distants ;
- des moyens de transmettre au dispositif hôte le crédit d'authentification d'un service choisi sous la forme d'une séquence de codes simulant l'appui sur les touches d'un clavier.
12/ Dispositif de sécurité selon la revendication 1 1 , caractérisé en ce qu'il comporte en outre une page d'authentification qu'il rend disponible auprès d'un navigateur lancé sur le dispositif hôte et des moyens de valider des paramètres d'authentification entrés par un utilisateur à l'aide de ladite page d'authentification.
13/ Dispositif de sécurité selon la revendication 11, caractérisé en ce qu'il comporte en outre un capteur biométrique pour l'authentification de l'utilisateur.
14 / Dispositif de sécurité selon l'une des revendications 11 à 13, caractérisé en ce qu'il comporte en outre une page disponible sur ledit dispositif de sécurité, ladite page comprenant une liste de liens sur lesdits services distants.
15/ Dispositif de sécurité selon l'une des revendications 11 à 14, caractérisé en ce qu'il comporte en outre une page disponible dans ledit dispositif de sécurité, ladite page comprenant un premier cadre dédié à la communication avec le service distant et un second cadre dédié à la communication avec ledit dispositif de sécurité lorsque ladite page est chargée dans un navigateur lancé sur le dispositif hôte. 16 / Dispositif de sécurité selon l'une des revendications 11 à 14, caractérisé en ce qu'il comporte des moyens pour communiquer avec le dispositif hôte selon un protocole particulier.
17/ Dispositif de sécurité selon l'une des revendications 11 à 16, caractérisé en ce qu'il comporte une mémoire de stockage pour mémoriser le navigateur destiné à être utilisé pour la connexion au service distant depuis le dispositif hôte.
18/ Dispositif de sécurité selon la revendication 17, caractérisé en ce qu'il comporte en outre des moyens de chiffrer/déchiffrer au moins une partie des données échangées entre le service distant et le navigateur.
PCT/EP2012/051896 2011-02-08 2012-02-03 Procede et dispositif de connexion a un service distant depuis un dispositif hote WO2012107369A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1150977A FR2971350B1 (fr) 2011-02-08 2011-02-08 Procede et dispositif de connexion a un service distant depuis un dispositif hote
FR11/50977 2011-02-08

Publications (1)

Publication Number Publication Date
WO2012107369A1 true WO2012107369A1 (fr) 2012-08-16

Family

ID=45558746

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/051896 WO2012107369A1 (fr) 2011-02-08 2012-02-03 Procede et dispositif de connexion a un service distant depuis un dispositif hote

Country Status (2)

Country Link
FR (1) FR2971350B1 (fr)
WO (1) WO2012107369A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050071282A1 (en) * 2003-09-29 2005-03-31 Lu Hongqian Karen System and method for preventing identity theft using a secure computing device
WO2006131897A1 (fr) * 2005-06-09 2006-12-14 Axalto S.A. Systeme et procede permettant l'utilisation d'une unite memoire securisee pour transmettre les references d'utilisateur a un service distant par l'intermediaire d'un reseau
WO2007122224A1 (fr) * 2006-04-24 2007-11-01 Cypak Ab Dispositif et procede d'identification et d'authentification
GB2444650A (en) * 2006-12-08 2008-06-11 Visible Computing Ltd Passing key sequences to a host computer through a USB device

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009001197A2 (fr) * 2007-06-22 2008-12-31 Gemalto S.A. Procédé pour empêcher des extensions de navigateur web à partir de piratage d'informations d'utilisateur

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050071282A1 (en) * 2003-09-29 2005-03-31 Lu Hongqian Karen System and method for preventing identity theft using a secure computing device
WO2006131897A1 (fr) * 2005-06-09 2006-12-14 Axalto S.A. Systeme et procede permettant l'utilisation d'une unite memoire securisee pour transmettre les references d'utilisateur a un service distant par l'intermediaire d'un reseau
WO2007122224A1 (fr) * 2006-04-24 2007-11-01 Cypak Ab Dispositif et procede d'identification et d'authentification
GB2444650A (en) * 2006-12-08 2008-06-11 Visible Computing Ltd Passing key sequences to a host computer through a USB device

Also Published As

Publication number Publication date
FR2971350A1 (fr) 2012-08-10
FR2971350B1 (fr) 2015-08-21

Similar Documents

Publication Publication Date Title
EP1004101B1 (fr) Terminal et systeme pour la mise en oeuvre de transactions electroniques securisees
JP6012125B2 (ja) 問い合わせ型トランザクションによる強化された２ｃｈｋ認証セキュリティ
EP2567502A2 (fr) Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
EP2614458B1 (fr) Procede d'authentification pour l'acces a un site web
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
CA2525121A1 (fr) Procede et appareil d'authentification d'utilisateurs et de sites web
JP2008269610A (ja) リモートアプリケーションを対象とした機密データの保護
WO2013021107A9 (fr) Procede, serveur et systeme d'authentification d'une personne
WO2014064353A1 (fr) Procede de fourniture d'un service securise
EP3022867A1 (fr) Procéde d'authentification forte
US20090177892A1 (en) Proximity authentication
EP2509025A1 (fr) Procédé d'accès à une ressource protégée d'un dispositif personnel sécurisé
EP3991381B1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
EP2306668B1 (fr) Système et procédé de transaction sécurisée en ligne
US20090271629A1 (en) Wireless pairing ceremony
EP2813962B1 (fr) Méthode de contrôle d'accès à un type de services spécifique et dispositif d'authentification pour le contrôle de l'accès à un tel type de services.
EP2441228A1 (fr) Dispositif et procédé d'accès sécurisé à un service distant
EP2215800A1 (fr) Procede d'authentification d'un utilisateur accedant a un serveur distant a partir d'un ordinateur
FR3053548A1 (fr) Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants.
WO2012107369A1 (fr) Procede et dispositif de connexion a un service distant depuis un dispositif hote
EP3570518B1 (fr) Systeme et procede d'authentification utilisant un jeton a usage unique de duree limitee
WO2017005644A1 (fr) Procédé et système de contrôle d'accès à un service via un média mobile sans intermediaire de confiance
EP4105798A1 (fr) Procédé d authentification, dispositif et programme correspondant
Mannan Authentication and securing personal information in an untrusted internet
WO2012022856A1 (fr) Procédé d'authentification d' un utilisateur du réseau internet

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12701921

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12701921

Country of ref document: EP

Kind code of ref document: A1