WO2017055716A1 - Procede et dispositif d'authentification ameliores - Google Patents

Procede et dispositif d'authentification ameliores Download PDF

Info

Publication number
WO2017055716A1
WO2017055716A1 PCT/FR2016/052418 FR2016052418W WO2017055716A1 WO 2017055716 A1 WO2017055716 A1 WO 2017055716A1 FR 2016052418 W FR2016052418 W FR 2016052418W WO 2017055716 A1 WO2017055716 A1 WO 2017055716A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
access
encryption
resource
creating
Prior art date
Application number
PCT/FR2016/052418
Other languages
English (en)
Inventor
Antoine BOULANGER
Sylvain PATUREAU MIRAND
Original Assignee
Peugeot Citroen Automobiles Sa
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Peugeot Citroen Automobiles Sa filed Critical Peugeot Citroen Automobiles Sa
Priority to EP16784231.9A priority Critical patent/EP3357212A1/fr
Priority to CN201680057040.7A priority patent/CN108141444B/zh
Publication of WO2017055716A1 publication Critical patent/WO2017055716A1/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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Definitions

  • the invention relates to authentication and rights management in the context of exchanges of data between different computer systems such as an electronic box in a vehicle, mobile devices (smartphones, tablets, laptops, etc.) and landed systems (also called cloud in English).
  • mobile devices smarttphones, tablets, laptops, etc.
  • landed systems also called cloud in English.
  • document US2004230831 discloses an authentication system based on security tokens.
  • This system makes it possible to allow a terminal belonging to a first organization to access a service provider server belonging to a second organization.
  • the first and second organizations form a federation.
  • the user of the terminal belonging to the first organization identifies himself only once and is allowed to access resources of the second organization.
  • Authorizations are carried by tokens issued by a trusted authority and then exchanged by the two organizations.
  • the authentication tokens are limited in time by a period of validity. After the token has expired, it must be renewed with the trusted authority (also known as the authentication server).
  • the renewal request requires a connection (for example of the Internet or 3G type) to communicate with the authentication server.
  • the problem to be solved by the present invention relates to the case: (i) where the service provider is a connected object (for example a telematic box of a motor vehicle) accessible via a wireless link (for example Bluetooth type or NFC) or a wired link, and (ii) where the user is able to access the object (for example a user with a smartphone located outside the vehicle) but without access to an Internet connection (in other words without any means of communicating with the trusted authority issuing the security tokens).
  • a wireless link for example Bluetooth type or NFC
  • NFC wireless link
  • the user is able to access the object (for example a user with a smartphone located outside the vehicle) but without access to an Internet connection (in other words without any means of communicating with the trusted authority issuing the security tokens).
  • the user wishes to control, with the aid of his Smartphone, the unlocking of an opening to gain access to the passenger compartment of the vehicle, while he is at a place without a cover of a network of communication.
  • the invention therefore aims to remedy the aforementioned problems by providing an improved method and an authentication device allowing secure access to a computer resource without requiring permanent communication with an authentication server.
  • step (206) comprises steps of:
  • the invention proposes the creation of a secure storage system of an access token.
  • the access token is kept in a so-called conservation token.
  • the access token is encrypted using encryption data.
  • Token encryption allows for a longer validity period (for example, more than one day) without compromising the security of the system.
  • the user wishes to access the resource, even though he has no means of communication with an authentication server, it decrypts the access token contained in the conservation token .
  • the access token is then ready to use for use with the resource.
  • the security of the system is maintained insofar as only the user is able to provide the data necessary to decrypt the access token.
  • the step of generating the conservation token furthermore includes adding an expiry date to said token the expiration date of the retention token being the same as the expiration date of the access token.
  • the step of encrypting the access token implements a symmetric cryptography method.
  • the encryption information comprises at least Less: an answer to a question, a fingerprint or a voice print.
  • the step of encrypting the access token implements an asymmetric cryptographic method.
  • the encryption information comprises at least one public key of a cryptographic key pair whose private key is stored in a memory of an object held by the user.
  • the method of creating a token according to the invention further comprises a step of signing the access token and the storage token with a private key of the authentication device.
  • the invention also relates to an authorization token for a terminal of a user to access a resource comprising a memory in which a private key is stored, characterized in that it comprises:
  • a first data field comprising at least one identifier associated with an encryption information, at least part of which is intended to be used as an encryption key
  • a second data field comprising an access token, said access token comprising data describing rights granted to the user's terminal on the resource, data describing access rights being with a public key associated with the private key stored in the resource's memory,
  • the access token is encrypted with an encryption key based on at least a portion of the encryption information associated with the identifier contained in the first data field of the preservation token.
  • the invention also relates to a device for authorizing a terminal of a user to access a resource comprising a memory in which a private key is stored, comprising means for generating a preservation token and means for transmitting said token.
  • storage device for the terminal characterized in that the means for generating the conservation token comprise:
  • FIG. 1 illustrates a schematic view of a system comprising an authentication device according to the invention
  • FIG. 2 illustrates a diagram representing steps of the method according to the invention
  • FIG. 3 illustrates a diagram representing substeps of the method according to the invention
  • FIG. 4 shows an example of a token structure according to the prior art
  • FIG. 5 shows an example of a token structure according to the invention.
  • an authentication system comprises at least one terminal 103, a service provider 104 and an authentication authority 101.
  • the access by the terminal 103 to data or services of the service provider 104 requires authentication and authorizations issued by the authentication authority 101.
  • the terminal 103 is a smart mobile phone (also called smartphone in English). But the invention is not limited to this example. Indeed, the terminal 103 may be a laptop, a touch pad or any other connected object (ie capable of exchanging data via a wireless connection).
  • This mobile equipment belongs, for example, to the driver of a vehicle or to one of the passengers of the vehicle.
  • the service provider 104 (or SP for "Service Provider" in English) is an IT resource.
  • SP 104 controls access to data or commands to perform an activity.
  • SP 104 protects access to data and applications. It refuses any access without prior authentication.
  • it redirects the unauthenticated user to an identity provider. Access to the service is therefore restricted. Users must be identified before they can access data or start the execution of an order.
  • the SP 104 is also called resource 104 or box 104.
  • authorization tokens also called token or "identity credentials” in English.
  • the tokens used to transmit the permissions are encrypted (or encrypted) according to an asymmetric cryptography mechanism (also called public key cryptography).
  • a pair of keys is used: a public key for encryption and a private key for decryption.
  • a resource sends a token to another computing resource, it simply encrypts the token to be sent using the recipient's public key. The latter will be able to decipher the message using his private key (which he is alone to know).
  • the tokens incorporate the authorizations that allow access to functions or data on the services hosted on the SP 104.
  • the SP 104 includes a secure storage space capable of storing a private key used to decrypt the authorization tokens.
  • the secure storage space is for example a Trusted Platform Module (TPM) chip, which is a hardware cryptographic component for storing secrets (such as encryption keys) securely.
  • TPM Trusted Platform Module
  • the SP 104 is an electronic box of a motor vehicle.
  • the electronic box is an on-board vehicle that is the boundary of the vehicle data to the outside through various means: cable, wireless protocols (wifi, bluetooth, 3G, etc.).
  • the SP can be a management information system or a system that controls a numerically controlled machine or more generally any connected object (ie capable of exchanging data via a wired or wireless connection) and including a secure storage space capable of storing a private key.
  • the authentication authority 101 (Identity Provider or Identity Provider) is used to authenticate the user as well as to retrieve additional information associated with his identity.
  • the Idp 101 allows users 102 to authenticate and receive tokens on their terminal 103 (personal computer or smartphone) allowing them to be recognized with the SP 104.
  • Idp 101 makes it possible to allow a terminal 103 of a user 102 to access a resource 104.
  • Idp 101 includes means for generating a conservation token and means for issuing said conservation token to the terminal 103.
  • the means for generating the conservation token comprise:
  • means for creating a first data field comprising at least one identifier associated with encryption information, at least part of which is intended to be used as an encryption key
  • means for creating a second data field comprising an access token, said access token comprising data describing rights granted to the terminal 103 of the user 102 on the resource 104;
  • Idp 101 further includes means for electronically signing authorization tokens.
  • the electronic signature makes it possible to guarantee the integrity of a token and to authenticate the author.
  • the electronic signature system uses a pair of keys. A private key used to sign a token and a public key to read the signed token.
  • Such a system generally comprises a public key infrastructure (PKI), in other words an IT resource for generating, distributing and publishing certificates to the various necessary components (SP, IdP, etc.).
  • PKI public key infrastructure
  • IdP 101 and SP 104 each have a certificate of their own.
  • a certificate (or electronic certificate) is a set of data containing at least one public key, at least one identification information (for example: a name, usually stored in a data field called CN for "Common Name” And at least one private key to sign.
  • the system also includes an Internet interface 106 through which a user can authenticate with Idp 101.
  • the chips are generated and used as follows.
  • a token is generated by the Idp 101, in response to a request from a user (previously authenticated to the authentication authority 101).
  • the token is transported by the user's terminal 103 to be finally checked and consumed by the embedded box 104 to allow the user and an application executed on the terminal 103 to access certain functions of the housing 104 (for example unlocking a door of the vehicle).
  • an authorization token is structured, for example, in the following manner (JSON type structure).
  • the authorization token includes:
  • a first datum (access_token) containing the rights of the user encrypted with the public key of the embedded box 104 (for example with an asymmetric encryption algorithm, for example of the RSA type).
  • access_token for example with an asymmetric encryption algorithm, for example of the RSA type.
  • token_type a second data (token_type) whose value is set to "bearer” to indicate that it is a standard access token (as opposed to a storage token).
  • a fifth data token_signature corresponding to a signature of HMAC type is a condensate (or "hash") of the token, generated by means of a hashing algorithm (for example SHA-1) and encrypted with the private key the authentication authority 101 (for example an asymmetric RSA encryption algorithm)
  • SHA-1 hashing algorithm
  • the signature ensures the authenticity of the sender and the integrity (non-alteration) of the message.
  • the invention also relates to a storage token, which can be stored securely (encrypted) on a terminal. In this way, the validity period of such a token can be lengthened while maintaining a high level of security.
  • data of the conservation token are encrypted using a key from one or more data of the user. previously informed.
  • a conservation token is for example structured in the following manner (JSON type structure).
  • the conservation token includes:
  • token_type a first datum indicating a type of token (here "long” or “conservation"), as well as at least one identifier associated with an encryption information (for example question identifiers whose personal answers form the key used to decipher the token contained in the third data (access_token) of the conservation token),
  • a third datum (access_token) containing the data structure of an authorization token, for example as defined above, but encrypted by means of a key issuing from the encryption information corresponding to the identifiers indicated in the first datum. Only this part is sent, once deciphered by the terminal 103, to the housing 104.
  • the invention also relates to a method for authorizing the terminal 103 of the user 102 to access the resource 104.
  • the method comprises steps of:
  • connection information eg an identifier and a password or any other authentication method
  • connection information if the connection information is correct then move to the next step 204, if not connection refusal;
  • This method may be initiated by the user 102 when he wishes to have a storage token on his terminal 103, either as a precaution or in anticipation of a situation where he will have to access the resource 104 without being able to communicate with the user. 'Idp 101.
  • the creation step 206 of the conservation token, by Idp 101, comprises the following substeps:
  • creation 206.2 of a second data field comprising an access token, said access token comprising data describing rights granted to the terminal 103 of the user 102 on the resource 104.
  • the encrypted access token is intended to be decrypted by the user's terminal 102.
  • the access token and the storage token each include a validity date.
  • their validity dates are identical. This then makes it possible to know the date of validity of the access token without having to decipher it (i.e. only by consulting the date of validity of the conservation token).
  • the encryption step 206.4 of the access token implements a symmetric cryptographic method.
  • the key used to encrypt the data is identical to the key used to decrypt the data.
  • the information of encryption includes at least: an answer to a question, a fingerprint or a voice print.
  • the encryption information comprises several answers to questions to which the user has previously responded.
  • the step of encryption 206.4 of the access token implements an asymmetric cryptographic method.
  • the encryption information comprises at least one public key of a cryptographic key pair whose private key is stored in a memory of an object held by the user, for example a secure usb key.
  • an encryption for the access token makes it possible to consider storing this token on the terminal 103 for a duration greater than one day without compromising the security of the resource. Indeed, even if the terminal 103 is stolen by an attacker, it will be unable to use the access token to access the resource, as long as this access token remains encrypted in the storage token.
  • the token To be used and sent to the box, the token must be decrypted using the key that was used for encryption. This key is restored by obtaining from the user, the encryption data (for example, its answers to questions) chosen to encrypt the token.
  • the encryption data for example, its answers to questions
  • the terminal 103 decrypts the token, then transmits it to the housing 104.
  • the box 104 Upon receipt of the token, the box 104 first verifies the signature of Idp 101. For that it calculates the condensate of the token using the same hashing algorithm that used by Idp 101 (for example SHA-1). It also decrypts the signature, using the public key of Idp 101 and using the same algorithm (for example RSA) and obtains the condensate calculated by Idp 101. If the two condensates are identical, the signature is validated. Otherwise, the token is rejected.
  • the same hashing algorithm that used by Idp 101 for example SHA-1
  • RSA the same algorithm
  • the data (access_token), containing the rights of the user, of the access token are then decrypted using the private key of the box 104.
  • the enclosure is then ready to allow access in accordance with the rights specified in the access token.

Abstract

L'invention concerne un procédé de création d'un jeton autorisant un terminal (103) d'un utilisateur (102) à accéder à une ressource comportant une mémoire dans laquelle est stockée une clé privée, comportant des étapes de : - création d'un premier champ de données comportant au moins un identifiant associé à une information de chiffrement, - création d'un deuxième champ de données comportant un jeton d'accès, ledit jeton d'accès comprenant des données décrivant des droits accordés au terminal (103) de l'utilisateur (102) sur la ressource; - chiffrement des données décrivant des droits d'accès, avec une clé publique associée à la clé privée stockée dans la mémoire de la ressource, - chiffrement du jeton d'accès avec une clé de chiffrement basée sur au moins une partie des informations de chiffrement associées à l'identifiant contenu dans le premier champ de donnée du jeton de conservation.

Description

PROCEDE ET DISPOSITIF D'AUTHENTIFICATION AMELIORES
L'invention concerne l'authentification et la gestion des droits dans le cadre d'échanges de données entre différents systèmes informatiques tel qu'un boîtier électronique dans un véhicule, des équipements mobiles (Smartphones, tablettes, ordinateur portable...) et des systèmes débarqués (aussi appelé cloud en anglais).
Il est connu de l'état de la technique d'accéder à une ressource informatique après s'être préalablement authentifié. Il est aussi connu d'utiliser un jeton (physique ou numérique) pour procéder à une authentification auprès de la ressource.
On connaît par exemple par le document US2004230831 un système d'authentification basé sur des jetons de sécurité. Ce système permet d'autoriser un terminal, appartenant à une première organisation, à accéder à un serveur fournisseur de service, appartenant à une deuxième organisation. La première et la deuxième organisation forment une fédération. L'utilisateur du terminal appartenant à la première organisation s'identifie une seule fois et est autorisé à accéder à des ressources de la deuxième organisation. Des autorisations sont transportées par des jetons délivrés par une autorité de confiance puis échangés par les deux organisations.
En général, pour des raisons de sécurité, les jetons d'authentification sont limités dans le temps par une période de validité. Après expiration du jeton, celui-ci doit être renouvelé auprès de l'autorité de confiance (aussi appelé serveur d'authentification). La demande de renouvellement nécessite de disposer d'une connexion (par exemple de type Internet ou 3G) pour communiquer avec le serveur d'authentification.
Cependant, il existe des situations où un utilisateur souhaite accéder à un serveur fournisseur de service sans pour autant disposer d'une connexion à Internet et donc sans pouvoir communiquer avec le serveur d'authentification.
Un tel problème ne se pose pas lorsque le fournisseur de service est un serveur informatique uniquement accessible via une connexion Internet. Dans ce cas, un utilisateur souhaitant accéder à la ressource dispose nécessairement d'un accès à Internet et peut donc récupérer un jeton de sécurité par cet accès Internet.
Le problème que se propose de résoudre la présente invention concerne, le cas : (i) où le fournisseur de service est un objet connecté (par exemple un boîtier télématique d'un véhicule automobile) accessible via une liaison sans fil (par exemple type bluetooth ou NFC) ou une liaison filaire, et (ii) où l'utilisateur est capable d'accéder à l'objet (par exemple un utilisateur muni d'un smartphone situé à l'extérieur du véhicule) mais sans accès à une connexion Internet (autrement dit sans moyen de communiquer avec l'autorité de confiance délivrant les jetons de sécurité). On suppose par exemple que l'utilisateur souhaite commander, à l'aide de son Smartphone, le déverrouillage d'un ouvrant pour accéder à l'habitacle du véhicule, alors qu'il se trouve à un endroit sans couverture d'un réseau de communication.
Rien n'est prévu pour accéder de façon sécurisée à la ressource dans ce cas de figure.
L'invention a donc pour but de remédier aux problèmes précités en proposant un procédé et un dispositif d'authentification améliorés permettant un accès sécurisé à une ressource informatique sans pour autant nécessiter une communication permanente avec un serveur d'authentification.
Elle propose plus précisément à cet effet un procédé pour autoriser un terminal (103) d'un utilisateur (102) à accéder à une ressource (104) comportant une mémoire dans laquelle est stockée une clé privée, comportant des étapes de :
- génération (206) d'un jeton de conservation par un dispositif d'authentification (101 ),
- émission (207) d'un jeton de conservation à destination du terminal (103), caractérisé en ce que ladite étape (206) comporte des étapes de :
- création (206.1 ) d'un premier champ de données comportant au moins un identifiant associé à une information de chiffrement, dont au moins une partie est destinée à être utilisée comme clé de chiffrement ;
- création (206.2) d'un deuxième champ de données comportant un jeton d'accès, ledit jeton d'accès comprenant des données décrivant des droits accordés au terminal (103) de l'utilisateur (102) sur la ressource (104) ;
- chiffrement (206.3) des données décrivant des droits d'accès, avec une clé publique associée à la clé privée stockée dans la mémoire de la ressource (104),
- chiffrement (206.4) du jeton d'accès avec une clé de chiffrement basée sur au moins une partie des informations de chiffrement associées à l'identifiant contenu dans le premier champ de donnée du jeton de conservation.
Pour remédier au problème d'accès au serveur d'authentification, l'invention propose la création d'un système de conservation sécurisé d'un jeton d'accès. Le jeton d'accès est conservé dans un jeton dit de conservation. Le jeton d'accès est chiffré à l'aide de données de chiffrement.
Le chiffrement du jeton permet de lui accorder une durée de validité plus importante (par exemple supérieure à un jour) sans compromettre la sécurité du système. Ainsi, dans le cas où l'utilisateur souhaite accéder à la ressource, alors même qu'il n'a pas de moyen de communication avec un serveur d'authentification, celui-ci déchiffre le jeton d'accès contenu dans le jeton de conservation.
Le jeton d'accès est alors prêt à l'emploi pour être utilisé auprès de la ressource.
La sécurité du système est conservée dans la mesure où seul l'utilisateur est capable de fournir les données nécessaires au déchiffrement du jeton d'accès.
Avantageusement, le jeton d'accès comportant une date de validité indiquant une date d'expiration des droits accordés à l'utilisateur, l'étape de génération du jeton de conservation comporte en outre l'ajout d'une date d'expiration audit jeton de conservation, la date d'expiration du jeton de conservation étant identique à la date d'expiration du jeton d'accès.
Avantageusement, l'étape de chiffrement du jeton d'accès met en œuvre une méthode de cryptographie symétrique.
Avantageusement, les informations de chiffrement comportent au moins : une réponse à une question, une empreinte digitale ou une empreinte vocale.
Avantageusement, l'étape de chiffrement du jeton d'accès met en œuvre une méthode de cryptographie asymétrique.
Avantageusement, les informations de chiffrement comportent au moins une clé publique d'une paire de clé cryptographique dont la clé privée est stockée dans une mémoire d'un objet détenu par l'utilisateur.
Avantageusement, le procédé de création d'un jeton selon l'invention comporte en outre une étape de signature du jeton d'accès et du jeton de conservation avec une clé privé du dispositif d'authentification.
L'invention concerne aussi un jeton d'autorisation pour un terminal d'un utilisateur à accéder à une ressource comportant une mémoire dans laquelle est stockée une clé privée, caractérisé en ce qu'il comporte :
- un premier champ de données comportant au moins un identifiant associé à une information de chiffrement, dont au moins une partie est destinée à être utilisée comme clé de chiffrement ;
- un deuxième champ de données comportant un jeton d'accès, ledit jeton d'accès comprenant des données décrivant des droits accordés au terminal de l'utilisateur sur la ressource, les données décrivant des droits d'accès étant avec une clé publique associée à la clé privée stockée dans la mémoire de la ressource,
et en ce que le jeton d'accès est chiffré avec une clé de chiffrement basée sur au moins une partie des informations de chiffrement associées à l'identifiant contenu dans le premier champ de donnée du jeton de conservation.
L'invention concerne aussi un dispositif pour autoriser un terminal d'un utilisateur à accéder à une ressource comportant une mémoire dans laquelle est stockée une clé privée, comportant des moyens de génération d'un jeton de conservation et des moyens d'émission dudit jeton de conservation à destination du terminal, caractérisé en ce que les moyens de génération du jeton de conservation comportent :
- des moyens de création d'un premier champ de données comportant au moins un identifiant associé à une information de chiffrement, dont au moins une partie est destinée à être utilisée comme clé de chiffrement ;
- des moyens de création d'un deuxième champ de données comportant un jeton d'accès, ledit jeton d'accès comprenant des données décrivant des droits accordés au terminal de l'utilisateur sur la ressource ;
- des moyens de chiffrement des données décrivant des droits d'accès, avec une clé publique associée à la clé privée stockée dans la mémoire de la ressource,
- des moyens de chiffrement du jeton d'accès avec une clé de chiffrement basée sur au moins une partie des informations de chiffrement associées à l'identifiant contenu dans le premier champ de donnée du jeton de conservation.
D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés, sur lesquels:
- la figure 1 illustre une vue schématique d'un système comportant un dispositif d'authentification selon l'invention ;
- la figure 2 illustre un diagramme représentant des étapes du procédé selon l'invention,
- la figure 3 illustre un diagramme représentant des sous-étapes du procédé selon l'invention ;
- la figure 4 montre un exemple de structure de jeton selon l'art connu ;
- la figure 5 montre un exemple de structure de jeton selon l'invention.
Les dessins annexés pourront non seulement servir à compléter l'invention, mais aussi contribuer à sa définition, le cas échéant.
En référence à la figure 1 , un système d'authentification selon l'invention comporte au moins un terminal 103, un fournisseur de service 104 et une autorité d'authentification 101 . L'accès, par le terminal 103, à des données ou des services du fournisseur de service 104 nécessite une authentification et des autorisations délivrées par l'autorité d'authentification 101 .
Dans ce qui suit, on considère à titre d'exemple non limitatif que le terminal 103 est un téléphone mobile intelligent (aussi appelé smartphone en anglais). Mais l'invention n'est pas limitée à cet exemple. En effet, le terminal 103 peut être un ordinateur portable, une tablette tactile ou tout autre objet connecté (i.e. susceptible d'échanger des données via une connexion sans fils). Cet équipement mobile appartient, par exemple, au conducteur d'un véhicule ou à l'un des passagers du véhicule.
Le fournisseur de service 104 (ou SP pour « Service Provider » en anglais) est une ressource informatique. Le SP 104 contrôle l'accès à des données ou des commandes permettant de réaliser une activité. Le SP 104 protège l'accès à des données et à des applications. Il refuse tout accès sans authentification préalable. De façon avantageuse, il redirige l'utilisateur non authentifié vers un fournisseur d'identité. L'accès au service est donc restreint. Les utilisateurs doivent être identifiés avant de pouvoir accéder à une donnée ou lancer l'exécution d'une commande. Dans la suite du document, le SP 104 est aussi appelée ressource 104 ou boîtier 104.
Les authentifications et les autorisations sont communiquées au moyen de jetons d'autorisation aussi appelés token ou encore « identity credentials » en anglais.
Les jetons utilisés pour transmettre les autorisations, sont chiffrés (ou cryptés) selon un mécanisme de cryptographie asymétrique (aussi appelé cryptographie à clé publique). Dans un tel système, on utilise une paire de clés : une clé publique pour le chiffrement et une clé privée pour le déchiffrement. Lorsqu'une ressource envoie un jeton à une autre ressource informatique, il lui suffit de chiffrer le jeton à envoyer au moyen de la clé publique du destinataire. Ce dernier sera en mesure de déchiffrer le message à l'aide de sa clé privée (qu'il est seul à connaître).
Les jetons intègrent les autorisations qui permettent de donner les accès à des fonctions ou des données sur les services hébergés sur le SP 104.
Les autorisations sont vérifiées par le SP soit en faisant une interrogation vers un annuaire de référence soit vers un manifeste permettant de faire des autorisations pouvant être communes dans le jeton mais n'apportant pas les mêmes services sur les différents systèmes. Le SP 104 comporte un espace de stockage sécurisé apte à stocker une clé privée utilisée pour déchiffrer les jetons d'autorisation. L'espace de stockage sécurisé est par exemple une puce TPM (pour Trusted Platform Module), qui est un composant cryptographique matériel permettant de stocker des secrets (tels que des clefs de chiffrement) de manière sécurisée.
Dans ce qui suit, on considère à titre d'exemple non limitatif que le SP 104 est un boîtier électronique d'un véhicule automobile. Le boîtier électronique est un organe embarqué du véhicule qui est la frontière des données véhicule vers l'extérieur au travers de différents moyens : câble, protocoles sans fils (wifi, bluetooth,3G, etc.).
Mais l'invention n'est pas limitée à cet exemple. En effet, le SP peut être un système d'information de gestion ou un système qui pilote une machine à commande numérique ou plus généralement n'importe quel objet connecté (i.e. susceptible d'échanger des données via une connexion avec ou sans fil) et comprenant un espace de stockage sécurisé susceptible de stocker une clé privée.
L'autorité d'authentification 101 (ou fournisseur d'identité ou IdP pour Identity Provider) s'occupe d'authentifier l'utilisateur ainsi que de récupérer des informations additionnelles associées à son identité. L'Idp 101 permet aux utilisateurs 102 de s'authentifier et de recevoir des jetons sur leur terminal 103 (ordinateur personnel ou Smartphone) leur permettant d'être reconnu auprès du SP 104.
Ainsi, l'Idp 101 permet d'autoriser un terminal 103 d'un utilisateur 102 à accéder à une ressource 104.
Pour ce faire l'Idp 101 comporte des moyens de génération d'un jeton de conservation et des moyens d'émission dudit jeton de conservation à destination du terminal 103.
En particulier les moyens de génération du jeton de conservation comportent :
- des moyens de création d'un premier champ de données comportant au moins un identifiant associé à une information de chiffrement, dont au moins une partie est destinée à être utilisée comme clé de chiffrement ; - des moyens de création d'un deuxième champ de données comportant un jeton d'accès, ledit jeton d'accès comprenant des données décrivant des droits accordés au terminal 103 de l'utilisateur 102 sur la ressource 104 ;
- des moyens de chiffrement des données décrivant des droits d'accès, avec une clé publique associée à la clé privée stockée dans la mémoire de la ressource 104,
- des moyens de chiffrement du jeton d'accès avec une clé de chiffrement basée sur au moins une partie des informations de chiffrement associées à l'identifiant contenu dans le premier champ de donnée du jeton de conservation.
De façon avantageuse, l'Idp 101 comporte, en outre, des moyens pour signer, de façon électronique, des jetons d'autorisation. La signature électronique permet de garantir l'intégrité d'un jeton et d'en authentifier l'auteur. Le système de signature électronique utilise une paire de clés. Une clé privée utilisée pour signer un jeton et une clé publique permettant de lire le jeton signé.
Un tel système comporte généralement une infrastructure à clés publiques (ou PKI pour Public Key Infrastructure en anglais) autrement dit une ressource informatique permettant de générer, de distribuer et de publier des certificats aux différents composants nécessaires (SP, IdP...)■ L'IdP 101 et le SP 104, disposent chacun d'un certificat qui leur est propre.
On rappelle qu'un certificat (ou certificat électronique) est un ensemble de données contenant au moins une clé publique, au moins une information d'identification (par exemple : un nom, généralement stocké dans un champ de données dit CN pour « Common Name ») et au moins une clé privée pour signer.
Le système comporte également une interface Internet 106 par l'intermédiaire de laquelle un utilisateur peut s'authentifier auprès de l'Idp 101 .
Dans le système de la figure 1 , les jetons sont générés et utilisés de la façon suivante. Un jeton est produit par l'Idp 101 , en réponse à une demande d'un utilisateur (préalablement authentifié auprès de l'autorité d'authentification 101 ). Le jeton est transporté par le terminal 103 de l'utilisateur pour être finalement vérifié et consommé par le boîtier embarqué 104 pour autoriser l'utilisateur et une application exécutée sur le terminal 103 à accéder à certaines fonctions du boîtier 104 (par exemple le déverrouillage d'un ouvrant du véhicule).
En référence à la figure 4, un jeton d'autorisation est par exemple structuré de la manière suivante (structure de type JSON).
Le jeton d'autorisation comporte :
- une première donnée (access_token) contenant les droits de l'utilisateur, chiffrés avec la clé publique du boîtier embarqué 104 (par exemple avec un algorithme de chiffrement asymétrique par exemple de type RSA). Ainsi, seul le boîtier 104 destinataire peut déchiffrer le contenu du jeton.
- une deuxième donnée (token_type) dont la valeur est fixée à « bearer » pour indiquer qu'il s'agit d'un jeton d'accès standard (par opposition à un jeton de conservation).
- une troisième donnée (expires_in) correspondant à une date de fin de validité du jeton.
- Une quatrième donnée (refresh_token) correspondant à une chaîne aléatoire générée par l'autorité d'authentification 101 permettant de requérir ultérieurement un nouveau jeton sans nouvelle authentification de la part de l'utilisateur,
- Une cinquième donnée token_signature correspondant à une signature de type HMAC (il s'agit d'un condensât (ou « hash ») du jeton, généré grâce à un algorithme de hachage (par exemple SHA-1 ) et chiffré avec la clé privée de l'autorité d'authentification 101 (par exemple un algorithme de chiffrement asymétrique RSA). La signature assure l'authenticité de l'émetteur et l'intégrité (non-altération) du message.
L'invention concerne aussi un jeton de conservation, pouvant être stocké de manière sécurisée (chiffrée) sur un terminal. De cette manière, la durée de validité d'un tel jeton peut être allongée tout en conservant un haut niveau de sécurité.
En plus du chiffrement des autorisations (access_token) avec la clé publique du boîtier 104, des données du jeton de conservation sont chiffrées à l'aide d'une clé issue d'une ou plusieurs données de l'utilisateur préalablement renseignées.
En référence à la figure 5, un jeton de conservation est par exemple structuré de la manière suivante (structure de type JSON). Le jeton conservation comporte :
- une première donnée (token_type) indiquant un type de jeton (ici « long » ou « conservation »), ainsi qu'au moins un identifiant associé à une information de chiffrement (par exemple des identifiants de questions dont les réponses personnelles forment la clé servant à déchiffrer le jeton contenu dans la troisième donnée (access_token) du jeton de conservation),
- une deuxième donnée (expires_in) correspondant à une date de fin de validité du jeton de conservation,
- une troisième donnée (access_token) contenant la structure de données d'un jeton d'autorisation, par exemple telle que définie précédemment, mais chiffrée au moyen d'une clé issue des informations de chiffrement correspondant aux identifiants indiqués dans la première donnée. Seule cette partie est envoyée, une fois déchiffrée par le terminal 103, au boîtier 104.
L'invention concerne aussi un procédé pour autoriser le terminal 103 de l'utilisateur 102 à accéder la ressource 104.
En référence à la figure 2, le procédé comporte des étapes de :
- Saisie 201 , par l'utilisateur 102, des informations de connexion (par exemple un identifiant et un mot de passe ou tout autre méthode d'authentification) dans le terminal 103 ;
- Demande 202 de connexion du terminal 103 à l'Idp 101 ;
- Vérification 203, par l'Idp 101 , des informations de connexion, si les informations de connexion sont correct alors passage à l'étape suivante 204, sinon refus de connexion ;
- Etablissement 204 d'une session de connexion avec le terminal 103 ;
- Demande 205, par le terminal 103, d'un jeton de conservation auprès de l'Idp 101 ;
- Génération 206 du jeton de conservation par l'Idp 101 ; - Envoi 207 du jeton de conservation de l'Idp 101 vers le terminal 103.
Ce procédé peut être initié par l'utilisateur 102 lorsqu'il souhaite disposer d'un jeton de conservation sur son terminal 103, soit par précaution, soit en prévision d'une situation où il devra accéder à la ressource 104 sans pouvoir communiquer avec l'Idp 101 .
L'étape de création 206 du jeton de conservation, par l'Idp 101 , comporte les sous-étapes suivantes :
- création 206.1 d'un premier champ de données comportant au moins un identifiant associé à une information de chiffrement, dont au moins une partie est destinée à être utilisée comme clé de chiffrement. Il s'agit par exemple d'un identifiant d'une question.
- création 206.2 d'un deuxième champ de données comportant un jeton d'accès, ledit jeton d'accès comprenant des données décrivant des droits accordés au terminal 103 de l'utilisateur 102 sur la ressource 104.
- chiffrement 206.3 des données décrivant des droits d'accès, avec une clé publique associée à la clé privée stockée dans la mémoire de la ressource 104. De la sorte les données chiffrées sont uniquement lisible par la ressource 104.
- chiffrement 206.4 du jeton d'accès avec une clé de chiffrement basée sur au moins une partie des informations de chiffrement associées à l'identifiant contenu dans le premier champ de donnée du jeton de conservation. Le jeton d'accès chiffré est destiné à être déchiffré par le terminal 103 de l'utilisateur 102.
Selon une caractéristique de l'invention, le jeton d'accès et le jeton de conservation comportent chacun une date de validité. De façon avantageuse, leurs dates de validité sont identiques. Ceci permet alors de connaître la date de validité du jeton d'accès sans avoir à le déchiffrer (i.e. uniquement en consultant la date de validité du jeton de conservation).
Selon un premier mode de réalisation, l'étape de chiffrement 206.4 du jeton d'accès met en œuvre une méthode de cryptographie symétrique. Autrement dit, la clé utilisée pour chiffrer les données est identique à la clé utilisée pour déchiffrer les données. Dans ce cas les informations de chiffrement comportent au moins : une réponse à une question, une empreinte digitale ou une empreinte vocale.
De façon avantageuse, les informations de chiffrement comportent plusieurs réponses à des questions auquel l'utilisateur a préalablement répondu.
Selon un deuxième mode de réalisation, l'étape de chiffrement 206.4 du jeton d'accès met en œuvre une méthode de cryptographie asymétrique. Dans ce cas, les informations de chiffrement comportent au moins une clé publique d'une paire de clé cryptographique dont la clé privée est stockée dans une mémoire d'un objet détenu par l'utilisateur par exemple une clé usb sécurisée.
L'utilisation d'un chiffrement pour le jeton d'accès permet d'envisager le stockage de ce jeton sur le terminal 103 pour une durée supérieure à une journée sans pour autant compromettre la sécurité de la ressource. En effet, même si le terminal 103 est dérobé par un attaquant, celui-ci sera incapable d'utiliser le jeton d'accès pour d'accéder à la ressource, tant que ce jeton d'accès reste chiffré dans le jeton de conservation.
Pour être utilisé et envoyé au boîtier, le jeton doit être déchiffré au moyen de la clé ayant été utilisée pour le chiffrement. Cette clé est reconstituée en obtenant de la part de l'utilisateur, les données de chiffrement (par exemple, ses réponses aux questions) choisies pour chiffrer le jeton.
Si les données de chiffrement sont correctement renseignées, le terminal 103 déchiffre le jeton, puis le transmet au boîtier 104.
A la réception du jeton, le boîtier 104 vérifie d'abord la signature de l'Idp 101 . Pour cela il calcule le condensât du jeton au moyen du même algorithme de hachage que celui utilisé par l'Idp 101 (par exemple SHA-1 ). Il déchiffre par ailleurs la signature, au moyen de la clé publique de l'Idp 101 et en utilisant le même algorithme (par exemple RSA) et obtient le condensât calculé par l'Idp 101 . Si les deux condensais sont identiques, la signature est validée. Sinon, le jeton est rejeté.
Les données (access_token), contenant les droits de l'utilisateur, du jeton d'accès sont ensuite déchiffrées à l'aide de la clé privée du boîtier 104. Le boîtier est alors prêt à autoriser des accès conformément aux droits spécifiés dans le jeton d'accès.

Claims

REVENDICATIONS
1 . Procédé de création d'un jeton autorisant un terminal (103) d'un utilisateur (102) à accéder à une ressource (104) comportant une mémoire dans laquelle est stockée une clé privée, comportant des étapes de :
- génération (206) d'un jeton de conservation par un dispositif d'authentification (101 ),
- émission (207) du généré jeton de conservation à destination du terminal
(103) ,
caractérisé en ce que ladite étape (206) de génération du jeton de conservation comporte des étapes de :
- création (206.1 ) d'un premier champ de données comportant au moins un identifiant associé à une information de chiffrement, dont au moins une partie est destinée à être utilisée comme clé de chiffrement ;
- création (206.2) d'un deuxième champ de données comportant un jeton d'accès, ledit jeton d'accès comprenant des données décrivant des droits accordés au terminal (103) de l'utilisateur (102) sur la ressource (104) ;
- chiffrement (206.3) des données décrivant des droits d'accès, avec une clé publique associée à la clé privée stockée dans la mémoire de la ressource
(104) ,
- chiffrement (206.4) du jeton d'accès avec une clé de chiffrement basée sur au moins une partie des informations de chiffrement associées à l'identifiant contenu dans le premier champ de donnée du jeton de conservation.
2. Procédé de création d'un jeton selon la revendication 1 , caractérisé en ce que le jeton d'accès comportant une date de validité indiquant une date d'expiration des droits accordés à l'utilisateur, l'étape de génération (206) du jeton de conservation comporte en outre l'ajout d'une date d'expiration audit jeton de conservation, la date d'expiration du jeton de conservation étant identique à la date d'expiration du jeton d'accès.
3. Procédé de création d'un jeton selon l'une des revendications précédentes caractérisé en ce que, l'étape de chiffrement (206.4) du jeton d'accès met en œuvre une méthode de cryptographie symétrique.
4. Procédé de création d'un jeton selon la revendication précédente, caractérisé en ce que les informations de chiffrement comportent au moins : une réponse à une question, une empreinte digitale ou une empreinte vocale.
5. Procédé de création d'un jeton selon l'une des revendications 1 ou 2, caractérisé en ce que, l'étape de chiffrement (206.4) du jeton d'accès met en œuvre une méthode de cryptographie asymétrique.
6. Procédé de création d'un jeton selon la revendication précédente, caractérisé en ce que les informations de chiffrement comportent au moins une clé publique d'une paire de clé cryptographique dont la clé privée est stockée dans une mémoire d'un objet détenu par l'utilisateur.
7. Procédé de création d'un jeton selon l'une des revendications précédentes caractérisé en ce qu'il comporte en outre une étape de signature du jeton d'accès et du jeton de conservation avec une clé privé du dispositif d'authentification (101 ).
8. Jeton d'autorisation pour un terminal (103) d'un utilisateur (102) à accéder à une ressource (104) comportant une mémoire dans laquelle est stockée une clé privée, caractérisé en ce qu'il comporte :
- un premier champ de données comportant au moins un identifiant associé à une information de chiffrement, dont au moins une partie est destinée à être utilisée comme clé de chiffrement ;
- un deuxième champ de données comportant un jeton d'accès, ledit jeton d'accès comprenant des données décrivant des droits accordés au terminal (103) de l'utilisateur (102) sur la ressource (104), les données décrivant des droits d'accès étant avec une clé publique associée à la clé privée stockée dans la mémoire de la ressource (104),
et en ce que le jeton d'accès est chiffré avec une clé de chiffrement basée sur au moins une partie des informations de chiffrement associées à l'identifiant contenu dans le premier champ de donnée du jeton de conservation.
9. Dispositif (101 ) de création d'un jeton autorisant un terminal (103) d'un utilisateur (102) à accéder à une ressource (104) comportant une mémoire dans laquelle est stockée une clé privée, comportant des moyens de génération d'un jeton de conservation et des moyens d'émission dudit jeton de conservation à destination du terminal (103), caractérisé en ce que les moyens de génération du jeton de conservation comportent :
- des moyens de création d'un premier champ de données comportant au moins un identifiant associé à une information de chiffrement, dont au moins une partie est destinée à être utilisée comme clé de chiffrement ;
- des moyens de création d'un deuxième champ de données comportant un jeton d'accès, ledit jeton d'accès comprenant des données décrivant des droits accordés au terminal (103) de l'utilisateur (102) sur la ressource (104) ;
- des moyens de chiffrement des données décrivant des droits d'accès, avec une clé publique associée à la clé privée stockée dans la mémoire de la ressource (104),
- des moyens de chiffrement du jeton d'accès avec une clé de chiffrement basée sur au moins une partie des informations de chiffrement associées à l'identifiant contenu dans le premier champ de donnée du jeton de conservation.
PCT/FR2016/052418 2015-09-29 2016-09-23 Procede et dispositif d'authentification ameliores WO2017055716A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP16784231.9A EP3357212A1 (fr) 2015-09-29 2016-09-23 Procede et dispositif d'authentification ameliores
CN201680057040.7A CN108141444B (zh) 2015-09-29 2016-09-23 经改善的认证方法和认证装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1559165A FR3041798B1 (fr) 2015-09-29 2015-09-29 Procede et dispositif d'authentification ameliores
FR1559165 2015-09-29

Publications (1)

Publication Number Publication Date
WO2017055716A1 true WO2017055716A1 (fr) 2017-04-06

Family

ID=55178113

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2016/052418 WO2017055716A1 (fr) 2015-09-29 2016-09-23 Procede et dispositif d'authentification ameliores

Country Status (4)

Country Link
EP (1) EP3357212A1 (fr)
CN (1) CN108141444B (fr)
FR (1) FR3041798B1 (fr)
WO (1) WO2017055716A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3720165A1 (fr) * 2019-03-30 2020-10-07 Illotros GmbH Procédé pour fournir au moins une identité et des droits
CN112260838A (zh) * 2020-10-15 2021-01-22 四川长虹电器股份有限公司 一种基于jwt的自动续签认证方法

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3064960B1 (fr) * 2017-04-05 2021-12-03 Renault Sas Procede et systeme de deverrouillage a distance d un vehicule automobile
FR3082089B1 (fr) * 2018-05-31 2021-12-10 Renault Sas Procede et systeme de deverrouillage a distance d'un vehicule automobile
CN110149328B (zh) * 2019-05-22 2023-01-31 平安科技（深圳）有限公司 接口鉴权方法、装置、设备及计算机可读存储介质
CN110753345B (zh) * 2019-10-08 2022-11-25 武汉光庭信息技术股份有限公司 一种TBox通信方法及TBox装置
EP4248343A1 (fr) * 2020-11-23 2023-09-27 Volvo Truck Corporation Authentification et autorisation hors ligne pour dispositifs en réseau
CN116491103A (zh) * 2021-01-08 2023-07-25 Oppo广东移动通信有限公司 访问令牌处理方法、设备和云端
CN114157470B (zh) * 2021-11-29 2024-01-19 惠州Tcl移动通信有限公司 一种令牌管理方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010039620A1 (en) * 2000-05-08 2001-11-08 Berry Onni Michael Method for protecting a memory card, and a memory card
EP2151795A1 (fr) * 2008-08-08 2010-02-10 France Telecom Fourniture de coupon électronique sécurisé sur un dispositif mobile
EP2743868A1 (fr) * 2012-12-14 2014-06-18 Seven Principles AG Clé de véhicule virtuel
WO2015092261A1 (fr) * 2013-12-19 2015-06-25 Orange Système et procédé pour fournir un service a l'utilisateur d'un terminal mobile

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7548620B2 (en) * 2004-02-23 2009-06-16 Verisign, Inc. Token provisioning
CN103326862B (zh) * 2013-06-20 2017-02-22 天地融科技股份有限公司 电子签名方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010039620A1 (en) * 2000-05-08 2001-11-08 Berry Onni Michael Method for protecting a memory card, and a memory card
EP2151795A1 (fr) * 2008-08-08 2010-02-10 France Telecom Fourniture de coupon électronique sécurisé sur un dispositif mobile
EP2743868A1 (fr) * 2012-12-14 2014-06-18 Seven Principles AG Clé de véhicule virtuel
WO2015092261A1 (fr) * 2013-12-19 2015-06-25 Orange Système et procédé pour fournir un service a l'utilisateur d'un terminal mobile

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3720165A1 (fr) * 2019-03-30 2020-10-07 Illotros GmbH Procédé pour fournir au moins une identité et des droits
CN112260838A (zh) * 2020-10-15 2021-01-22 四川长虹电器股份有限公司 一种基于jwt的自动续签认证方法

Also Published As

Publication number Publication date
CN108141444A (zh) 2018-06-08
CN108141444B (zh) 2020-12-25
FR3041798B1 (fr) 2017-10-27
EP3357212A1 (fr) 2018-08-08
FR3041798A1 (fr) 2017-03-31

Similar Documents

Publication Publication Date Title
EP3547202B1 (fr) Méthode d'accès à des données anonymisées
EP3357212A1 (fr) Procede et dispositif d'authentification ameliores
US20200213283A1 (en) Key rotation techniques
EP3395006B1 (fr) Procédé de gestion d'une identité de confiance
EP3547203A1 (fr) Méthode et système de gestion d'accès à des données personnelles au moyen d'un contrat intelligent
US9300639B1 (en) Device coordination
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
WO2015193578A1 (fr) Procede et systeme d'authentification au moyen de jetons
US20220014354A1 (en) Systems, methods and devices for provision of a secret
FR3066666A1 (fr) Procede de securisation d'une communication sans gestion d'etats
EP1514377A1 (fr) Procede et dispositif d'interface pour echanger de maniere protegee des donnees de contenu en ligne
EP3532973A1 (fr) Procédé d'installation d'un certificat dans un calculateur de véhicule, calculateur et système associés
FR3113800A1 (fr) Echange de données entre un client et un dispositif distant, par exemple un module sécurisé
FR3041841A1 (fr) Procede et dispositif pour acceder a une ressource a l’aide d’un jeton chiffre
EP2911365B1 (fr) Procédé et système de sécurisation de transactions offertes par une pluralité de services entre un appareil mobile d'un utilisateur et un point d'acceptation
FR3073998B1 (fr) Procede numerique de controle d'acces a un objet, une ressource ou service par un utilisateur
EP2842290B1 (fr) Procédé et système de communication par ordinateur pour l'authentification d'un système client
KR100892941B1 (ko) 이동통신단말기를 이용한 보안처리 방법
EP3437294B1 (fr) Systeme de commande d'un vehicule a distance
FR3057420A1 (fr) Procede et systeme de synchronisation d’une heure d’un calculateur d’un vehicule avec celle d’un serveur distant
FR3044500A1 (fr) Procede et systeme d'acces, par un serveur, a des donnees confidentielles disponibles aupres d'un fournisseur de service.
FR3093887A1 (fr) Procédé pour délivrer, à un dispositif nomade, une autorisation d’accès à un calculateur connecté d’un véhicule
WO2023057652A1 (fr) Application de sécurité pour un dispositif informatique, et architecture de sécurité correspondante
FR3044501A1 (fr) Procede de transmission, par un terminal, de donnees confidentielles depuis un calculateur telematique de vehicule vers un serveur
FR2990818A1 (fr) Procede de transfert et de stockage securise de documents et appareils associes au procede.

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE