FR3103922A3 - Stockage de tokens sécurisé - Google Patents
Stockage de tokens sécurisé Download PDFInfo
- Publication number
- FR3103922A3 FR3103922A3 FR1913402A FR1913402A FR3103922A3 FR 3103922 A3 FR3103922 A3 FR 3103922A3 FR 1913402 A FR1913402 A FR 1913402A FR 1913402 A FR1913402 A FR 1913402A FR 3103922 A3 FR3103922 A3 FR 3103922A3
- Authority
- FR
- France
- Prior art keywords
- token
- sensitive data
- digest
- database
- data
- 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
Links
- 238000003860 storage Methods 0.000 title claims abstract description 21
- 238000000034 method Methods 0.000 claims abstract description 75
- 230000004044 response Effects 0.000 claims abstract description 61
- 238000013507 mapping Methods 0.000 claims description 80
- 230000008569 process Effects 0.000 claims description 15
- 230000002441 reversible effect Effects 0.000 claims description 12
- 238000004590 computer program Methods 0.000 claims description 6
- 238000004364 calculation method Methods 0.000 claims description 4
- 238000012545 processing Methods 0.000 abstract description 12
- 230000015654 memory Effects 0.000 description 19
- 238000007792 addition Methods 0.000 description 18
- 238000010586 diagram Methods 0.000 description 15
- 238000004422 calculation algorithm Methods 0.000 description 14
- 230000006870 function Effects 0.000 description 14
- 238000004891 communication Methods 0.000 description 9
- 230000009471 action Effects 0.000 description 4
- 238000009826 distribution Methods 0.000 description 4
- 239000012141 concentrate Substances 0.000 description 3
- 238000013500 data storage Methods 0.000 description 3
- 238000011156 evaluation Methods 0.000 description 3
- 230000001052 transient effect Effects 0.000 description 3
- 230000004888 barrier function Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000013478 data encryption standard Methods 0.000 description 2
- 238000013506 data mapping Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 239000007787 solid Substances 0.000 description 2
- 230000003190 augmentative effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000002427 irreversible effect Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000000873 masking effect Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011022 operating instruction Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000002829 reductive effect Effects 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- 230000001755 vocal effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/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/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- 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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Bioethics (AREA)
- Databases & Information Systems (AREA)
- Medical Informatics (AREA)
- Storage Device Security (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Des systèmes et des procédés pour le traitement de demande de tokenisation afin de faciliter le stockage sécurisé de tokens. Une demande de tokenisation comprenant des données sensibles est reçue. Un condensé de données sensibles est généré sur la base des données sensibles et une interrogation comprenant le condensé de données sensibles est soumise à une base de données. La base de données stocke une pluralité d’éléments relationnels. Chaque élément relationnel étant mappé sur (i) un condensé de données sensibles stockées dans la base de données et (ii) un condensé donné de tokens stocké dans la base de données. Un token associé aux données sensibles est généré sur la base d’une réponse à l’interrogation reçue de la base de données.
Description
La présente invention concerne de façon générale des processus de sécurisation des données (tokenisation) bien qu’elle n’y soit pas limitée. Plus spécifiquement, la présente invention concerne des techniques pour sécuriser (tokeniser) des données sensibles et pour améliorer la sécurité des données de mappage de tokens.
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 la 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 tokénisées des données sensibles) qui manquent de signification extrinsèque ou de valeur. Puisque les tokens manquent de signification extrinsèque ou de valeur, un mappage de données est généralement retenu qui mappe chaque token en retour sur les 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 des données sensibles et d’amélioration de la sécurité des données de mappage de token 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 tokeniser des données sensibles et améliorer la sécurité des données de mappage de token.
Dans un mode de réalisation, un système de tokenisation inclut un processeur et un support de stockage lisible par ordinateur qui inclut des instructions. Lors de l’exécution par le processeur, les instructions amènent le système à mettre en œuvre des opérations. Les opérations incluent la réception d’une requête de tokenisation comprenant des données sensibles. Un condensé de données sensibles est généré sur la base des données sensibles et une interrogation comprenant le condensé de données sensibles est soumise à une base de données. La base de données stocke une pluralité d’éléments relationnels. Chaque élément relationnel étant mappé sur (i) un condensé de données sensibles stockées dans la base de données et (ii) un condensé donné de token stocké dans la base de données. Un token associé aux données sensibles est généré sur la base d’une réponse à l’interrogation reçue de la base de données.
Dans certains modes de réalisation de système, la génération d’un token comprend la mise en œuvre d’une opération inversible sur l’élément relationnel et sur les données sensibles pour générer le token.
Dans certains modes de réalisation de système, l’opération inversible est une opération OU exclusive (OR exclusive).
Dans certains modes de réalisation de système, les opérations comprennent par ailleurs: la réception d’une requête de détokenisation comprenant le token ; le calcul d’un condensé de token basé sur le token de la demande de détokenisation ; la récupération de la base de données d’un élément relationnel mappé sur le condensé de token ; la mise en œuvre d’une opération inversible sur l’élément relationnel et sur le token de la requête de détokenisation pour calculer les données sensibles ; et la réponse à la requête de détokenisation en envoyant les données sensibles calculées.
Dans certains modes de réalisation de système, le condensé de token est un condensé claveté et dans lequel le calcul du condensé de token comprend: la mise en œuvre d’une opération de hachage claveté sur le token.
Dans certains modes de réalisation de système, la génération du condensé de données sensibles comprend: la mise en œuvre d’une opération de hachage sur les données sensibles pour générer le condensé de données sensibles.
Dans certains modes de réalisation de système, après que la base de données a déterminé que le condensé de données sensibles n’est pas stocké dans la base de données, la génération du token comprend: l’identification d’un token non attribué à associer aux données sensibles ; et le mappage du condensé de données sensibles sur un condensé de token basé sur le token non attribué dans la base de données.
Dans certains modes de réalisation de système, l’identification d’un token non attribué comprend: la génération itérative de valeurs aléatoires pour le token ; et la comparaison d’un condensé de token respectif généré pour chaque valeur aléatoire avec des condensés de tokens stockés dans la base de données.
Dans certains modes de réalisation de système, l’identification d’un token non attribué comprend: l’accès à un index définissant une pluralité de tokens désignés pour usage par le système.
Dans certains modes de réalisation d’un système, la génération d’un token comprend la mise en œuvre d’une opération inversible sur l’élément relationnel et sur les données sensibles pour générer le token.
Dans un autre mode de réalisation, un procédé pour la tokenisation inclut la réception d’une requête de tokenisation comprenant des données sensibles. Un condensé de données sensibles est généré sur la base des données sensibles et une interrogation comprenant le condensé de données sensibles est soumise à une base de données. La base de données stocke une pluralité d’éléments relationnels. Chaque élément relationnel étant mappé sur (i) un condensé de données sensibles stockées dans la base de données et (ii) un condensé donné de token stocké dans la base de données. Un token associé aux données sensibles est généré sur la base d’une réponse à l’interrogation reçue de la base de données.
Dans certains modes de réalisation du procédé, la réponse inclut un élément relationnel crypté et dans lequel la génération du token comprend: le décryptage de l’élément relationnel crypté pour obtenir un élément relationnel ; et la mise en œuvre d’une opération inversible sur l’élément relationnel et sur les données sensibles pour générer le token.
Dans certains modes de réalisation de procédé, le décryptage de l’élément relationnel crypté comprend: l’accès à un module matériel de sécurité pour récupérer une clé cryptographique.
Dans certains modes de réalisation du procédé, le condensé de données sensibles est un condensé de données sensibles claveté et dans lequel la génération du condensé de données sensibles comprend: la mise en œuvre d’une opération de hachage claveté sur les données sensibles pour générer le condensé de données sensibles claveté.
Dans certains modes de réalisation du procédé, après que la base de données a déterminé que le condensé de données sensibles n’est pas stocké dans la base de données, la génération du token comprend: l’identification d’un token non attribué à associer aux données sensibles ;
Dans certains modes de réalisation du procédé, l’identification d’un token non attribué comprend: la génération itérative de valeurs aléatoires pour le token ; et la comparaison d’un condensé de token respectif claveté généré pour chaque valeur aléatoire avec des condensés de tokens clavetés stockés dans la base de données.
Certains modes de réalisation du procédé comprennent par ailleurs: la réception d’une requête de détokenisation comprenant le token ; et la détokenisation du token en utilisant un élément relationnel reçu de la base de données.
Dans certains modes de réalisation du procédé, la détokénisation d’un token comprend: l’exécution d’une opération inversible sur l’élément relationnel et le token pour obtenir les données sensibles.
Certains modes de réalisation du procédé comprennent par ailleurs: la génération d’un condensé de token claveté basé sur le token ; et la communication du condensé de token claveté à la base de données pour recevoir l’élément relationnel.
Dans certains modes de réalisation du procédé, la requête de tokenisation est reçue à un premier dispositif informatique provenant d’un deuxième dispositif informatique et dans lequel le procédé comprend par ailleurs: la transmission du token du premier dispositif informatique au deuxième dispositif informatique sur un canal de communication.
Dans certains modes de réalisation du procédé, la base de données stocke une pluralité d’éléments relationnels cryptés qui mappent un condensé donné de données sensibles claveté stocké dans la base de données et sur un condensé donné de token claveté stocké dans la base de données.
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 une requête de tokenisation comprenant des données sensibles. Un condensé de données sensibles est généré sur la base des données sensibles et une interrogation comprenant le condensé de données sensibles est soumise à une base de données. La base de données stocke une pluralité d’éléments relationnels. Chaque élément relationnel étant mappé sur (i) un condensé de données sensibles stockées dans la base de données et (ii) un condensé donné de token stocké dans la base de données. Un token associé aux données sensibles est généré sur la base d’une réponse à l’interrogation reçue de la base de données.
Dans certains modes de réalisation de supports de stockage, les instructions amènent par ailleurs le dispositif informatique à mettre en œuvre les opérations de l’un quelconque des modes de réalisation du procédé exposé ci-dessus.
Dans un autre mode de réalisation, un produit-programme d’ordinateur comprend des instructions de code de programme stockées sur un support lisible par ordinateur pour exécuter les étapes du procédé selon l’un quelconque des modes de réalisation exposés ci-dessus lorsque ledit programme fonctionne sur un ordinateur.
Ce résumé est fourni pour présenter une sélection de concepts sous une forme simplifiée qui sera décrite de façon plus détaillée 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.
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 l’invention présente 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 tokens130, un module matériel de sécurité (« HSM ») 140 et une base de données ou coffre de tokens150. La FIG.1 illustre les divers composants en cours de communication les uns avec les autres via des réseaux (p. ex. le réseau160) 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éseau160 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é 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é des autres portions de l’environnement d’exploitation en utilisant des barrières physiques (p. ex. des clôtures) 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 différents de protection pour les données stockées et/ou communiquées dans chaque environnement respectif. En conséquence, 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.
Tel 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 tokens130. En réponse à chaque requête de tokenisation, le serveur de tokens130 renvoie un token mappé sur les données sensibles incluses dans cette requête de tokenisation. Tel 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. Dans divers modes de réalisation, un token peut être implémenté comme un nombre aléatoire, un nombre pseudo aléatoire, une valeur de compteur, et similaire.
À 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 tokens130 qui inclut les informations de la carte de crédit. En réponse à la requête de tokenisation, le dispositif client peut recevoir un token mappé sur 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 transmet le token mappé sur les informations de la carte de crédit.
Dans l’environnement d’exploitation100, un dispositif informatique transmet une requête de détokenisation incluant un token au serveur de token130 pour récupérer les données sensibles associées au token. En réponse à la réception de la requête de détokenisation, le serveur de tokens130 soumet une interrogation basée sur le token à une base de données ou coffre de tokens150. La base de données150 est configurée pour stocker des données de mappage de token152 qui associent de façon unique chaque token à des données sensibles particulières. 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. Le serveur de tokens130 détermine les données sensibles associées au token sur la base d’une réponse à l’interrogation reçue de la base de données 150. Le serveur de tokens130 peut ensuite transmettre une réponse de détokenisation incluant les données sensibles au dispositif informatique.
Poursuivant avec l’exemple ci-dessus, le dispositif informatique120 peut transmettre une requête de détokenisation au serveur de tokens130 qui inclut le token reçu du dispositif client 110. En réponse à la réception de la requête de détokenisation, le serveur de tokens130 soumet une interrogation basée sur le token à une base de données150. Le serveur de tokens130 détermine les informations de carte de crédit associées au token sur la base d’une réponse à l’interrogation reçue de la base de données 150. Le serveur de tokens130 peut ensuite transmettre une réponse de détokenisation incluant les informations de carte de crédit au dispositif informatique120.
Dans certains modes de réalisation, le serveur de tokens130 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 tokens130 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 tokens130 peut ensuite recevoir une réponse de cryptage incluant les données cryptées 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 similaire.
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 informatique1000 décrit de façon plus détaillée ci-dessous en référence à la FIG. 10. Chaque système montré dans la FIG.1 peut comprendre un seul dispositif ou des dispositifs multiples en coopération dans un environnement distribué. Par exemple, le serveur de tokens130, le HSM140 et/ou la base de données150 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.2 est un diagramme de flux de communication illustrant un exemple d’une technique pour tokeniser des données sensibles et améliorer la sécurité des données de mappage de token. À l’étape201, un dispositif client 210 transmet une requête de tokenisation comprenant des données sensibles à un serveur de tokens230. Dans un mode de réalisation, le dispositif client 210 et le serveur de tokens230 sont implémentés en utilisant le dispositif client 110 et le serveur de tokens130 de la FIG.1 respectivement. À l’étape203, le serveur de tokens230 génère (ou calcule) un condensé de données sensibles basé sur les données sensibles incluses dans la requête de tokenisation. Dans un mode de réalisation, le serveur de tokens230 génère le condensé de données sensibles en effectuant une opération de hachage sur les données sensibles pour générer le condensé de données sensibles. L’homme de métier reconnaîtra qu’une « opération de hachage » fait référence à un algorithme qui produit un condensé irréversible et unique (ou valeur hachée) d’une taille fixe comme produit en réponse à la réception d’une chaîne de valeurs d’une quelconque longueur comme entrée. Des exemples d’opérations de hachage appropriées incluent: l’algorithme de condensé de messageMD5, l’algorithme de hachage sécurisé2 (SHA-2), l’algorithme de hachage sécurisé3 (SHA-3), le condensé de messaged’évaluations primitives d’intégrité RACE 160 (RACE Integrity Primitives Evaluation Message Digest-160), et similaire. Dans un mode de réalisation, le serveur de tokens230 génère le condensé de données sensibles en effectuant une opération de répartition aléatoire non réversible à sens unique sur les données sensibles pour générer le condensé de données sensibles.
À l’étape205, le serveur de tokens230 soumet une interrogation comprenant le condensé de données sensibles à une base de données250 qui stocke des données de mappage de token252. Ainsi qu’illustré dans la FIG.2, pour chaque token stocké dans la base de données250, des données de mappage252 incluent: une première association entre ce token et un condensé donné de données sensibles stocké dans la base de données250 ; et une deuxième association entre ce token et des données sensibles cryptées particulières correspondant à une version cryptée des données sensibles utilisée pour générer le condensé de données sensibles. En réponse à la réception de l’interrogation, la base de données250 effectue une recherche pour déterminer si le condensé de données sensibles est inclus dans les données de mappage de token252, à l’étape207. S’il est déterminé à l’issue de la recherche que le condensé de données sensible est inclus dans les données de mappage de token252, la technique poursuit à l’étape209. Autrement, s’il est déterminé à l’issue de la recherche que le condensé de données sensible n’est pas inclus dans les données de mappage de token252, la technique poursuit à l’étape213.
À l’étape209, une fois qu’il a été déterminé que le condensé de données sensibles est inclus dans les données de mappage de token252, la base de données250 transmet une réponse au serveur de tokens230 qui inclut un token associé au condensé de données sensibles dans les données de mappage de token252. Lors de la réception de cette réponse en provenance de la base de données250, le serveur de tokens230 transmet une réponse de tokenisation qui inclut le token au dispositif client 210, à l’étape211.
À l’étape213, une fois qu’il a été déterminé que le condensé de données sensibles n’est pas inclus dans les données de mappage de token252, la base de données250 transmet une réponse au serveur de tokens230 indiquant que la requête de tokenisation est une nouvelle requête de tokenisation. En réponse à la réception de cette réponse de la base de données250, le serveur de tokens230 identifie un token non attribué pour associer aux données sensibles, à l’étape215. Lors de l’identification du token non attribué, le serveur de token230 transmet une requête de cryptage comprenant les données sensibles au HSM240, à l’étape217. À l’étape219, le HSM240 effectue un processus de cryptage sur les données sensibles pour générer les données sensibles cryptées. À l’étape221, le HSM240 transmet une réponse de cryptage comprenant les données sensibles cryptées au serveur de tokens230.
Lors de la réception de la réponse de cryptage, le serveur de tokens230 transmet de nouvelles données de mappage de token à la base de données250 pour actualiser les données de mappage de token252, à l’étape223. Les nouvelles données de mappage de token incluent deux associations: une première association entre le token non attribué et le condensé de données sensibles ; et une deuxième association entre le token non attribué et les données sensibles cryptées. En actualisant les données de mappage de token252 avec les nouvelles données de mappage de token, le token non attribué devient uniquement associé aux données sensibles. À l’étape225, le serveur de tokens230 transmet une réponse de tokenisation incluant le token non attribué (précédemment) — maintenant uniquement associé aux données sensibles incluses dans la requête de tokenisation — au dispositif client 210.
La FIG.3 est un diagramme de flux de communication illustrant un exemple d’une technique pour tokeniser des données sensibles et améliorer la sécurité des données de mappage de token. À l’étape301, un dispositif client 310 transmet une requête de tokenisation comprenant des données sensibles à un serveur de tokens330. Dans un mode de réalisation, le dispositif client 310 et le serveur de tokens330 sont implémentés en utilisant le dispositif client 110 et le serveur de tokens130 de la FIG.1 respectivement. À l’étape303, le serveur de tokens330 génère (ou calcule) un condensé de données sensibles basé sur les données sensibles incluses dans la requête de tokenisation. Dans un mode de réalisation, le serveur de tokens330 génère le condensé de données sensibles en effectuant une opération de hachage sur les données sensibles pour générer le condensé de données sensibles. Dans un mode de réalisation, le serveur de tokens330 génère le condensé de données sensibles en effectuant une opération de répartition aléatoire non réversible à sens unique sur les données sensibles pour générer le condensé de données sensibles.
À l’étape305, le serveur de tokens330 soumet une interrogation comprenant le condensé de données sensibles à une base de données350 qui stocke des données de mappage de token352. En réponse à la réception de l’interrogation, la base de données350 conduit une recherche pour déterminer si le condensé de données sensibles est inclus dans les données de mappage de token352, à l’étape307. S’il est déterminé à l’issue de la recherche que le condensé de données sensible est inclus dans les données de mappage de token352, la technique poursuit à l’étape309. Autrement, s’il est déterminé à l’issue de la recherche que le condensé de données sensible n’est pas inclus dans les données de mappage de token352, la technique poursuit à l’étape315.
À l’étape309, une fois qu’il a été déterminé que le condensé de données sensibles est inclus dans les données de mappage de token352, la base de données350 transmet une réponse au serveur de tokens330 qui inclut un élément relationnel associé au condensé de données sensibles dans les données de mappage de token352. À l’étape311, le serveur de tokens330 effectue une opération inversible sur les éléments relationnels inclus dans la réponse reçue de la base de données350 et les données sensibles incluses dans la requête de tokenisation reçue du dispositif client 310 pour générer le token.
En génèral une opération inversible est définie en utilisant: en supposant que soit un ensemble et en supposant que soit une fonction, alors:
Dans un mode de réalisation, l’opération inversible est définie en utilisant: en supposant que = {0,1}ℓ pour certains étant l’ensemble de toutes les chaînes binaires d’une longueur donnée et en supposant que soit une fonction, alors:
[Mat. 2]
[Mat. 2]
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 et que si une de l’opération f, g ou h est un XOU (XOR) alors les deux opérations restantes doivent être un XOU.
À l’étape313, le serveur de tokens transmet une réponse de tokenisation qui inclut le token au dispositif client 310. À l’étape315, une fois qu’il a été déterminé que le condensé de données sensibles n’est pas inclus dans les données de mappage de token352, la base de données350 transmet une réponse au serveur de tokens330 qui indique que la requête de tokenisation est une nouvelle requête de tokenisation. En réponse à la réception de cette réponse de la base de données350, le serveur de tokens330 identifie un token non attribué pour associer aux données sensibles, à l’étape317. À l’étape319, le serveur de tokens330 effectue une opération inversible sur les données sensibles incluses dans la requête de tokenisation reçue du dispositif client 310 et le token non attribué identifié pour association aux données sensibles, afin de de générer le token. Dans un mode de réalisation, l’opération inversible est une opération XOU à bits. À l’étape321, le serveur de tokens330 génère un condensé de token basé sur le token non attribué identifié pour association aux données sensibles.
À l’étape323, le serveur de tokens330 transmet de nouvelles données de mappage de token à la base de données350 pour mettre à jour les données de mappage de token352. Les nouvelles données de mappage de token incluent deux associations: une première association entre le condensé de données sensibles et l’élément relationnel ; et une deuxième association entre le condensé de token et l’élément relationnel. En actualisant les données de mappage de token352 avec les nouvelles données de mappage de token, le token non attribué devient uniquement associé aux données sensibles. À l’étape325, le serveur de tokens330 transmet une réponse de tokenisation incluant le token non attribué (précédemment) — maintenant uniquement associé aux données sensibles incluses dans la requête de tokenisation — au dispositif client 210.
Une comparaison entre les données de mappage de token352 de la FIG.3 et les données de mappage de token252 de la FIG.2 illustre les distinctions diverses entre les techniques exemplaires respectives illustrées par chaque figure. Par exemple, les données de mappage de token252 associent directement chaque token stocké dans la base de données250 à deux représentations différentes des données: un condensé des données sensibles correspondantes et une version cryptée des données sensibles correspondantes. Par contraste, les données de mappage de token352 manquent d’une quelconque association directe entre les tokens stockés dans la base de données350 et les données sensibles correspondantes. Au lieu de cela, les données de mappage de token352 incluent une pluralité d’éléments relationnels avec chaque élément relationnel mappé sur: (i) un condensé donné de données sensibles stocké dans la base de données350 et (ii) un condensé donné de token stocké dans la base de données350.
Une autre distinction est que la technique exemplaire illustrée par la FIG.2 implique un HSM alors que la technique exemplaire illustrée par la FIG.3 est dépourvue d’une quelconque implication d’un HSM. Cette distinction concerne la sécurité des données sensibles stockées dans la base de données de 250 qui sont, au moins, partiellement dépendantes du cryptage de ces données sensibles en vertu des deuxièmes associations de données de mappage de token252. Spécifiquement, l’association entre un token donné et une version cryptée de données sensibles associées à ce token. Contrairement à la base de données250, la base de données350 est dépourvue d’une quelconque donnée sensible en vertu de l’irréversibilité des opérations de hachage que le serveur de tokens330 effectue pour générer les concentrés de données sensibles stockés dans la base de données350.
De nombreuses techniques cryptographiques utilisent des opérations inversibles, telles que des opérations arithmétiques modulaires, pour manipuler des valeurs d’entrées pour masquer et à d’autres fins. Des exemples de ces opérations arithmétiques modulaires incluent des opérations XOU binaires pour des chaînes binaires et des opérations modulo 10 d’addition chiffrée pour des valeurs de nombre entier. Un aspect des opérations XOU binaire est qu’une entrée fournie à une opération XOU binaire en générant un produit peut être récupérée (ou générée en fournissant la même opération binaire sur le produit). Dans certains modes de réalisation, cet aspect des opérations binaires XOU fournit une consommation réduite de ressources computationnelles en vertu de l’utilisation de moins d’opérateurs de calcul.
La FIG.4 illustre un exemple de mise en œuvre d’une opération modulo 10 d’addition chiffrée (dénoté par ) sur des données sensibles410 et un token420 pour générer un élément relationnel430. Le modulo 10 d’addition chiffrée de la FIG.4 combine deux valeurs de nombre entier de longueurs égales (p. ex. les données sensibles410 et le token420) reçues dans une entrée et génère une valeur de nombre entier (p. ex. l’élément relationnel430) ayant cette même longueur sur un produit.
Dans la FIG.4, l’opération modulo 10 d’addition chiffrée combine des données sensibles410 et le token420 sur la base d’un chiffre à la fois pour générer l’élément relationnel430. Ces opérations modulo 10 d’addition chiffrée sont connues comme additions sans retenue en ce qu’il n’y a pas de report ou autres interactions propagées entre les chiffres. Par exemple, effectuer une addition du chiffre412 des données sensibles410 et du chiffre422 du token420 résulterait généralement en un produit de 12 (c.-à-d. 9 + 3). Cependant, comme on peut le voir dans la FIG.4, un chiffre432 de l’élément relationnel430 généré en effectuant l’opération modulo 10 d’addition chiffrée sur les chiffres412 et 422 résulte en un produit de 2 -- non 12. Au lieu de reporter la retenue résultante « 1 » au chiffre433 de l’élément relationnel430 qui est adjacent au chiffre432, cette retenue résultante est éliminée.
L’homme de métier reconnaîtra que lorsque l’opération modulo 10 d’addition chiffrée précédente est utilisée pour générer un élément relationnel430, les données sensibles410 peuvent être récupérées (ou générées) en fournissant l’élément relationnel430 et le token420 comme entrées dans une opération inverse au modulo 10 d’addition chiffrée (c.-à-d. un modulo 10 de soustraction chiffrée). Autrement, le token420 peut être récupéré (ou généré) en fournissant l’élément relationnel430 et les données sensibles410 comme entrée dans un modulo 10 de soustraction chiffrée.
En plus de l’opération modulo 10 d’addition chiffrée, plusieurs autres opérations sont possibles. En fait, de façon plus générale, les opérations inversibles peuvent être utilisées sous trois conditions: afin de calculer le token lorsque les données relationnelles sont présentes dans la base de données avec une fonction dénommée f à titre d’exemple uniquement ; afin de calculer les données sensibles à partir du token et des données relationnelles avec une fonction dénommée h à titre d’exemple uniquement ; afin de calculer les données relationnelles du token lorsqu’un nouveau token a été créé avec une fonction dé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 être un triplet conformément à la définition 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 f, g, h constitue aussi 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 g, alors pour f et h l’opération modulo 10 de soustraction chiffrée doit être utilisée de sorte que f, g, h constituent aussi 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 h, alors pour f et g l’opération modulo 10 de soustraction chiffrée doit être utilisée de sorte que f, g, h constituent aussi un triplet valide conformément à la définition ci-dessus.
La FIG.5 est un diagramme de flux de communication illustrant un exemple d’une technique pour tokeniser des données sensibles et améliorer la sécurité des données de mappage de token. À l’étape501, un dispositif client 510 transmet une requête de tokenisation comprenant des données sensibles à un serveur de tokens530. Dans un mode de réalisation, le dispositif client 510, le serveur de tokens530 et le HSM540 sont implémentés en utilisant le dispositif client 110, le serveur de tokens130 et le HSM140 de la FIG.1 respectivement. À l’étape503, le serveur de tokens530 génère un condensé de données sensibles claveté basé sur les données sensibles incluses dans la requête de tokenisation. Dans un mode de réalisation, le serveur de tokens530 génère le condensé de données sensibles claveté en appliquant les données sensibles et une valeur clé comme entrées dans une opération de hachage pour générer le condensé de données sensibles claveté comme produit de l’opération de hachage. Dans un mode de réalisation, le serveur de tokens530 obtient la valeur clé du HSM540. Dans un mode de réalisation, le serveur de tokens530 génère le condensé de données sensibles claveté en appliquant les données sensibles et une valeur clé comme entrées dans une opération de distribution aléatoire non réversible, à sens unique, pour générer le condensé de données sensibles claveté comme produit de l’opération de distribution aléatoire non réversible, à sens unique.
À l’étape505, le serveur de tokens530 soumet une interrogation comprenant le condensé de données sensibles claveté à une base de données550 qui stocke des données de mappage de token552. En réponse à la réception de l’interrogation, la base de données550 effectue une recherche pour déterminer si le condensé de données sensibles claveté est inclus dans les données de mappage de token552, à l’étape507. S’il est déterminé à l’issue de la recherche que le condensé de données sensibles claveté est inclus dans les données de mappage de token252, la technique poursuit à l’étape509. Autrement, si ces résultats de recherche dans une détermination que le condensé de données sensibles claveté n’est pas inclus dans les données de mappage de token552, la technique poursuit à l’étape521.
À l’étape509, une fois qu’il a été déterminé que le condensé de données sensibles claveté est inclus dans les données de mappage de token552, la base de données550 transmet une réponse au serveur de tokens530 qui inclut un élément relationnel crypté associé au condensé de données sensibles claveté dans les données de mappage de token552. À l’étape511, le serveur de tokens530 transmet une requête de décryptage comprenant l’élément relationnel crypté au HSM540. À l’étape513, le HSM540 met en œuvre un processus de décryptage pour transformer l’élément relationnel crypté en sa forme d’origine non cryptée pour obtenir l’élément relationnel. Dans un mode de réalisation, le processus de décryptage effectué par le HSM540 utilise une clé cryptographique symétrique. Dans un mode de réalisation, le processus de décryptage effectué par le HSM540 utilise une clé cryptographique asymétrique.
À l’étape515, HSM 540 transmet une réponse de décryptage comprenant l’élément relationnel au serveur de tokens 530. Le serveur de tokens530 effectue une opération inversible sur les données sensibles incluses dans la requête de tokenisation reçue du dispositif client 510 et sur l’élément relationnel inclus dans la réponse de décryptage reçue du HSM540 pour générer un token associé aux données sensibles, à l’étape517. Dans un mode de réalisation, l’opération inversible est une opération XOU binaire. À l’étape519, le serveur de tokens520 transmet une réponse de tokenisation au dispositif client 510 qui inclut le token.
À l’étape521, une fois qu’il a été déterminé que le condensé de données sensibles claveté n’est pas inclus dans les données de mappage de token552, la base de données550 transmet une réponse au serveur de tokens530 qui indique que la requête de tokenisation est une nouvelle requête de tokenisation. En réponse à la réception de cette réponse de la base de données550, le serveur de tokens530 identifie un token non attribué pour associer aux données sensibles, à l’étape523. À l’étape525, le serveur de tokens530 effectue une opération inversible sur les données sensibles incluses dans la requête de tokenisation reçue du dispositif client 510 et le token non attribué identifié pour association aux données sensibles, afin de générer le token. Dans un mode de réalisation, l’opération inversible est une opération XOU binaire.
À l’étape527, le serveur de tokens530 génère un condensé de token claveté basé sur le token non attribué identifié pour association aux données sensibles. Dans un mode de réalisation, le serveur de tokens530 génère le condensé de données sensibles claveté en appliquant le token non attribué et une valeur clé comme entrées dans une opération de hachage pour générer le condensé de données sensibles claveté comme produit de l’opération de hachage. Dans un mode de réalisation, la valeur clé que le serveur de tokens530 utilise pour générer le condensé de token claveté est distincte de la valeur clé que le serveur de tokens530 utilise pour générer le condensé de données sensibles claveté. Dans un mode de réalisation, le serveur de tokens530 utilise une valeur clé commune pour à la fois générer le condensé de token claveté et le condensé de données sensibles claveté. Dans un mode de réalisation, le serveur de tokens530 obtient la valeur clé du HSM540. Dans un mode de réalisation, le serveur de tokens530 génère le condensé de données sensibles claveté en appliquant les données sensibles et une valeur clé comme entrées dans une opération de distribution aléatoire non réversible, à sens unique, pour générer le condensé de données sensibles claveté comme produit de l’opération de distribution aléatoire non réversible, à sens unique.
À l’étape529, le serveur de tokens530 transmet une requête de cryptage comprenant l’élément relationnel généré à l’étape525 au HSM540. À l’étape531, le HSM540 met en œuvre un processus de cryptage sur l’élément relationnel pour générer un élément relationnel crypté. Dans un mode de réalisation, le processus de cryptage effectué par le HSM540 utilise une clé cryptographique symétrique. Dans un mode de réalisation, le processus de cryptage effectué par le HSM540 utilise une clé cryptographique asymétrique. À l’étape533, le HSM240 transmet une réponse de cryptage comprenant les données sensibles cryptées au serveur de tokens530.
À la réception de la réponse de cryptage, le serveur de tokens530 transmet une nouvelle donnée de mappage de token à la base de données de 550 pour actualiser les données de mappage de token552, à l’étape535. Les nouvelles données de mappage de token incluent deux associations: une première association entre le condensé de données sensibles claveté et l’élément relationnel ; et une deuxième association entre le condensé de token claveté et l’élément relationnel. En actualisant les données de mappage de token552 avec les nouvelles données de mappage de token, le token non attribué devient uniquement associé aux données sensibles. À l’étape537, le serveur de tokens530 transmet le token non attribué (précédemment) — maintenant uniquement associé aux données sensibles incluses dans la requête de tokenisation — au dispositif client 510.
Une comparaison entre les données de mappage de token352 de la FIG.3 et les données de mappage de token552 de la FIG.5 démontre que la technique exemplaire illustrée par la FIG.3 peut être augmentée avec diverses techniques de cryptage pour encore améliorer la sécurité des données de mappage de token. Par exemple, une première association de données de mappage de token552 inclut un condensé de données sensibles claveté alors qu’une première association de données de mappage de token352 inclut un condensé de données sensibles. De façon similaire, une deuxième association de données de mappage de token552 inclut un condensé de token claveté alors qu’une deuxième association de données de mappage de token352 inclut un condensé de token.
L’homme de métier reconnaitra que les opérations de hachage tel que l’algorithmeSHA-3 sont disponibles au public. En tant que tels, les éléments relationnels peuvent être compromis par un receveur non autorisé qui est capable d’obtenir des tokens associés à ces éléments. Pour minimiser la probabilité d’une telle compromission, une valeur clé peut être appliquée comme une entrée à une opération de hachage ainsi qu’aux données sensibles et/ou aux tokens pour générer des concentrés de données sensibles clavetés et/ou des concentrés de tokens clavetés, respectivement. Dans ce cas, l’opération de hachage peut être désignée comme une opération de hachage clavetée. L’introduction d’une valeur clé comme une entrée à une opération de hachage peut effectivement privatiser une opération de hachage disponible au public.
Comme autre exemple, les données de mappage de token552 incluent des éléments relationnels cryptés alors que les données de mappage de token352 incluent des éléments relationnels (non cryptés). Un receveur non autorisé accédant à la base de données350 peut récupérer des éléments relationnels non cryptés et potentiellement compromettre des données sensibles et/ou des tokens associés à ces éléments. Pour minimiser la probabilité d’une telle compromission, les éléments relationnels peuvent être cryptés avant de stocker ces éléments dans les données de mappage de token.
En plus d’améliorer la sécurité des données de mappage de token, l’implémentation de diverses techniques de cryptage exposées dans des exemples précédents peut aussi augmenter la complexité computationnelle. Afin d’arbitrer entre ces considérations rivales, les diverses techniques de cryptage exposées dans les exemples ci-dessus peuvent être implémentées individuellement ou être combinées. Dans un mode de réalisation, le serveur de tokens530 peut interagir avec la base de données600 de la FIG.6 en traitant les requêtes de tokenisation (ou détokenisation). Dans ce mode de réalisation, les étapes529-533 de la technique exemplaire illustrée par la FIG.5 peuvent être omises et l’étape535 peut être modifiée. En particulier, l’étape535 peut être modifiée de sorte que les nouvelles données de mappage de token transmises par le serveur de tokens530 pour mettre à jour les données de mappage de token652 incluent deux associations: une première association entre le condensé de données sensibles claveté et l’élément relationnel ; et une deuxième association entre le condensé de token claveté et l’élément relationnel.
Dans un mode de réalisation, le serveur de tokens530 peut interagir avec la base de données700 de la FIG.7 en traitant les requêtes de tokenisation (ou détokenisation). Dans ce mode de réalisation, les étapes503 et 527 de la technique exemplaire illustrée par la FIG.5 peuvent être omises ; et les étapes505-507 et 535 peuvent être modifiées. En particulier, les étapes505-507 peuvent être modifiées de sorte que le serveur de tokens530 soumette une interrogation comprenant le condensé de données sensibles et en réponse à la réception de cette interrogation la base de données700 effectue une recherche pour déterminer si le condensé de données sensibles est inclus dans les données de mappage de token752. En outre, l’étape535 peut être modifiée de sorte que les nouvelles données de mappage de token transmises par le serveur de tokens530 pour mettre à jour les données de mappage de token752 incluent deux associations: une première association entre le condensé de données sensibles et l’élément relationnel crypté ; et une deuxième association entre le condensé de token et l’élément relationnel crypté.
La FIG.8 est un organigramme illustrant un exemple d’un procédé800 de traitement d’une requête de tokenisation conforme à un mode de réalisation de l’invention. Dans un mode de réalisation, le procédé800 est implémenté par le serveur de tokens320 de la FIG.3 ou le serveur de tokens520 de la FIG.5.
À l’étape802, une requête de tokenisation comprenant des données sensibles est reçue. À l’étape804, un condensé de données sensibles est généré (ou calculé) sur la base des données sensibles incluses dans la requête de tokenisation reçue. Dans un mode de réalisation, la génération du condensé de données sensibles comprend d’effectuer une opération de hachage sur les données sensibles pour générer le condensé de données sensibles. Dans un mode de réalisation, le condensé de données sensibles est un condensé de données sensibles claveté. Dans un mode de réalisation, la génération du condensé de données sensibles comprend d’effectuer une opération de hachage claveté sur les données sensibles pour générer le condensé de données sensibles claveté.
À l’étape806, une interrogation comprenant le condensé de données sensibles est soumise à une base de données stockant une pluralité d’éléments relationnels. Dans un mode de réalisation, la base de données est implémentée en utilisant la base de données350, la base de données550, la base de données600 ou la base de données700 des FIGS. 3, 5, 6 et 7 respectivement. Dans un mode de réalisation, chaque élément relationnel étant mappé sur: (i) un condensé de données sensibles stockées dans la base de données et (ii) un condensé donné de token stocké dans la base de données. Dans un mode de réalisation, chaque élément relationnel de la pluralité des éléments relationnels mappe sur: (i) un condensé donné de données sensibles claveté stocké dans la base de données et (ii) un condensé donné de token claveté stocké dans la base de données. Dans un mode de réalisation, chaque élément relationnel de la pluralité des éléments relationnels est un élément relationnel crypté. Dans un mode de réalisation, chaque élément relationnel crypté mappe sur: (i) un condensé donné de données sensibles stocké dans la base de données et (ii) un condensé donné de token stocké dans la base de données. Dans un mode de réalisation, chaque élément relationnel crypté mappe sur: (i) un condensé donné de données sensibles claveté stocké dans la base de données et (ii) un condensé donné de token claveté stocké dans la base de données.
À l’étape808, un token associé aux données sensibles est généré sur la base d’une réponse à l’interrogation reçue de la base de données. Dans un mode de réalisation, la réponse inclut un élément relationnel. Dans un mode de réalisation, la génération d’un token comprend la mise en œuvre d’une opération inversible sur l’élément relationnel et sur les données sensibles pour générer le token. Dans un mode de réalisation, l’opération inversible est une opération XOU. Dans un mode de réalisation, la génération du token comprend la mise en œuvre d’une opération XOU binaire sur l’élément relationnel et sur les données sensibles pour générer le token. Dans un mode de réalisation, la génération du token comprend la mise en œuvre d’une opération modulo 10 d’addition chiffrée sur l’élément relationnel et sur les données sensibles pour générer le token.
Dans un mode de réalisation, la réponse inclut une indication que la requête de tokenisation est une nouvelle requête de tokenisation. Dans un mode de réalisation, la réponse inclut l’indication en réponse à une détermination que le condensé de données sensibles n’est pas stocké dans la base de données lorsque l’interrogation est soumise. Dans un mode de réalisation, la génération du token comprend d’identifier un token non attribué pour associer aux données sensibles et de mapper le condensé de données sensibles sur un condensé de token basé sur le token non attribué dans la base de données. Dans un mode de réalisation, l’identification d’un token non attribué comprend de générer de façon itérative (ou de calculer) des valeurs aléatoires pour le token est de comparer un condensé de token respectif généré pour chaque valeur aléatoire avec des condensés de token stockés dans la base de données. Dans un mode de réalisation, l’identification d’un token non attribué comprend de générer de façon itérative (ou de calculer) des valeurs aléatoires pour le token est de comparer un condensé de token respectif claveté généré pour chaque valeur aléatoire avec des condensés de tokens clavetés stockés dans la base de données. Dans un mode de réalisation, l’identification du token non attribué comprend l’accès à un index définissant une pluralité de tokens désignés pour être utilisés par un système.
Dans un mode de réalisation, le mappage du token non attribué sur le condensé de token comprend la mise en œuvre d’une opération inversible sur le token non attribué et sur les données sensibles pour générer un élément relationnel. Dans un mode de réalisation, le mappage du token non attribué sur le condensé de token comprend la mise en œuvre d’une opération XOU sur le token non attribué et sur les données sensibles pour générer un élément relationnel. Dans un mode de réalisation, le mappage du token non attribué sur le condensé de token comprend la mise en œuvre d’une opération XOU binaire sur le token non attribué et sur les données sensibles pour générer un élément relationnel. Dans un mode de réalisation, le mappage du token non attribué sur le condensé de token comprend la mise en œuvre d’une opération modulo 10 d’addition chiffrée sur le token non attribué et sur les données sensibles pour générer un élément relationnel.
Dans un mode de réalisation, la réponse inclut un élément relationnel crypté. Dans un mode de réalisation, le procédé800 comprend par ailleurs le décryptage de l’élément relationnel crypté pour obtenir un élément relationnel. Dans un mode de réalisation, le décryptage de l’élément relationnel crypté comprend d’accéder à un HSM pour récupérer une clé cryptographique. Dans un mode de réalisation, le procédé800 comprend par ailleurs la transmission d’une requête de décryptage comprenant l’élément relationnel crypté à un HSM. Dans un mode de réalisation, le procédé800 comprend par ailleurs la réception d’une réponse de décryptage comprenant l’élément relationnel crypté d’un HSM.
Dans un mode de réalisation, la requête de tokenisation est reçue par un premier dispositif informatique en provenance d’un deuxième dispositif informatique. Dans un mode de réalisation, le procédé800 comprend par ailleurs la transmission du token du premier dispositif informatique au deuxième dispositif informatique sur un canal de communication.
La FIG.9 est un organigramme illustrant un exemple d’un procédé900 de traitement d’une requête de détokenisation conforme à un mode de réalisation de l’invention. Dans un mode de réalisation, le procédé900 est implémenté par le serveur de tokens320 de la FIG.3 ou le serveur de tokens520 de la FIG.5. À l’étape902, une requête de détokenisation comprenant un token est reçue. À l’étape904, un condensé de token est généré basé sur le token inclus dans la requête de détokenisation. Dans un mode de réalisation, la génération du condensé de token comprend d’effectuer une opération de hachage sur le token pour générer le condensé de token. Dans un mode de réalisation, le condensé de tokens est un condensé de token claveté. Dans un mode de réalisation, la génération du condensé de token comprend d’effectuer une opération de hachage claveté sur le token pour générer un condensé de token claveté.
À l’étape906, une interrogation comprenant le condensé de token est soumise à une base de données stockant une pluralité d’éléments relationnels. Dans un mode de réalisation, chaque élément relationnel de la pluralité des éléments relationnels mappe sur: (i) un condensé donné de données sensibles claveté stocké dans la base de données et (ii) un condensé donné de token claveté stocké dans la base de données. Dans un mode de réalisation, chaque élément relationnel de la pluralité des éléments relationnels est un élément relationnel crypté. Dans un mode de réalisation, chaque élément relationnel crypté mappe sur: (i) un condensé donné de données sensibles stocké dans la base de données et (ii) un condensé donné de token stocké dans la base de données. Dans un mode de réalisation, chaque élément relationnel crypté mappe sur: (i) un condensé donné de données sensibles claveté stocké dans la base de données et (ii) un condensé donné de token claveté stocké dans la base de données. Dans un mode de réalisation, la base de données est implémentée en utilisant la base de données350, la base de données550, la base de données600 ou la base de données700 des FIGS. 3, 5, 6 et 7 respectivement.
À l’étape908, le token est détokenisé sur la base d’une réponse à l’interrogation reçue de la base de données afin d’obtenir des données sensibles associées au token. Dans un mode de réalisation, la réponse inclut un élément relationnel. Dans un mode de réalisation, la détokenisation du token comprend la mise en œuvre d’une opération inversible sur l’élément relationnel et sur les données sensibles pour générer le token. Dans un mode de réalisation, la réponse inclut un élément relationnel. Dans un mode de réalisation, la détokenisation du token comprend la mise en œuvre d’une opération XOU sur l’élément relationnel et sur les données sensibles pour obtenir le token. Dans certains modes de réalisation, la détokenisation du token comprend la mise en œuvre d’une opération XOU binaire sur l’élément relationnel et sur les données sensibles pour obtenir le token. Dans un mode de réalisation, la détokenisation du token comprend la mise en œuvre d’une opération modulo 10 d’addition chiffrée sur l’élément relationnel et sur les données sensibles pour obtenir le token.
Dans un mode de réalisation, la réponse inclut un élément relationnel crypté. Dans un mode de réalisation, le procédé900 comprend par ailleurs de décrypter l’élément relationnel crypté pour obtenir un élément relationnel. Dans un mode de réalisation, le décryptage de l’élément relationnel crypté comprend d’accéder à un HSM pour récupérer une clé cryptographique. Dans un mode de réalisation, le procédé900 comprend par ailleurs la transmission d’une requête de décryptage comprenant l’élément relationnel crypté à un HSM. Dans un mode de réalisation, le procédé900 comprend par ailleurs la réception d’une réponse de décryptage comprenant un élément relationnel d’un HSM.
Dans un mode de réalisation, les procédés800 et/ou 900 sont mis en œuvre 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, les procédés800 et/ou 900 sont mis en œuvre par un processeur exécutant un code stocké sur un support non transitoire lisible par ordinateur (p. ex. une mémoire).
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.10, les dispositifs clients 110, 210, 310 et 510 ; le dispositif informatique120 ; les serveurs de tokens130, 230, 330 et 530 ; les HSMs140, 240, et 540 et les bases de données150, 250, 350, 550, 600 et 700 peuvent être implémentés sur un ou plusieurs dispositifs informatiques ou systèmes tels que le système informatique exemplaire1000. Le système informatique1000 peut comprendre un processeur1026, une mémoire1028, un dispositif de mémoire de masse1030, une interface entrée/sortie (I/O) 1032, et une interface homme-machine (HMI) 1034. Le système informatique1000 peut aussi être couplé de façon fonctionnelle à une ou plusieurs ressources externes1036 via le réseau1023 ou l’interface I/O1032. 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 dématérialisé basé sur le cloud, ou toute autre ressource informatique adaptée qui peut être utilisée par le système informatique1000.
Le processeur1026 peut inclure un ou plusieurs dispositifs sélectionnés parmi des: 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émoire1028. La mémoire1028 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 masse1030 peut inclure des dispositifs de stockage de données tels qu’un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l’état solide non volatile, ou tout autre dispositif capable de stocker des informations.
Le processeur1026 peut fonctionner sous le contrôle d’un système d’exploitation1038 qui réside dans la mémoire1028. Le système d’exploitation1038 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’application1040 qui réside dans la mémoire1028, puisse avoir des instructions exécutées par le processeur1026. Dans un autre mode de réalisation, le processeur1026 peut exécuter l’application1040 directement et dans ce cas, le système d’exploitation1038 peut être omis. Une ou plusieurs structures de donnée1042 peuvent également résider dans la mémoire1028, et peuvent être utilisées par le processeur1026, le système d’exploitation1038, ou l’application1040 pour stocker ou manipuler des données.
L’interfaceI/O1032 peut fournir une interface de machine qui couple de façon fonctionnelle le processeur1026 à d’autres dispositifs et systèmes, tels que le réseau1023 ou une ou plusieurs ressources externes1036. L’application1040 peut ainsi collaborer avec le réseau1023 ou les ressources externes1036 en communiquant via l’interface I/O1032 pour fournir les divers éléments, fonctions, applications, processus, ou modules composant les modes de réalisation de l’invention. L’application1040 peut aussi avoir un code de programme qui est exécuté par ladite une ou plusieurs ressources externes1036 ou autrement repose sur les fonctions ou signaux fournis par d’autres systèmes ou composants de réseau externes au système informatique1000. 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’ordinateur1000, distribuées à des ordinateurs multiples et à d’autres ressources externes1036, ou apportées par des ressources informatiques (matérielles et logicielles) qui sont fournies comme services sur le réseau1023, par exemple un service tel qu’un service informatique dématérialisé.
Le HMI1034 peut être couplé de façon opérationnelle au processeur1026 du système informatique1000 d’une façon connue pour permettre à un utilisateur d’interagir directement avec le système informatique1000. Le HMI1034 peut inclure des écrans 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 HMI1034 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 processeur1026.
Une base de données1044 peut résider sur le dispositif de mémoire de masse 1030, et peut être utilisée pour collecter et organiser les données utilisées par les différents systèmes et modules décrits dans les présentes. Dans un mode de réalisation, une ou plusieurs des bases de données150, base de données250, base de données350, base de données550, base de données600 et base de données700 peuvent être implémentées en utilisant une ou plusieurs bases de données telles que la base de données1044. La base de données1044 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ées1044 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. Un système de gestion de base de données sous forme de logiciel informatique d’application qui s’exécute sous la forme d’instructions sur le processeur1026 peut être utilisé pour accéder à l’information ou aux données stockées dans des fichiers de la base de données1044 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’exploitation1038, les autres applications1040, 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 ces facteurs, peuvent être désignées dans les présentes 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’il est lu et exécuté par un ou plusieurs processeurs dans un ordinateur, amène cet ordinateur à mettre en œuvre les opérations et/ou les éléments propres aux aspects variés des modes de réalisation de l’invention. Les instructions d’un programme informatique lisible 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, écrits en combinaison avec un ou plusieurs langages de programmation.
Le code de programme mis en œuvre dans toute application/module décrit(e) dans les présentes 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 qui sont 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 des mémoires: 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 (p. ex. 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 les présentes 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. 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. De plus, dans la mesure où les formes verbales « inclut », « ayant », « a », « avec » « compris de » ou leurs variantes, sont utilisées dans la description détaillée ou les 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, il n’est pas de l’intention du demandeur de restreindre ou de limiter, de quelque façon que ce soit, le champ d’application des revendications des présentes à 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 (12)
- Un système de tokenisation comprenant:
un processeur ; et
un support de stockage lisible par ordinateur comprenant des instructions qui, lorsqu’elles sont exécutées par le processeur, amènent le système à mettre en œuvre des opérations, les opérations comprenant :
la réception d’une requête de tokenisation comprenant des données sensibles ;
le calcul d’un condensé de données sensibles basées sur les données sensibles ;
la soumission d’une interrogation à une base de données comprenant le condensé de données sensibles, la base de données stockant une pluralité d’éléments relationnels, chaque élément relationnel étant mappé sur: (i) un condensé donné de données sensibles stocké dans la base de données et (ii) un condensé donné de tokens stocké dans la base de données ; et
la génération d’un token associé aux données sensibles sur la base d’une réponse de la base de données à l’interrogation reçue de la base de données. - Le système de la revendication1, dans lequel la génération du token comprend:
la mise en œuvre d’une opération inversible sur l’élément relationnel et sur les données sensibles pour générer le token. - Le système de la revendication2, dans lequel l’opération inversible est une opération OU exclusive.
- Le système de l’une quelconque des revendications1 à 3, dans lequel les opérations comprennent par ailleurs:
la réception d’une requête de détokenisation comprenant le token ;
le calcul d’un condensé de token basé sur le token de la demande de détokenisation ;
la récupération de la base de données d’un élément relationnel mappé sur le condensé de token ;
la mise en œuvre d’une opération inversible sur l’élément relationnel et sur le token de la requête de détokenisation pour calculer les données sensibles ; et
la réponse à la requête de détokenisation en envoyant les données sensibles calculées. - Le système de la revendication4, dans lequel le condensé de token est un condensé claveté, et dans lequel le calcul du condensé de token comprend:
la mise en œuvre d’une opération de hachage claveté sur le token. - Le système de l’une quelconque des revendications1 à 5, dans lequel la génération du condensé de données sensibles comprend:
la mise en œuvre d’une opération de hachage sur les données sensibles pour générer le condensé de données sensibles. - Le système de l’une quelconque des revendications1 à 6, dans lequel après que la base de données a déterminé que le condensé de données sensibles n’est pas stocké dans la base de données, la génération du token comprend:
l’identification d’un token non attribué à associer aux données sensibles ; et
le mappage du condensé de données sensibles sur un condensé de token basé sur le token non attribué dans la base de données. - Le système de la revendication7, dans lequel l’identification du token non attribué comprend:
la génération itérative de valeurs aléatoires pour le token ; et
la comparaison d’un condensé de token respectif généré pour chaque valeur aléatoire avec des condensés de tokens stockés dans la base de données. - Le système de la revendication7 ou de la revendication8, dans lequel l’identification du token non attribué comprend:
l’accès à un index définissant une pluralité de tokens désignés pour usage par le système. - Le système de l’une quelconque des revendications7 à 9, dans lequel le mappage du condensé de données sensibles sur le condensé de token comprend
la mise en œuvre d’une opération inversible sur le token non attribué et sur les données sensibles pour générer un élément relationnel. - Un procédé de tokenisation comprenant:
la réception d’une requête de tokenisation comprenant des données sensibles ;
le calcul d’un condensé de données sensibles basées sur les données sensibles ;
la soumission d’une interrogation à une base de données comprenant le condensé de données sensibles, la base de données stockant une pluralité d’éléments relationnels, chaque élément relationnel étant mappé sur: (i) un condensé donné de données sensibles stocké dans la base de données et (ii) un condensé donné de tokens stocké dans la base de données ; et
la génération d’un token associé aux données sensibles sur la base d’une réponse de la base de données à l’interrogation reçue de la base de données. - Un produit programme d’ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour mettre en œuvre les étapes du procédé selon la revendication11 lorsque ledit programme fonctionne sur un ordinateur.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1913402A FR3103922B3 (fr) | 2019-11-28 | 2019-11-28 | Stockage de tokens sécurisé |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1913402A FR3103922B3 (fr) | 2019-11-28 | 2019-11-28 | Stockage de tokens sécurisé |
| FR1913402 | 2019-11-28 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3103922A3 true FR3103922A3 (fr) | 2021-06-04 |
| FR3103922B3 FR3103922B3 (fr) | 2021-12-03 |
Family
ID=76136043
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1913402A Active FR3103922B3 (fr) | 2019-11-28 | 2019-11-28 | Stockage de tokens sécurisé |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3103922B3 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20210286886A1 (en) * | 2020-01-27 | 2021-09-16 | Capital One Services, Llc | High performance tokenization platform for sensitive data |
-
2019
- 2019-11-28 FR FR1913402A patent/FR3103922B3/fr active Active
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20210286886A1 (en) * | 2020-01-27 | 2021-09-16 | Capital One Services, Llc | High performance tokenization platform for sensitive data |
| US11741249B2 (en) * | 2020-01-27 | 2023-08-29 | Capital One Services, Llc | High performance tokenization platform for sensitive data |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3103922B3 (fr) | 2021-12-03 |
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 | |
| US10333696B2 (en) | Systems and methods for implementing an efficient, scalable homomorphic transformation of encrypted data with minimal data expansion and improved processing efficiency | |
| US20190386814A1 (en) | Systems and Methods for Implementing an Efficient, Scalable Homomorphic Transformation of Encrypted Data with Minimal Data Expansion and Improved Processing Efficiency | |
| US11726968B2 (en) | Methods, apparatuses, and devices for transferring data assets based on blockchain | |
| Sun et al. | Data security and privacy in cloud computing | |
| US10608811B2 (en) | Private set intersection encryption techniques | |
| CN110214325B (zh) | 数据屏蔽的方法和*** | |
| US20200089917A1 (en) | Providing differential privacy in an untrusted environment | |
| US20070291936A1 (en) | Consumer-driven secure sockets layer modulator | |
| US11621834B2 (en) | Systems and methods for preserving data integrity when integrating secure multiparty computation and blockchain technology | |
| EP3363143B1 (fr) | Méthode d'interrogation confidentielle d'une base de données chiffrée | |
| FR3015080A1 (fr) | Verification d'integrite de paire de cles cryptographiques | |
| WO2022068355A1 (fr) | Procédé et appareil de chiffrement basés sur une caractéristique d'informations, dispositif, et support d'enregistrement | |
| US10476661B2 (en) | Polynomial-based homomorphic encryption | |
| US20230336344A1 (en) | Data processing methods, apparatuses, and computer devices for privacy protection | |
| CN111949998B (zh) | 对象检测及请求方法、数据处理***、装置及存储介质 | |
| US11836267B2 (en) | Opaque encryption for data deduplication | |
| US20230155815A1 (en) | Secure integer comparison using binary trees | |
| US11569985B2 (en) | Preserving inter-party data privacy in global data relationships | |
| JP5972181B2 (ja) | 改ざん検知装置、改ざん検知方法、およびプログラム | |
| Kim et al. | Privacy-preserving parallel kNN classification algorithm using index-based filtering in cloud computing | |
| US8594329B2 (en) | Non-interactive verifiable, delegated computation | |
| FR3103922A3 (fr) | Stockage de tokens sécurisé | |
| FR3107416A1 (fr) | Tokenisation aléatoire efficace dans un environnement dématérialisé | |
| Rowe et al. | The curious case of the half-half bitcoin ECDSA nonces |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |