EP3158710A1 - Procede et systeme d'authentification au moyen de jetons - Google Patents

Procede et systeme d'authentification au moyen de jetons

Info

Publication number
EP3158710A1
EP3158710A1 EP15733809.6A EP15733809A EP3158710A1 EP 3158710 A1 EP3158710 A1 EP 3158710A1 EP 15733809 A EP15733809 A EP 15733809A EP 3158710 A1 EP3158710 A1 EP 3158710A1
Authority
EP
European Patent Office
Prior art keywords
token
service provider
application
request
electronic equipment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP15733809.6A
Other languages
German (de)
English (en)
Inventor
Sylvain PATUREAU MIRAND
Carmela TRONCOSO
David CHAVEZ DIEGUEZ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PSA Automobiles SA
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
Publication of EP3158710A1 publication Critical patent/EP3158710A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • 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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/062—Pre-authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys

Definitions

  • the invention relates to authentication and rights management in the context of exchanges of data between different computer systems such as
  • a user registers an identity with an identity provider.
  • the identity provider requests the user to provide appropriate credentials.
  • These receipts include a ticket
  • the invention therefore aims to overcome the aforementioned drawbacks by providing a method of authenticating an application executed on a connected terminal, the terminal is not necessarily provided with a security device.
  • the invention makes it possible to receive authentications and authorizations from a terminal that does not include specific security equipment.
  • the transmission of these authentications and these authorizations is ensured by means of authorization tokens which are encrypted and readable only by the service provider.
  • the service provider stores the decryption key in an internal memory.
  • the authentication method according to the invention further comprises steps of:
  • the token verification step further includes verifying the signature of the token, the token being valid if it is signed by the identity provider.
  • the token comprises: an identifier of a user of the application, a unique identifier of the service provider, authorizations, and an identifier of the application.
  • the authentication method according to the invention further comprises a step of authenticating the user with the identity provider.
  • the invention also relates to electronic equipment comprising a memory storing data characterized in that it comprises: means for receiving a data access request, transmission means, a request for a token valid,
  • Means for receiving an encrypted token, means for verifying the token comprising means for decrypting the token with a private key, said private key being stored in a secure memory of said electronic equipment, means for opening the access to the data.
  • the invention also relates to a vehicle comprising electronic equipment according to the invention.
  • the invention also relates to an authentication system comprising electronic equipment according to the invention and / or a vehicle according to the invention.
  • FIG. 1 illustrates a schematic view of the system according to the invention
  • FIG. 2 illustrates a diagram representing steps of the method according to the invention
  • FIG. 3 illustrates a diagram showing additional steps of the method according to the invention.
  • the authentication system comprises at least one terminal 103, a service provider 104 and an authentication authority 101.
  • the invention makes it possible to transmit authentications and authorizations between elements embedded in the vehicle and landed elements. The transmission of these authentications
  • authorization tokens as called token or "identity credentials” in English.
  • 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 is a smart mobile phone (also called smartphone in English). But the invention is not limited to this example. Indeed, 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 is a smart mobile phone (also called smartphone in English). But the invention is not limited to this example. Indeed, the terminal 103
  • 5,103 may be a laptop, touch pad, or other connected object (i.e. capable of exchanging data over a wireless connection).
  • This mobile equipment or connected object belongs, for example, to the driver of a vehicle or to one of the passengers of the vehicle.
  • SP 104 is a computer 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.
  • the tokens used to transmit the authorizations are encrypted (or encrypted) according to an asymmetric cryptography mechanism (also called public key cryptography).
  • an asymmetric cryptography mechanism also called public key cryptography
  • a key pair 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 with the help of his private key (he is alone in
  • Tokens are also signed by a trusted authority (Idp 101) to ensure that they are compliant and that they come from an authorized source.
  • Idp 101 a trusted authority
  • the tokens incorporate the authorizations for giving access to functions or data on the services hosted on the infrastructures, in partners or on connected boxes (SPs).
  • Authorizations are verified by the SP or by making a query to a reference directory or to a manifest to make permissions that can be common in the token but not providing the same services on different systems.
  • the SP 104 comprises a
  • 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 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 104 'or the system that controls a numerically controlled machine or more generally any connected object (ie capable of exchanging data via a wireless connection) and including a secure storage space capable of storing a
  • Identity Provider 101 (or IdP for Identity Provider) is responsible for authenticating the user as well as retrieving additional information associated with his identity.
  • Idp 101 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.
  • the Idp 101 comprises means for encrypting the token.
  • the token is encrypted using a public key associated with the SP 104 for which the token is intended.
  • the encrypted token is only readable by the SP to which it is destined.
  • the identity provider enables the users 102 to authenticate and receive tokens on their PC or smartphone 103 enabling them to be recognized and to carry authorizations on infrastructures
  • the system also includes a public key infrastructure (PKI) 1 10 (PKI)
  • PKI public key infrastructure
  • a PKI is a computer resource for generating, distributing and publishing certificates
  • 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 a client database 1 1 1 for identifying a client, authenticating it and assigning services that are assigned on an SP 104.
  • the system also includes a vehicle database 1 12 to identify the SPs and to join the identification of the SP and its certificate (the vehicle with its VIN for Vehicle Identifier Number - a unique identifier associated with the vehicle, its UIN Unique Identifier Number - a unique identifier associated with the box and the link to the associated certificate).
  • vehicle database 1 12 to identify the SPs and to join the identification of the SP and its certificate (the vehicle with its VIN for Vehicle Identifier Number - a unique identifier associated with the vehicle, its UIN Unique Identifier Number - a unique identifier associated with the box and the link to the associated certificate).
  • the system also includes a service database 1 13 listing services available on the SPs that can be assigned to the clients (service catalog).
  • Figure 2 shows a diagram illustrating the different steps of the method according to the invention.
  • the method firstly comprises the connection 201 of the telephone 103 to the electronic control unit 104 of a vehicle.
  • the connection is a wireless connection (eg wifi, bluetooth or 3G).
  • the next step is startup 202, at the instruction of the user of an application, the application being executed on the telephone 103. It is assumed that the application requires the use of data or commands provided by the control unit. 104. In this example, it is considered that
  • the application allows remote opening of the vehicle using the phone 103.
  • the application transmits, via the telephone 103, a request for access to data (and / or commands) intended for the control unit 104.
  • the application must in particular be authorized to operate the commands of openings and closures of the vehicle.
  • the controller 104 In response to this access request, the controller 104 requests the application a valid authorization token.
  • the application If the application has a valid token then it transmits it to the electronic box 104 otherwise the electronic box 104 redirects the application 205 to the Idp 101.
  • the application then requests 206 an authorization token at Idp 101.
  • This request specifies to which SP is intended the token as well as the necessary authorizations for the execution of the application.
  • the next step is user authentication 207 to Idp 101.
  • This authentication can be done according to different means according to art) known, for example, with an identifier and a password.
  • Idp 101 creates and issues a token to the application.
  • the token is signed with the private key of Idp 101.
  • the token is encrypted using the public key of the electronic box 104, so that only the electronic box 104 is able to decrypt the token.
  • the token also includes a description of the permissions granted by Idp 101.
  • the token is in an OAuth format, a description of which is available, on the filing date of the patent application, on the internet site "http://oauth.net/”.
  • the application transmits the token to the control unit 104.
  • the controller 104 performs a token check and if the check is positive (that is, if the token is valid) then the controller 104 opens access to the data in accordance with the permissions indicated in the token.
  • Verification includes verifying the signature of the token.
  • the control unit 104 uses the public key of the Idp 101 for this check.
  • the CN field or "common name" contained in the certificate is also used to check the provenance of the token. CN must match the name of the authority of
  • the name of the authorized signing authority is stored in a memory of the SP 104, advantageously, the secure memory of the SP 104.
  • the verification also includes the decryption of the token.
  • the token is decrypted with the private key of the electronic box 104.
  • the electronic unit 104 extracts the token, the identifier of the user, the identifier of the electronic unit 104 called UIN (for Unique Identifier Number), the identifier of the application and the granted permissions.
  • UIN for Unique Identifier Number
  • SP 104 also verifies that the permissions described in the token correspond to the permissions requested by the application in the access request. If not, access to the data is denied.
  • the authorizations are advantageously grouped together, the token then indicating the sets of permissions granted by Idp 101. To match these sets and permissions, the electronics package 104 uses a lookup table called manifest.
  • a token is generated to authenticate. It is encrypted with the public key of the SP 104 certificate and signed with the private key of the Idp 101 certificate.
  • the token is a kind of container guaranteeing the authenticity of its transmitter. This container can only be opened by the vehicle for which it is intended.
  • the invention also makes it possible to transmit authentications and authorizations from an on-board electronic box. in a vehicle to landed service providers.
  • the transmission of these authentications and these authorizations are also ensured by means of authorization tokens.
  • These authorization tokens are distributed by a second Idp 101 'dedicated to the identification of vehicles.
  • the authentication method further comprises a step 301 for establishing a secure network connection between the electronic box 104 and the second Idp 101 '.
  • the electronic box 104 authenticates with the second Idp 101 '.
  • the authentication is performed with a certificate stored in the secure memory of the electronic box 104.
  • the electronic box 104 requests 302 an authorization token at the second Idp 101 '. This request specifies to which SP is intended the token as well as the necessary authorizations.
  • the second Idp 101 creates and issues 303 a token to
  • the token is signed with the private key of the second Idp 101 '.
  • the token is encrypted using the public key of the SP 400, so that only the SP 400 is able to decrypt the token.
  • the electronic box 104 In response to receiving the token, the electronic box 104
  • the SP 400 Upon receipt of the token, the SP 400 performs token verification and if the verification is positive (that is, if the token is valid) then the SP 400 opens access to the data according to the permissions indicated in the token.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Lock And Its Accessories (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé d'authentification d'une application, exécutée sur un terminal (103), auprès d'un fournisseur de service (104), comportant des étapes de : - Réception d'une demande (203) d'accès à des données, par le fournisseur de service (104), - En réponse à la demande (203), l'émission, par le fournisseur de service (104), d'une demande (204) d'un jeton valide, - Réception (209), par fournisseur de service (104), d'un jeton chiffré, - Vérification du jeton, au cours de laquelle le jeton est déchiffré avec une clé privée, ladite clé privée étant stockée par le fournisseur de service (104), - Ouverture (210) d'un accès aux données.

Description

PROCEDE ET SYSTEME D'AUTHENTIFICATION AU MOYEN DE
JETONS
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
5 qu'un boîtier électronique dans un véhicule, des équipements mobiles (Smartphones, tablettes, ordinateur portable...) et de systèmes débarqués (aussi appelé cloud en anglais).
On connaît, par le document WO201 1031272, un procédé pour une authentification et une connexion sécurisées. Le procédé utilise un module de
) plateforme sécurisée pour l'authentification et l'accès à des données. Selon ce procédé, un utilisateur enregistre une identité avec un fournisseur d'identité. Lorsque l'utilisateur se connecte à un fournisseur de services au moyen de cette identité, le fournisseur d'identité demande à l'utilisateur de fournir des justificatifs appropriés. Ces justificatifs comprennent un ticket
5 généré sur la plateforme sécurisée. Ceci permet à l'utilisateur de se connecter au fournisseur d'identité sans avoir besoin d'un mot de passe.
L'inconvénient d'un tel procédé est que l'utilisateur doit avoir accès à une plateforme sécurisée (autrement dit, un matériel spécifique) pour enregistrer une identité. Avec un tel procédé, un utilisateur ne peut pas
) s'identifier avec un téléphone mobile.
L'invention a donc pour but de remédier aux inconvénients précités en fournissant un procédé d'authentification d'une application exécutée sur un terminal connecté, le terminal n'étant pas forcément pourvu d'un dispositif de sécurité.
5 Elle propose plus précisément à cet effet un procédé d'authentification d'une application, exécutée sur un terminal, auprès d'un fournisseur de service, comportant des étapes de :
Réception d'une demande d'accès à des données, par le fournisseur de service,
) - En réponse à la demande, l'émission, par le fournisseur de service, d'une demande d'un jeton valide, Réception, par fournisseur de service, d'un jeton chiffré,
Vérification de la validité du jeton, au cours de laquelle le jeton est déchiffré avec une clé privée, ladite clé privée étant stockée par le fournisseur de service,
5 - Ouverture, par le fournisseur de service d'un accès aux données, si le jeton est valide.
L'invention permet de recevoir des authentifications et des autorisations provenant d'un terminal ne comportant pas d'équipements de sécurité spécifiques. La transmission de ces authentifications et de ces ) autorisations est assurée au moyen de jetons d'autorisation qui sont chiffrés et lisible uniquement par le fournisseur de service. Le fournisseur de service stocke la clé de déchiffrement dans un mémoire interne.
Avantageusement, le procédé d'authentification selon l'invention comporte, en outre, des étapes de :
5 - Redirection, de l'application, vers un fournisseur d'identité,
Envoi, par l'application, d'une demande d'un jeton, à destination du fournisseur d'identité,
Création, par le fournisseur d'identité, d'un jeton dédié au fournisseur de service, ledit jeton étant signé et chiffré,
) - Transmission du jeton à l'application, l'application transmettant le jeton au fournisseur de service.
Selon une caractéristique de l'invention, l'étape de vérification du jeton comporte, en outre, la vérification de la signature du jeton, le jeton étant valide s'il est signé par le fournisseur d'identité.
5 De préférence, le jeton comporte : un identifiant d'un 'utilisateur de l'application, un identifiant unique du fournisseur de service, des autorisations, et un identifiant de l'application.
Avantageusement, le procédé d'authentification selon l'invention comporte en outre une étape d'authentification de l'utilisateur auprès du ) fournisseur d'identité. L'invention concerne aussi un équipement électronique comportant une mémoire stockant des données caractérisé en ce qu'il comporte : des moyens de réception d'une demande d'accès aux données, des moyens d'émission, d'une demande d'un jeton valide,
5 - des moyens de réception d'un jeton chiffré, des moyens de vérification du jeton comportant des moyens de déchiffrement du jeton avec une clé privée, ladite clé privée étant stockée dans un mémoire sécurisée dudit équipement électronique, des moyens d'ouverture d'un accès aux données.
) L'invention concerne aussi un véhicule comportant un équipement électronique selon l'invention.
L'invention concerne aussi un système d'authentification comportant un équipement électronique selon l'invention et/ou un véhicule selon l'invention.
5 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 du système 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 étapes supplémentaires du procédé 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.
5 En référence à la figure 1 , le 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'invention permet de transmettre des authentifications et des autorisations entre des éléments embarqués dans le véhicule et des éléments débarqués. La transmission de ces authentifications
) et de ces autorisations est assurée au moyen de jetons d'autorisation aussi appelés token ou encore « identity credentials » en anglais.
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
5 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 (ou objet connecté) appartient, par exemple, au conducteur d'un véhicule ou à l'un des passagers du véhicule.
Le fournisseur de service 104, 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 aux données et aux 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.
5 Les utilisateurs doivent être identifiés avant de pouvoir accéder à une donnée ou lancer l'exécution d'une commande.
Selon une caractéristique de l'invention, les jetons, utilisés pour transmettre les autorisations, sont chiffrés (ou crypté) 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 à
5 connaître).
Les jetons sont, en outre, signés par une autorité de confiance (l'Idp 101 ) pour garantir qu'ils sont bien conformes et qu'ils proviennent bien d'une source autorisée.
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 les infrastructures, chez des partenaires ou sur les boîtiers connectés (les SP).
Les autorisations sont vérifiées par les 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.
Selon une caractéristique de l'invention, le SP 104 comporte un
5 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.).
5 Mais l'invention n'est pas limitée à cet exemple. En effet, le SP peut être un système d'information de gestion 104' ou le 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 sans fil) et comprenant un espace de stockage sécurisé susceptible de stocker une
) clé privée.
Le fournisseur d'identité 101 (ou IdP pour Identity Provider) s'occupe d'authentifier l'utilisateur ainsi que de récupérer des informations additionnelles associées à son identité.
Selon une caractéristique de l'invention, l'Idp 101 comporte des 5 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 pour permettant de lire le jeton signé.
) Selon une caractéristique de l'invention, l'Idp 101 comporte des moyens pour chiffrer le jeton. Le jeton est chiffré à l'aide d'une clé publique associée au SP 104 auquel est destiné le jeton.
De la sorte, le jeton chiffré est uniquement lisible par le SP auquel il est destiné.
Le fournisseur d'identité permet aux utilisateurs 102 de s'authentifier et de recevoir des jetons sur leur PC ou Smartphone 103 leur permettant d'être reconnu et de porter des autorisations sur des infrastructures
5 débarquées mais aussi de les utiliser sur les boîtiers connectés pour accéder à des fonctions spécifiques.
Le système comporte aussi une infrastructure à clés publiques 1 10 (ou PKI pour Public Key Infrastructure en anglais) Une PKI est un 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 les différents SP 104, 104' dispose 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 5 un champ de données dit CN pour « Common Name ») et au moins une clé privée pour signer.
Le système comporte aussi une base de données de clients 1 1 1 permettant d'identifier un client, de l'authentifier et d'attribuer les services qui sont attribués sur un SP 104.
) Le système comporte aussi une base de données de véhicules 1 12 permettant d'identifier les SP et de faire la jonction de l'identification du SP et de son certificat (le véhicule avec son VIN pour Véhicule Identifiant Number - un identifiant unique associé au véhicule, son UIN Unique Identifiant Number - un identifiant unique associé au boîtier et le lien vers le certificat associé).
5 Le système comporte aussi une base de données de services 1 13 répertoriant des services disponibles sur les SP et pouvant être attribués aux clients (catalogue des services).
La figure 2 montre un diagramme illustrant les différentes étapes du procédé selon l'invention.
) Le procédé comporte tout d'abord la connexion 201 du téléphone 103 au boîtier électronique 104 d'un véhicule. La connexion est une connexion sans fil (par exemple wifi, bluetooth ou 3G). L'étape suivante est le démarrage 202, sur instruction de l'utilisateur d'une application, l'application étant exécutée sur le téléphone 103. On suppose que l'application nécessite l'utilisation de données ou de commandes fournies par le boîtier électronique 104. Dans cet exemple, on considère que
5 l'application permet d'ouvrir à distance le véhicule à l'aide du téléphone 103.
L'application émet, via le téléphone 103, une requête d'accès à des données (et/ou des commandes) à destination du boîtier électronique 104. Dans l'exemple, l'application doit notamment être autorisée à actionner les commandes d'ouvertures et de fermetures du véhicule.
) En réponse à cette requête d'accès, le boîtier électronique 104 demande à l'application un jeton d'autorisation valide.
Si l'application dispose d'un jeton valide alors elle le transmet au boîtier électronique 104 sinon le boîtier électronique 104 redirige 205 l'application vers l'Idp 101 .
5 L'application demande 206 alors un jeton d'autorisation à l'Idp 101 .
Cette demande précise à quel SP est destiné le jeton ainsi que les autorisations nécessaires pour l'exécution de l'application.
L'étape suivante est l'authentification 207 de l'utilisateur auprès de l'Idp 101 . Cette authentification peut se faire selon différent moyen selon l'art ) connu, par exemple, avec un identifiant et un mot de passe.
Une fois l'utilisateur authentifié et, en réponse à la demande de jeton, l'Idp 101 crée et émet 208 un jeton à destination de l'application. Le jeton est signé avec la clé privé de l'Idp 101 . Avantageusement, le jeton est crypté à l'aide de la clé publique du boîtier électronique 104, de sorte que seul le boîtier 5 électronique 104 est capable de décrypter le jeton.
Le jeton comporte aussi une description des autorisations accordées par l'Idp 101 .
De façon avantageuse, le jeton est dans un format OAuth dont une description est disponible, à la date de dépôt de la demande de brevet, sur le ) site internet « http://oauth.net/ ».
En réponse à la réception du jeton, l'application transmet 209 le jeton au boîtier électronique 104. A la réception du jeton, le boîtier électronique 104 effectue une vérification du jeton et si la vérification est positive (autrement dit si le jeton est valide) alors le boîtier électronique 104 ouvre un accès aux données conformément aux autorisations indiquées dans le jeton.
5 La vérification comporte la vérification de la signature du jeton. Le boîtier électronique 104 utilise la clé publique de l'Idp 101 pour cette vérification. Lors de la vérification de la signature par le SP, le champ CN ou « common name » contenu dans le certificat sert aussi à vérifier la provenance du jeton. Le CN doit correspondre au nom de l'autorité de
) signature habilité. Le nom de l'autorité de signature habilité est stocké dans une mémoire du SP 104, avantageusement, la mémoire sécurisée du SP 104.
La vérification comporte aussi le déchiffrement du jeton. Le jeton est déchiffré avec la clé privée du boîtier électronique 104.
5 Le boîtier électronique 104 extrait du jeton, l'identifiant de l'utilisateur, l'identifiant du boîtier électronique 104 appelé UIN (pour Unique Identifiant Number), l'identifiant de l'application ainsi que les autorisations accordées.
Le SP 104 vérifie aussi que les autorisations décrites dans le jeton correspondent aux autorisations demandées par l'application dans la requête ) d'accès. Dans la négative, l'accès aux données est refusée.
Comme expliqué précédemment, les autorisations sont avantageusement regroupées par ensemble, le jeton indiquant alors les ensembles d'autorisations accordés par l'Idp 101 . Pour faire la correspondance entre ces ensembles et les autorisations, le boîtier 5 électronique 104 utilise une table de correspondance appelée manifeste.
En résumé, un jeton est généré pour faire des authentifications. Il est chiffré avec la clé publique du certificat du SP 104 et signé avec la clé privé du certificat de l'Idp 101 .
Le jeton est une sorte de conteneur garantissant l'authenticité de son ) émetteur. Ce conteneur n'ouvrable que par le véhicule auquel il est destiné.
De façon avantageuse, l'invention permet aussi de transmettre des authentifications et des autorisations depuis un boîtier électronique embarqué dans un véhicule vers des fournisseurs de service débarqués. La transmission de ces authentifications et ces autorisations sont aussi assurées au moyen de jetons d'autorisation. Ces jetons d'autorisations sont distribués par un deuxième Idp 101 ' dédié à l'identification des véhicules.
5 En référence à la figure 3, le procédé d'authentification comporte en outre une étape d'établissement 301 d'une connexion réseau sécurisée entre le boitier électronique 104 et le deuxième Idp 101 '. Le boitier électronique 104 s'authentifie auprès du deuxième Idp 101 '. L'authentification est réalisée avec un certificat stocké dans la mémoire sécurisée du boitier électronique 104.
) Le boitier électronique 104 demande 302 un jeton d'autorisation au deuxième Idp 101 '. Cette demande précise à quel SP est destinée le jeton ainsi que les autorisations nécessaires.
Une fois le boitier électronique 104 authentifié et en réponse à la demande de jeton, le deuxième Idp 101 ' crée et émet 303 un jeton à
5 destination du boitier électronique 104. Comme précédemment, le jeton est signé avec la clé privé du deuxième Idp 101 '. Avantageusement, le jeton est crypté à l'aide de la clé publique du SP 400, de sorte que seul le SP 400 est capable de décrypter le jeton.
En réponse à la réception du jeton, le boitier électronique 104
) transmet 304 le jeton au SP 400.
A la réception du jeton, le SP 400 effectue une vérification du jeton et si la vérification est positive (autrement dit si le jeton est valide) alors le SP 400 ouvre un accès aux données conformément aux autorisations indiquées dans le jeton.
5 Ces jetons permettent au boitier électronique 104 de consommer des services sur des infrastructures débarqués de partenaires ou internes (par exemple des services de navigation ou de cartographie).
Ces jetons permettent aussi d'authentifier un boitier électronique d'un véhicule auprès d'un boitier électronique d'un autre véhicule de sorte à
) échanger des données de façon sécurisée.

Claims

REVENDICATIONS
1 . Procédé d'authentification d'une application exécutée sur un terminal (103), auprès d'un fournisseur de service (104), comportant des étapes de :
- Réception d'une demande (203) d'accès à des données, par le fournisseur de service (104),
- En réponse à la demande, l'émission, par le fournisseur de service (104), d'une demande (204) d'un jeton valide,
- Réception (209), par fournisseur de service (104), d'un jeton chiffré,
- Vérification de la validité du jeton, au cours de laquelle le jeton est déchiffré avec une clé privée, ladite clé privée étant stockée par le fournisseur de service (104),
- Ouverture (210), par le fournisseur de service (104), d'un accès aux données, si le jeton est valide.
2. Procédé d'authentification selon la revendication 1 , comportant, en outre, des étapes de :
- Redirection (205), de l'application (103), vers un fournisseur d'identité (101 ),
- Envoi, par l'application, d'une demande (206) d'un jeton, à destination du fournisseur d'identité (101 ),
- Création (220), par le fournisseur d'identité (101 ), d'un jeton dédié au fournisseur de service (104), ledit jeton étant signé et chiffré,
- Transmission (208) du jeton à l'application, l'application transmettant le jeton au fournisseur de service (104).
3. Procédé d'authentification selon la revendication 2, caractérisé en ce que l'étape de vérification du jeton comporte, en outre, la vérification de la signature du jeton, le jeton étant valide s'il est signé par le fournisseur d'identité (101 ).
4. Procédé d'authentification selon l'une des revendications précédentes, caractérisé en ce que le jeton comporte : un identifiant d'un utilisateur (102) de l'application, un identifiant unique du fournisseur de service (104), des autorisations, et un identifiant de l'application.
5. Procédé d'authentification selon l'une des revendications précédentes, caractérisé en ce qu'il comporte en outre une étape d'authentification (201 ) de l'utilisateur auprès du fournisseur d'identité (101 ).
) 6. Procédé d'authentification selon l'une des revendications 2 à 5, caractérisé en ce que jeton est signé avec la clé privé du fournisseur d'identité (101 ) et chiffré à l'aide de la clé publique du fournisseur de service (104), de sorte que seul le fournisseur de service (104) est capable de déchiffrer le jeton.
5 7. Equipement électronique (104) comportant une mémoire stockant des données caractérisé en ce qu'il comporte :
- des moyens de réception d'une demande (203) d'accès aux données,
- des moyens d'émission, d'une demande (204) d'un jeton valide,
- des moyens de réception d'un jeton chiffré,
) - des moyens de vérification du jeton comportant des moyens de déchiffrement du jeton avec une clé privée, ladite clé privée étant stockée dans une mémoire sécurisée dudit équipement électronique (104),
- des moyens d'ouverture d'un accès aux données.
5 8. Véhicule caractérisé en ce qu'il comporte un équipement électronique (104) selon la revendication précédente.
9. Système d'authentification caractérisé en ce qu'il comporte :
- un équipement électronique (104) selon la revendication 7, et
) - une application, exécutée sur un terminal (103), apte à recevoir un jeton signé et chiffré provenant d'un fournisseur d'identité (101 ) et apte à transmettre ledit jeton à l'équipement électronique (104).
10. Système d'authentification selon la revendication précédente caractérisé en ce qu'il comporte, en outre, un fournisseur d'identité (101 ) apte à signer, 5 avec une clé privé du fournisseur d'identité (101 ), et à chiffrer, à l'aide de la clé publique du fournisseur de service (104), un jeton.
1 1 . Système d'authentification selon l'une des revendications 9 ou 10 caractérisé en ce qu'il comporte, en outre, un deuxième équipement î o électronique selon la revendication 7, chacun desdits premier et deuxième équipements électroniques comportant son propre certificat.
12. Système d'authentification selon l'une des revendications 10 ou 1 1 caractérisé en ce que le premier équipement électronique (104) est embarqué 15 à bord d'un véhicule et en ce que le terminal (103) est un téléphone mobile.
13. Système d'authentification selon la revendication précédente caractérisé en ce que la donnée dont l'accès est contrôlé est une commande de déverrouillage des portes du véhicule.
EP15733809.6A 2014-06-20 2015-06-05 Procede et systeme d'authentification au moyen de jetons Withdrawn EP3158710A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1455686A FR3022664B1 (fr) 2014-06-20 2014-06-20 Procede et systeme d'authentification
PCT/FR2015/051496 WO2015193578A1 (fr) 2014-06-20 2015-06-05 Procede et systeme d'authentification au moyen de jetons

Publications (1)

Publication Number Publication Date
EP3158710A1 true EP3158710A1 (fr) 2017-04-26

Family

ID=51417475

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15733809.6A Withdrawn EP3158710A1 (fr) 2014-06-20 2015-06-05 Procede et systeme d'authentification au moyen de jetons

Country Status (4)

Country Link
EP (1) EP3158710A1 (fr)
CN (1) CN106664294A (fr)
FR (1) FR3022664B1 (fr)
WO (1) WO2015193578A1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3049798B1 (fr) * 2016-03-31 2018-03-23 Peugeot Citroen Automobiles Sa Systeme de commande d’un vehicule a distance
FR3057973B1 (fr) 2016-10-25 2018-11-30 Peugeot Citroen Automobiles Sa Procede d'installation d'un certificat dans un calculateur de vehicule, calculateur et systeme associes
CN109729048A (zh) * 2017-10-30 2019-05-07 中移(苏州)软件技术有限公司 一种联合认证方法、系统、相关平台及介质
CN108667791B (zh) * 2017-12-18 2021-01-01 中国石油天然气股份有限公司 身份验证方法
US10553058B2 (en) * 2018-06-29 2020-02-04 Micron Technology, Inc. Secure wireless lock-actuation exchange
FR3093887B1 (fr) 2019-03-15 2021-05-14 Psa Automobiles Sa Procédé pour délivrer, à un dispositif nomade, une autorisation d’accès à un calculateur connecté d’un véhicule
EP4052414B1 (fr) * 2019-12-06 2024-02-07 Samsung Electronics Co., Ltd. Procédé et dispositif électronique permettant de gérer des clés numériques
CN111080253B (zh) * 2019-12-11 2023-03-03 深圳供电局有限公司 随机太阳式输电线路现场作业方法与系统
CN115828309B (zh) * 2023-02-09 2023-11-07 中国证券登记结算有限责任公司 一种服务调用方法及系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013177331A1 (fr) * 2012-05-23 2013-11-28 Global Integrated Technologies, Inc. Système et procédé d'accès et de gestion de véhicule de location/partagé

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8108920B2 (en) * 2003-05-12 2012-01-31 Microsoft Corporation Passive client single sign-on for web applications
US20060021018A1 (en) * 2004-07-21 2006-01-26 International Business Machines Corporation Method and system for enabling trust infrastructure support for federated user lifecycle management
US7702917B2 (en) * 2004-11-19 2010-04-20 Microsoft Corporation Data transfer using hyper-text transfer protocol (HTTP) query strings
KR101482564B1 (ko) 2009-09-14 2015-01-14 인터디지탈 패튼 홀딩스, 인크 신뢰성있는 인증 및 로그온을 위한 방법 및 장치
EP2540057A2 (fr) * 2010-02-26 2013-01-02 General instrument Corporation Liaison dynamique et cryptographique d'identité entre un abonné et un périphérique pour la mobilité de l'abonné

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013177331A1 (fr) * 2012-05-23 2013-11-28 Global Integrated Technologies, Inc. Système et procédé d'accès et de gestion de véhicule de location/partagé

