FR3072802A1 - Verification d'identite preservant la confidentialite - Google Patents

Verification d'identite preservant la confidentialite Download PDF

Info

Publication number
FR3072802A1
FR3072802A1 FR1857843A FR1857843A FR3072802A1 FR 3072802 A1 FR3072802 A1 FR 3072802A1 FR 1857843 A FR1857843 A FR 1857843A FR 1857843 A FR1857843 A FR 1857843A FR 3072802 A1 FR3072802 A1 FR 3072802A1
Authority
FR
France
Prior art keywords
requesting entity
clear text
entity
hash value
secure token
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.)
Pending
Application number
FR1857843A
Other languages
English (en)
Inventor
Stefano Schiavoni
Simon Morris
Phillips Benton
Tom Pritchard
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.)
Google LLC
Original Assignee
Google LLC
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 Google LLC filed Critical Google LLC
Publication of FR3072802A1 publication Critical patent/FR3072802A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • 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
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • 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/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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/3215—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 using a plurality of channels
    • 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/3236—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 using cryptographic hash functions
    • H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115—Third party

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Software Systems (AREA)
  • Storage Device Security (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Les aspects de la technologie mettent en œuvre un protocole d'authentification qui permet au fournisseur de confiance de se porter garant d'une entité demandeuse lorsque cette entité sollicite la vérification par une entité d'authentification (la figure 1). Cela est réalisé sans avoir besoin de partager des informations confidentielles ou d'autres informations personnelles de l'entité demandeuse directement avec l'entité d'authentification (la figure 1). Au lieu de cela, le fournisseur de confiance peut utiliser des informations spécifiques à propos d'une entité demandeuse, telles que des informations de contact qui forment un enregistrement d'identité (404) et peut générer un hachage de l'enregistrement (408). Le hachage est envoyé à une entité d'authentification (410), qui renvoie un jeton sécurisé au fournisseur de confiance (508). Les informations du jeton sécurisé et de l'enregistrement d'identité sont utilisées afin de créer une URL de vérification (414), laquelle est partagée avec l'entité demandeuse (416). L'URL de vérification, lorsqu'on clique dessus, renvoie à l'entité d'authentification (la figure 1), laquelle valide l'entité demandeuse (512, 514). L'invention permet une identification instantanée de l'entité demandeuse sans que les parties doivent réaliser des opérations cryptographiques avancées (516).

Description

Vérification d'identité préservant la confidentialité
Le commerce électronique et d'autres activités sur internet impliquent souvent une partie vérifiant l'identité d'une autre partie. La vérification peut être réalisée de différentes façons. Dans un exemple, une autorité de certification Internet ou une autorité de certification peut émettre un certificat numérique qui contient des informations de justificatif d'identité pour aider une personne ou un commerce pour des transactions en ligne. Cependant, ce type d'approche peut avoir besoin des différentes parties pour réaliser des opérations cryptographiques avancées. Cela peut aussi nécessiter le stockage des informations sensibles allant au-delà de ce qui est normalement requis pour le travail quotidien, ou autrement cela implique des frais généraux supplémentaires des ressources ou de gestion qui sont inefficaces ou fastidieux. Ainsi, ce type d'approche peut ne pas être réalisable pour certaines parties, qu'elles soient des particuliers, des petits commerces ou d'autres entités.
Les techniques de vérification d'identité décrites dans la présente invention sont simples à mettre en œuvre tout en préservant la vie privée d'une partie (une entité demandeuse) qui souhaite s'identifier à une autre partie (une entité d'authentification). L'approche générale se base sur les facteurs suivants. Premièrement, un intermédiaire (un fournisseur de confiance) peut déjà identifier l'entité demandeuse (telle qu'une personne ou un commerce), par exemple, selon une relation préexistante. Deuxièmement, le fournisseur de confiance ne peut pas partager les données lisibles à propos de l'entité demandeuse avec l'entité d'authentification. Ces dernières peuvent être des accords contractuels ou légaux qui empêchent un tel partage d'informations. Et troisièmement, le fournisseur de confiance devrait réaliser le moins de travail possible pour assister au processus de vérification. Cela peut inclure de garder un tableur ou de calculer des calculs de base, mais cela n'inclut pas de calculer des signatures numériques ou de stocker des informations très sensibles à propos des affaires.
Les aspects de la technologie décrits ci-dessous permettent au fournisseur de confiance d'utiliser leurs informations spécifiques à propos d'une entité demandeuse pour permettre une identification ou une authentification instantanée de cette entité demandeuse avec une entité d'authentification particulière. Le fournisseur de confiance peut être un fournisseur de services inter-entreprises (B2B) tel qu'une banque ou une entreprise de télécommunication. Les informations spécifiques du fournisseur de confiance à propos d'une personne, d'un négociant, d'un commerce donné ou d'une autre entité demandeuse peuvent inclure son adresse, son point de contact et d'autres données d'identification qui dépendent des transactions normales avec ce commerce. Ces informations sont hachées de manière particulière visant à les partager avec une entité donnée d'authentification. L'entité d'authentification génère un jeton sécurisé sur base des informations hachées qu'utilise le fournisseur de confiance pour créer un lien de vérification. L'entité demandeuse est alors capable d'utiliser le lien de vérification, qui met à disposition une identification instantanée de l'entité demandeuse par l'entité d'authentification.
Selon les aspects de la technologie, un procédé inclut le traitement, par un ou plusieurs dispositifs de processeur, d'un message en texte clair à l'aide d'une fonction de hachage pour générer une valeur de hachage du message en texte clair. Le message en texte clair inclut des informations de contact à propos d'une entité demandeuse. Le procédé inclut également l'envoi, par une unité de communication, de la valeur générée de hachage à un deuxième dispositif externe d'une entité d'authentification, et la réception, par l'unité de communication, d'un jeton sécurisé depuis le deuxième dispositif externe de l'entité d'authentification en réponse à l'envoi de la valeur générée de hachage. Le procédé inclut en outre la création, par l'un ou plusieurs dispositifs de traitement et en réponse à la réception du jeton sécurisé depuis le deuxième dispositif externe de l'entité d'authentification, d'une indication de vérification sur base du jeton sécurisé et du message en texte clair. Le procédé inclut également l'envoi, par l'unité de communication, de l'indication de vérification au premier dispositif externe de l'entité demandeuse.
Dans un exemple, le processus est réalisé en réponse à la réception du message en texte clair à partir d'un premier dispositif externe d'une entité demandeuse, le message en texte clair comprenant les informations de contact de l'entité demandeuse. Dans un autre exemple, le message en texte clair comprend les informations de contact qui incluent une adresse physique d'un commerce ou d'une personne associée à l'entité demandeuse. Dans un exemple supplémentaire, le message en texte clair comprend une notification d'objet javascript (JSON) d'identité des informations de contact.
Dans un autre exemple, le procédé inclut en outre l'ajout d'un élément SALT au message en texte clair et le traitement du message en texte clair avec l'élément SALT prédéfini en utilisant la fonction de hachage. Ici, l'envoi de l'indication de vérification au premier dispositif externe de l'entité demandeuse comprend l'envoi d'une URL de vérification incorporant le jeton sécurisé et l'information du message en texte clair au premier dispositif externe.
Selon les autres aspects de la technologie, un dispositif est fourni et comprend une unité de communication et un ou plusieurs processeurs. L'un ou plusieurs processeurs sont configurés pour la récupération, dans la mémoire, d'un message en texte clair contenant des informations d'une entité demandeuse, le traitement du message en texte clair à l'aide d'une fonction de hachage pour générer une valeur de hachage du message en texte clair et la création d'une indication de vérification sur base du message en texte clair et d'un jeton sécurisé reçu d'un deuxième dispositif externe d'une entité d'authentification. Le message en texte clair inclut des informations de contact à propos de l'entité demandeuse. L'unité de communication est en outre configurée pour envoyer l'indication de vérification à un premier dispositif externe de l'entité demandeuse en réponse à la réception du jeton sécurisé depuis le deuxième dispositif externe de l'entité d'authentification.
Dans un exemple, le message en texte clair comprend les informations de contact de l'entité demandeuse. Dans un autre exemple, le message en texte clair comprend les informations de contact incluant une adresse physique d'un commerce ou d'une personne associée à l'entité demandeuse. Dans un exemple supplémentaire, le message en texte clair comprend une notification d'objet javascript (JSON) d'identité des informations de contact.
Dans un autre exemple, l'un ou plusieurs processeurs sont en outre configurés pour l'ajout d'un élément SALT au message en texte clair et pour le traitement du message en texte clair avec l'élément SALT prédéfini en utilisant la fonction de hachage. Ici, le dispositif peut envoyer l'indication de vérification au premier dispositif externe de l'entité demandeuse en envoyant une URL de vérification qui incorpore le jeton sécurisé et l'information du message en texte clair au premier dispositif externe.
Selon les aspects additionnels de la technologie, l'invention concerne un procédé. Le procédé inclut, en réponse à la réception d'une valeur de hachage à partir d'un dispositif informatique d'un fournisseur de confiance, le stockage de la valeur de hachage dans la mémoire. La valeur de hachage correspond à des informations en texte clair associées à une entité demandeuse. Les informations en texte clair incluent des informations de contact à propos de l'entité demandeuse. Le procédé inclut également la génération, par un ou plusieurs dispositifs de processeur, d'un jeton sécurisé associé à un emplacement de stockage de la valeur de hachage. En réponse à la réception d'un message de vérification à partir d'un premier dispositif externe de l'entité demandeuse, le procédé inclut le traitement, par l'un ou plusieurs dispositifs de processeur, du message de vérification à l'aide d'une fonction de hachage pour générer une valeur de hachage, la récupération de la valeur de hachage stockée dans la mémoire, la comparaison d'une valeur générée de hachage avec la valeur de hachage extraite à partir de la mémoire et la comparaison du jeton sécurisé généré avec les informations du jeton dans le message de vérification, en vue de vérifier une identité de l'entité demandeuse.
Dans un exemple, la génération du jeton sécurisé associé à l'emplacement de stockage comprend la génération d'une chaîne de jetons aléatoires et l'enregistrement d'une association entre la chaîne de jetons aléatoires et l'emplacement de stockage. Dans un autre exemple, une longueur de la chaîne de jetons aléatoires est d'au moins 16 bits. Dans un exemple supplémentaire, le procédé inclut en outre le stockage du jeton sécurisé dans une base de données et l'association du jeton sécurisé avec la valeur stockée de hachage. Dans encore un autre exemple, le procédé inclut en outre l'un ou plusieurs dispositifs de processeur pré-remplissant un modèle d'inscription avec des détails du compte de l'entité demandeuse. Ici, les détails du compte peuvent être reçus via un paramètre de chaîne de requête d'identification associé à l'entité demandeuse.
Et selon les autres aspects de la technologie, un dispositif qui est fourni inclut une unité de communication et un ou plusieurs processeurs configurés pour réaliser les opérations sélectionnées. En particulier, en réponse à la réception d'une valeur de hachage à partir d'un dispositif informatique d'un fournisseur de confiance, l'un ou plusieurs processeurs sont configurés pour le stockage de la valeur de hachage dans la mémoire. La valeur de hachage correspond à des informations en texte clair associées à une entité demandeuse. Les informations en texte clair incluent des informations de contact à propos de l'entité demandeuse. L'un ou plusieurs processeurs sont aussi configurés pour la génération d'un jeton sécurisé associé à un emplacement de stockage de la valeur de hachage. En réponse à la réception d'un message de vérification à partir d'un premier dispositif externe de l'entité demandeuse, l'un ou plusieurs processeurs sont configurés pour le traitement du message de vérification à l'aide d'une fonction de hachage pour générer une valeur de hachage, la récupération de la valeur de hachage stockée dans la mémoire, la comparaison d'une valeur générée de hachage avec la valeur de hachage extraite à partir de la mémoire et la comparaison du jeton sécurisé généré avec les informations du jeton dans le message de vérification, en vue de vérifier une identité de l'entité demandeuse.
Dans un exemple, le jeton sécurisé associé à l'emplacement de stockage est créé en générant une chaîne de jetons aléatoires et l'enregistrement d'une association entre la chaîne de jetons aléatoires et l'emplacement de stockage. Dans ce cas-ci, une longueur de la chaîne de jetons aléatoires peut être au moins de 16 bits. Dans un autre exemple, l'un ou plusieurs processeurs sont en outre configurés pour stocker le jeton sécurisé dans une base de données et pour associer le jeton sécurisé avec la valeur stockée de hachage. Dans un exemple supplémentaire, l'un ou plusieurs processeurs sont aussi configurés pour le pré-remplissage d'un modèle d'inscription avec des détails du compte de l'entité demandeuse. Dans cette situation, les détails du compte peuvent être reçus via un paramètre de chaîne de requête d'identification associé à l'entité demandeuse.
Un ensemble de figures accompagnant cette description illustrent diverses caractéristiques et différents aspects de la technologie. Sur ces figures, les mêmes numéros de référence se réfèrent aux mêmes éléments. Une brève discussion de chaque figure est fournie ci-dessous.
La figure 1 montre un exemple de procédé selon les aspects de l'invention.
La figure 2A un exemple de disposition du fournisseur de confiance selon les aspects de l'invention.
La figure 2B est un exemple de disposition d'entité d'authentification selon les aspects de l'invention.
La figure 3 montre un exemple de réseau selon les aspects de l'invention.
La figure 4 montre un exemple de procédé de requête selon les aspects de l'invention.
La figure 5 montre un exemple de procédé de vérification selon les aspects de l'invention.
La description suivante se base sur des modes de réalisation des revendications et ne devrait pas être interprétée comme une restriction aux revendications par rapport à des modes de réalisation alternatifs qui ne sont pas décrits explicitement dans la présente invention.
Le protocole d'authentification discuté dans la présente invention inclut une interaction entre une entité demandeuse, un fournisseur de confiance et une entité d'authentification. L'entité demandeuse dépend du fournisseur de confiance pour effectivement se porter garant de l'entité demandeuse avec l'entité d'authentification, mais sans partager directement avec l'entité d'authentification des informations confidentielles ou d'autres informations personnelles de l'entité demandeuse. Cette approche ne nécessite aucune entité pour réaliser des opérations cryptographiques avancées ou pour stocker des informations sensibles allant au-delà de ce qui est normalement requis pour le travail quotidien. Les frais généraux des ressources ou de gestion sont ainsi maintenus à un minimum, par exemple via un tableur ou une base de données simplifiée. Cela peut être attractif aux yeux des particuliers, des petits commerces et d'autres entités demandeuses, ainsi qu'aux fournisseurs de confiance qui sont liés aux entités délivrant l'autorisation.
Un exemple du protocole d'authentification est illustré à la figure 1. Ici, comme exposé plus en détails ci-dessous, un flux du procédé est présenté allant d'une entité demandeuse à un fournisseur de confiance à une entité d'authentification et puis de nouveau au fournisseur de confiance et à l'entité demandeuse. A un niveau élevé, le protocole permet au fournisseur de confiance de générer des codes de vérification - de préférence des URL de vérification - sans partager les données confidentielles de l'entité demandeuse avec l'entité d'authentification. Par exemple, le protocole implique le fournisseur de confiance de mettre en œuvre certaines tâches et une interaction avec l'entité d'authentification et d'être ainsi capable de livrer l'URL de vérification directement à l'entité demandeuse. Lorsque quelqu'un se trouvant à l'entité demandeuse reçoit l'URL et clique sur celle-ci, il y a une vérification automatique avec l'entité d'authentification. L'entité d'authentification prend ainsi connaissance de l'existence de l'entité demandeuse au moment où l'entité demandeuse active le lien, pas avant.
En particulier, tel qu'illustré à la figure 1, l'entité demandeuse fournit initialement certaines informations (« informations d'entité ») au fournisseur de confiance. Cela peut être réalisé via un déroulement normal d'affaires avec ce fournisseur de confiance. Par exemple, une personne ou un commerce peut ouvrir un compte dans une institution bancaire ou un service mis en place avec un fournisseur de télécommunications. Les informations d'entité seraient, par exemple, un nom et une adresse ou d'autres informations de contact à propos de l'entité demandeuse. Les informations d'entité sont stockées par le fournisseur de confiance comme des informations d'identité sous un enregistrement d'identité.
A titre d'exemple, les détails de l'entité demandeuse (« informations d'entité ») stockés par le fournisseur de confiance peuvent être désignés comme une identité de l'entité demandeuse. L'identité peut inclure typiquement le nom d'un point de contact (par exemple, le chef d'entreprise) et une adresse physique d'une rue associés au commerce ou à une autre entité demandeuse. Les informations d'identité peuvent être stockées par le fournisseur de confiance, par exemple, comme faisant partie d'un tableur ou d'un enregistrement dans une base de données de la gestion de la relation client (GRC). Les informations d'identité peuvent être agencées comme un message en texte clair (« enregistrement d'identité ») dans le format de notation d'objet JavaScript (JSON).
A un certain point, l'entité demandeuse peut faire la demande au fournisseur de confiance de se porter garant pour cette entité avec une entité d'authentification. Cela peut être fait, par exemple, de telle sorte que l'entité demandeuse peut accéder aux services offerts par l'entité d'authentification. Le fournisseur de confiance crée et partage un hachage sécurisé (hachage de message) des détails de l'entité demandeuse (enregistrement d'identité) avec l'entité d'authentification.
En particulier, le hachage de message est envoyé à l'entité d'authentification par le fournisseur de confiance. L'entité d'authentification génère un jeton sécurisé qui est renvoyé au fournisseur de confiance et sert d'accusé de réception de message pour le hachage de message fourni. Le hachage de message et le jeton sécurisé sont stockés par l'entité d'authentification pour une vérification ultérieure de l'entité demandeuse concernée.
Une fois que le fournisseur de confiance reçoit l'accusé de réception, le jeton sécurisé est utilisé pour créer un lien de vérification. Par exemple, une URL de vérification est créée au niveau du fournisseur de confiance pour l'entité demandeuse pour s'inscrire directement avec l'entité d'authentification. L'URL se crée sur base, à la fois, du jeton sécurisé reçu de l'entité d'authentification et de l'enregistrement d'identité stockés par le fournisseur de confiance.
L'URL de vérification est ensuite envoyée à l'entité demandeuse. Tel qu'illustré à la figure 1, lorsque l'entité demandeuse désire s'inscrire ou sinon s'enregistrer avec l'entité d'authentification, l'URL de vérification est cliquée ou sinon activée. Cela permet l'ouverture d'une connexion au site web de l'entité d'authentification. A ce niveau, l'entité d'authentification détecte si les données qu'elle reçoit de l'entité demandeuse hachent la même valeur fournie par le fournisseur de confiance et stockée dans la mémoire par l'entité d'authentification. En supposant que les informations soient correctes, l'entité demandeuse est instantanément validée avec l'entité d'authentification.
La figure 2A montre un exemple de configuration d'un fournisseur de confiance 200 qui peut être employé avec le protocole d'authentification décrit dans la présente invention. Tel qu'il est illustré, la configuration 200 inclut un module de traitement 202 ayant un ou plusieurs processeurs informatiques tels qu'une unité centrale de traitement 204 et/ou des processeurs graphiques 206, ainsi qu'un module de mémoire 208 configurés pour stocker des instructions 210 et des données 212. Une base de données 214 peut ou ne peut pas être séparée du module de mémoire 208. Les processeurs peuvent ou ne peuvent pas fonctionner en parallèle, et peuvent inclure des ASIC, des contrôleurs et d'autres types de circuit matériel. Les processeurs sont configurés pour recevoir des informations d'un utilisateur à travers le module d'interface utilisateur 216 et pour présenter des informations à l'utilisateur sur un dispositif d'affichage du module d'affichage 218 présentant une interface d'affichage.
Le module d'interface utilisateur 216 peut recevoir des commandes d'un utilisateur via des entrées utilisateur et les convertir en présentation à un processeur donné. Les entrées utilisateur peuvent inclure un ou plusieurs parmi un écran tactile, un clavier, une souris, un stylet, un microphone ou d'autres types de dispositifs d'entrée. Le module d'affichage 218 peut comprendre un circuit approprié pour commander le dispositif d'affichage pour présenter des informations graphiques et d'autres informations à l'utilisateur. A titre d'exemple, les informations graphiques peuvent être générées par le(s) processeur(s) graphique(s) 206, tandis que le CPU 204 dirige le fonctionnement général de la configuration d'un fournisseur de confiance 200.
Le module de mémoire 208 peut être mis en œuvre sous la forme d'un ou de plusieurs parmi un support ou des supports lisible(s) par ordinateur, une ou des unité(s) de mémoire volatile ou une ou des unité(s) de mémoire non volatile. Le module de mémoire 208 peut inclure, par exemple, une mémoire flash et/ou une NVRAM et peut être réalisé par un disque dur ou une carte mémoire. Autrement, le module de mémoire 208 peut également inclure un DVD, un CD-ROM et des mémoires en lecture seule et capables d'écriture. Dans un mode de réalisation, un produit de programme informatique est concrètement matérialisé dans un support d'information. Le produit de programme informatique contient des instructions, telles que les instructions 210 qui, lorsqu'elles sont exécutées par un ou plusieurs processeurs, réalisent un ou plusieurs procédés tels que ceux décrits dans la présente invention. Le support d'information est un support lisible par un ordinateur ou par une machine, tel que le module de mémoire 208. Bien que la figure 2A montre de manière fonctionnelle le(s) processeur(s), le module de mémoire, et d'autres éléments du dispositif 200 comme étant à l'intérieur du même bloc global, de tels composants peuvent ou ne peuvent pas être stockés dans le même boîtier physique. Par exemple, certaines ou toutes les instructions et données peuvent être stockées sur un support d'information qui est un support de stockage démontable (par exemple, un lecteur optique ou un lecteur USB) et d'autres sont stockées dans une puce informatique à lecture seule. Autrement, la base de données 214 peut stocker des enregistrements d'identité dans une configuration physiquement séparée du reste de la disposition du fournisseur de confiance 200.
Les données 212 peuvent être récupérées, stockées ou modifiées par les processeurs conformément aux instructions 210. Par exemple, bien que l'objet revendiqué ne soit pas limité à une quelconque structure de données particulière, les données peuvent être stockées dans des registres de dispositifs informatiques, dans une base de données relationnelle sous la forme d'une table ayant une pluralité de différents champs et enregistrements, des documents XML ou dans des fichiers plats. Les données 212 peuvent aussi être formatées dans un quelconque format lisible par un dispositif informatique.
Les instructions 210 peuvent être n'importe quel ensemble d'instructions devant être exécutées directement (telles qu'un code machine) ou indirectement (telles que des scripts) par le(s) processeur(s). Par exemple, les instructions peuvent être stockées comme code de dispositif informatique sur le support lisible par un dispositif informatique. A cet égard, les termes « instructions » et « programmes » peuvent être utilisés ici de manière interchangeable. Les instructions peuvent être stockées sous format de code objet pour un traitement direct par le(s) processeur(s), ou dans tout autre langage de dispositif informatique, y compris des scripts ou des collections de modules de code source indépendants qui sont interprétés sur demande ou compilés d'avance. Les fonctions, procédés et routines des instructions sont expliqués d'une manière plus détaillée ci-dessous.
Tel qu'il est également montré à la figure 2A, la configuration d'un fournisseur de confiance 200 inclut un module de communication 220 pour la communication avec d'autres dispositifs et systèmes, y compris des entités demandeuses et une ou plusieurs entités délivrant l'autorisation. Le module de communication 220 inclut un émetteurrécepteur sans fil ; Autrement, le module peut inclure un émetteurrécepteur doté d'un câble, ou les deux. La configuration d'un fournisseur de confiance 200 peut communiquer avec d'autres dispositifs à distance via le module de communication 220 à l'aide de divers protocoles et de différentes configurations, incluant un protocole de communication à courte portée tel qu'une communication en champ proche, Bluetooth™, Bluetooth™ de faible énergie (LE), ou d'autres réseaux ad-hoc, l'Internet, l'intranets, des réseaux privés virtuels, des réseaux à zone étendue, des réseaux locaux, des réseaux privés à l'aide de protocoles de communication de marque déposée d'une ou de plusieurs entreprises, d'Ethernet, de WiFi et d'HTTP, et des combinaisons des éléments précédents. De plus, la configuration d'un fournisseur de confiance 200 tel qu'il est illustré inclut un module de puissance 222.
Dans un exemple, le fournisseur de confiance applique une fonction de hachage sécurisé pour hacher les informations d'identité de l'entité demandeuse. Comme indiqué plus haut, l'enregistrement d'identité peut être sous format de notation d'objet JavaScript (JSON). Par exemple, le fournisseur de confiance peut « ficeler » la JSON d'enregistrement d'identité, par exemple, avec le codage UTF-8. Il peut alors facultativement le coder en base 64. Ces données peuvent être alors fournies à la fonction de hachage, par exemple, une fonction de hachage SHA-256. Le résultat du procédé de hachage est un hachage de message. Le hachage de message est une représentation spécifique des données mais ne sont pas les données en elles-mêmes. Pour plus de sécurité du fournisseur de confiance contre la réingénierie du hachage, les données aléatoires (« sait ») peuvent être ajoutées à la JSON d'enregistrement d'identité avant l'exécution du procédé de hachage. Uniquement à titre d'exemple, le sait peut inclure un ou plusieurs octets de données aléatoires. Le fournisseur de confiance peut alors partager le hachage de message avec l'entité d'authentification via une requête POST du HTTP ou une autre transmission.
Un exemple de configuration d'entité d'authentification 250 est illustré à la figure 2B. Cette configuration est similaire à la configuration d'un fournisseur de confiance 200. Par exemple, la configuration 250 inclut un module de traitement 252 ayant un ou plusieurs processeurs informatiques tels qu'une unité centrale de traitement 254 et/ou des processeurs graphiques 256, ainsi qu'un module de mémoire 258 configuré pour stocker des instructions 260 et des données 262. Une base de données 264 peut ou ne peut pas être séparée du module de mémoire 208. Cette base de données est agencée afin de stocker les hachages de messages reçus et les jetons sécurisés créés par l'entité d'authentification.
Les processeurs peuvent ou ne peuvent pas fonctionner en parallèle et peuvent inclure des ASIC, des contrôleurs et d'autres types de circuit matériel. Les processeurs sont configurés pour recevoir des informations d'un utilisateur à travers le module d'interface utilisateur 266 et pour présenter des informations à l'utilisateur sur un dispositif d'affichage du module d'affichage 268 présentant une interface d'affichage. Les processeurs, le module de mémoire, le module d'interface utilisateur et le module d'affichage fonctionnent de la même manière que celle décrite plus haut pour la configuration d'un fournisseur de confiance 200. Et de manière similaire à la base de données 214, la base de données 264 peut stocker des hachages de messages et les jetons sécurisés dans une configuration physiquement séparée du reste de la configuration d'entité d'authentification 250.
Tel qu'il est également montré à la figure 2B, la configuration d'entité d'authentification 250 inclut un module de communication 270 pour la communication avec d'autres dispositifs et systèmes, y compris des entités demandeuses et un ou plusieurs fournisseurs de confiance. Le module de communication 270 peut avoir une configuration équivalente à celle décrite pour le module de communication 220. De plus, la configuration d'entité d'authentification 250 comme il est montré inclut un module de puissance 272.
Lors de la réception du hachage de message, l'entité d'authentification réalise diverses choses. Premièrement, elle peut valider que le fournisseur de confiance est lui-même autorisé de se porter garant pour l'entité demandeuse. Si la validation échoue, le procédé devra s'arrêter et l'entité demandeuse devra utiliser un procédé de vérification plus formel et direct avec l'entité demandeuse. En supposant que la validation du fournisseur de confiance est réussie, l'entité d'authentification crée le jeton sécurisé afin de servir comme récepteur du hachage de message. Le jeton sécurisé ne devrait pas avoir de lien avec le hachage de message reçu. Par exemple, le jeton sécurisé peut être un nonce aléatoire (par exemple, 16 octets ou davantage). L'entité d'authentification stocke le hachage de message et le jeton sécurisé dans la base de données 264 et renvoie une copie du jeton sécurisé au fournisseur de confiance. Ainsi, on peut constater que le fournisseur de confiance ne fournit pas une version de texte clair de la JSON d'enregistrement d'identité à l'entité d'authentification et l'entité d'authentification ne peut pas réaliser l'ingénierie inverse des informations d'identité de l'entité demandeuse.
A ce niveau, une fois que le fournisseur de confiance a le jeton sécurisé, le fournisseur de confiance peut partager efficacement l'enregistrement d'identité et le jeton sécurisé avec l'entité demandeuse. Cela peut être réalisé, par exemple, par le fournisseur de confiance en générant une URL de vérification pour l'entité demandeuse sur base de l'enregistrement d'identité et du jeton sécurisé reçu. Dans un exemple, l'URL de vérification incorpore la version ficelée de l'enregistrement d'identité et du jeton sécurisé, avec un pointeur indiquant le site web de l'entité d'authentification. Le fournisseur de confiance peut stocker le jeton sécurisé reçu dans la base de données 214, par exemple en liaison ou séparément avec l'enregistrement d'identité associé. Autrement, le fournisseur de confiance peut ne pas stocker le jeton sécurisé reçu une fois que l'URL de vérification ait été générée.
Une fois cette génération réalisée, l'URL de vérification est envoyée à l'entité demandeuse directement à partir du fournisseur de confiance. Cela, à son tour, permet à la personne ou à un utilisateur au niveau de l'entité demandeuse de cliquer sur le lien ou autrement de débuter la vérification. Lorsque l'URL de vérification est activée, le navigateur internet de l'entité demandeuse est pris pour le site web de l'entité d'authentification, où l'utilisateur de l'entité demandeuse peut être automatiquement vérifié lui-même ou son commerce par l'entité d'authentification.
En particulier, l'entité d'authentification valide les informations reçues via l'URL de vérification selon le hachage de message reçu précédemment par l'entité d'authentification à partir du fournisseur de confiance. Lorsque l'entité demandeuse clique sur le lien de l'URL de vérification, l'entité d'authentification validera la version ficelée des informations d'identité et du jeton sécurisé. Pour ces derniers, le jeton sécurisé stocké par l'entité d'authentification dans la mémoire est comparé au jeton sécurisé reçu pour confirmer une correspondance. Pour les informations d'identité, le système d'entité d'authentification réalisera un procédé de hachage et comparera le résultat avec le hachage de message qui a été précédemment reçu du fournisseur de confiance.
L'entité d'authentification peut pré-remplir un écran d'inscription avec les détails de la personne ou du commerce. Cette inscription est possible car les détails sont codés en texte clair dans un paramètre de chaîne de requête d'identification associé aux détails de l'entité demandeuse, selon le hachage de message reçu précédemment du fournisseur de confiance.
L'entité d'authentification peut également vérifier que les informations d'identité correspondent à quelque chose que le fournisseur de confiance a le droit de fournir. Par exemple, il peut y avoir des restrictions géographiques ou d'autres restrictions sur lesquelles le fournisseur de confiance peut réaliser la certification.
Une fois que les vérifications sont réalisées avec satisfaction, l'entité d'authentification détermine que l'URL de vérification est légitime et a été générée par un fournisseur de confiance qui est autorisé par l'entité d'authentification. S'il en est ainsi, les données de l'entité demandeuse peuvent être immédiatement vérifiées. Ainsi, de cette façon, le système permet aux fournisseurs de confiance de se porter garant pour les identités de leurs utilisateurs à une entité d'authentification, et pour permettre aux utilisateurs d'être vérifiés de manière instantanée par l'entité d'authentification sans avoir à échanger des informations sensibles à propos d'eux-mêmes ou de leur commerce.
La figure 3 montre un exemple d'agencement dans lequel les différents dispositifs d'entité demandeuse 300, par exemple, 300i, 3002, 30Û3 et 3004 peuvent solliciter un contenu ou d'autres informations d'un fournisseur de confiance 320 et d'une entité d'authentification 340 via un système de communication 310. Les dispositifs d'entité demandeuse 300 peuvent inclure certains composants ou tous les composants discutés plus haut dans la présente invention en fonction de la configuration d'un fournisseur de confiance 200 et de la configuration d'entité d'authentification 250. Les dispositifs d'entité demandeuse peuvent inclure des ordinateurs portables (300i), des tablettes (3ΟΟ2), des téléphones cellulaires ou des assistants personnels à fonctions (PDA) (3ΟΟ3) ou des PC de bureau (3ΟΟ4). Cependant, d'autres dispositifs d'entité demandeuse peuvent être également utilisés par une entité demandeuse telle qu'un particulier, un petit commerce ou une société. De tels dispositifs d'entité demandeuse peuvent envoyer des informations à un fournisseur de confiance, recevoir des URL de vérification et solliciter une vérification d'une entité d'authentification telle qu'illustrée à la figure 1.
Comme il est montré, le fournisseur de confiance 320 peut se connecter à la base de données 322 via un lien 324. Le fournisseur de confiance 320 et la base de données 322 correspondent à la configuration d'un fournisseur de confiance 200 comme il a été décrit plus haut par rapport à la figure 2A. De manière similaire, l'entité d'authentification peut se connecter à la base de données 342 via un lien 344. L'entité d'authentification 340 et la base de données 342 correspondent à la configuration d'entité d'authentification 250 comme il a été décrit plus haut en fonction de la figure 2B. Tandis que seulement un fournisseur de confiance 320 et seulement une entité d'authentification 340 sont montrés à la figure 3, n'importe quel nombre de fournisseurs de confiance et d'entités délivrant l'autorisation peuvent y être inclus.
Un scénario faisant office d'exemple du fonctionnement du fournisseur de confiance est illustré en relation avec le diagramme des opérations 400 de la figure 4. Ici, dans le bloc 402, le procédé inclut des informations d'authentification de l'entité demandeuse, par exemple un nom et une adresse ou d'autres informations de contact. Celui-ci peut être réalisé en se basant sur l'interaction préexistante du fournisseur de confiance avec l'entité demandeuse, par exemple en confirmant un nom de contact et une adresse postale pour lesquels des avis ont été envoyés à l'entité demandeuse. Ces informations sont stockées en tant qu'enregistrement d'identité dans le bloc 404. Cela peut être réalisé sous format JSON ou sous un autre format, en fonction de la configuration de la base de données du fournisseur de confiance. Ces opérations peuvent être exécutées à un moment où l'entité demandeuse ouvre un compte ou sinon engage les services du fournisseur de confiance.
Le fournisseur de confiance peut recevoir une demande de l'entité demandeuse au bloc 406. Cela peut inclure une demande que le fournisseur de confiance se porte garant de l'entité demandeuse avec une entité d'authentification particulière. Ou, autrement, le fournisseur de confiance peut agir de manière prospective. En se basant sur soit une demande soit sur une action potentielle, le fournisseur de confiance génère un hachage de message de l'enregistrement d'identité au bloc 408. Pour y arriver, des approches réalisées par les processeurs du fournisseur de confiance sont analysées ci-dessus. Le hachage de message est transmis à l'entité d'authentification particulière au niveau du bloc 410. Alors, en réponse à cela, le fournisseur de confiance reçoit un jeton sécurisé au bloc 412. Le jeton sécurisé, tel qu'un nonce ou une autre information, fait office d'accusé de réception du hachage de message par l'entité d'authentification.
Une fois le jeton sécurisé reçu, le(s) processeur(s) du fournisseur de confiance créent l'URL de vérification à l'aide du jeton sécurisé et de l'enregistrement d'identité stocké au bloc 414. Cette information est ensuite transmise à l'entité demandeuse au bloc 416. A ce niveau, le fournisseur de confiance a achevé sa partie du procédé de vérification.
La figure 5 montre un exemple du procédé 500 pour l'opération de l'entité d'authentification. Au bloc 502, l'entité d'authentification reçoit un hachage de message d'un fournisseur de confiance. En se basant sur cela, un jeton sécurisé est généré par un ou plusieurs processeurs de l'entité d'authentification au bloc 504. Comme indiqué plus haut, le jeton sécurisé peut être un nonce aléatoire. Ensuite, au bloc 506, le hachage de message reçu et le jeton sécurisé généré sont stockés dans la mémoire, par exemple dans la base de données 264 de la figure 2B (ou la base de données équivalente 342 de la figure 3). Le jeton sécurisé est transmis au fournisseur de confiance dans le bloc 508. Ensuite, lorsque l'entité demandeuse active (par exemple, en réalisant un clic) l'URL de vérification, l'entité d'authentification reçoit cette information de l'entité demandeuse au bloc 510. A ce niveau, les processeurs de l'entité d'authentification réalisent une opération de vérification au bloc 512. Cette opération inclut la comparaison des informations de l'URL de vérification reçue avec le hachage de message stocké, ainsi que la confirmation que les informations reçues du jeton sécurisé de l'URL de vérification correspondent au jeton sécurisé stocké dans la base de données de l'entité d'authentification. Le bloc 514 analyse si la vérification est réussie. S'il en est ainsi, au bloc 516, l'entité demandeuse reçoit l'autorisation d'accès de l'entité d'authentification. En fonction du type d'entité d'authentification et du type d'entité demandeuse, cela peut permettre à l'entité demandeuse de réaliser certaines opérations ou lui permettre de fournir des biens ou des services sélectionnés. Si le procédé de vérification échoue, l'entité demandeuse se voit refuser l'accès au bloc 518.
Les flux logique et du procédé présentés dans les figures et décrits dans la présente invention ne se limitent pas à un ordre particulier ou à une séquence particulière, sauf indication contraire.
De plus, d'autres étapes peuvent être fournies ou peuvent être éliminées, issues des flux décrits et d'autres composantes peuvent être ajoutées ou retirées aux systèmes décrits de ces derniers.
Bien que la technologie de cette présente invention ait été décrite en faisant référence à des modes de réalisations particuliers, il doit être entendu que ces modes de réalisations ont un caractère purement illustratif des principes et des applications de la présente technologie. Il est donc entendu que plusieurs modifications peuvent être réalisées aux modes de réalisations représentatifs et que d'autres 10 dispositions peuvent être conçues sans s'écarter ni de l'esprit ni de la portée de la présente technologie tel qu'il est défini dans les revendications annexées.

Claims (22)

  1. REVENDICATIONS
    1. Procédé comprenant :
    le traitement, par un ou plusieurs dispositifs de processeur, d'un message en texte clair à l'aide d'une fonction de hachage pour générer une valeur de hachage du message en texte clair, dans lequel le message en texte clair inclut des informations de contact à propos d'une entité demandeuse ;
    l'envoi, par une unité de communication, de la valeur générée de hachage à un deuxième dispositif externe d'une entité d'authentification ;
    la réception, par l'unité de communication, d'un jeton sécurisé depuis le deuxième dispositif externe de l'entité d'authentification en réponse à l'envoi de la valeur générée de hachage ;
    en réponse à la réception du jeton sécurisé depuis le deuxième dispositif externe de l'entité d'authentification, la création, par l'un ou plusieurs dispositifs de traitement, d'une indication de vérification sur base du jeton sécurisé et du message en texte clair ; et l'envoi, par l'unité de communication, de l'indication de vérification au premier dispositif externe de l'entité demandeuse.
  2. 2. Procédé selon la revendication 1, dans lequel le processus est réalisé en réponse à la réception du message en texte clair à partir d'un premier dispositif externe d'une entité demandeuse, le message en texte clair comprenant les informations de contact de l'entité demandeuse.
  3. 3. Procédé selon la revendication 1 ou selon la revendication 2, dans lequel le message en texte clair comprend les informations de contact qui incluent une adresse physique d'un commerce ou d'une personne associée à l'entité demandeuse.
  4. 4. Procédé selon Tune quelconque revendication précédente, dans lequel le message en texte clair comprend une notification d'objet javascript (JSON) d'identité des informations de contact.
  5. 5. Procédé selon Tune quelconque revendication précédente, dans lequel :
    le traitement du message en texte clair comprend en outre l'ajout d'un élément SALT au message en texte clair et le traitement du message en texte clair avec l'élément SALT prédéfini en utilisant la fonction de hachage ; et l'envoi de l'indication de vérification au premier dispositif externe de l'entité demandeuse comprend l'envoi d'une URL de vérification incorporant le jeton sécurisé et l'information du message en texte clair au premier dispositif externe.
  6. 6. Dispositif comprenant :
    une unité de communication ; et un ou plusieurs processeurs configurés pour :
    la récupération, dans la mémoire, d'un message en texte clair contenant des informations d'une entité demandeuse ;
    le traitement du message en texte clair à l'aide d'une fonction de hachage pour générer une valeur de hachage du message en texte clair ; et la création d'une indication de vérification sur base du message en texte clair et d'un jeton sécurisé reçus d'un deuxième dispositif externe d'une entité d'authentification ;
    dans lequel :
    le message en texte clair inclut des informations de contact à propos de l'entité demandeuse ; et l'unité de communication est en outre configurée pour envoyer l'indication de vérification à un premier dispositif externe de l'entité demandeuse en réponse à la réception du jeton sécurisé depuis le deuxième dispositif externe de l'entité d'authentification.
  7. 7. Dispositif selon la revendication 6, dans lequel le message en texte clair comprend les informations de contact de l'entité demandeuse.
  8. 8. Dispositif selon la revendication 6 ou selon la revendication 7, dans lequel le message en texte clair comprend les informations de contact incluant une adresse physique d'un commerce ou d'une personne associée à l'entité demandeuse.
  9. 9. Dispositif selon l'une quelconque des revendications 6 à 8, dans lequel le message en texte clair comprend une notification d'objet javascript (JSON) d'identité des informations de contact.
  10. 10. Dispositif selon l'une quelconque des revendications 6 à 9, dans lequel l'un ou plusieurs processeurs sont en outre configurés pour :
    l'ajout d'un élément SALT au message en texte clair et le traitement du message en texte clair avec l'élément SALT prédéfini en utilisant la fonction de hachage ; et l'envoi de l'indication de vérification au premier dispositif externe de l'entité demandeuse en envoyant une URL de vérification incorporant le jeton sécurisé et des informations du message en texte clair au premier dispositif externe.
  11. 11. Procédé comprenant :
    en réponse à la réception d'une valeur de hachage à partir d'un dispositif informatique d'un fournisseur de confiance :
    le stockage de la valeur de hachage dans la mémoire, la valeur de hachage correspondant à des informations en texte clair associées à une entité demandeuse, les informations en texte clair incluant des informations de contact à propos de l'entité demandeuse, et la génération, par un ou plusieurs dispositifs de processeur, d'un jeton sécurisé associé à un emplacement de stockage de la valeur de hachage ; et en réponse à la réception d'un message de vérification à partir d'un premier dispositif externe de l'entité demandeuse :
    le traitement, par l'un ou plusieurs dispositifs de processeur, du message de vérification à l'aide d'une fonction de hachage pour générer une valeur de hachage, la récupération de la valeur de hachage stockée dans la mémoire, la comparaison d'une valeur générée de hachage avec la valeur de hachage extraite à partir de la mémoire, et la comparaison du jeton sécurisé généré avec les informations du jeton dans le message de vérification, en vue de vérifier une identité de l'entité demandeuse.
  12. 12. Procédé selon la revendication 11, dans lequel la génération du jeton sécurisé associé à l'emplacement de stockage comprend la génération d'une chaîne de jetons aléatoires et l'enregistrement d'une association entre la chaîne de jetons aléatoires et l'emplacement de stockage.
  13. 13. Procédé selon la revendication 12, dans lequel une longueur de la chaîne de jetons aléatoires est d'au moins 16 bits.
  14. 14. Procédé selon l'une quelconque des revendications 11 à 13, comprenant en outre le stockage du jeton sécurisé dans une base de données et l'association du jeton sécurisé avec la valeur stockée de hachage.
  15. 15. Procédé selon l'une quelconque des revendications 11 à 14, comprenant en outre l'un ou plusieurs dispositifs de processeur pré-remplissant un modèle d'inscription avec des détails du compte de l'entité demandeuse.
  16. 16. Procédé selon la revendication 15, dans lequel les détails du compte sont reçus via un paramètre de chaîne de requête d'identification associé à l'entité demandeuse.
  17. 17. Dispositif comprenant :
    une unité de communication ; et un ou plusieurs processeurs configurés pour :
    en réponse à la réception d'une valeur de hachage à partir d'un dispositif informatique d'un fournisseur de confiance :
    le stockage de la valeur de hachage dans la mémoire, la valeur de hachage correspondant à des informations en texte clair associées à une entité demandeuse, les informations en texte clair incluant des informations de contact à propos de l'entité demandeuse, et la génération d'un jeton sécurisé associé à un emplacement de stockage de la valeur de hachage ; et en réponse à la réception d'un message de vérification à partir d'un premier dispositif externe de l'entité demandeuse :
    le traitement du message de vérification à l'aide d'une fonction de hachage pour générer une valeur de hachage, la récupération de la valeur de hachage stockée dans la mémoire, la comparaison d'une valeur générée de hachage avec la valeur de hachage extraite à partir de la mémoire, et la comparaison du jeton sécurisé généré avec les informations du jeton dans le message de vérification, en vue de vérifier une identité de l'entité demandeuse.
  18. 18. Dispositif selon la revendication 17, dans lequel le jeton sécurisé associé à l'emplacement de stockage est créé en générant une chaîne de jetons aléatoires et l'enregistrement d'une association entre la chaîne de jetons aléatoires et l'emplacement de stockage.
  19. 19. Dispositif selon la revendication 18, dans lequel une longueur de la chaîne de jetons aléatoires est d'au moins 16 bits.
  20. 20. Dispositif selon l'une quelconque des revendications 17 à 19, dans lequel l'un ou plusieurs processeurs sont en outre configurés pour stocker le jeton sécurisé dans une base de données et pour associer le jeton sécurisé à la valeur stockée de hachage.
  21. 21. Dispositif selon l'une quelconque des revendications 17 à 20, dans lequel l'un ou plusieurs processeurs sont en outre configurés pour pré-remplir un modèle d'inscription avec des détails du compte de l'entité demandeuse.
  22. 22. Dispositif selon la revendication 21, dans lequel les détails du compte sont reçus via un paramètre de chaîne de requête d'identification associé à l'entité demandeuse.
FR1857843A 2017-10-25 2018-08-31 Verification d'identite preservant la confidentialite Pending FR3072802A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
USPCT/US17/58185 2017-10-25
PCT/US2017/058185 WO2019083517A1 (fr) 2017-10-25 2017-10-25 Vérification d'identité préservant la confidentialité

Publications (1)

Publication Number Publication Date
FR3072802A1 true FR3072802A1 (fr) 2019-04-26

Family

ID=60327381

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1857843A Pending FR3072802A1 (fr) 2017-10-25 2018-08-31 Verification d'identite preservant la confidentialite

Country Status (6)

Country Link
US (1) US10764051B2 (fr)
EP (1) EP3596642B1 (fr)
DE (1) DE102018121306A1 (fr)
FR (1) FR3072802A1 (fr)
GB (1) GB2567932A (fr)
WO (1) WO2019083517A1 (fr)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9678773B1 (en) 2014-09-30 2017-06-13 Amazon Technologies, Inc. Low latency computational capacity provisioning
US9600312B2 (en) 2014-09-30 2017-03-21 Amazon Technologies, Inc. Threading as a service
US9146764B1 (en) 2014-09-30 2015-09-29 Amazon Technologies, Inc. Processing event messages for user requests to execute program code
US9537788B2 (en) 2014-12-05 2017-01-03 Amazon Technologies, Inc. Automatic determination of resource sizing
US9733967B2 (en) 2015-02-04 2017-08-15 Amazon Technologies, Inc. Security protocols for low latency execution of program code
US9588790B1 (en) 2015-02-04 2017-03-07 Amazon Technologies, Inc. Stateful virtual compute system
US11132213B1 (en) 2016-03-30 2021-09-28 Amazon Technologies, Inc. Dependency-based process of pre-existing data sets at an on demand code execution environment
US10102040B2 (en) 2016-06-29 2018-10-16 Amazon Technologies, Inc Adjusting variable limit on concurrent code executions
CN108564688A (zh) * 2018-03-21 2018-09-21 阿里巴巴集团控股有限公司 身份验证的方法及装置和电子设备
US10853115B2 (en) 2018-06-25 2020-12-01 Amazon Technologies, Inc. Execution of auxiliary functions in an on-demand network code execution system
US11146569B1 (en) 2018-06-28 2021-10-12 Amazon Technologies, Inc. Escalation-resistant secure network services using request-scoped authentication information
US11099870B1 (en) 2018-07-25 2021-08-24 Amazon Technologies, Inc. Reducing execution times in an on-demand network code execution system using saved machine states
US11243953B2 (en) 2018-09-27 2022-02-08 Amazon Technologies, Inc. Mapreduce implementation in an on-demand network code execution system and stream data processing system
US11099917B2 (en) 2018-09-27 2021-08-24 Amazon Technologies, Inc. Efficient state maintenance for execution environments in an on-demand code execution system
US11943093B1 (en) 2018-11-20 2024-03-26 Amazon Technologies, Inc. Network connection recovery after virtual machine transition in an on-demand network code execution system
US11010188B1 (en) 2019-02-05 2021-05-18 Amazon Technologies, Inc. Simulated data object storage using on-demand computation of data objects
US11861386B1 (en) * 2019-03-22 2024-01-02 Amazon Technologies, Inc. Application gateways in an on-demand network code execution system
US11119809B1 (en) 2019-06-20 2021-09-14 Amazon Technologies, Inc. Virtualization-based transaction handling in an on-demand network code execution system
US11159528B2 (en) 2019-06-28 2021-10-26 Amazon Technologies, Inc. Authentication to network-services using hosted authentication information
US11190609B2 (en) 2019-06-28 2021-11-30 Amazon Technologies, Inc. Connection pooling for scalable network services
US11119826B2 (en) 2019-11-27 2021-09-14 Amazon Technologies, Inc. Serverless call distribution to implement spillover while avoiding cold starts
US11714682B1 (en) 2020-03-03 2023-08-01 Amazon Technologies, Inc. Reclaiming computing resources in an on-demand code execution system
US11165586B1 (en) * 2020-10-30 2021-11-02 Capital One Services, Llc Call center web-based authentication using a contactless card
US11593270B1 (en) 2020-11-25 2023-02-28 Amazon Technologies, Inc. Fast distributed caching using erasure coded object parts
US11550713B1 (en) 2020-11-25 2023-01-10 Amazon Technologies, Inc. Garbage collection in distributed systems using life cycled storage roots
US11388210B1 (en) 2021-06-30 2022-07-12 Amazon Technologies, Inc. Streaming analytics using a serverless compute system
US11968280B1 (en) 2021-11-24 2024-04-23 Amazon Technologies, Inc. Controlling ingestion of streaming data to serverless function executions
US12015603B2 (en) 2021-12-10 2024-06-18 Amazon Technologies, Inc. Multi-tenant mode for serverless code execution
WO2023154783A2 (fr) * 2022-02-10 2023-08-17 Fall Guy Llc, Dba Fall Guy Consulting Vérification d'identité préservant la confidentialité
CN117592124B (zh) * 2024-01-18 2024-05-07 中国科学院信息工程研究所 低开销抗泄漏与伪造的存证方法、装置、设备和存储介质

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7640578B2 (en) * 2002-07-08 2009-12-29 Accellion Inc. System and method for providing secure communication between computer systems
US8788836B1 (en) 2006-12-22 2014-07-22 Symantec Corporation Method and apparatus for providing identity claim validation
US8347093B1 (en) 2010-07-19 2013-01-01 Google Inc. Privacy preserving name verification
US9098678B2 (en) * 2011-09-15 2015-08-04 Verizon Patent And Licensing Inc. Streaming video authentication
US9847982B2 (en) * 2011-10-31 2017-12-19 Nokia Technologies Oy Method and apparatus for providing authentication using hashed personally identifiable information
US20150047003A1 (en) 2013-08-07 2015-02-12 Sal Khan Verification authority and method therefor
US9971574B2 (en) * 2014-10-31 2018-05-15 Oracle International Corporation JSON stylesheet language transformation
US10114975B1 (en) * 2017-01-13 2018-10-30 Marklogic Corporation Apparatus and method for data redaction in a semi-structured document database
GB2561875A (en) 2017-04-26 2018-10-31 Sita Advanced Travel Solutions Ltd System and method for authenticating a non-transferrable access token

Also Published As

Publication number Publication date
US10764051B2 (en) 2020-09-01
US20190363885A1 (en) 2019-11-28
EP3596642B1 (fr) 2021-03-10
EP3596642A1 (fr) 2020-01-22
GB2567932A (en) 2019-05-01
DE102018121306A1 (de) 2019-04-25
GB201813959D0 (en) 2018-10-10
WO2019083517A1 (fr) 2019-05-02

Similar Documents

Publication Publication Date Title
FR3072802A1 (fr) Verification d'identite preservant la confidentialite
US10764254B2 (en) Systems and methods of secure data exchange
US11050690B2 (en) Method for providing recording and verification service for data received and transmitted by messenger service, and server using method
US11403684B2 (en) System, manufacture, and method for performing transactions similar to previous transactions
US11741052B2 (en) Method and system for real-time collaboration and annotation-based action creation and management
CN111356995B (zh) 跨全异的不可变分布式账本网络进行身份解析的系统和方法
US8788819B2 (en) System and method for a cloud-based electronic communication vault
US8868916B2 (en) Self-contained electronic signature
Sirisha et al. Proposed solution for trackable donations using blockchain
CN114616795B (zh) 用于防止重试或重放攻击的安全机制
JP2023517049A (ja) 暗号データ入力ブロックチェーンデータ構造
JP2023535927A (ja) デジタル台帳ベースのヘルスデータ共有および管理
David Managing IoT data on hyperledger blockchain
Toma et al. Secure IoT Supply Chain Management Solution Using Blockchain and Smart Contracts Technology
JP2023001908A (ja) 下流制御を用いた文書の配布および追跡
Tsai et al. STRISA: a new regulation architecture to enforce travel rule
Hardjono et al. Privacy-preserving claims exchange networks for virtual asset service providers
US11893553B1 (en) Systems and methods of exchanging digital assets using a public key cryptography (PKC) framework
Sathiaseelan et al. Multi-Level Secure Framework (MLSF) for composite web services
Zanbaghi A Blockchain-Based Privacy-Preserving Physical Delivery System
Simone The Digital Wallet paradigm for identity
WO2023183494A1 (fr) Plateforme intégrée pour enregistrement, suivi et validation d'actifs numériques
Kumar et al. USER CENTRIC APPROACH TO IDENTITY MANAGEMENT IN CLOUD COMPUTING ENVIRONMENT: AN EMPIRICALLY TESTED FRAMEWORK
dos Santos DClaims: A Censorship-Resistant Web Annotations System
US10380592B1 (en) Secure verification of claims

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLFP Fee payment

Year of fee payment: 3

PLSC Publication of the preliminary search report

Effective date: 20210212

RX Complete rejection

Effective date: 20211217