WO2010142740A1 - Dispositif et procédé d'accès sécurisé à un service distant - Google Patents

Dispositif et procédé d'accès sécurisé à un service distant Download PDF

Info

Publication number
WO2010142740A1
WO2010142740A1 PCT/EP2010/058108 EP2010058108W WO2010142740A1 WO 2010142740 A1 WO2010142740 A1 WO 2010142740A1 EP 2010058108 W EP2010058108 W EP 2010058108W WO 2010142740 A1 WO2010142740 A1 WO 2010142740A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
service
terminal
server
connection
Prior art date
Application number
PCT/EP2010/058108
Other languages
English (en)
Inventor
François LECOCQ
Cyrille Pepin
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
Priority to US13/376,916 priority Critical patent/US9185110B2/en
Priority to EP10725090A priority patent/EP2441228A1/fr
Publication of WO2010142740A1 publication Critical patent/WO2010142740A1/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/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer

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 terminal 1.1 such as a personal computer or any similar device such as a personal assistant or a smartphone.
  • This terminal 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 terminal to the services hosted on the servers 1.3 via the information exchange network 1.2.
  • Many of these services deal with confidential information and it is important to secure access to these services.
  • 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 terminal and the server. This security is typically done by creating an encrypted connection or an encrypted tunnel between the terminal and the server. This encrypted connection or tunnel can, for example, be created using the SSL protocol (Secure Socket Rent), or its successor TLS (Transport Layer Security in English). Fig. 2 illustrates the use of these techniques.
  • the terminal sends a connection request 2.1, generally 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 terminal 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. Only the server is able to decrypt this symmetric key using its private key associated with its public key. It performs this decryption during step 2.6. At this time, the terminal and the server share the same secret key, the symmetric key, and are therefore able to establish an encrypted connection 2.7 using this shared key.
  • This encrypted connection then allows the exchange of information between the terminal and the server in a secure manner.
  • All data exchanged are encrypted using the shared secret key and can only be decrypted by both ends of the encrypted connection, the terminal and the server, which share the same secret. It can be seen that this method makes it possible to secure exchanges between the terminal and the server.
  • the data exchanged are manipulated in clear by the server and the terminal. It is assumed a priori that the server is safe because of management by professionals.
  • the security of the terminal poses a problem. Indeed, users are rarely aware of techniques to ensure the security of an information processing station. Moreover, it is extremely difficult to obtain from them a strict respect of safety rules.
  • the invention aims to solve the above problems by providing a device and a method for securing the confidential information of the user and their exchanges securely with the servers hosting the services. It is based on the personalization of a smart card containing this information.
  • This smart card connected to the user's terminal, has connection means allowing it to appear as an autonomous host of the user's local network.
  • An encrypted connection is then established directly between the smart card and the server hosting the service for the transmission of confidential data.
  • This data, stored on the smart card is then exchanged with the server by this encrypted connection. They are never accessible in clear on the terminal of the user.
  • the invention relates to a device for secure access to a remote service comprising a smart card; means for connecting the smart card to a user terminal connected to a communication network; communication means with the user terminal to which the device is connected; communication means with a server hosting the remote service, said server being connected to the communication network, said communication means establishing the communication via the user terminal to which the device is connected; means for storing the address of said server hosting the remote service and means of authentication with this server; means for establishing an encrypted connection between the device and the server hosting the remote service using said connection identifiers and means for relaying the traffic between the user terminal and the server via said encrypted connection.
  • it further comprises means for authenticating the user.
  • the authentication means are biometric means.
  • the device further comprises means for storing a list of accessible services and means for offering a choice from this list.
  • the device further comprises means for storing a client software allowing access to the secure service when it is executed on the user terminal.
  • the invention also relates to a remote service connection method which comprises a step of establishing an encrypted connection between a device comprising a smart card and a remote server hosting a secure service, said device being connected to a user terminal. itself connected to a communication network, said remote server being accessible via the communication network, the encrypted connection being established by routing the communication by the user terminal, said encrypted connection being established using connection identifiers stored on said device and a step of using the service from the user terminal, the traffic between the terminal and the remote server being relayed by said device by said encrypted connection.
  • the device storing a list of accessible services with the corresponding identifiers
  • the method further comprises a step of proposing the list of services to the user and a step of choosing the service with which establish the encrypted connection.
  • the method comprises a prior step of authenticating the user.
  • the method comprises a prior step of loading remote service access software from the device on the user terminal.
  • 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
  • Fig. 4 illustrates the protocol architecture of an exemplary embodiment 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 enabling the user to connect to secure remote services such as his bank's website, e-commerce sites, and others. 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.
  • the client terminal 3.1 has a first network interface 3.2 allowing the connection of the terminal to the Internet network 3.5. On this network are available servers hosting services. One of these servers 3.6 is shown connected to the network 3.5.
  • the device according to the invention 3.4 is connected to the terminal 3.1 by a second network interface 3.3. This second network interface is based in the exemplary embodiment of the invention on a USB serial physical interface.
  • the arrows 3.7 and 3.8 represent the data flows when using the device for a connection of the user to a secure service.
  • the arrow 3.7 between the device 3.4 and the server 3.6 illustrates the encrypted connection that is established between these two elements.
  • This encrypted connection is relayed by the terminal which then functions as a simple network router.
  • the transferred data is protected against any attack by any malicious software on the terminal 3.1 by the encryption used to establish the encrypted connection.
  • the terminal therefore has no means of access to these data although they transit through it.
  • the arrow 3.8 represents in fact two different data streams passing between the terminal and the device 3.4.
  • the user may be required to authenticate with the device to prevent fraudulent use. It must also, at least when the device hosts multiple services, select the service that it wants to access for the device to initiate the connection to this service. Confidential data for this connection may include login name and password pairs, digital encryption certificates, and any other information that may be required depending on the implementation of the service.
  • a software module present on the device then establishes the encrypted connection with the server 3.6. Once this encrypted connection is established, the user can use the service from the terminal 3.1. This use is done by interaction, arrow 3.8, with a software module on the device for relaying information between the server and the user via the encrypted connection 3.7.
  • the device is content with a relay (proxy in English) at the transport layer of the network, in this case TCP / IP (Transmission Control Protocol I Internet Protocol in English defined by RFC 791 and 793).
  • TCP / IP Transmission Control Protocol I Internet Protocol in English defined by RFC 791 and 793.
  • the client-server model is implemented between a client hosted on the terminal, for example an HTTP client (HyperText Transfer Protocol defined by RFC 2616) or browser and the device.
  • HTTP client HyperText Transfer Protocol defined by RFC 2616
  • This same model is also implemented between the device that hosts the client and the remote service that the user wants to access.
  • the exemplary embodiment of the invention is based on the use of a smart card inserted in a smart card reader connected in USB to the client terminal.
  • a first adaptation aims to allow TCP / IP communication over the USB connection.
  • the choice fell on the use of the protocol RNDIS (Remonte Network Driver Interface Specification developed by Microsoft).
  • RNDIS Redmonte Network Driver Interface Specification developed by Microsoft.
  • This is a specification for network devices running on a bus such as USB.
  • This choice makes it possible to be compatible without requiring parameterization or to add a particular software with a wide selection of user terminal operating systems such as Windows Vista, Apple Mac OS X or Linux, which integrate into their distribution. by default the management of RNDIS.
  • Windows XP it is simply necessary to add a ".inf" file of a few kilobytes. This choice therefore allows the simple use of the device according to the invention with most user terminals available on the market.
  • Those skilled in the art understand that other choices can be made on this point, more particularly if the invention is made with a connection other than USB between the device and the terminal.
  • TCP / IP communication stack it is also necessary to add a TCP / IP communication stack to the operating system of the smart card which is generally without it.
  • the choice here was focused on the TCP / IP stack implemented in the free operating system Contiki (http://www.sics.se/contiki/).
  • This system is a lightweight, multitasking, highly portable operating system that contains a TCP / IP stack that is particularly suitable for porting to a smart card due to its low resource requirements and small size.
  • this stack is made even more compact by deactivating all functions not strictly necessary for its operation. Thanks to the implementation of these two technologies, the smart card within its USB drive acquires the status of TCP / IP network host in its own right. All that is required is for the user's terminal to be configured in relay mode to share its network connection so that the device has network access via this intermediary.
  • the creation of the encrypted connection between the device and the server hosting the service requires an encryption software layer.
  • Various solutions can be used to establish the encrypted connection such as IPsec, a set of protocols to secure data transport over the IP protocol, PPTP (Point to Point Tunneling Protocol), SSL (Secure Socket Rent) or still its evolution TLS (Transport Loyer Security in English).
  • IPsec IP Security
  • PPTP Point to Point Tunneling Protocol
  • SSL Secure Socket Rent
  • TLS Transaction Loyer Security in English
  • TLS Transaction Loyer Security in English
  • TLS Transaction Loyer Security in English
  • Fig. 4 illustrates the protocol layers involved in the implementation of the embodiment of the invention.
  • the user terminal 4.1 the device according to the invention 4.4 and the server hosting the secure service 4.6.
  • the user terminal 4.1 and the device 4.4 have a USB connection over which the RNDIS protocol is ported to allow IP communication.
  • the TCP transport layer is conventionally used to implement reliable sessions.
  • the transferred data is secured by encryption by the TLS layer which is an evolution of SSL. It is this layer that allows the encryption and therefore the creation of the encrypted communication connection.
  • the application layer is based in the exemplary embodiment on a WEB environment and therefore on the HTTP transport protocol (HyperText Transfer Protocol in English defined by RFC 2616).
  • the user terminal 4.1 has a second network interface, typically based on Ethernet, but other interfaces such as a Wi-Fi wireless interface can also be used, which allows it to communicate with the server 4.6.
  • This server 4.6 also has the IP / TCP / TLS / HTTP layers already mentioned, typically over an Ethernet interface.
  • Arrow 4.8 represents the traffic between the user terminal 4.1 and the device 4.4. Typically, this traffic corresponds to an authentication phase of the user with the device, the choice of the service and the traffic relating to the chosen service that the device refers to the terminal for use by the user.
  • Arrow 4.7 for its part, represents the encrypted connection between the device 4.4 and the server 4.6. This encrypted connection goes through the terminal operating as a network router at the IP layer.
  • Fig. 5 illustrates an example of use of the invention.
  • the device connects to the terminal.
  • the user must authenticate with the device.
  • the safest is to provide the device with a biometric sensor for identification, for example by a fingerprint recognition device executed on the device (Match On Card or MOC).
  • MOC fingerprint recognition device executed on the device
  • password authentication can be done.
  • the user opens a web browser for example on the terminal and connects to the device.
  • the device has an embedded WEB server which proposes an authentication page.
  • the traffic between the terminal and the device 3.8, 4.8 is also protected by encryption. This limits the risk of malware attacks on the device.
  • the device advantageously allows it to select one of the accessible services offered during a step 5.3. This step is optional, the device being configurable to only provide access to a particular service. This step can be implemented via a WEB page transmitted by HTTP to the terminal. The user can then select the desired service during a step 5.4 of choice of the service.
  • the device establishes the encrypted connection with the server hosting the chosen service in a step 5.5. This encrypted connection is performed by the TLS security layer in the exemplary embodiment.
  • the device has the service address and authentication means to the server, for example the identifiers required for connection to the server or service.
  • This confidential data is entered in the card during a prior stage of personalization thereof. They benefit from the protection techniques against both software and hardware attacks intrinsic to smart cards.
  • This preliminary programming of the card can be done using a dedicated software on the terminal.
  • this personalization step is made before the distribution of the card to the user, for example by a service provider who can be the manager of one of the secure services, for example a banking establishment.
  • These parameters typically consist of a list of accessible services and for each service are available the service address and login credentials, preferably a digital encryption certificate.
  • the device then functions as a relay (proxy in English) for HTTP traffic between the user terminal and the service.
  • the user can use the service, during a step 5.6, using his web browser as if he were directly connected to the server via his terminal.
  • HTTP traffic is directed to the device that relays it to the server through the encrypted connection.
  • the traffic goes back to the terminal, but encrypted, the terminal functioning as a simple IP router.
  • the device closes the encrypted connection in step 5.7. If a connection, for example encrypted, was established between the terminal and the device, this connection is also closed in step 5.8.
  • it is possible to further increase the security of the system by allowing the connection to the device only from a client software provided by the system and not from the web browser of the terminal.
  • This client software can be a web browser, but can also be a client based on a different protocol possibly developed for the occasion.
  • this client is stored securely and can not be modified without authorization on the card within a storage space.
  • This storage space can then be seen from the terminal as a removable storage device visible from the terminal when the device is connected.
  • This software allows access to the secure service when it is run on the user terminal.
  • the use of the device then comprises a preliminary step of loading this access software from the device on the user terminal. This avoids manipulation and / or espionage exchanges by modification of the client software.
  • the user can connect to a secure service without at any time, the service address or login credentials are present in clear on the terminal. Eventually, this information is never even brought to the attention of the user who is provided with a personalized card ready to use.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (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)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

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. Elle décrit un dispositif et un procédé permettant la sécurisation des informations confidentielles de l'utilisateur et leurs échanges de manière sûre avec les serveurs hébergeant les services. Elle se base sur la personnalisation d'une carte à puce contenant ces informations. Cette carte à puce, connectée au terminal de l'utilisateur, possède des moyens de connexion lui permettant d'apparaître comme un hôte autonome du réseau local de l'utilisateur. Une connexion chiffrée est alors établie directement entre la carte à puce et le serveur hébergeant le service pour la transmission des données confidentielles. Ces données, stockées sur la carte à puce, sont alors échangées avec le serveur par cette connexion chiffrée. Elles ne sont jamais accessibles en clair sur le terminal de l'utilisateur.

Description

Dispositif et procédé d'accès sécurisé à un service distant
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 authentifîcation 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 terminal 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 terminal 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 terminal 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 terminal 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 terminal et le serveur. Cette connexion chiffrée ou tunnel peut, par exemple, être créée en utilisant le protocole SSL (Secure Socket Loyer en anglais), ou son successeur TLS (Transport Layer Security en anglais). La Fig. 2 illustre l'utilisation de ces techniques. Le terminal 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 terminal 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 terminal 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 terminal 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 terminal et le serveur, qui partagent le même secret. On voit que ce procédé permet de sécuriser les échanges entre le terminal 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 terminal 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 terminal 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 terminal 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 terminal et le serveur. Il s'avère que le point faible du système, en ce qui concerne la sécurité, est le terminal 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 de la communication de celui-ci.
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.
L'invention vise à résoudre les problèmes précédents en offrant un dispositif et un procédé permettant la sécurisation des informations confidentielles de l'utilisateur et leurs échanges de manière sûre avec les serveurs hébergeant les services. Elle se base sur la personnalisation d'une carte à puce contenant ces informations. Cette carte à puce, connectée au terminal de l'utilisateur, possède des moyens de connexion lui permettant d'apparaître comme un hôte autonome du réseau local de l'utilisateur. Une connexion chiffrée est alors établie directement entre la carte à puce et le serveur hébergeant le service pour la transmission des données confidentielles. Ces données, stockées sur la carte à puce, sont alors échangées avec le serveur par cette connexion chiffrée. Elles ne sont jamais accessibles en clair sur le terminal de l'utilisateur.
L'invention concerne un dispositif d'accès sécurisé à un service distant comportant une carte à puce; des moyens de connexion de la carte à puce à un terminal utilisateur connecté à un réseau de communication; des moyens de communication avec le terminal utilisateur auquel le dispositif est connecté; des moyens de communication avec un serveur hébergeant le service distant, ledit serveur étant connecté au réseau de communication, lesdits moyens de communication établissant la communication par l'intermédiaire du terminal utilisateur auquel est connecté le dispositif; des moyens de stockage de l'adresse dudit serveur hébergeant le service distant et de moyens d'authentifïcation auprès de ce serveur; des moyens d'établir une connexion chiffrée entre le dispositif et le serveur hébergeant le service distant à l'aide desdits identifiants de connexion et des moyens de relayer le trafic entre le terminal utilisateur et le serveur par ladite connexion chiffrée. Selon un mode de réalisation particulier de l'invention, il comporte en outre des moyens d'authentifïcation de l'utilisateur.
Selon un mode de réalisation particulier de l'invention, les moyens d'authentifïcation sont des moyens biométriques.
Selon un mode de réalisation particulier de l'invention, le dispositif comporte en outre des moyens de stockage d'une liste de services accessibles et des moyens d'offrir un choix parmi cette liste.
Selon un mode de réalisation particulier de l'invention, le dispositif comporte en outre des moyens de stockage d'un logiciel client permettant l'accès au service sécurisé lorsqu'il est exécuté sur le terminal utilisateur. L'invention concerne également un procédé de connexion à un service distant qui comporte une étape d'établissement d'une connexion chiffrée entre un dispositif comportant une carte à puce et un serveur distant hébergeant un service sécurisé, ledit dispositif étant connecté à un terminal utilisateur lui-même connecté à un réseau de communication, ledit serveur distant étant accessible par le réseau de communication, la connexion chiffrée étant établie par routage de la communication par le terminal utilisateur, ladite connexion chiffrée étant établie à l'aide d'identifiants de connexion stockés sur ledit dispositif et une étape d'utilisation du service depuis le terminal utilisateur, le trafic entre le terminal et le serveur distant étant relayé par ledit dispositif par ladite connexion chiffrée. Selon un mode de réalisation particulier de l'invention, le dispositif stockant une liste de services accessibles avec les identifiants correspondants, le procédé comporte en outre une étape de proposition de la liste des services à l'utilisateur et une étape de choix du service avec lequel établir la connexion chiffrée.
Selon un mode de réalisation particulier de l'invention, le procédé comporte une étape préalable d'authentifïcation de l'utilisateur.
Selon un mode de réalisation particulier de l'invention, le procédé comporte une étape préalable de chargement d'un logiciel d'accès au service distant depuis le dispositif sur le terminal utilisateur. 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 ; La Fig. 4 illustre l'architecture protocolaire d'un exemple 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 de part 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. Le terminal du client 3.1 possède une première interface réseau 3.2 permettant la connexion du terminal au réseau Internet 3.5. Sur ce réseau sont disponibles des serveurs hébergeant des services. Un de ces serveurs 3.6 est représenté connecté au réseau 3.5. Le dispositif selon l'invention 3.4 est connecté au terminal 3.1 par une seconde interface réseau 3.3. Cette seconde interface réseau est basée dans l'exemple de réalisation de l'invention sur une interface physique série USB. Les flèches 3.7 et 3.8 représentent les flux de données lors de l'utilisation du dispositif pour une connexion de l'utilisateur à un service sécurisé. La flèche 3.7 entre le dispositif 3.4 et le serveur 3.6 illustre la connexion chiffrée qui est établie entre ces deux éléments. Cette connexion chiffrée est relayée par le terminal qui fonctionne alors comme un simple routeur réseau. Les données transférées sont protégées contre toute attaque de la part d'un éventuel logiciel malveillant sur le terminal 3.1 par le chiffrement utilisé pour établir la connexion chiffrée. Le terminal n'a donc aucun moyen d'accès à ces données bien qu'elles transitent par lui.
La flèche 3.8 représente en fait deux flux de données différents transitant entre le terminal et le dispositif 3.4. Dans un premier temps, l'utilisateur peut être obligé de s'authentifier auprès du dispositif pour empêcher une utilisation frauduleuse. Il doit aussi, du moins lorsque le dispositif héberge plusieurs services, sélectionner le service auquel il veut accéder pour que le dispositif amorce la connexion à ce service. Les données confidentielles permettant cette connexion peuvent comprendre des couples nom de connexion et mot de passe, des certificats numériques de chiffrement et toute information nécessaire en fonction de la mise en œuvre du service. Un module logiciel présent sur le dispositif établit alors la connexion chiffrée avec le serveur 3.6. Une fois cette connexion chiffrée établie, l'utilisateur peut utiliser le service depuis le terminal 3.1. Cette utilisation se fait par interaction, flèche 3.8, avec un module logiciel sur le dispositif permettant le relais des informations entre le serveur et l'utilisateur par la connexion chiffrée 3.7.
Plusieurs mises en œuvre peuvent être utilisées ici se différenciant par le niveau d'intelligence du logiciel embarqué sur le dispositif. Une solution est la suivante : le dispositif se contente d'un relais (proxy en anglais) au niveau de la couche de transport du réseau, en l'occurrence TCP/IP (Transmission Control Protocol I Internet Protocol en anglais défini par les RFC 791 et 793). Le modèle client-serveur est mis en œuvre entre un client hébergé sur le terminal, par exemple un client HTTP (HyperText Transfer Protocol en anglais défini par la RFC 2616) ou navigateur et le dispositif. Ce même modèle est également mis en œuvre entre le dispositif qui héberge le client, et le service distant auquel l'utilisateur désire accéder. L'exemple de réalisation de l'invention est basé sur l'utilisation d'une carte à puce insérée dans un lecteur de carte à puce connecté en USB au terminal client. Une première adaptation vise à permettre la communication en TCP/IP au-dessus de la connexion USB. Pour ce faire, le choix s'est porté sur l'utilisation du protocole RNDIS (Remonte Network Driver Interface Spécification développé par Microsoft). Il s'agit d'une spécification pour périphériques réseaux fonctionnant sur un bus comme par exemple USB. Ce choix permet d'être compatible sans nécessiter de paramétrage ou d'ajouter un logiciel particulier avec une large sélection de systèmes d'exploitation du terminal de l'utilisateur tels que Windows Vista, Apple Mac OS X ou Linux, qui intègrent dans leur distribution par défaut la gestion de RNDIS. Sur Windows XP, il est simplement nécessaire d'ajouter un fichier «.inf» de quelques kilo-octets. Ce choix permet donc l'utilisation simple du dispositif selon l'invention avec la plupart des terminaux utilisateurs disponibles sur le marché. L'homme du métier comprend que d'autres choix peuvent être faits sur ce point, plus particulièrement si l'invention est réalisée avec une connexion autre que USB entre le dispositif et le terminal.
Il est également nécessaire d'ajouter une pile de communication TCP/IP au système d'exploitation de la carte à puce qui en est généralement dépourvue. Le choix s'est ici porté sur la pile TCP/IP mise en œuvre dans le système d'exploitation libre Contiki (http://www.sics.se/contiki/). Ce système est un système d'exploitation léger, multitâche, hautement portable qui contient une pile TCP/IP particulièrement adaptée pour un portage sur une carte à puce du fait de ses faibles exigences en ressources et de sa petite taille. Avantageusement, cette pile est rendue encore plus compacte par une désactivation de toutes les fonctions non strictement nécessaires à son fonctionnement. Grâce à la mise en œuvre de ces deux technologies, la carte à puce au sein de son lecteur USB acquiert le statut d'hôte réseau TCP/IP à part entière. Il suffit alors que le terminal de l'utilisateur soit configuré en relais pour le partage de sa connexion réseau pour que le dispositif ait un accès réseau par cet intermédiaire.
La création de la connexion chiffrée entre le dispositif et le serveur hébergeant le service nécessite une couche logicielle de chiffrement. Diverses solutions peuvent être utilisées pour établir la connexion chiffrée telles que IPsec, un ensemble de protocoles permettant de sécuriser le transport de données sur le protocole IP, PPTP (Point to Point Tunneling Protocol en anglais), SSL (Secure Socket Loyer en anglais) ou encore son évolution TLS (Transport Loyer Security en anglais). L'exemple de réalisation est basé sur l'utilisation de TLS, lequel est avantageusement mis en œuvre pour utiliser le coprocesseur crypto graphique généralement présent sur les cartes à puce. Cette utilisation du coprocesseur crypto graphique permet d'améliorer notablement les performances des opérations de chiffrement et de déchiffrement par rapport à une solution purement logicielle.
La Fig. 4 illustre les couches protocolaires impliquées dans la mise en œuvre du mode de réalisation de l'invention. On retrouve le terminal utilisateur 4.1, le dispositif selon l'invention 4.4 et le serveur hébergeant le service sécurisé 4.6. Le terminal utilisateur 4.1 et le dispositif 4.4 possèdent une connexion USB au-dessus de laquelle le protocole RNDIS est porté pour permettre la communication IP. Au-dessus de IP on retrouve de manière classique la couche de transport TCP pour la mise en œuvre de sessions fiables. Les données transférées sont sécurisées par chiffrement par la couche TLS qui est une évolution de SSL. C'est cette couche qui permet le chiffrement et donc la création de la connexion chiffrée de communication. La couche applicative se base dans l'exemple de réalisation sur un environnement WEB et donc sur le protocole de transport HTTP (HyperText Transfer Protocol en anglais défini par la RFC 2616).
Le terminal utilisateur 4.1 dispose d'une seconde interface réseau, typiquement basée sur Ethernet, mais d'autres interfaces comme une interface sans fil Wi-Fi peut aussi être utilisée, qui lui permet de communiquer avec le serveur 4.6. Ce serveur 4.6 possède également les couches IP/TCP/TLS/HTTP déjà citées, typiquement au-dessus d'une interface Ethernet. La flèche 4.8 représente le trafic entre le terminal utilisateur 4. 1 et le dispositif 4.4. Typiquement, ce trafic correspond à une phase d'authentifîcation de l'utilisateur auprès du dispositif, au choix du service et au trafic relatif au service choisi que le dispositif renvoie au terminal pour être utilisé par l'utilisateur. La flèche 4.7, quant à elle, représente la connexion chiffrée entre le dispositif 4.4 et le serveur 4.6. Cette connexion chiffrée passe par le terminal fonctionnant en routeur réseau au niveau de la couche IP.
La Fig. 5 illustre un exemple d'utilisation de l'invention. Lors d'une première étape 5.1 , le dispositif se connecte au terminal. Avantageusement, pour éviter l'utilisation frauduleuse du dispositif lors d'une seconde étape 5.2, l'utilisateur doit s'authentifier auprès du dispositif. Plusieurs solutions d'authentifîcation peuvent être utilisées. Le plus sûr est de doter le dispositif d'un capteur biométrique permettant l'identification, par exemple par un dispositif de reconnaissance d'empreinte digitale exécuté sur le dispositif (Match On Card ou MOC en anglais). De ce fait, aucune entrée relative à l'authentifïcation n'est faite sur le terminal du client et n'est donc susceptible d'être capturée par un logiciel malveillant. Alternativement, une authentifïcation par mot de passe peut être faite. Dans ce cas, l'utilisateur ouvre un navigateur WEB par exemple sur le terminal et se connecte au dispositif. Le dispositif possède un serveur WEB embarqué qui propose une page d' authentifïcation. Avantageusement, le trafic entre le terminal et le dispositif 3.8, 4.8 est également protégé par chiffrement. Cela permet de limiter les risques d'attaques par un logiciel malveillant sur le terminal. Une fois que l'utilisateur est authentifié, le dispositif permet avantageusement à celui-ci de sélectionner l'un des services accessibles offerts lors d'une étape 5.3. Cette étape est optionnelle, le dispositif pouvant être configuré pour offrir uniquement l'accès à un service particulier. Cette étape peut être mise en œuvre par l'intermédiaire d'une page WEB transmise par HTTP au terminal. L'utilisateur peut alors sélectionner le service désiré lors d'une étape 5.4 de choix du service. Lorsque le service est choisi, le dispositif établit la connexion chiffrée avec le serveur hébergeant le service choisi lors d'une étape 5.5. Cette connexion chiffrée est réalisée par la couche de sécurisation TLS dans l'exemple de réalisation. Pour ce faire, le dispositif dispose de l'adresse du service ainsi que des moyens d'authentification auprès du serveur, par exemple les identifiants nécessaires à la connexion au serveur ou au service. Ces données confidentielles sont inscrites dans la carte lors d'une étape préalable de personnalisation de celle-ci. Elles bénéficient des techniques de protection tant contre les attaques logicielles que matérielles intrinsèques aux cartes à puce. Cette programmation préalable de la carte peut être faite à l'aide d'un logiciel dédié sur le terminal. Avantageusement, cette étape de personnalisation est faite avant la distribution de la carte à l'utilisateur, par exemple par un prestataire de service pouvant être le gestionnaire d'un des services sécurisés, par exemple un établissement bancaire. Ces paramètres consistent typiquement en une liste de services accessibles et pour chaque service sont disponibles l'adresse du service et les identifiants de connexion, avantageusement un certificat numérique de chiffrement. Une fois la connexion chiffrée établie, le service peut être utilisé de manière classique. Le dispositif fonctionne alors comme relais (proxy en anglais) du trafic HTTP entre le terminal utilisateur et le service. L'utilisateur peut utiliser le service, lors d'une étape 5.6, à l'aide de son navigateur WEB comme s'il était directement connecté au serveur via son terminal. Le trafic HTTP est dirigé vers le dispositif qui le relaie vers le serveur au travers de la connexion chiffrée. Le trafic repasse donc sur le terminal, mais chiffré, le terminal fonctionnant comme simple routeur IP. A la fin de la session, le dispositif ferme la connexion chiffrée lors d'une étape 5.7. Si une connexion, par exemple chiffrée, était établie entre le terminal et le dispositif, cette connexion est également fermée lors de l'étape 5.8. Alternativement, il est possible d'augmenter encore la sécurité du système en autorisant la connexion au dispositif uniquement à partir d'un logiciel client fourni par le système et non pas depuis le navigateur WEB du terminal. Ce logiciel client peut être un navigateur WEB, mais peut également être aussi un client basé sur un protocole différent éventuellement développé pour l'occasion. Avantageusement, ce client est stocké de manière sécurisée et non modifiable sans autorisation sur la carte au sein d'un espace de stockage. Cet espace de stockage peut alors être vu depuis le terminal comme un périphérique de stockage amovible visible depuis le terminal lorsque le dispositif est connecté. Ce logiciel permet l'accès au service sécurisé lorsqu'il est exécuté sur le terminal utilisateur. L'utilisation du dispositif comporte alors une étape préalable de chargement de ce logiciel d'accès depuis le dispositif sur le terminal utilisateur. On évite ainsi toute manipulation et/ou espionnage des échanges par modification du logiciel client.
Ce faisant, l'utilisateur peut se connecter à un service sécurisé sans qu'à aucun moment, l'adresse du service ni les identifiants de connexion soient présents en clair sur le terminal. Éventuellement, ces informations ne sont même jamais portées à la connaissance de l'utilisateur à qui on fournit une carte personnalisée prête à l'emploi.

Claims

REVENDICATIONS
1/ Dispositif d'accès sécurisé à un service distant comportant :
- une carte à puce ; - des moyens de connexion de la carte à puce à un terminal utilisateur connecté à un réseau de communication ; caractérisé en ce qu'il comporte en outre :
- des moyens de communication avec le terminal utilisateur auquel le dispositif est connecté ; - des moyens de communication avec un serveur hébergeant le service distant, ledit serveur étant connecté au réseau de communication, lesdits moyens de communication établissant la communication par l'intermédiaire du terminal utilisateur auquel est connecté le dispositif ;
- des moyens de stockage de l'adresse dudit serveur hébergeant le service distant et de moyens d'authentifîcation auprès de ce serveur ;
- des moyens d'établir une connexion chiffrée entre le dispositif et le serveur hébergeant le service distant à l'aide desdits identifiants de connexion ;
- des moyens de relayer le trafic entre le terminal utilisateur et le serveur par ladite connexion chiffrée.
2/ Dispositif selon la revendication 1, caractérisé en ce qu'il comporte en outre des moyens d'authentifîcation de l'utilisateur.
3/ Dispositif selon la revendication 2, caractérisé en ce que les moyens d'authentifîcation sont des moyens biométriques.
4/ Dispositif selon l'une des revendications 1 à 3, caractérisé en ce que le dispositif comporte en outre des moyens de stockage d'une liste de services accessibles et des moyens d'offrir un choix parmi cette liste.
5/ Dispositif selon l'une des revendications 1 à 4, caractérisé en ce que le dispositif comporte en outre des moyens de stockage d'un logiciel client permettant l'accès au service sécurisé lorsqu'il est exécuté sur le terminal utilisateur. 6/ Procédé de connexion à un service distant caractérisé en ce qu'il comporte les étapes suivantes :
- une étape d'établissement d'une connexion chiffrée entre un dispositif comportant une carte à puce et un serveur distant hébergeant un service sécurisé, ledit dispositif étant connecté à un terminal utilisateur lui-même connecté à un réseau de communication, ledit serveur distant étant accessible par le réseau de communication, la connexion chiffrée étant établie par routage de la communication par le terminal utilisateur, ladite connexion chiffrée étant établie à l'aide d'identifiants de connexion stockés sur ledit dispositif ; - une étape d'utilisation du service depuis le terminal utilisateur, le trafic entre le terminal et le serveur distant étant relayé par ledit dispositif par ladite connexion chiffrée.
Il Procédé selon la revendication 6, caractérisé en ce que le dispositif stockant une liste de services accessibles avec les identifiants correspondants, il comporte en outre :
- une étape de proposition de la liste des services à l'utilisateur ;
- une étape de choix du service avec lequel établir la connexion chiffrée.
8/ Procédé selon l'une des revendications 6 à 7, caractérisé en ce qu'il comporte une étape préalable d'authentifîcation de l'utilisateur.
9/ Procédé selon l'une des revendications 6 à 8, caractérisé en ce qu'il comporte une étape préalable de chargement d'un logiciel d'accès au service distant depuis le dispositif sur le terminal utilisateur.
PCT/EP2010/058108 2009-06-11 2010-06-09 Dispositif et procédé d'accès sécurisé à un service distant WO2010142740A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/376,916 US9185110B2 (en) 2009-06-11 2010-06-09 Device and method for secure access to a remote server
EP10725090A EP2441228A1 (fr) 2009-06-11 2010-06-09 Dispositif et procédé d'accès sécurisé à un service distant

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR09/53907 2009-06-11
FR0953907A FR2946822B1 (fr) 2009-06-11 2009-06-11 Dispositif et procede d'acces securise a un service distant.

Publications (1)

Publication Number Publication Date
WO2010142740A1 true WO2010142740A1 (fr) 2010-12-16

Family

ID=42125944

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2010/058108 WO2010142740A1 (fr) 2009-06-11 2010-06-09 Dispositif et procédé d'accès sécurisé à un service distant

Country Status (4)

Country Link
US (1) US9185110B2 (fr)
EP (1) EP2441228A1 (fr)
FR (1) FR2946822B1 (fr)
WO (1) WO2010142740A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106713509A (zh) * 2017-02-27 2017-05-24 武汉芯光云信息技术有限责任公司 基于aoc光纤的arm云终端系统
FR3076012B1 (fr) * 2017-12-21 2020-01-10 Thales Procede de securisation d'un protocole usb par authentification d'un peripherique usb par un appareil et par chiffrement des echanges entre le peripherique et l'appareil et dispositifs associes
FR3090945B1 (fr) * 2018-12-24 2021-07-09 Blade Procédé de raccordement d’un périphérique distant à un réseau local virtuel
SE546367C2 (en) * 2019-06-28 2024-10-15 Assa Abloy Ab Cryptographic signing of a data item

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2102778B1 (fr) * 2006-12-19 2018-10-31 Telecom Italia S.p.A. Procédé et agencement pour une authentification d'utilisateur sécurisée sur la base d'un dispositif de détection de données biométriques

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
HINZ W ED - POHLMANN N ET AL: "Authentication for Web Services with the Internet Smart Card", 1 January 2008, SECURING ELECTRONIC BUSINESS PROCESSES : ISSE 2008 ; HIGHLIGHTS OF THE INFORMATION SECURITY SOLUTIONS EUROPE 2008 CONFERENCE, VIEWEG + TEUBNER, DE LNKD- DOI:10.1007/978-3-8348-9283-6_38, PAGE(S) 357 - 366, ISBN: 9783834806604, XP008116264 *
LU H K ET AL: "A New Secure Communication Framework for Smart Cards", CONSUMER COMMUNICATIONS AND NETWORKING CONFERENCE, 2009. CCNC 2009. 6TH IEEE, IEEE, PISCATAWAY, NJ, USA, 10 January 2009 (2009-01-10), pages 1 - 5, XP031425432, ISBN: 978-1-4244-2308-8 *
PASCAL URIEN: "TLS-Tandem: A Smart Card for WEB Applications", CONSUMER COMMUNICATIONS AND NETWORKING CONFERENCE, 2009. CCNC 2009. 6TH IEEE, IEEE, PISCATAWAY, NJ, USA, 10 January 2009 (2009-01-10), pages 1 - 2, XP031425704, ISBN: 978-1-4244-2308-8 *
URIEN P: "Internet card, a smart card as a true Internet node", COMPUTER COMMUNICATIONS, ELSEVIER SCIENCE PUBLISHERS BV, AMSTERDAM, NL LNKD- DOI:10.1016/S0140-3664(00)00252-8, vol. 23, no. 17, 1 November 2000 (2000-11-01), pages 1655 - 1666, XP004238469, ISSN: 0140-3664 *

Also Published As

Publication number Publication date
FR2946822B1 (fr) 2011-08-12
US20120084849A1 (en) 2012-04-05
EP2441228A1 (fr) 2012-04-18
FR2946822A1 (fr) 2010-12-17
US9185110B2 (en) 2015-11-10

Similar Documents

Publication Publication Date Title
US9961103B2 (en) Intercepting, decrypting and inspecting traffic over an encrypted channel
EP2619941B1 (fr) Procede, serveur et systeme d'authentification d'une personne
WO2008145558A2 (fr) Procede de securisation d'echange d'information, dispositif, et produit programme d'ordinateur correspondant
WO2011138558A2 (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
EP1095491B1 (fr) Procede, systeme, serveur et dispositif pour securiser un reseau de communication
WO2007115982A2 (fr) Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants
EP3375133B1 (fr) Procede de securisation et d'authentification d'une telecommunication
WO2014064353A1 (fr) Procede de fourniture d'un service securise
Tally et al. Anti-phishing: Best practices for institutions and consumers
EP2441228A1 (fr) Dispositif et procédé d'accès sécurisé à un service distant
EP3549330B1 (fr) Procédé et système pour réaliser une operation sensible au cours d'une session de communication
US20160036792A1 (en) Systems, apparatus, and methods for private communication
CA3029152A1 (fr) Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants
WO2012156365A1 (fr) Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants
Jotwani et al. An analysis of E-Commerce security threats and its related effective measures
FR2887049A1 (fr) Procede de protection contre le piratage d'un terminal client utilisant un connexion securisee avec un serveur sur un reseau public
EP1966974B1 (fr) Systeme securise de saisie et de traitement de donnees d'authentification
EP4105798A1 (fr) Procédé d authentification, dispositif et programme correspondant
WO2012107369A1 (fr) Procede et dispositif de connexion a un service distant depuis un dispositif hote
EP3503500A1 (fr) Procédé pour créer une signature électronique à distance au moyen du protocole fido
Wu Control E-commerce security
WO2005034009A2 (fr) Procede et systeme pour securiser les acces d'un utilisateur a un reseau de communication

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: 10725090

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13376916

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2010725090

Country of ref document: EP