FR3107416A1 - Tokenisation aléatoire efficace dans un environnement dématérialisé - Google Patents

Tokenisation aléatoire efficace dans un environnement dématérialisé Download PDF

Info

Publication number
FR3107416A1
FR3107416A1 FR2001463A FR2001463A FR3107416A1 FR 3107416 A1 FR3107416 A1 FR 3107416A1 FR 2001463 A FR2001463 A FR 2001463A FR 2001463 A FR2001463 A FR 2001463A FR 3107416 A1 FR3107416 A1 FR 3107416A1
Authority
FR
France
Prior art keywords
token
node
data
index
service
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.)
Granted
Application number
FR2001463A
Other languages
English (en)
Other versions
FR3107416B1 (fr
Inventor
Roman Bayon
Sylvain Palmier
Rodrigo Broggi
Michele Minelli
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.)
Amadeus SAS
Original Assignee
Amadeus SAS
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 Amadeus SAS filed Critical Amadeus SAS
Priority to FR2001463A priority Critical patent/FR3107416B1/fr
Priority to US17/098,846 priority patent/US11921877B2/en
Priority to EP20208945.4A priority patent/EP3866431A1/fr
Priority to CN202011378964.1A priority patent/CN113271203A/zh
Publication of FR3107416A1 publication Critical patent/FR3107416A1/fr
Application granted granted Critical
Publication of FR3107416B1 publication Critical patent/FR3107416B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/0435—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 symmetric encryption, i.e. same key used for encryption and decryption
    • 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
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • 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
    • G06F21/33—User authentication using certificates
    • G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • 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/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • 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/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • 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/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0863—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving passwords or one-time passwords
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • 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/3226—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 predetermined code, e.g. password, passphrase or PIN
    • 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/3247—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 digital signatures
    • 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/3271—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 challenge-response
    • 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/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0433—Key management protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/068—Network architectures or network communication protocols for network security for supporting key management in a packet data network using time-dependent keys, e.g. periodically changing keys

Abstract

Des systèmes et des procédés pour fournir une tokenisation décentralisée avec des données de mappage dénuées de données sensibles. Un nœud reçoit un ensemble de paires index-clé générées par un service de randomisation extérieur au nœud. Chaque paire index-clé dans l'ensemble de paires index-clé définit une valeur d'index particulière mappée sur une valeur de clé aléatoire particulière. Le nœud crée une structure de mappage en utilisant l'ensemble de paires index-clé. Des données en transit comprenant des données sensibles sont reçues. Un service de tokenisation d'un nœud génère un token pour les données sensibles en utilisant la structure de mappage.

Description

TOKENISATION ALÉATOIRE EFFICACE DANS UN ENVIRONNEMENT DÉMATÉRIALISÉ
La présente invention concerne de façon générale des processus de tokenisation bien qu’elle n’y soit pas limitée. Plus spécifiquement, la présente invention concerne des techniques pour fournir une tokenisation décentralisée avec un mappage de données dénuées de données sensibles.
CONTEXTE
Certaines données électroniques stockées sur des dispositifs informatiques ou échangées entre dispositifs informatiques sur des canaux de communication en couplant ces dispositifs incluent des données sensibles. Des exemples de ces données sensibles incluent: des informations d’identification (p. ex. un mot de passe, un nom d’identifiant, etc.) des informations médicales privées numériques, des numéros de compte principaux, des numéros de sécurité sociale, des numéros de cartes de crédit, et similaire. Dans certains cas, une personne non autorisée peut obtenir ces données sensibles à des fins néfastes. Par conséquent, diverses techniques sont utilisées pour mitiger l’exposition de ces données sensibles à des personnes non autorisées.
Une de ces techniques utilisées pour mitiger l’exposition des données sensibles à des personnes non autorisées est connue sous le nom de tokenisation de données. La tokenisation de données ou tokenisation fait référence généralement à un processus de remplacement des données sensibles par des données non sensibles. Comme l’explique le conseil des normes de sécurité de l’industrie des cartes de paiement (« PCI ») « la sécurité objective d’un processus de tokenisation est d’assurer que le token en résultant n’a aucune valeur pour un assaillant. » Dans ce but, un processus de tokenisation est configuré pour générer des « tokens » (c.-à-d. des versions tokenisées de données sensibles) qui manquent de signification extrinsèque ou de valeur. Puisque les tokens manquent de signification extrinsèque ou de valeur, on retient généralement le mappage de données qui associe chaque token à une instance particulière de données sensibles qu’il remplace. Ce mappage de données peut faciliter la dérivation de données sensibles remplacées à partir d’un token correspondant.
Ainsi, des techniques améliorées de tokenisation de données sensibles et d’amélioration de la sécurité des données de mappage sont nécessaires pour satisfaire l’objectif de sécurité d’un processus de tokenisation.
RÉSUMÉ
Des modes de réalisation de la présente invention fournissent des systèmes, des procédés et des supports de stockage lisibles par ordinateur pour fournir une tokenisation décentralisée avec des données de mappage dénuées de données sensibles. Dans un mode de réalisation, un système inclut un nœud comprenant un processeur, un support de stockage lisible par ordinateur et un service de tokenisation. Le support de stockage lisible par ordinateur inclut des instructions qui, lorsqu’elles sont exécutées par le processeur, amènent le système à effectuer des opérations. Les opérations incluent la réception, par le nœud, d’un ensemble de paires index-clé générées par un service de randomisation extérieur au nœud. Chaque paire index-clé dans l’ensemble de paires index-clé définit une valeur d’index particulière mappée sur une aléatoire particulière. Le nœud crée une structure de mappage en utilisant l’ensemble de paires index-clé. Par exemple, le nœud analyse l’ensemble de paires index-clé pour créer la structure de mappage. Des données en transit comprenant des données sensibles sont reçues. Le service de tokenisation d’un nœud génère un token pour les données sensibles en utilisant la structure de mappage.
Dans certains exemples, la structure de mappage inclut une pluralité de valeurs d’index et dans laquelle la génération du token comprend:
la sélection aléatoire d’une valeur d’index parmi la pluralité des valeurs d’index ; et
l’exécution d’une opération inversible sur les données sensibles et une valeur de clé aléatoire mappée sur la valeur d’index dans la structure de mappage pour générer le token.
Dans certains exemples, le nœud est un premier nœud, dans lequel le système comprend par ailleurs le service de randomisation et un deuxième nœud et dans lequel le service de randomisation est configuré pour pousser périodiquement des ensembles actualisés de paires index-clé vers le premier nœud et le deuxième nœud.
Dans certains exemples, les instructions, lorsqu’elles sont exécutées, amènent par ailleurs le système à effectuer des opérations supplémentaires, les opérations supplémentaires comprenant:
la transmission du token à une interface d’application d’un processus d’exécution en utilisant un premier ensemble de ressources informatiques qui est isolé du deuxième ensemble de ressources informatiques que le nœud affecte au service de tokenisation.
Dans certains exemples, le nœud est un premier nœud dans lequel le système comprend par ailleurs un deuxième nœud et dans lequel le premier ensemble de ressources informatiques est affecté au processus par le deuxième nœud.
Dans certains exemples, le premier ensemble de ressources informatiques est affecté au processus par le nœud.
Dans certains exemples, le token est transmis à l’interface d’application sans stocker les données mappant les données sensibles sur le token.
Dans certains exemples, les instructions, lorsqu’elles sont exécutées, amènent par ailleurs le système à effectuer des opérations supplémentaires, les opérations supplémentaires comprenant:
le cryptage du token avant la transmission du token à l’interface d’application du processus.
Dans certains exemples, le token et les données sensibles sont chacun composés d’un nombre d’octets équivalent, et dans lesquels le token comprend un premier nombre de bits et les données sensibles comprennent un deuxième nombre de bits qui est différent du premier nombre de bits.
Dans certains exemples, le service de randomisation est empêché d’accéder aux données de transaction.
Dans certains exemples, dans lesquels la réception des données en transit comprend:
la détection, par une unité de traitement de flux de données du nœud traitant les données en transit, des données sensibles à l’intérieur des données en transit.
Dans un autre mode de réalisation, un procédé inclut la réception, par un nœud, d’un ensemble de paires index-clé générées par un service de randomisation extérieur au nœud. Chaque paire index-clé dans l’ensemble de paires index-clé définit une valeur d’index particulière mappée sur une aléatoire particulière. Le nœud crée une structure de mappage en utilisant l’ensemble de paires index-clé. Des données en transit comprenant des données sensibles sont reçues. Un service de tokenisation du nœud génère un token pour les données sensibles en utilisant la structure de mappage.
Dans certains exemples, la structure de mappage inclut une pluralité de valeurs d’index et dans laquelle la génération du token comprend:
la sélection aléatoire d’une valeur d’index parmi la pluralité des valeurs d’index ; et
l’interrogation d’une structure de liste noire du nœud associée à la structure de mappage pour identifier un état de la valeur d’index.
Dans certains exemples, le procédé comprend par ailleurs:
la synchronisation de la structure de liste noire du nœud avec une copie de la structure de liste noire résidant dans les ressources de mémoire d’un autre nœud extérieur au nœud.
Dans certains exemples, le procédé comprend par ailleurs:
le cryptage du token pour obtenir un token crypté ; et
la transmission du token crypté à une interface d’application d’un processus d’exécution en utilisant un premier ensemble de ressources informatiques qui est isolé du deuxième ensemble de ressources informatiques que le nœud affecte au service de tokenisation.
Dans certains exemples, le procédé comprend par ailleurs:
la configuration d’un service de détokenisation pour détokeniser les tokens en utilisant une pluralité de structures de mappage associées à une pluralité d’époques, dans lequel la structure de mappage est une de la pluralité des structures de mappage résidant dans les ressources de mémoire accessibles au service de détokenisation et dans lequel au moins une époque parmi la pluralité des époques précède une époque correspondante de la structure de mappage.
Dans certains exemples, une structure de mappage donnée de la pluralité des structures de mappage associées à ladite au moins une époque est utilisée uniquement pour les opérations de détokenisation, non pour les opérations de tokenisation.
Dans certains exemples, le service de détokenisation sélectionne une structure de mappage particulière de la pluralité des structures de mappage pour détokeniser un token donné en utilisant un identifiant de version extrait pour le token donné.
Dans certains exemples, le procédé comprend par ailleurs:
la détokenisation, par un service de détokenisation, du token en utilisant la structure de mappage et une valeur d’index extraite du token.
Dans certains exemples, le token est un premier token, le procédé comprenant par ailleurs:
la réception d’un deuxième token généré par un service de tokenisation distant en utilisant la structure de mappage, le service de tokenisation distant s’exécutant sur des ressources informatiques extérieures au nœud ;
le décryptage du deuxième token pour obtenir un deuxième token décrypté ;
l’extraction d’un identifiant de version associé à la structure de mappage à partir du deuxième token décrypté ; et
la détokenisation du deuxième token décrypté en utilisant une valeur d’index extraite du deuxième token décrypté et une valeur aléatoire mappée sur la valeur d’index dans la structure de mappage.
Dans certains exemples, le nœud comprend des ressources de mémoire stockant des données au repos et dans lequel les données sensibles sont absentes des données au repos.
Dans un autre mode de réalisation, un support de stockage non transitoire lisible par ordinateur, incluant des instructions lisibles par ordinateur, est fourni. Lors de l’exécution par un processeur d’un dispositif informatique, les instructions lisibles par ordinateur amènent le dispositif informatique à recevoir, au niveau d’un nœud, un ensemble de paires index-clé générées par un service de randomisation extérieur au nœud. Chaque paire index-clé dans l’ensemble de paires index-clé définit une valeur d’index particulière mappée sur une aléatoire particulière. Le nœud crée une structure de mappage en utilisant l’ensemble de paires index-clé. Des données en transit comprenant des données sensibles sont reçues. Un service de tokenisation d’un nœud génère un token pour les données sensibles en utilisant la structure de mappage.
Dans des modes de réalisation, la structure de mappage inclut une pluralité de valeurs d’index et la génération du token pour les données sensibles comprend la sélection aléatoire d’une valeur d’index parmi une pluralité de valeurs d’index. Dans des modes de réalisation, la génération du token pour les données sensibles inclut par ailleurs l’exécution d’une opération inversible sur les données sensibles et une valeur aléatoire mappée sur la valeur d’index dans la structure de mappage pour générer une portion du token. Dans des modes de réalisation, la génération du token pour les données sensibles comprend par ailleurs la concaténation de la valeur d’index à la portion du token. Dans des modes de réalisation, la génération du token pour les données sensibles comprend par ailleurs la concaténation d’un identifiant de version associé à la structure de mappage de la portion du token.
Ce résumé est fourni pour présenter, sous une forme simplifiée, une sélection de concepts qui seront décrits par ailleurs dans la description détaillée ci-après. Ce résumé n’est pas censé identifier des caractéristiques clés ou des caractéristiques essentielles de l’invention revendiquée et n’est pas non plus destiné à être utilisé de façon isolée comme outil de détermination du champ d’application de l’invention revendiquée.
Les dessins accompagnants qui sont incorporés et constituent une partie de cette spécification, illustrent divers modes de réalisation de l’invention et, avec la description générale de l’invention ci-dessus et la description détaillée des modes de réalisation donnée ci-dessous, servent à expliquer les modes de réalisation de l’invention. Dans les dessins, des numéros de référence similaires sont utilisés pour désigner des parties similaires dans les diverses vues.
est un diagramme bloc d’un exemple d’environnement d’exploitation adapté à l’implémentation des aspects de la présente invention.
illustre une vue d’ensemble de haut niveau de la segmentation d’éléments dans un environnement fiable, selon un mode de réalisation de la présente invention.
illustre une vue d’ensemble de haut niveau de la segmentation d’éléments dans un environnement fiable selon un mode de réalisation de la présente invention.
est un diagramme bloc d’un système exemplaire de la segmentation d’éléments au sein d’un environnement fiable en utilisant des services de tokenisation centralisés.
est un diagramme bloc d’un système exemplaire de la segmentation d’éléments au sein d’un environnement fiable en utilisant des services de tokenisation centralisés.
est un diagramme bloc d’un nœud exemplaire approprié pour implémenter des aspects de l’invention décrits dans la présente.
est un organigramme illustrant un exemple d’un procédé fournissant une détokenisation décentralisée avec des données de mappage dénuées de données sensibles, selon un mode de réalisation de l’invention.
illustre une vue d’ensemble conceptuelle de haut niveau d’un cryptage déterministe.
illustre une chronologie montrant une actualisation périodique des structures de mappage, selon un mode de réalisation de la présente invention.
illustre un exemple de versionnage de mappage de structure une première fois.
illustre l’exemple d’un versionnage de structure de mappage une deuxième fois, subséquemment à la première fois illustrée dans la FIG.9.
illustre un exemple de données sensibles et un token associé ayant un nombre équivalent d’octets tout en ayant un nombre de bits différents.
est un diagramme bloc d’un exemple d’environnement informatique adapté à l’implémentation des modes de réalisation de l’invention.
DESCRIPTION DÉTAILLÉE
Les techniques décrites dans la présente concernent la tokenisation de données sensibles et l’amélioration de la sécurité des données de mappage de token. Faisant référence à la FIG.1, un environnement d’exploitation exemplaire pour implémenter les aspects de la présente invention est illustré et désigné de façon générale par le numéro100. L’environnement d’exploitation100 inclut un dispositif client 110, un dispositif informatique120, un serveur de tokens 130, un module de sécurité du matériel (« HSM ») 140, une base de données ou coffre de tokens 150 et un système interne160. La FIG.1 illustre les divers composants en cours de communication les uns avec les autres via des réseaux (p. ex. le réseau170) qui peuvent inclure un ou plusieurs réseaux publics et/ou privés. Des exemples de réseaux qui sont appropriés pour l’implémentation du réseau170 incluent: des réseaux de zone locale (LANs), des réseaux de zone étendue (WANs), un réseau cellulaire, l’Internet et similaire.
À l’intérieur de l’environnement d’exploitation100 il y a un environnement fiable102 et un environnement non fiable 104. L’environnement fiable102 représente une portion de l’environnement d’exploitation100 qui est au moins partiellement cloisonnée par rapport aux autres portions de l’environnement d’exploitation100, telles que l’environnement non fiable 104. À titre d’exemple, l’environnement fiable102 peut être séparé ou segmenté des autres portions de l’environnement d’exploitation100 en utilisant des barrières physiques (p. ex. des cloisons) des barrières logiques (p. ex. des pare-feu), et similaires. À travers ce cloisonnement, l’environnement fiable102 et l’environnement non fiable 104 peuvent implémenter des mesures de sécurité différentes en fournissant des niveaux de protection différents pour les données stockées et/ou communiquées dans chaque environnement respectif. Par conséquent, la probabilité qu’une personne non autorisée soit capable de compromettre les données stockées et/ou communiquées dans chaque environnement respectif de l’environnement d’exploitation100 peut être différente.
Par exemple, l’environnement fiable102 peut implémenter des mesures de sécurité qui fournissent un niveau de protection plus élevée pour les données stockées et/ou communiquées dans l’environnement fiable102 que les mesures de sécurité fournies implémentées par l’environnement non fiable 104 pour les données stockées et/ou communiquées dans l’environnement non fiable 104. Dans cet exemple, une personne non autorisée serait plus à même de compromettre des données stockées et/ou communiquées dans l’environnement non fiable 104qu’elle ne le serait pour les données stockées et/ou communiquées dans l’environnement fiable102. Par extension, si ces données incluaient des données sensibles, une personne non autorisée serait plus à même de compromettre des données stockées et/ou communiquées dans l’environnement non fiable 104qu’elle ne le serait pour les données stockées et/ou communiquées dans l’environnement fiable102.
Ainsi qu’utilisé dans la présente, « données sensibles » fait référence à une quelconque information concernant une entité qui pourrait exposer l’entité à un risque élevé ou à une perte d’un avantage en cas de compromission, de perte ou de divulgation accidentelle à travers un accès non autorisé. Des exemples de données sensibles incluent: des informations d’identification (p. ex., un mot de passe, un nom d’utilisateur, etc.) ; des informations d’identification personnelle (« PII ») (p. ex. des numéros de sécurité sociale, des numéros de passeport, etc.) ; des informations médicales personnelles numériques (« PHI ») ; des données financières (p. ex. des numéros de cartes de crédit, des numéros de comptes bancaires, etc.).
Dans l’environnement d’exploitation100, la tokenisation est implémentée pour minimiser l’exposition de données sensibles à des personnes non autorisées dans l’environnement non fiable 104 comme cela sera décrit de façon plus détaillée ci-dessous. Dans ce but, les dispositifs informatiques dans l’environnement non fiable 104, tels que le dispositif client 110 et le dispositif informatique120 soumettent des requêtes de tokenisation incluant des données sensibles au serveur de tokens 130. En réponse à ces requêtes de tokenisation, le serveur de tokens 130 renvoie des tokens. Ainsi qu’utilisé dans la présente, un « token » fait référence à des données non sensibles manquant de signification extrinsèque ou de valeur qui sert de substitut aux données sensibles associées. Des exemples de valeurs appropriées pour implémenter les tokens incluent: des valeurs numériques, des valeurs alphabétiques, des valeurs alphanumériques, et similaires.
À titre d’exemple, le dispositif client 110 peut avoir besoin d’échanger des informations de carte de crédit avec un dispositif informatique120 au cours d’une transaction. Pour minimiser l’exposition des informations de la carte de crédit à des personnes non autorisées dans l’environnement non fiable 104, le dispositif client 110 peut soumettre une requête de tokenisation au serveur de tokens 130. La requête de tokenisation soumise par le dispositif client 110 peut inclure les informations de la carte de crédit. En réponse à la requête de tokenisation, le dispositif client 110 peut recevoir une réponse de tokenisation du serveur130 comprenant un token mappé sur les informations de la carte de crédit. Le token que le dispositif client 110 reçoit sert de substitut pour les informations de la carte de crédit. Au lieu de transmettre les informations de la carte de crédit au dispositif informatique120, le dispositif client 110 transmet le token mappé sur les informations de la carte de crédit.
Dans l’environnement d’exploitation100, un dispositif informatique peut transmettre une requête de détokenisation incluant un token au serveur de tokens 130 pour récupérer les données sensibles associées au token. En réponse à la requête de tokenisation, le dispositif informatique120 peut recevoir une réponse de détokenisation provenant du serveur de tokens 130. La réponse de détokenisation que le dispositif informatique120 reçoit comprend une instance particulière de données sensibles associées au token en mappant les données152 stockées dans la base de données150 qui associe de façon unique chaque token à une donnée sensible particulière. Dans un mode de réalisation, la base de données150 fournit un stockage exclusif pour des données de mappage de token dans l’environnement d’exploitation100.
Poursuivant avec l’exemple ci-dessus, le dispositif informatique120 peut transmettre une requête de détokenisation qui inclut le token reçu du dispositif client110 au serveur de tokens 130. En réponse à la requête de détokenisation, le serveur130 peut transmettre au dispositif informatique120 une réponse de détokenisation qui inclut les informations de carte de crédit incluses dans la requête de tokenisation soumise par le dispositif client 110.
Dans certains modes de réalisation, le serveur de tokens 130 peut interagir avec le HSM140 pour effectuer les opérations cryptographiques sur diverses données échangées ou stockées dans l’environnement d’exploitation100. Par exemple, le serveur de tokens 130 peut transmettre une requête de cryptage incluant des données (p. ex. des données sensibles) au HSM140. En réponse, le HSM140 peut effectuer une opération cryptographique sur les données incluses dans la requête de cryptage pour générer des données cryptées. Le serveur de tokens 130 peut ensuite recevoir une réponse de cryptage incluant les données cryptées provenant du HSM140.
L’homme de métier reconnaîtra qu’un HSM décrit une circuiterie spécialisée (p. ex. un crypto processeur) qui est optimisée pour effectuer des opérations cryptographiques basées sur du matériel. Ces opérations cryptographiques incluent des opérations de cryptage et des opérations de décryptage. Une opération de cryptage implique d’appliquer des données sources et une clé à une entrée d’un algorithme de cryptage pour produire des données cryptées sur un produit de l’algorithme de cryptage. Une opération de décryptage implique d’appliquer des données cryptées et une clé à une entrée d’un algorithme de décryptage pour produire les données sources. Des exemples d’algorithmes appropriés pour implémenter l’algorithme de cryptage et/ou l’algorithme de décryptage incluent: des algorithmes de normes de cryptage avancées (AES) ; des algorithmes de normes de cryptage de données (DES) ; des algorithmes d’algorithme de signature numérique (DSA) ; des algorithmes Rivest-Shamir-Adleman (RSA) ; et similaires.
Ainsi que noté ci-dessus, l’environnement fiable102 peut implémenter des mesures de sécurité qui facilite la sécurité des données dans l’environnement fiable102. Dans un mode de réalisation, une de ces mesures de sécurité comprend la séparation d’éléments de l’environnement fiable102 des autres éléments de l’environnement fiable102. Les FIGS. 2A et 2B illustrent une vue d’ensemble conceptuelle de haut niveau de cette séparation. Dans les FIGS. 2 A et 2B, la partition 210 sépare des éléments d’un environnement fiable comprenant un service de tokenisation220 et un système interne230 des éléments d’un environnement non fiable comprenant le système externe240. Ainsi, la partition210 peut représenter une ou plusieurs partitions physiques et/partitions logiques qui séparent l’environnement fiable102 de l’environnement non fiable 104 dans l’environnement d’exploitation100. La séparation fournie la partition210 améliore la sécurité des données dans l’environnement fiable en limitant l’accès à ces données par des éléments de l’environnement non fiable, tels que le système externe240.
La sécurité de données supplémentaires dans l’environnement fiable peut être accomplie en implémentant une mesure de sécurité qui limite l’accès aux données sensibles par des éléments de l’environnement fiable. Dans ce but, la partition250 peut être implémentée pour séparer le service de tokenisation220 du système interne230 ainsi que l’illustre la FIG.2 B. La partition250 fournit une sécurité supplémentaire pour les données au sein de l’environnement fiable en isolant des éléments impliqués dans la génération de tokens (p. ex. le service de tokenisation220) d’autres éléments de l’environnement fiable qui peuvent utiliser des tokens (p. ex., le système interne 230). Cette isolation peut aussi réduire un nombre d’éléments au sein de l’environnement fiable qui seraient soumis à un contrôle lorsque les données sensibles sont soumises à la conformité réglementaire.
Par exemple, la partition250 n’a pas été implémentée dans la FIG.2A pour séparer le service de tokenisation220 du système interne230. La séparation fournie par la partition250 étant absente, le système interne230 peut faire l’objet d’un contrôle dans la FIG.2A en raison de la présence de données sensibles au sein des tokens traités par le système interne230. Par contraste, la partition250 a été implémentée dans la FIG.2B pour segmenter le service de tokenisation220 du système interne230. En dépit de la présence de données sensibles au sein des tokens traités par le système interne230, la partition250 fournit l’isolation dans la FIG.2B qui peut exclure que le système interne230 soit soumis à une conformité réglementaire. Ainsi, le système interne230 peut ne pas être soumis à un contrôle dans la FIG.2 B.
En continuant avec l’exemple exposé ci-dessus en référence à la FIG.1, l’environnement fiable102 peut représenter une plateforme de commerce électronique. Dans ce cas, le dispositif client 110 peut soumettre les informations de la carte de crédit dans le cadre de la transaction menée avec la plateforme de commerce électronique. L’homme de métier reconnaîtra que le conseil des normes de sécurité PCI établit des directives règlementaires (p. ex., la norme de sécurité des données PCI [« PCI-DSS »]) qui gouvernent de nombreuses transactions de ce genre impliquant des informations de carte de crédit. Si la PCI-DSS gouverne des transactions impliquant les informations de carte de crédit soumises par le dispositif client 110, chaque élément de l’environnement fiable102 peut faire l’objet d’un contrôle dans le cadre de la conformité qu’il définit.
Dans le cadre de la PCI-DSS, tous les systèmes qui stockent, traitent, ou transmettent des données de détenteur de carte de crédit (p. ex. des informations de carte de crédit) rentrent dans le champ d’application de la conformité PCI-DSS. La tokenisation des informations de carte de crédit soumise par le dispositif client 110 serait vraisemblablement interprétée comme étant un traitement des données de détenteur de carte. Par conséquent, le serveur de tokens 130 serait vraisemblablement considéré comme étant dans le champ d’application de la conformité PCI-DSS et donc soumis à un contrôle. La base de données150 serait vraisemblablement considérée comme étant dans le champ de conformité de la PCI-DSS et soumise à un contrôle si les informations de la carte de crédit étaient incluses dans les données de mappage152.
Dans certains cas, le cryptage des données de détenteurs de cartes est suffisant pour placer les données du détenteur de carte en dehors du champ de conformité PCI-DSS. Ainsi, le système interne160 peut être considéré comme étant en dehors du champ de conformité PCI-DSS si le serveur de tokens 130 soumet les informations de carte de crédit au HSM140 pour cryptage dans le cadre du processus de tokenisation préalablement à la transmission du token résultant au système interne160 pour un traitement ultérieur de la transaction. Cependant, la PCI-DSS considère les données de détenteur de carte cryptées comme étant dans le champ de conformité PCI-DSS lorsqu’elles sont présentes dans le même environnement que la clé de décryptage. Ainsi, la PCI-DSS exigerait vraisemblablement que la plateforme de commerce électronique (représentée par l’environnement fiable102) implémente une partition, entre le HSM140 et les systèmes internes160, similaire à la partition250 de la FIG.2B pour que le système interne160 reste en dehors du champ de conformité PCI-DSS. En l’absence de cette isolation le système interne160 serait vraisemblablement considéré comme étant dans le champ de conformité PCI-DSS en traitant le token comprenant les informations de carte de crédit cryptées et donc soumis à un contrôle.
Chacun des systèmes montrés dans la FIG.1 peut être implémenté via tout type de système informatique tel que le système informatique1200 décrit de façon plus détaillée ci-dessous en référence à la FIG. 12. Chaque système montré dans la FIG.1 peut comprendre un seul dispositif ou des dispositifs multiples coopérant dans un environnement distribué. Par exemple, le serveur de tokens 130, le HSM140 et/ou la base de données150 et/ou le système interne160 peuvent être fournis via de multiples dispositifs arrangés dans un environnement distribué qui fournissent collectivement la fonctionnalité décrite dans la présente. De plus, d’autres composants non représentés peuvent aussi être inclus dans l’environnement distribué.
La FIG.3 est un diagramme bloc d’un système exemplaire 300 de la segmentation d’éléments dans un environnement fiable en utilisant une tokenisation centralisée. Dans la FIG.3, les nœuds310 et 330 représentent généralement des points extrémité de l’environnement fiable302. Des données sensibles sont reçues provenant des éléments d’un environnement non fiable 304 via le nœud310 et sont renvoyées vers des éléments de l’environnement non fiable 304 via le nœud330. Pour faciliter une réduction du nombre d’éléments au sein de l’environnement fiable302 qui ont accès à des données sensibles, le nœud310 implémente la partition312 et le nœud330 implémente la partition332. Dans un mode de réalisation, l’environnement fiable302 et l’environnement non fiable 304 sont implémentés dans l’environnement fiable102 et dans l’environnement non fiable 104 de la FIG.1, respectivement.
Le nœud310 comprend une unité de traitement de flux de données pour traiter les données reçues des éléments de l’environnement non fiable 304 qui interviennent entre la partition312 et l’environnement non fiable 304. Dans la FIG.3, cette unité de traitement de flux de données comprend un service d’interception314. Le service d’interception314 est configuré pour soumettre des requêtes de tokenisation comprenant les données sensibles reçues des éléments de l’environnement non fiable 304, au serveur de tokens 320. En réponse à chaque requête de tokenisation, le service d’interception314 reçoit une réponse de tokenisation comprenant un token généré par le serveur de tokens 320 pour des données sensibles incluses dans cette requête de tokenisation. Les tokens générés par le serveur de tokens 320 sont communiqués à partir du service d’interception314 aux autres éléments (p. ex. les événements segmentés316 et/ou 336) de l’environnement fiable302 via la partition312 pour traitement ultérieur.
Le nœud330 comprend une unité de traitement de flux de données pour traiter les données reçues des éléments de l’environnement non fiable 304 qui interviennent entre la partition332 et l’environnement non fiable 304. Dans la FIG.3, cette unité de traitement de flux de données comprend un service d’interception334. Le service d’interception334 est configuré pour soumettre des requêtes de détokenisation au serveur de tokens 320 comprenant des tokens reçus en provenance d’autres éléments (p. ex. les éléments segmentés316 et/ou 336) de l’environnement fiable302 via la partition332. En réponse à chaque requête de tokenisation, le service d’interception334 reçoit une réponse de tokenisation du serveur de tokens 320 comprenant une instance particulière de données sensibles mappées sur un token donné inclus dans cette requête de tokenisation. Le service d’interception314 communique chaque instance de données sensibles reçue du serveur de tokens 320 à environnement non fiable 304 sur la base d’une information d’adresse que le service interception 314 reçoit avec un token correspondant.
En traitant les requêtes de tokenisation et de détokenisation reçues des points d’extrémité de l’environnement fiable302, le serveur de tokens 320 fournit à l’environnement fiable302 une tokenisation centralisée. Un aspect de la tokenisation centralisée dans l’environnement fiable302 est qu’une quelconque donnée de mappage impliquée dans le traitement des requêtes de tokenisation et de détokenisation peut être localisée au niveau du serveur de tokens 320. En conséquence, l’environnement fiable302 peut limiter ces données de mappage aux données de mappage322 stockées dans la base de données324. En faisant ceci, l’environnement fiable302 peut réduire ou éliminer les opérations de réplication de données que certaines implémentations de tokenisation décentralisée effectuent pour assurer que des données de mappage cohérentes soient disponibles à chaque endroit où les opérations de tokenisation et de détokenisation surviennent.
Un autre aspect de la tokenisation centralisée est que chaque opération de tokenisation ou de détokenisation implique une communication aller-retour entre un nœud d’un environnement fiable302 et le serveur de tokens 320. En conséquence, toute communication liée à des données sensibles entre l’environnement fiable302 et l’environnement non fiable 304 subit des délais de traitement causés par ces communications aller-retour entre le serveur de tokens 320 et un nœud de l’environnement fiable302. Une autre conséquence du fait que le serveur de tokens 320 soit impliqué dans chaque opération de tokenisation ou de détokenisation est que le serveur de tokens 320 représente un unique point d’échec pour la tokenisation au sein de l’environnement fiable302. C’est-à-dire, que si le serveur de tokens 320 est hors service, la tokenisation au sein de l’environnement fiable302 peut cesser.
La FIG.4 est un diagramme bloc d’un système exemplaire 400de segmentation d’éléments dans un environnement fiable402 en utilisant une tokenisation décentralisée. Dans la FIG.4, les nœuds410 et 430 représentent généralement des points d’extrémité de l’environnement fiable402. Des données sensibles sont reçues provenant des éléments d’un environnement non fiable 404 via le nœud410 et sont renvoyés vers des éléments de l’environnement non fiable 404 via le nœud430. Pour faciliter une réduction du nombre d’éléments au sein de l’environnement fiable402 qui ont accès à des données sensibles, le nœud410 implémente la partition412 et le nœud430 implémente la partition432.
Une comparaison entre la FIG.3 et la FIG.4 illustre que, contrairement à l’environnement fiable302 dans lequel le serveur de tokens 320 fournit une tokenisation113, l’environnement fiable402 implémente une tokenisation décentralisée. Dans ce but, le nœud410 comprend un serveur de tokenisation414 qui intervient entre la partition412 et l’environnement non fiable 404. Le service de tokenisation414 est configuré pour générer des tokens pour des données sensibles reçues en provenance d’éléments de l’environnement non fiable 404 en utilisant des données de mappage422 créées avec un ensemble(s) de paires index-clé générées par le service de randomisation420, ainsi que décrit de façon plus détaillée ci-dessous. Dans un mode de réalisation, le service de randomisation420 est implémenté en utilisant un générateur de nombres aléatoires. Les tokens sont générés par le service de tokenisation414 aux autres éléments (p. ex. les événements segmentés416 et/ou 436) de l’environnement fiable402 via la partition412 pour traitement ultérieur.
Le nœud430 comprend un service de détokenisation434 qui intervient entre la partition432 et l’environnement non fiable 404. Le service de détokenisation434 est configuré pour détokeniser chaque token reçu provenant d’autres éléments (p. ex. les éléments segmentés416 et/ou 436) de l’environnement fiable402 via la partition432 en utilisant les données de mappage422 pour obtenir une instance particulière de données sensibles associée à ce token, ainsi que décrit de façon plus détaillée ci-dessous. Le service de détokenisation414 communique chaque instance de données sensibles reçue à l’environnement non fiable 404 sur la base d’une information d’adresse que le service de détokenisation414 reçoit avec un token correspondant.
Un aspect de la décentralisation de la tokenisation est que les opérations de tokenisation et de détokenisation sont traitées localement à des points d’extrémité de l’environnement fiable402, évitant ainsi tout aller-retour de communications entre l’environnement fiable402 et un serveur de tokens centralisé. En conséquence, les retards de propagation de communications relatives à des données sensibles entre l’environnement fiable402 et l’environnement non fiable 404 sont moindre que ceux subis par des communications relatives à des données sensibles impliquant l’environnement fiable 302.
Une autre conséquence de la décentralisation de tokenisation est qu’un environnement fiable402 minimise une probabilité d’échecs de points uniques. Bien que le service de randomisation420 puisse représenter un unique point d’échec pour la tokenisation au sein de l’environnement fiable402, ce risque est minimisé en chargeant préalablement les données de mappage422 dans des bases de données (p. ex. les bases de données418 et/ou 438) accessibles aux points extrémité de l’environnement fiable402. C’est-à-dire que si le service de randomisation420 charge préalablement les données de mappage422 dans ces bases de données avant que les opérations de tokenisation de détokenisation ne soient traitées, la tokenisation au sein de l’environnement fiable402 peut continuer si le service de randomisation420 devient par la suite inopérable.
Notamment, l’environnement fiable402 implémente une couche supplémentaire d’isolation entre les éléments segmentés et les données sensibles au-delà de l’implémentation des partitions412 et 432 sur les nœuds410 et 430, respectivement. Cette couche supplémentaire d’isolation est liée au contenu des données de mappage422. En particulier, les données de mappage422 sont dénuées de toute donnée sensible. Au lieu de cela, les données de mappage422 sont créées en utilisant un ensemble de paires index-clé générées par un service de randomisation420, chaque paire index-clé définissant une valeur d’index particulière mappée sur une valeur de clé aléatoire particulière. Dans un mode de réalisation, le service de randomisation420 comprend un privilège de lecture qui empêche le service de randomisation420 d’accéder aux données de transaction (p. ex., les données de transaction en cours de traitement par des éléments segmentés de l’environnement fiable402). Dans un mode de réalisation, le service de randomisation420 est configuré pour pousser périodiquement des ensembles de paires index-clé vers les nœuds410 et 430.
Une « valeur de clé aléatoire » fait généralement référence à des valeurs imprévisibles dérivées en utilisant un produit d’une source de randomisation, tel qu’un générateur de nombres aléatoires. Dans des modes de réalisation, les valeurs de clé aléatoire peuvent être implémentées sous forme de: valeurs numériques, valeurs alphanumériques, et similaires. Une « valeur d’index » fait généralement référence à des données non sensibles identifiant une localisation d’une structure de donnée comprenant cette valeur d’index dans laquelle réside une valeur de clé aléatoire correspondante.
La FIG.5 est un diagramme bloc d’un nœud exemplaire 500 qui est approprié pour implémenter des aspects de l’invention décrits dans la présente. Dans un mode de réalisation, les nœuds410 et/ou 430 de la FIG.4 peuvent être implémentés en utilisant le nœud500. Le nœud500 inclut généralement un premier ensemble de ressources informatiques arrangées comme éléments non segmentés 502 et un deuxième ensemble de ressources informatiques arrangées comme éléments segmentés504. Le premier ensemble de ressources informatiques inclut un processeur (ou cœur d’exécution) 510 et une mémoire520. Le deuxième ensemble de ressources informatiques inclut un processeur560 et une mémoire570.
Le nœud500 est configuré pour implémenter une partition501 afin d’isoler physiquement et/ou logiquement le premier ensemble de ressources informatiques du deuxième ensemble de ressources informatiques. À titre d’exemple, l’isolation logique peut être implémentée en utilisant des techniques de virtualisation. Un exemple d’isolation physique inclut la provision d’un premier dispositif informatique (ou serveur) comprenant le premier ensemble de ressources informatiques et un deuxième dispositif informatique comprenant le deuxième ensemble de ressources informatiques avec une ou plusieurs barrières physiques intervenant entre le premier dispositif informatique et le deuxième dispositif informatique.
Les instructions stockées dans la mémoire520, lorsqu’elles sont exécutées par le processeur510, implémentent un nombre de services, de processus ou de routines. Ces services incluent: le service de tokenisation530, le service de détokenisation540 et optionnellement le service d’interception550. Le service de tokenisation530 est configuré pour générer des tokens pour des données sensibles reçues en provenance des éléments d’un environnement non fiable (p. ex. le dispositif client110 de la FIG.1) en utilisant des données de mappage522 générées par un service de randomisation (p. ex. le service de randomisation420 de la FIG.4) extérieur au nœud500, comme cela sera exposé de façon plus détaillée ci-dessous. Le service de détokenisation540 est configuré pour détokeniser chaque token reçu des autres éléments de l’environnement fiable (p. ex. l’environnement fiable402) comprenant le nœud500 via la partition501 en utilisant les données de mappage522, ainsi que décrit de façon plus détaillée ci-dessous. Le service d'interception optionnel 550 représente généralement toute unité de traitement de flux de données pour traiter des données en transit reçues des éléments d'un environnement non fiable et/ou pour traiter des données reçues d'autres éléments d'un environnement fiable via la partition 501. Dans un mode de réalisation, le service d'interception optionnel 550 est configuré pour détecter des données sensibles au sein des données en transit reçues en provenance d'éléments d'un environnement fiable et/ou des tokens au sein de données reçues en provenance d'autres éléments d'un environnement fiable via la partition 501. Dans un mode de réalisation, le service d'interception optionnel 550 peut être implémenté au niveau d'une couche de transport d'une pile réseau effectuée par le nœud 500. Dans un mode de réalisation, le service d'interception optionnel 550 peut être implémenté comme un renifleur de paquets.
Les instructions stockées dans la mémoire 570, lorsqu'elles sont exécutées par le processeur 560, implémentent un nombre de services, de processus ou de routines. Ces services incluent une application 580 configurée pour consommer des tokens générés par un service de tokenisation (p. ex. le service de tokenisation 530) en effectuant des transactions impliquant des données sensibles. Continuant avec l'exemple exposé ci-dessus par référence à la FIG. 1 qui implique un dispositif client soumettant des informations de carte de crédit relatives à une transaction à une plateforme de commerce électronique, l'application 580 peut représenter une application de paiement de la plateforme de commerce électronique. Dans cet exemple, l'application 580 peut recevoir un token généré pour les informations de carte de crédit dans le cadre de la transaction.
En utilisant le token, l'application 580 peut interagir avec le réseau de traitement de paiements (et/ou un système émetteur) pour demander l'autorisation de poursuivre avec la transaction. Une telle interaction peut inclure que l'application 580 transmette un message de demande d'autorisation comprenant le token au réseau de traitement de paiements. Dans un mode de réalisation, un service de détokenisation (p. ex. le service de détokenisation 540), peut détokeniser le token dans le message de demande d'autorisation et le remplacer avec les informations de la carte de crédit. Dans un mode de réalisation, les informations de la carte de crédit dans le message de demande d'autorisation sont remplacées par un nouveau token généré selon le processus de tokenisation établi par le réseau de traitement de paiements préalablement à la transmission.
La FIG. 6 est un organigramme illustrant un exemple d'un procédé 600 pour la provision de tokenisation décentralisée avec des données le mappage, dénuées de données sensibles, selon un mode de réalisation de l'invention. Dans un mode de réalisation, le procédé 600 est implémenté par les nœuds 410 ou 430 de la FIG. 4; ou le nœud 500 de la FIG. 5. À l'étape 601, un nœud reçoit un ensemble de paires index-clé générées par un service de randomisation extérieur au nœud. Chaque paire index-clé dans l'ensemble de paires index-clé définit une valeur d'index particulière mappée sur une valeur de clé aléatoire particulière. À l'étape 603, le nœud crée une structure de mappage en utilisant l'ensemble de paires index-clé. À titre d'exemple et en faisant référence à la FIG. 4, les données de mappage 422 sont créées avec un ensemble de paires index-clé comprenant une première paire index-clé qui inclut une valeur d'index « 112 » mappée sur la valeur de clé aléatoire « 976… 145 » et une deuxième paire index-clé qui inclut une valeur d'index « 123 » mappée sur la valeur de clé aléatoire « 871… 756 ». Dans un mode de réalisation, le nœud analyse l'ensemble de paires index-clé pour créer la structure de mappage.
À l'étape 605, les données en transit comprenant des données sensibles sont reçues. L'homme de métier appréciera que les données existent généralement dans trois états : données en utilisation, données au repos et données en transit. Les données en utilisation font généralement référence aux données qui sont en cours de traitement par un ou plusieurs services, processus ou routines (p. ex., l'application 580 de la FIG. 5) s'exécutant ou en cours d'exécution sur un processeur (p. ex. le processeur 560). Les données au repos font généralement référence à des données qui sont stockées sur un support de stockage lisible par ordinateur (p. ex., la mémoire 520 et/ou la mémoire 570) et qui ne sont pas traitées par un ou plusieurs services, processus ou routines s'exécutant ou en cours d'exécution sur un processeur. Des exemples de données au repos incluent des données résidentes ou stockées sur : un disque dur, un stockage attaché à un réseau, un dispositif de stockage basé sur la dématérialisation, et similaire. Les données en transit font généralement référence aux données qui sont propagées ou transférées sur un support de communication. Des exemples de données en transit incluent des données étant propagées sur : une voie de communication filaire ou sans fil d'un premier dispositif informatique vers le deuxième dispositif informatique, un bus de services au cours d'une opération entrée/sortie, et similaire. Dans un mode de réalisation, la réception des données en transit comprend une unité de traitement de flux de données du nœud pour le traitement des données en transit, la détection des données sensibles au sein des données en transit. Dans un mode de réalisation, l'unité de traitement de flux de données du nœud est implémentée comme un service d'interception. Dans un mode de réalisation, le nœud comprend des ressources de mémoire stockant des données au repos et dans lequel les données sensibles sont absentes des données au repos.
A l’étape 607, un service de tokenisation d'un nœud génère un token pour les données sensibles en utilisant la structure de mappage. Dans un mode de réalisation, la structure de mappage comprend une pluralité de valeurs d'index. Dans un mode de réalisation, la génération du token comprend la sélection aléatoire d'une valeur d'index parmi une pluralité de valeurs d'index. Dans un mode de réalisation, la génération du token comprend par ailleurs l'exécution d'une opération inversible sur les données sensibles et une valeur de clé aléatoire mappée sur la valeur d'index dans la structure de mappage pour générer le token. Dans un mode de réalisation, la génération du token comprend par ailleurs la concaténation ou l'ajout de la valeur d'index sélectionnée de façon aléatoire à un produit de l'opération inversible.
En continuant avec l'exemple exposé ci-dessus faisant référence à la FIG. 4, le service de tokenisation peut sélectionner de façon aléatoire la valeur d'index « 123 » des données de mappage 422. Dans ce cas, le service de tokenisation peut ensuite exécuter une opération inversible sur les données sensibles et sur la valeur de clé aléatoire « 871… 756 ». La valeur d'index « 123 » peut être concaténée à un produit de l'opération inversible pour générer le token.
En général, une opération inversible est définie en utilisant : soit
est un ensemble et soit est une fonction, ensuite :
Dans un mode de réalisation, une opération inversible est définie en utilisant : soit = {0,1}ℓpour certains est l'ensemble de toutes les chaînes binaires d'une longueur donnée et soit est une fonction, ensuite :
Et ensuite on peut définir un triplet (f, g, h) des opérations f, g et h de sorte que : f(a,b) = c; g(a,c) = b; h(b,c) = a; ;
où f, g et h sont des opérations inversibles. Une des particularités de cette définition d'un triplet est que si une opération parmi les opérations f, g ou h est un XOU, (XOR) alors les deux opérations restantes doivent être un XOU. Dans un mode de réalisation, l'opération inversible est une opération XOU binaire.
Dans un mode de réalisation, les opérations inversibles peuvent être utilisées sous trois conditions : (i) pour calculer un token à partir de données sensibles et une valeur de clé aléatoire particulière mappée sur une valeur d'index donnée dans une structure de mappage avec une fonction nommée «f » à titre d'exemple uniquement ; (ii) pour calculer une valeur de clé aléatoire particulière mappée sur une valeur d'index donnée dans une structure de mappage à partir d'un token et de données sensibles avec une fonction nommée «g » à titre d'exemple uniquement ; et (iii) pour calculer des données sensibles à partir d'un token et d'une valeur de clé aléatoire particulière mappée sur une valeur d'index donnée dans une structure de mappage avec une fonction nommée « h » à titre d'exemple uniquement. Selon un mode de réalisation, ces fonctions f, g, h utilisées sous ces trois conditions doivent être inversibles et respecter : f(a,b) = c; g(a,c) = b; h(b,c) = a; .
Par conséquent ces trois fonctions f, g et h doivent former un triplet ainsi que défini ci-dessus.
Dans un mode de réalisation, une fonction XOU peut être utilisée pour une de la fonction f, g ou h de sorte que conformément f=g=h=XOU constitue un triplet valide conformément à la définition ci-dessus. Dans un autre mode de réalisation, si une opération modulo 10 d'addition chiffrée est utilisée pour f, alors pour g et h l'opération modulo 10 de soustraction chiffrée doit être utilisée de sorte que les trois fonctions f, g, h constituent aussi un triplet valide ainsi que défini ci-dessus. Dans un autre mode de réalisation, si une opération modulo 10 d'addition chiffrée est utilisée pour g alors pour f et h l'opération modulo 10 de soustraction chiffrée doit être utilisée de sorte que les trois fonctions f, g, h constituent aussi un triplet valide ainsi que défini ci-dessus. Dans un autre mode de réalisation, si une opération modulo 10 d'addition chiffrée est utilisée pour h alors pour f et g l'opération modulo 10 de soustraction chiffrée doit être utilisée de sorte que les trois fonctions f, g, h constituent aussi un triplet valide ainsi que défini ci-dessus.
Dans un mode de réalisation, la génération du token comprend par ailleurs l'interrogation d'une structure de liste noire du nœud associée à la structure de mappage pour identifier un état de la valeur d'index. Dans un mode de réalisation, le procédé 600 comprend par ailleurs la synchronisation de la structure de liste noire du nœud avec une copie de la structure de liste noire résidant dans les ressources de mémoire d'un autre nœud extérieur au nœud. Dans un mode de réalisation, la synchronisation de la structure de liste noire est exécutée dans un mode de faible priorité et/ou d'une manière non bloquante. Dans ce mode de réalisation, une seule valeur d'index (et valeur de clé aléatoire associée) peut potentiellement être utilisée dans la génération de multiples tokens avant que la synchronisation ne survienne. Dans ce cas, chaque token serait considéré comme étant valide et fonctionnant correctement. Un risque potentiel de l'utilisation d'une seule valeur d'index et d'une valeur de clé aléatoire associée pour générer de multiples tokens est que les données sensibles associées à chaque token pourraient être compromises par un destinataire non désiré ayant connaissance de la structure de token et accès à chaque token.
Dans un mode de réalisation, le procédé 600 comprend par ailleurs la transmission du token à une interface d'application d'un processus d'exécution en utilisant un premier ensemble de ressources informatiques qui est isolé du deuxième ensemble de ressources informatiques que le nœud affecte au processus de tokenisation. Dans un mode de réalisation, l'interface d'application est une interface de programmation d'application (« API »), une bibliothèque, une API distante, une API Web ou une combinaison de celles-ci. Dans un mode de réalisation, le premier ensemble de ressources informatiques est affecté au processus par le nœud. Dans un mode de réalisation, le premier ensemble de ressources informatiques est affecté au processus par un autre nœud d'un système comprenant le nœud qui est extérieur au nœud. Dans un mode de réalisation, le processus est implémenté en utilisant l'application segmentée 580 de la FIG. 5. Dans un mode de réalisation, le service de tokenisation et le processus sont implémentés en utilisant le service de tokenisation 420 et les éléments segmentés 436 de la FIG. 4, respectivement.
Dans un mode de réalisation, le token est transmis à l'API sans stocker les données mappant les données sensibles sur le token. Dans un mode de réalisation, le procédé 600 comprend par ailleurs le cryptage du token préalablement à la transmission du token à l'API du processus. Dans un mode de réalisation, le token est transmis à l'API du processus sous forme de token crypté et le procédé 600 comprend par ailleurs le cryptage du token pour obtenir le token crypté. Dans un mode de réalisation, le nœud inclut des ressources segmentées comprenant le service de tokenisation et un HSM (p. ex. le HSM 140 de la FIG. 1), et le cryptage du token comprend une interaction du service de tokenisation avec le HSM.
Dans un mode de réalisation, le procédé 600 comprend par ailleurs la configuration d'un service de détokenisation pour détokeniser des tokens en utilisant une pluralité de structures de mappage associées à une pluralité d'époques, ainsi qu'exposé ci-dessous de façon plus détaillée par rapport à la FIG. 9. Dans un mode de réalisation, le service de détokenisation sélectionne une structure de mappage particulière dans la pluralité des structures de mappage pour détokeniser un token donné en utilisant un identifiant de version extrait du token donné. Dans un mode de réalisation, le service de détokenisation est effectué par des ressources informatiques du nœud. Dans un mode de réalisation, le service de détokenisation est effectué en utilisant les ressources informatiques d'un autre nœud au sein d'un système comprenant le nœud qui est extérieur au nœud.
Dans un mode de réalisation, le token est un premier token et le procédé 600 comprend par ailleurs la réception d'un deuxième token généré par un service de tokenisation distant utilisant la structure de mappage. Dans un mode de réalisation, le service de tokenisation distant s'exécute sur des ressources informatiques extérieures au nœud. Dans un mode de réalisation, le procédé 600 comprend par ailleurs le décryptage du deuxième token pour obtenir un deuxième token décrypté. Dans un mode de réalisation, le procédé 600 comprend par ailleurs l'extraction d'un identifiant de version associé à la structure de mappage à partir du deuxième token décrypté. Dans un mode de réalisation, le procédé 600 comprend par ailleurs la détokenisation du deuxième token décrypté en utilisant une valeur d'index extraite du deuxième token décrypté et une valeur aléatoire mappée sur la valeur d'index dans la structure de mappage.
Dans un mode de réalisation, le procédé 600 est exécuté par une logique de traitement incluant du matériel, des micrologiciels, des logiciels ou une combinaison de ceux-ci. Dans un mode de réalisation, le procédé 600 est exécuté par un processeur exécutant un code stocké sur un support non transitoire lisible par ordinateur (p. ex. une mémoire).
La FIG. 7 illustre une vue d'ensemble conceptuel de haut niveau d'un programme de cryptage déterministe. Dans la FIG. 7, un message de texte simple et une clé aléatoire sont fournis à un algorithme de cryptage pour produire un cryptogramme. Un destinataire désiré peut récupérer le message de texte simple en fournissant la clé aléatoire et le cryptogramme à un algorithme de décryptage. Le cryptogramme n'a aucune valeur pour un destinataire non désiré tant que la clé aléatoire, utilisée pour produire le cryptogramme, reste sécurisée. Cependant, si la clé aléatoire devait être compromise, chaque instance du cryptogramme produit par la suite avec la clé aléatoire deviendrait compromise. Spécifiquement, un destinataire non désiré pourrait fournir la clé aléatoire compromise et une instance donnée de cryptogramme à un algorithme de décryptage pour récupérer un message de texte simple correspondant.
Une sécurité supplémentaire pour les données sensibles peut être accomplie en implémentant une mesure de sécurité qui actualise périodiquement les structures de mappage utilisées pour générer des tokens ainsi qu'illustrée par la FIG 8. L'actualisation périodique des structures de mappage mitige un risque que les tokens soient compromis à partir d'ensembles de paires index-clé comprenant ce mappage devenu compromis. Dans la FIG. 8, une pluralité de périodes prédéfinies est représentée le long d'une chronologie par les indicateurs 812, 822 et 832. Ces pluralités de périodes prédéfinies partitionnent la chronologie en une pluralité de périodes (ou époques) représentées par les indicateurs 810, 820 et 830.
Chaque époque parmi la pluralité des époques à une durée définie par son horaire de départ associé et un horaire de départ d'une époque suivant immédiatement cette époque. Par exemple, la première époque 810 a une durée définie par l'horaire de départ 812 et l'horaire de départ 822 de la deuxième époque 820. Comme autre exemple, la deuxième époque 820 a une durée définie par l'horaire de départ 822 et l'horaire de départ 832 de la troisième époque 830. Dans un mode de réalisation, la première époque 810, la deuxième époque 820 et une troisième époque 830 ont des durées équivalentes. Dans un mode de réalisation, la durée de la première époque 810 est différente des durées respectives de la deuxième époque 820 et de la troisième époque 830.
Pendant toute la durée d'une époque donnée, cette époque est identifiée comme étant une « époque actuelle ». Lorsque la durée de l'époque donnée prend fin à l'horaire de départ de l'époque suivant immédiatement l'époque donnée, une nouvelle époque (c.-à-d., l'époque suivant immédiatement l'époque donnée) est identifiée comme étant l'époque actuelle. Par exemple, un premier déclenchement peut être initié lorsqu’un processus d'arrière-plan d'un nœud (p. ex., les nœuds 410, 430 ou 500) détermine qu'un horaire de système actuel correspond à l'horaire de départ 812 de la première époque 810. À l'horaire de départ 812, la première époque 810 est identifiée comme étant une époque actuelle. En réponse au premier déclenchement, le nœud configure un service de tokenisation (p. ex., le service de tokenisation 414 de la FIG. 4 et/ou le service de tokenisation 530 de la FIG. 5) pour tokeniser des données sensibles en utilisant une première structure de mappage 815. Ainsi que noté ci-dessus, l'utilisation de sources d'horaires de système pour actualiser périodiquement les structures de mappage facilite la nature éphémère de chaque ensemble de paires index-clé comprenant ces structures de mappage. Dans ce but, chaque ensemble de paires index-clé comprenant la première structure de mappage 815 a une vie utilisable définie par la première époque 810. Dans un sens, la première époque 810 définit cette vie utilisable à travers le nœud configurant le service de tokenisation pour tokeniser des données sensibles en utilisant la première structure de mappage 815 pour une durée 817 de la première époque 810.
Un deuxième déclenchement peut être initié lorsque le processus d'arrière-plan détermine que l'horaire de système actuel correspond à l'horaire de départ 822 de la deuxième époque 820 et la deuxième époque 820 est identifiée comme étant l'époque actuelle. En réponse au deuxième déclenchement, le nœud configure le service de tokenisation afin de tokeniser les données sensibles pour une durée de la deuxième époque 820 en utilisant la deuxième structure de mappage 825. Lors de la configuration du service de tokenisation pour tokeniser des données sensibles en utilisant la deuxième structure de mappage 825, le service de tokenisation ne tokenise plus les données sensibles en utilisant la première structure de mappage 815. Cependant, la première structure de mappage 815 reste utilisable par d'autres services durant la deuxième époque 820. Par exemple, un service de détokenisation du nœud (ou d'un autre nœud d'un système comprenant le nœud) peut être configuré pour détokeniser en utilisant la première structure de mappage 815 pour une durée 819.
Ainsi que l'illustre la FIG. 8, chaque structure de mappage inclut un ensemble différent de paires index-clé. Par exemple, la première structure de mappage 815, la valeur d'index « 112 » est mappée sur une valeur de clé aléatoire « 976… 154 ». Cependant, dans une deuxième structure de mappage 825, la valeur d'index « 112 » est mappée sur une valeur de clé aléatoire « 435… 843 ». Ceci illustre un autre aspect de la présente divulgation dans laquelle les structures de mappage sont versionnées. Dans l'exemple de la FIG. 8, ce versionnage des structures de mappage est représenté par les lettres minuscules associées à chaque horaire de départ d'une époque. Par exemple, la première époque 810 est associée à la version « a », la deuxième époque 820 est associée à la version « b » et la troisième époque 830 est associée à la version « c ». Dans un mode de réalisation, chaque token généré une structure de mappage comprenant des paires index-clé inclut un identifiant de version indicatif d'une version associée à une époque pendant laquelle ce token a été généré.
L'homme de métier reconnaîtra que les identifiants de version peuvent prendre d'autres formes et être incorporés dans des tokens éphémères d'autres manières. Par exemple, les identifiants de version peuvent être implémentés sous forme d'une ou de plusieurs valeurs comprenant : des valeurs numériques, des valeurs alphabétiques, des valeurs alphanumériques, et similaires. Comme autre exemple, les identifiants de version peuvent être incorporés dans des tokens en ajoutant les identifiants de version sous forme d'un suffixe à chaque token ou en insérant des identifiants de version au sein d'une séquence de valeurs formant chaque token. Comme autre exemple, les identifiants de versions peuvent être incorporés dans des tokens en ajoutant les identifiants de versions sous forme d'un préfixe à chaque token.
Dans un mode de réalisation, une forme d'identifiant de version utilisée dans une époque peut être différente d'une forme d'identifiant de version utilisée dans une autre époque. Dans un mode de réalisation, les identifiants de version peuvent être incorporés dans des tokens d'une première manière alors que les identifiants de version peuvent être incorporés dans des tokens d'une deuxième manière qui est différente de la première manière pour une autre époque. Dans ce mode de réalisation, il reste possible d'identifier un identifiant de version respectif de chaque token reçu quelle que soit la manière par laquelle cet identifiant de version a été incorporé dans ce token.
Ce versionnage de structure de mappage représente un moyen par lequel une époque définit une vie utilisable de chaque ensemble de paires index-clé comprenant une structure de mappage donnée. Par exemple, un troisième déclenchement peut être initié lorsque le processus d'arrière-plan détermine que l'horaire de système actuel correspond à l'horaire de départ 832 de la troisième époque 830 et que la troisième époque 830 est identifiée comme étant l'époque actuelle. En réponse au troisième déclenchement, le nœud configure le service de tokenisation afin de tokeniser les données sensibles pour une durée de la troisième époque 830 en utilisant la troisième structure de mappage 835.
Lors de la configuration du service de tokenisation, pour tokeniser des données sensibles en utilisant la troisième structure de mappage 835, le service de tokenisation ne tokenise plus les données sensibles en utilisant la deuxième structure de mappage 825. Cependant, un service de détokenisation (p. ex. le service de détokenisation 434 de la FIG. 4 et/ou le service de détokenisation 540 de la FIG. 5) peut être configuré pour détokeniser des tokens en utilisant la deuxième structure de mappage 825 pour la durée de la troisième époque 830. Ainsi qu'illustré dans la FIG. 8, le service de détokenisation peut aussi être configuré pour détokeniser des tokens en utilisant la troisième structure de mappage 835 pour la durée de la troisième époque 830. Un aspect du service de détokenisation, la détokenisation des tokens en utilisant la deuxième structure de mappage 825 et/ou la troisième structure de mappage 835 pour la durée de la troisième époque 830, est que les tokens générés au cours de la deuxième époque 820 et/ou de la troisième époque 830 peuvent être reçus par le service de détokenisation au cours de la troisième époque 830. Dans un mode de réalisation, le service de détokenisation est configuré pour identifier une époque particulière pendant laquelle un token donné est généré en utilisant un identifiant de version du token donné. Dans un mode de réalisation, le token donné est crypté et le service de détokenisation est configuré pour interagir avec un HSM (p. ex., le HSM 140 de la FIG. 1) afin de décrypter le token donné pour obtenir un token décrypté.
Un autre aspect de la présente divulgation illustré par la FIG. 8. est que les versions de structures de mappage peuvent être réutilisées cycliquement dans le temps. Par exemple, préalablement à l'horaire de départ 832, le service de détokenisation peut être configuré pour traiter les demandes de détokenisation en utilisant la première structure de mappage 815. Après l'horaire de départ 832, le service de détokenisation peut être configuré pour ne plus traiter la détokenisation de tokens en utilisant la première structure de mappage 815. Pourtant, plus tard, une nouvelle structure de mappage associée à la version « a » peut être créée en utilisant un nouvel ensemble de paires index-clé générées par le service de randomisation pour un usage durant une époque ultérieure.
Les FIGS. 9 et 10 illustrent un exemple de réutilisation cyclique de versions de structures de mappage dans le temps. Faisant référence à la FIG. 9, une époque identifiée comme étant une époque actuelle une première fois est associée à une version « w ». Dans la FIG. 9, un service de détokenisation est configuré pour tokeniser des données sensibles incluses dans des données en transit reçues en utilisant une structure de mappage associée à la version « w » représentée par l'indicateur 910. La première fois, un processus de détokenisation est configuré pour détokeniser des tokens en utilisant des structures de mappage associées aux versions « t » - « w », ainsi que représenté par l'indicateur 920.
Faisant référence à la FIG. 10, une nouvelle époque est identifiée comme étant l'époque actuelle la deuxième fois subséquemment à la première fois. Cette nouvelle époque est associée à la version « x ». Dans la FIG. 10, le service de tokenisation est configuré pour tokeniser des données sensibles en utilisant une structure de mappage associée à la version «x » représentée par l'indicateur 1010. La deuxième fois, le processus de détokenisation est configuré pour détokeniser des tokens en utilisant des structures de mappage associées aux versions « u » - « x », ainsi que représenté par l'indicateur 1020. Ainsi qu'illustré par la FIG. 10, ni le service de tokenisation ni le service de détokenisation ne sont configurés pour traiter les données sensibles des tokens en utilisant une structure de mappage associée à la version « t ». Ceci illustre le fait que la version de structure de mappage « t » a été relâchée la deuxième fois pour une utilisation ultérieure.
La FIG. 11 illustre un exemple de données sensibles 1100 et un token associé 1150 ayant un nombre équivalent d'octets tout en ayant un nombre de bits différents. Dans l'exemple de la FIG. 11, les données sensibles 1100 sont encodées sous forme d'une chaîne de 16 chiffres numériques (ou octets) qui a été formatée en un premier morceau 1102, un deuxième morceau 1104 et un troisième morceau 1106. Lors de la tokenisation en utilisant une structure de mappage (p. ex., les données de mappage 422 et/ou 522) comprenant un ensemble de valeurs index-clé, les données sensibles 1100 sont transformées en token associé 1150. Comme on peut le voir dans la FIG. 11, les données sensibles 1100 et le token 1150 comprennent chacun 16 octets. Cependant, alors que le deuxième morceau 1104 des données sensibles 1100 est encodé en utilisant des valeurs numériques, le deuxième morceau 1154 du token 1150 est encodé en utilisant des valeurs alphanumériques sensibles à la casse. L'homme de métier reconnaîtra que les 6 caractères numériques du deuxième morceau 1140 représentent 10^6 permutations possibles qui peuvent être représentées en utilisant approximativement 24 bits et les 6 caractères alphanumériques sensibles à la casse du deuxième morceau 1154 représentent 62^6 permutations possibles qui peuvent être représentées en utilisant approximativement 34 bits. Ainsi, en encodant le deuxième morceau 1154 en caractères alphanumériques sensibles à la casse plutôt qu'en caractères numériques, le deuxième morceau 1154 comprend 10 bits de plus que le deuxième morceau 1104 pour encoder l'information.
Après avoir décrit divers modes de réalisation de l’invention, un environnement informatique exemplaire adapté à l’implémentation des modes de réalisation de l’invention va maintenant être décrit. Faisant référence à la FIG. 12, le dispositif client 110 ; le dispositif informatique 120 ; les serveurs de tokens 130 et 320 ; le HSM 140 ; le système interne 160 et les noeuds 310, 330, 410, 430 et 500 peuvent être implémentés sur un ou plusieurs dispositifs informatiques ou systèmes tels que le système informatique exemplaire 1200. Le système informatique 1200 peut comprendre un processeur 1226, une mémoire 1228, un dispositif de mémoire de masse 1230, une interface entrée/sortie (I/O) 1232, et une interface homme-machine (HMI) 1234. Le système informatique 1200 peut aussi être couplé de façon fonctionnelle à une ou plusieurs ressources externes 1236 via le réseau 1223 ou l’interface I/O 1232. Les ressources externes peuvent inclure, mais de façon non exhaustive, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau basés sur la dématérialisation, ou toute autre ressource informatique adaptée qui peut être utilisée avec l'ordinateur 1200.
Le processeur 1226 peut inclure un ou plusieurs dispositifs sélectionnés: microprocesseurs, microcontrôleurs, processeurs de signaux numériques, micro-ordinateurs, unités centrales de traitement, réseaux de portes programmables, dispositifs logiques programmables, machines à état défini, circuits logiques, circuits analogiques, circuits numériques, ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) basés sur des instructions de fonctionnement enregistrées dans la mémoire 1228. La mémoire1228 peut inclure un seul dispositif de mémoire ou une pluralité de dispositifs de mémoire comprenant, de façon non exhaustive, la mémoire à lecture seule (ROM), la mémoire à accès aléatoire (RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, la mémoire cache, ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de stockage de masse 1230 peut inclure des dispositifs de stockage de données tels que disque dur, un disque optique, un dispositif à état solide non transitoire ou tout autre dispositif capable de stocker des informations.
Le processeur1226 peut fonctionner sous le contrôle d'un système d'exploitation1238 qui réside dans la mémoire1228. Le système d'exploitation 1238 peut gérer les ressources de l'ordinateur de telle façon que le code de programme de l'ordinateur, intégré sous forme d'un ou plusieurs logiciels d'application, telle que l'application 1240 qui réside dans la mémoire 1228, puisse disposer d'instructions exécutées par le processeur 1226. Dans un autre mode de réalisation, le processeur 1226 peut exécuter directement l'application 1240, dans ce cas le système d'exploitation 1238 peut-être omis. Une ou plusieurs structures de données1242 peuvent aussi résider dans la mémoire1228 et peuvent être utilisées par le processeur1226, le système d'exploitation1238 ou l'application1240 pour stocker ou manipuler des données.
L'interfaceI/O 1232 peut fournir une interface machine qui couple de façon fonctionnelle le processeur1226 à d'autres dispositifs et systèmes, tels que le réseau1223 ou une ou plusieurs ressources externes1236. L'application1240 peut ainsi collaborer avec le réseau1223 ou les ressources externes1236 en communiquant via l'interface I/O1232 pour fournir les divers éléments, fonctions, applications, processus, ou modules composant les modes de réalisation de l'invention. Le serveur d'application1240 peut aussi avoir un code de programme qui est exécuté par une ou plusieurs ressources externes1236 ou sinon repose sur les fonctions ou signaux fournis par d'autres systèmes ou composants de réseau externes à l'ordinateur1200. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent inclure des applications localisées à l'extérieur de l'ordinateur1200, distribuées à des ordinateurs multiples et à d'autres ressources externes1236, ou apportées par des ressources informatiques (matérielles et logicielles) qui sont fournies comme services sur le réseau1223, par exemple un service tel qu'un service informatique dématérialisé.
Le HMI 1234 peut être couplé de façon opérationnelle au processeur 1226 du système informatique 1200 d’une façon connue pour permettre à un utilisateur d’interagir directement avec le système informatique 1200. Le HMI 1234 peut inclure des affichages vidéo ou alphanumériques, un écran tactile, un haut-parleur et tout autre indicateur audio et visuel adapté, capables de fournir des données à l’utilisateur. Le HMI 1234 peut aussi inclure des dispositifs de saisie et des contrôles tels qu’un clavier alphanumérique, un dispositif de pointage, des boutons poussoirs, des boutons de contrôle, des microphones, etc., capables d’accepter des commandes ou des saisies de l’utilisateur et de transmettre la saisie entrée au processeur 1226.
Une base de données 1244 peut résider sur le dispositif de stockage de mémoire de masse 1230 et peut être utilisée pour collecter et organiser des données utilisées par les divers systèmes et modules décrits dans la présente. La base de données1244 peut inclure des données ainsi que les structures de donnée qui les accommodent pour stocker et organiser les données. En particulier, la base de données1244 peut-être arrangée selon toute organisation ou structure de base de données incluant, mais de façon non exhaustive, une base de données relationnelle, une base de données hiérarchique, une base de données en réseau, ou des combinaisons de celles-ci. Dans un mode de réalisation, une base de données 1244, peut être implémentée en utilisant une ou plusieurs de : la base de données 150, la base de données 324, la base de données 418, la base de données 424, la base de données 438, la base de données 520 et la base de données 570. Un système de gestion de base de données sous forme de logiciel d'application qui s'exécute sous la forme d'instructions sur le processeur 1226 peut être utilisé pour accéder à l'information ou aux données stockées dans des fichiers de la base de données 1244 en réponse à une interrogation, lorsqu'une interrogation peut être déterminée de façon dynamique et exécutée par le système d'exploitation 1238, les autres applications 1240, ou un ou plusieurs modules.
En général les routines exécutées pour mettre en œuvre les modes de réalisation de l'invention, qu'elles soient implémentées dans le cadre d'un système d'exploitation ou d'une application spécifique, d'un composant, d'un programme, d'un objet, d'un module ou d'une séquence d'instructions, ou même un sous-ensemble de ceux-ci, peuvent être désignées dans la présente comme «code de programme informatique» ou simplement «code de programme». Le code de programme comprend typiquement des instructions lisibles par ordinateur qui résident à divers moments dans divers dispositifs de mémoire et de stockage dans un ordinateur, et qui lorsqu'elles sont lues et exécutées par un ou plusieurs processeurs dans un ordinateur, amènent cet ordinateur à mettre en œuvre les opérations et/ou les éléments propres aux divers aspects des modes de réalisation de l'invention. Les instructions d'un programme informatique lisibles par ordinateur pour accomplir les opérations des modes de réalisation de l'invention peuvent être, par exemple, le langage d'assemblage ou, un code source ou un code objet, écrit en combinaison avec un ou plusieurs langages de programmation.
Le code de programme mis en œuvre dans toute application/module décrit(e) dans la présente peut être distribué individuellement ou collectivement comme un produit-programme d'ordinateur, sous une variété de formes. En particulier, le code de programme peut être distribué en utilisant un support de stockage lisible par ordinateur ayant des instructions de programme lisibles par ordinateur pour amener un processeur à mettre en œuvre des aspects des modes de réalisation de l'invention.
Les supports de stockage de données lisibles par ordinateur étant intrinsèquement non transitoires, peuvent inclure des médias tangibles, volatiles et non volatiles, amovibles et non amovibles, implémentés dans tout procédé ou technologie de stockage de données, tels que des instructions de programme lisibles par ordinateur, des structures de donnée, des modules de programme, ou autres données. Les supports de stockage lisibles par ordinateur peuvent aussi comprendre une mémoire à accès aléatoire (RAM), une mémoire à lecture seule (ROM), une mémoire à lecture seule programmable et effaçable (EPROM), une mémoire à lecture seule programmable et effaçable électriquement (EEPROM), une mémoire flash, ou autre technologie de support solide de mémoire, un disque compact portable doté d'une mémoire à lecture seule (CD-ROM), ou autre stockage optique, des cassettes magnétiques, une bande d'enregistrement magnétique, un stockage de disque magnétique ou autres dispositifs magnétiques de stockage ou tout autre support pouvant être utilisé pour stocker l'information désirée et apte à être lu par un ordinateur. Le support de stockage lisible par ordinateur ne doit pas être interprété en soi comme des signaux transitoires (des ondes radio ou d’autres ondes électromagnétiques propagées via des supports de transmission tels qu’un guide d’ondes, ou des signaux électriques transmis par un fil). Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d'appareil de traitement de données programmable ou sur tout autre dispositif de support de stockage lisible par machine, ou vers un ordinateur externe ou vers un dispositif de stockage externe via un réseau.
Les instructions de programme lisibles par ordinateur, stockées sur un support lisible par ordinateur, peuvent être utilisées pour instruire un ordinateur, d'autres types d'appareils programmables de traitement ou d'autres dispositifs pour fonctionner d'une façon particulière, de sorte que les instructions stockées sur un support lisible par ordinateur produisent un article de fabrication comprenant les instructions qui implémentent les fonctions/actions spécifiées dans les organigrammes, diagrammes de séquence, et/ou diagrammes blocs. Les instructions de programme informatique peuvent être fournies à un ou plusieurs processeurs d'un ordinateur à usage général, un ordinateur dédié ou un autre appareil programmable de traitement de données pour produire une machine, de sorte que les instructions, lorsqu'elles sont exécutées via ledit un ou plusieurs processeurs, accomplissent une série de calculs pour mettre en œuvre les fonctions, actions, et/ou les actions spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs.
Dans certains autres modes de réalisation, les fonctions et/ou les actions spécifiées dans les organigrammes, diagrammes séquentiels, et/ou des diagrammes blocs peuvent être réordonnées, traitées en série et/ou traitées en même temps sans s’éloigner du champ d’application des modes de réalisation de l’invention. De plus, un quelconque des organigrammes, diagrammes séquentiels, et/ou diagrammes bloc peut inclure plus ou moins de blocs que ceux qui sont illustrés, conformément à des modes de réalisation de l'invention.
La terminologie utilisée dans la présente a pour but de décrire uniquement des modes de réalisation particuliers et n'est pas destinée à limiter les modes de réalisation de l'invention. Ainsi qu'utilisé dans la présente, le singulier « un », « une », « le » et « la » est censé inclure également les formes plurielles, sauf s'il en est indiqué autrement et clairement par le contexte. On comprendra par ailleurs que les termes «comprend», et/ou «comprenant» lorsqu'ils sont utilisés dans cette spécification, précisent la présence de caractéristiques énoncées, de nombres entiers, d'étapes, d'opérations, d'éléments, et/ou de composants, mais n'excluent pas la présence ou l'ajout d'une ou de plusieurs caractéristiques, nombres entiers, étapes, éléments, composants et/ou groupes en cela. Par ailleurs, dans la mesure où les termes «inclut», «ayant», «a», «avec» « compris de » ou leurs variantes, sont utilisées dans la description détaillée des revendications, ces termes sont censés être inclusifs de façon similaire au verbe «comprendre».
Bien que l'invention soit illustrée par une description de divers modes de réalisation et bien que ces modes de réalisation soient décrits de façon très détaillée, le demandeur n'a pas l'intention de restreindre ou de limiter, de quelque façon que ce soit, le champ d'application des revendications de la présente à ces détails. Des avantages supplémentaires et des modifications possibles apparaîtront aisément aux hommes de métier. L'invention sous un angle plus large n'est donc pas limitée aux détails spécifiques, aux procédés et appareils représentatifs, et aux illustrations montrées et décrites à titre d'exemple. Par conséquent, il est possible de s'éloigner de ces détails sans s'éloigner de l'esprit et de la portée du concept inventif général du demandeur.

Claims (22)

  1. Un système pour une tokenisation aléatoire efficace dans l'environnement dématérialisé, le système comprenant :
    un nœud comprenant un processeur, un support de stockage lisible par ordinateur et un service de tokenisation, le support de stockage lisible par ordinateur comprenant des instructions qui, lors de l'exécution par le processeur, amènent le système à effectuer des opérations, les opérations comprenant :
    la réception, par le nœud, d'un ensemble de paires index-clé générées par un service de randomisation extérieur au nœud, chaque paire index-clé définissant une valeur d'index particulière mappée sur une valeur de clé aléatoire particulière ;
    la création, par le nœud d'une structure de mappage en utilisant l'ensemble de paires index-clé ;
    la réception de données en transit comprenant des données sensibles ; et
    la génération, par le service de tokenisation, d'un token pour les données sensibles en utilisant la structure de mappage.
  2. Le système de la revendication 1, dans lequel la structure de mappage inclut une pluralité de valeurs d'index et dans lequel la génération du token comprend :
    la sélection aléatoire d'une valeur d'index parmi la pluralité des valeurs d'index ; et
    l'exécution d'une opération inversible sur les données sensibles et une valeur de clé aléatoire mappée sur la valeur d'index dans la structure de mappage pour générer le token.
  3. Le système de la revendication 1, dans lequel le nœud est un premier nœud, dans lequel le système comprend par ailleurs le service de randomisation et un deuxième nœud et dans lequel le service de randomisation est configuré pour pousser périodiquement des ensembles actualisés de paires index-clé vers le premier nœud et le deuxième nœud.
  4. Le système de la revendication 1, dans lequel les instructions, lorsqu'elles sont exécutées, amènent par ailleurs le système à effectuer des opérations supplémentaires, les opérations supplémentaires comprenant :
    la transmission du token à une interface d'application d'un processus s'exécutant à l’aide un premier ensemble de ressources informatiques qui est isolé du deuxième ensemble de ressources informatiques que le nœud affecte au service de tokenisation.
  5. Le système de la revendication 4, dans lequel le nœud est un premier nœud, dans lequel le système comprend par ailleurs un deuxième nœud et dans lequel le premier ensemble de ressources informatiques est affecté au processus par le deuxième nœud.
  6. Le système de la revendication 4, dans lequel le premier ensemble de ressources informatiques est affecté au processus par le nœud.
  7. Le système de la revendication 4, dans lequel le token est transmis à l'interface d'application sans stocker les données mappant les données sensibles sur le token.
  8. Le système de la revendication 4, dans lequel les instructions, lorsqu'elles sont exécutées, amènent par ailleurs le système à effectuer des opérations supplémentaires, les opérations supplémentaires comprenant :
    le cryptage du token avant la transmission du token à l'interface d'application du processus.
  9. Le système de la revendication 1, dans lequel le token et les données sensibles sont chacun composés d'un nombre d'octets équivalent, et dans lequel le token comprend un premier nombre de bits et les données sensibles comprennent un deuxième nombre de bits qui est différent du premier nombre de bits.
  10. Le système de la revendication 1, dans lequel le service de randomisation est empêché d'accéder aux données de transaction.
  11. Le système de la revendication 1, dans lequel la réception des données en transit comprend :
    la détection, par une unité de traitement de flux de données du nœud traitant les données en transit, des données sensibles au sein des données en transit.
  12. Un procédé pour une tokenisation aléatoire efficace dans l'environnement dématérialisé, le procédé comprenant :
    la réception, par un nœud, d'un ensemble de paires index-clé générées par un service de randomisation extérieur au nœud, chaque paire index-clé définissant une valeur d'index particulière mappée sur une valeur de clé aléatoire particulière ;
    la création, par le nœud d'une structure de mappage en utilisant l'ensemble de paires index-clé.
    La réception de données en transit comprenant des données sensibles ; et
    la génération, par un service de tokenisation du nœud, d’un token pour les données sensibles en utilisant la structure de mappage.
  13. Le procédé de la revendication 12, dans lequel la structure de mappage inclut une pluralité de valeurs d'index et dans lequel la génération du token comprend :
    la sélection aléatoire d'une valeur d'index parmi la pluralité des valeurs d'index ; et
    l'interrogation d'une structure de liste noire du nœud associée à la structure de mappage pour identifier un état de la valeur d'index.
  14. Le procédé de la revendication13, comprenant par ailleurs:
    la synchronisation de la structure de liste noire du nœud avec une copie de la structure de liste noire résidant dans les ressources de mémoire d'un autre nœud extérieur au nœud.
  15. Le procédé de la revendication13, comprenant par ailleurs:
    le cryptage du token pour obtenir un token crypté ; et
    la transmission du token crypté à une interface d'application d'un processus d'exécution en utilisant un premier ensemble de ressources informatiques qui est isolé du deuxième ensemble de ressources informatiques que le nœud affecte au service de tokenisation.
  16. Le procédé de la revendication12, comprenant par ailleurs:
    la configuration d'un service de détokenisation pour détokeniser les tokens en utilisant une pluralité de structures de mappage associées à une pluralité d'époques, dans lequel la structure de mappage est une de la pluralité des structures de mappage résidant dans les ressources de mémoire accessibles au service de détokenisation et dans lequel au moins une époque parmi la pluralité des époques précède une époque correspondante de la structure de mappage.
  17. Le procédé de la revendication 16, dans lequel une structure de mappage donnée de la pluralité des structures de mappage associées à ladite au moins une époque est utilisée uniquement pour les opérations de détokenisation, non pour les opérations de tokenisation.
  18. Le procédé de la revendication 16, dans lequel le service de détokenisation sélectionne une structure de mappage particulière de la pluralité des structures de mappage pour détokeniser un token donné en utilisant un identifiant de version extrait pour le token donné.
  19. Le procédé de la revendication12, comprenant par ailleurs:
    la détokenisation, par un service de détokenisation, du token en utilisant la structure de mappage et une valeur d'index extraite du token.
  20. Le procédé de la revendication 12, dans lequel le token est un premier token, le procédé comprenant par ailleurs :
    la réception d'un deuxième token généré par un service de tokenisation distant en utilisant la structure de mappage, le service de tokenisation distant s'exécutant sur des ressources informatiques extérieures au nœud;
    le décryptage du deuxième token pour obtenir un deuxième token décrypté ;
    l'extraction d'un identifiant de version associé à la structure de mappage à partir du deuxième token décrypté ; et
    la détokenisation du deuxième token décrypté en utilisant une valeur d'index extraite du deuxième token décrypté et une valeur aléatoire mappée sur la valeur d'index dans la structure de mappage.
  21. Le procédé de la revendication 12, dans lequel le nœud comprend des ressources de mémoire stockant des données au repos et dans lequel les données sensibles sont absentes des données au repos.
  22. Un support de stockage non transitoire, lisible par ordinateur comprenant des instructions lisibles par ordinateur qui lors de l’exécution par processeur d'un dispositif informatique amènent le dispositif informatique à :
    recevoir, par un nœud, un ensemble de paires index-clé générées par un service de randomisation extérieur au nœud, chaque paire index-clé définissant une valeur d'index particulière mappée sur une valeur de clé aléatoire particulière ;
    créer, par le nœud une structure de mappage en utilisant l'ensemble de paires index-clé;
    recevoir des données en transit comprenant des données sensibles; et
    générer, par le service de tokenisation du nœud un token pour les données sensibles en utilisant la structure de mappage.
FR2001463A 2020-02-14 2020-02-14 Tokenisation aléatoire efficace dans un environnement dématérialisé Active FR3107416B1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR2001463A FR3107416B1 (fr) 2020-02-14 2020-02-14 Tokenisation aléatoire efficace dans un environnement dématérialisé
US17/098,846 US11921877B2 (en) 2020-02-14 2020-11-16 Efficient random tokenization in the cloud
EP20208945.4A EP3866431A1 (fr) 2020-02-14 2020-11-20 Tokénisation aléatoire efficace dans le nuage
CN202011378964.1A CN113271203A (zh) 2020-02-14 2020-11-30 云中高效的随机令牌化

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2001463A FR3107416B1 (fr) 2020-02-14 2020-02-14 Tokenisation aléatoire efficace dans un environnement dématérialisé
FR2001463 2020-02-14

Publications (2)

Publication Number Publication Date
FR3107416A1 true FR3107416A1 (fr) 2021-08-20
FR3107416B1 FR3107416B1 (fr) 2022-02-04

Family

ID=70918569

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2001463A Active FR3107416B1 (fr) 2020-02-14 2020-02-14 Tokenisation aléatoire efficace dans un environnement dématérialisé

Country Status (4)

Country Link
US (1) US11921877B2 (fr)
EP (1) EP3866431A1 (fr)
CN (1) CN113271203A (fr)
FR (1) FR3107416B1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11809493B2 (en) * 2021-01-19 2023-11-07 Micro Focus Llc System and method for tokenization of data

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050226420A1 (en) * 2002-05-17 2005-10-13 Jakke Makela Method and system in a digital wireless data communication network for arranging data encryption and corresponding server
US20190068558A1 (en) * 2017-08-31 2019-02-28 Fmr Llc Systems and Methods for Data Encryption and Decryption
US20190342088A1 (en) * 2018-05-03 2019-11-07 Salesforce.Com, Inc. Method and apparatus for linked encryption tokenization of user traceable data

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2775237C (fr) * 2011-04-27 2015-07-07 Perspecsys Inc. Systeme et methode de decoupage de donnees conservant l'ordre de tri

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050226420A1 (en) * 2002-05-17 2005-10-13 Jakke Makela Method and system in a digital wireless data communication network for arranging data encryption and corresponding server
US20190068558A1 (en) * 2017-08-31 2019-02-28 Fmr Llc Systems and Methods for Data Encryption and Decryption
US20190342088A1 (en) * 2018-05-03 2019-11-07 Salesforce.Com, Inc. Method and apparatus for linked encryption tokenization of user traceable data

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ARIJIT UKIL: "Privacy Preserving Data Aggregation in Wireless Sensor Networks", WIRELESS AND MOBILE COMMUNICATIONS (ICWMC), 2010 6TH INTERNATIONAL CONFERENCE ON, IEEE, PISCATAWAY, NJ, USA, 20 September 2010 (2010-09-20), pages 435 - 440, XP031795644, ISBN: 978-1-4244-8021-0 *

Also Published As

Publication number Publication date
US20210256150A1 (en) 2021-08-19
CN113271203A (zh) 2021-08-17
US11921877B2 (en) 2024-03-05
EP3866431A1 (fr) 2021-08-18
FR3107416B1 (fr) 2022-02-04

Similar Documents

Publication Publication Date Title
CA3061427C (fr) Traitement de donnees de chaine de blocs sur la base d'operations sur contrats intelligents executees dans un environnement d'execution de confiance
US10903976B2 (en) End-to-end secure operations using a query matrix
US20180212753A1 (en) End-To-End Secure Operations Using a Query Vector
US10432397B2 (en) Master password reset in a zero-knowledge architecture
CN110689349B (zh) 一种区块链中的交易哈希值存储和搜索方法及装置
US10608813B1 (en) Layered encryption for long-lived data
US10476663B1 (en) Layered encryption of short-lived data
CN107040520B (zh) 一种云计算数据共享系统及方法
US11075753B2 (en) System and method for cryptographic key fragments management
US20140344944A1 (en) Dynamic database update in multi-server private information retrieval scheme
WO2022068360A1 (fr) Procédé et appareil de traitement d'informations basés sur une clé racine partagée, dispositif, et support
JP7319380B2 (ja) ブラウザクッキーを保護する
CA3057398A1 (fr) Execution securisee d'operations cryptographiques
JP2020524864A (ja) データへのアクセスの制御
US20230155815A1 (en) Secure integer comparison using binary trees
US10476661B2 (en) Polynomial-based homomorphic encryption
US10540522B2 (en) Storing data securely in a database
US11356254B1 (en) Encryption using indexed data from large data pads
FR3107416A1 (fr) Tokenisation aléatoire efficace dans un environnement dématérialisé
US8769290B1 (en) Providing confidential structured data
FR3103922A3 (fr) Stockage de tokens sécurisé
CN115118434A (zh) 基于区块链的密钥管理方法及装置
US10043015B2 (en) Method and apparatus for applying a customer owned encryption
FR3040519A1 (fr) Methode de securisation et de verifiabilite d’un vote electronique
CA3093385A1 (fr) Traitement securise de donnees

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20210820

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5