Also Published As

Publication number Publication date
CN106664294A (zh) 2017-05-10
FR3022664B1 (fr) 2017-10-27
FR3022664A1 (fr) 2015-12-25
WO2015193578A1 (fr) 2015-12-23

Similar Documents

Publication Publication Date Title
EP3158710A1 (fr) Procede et systeme d'authentification au moyen de jetons
EP3602991B1 (fr) Mécanisme permettant d'obtenir une vérification d'identité mutuelle par l'intermédiaire de canaux de dispositif d'application unidirectionnels
JP6586446B2 (ja) 通信端末および関連システムのユーザーの識別情報を確認するための方法
CN112468506B (zh) 获取、下发电子证件的实现方法和装置
US9332002B1 (en) Authenticating and authorizing a user by way of a digital certificate
CN108141444B (zh) 经改善的认证方法和认证装置
US20030208681A1 (en) Enforcing file authorization access
CN105635147A (zh) 基于车载特种装备系统的数据安全传输方法及系统
CN111065081A (zh) 一种基于蓝牙的信息交互方法及其装置
CN120910920B (zh) 基于可信执行环境的大模型语料数据交互系统、交互方法、终端及介质
US20140013116A1 (en) Apparatus and method for performing over-the-air identity provisioning
JP6723422B1 (ja) 認証システム
JP2011118592A (ja) アクセス制御システム、アクセス制御方法およびプログラム
EP3532973A1 (fr) Procédé d'installation d'un certificat dans un calculateur de véhicule, calculateur et système associés
CN107409043B (zh) 基于中央加密的存储数据对产品的分布式处理
CN111127715A (zh) 一种蓝牙钥匙更换方法及其装置
KR102053993B1 (ko) 인증서를 이용한 사용자 인증 방법
KR20250046168A (ko) 자동차에 대한 접근 제어
US9281947B2 (en) Security mechanism within a local area network
US20250363843A1 (en) Method and Device for Securely Sharing a Digital Key for a Vehicle
KR100892941B1 (ko) 이동통신단말기를 이용한 보안처리 방법
US20260074918A1 (en) Method for authenticating data
EP2842290B1 (fr) Procédé et système de communication par ordinateur pour l'authentification d'un système client
US20240137354A1 (en) Secure online authentication method using mobile id document
FR3044500A1 (fr) Procede et systeme d'acces, par un serveur, a des donnees confidentielles disponibles aupres d'un fournisseur de service.

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20161129

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: PSA AUTOMOBILES SA

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20180913

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: PSA AUTOMOBILES SA

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

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

18D Application deemed to be withdrawn

Effective date: 20220615