FR 3097066 A1 20201211 FR 1905885 A 20190604 Description Titre de l'invention : TOKENISATION DANS UN ENVI- RONNEMENT DÉMATÉRIALISÉ [0001] La présente divulgation concerne de façon générale des techniques de sécurisation des données (tokenisation) par jetons numériques (tokens) à forte entropie. En particulier, cette divulgation concerne le déploiement d'une tokenisation à forte entropie dans un environnement basé sur le cloud (environnement dématérialisé) avec une tokenisation à faible entropie sur un réseau correspondant. [0002] Les techniques traditionnelles de tokenisation ne sont généralement pas adaptées pour un stockage à long terme. Par exemple, les techniques dc cryptage qui sont à faible entropie ne sont pas sécurisées. De façon similaire, les techniques de cryptage qui ne sont pas déterministes (telles que celles qui utilisent le salage pour augmenter l'entropie) peuvent occasionner des conflits dans le stockage à long ternie. En outre, les techniques de cryptage sécurisées ne sont généralement pas réversibles et par conséquent ne peuvent pas être utilisées pour le stockage à long terme et la récupération. [0003] Il existe donc un besoin pour un système de cryptage ayant la capacité de tokeniser des données pour un stockage à long terme et capable de récupérer les données tokenisées lors d'une requête autorisée. Selon la divulgation dans la présente, des systèmes et des procédés pour le cryptage de tokens peuvent fournir un cryptage de stockage à long terme qui surmonte les lacunes des approches existantes. [0004] Les modes de réalisation de la présente divulgation décrivent des systèmes et des procédés pour le stockage à long terme dc tokens cryptes. En outre, ce cryptage peut être combiné avec un cryptage dc réseau à court ternie pour fournir un mécanisme sécurisé de bout en bout pour le transfert, le stockage et la récupération d'informations. De plus, la combinaison de cryptage de stockage à long terme et de cryptage de réseau à court terme peut fournir des mécanismes dc sauvegarde si une quelconque portion du processus subit une défaillance. [0005] Dans certains modes de réalisation, un système pour tokeniser des données dans un environnement dématérialisé peut comprendre au moins un processeur et au moins une mémoire non transitoire comprenant des instructions qui, lorsqu'elles sont exécutées par ledit au moins un processeur, amènent le système à mettre en oeuvre des opérations. Les opérations peuvent comprendre la réception d'entrées devant être tokenisées, l'obtention d'une fonction de hachage clavetée, l'utilisation de la fonction de hachage clavetée au niveau d'un dispositif de tokenisation de stockage pour générer un token de stockage pour l'entrée, la création d'une entrée de base de données cryptée reliant le 2 token généré à l'entrée reçue, la fixation d'une échéance pour le token de stockage, et, lorsque le token de stockage est reçu avant l'échéance, la remise de l'entrée liée à cc dernier en réponse. [0006] Dans certains modes de réalisation, la fonction de hachage clavetée peut être obtenue à partir d'un système de gestion de clés. [0007] Dans certains modes de réalisation, les opérations peuvent par ailleurs comprendre la réception au niveau d'un processeur différent de l'environnement dématérialisé, d'une deuxième entrée (307b) à tokeniser en obtenant, pour le processeur différent, la fonction de hachage clavetée du système de gestion de clés (303), et en utilisant la fonction de hachage clavetée pour générer, au niveau du processeur différent, un deuxième token de stockage pour l'entrée, dans lequel le deuxième token de stockage généré par le processeur différent est le même que le token de stockage généré par ledit au moins un processeur. [0008] Dans certains modes de réalisation, ledit au moins un processeur et ladite au moins une mémoire non transitoire peuvent être distribués dans un environnement dématérialisé. Dans certains modes de réalisation, les opérations peuvent par ailleurs comprendre la réception d'une identification (id); et le stockage de l'identification (id) avec le token de stockage (215) dans une base de données d'application. Dans ces modes de réalisation, les opérations peuvent par ailleurs comprendre l'obtention du token de stockage (257) stocké dans la base de données d'application. [0009] Dans certains modes de réalisation, les opérations peuvent par ailleurs comprendre la synchronisation de la base de données cryptée à travers un ou plusieurs serveurs. Dans ces modes de réalisation, les opérations peuvent comprendre par ailleurs l'authentification dudit un ou plusieurs serveurs avant la synchronisation. [0010] Dans certains modes de réalisation, la base de données peut comprendre une mémoire de valeurs clés qui peut comprendre une base de données NoSQL. [0011] Dans certains modes de réalisation, les opérations peuvent comprendre par ailleurs, lorsque la base de données est en dysfonctionnement, la récupération des entrées de la base de données cryptée à partir d'un ou de plusieurs autres serveurs, et la reconstruction de la base de données cryptée en utilisant les entrées récupérées. Dans ces modes de réalisation, les opérations peuvent comprendre par ailleurs l'authentification dudit un ou plusieurs serveurs avant la récupération des entrées. [0012] Dans ces modes de réalisation, le système peut comprendre un dispositif de toke- nisation de réseau (251, 201, 203), ou être en communication avec celui-ci. Dans ces modes de réalisation, les opérations peuvent comprendre par ailleurs, lorsque la base de données cryptée est en dysfonctionnement, la distribution de la fonction de hachage clavetée au dispositif de tokenisation de réseau (251. 201. 203.) et la génération d'un token en utilisant la fonction de hachage clavetée au niveau du dispositif de toke- 3 nisation de réseau, et lorsque la base de données cryptée fonctionne, la réception, comme token de stockage, du token généré en utilisant la fonction de hachage clavetée à partir du dispositif de tokenisation de réseau. [0013] Dans certains de ces modes de réalisation, l'opération peut comprendre par ailleurs l'authentification du dispositif de tokenisation de réseau (251, 201, 203) avant la distribution de la fonction de hachage clavetée. [0014] Dans certains modes de réalisation, l'entrée peut comprendre un token de réseau (207) généré par le dispositif de tokenisation de réseau (201, 203). Dans ces modes de réalisation, les opérations peuvent comprendre par ailleurs, lorsque la base de données cryptée est en dysfonctionnement, le stockage des entrées dans une antémémoire et lorsque la base de données cryptée fonctionne, le décodage des tokens de réseau et le stockage d'une entrée reliant le token de stockage à l'entrée décodée. Dans ces modes de réalisation, l'antémémoire peut comprendre un stockage crypte. [0015] Dans certains modes de réalisation, le token de réseau (207) peut être généré par le dispositif de tokenisation de réseau (201) à partir de données sensibles (267). Dans ces modes de réalisation, le serveur peut fonctionner comme dispositif de tokenisation de réseau (201). [0016] Dans certains modes de réalisation, le dispositif de tokenisation de réseau (251, 201) peut être en communication avec ledit au moins un processeur et les opérations peuvent comprendre par ailleurs la réception d'un token de stockage (257), l'obtention du token de réseau (265) à partir du dispositif de tokenisation de stockage, le routage du token de réseau vers le dispositif de tokenisation de réseau (251, 201) et l'obtention des données sensibles (267) à partir du token de réseau. [0017] Dans certains modes de réalisation, le dispositif de tokenisation de réseau (251, 201, 203) peut générer le token de réseau en utilisant une tokenisation réversible. Dans ces modes de réalisation, la tokenisation réversible peut comprendre le cryptage avec préservation de format. [0018] Dans certains modes de réalisation, les opérations peuvent comprendre par ailleurs l'obtention d'une clé correspondant à une clé utilisée par le dispositif de tokenisation de réseau (251, 201, 203) pour générer le token de réseau ; et l'utilisation de la clé correspondante pour décoder le token de réseau ; et ensuite la génération d'un token de stockage en utilisant la fonction de hachage clavetée. Dans ces modes de réalisation, les opérations peuvent par ailleurs comprendre le renouvellement périodique de la clé correspondante. [0019] Dans certains modes de réalisation, le dispositif de tokenisation de réseau (251, 201, 203) peut saler les données sensibles (267) avant de générer le token de réseau, et les opérations peuvent par ailleurs comprendre l'obtention du sel utilisé par le dispositif de tokenisation de réseau (251, 201, 203), et l'enlèvement du sel du token de réseau décodé avant de générer le token de stockage en utilisant la fonction de hachage clavetée. [0020] Dans certains modes de réalisation, le système peut être en communication avec au moins un routeur de réseau. Dans ces modes de réalisation, ledit au moins un routeur de réseau peut exécuter des instructions pour fonctionner comme dispositif de tokenisation de réseau (251, 201, 203). [0021] Dans certains de ces modes de réalisation, les opérations peuvent par ailleurs comprendre l'authentification du routeur de réseau avant l'acceptation de l'entrée (207). [0022] Certains modes de réalisation combinent une tokenisation de réseau à la périphérie des centres de données protégés avec une tokenisation de stockage pour les données devant être stockées par application dans le centre de données. Le dispositif de tokenisation de réseau peut préserver l'interface de l'application et peut être à faible entropie alors que le dispositif de tokenisation de stockage peut être à forte entropie. Dans le dispositif de tokenisation de réseau, un quelconque risque augmenté dû à la faible entropie peut être contré par la courte durée de vie des tokens de réseau. [0023] Les deux dispositifs de tokenisation de réseau et de stockage peuvent répliquer leurs ensembles de tokens à travers les multiples centres de données de façon à garantir la cohérence à travers les centres de données. En outre, le dispositif de tokenisation de stockage peut utiliser une fonction de hachage clavetée à partir d'un système de gestion de clés afin d'assurer la cohérence à travers différents dispositifs de tokenisation de stockage. [0024] On comprendra que la description générale qui précède et la description détaillée qui suit sont présentées exclusivement à titre d'exemple et d'explication et ne sont pas restreintes aux modes de réalisation divulgués. [0025] Les dessins accompagnants illustrent plusieurs modes de réalisation et conjointement avec la description, servent à expliquer les principes divulgués dans les présentes. Dans les dessins : [0026] [fig.1] décrit un système pour le cryptage de tokens à long terme à travers une pluralité de centres de données dans un environnement dématérialisé. [0027] [fig.2A] décrit un système combinant le cryptage de tokens à court terme avec des entrées dans un centre de données utilisant le cryptage de tokens à long terme. [0028] [fig.2B] décrit un système combinant le cryptage de tokens à court terme avec les sorties d'un centre de données utilisant le cryptage de tokens à long terme. [0029] [fig.3] décrit schématiquement à titre d'exemple comment le système de la Fig. 1 ne résulte pas en tokens conflictuels. [0030] [fig.4] décrit schématiquement à titre d'exemple comment le système de la Fig. 2A peut faire passer des tokens de réseau à travers une pluralité de routeurs. [0031] [fig.5] décrit graphiquement à titre d'exemple comment des tokens de stockage sont cohérents à travers les renouvellements de clé pour la tokenisation de réseau. [0032] [fig.6] décrit un organigramme illustrant un procédé exemplaire 600 pour mettre en oeuvre le cryptage à long terme pour stockage. [0033] [fig.7] décrit un organigramme illustrant un procédé exemplaire 700 pour mettre en oeuvre le cryptage à court terme pour utilisation dans un réseau. [0034] [fig.8] est un diagramme bloc d'un dispositif exemplaire avec lequel les systèmes, les procédés et les dispositifs de la présente invention peuvent être implémentés. [0035] Des modes de réalisation exemplaires seront maintenant discutés dans les détails en faisant référence aux dessins qui les accompagnent. Dans certains cas, les mêmes numéros de référence seront utilisés dans les dessins et dans la description suivante pour faire référence à une même partie ou à des parties similaires. À moins d'être définis autrement, les termes techniques et/ou scientifiques ont la signification couramment comprise par l'homme de métier. Les modes de réalisation divulgués sont décrits avec suffisamment de détails pour permettre aux hommes de métier de mettre en oeuvre les modes de réalisation divulgués. On comprendra que d'autres modes de réalisation peuvent être utilisés et que des changements peuvent être faits sans s'éloigner du champ d'application des modes de réalisation divulgués. Par conséquent, les supports, les procédés et les exemples sont uniquement des illustrations et n'ont pas vocation à être nécessairement limitatifs. [0036] Une application peut fournir des services aux utilisateurs et aux processeurs. Par exemple, une application peut fournir un portail aux utilisateurs pour saisir des informations pour une réservation d'hôtel (dans cet exemple, la compagnie hôtelière est le processeur). Dans un autre exemple, une application peut fournir un portail aux utilisateurs pour saisir des informations pour une transaction d'achat (dans cet exemple, le marchand et/ou un processeur de carte de crédit sont le processeur). Toute application de ce genre peut stocker les informations de l'utilisateur pour une récupération ultérieure. [0037] Cependant, ces informations peuvent faire l'objet de réglementations sécuritaires diverses (p. ex. des informations d'identification personnelle [Pli] ou d'autres informations soumises à la réglementation 2016/679 pour la protection des données générales [FDPR], ou d'autres réglementations). Les techniques de cryptage traditionnelles pour protéger ces informations stockées souffrent généralement d'une faible entropie ou d'un manque de réversibilité. Cependant, le cryptage à faible entropie expose les informations à une possibilité de piratage alors que le manque de réversibilité rend l'information inappropriée à la récupération et à la réutilisation. [0038] Les systèmes et les procédés envisagés peuvent fournir une tokenisation des données à long terme qui est à la fois à forte entropie et réversible. En outre, les modes de réa- 6 lisation de la présente divulgation peuvent aussi être déterministes pour éviter les conflits et éventuellement cohérents pour résoudre de quelconques conflits. Par exemple, les systèmes et les procédés envisagés peuvent crypter l'information pour stockage en utilisant une fonction de hachage clavetée. La fonction de hachage clavetée peut être obtenue à partir d'un système de gestion de clés (KMS) afin de synchroniser des centres de données différents à travers un même environnement dématérialisé. Dans certains aspects, les systèmes et des procédés envisagés peuvent aussi fournir un cryptage à court terme via un ou plusieurs dispositifs de tokenisation de réseau. Par exemple, les dispositifs de tokenisation de réseau peuvent utiliser une tokenisation à préservation de format avant dc fournir le token généré au centre(s) de données pour un cryptage de stockage à long terme. Le centre(s) dc données peut se synchroniser avec les dispositifs de tokenisation de réseau pour utiliser la même clé pour le cryptage à court terme. Dans certains modes de réalisation, les dispositifs de tokenisation de réseau peuvent aussi utiliser le salage et le centre(s) de données peut se synchroniser avec les dispositifs de tokenisation de réseau pour utiliser le même sel. Cette modification peut augmenter l'entropie de cryptage à court terme. [0039] Les systèmes et procédés envisagés améliorent les systèmes existants de tokenisation. Par exemple, les systèmes et procédés envisagés peuvent fournir des tokens réversibles qui sont toujours à forte entropie. De plus, le cryptage n'est pas limité au cryptage pour stockage réversible et à forte entropie et peut coopérer avec le cryptage pour transfert non déterministe et à faible entropie. Par contraste, les systèmes de tokenisation existants n'offrent pas la combinaison de la réversibilité et de la forte entropie fournie par les systèmes et procédés envisagés. Ces améliorations sont permises, au moins en partie, par l'architecture spécifique divulguée dans la présente. [0040] La Fig. 1 décrit un système 100 pour une tokenisation de stockage à long terme incluant des bases de données d'application en communication avec des stockages de données dans un environnement dématérialisé, conformément aux modes de réalisation divulgués. Une pluralité de dispositifs de tokenisation de stockage, p. ex. les dispositifs de tokenisation de stockage 101a et 101b peuvent être des dispositifs informatiques faisant partie d'une baie de serveurs ou autre collection de serveurs fournissant des services dématérialisés aux bases de données d'application 103a et 103b. Par conséquent, le dispositif de tokenisation de stockage 101a et la base de données d'application 103b peuvent former un premier centre de données, le dispositif de tokenisation de stockage 101b et la base de données 103b peuvent former un deuxième centre de données, et ainsi de suite. Une pluralité de stockages locaux, p. ex. les bases de données d'application 103a et 103b peuvent être des dispositifs informatiques abonnés, ou autrement utilisant, des services dématérialisés fournis par des dispositifs de tokenisation de stockage 101a et 101b. Les bases de données d'application 103a et 7 103b peuvent aussi être des dispositifs informatiques configurés pour répondre aux requêtes provenant d'un dispositif d'entrée 105 et d'un dispositif demandeur 107. Le dispositif d'entrée 105 et le dispositif demandeur 107 peuvent comprendre des dispositifs informatiques utilisés par des clients et des processeurs ou toute autre partie échangeant des informations qui nécessitent un cryptagc et un stockage. Le dispositif d'entrée 105 et le dispositif demandeur 107 peuvent se connecter à des bases de données d'application 103a et 103b à travers un ou plusieurs réseaux et les bases de données d'application 103a et 103b peuvent aussi se connecter à des dispositifs de tokenisation de stockage 101 a et 101b à travers un ou plusieurs réseaux. Le réseau(x) peut être tout type de réseau (incluant une infrastructure) qui fournit des communications, des échanges d'informations et/ou qui facilite l'échange d'informations, tel que r internet, un réseau à zone étendue (LAN) ou autre connexion(s) appropriée. De plus, les bases de données d'application 103a et 103b peuvent se synchroniser à travers un ou plusieurs réseaux et les dispositifs de tokenisation de stockage 101a et 101b peuvent aussi se synchroniser à travers un ou plusieurs réseaux. [0041] Le dispositif d'entrée 105 peut être configure pour envoyer une requête à une ap- plication en utilisant les bases de données d'application 103a. Dans certains modes de réalisation, la requête peut comprendre une identification (étiquetée « id » dans l'exemple de la Fig. 1 et comprenant, p. ex., un nom, un numéro de réservation, et autres données de ce genre) ainsi que des données sensibles (étiquetées 209 dans l'exemple de la Fig. 1 et comprenant, p. ex., un numéro de carte de crédit, un numéro de passeport ou autres données de ce genre). En réponse, l'application peut être configurée pour traiter la requête et fournir les données sensibles 109 pour stockage par le dispositif de tokenisation de stockage 101a. Le dispositif de tokenisation de stockage 101a peut ensuite renvoyer un token de stockage 113 à l'application qui peut stocker le token de stockage 113 en association avec l'id reçue. La base de données d'application 103a peut à son tour renvoyer une confirmation 115 au dispositif d'entrée 105. [0042] Le dispositif de tokenisation de stockage 101a peut tokeniser la requête en utilisant un algorithme à forte entropie. Par exemple, le dispositif de tokenisation de stockage 101a peut utiliser une fonction de hachage clavetée pour transformer la requête en un token. En outre, le dispositif de tokenisation de stockage 101a peut générer une entrée dans une base de données cryptée reliant le token à la requête. Par exemple, la base de données cryptée peut comprendre une mémoire de valeurs clés, tel qu'une base de données NoSQL ou autre stockage de ce genre. Comme illustré par ailleurs dans la Fig. 1, les dispositifs de tokenisation de stockage 101a et 101b peuvent se synchroniser et/ou les bases de données d'application 103a et 103b peuvent se synchroniser. Par exemple, un dispositif de tokenisation de stockage 101a peut transférer 8 le token généré et l'entrée de base de données correspondante vers le dispositif de tokenisation de stockage 101b pour stockage. De plus ou autrement, la base de données d'application 103a peut envoyer la requête à la base de données d'application 103b pour traitement et stockage avec le dispositif de tokenisation de stockage 101b. [0043] Le dispositif d'entrée 107 peut être configure pour envoyer une requête à une ap- plication en utilisant la base de données d'application 103b. Par exemple, la requête peut comprendre une identification (étiquetée « id » dans l'exemple de la Fig. 1 et comprenant, p. ex., un nom, un numéro de réservation et autre données de cc genre). De plus ou autrement, la requête peut comprendre des données sensibles 109. En réponse, l'application peut être configurée pour traiter la requête et fournir un token de stockage associé 123 pour récupération au dispositif de tokenisation de stockage 101b. Par exemple, le token de stockage 123 peut comprendre une copie du token de stockage 1 1 3 dupliqué dans la base de données d'application 103b dans le deuxième centre de données pour utilisation par les dispositifs connectés à une application dans le deuxième centre de données plutôt qu'à une application dans le premier centre de données. Le dispositif de tokenisation de stockage 101b peut ensuite renvoyer les données demandées (p. ex., les données sensibles 109) à la base de données d'application 103b pour traitement par l'application. À son tour, l'application peut renvoyer les données demandées (p. ex., les données sensibles 109) au dispositif demandeur 107. [0044] La Fig. 2A décrit un système 200 qui utilise la tokenisation de réseau à court terme en combinaison avec la tokenisation de stockage à long terme conformément aux modes de réalisation divulgués. De façon similaire aux dispositifs de tokenisation de stockage 101a et 101b, le dispositif de tokenisation de stockage 213 peut être un dispositif informatique faisant partie d'une baie de serveurs ou autre collection de serveurs fournissant des services dématérialisés aux bases de données à l'application 211. De façon similaire aux applications utilisant les bases de données d'application 103a et 103b, l'application 211 peut être un dispositif infonnatique abonné à, ou utilisant autrement, des services dématérialisés fournis par un dispositif de tokenisation de stockage 213 et qui est configurée pour répondre aux requêtes provenant du dispositif d'entrée 209. De façon similaire au dispositif d'entrée 105, le dispositif d'entrée 209 peut comprendre des dispositifs informatiques utilisés par des clients ou tous autres tiers fournissant des données sensibles (p. ex., un numéro de carte de crédit, un numéro de passeport ou autres données de ce genre) nécessitant un stockage et une récupération ultérieure. Le dispositif d'entrée 209 peut se connecter à l'application 211 à travers un ou plusieurs réseaux en utilisant le routeur 203 et application 211 peut aussi se connecter à des dispositifs de tokenisation de stockage 213 à travers un ou plusieurs réseaux. Le réseau(x) peut être tout type de réseau (incluant 9 une infrastructure) qui fournit des communications, des échanges d'informations et/ou qui facilite l'échange d'informations, tel que l'internet, un réseau à zone étendue (LAN) ou autre connexion(s) appropriée. [0045] Le dispositif d'entrée 209 peut être configure pour envoyer une requête à l'application 211 via le routeur 203. De façon similaire à l'exemple de la Fig.1, la requête peut comprendre une identification (étiquetée « id » dans l'exemple de la Fig. 2 et comprendre, p. ex., un nom, un numéro de réservation ou autre données de ce genre). De plus ou autrement, la requête peut comprendre des données sensibles 205. En route, le routeur 203 peut utiliser le dispositif de tokenisation 201 pour générer un token de réseau 207 pour usage à la place des données sensibles 205. Par exemple, le token de réseau 207 peut être généré en utilisant un cryptage asymétrique et peut, par exemple, être réversible. Toute technique de tokenisation réversible de tokens, telle que les techniques à préservation de format, peut être utilisée. Dans certains modes de réalisation, le dispositif de tokenisation de réseau 201 peut utiliser un sel pour augmenter encore plus l'entropie du token de réseau 207. Par exemple, le dispositif de tokenisation de réseau 201 peut ajouter du sel aux données sensibles 205 avant de générer le token de réseau 207. Le token de réseau 207 peut aussi avoir une échéance (p. ex., quelques secondes, quelques minutes, quelques heures, quelques jours, et ainsi de suite). Dans certains modes de réalisation, l'échéance peut être connue uniquement de l'application 211. [0046] Bien que l'illustration soit basée sur une implémentation par le routeur 203, tout autre composant du système 200, ou en communication avec celui-ci, peut implémenter le dispositif de tokenisation de réseau 201. Par exemple, le dispositif de tokenisation de réseau 201 peut comprendre un serveur ou autre dispositif informatique faisant partie du système 200 ou étant au moins en communication avec celui-ci. De plus ou autrement, le routeur 203 peut implémenter le dispositif de tokenisation de réseau 201 en communiquant avec un serveur comprenant le dispositif de tokenisation de réseau 201 plutôt qu'en exécutant des instructions pour implémenter le dispositif de tokenisation de réseau 201 directement. [0047] En réponse, l'application 211 peut être configurée pour traiter le token de réseau 207 et fournir le token de réseau 207 pour stockage au dispositif de tokenisation de stockage 213. Le dispositif de tokenisation de stockage 213 peut avoir une clé privée du dispositif de tokenisation de réseau 201 afin de décrypter le token de réseau 207 avant d'utiliser une fonction de hachage clavetée pour transformer les données sensibles décryptées 205 dans un token différent (p. ex. de stockage) et générer une entrée dans une base de données cryptée reliant le nouveau token de stockage aux données sensibles décryptées. Le dispositif de tokenisation de stockage 213 peut ensuite renvoyer le token de stockage 215 à l'application 211 qui peut à son tour stocker le token 215 (avec l'identification, dans les modes de réalisation incluant l'identification) dans une base de données d'application. La base de données d'application peut renvoyer une confirmation à l'application 211 qui peut à son tour renvoyer la confirmation au routeur 203 et/ou au dispositif d'entrée 209. [0048] La Fig. 2B décrit un système 250 qui utilise la tokenisation de réseau à court ternie en combinaison avec la tokenisation de stockage à long ternie, conformément aux modes de réalisation divulgués. De façon similaire aux dispositifs de tokenisation 101a et 101b, le dispositif de tokenisation de stockage 263 peut être un dispositif informatique faisant partie d'une baie de serveurs ou autre collection de serveurs fournissant des services dématérialisés à l'application 261. De façon similaire aux applications utilisant les bases de données d'application 103a et 103b, l'application 261 peut être un dispositif informatique abonné à, ou utilisant autrement, des services dématérialisés fournis par un dispositif de tokenisation de stockage 263 et qui est configure pour répondre aux requêtes provenant du dispositif d'entrée 259. De façon similaire au dispositif demandeur 107, le dispositif demandeur 259 peut comprendre des dispositifs informatiques utilisés par des clients ou tous autres tiers échangeant des informations qui nécessitent un cryptagc et un stockage. Le dispositif demandeur 259 peut se connecter à l'application 261 à travers un ou plusieurs réseaux en utilisant le routeur 253 et application 261 peut aussi se connecter à des dispositifs de tokenisation de stockage 263 à travers un ou plusieurs réseaux. Le réseau(x) peut être tout type de réseau (incluant une infrastructure) qui fournit des communications, des échanges d'informations et/ou qui facilite l'échange d'informations, tel que l'intemet, un réseau à zone étendue (LAN) ou autre connexion(s) appropriée. [0049] Le dispositif demandeur 259 peut aussi être configuré pour envoyer une requête à l'application 261 via le routeur 253. Par exemple, la requête peut inclure une identification (p. ex., étiquetée « id» dans les exemples de la Fig. 1 et 2A) associée à des données sensibles 265 qui ont été tokenisées et stockées. Le routeur 253 peut transmettre l'identification à l'application 261 pour traitement. [0050] En réponse, l'application 261 peut être configurée pour récupérer le token de stockage 257 à partir d'une base de données correspondante en utilisant l'identification. En outre, l'application 261 peut fournir le token de stockage 257 au dispositif de tokenisation de stockage 263 pour récupération des données sensibles correspondantes 265. Par exemple, de façon similaire aux données sensibles 109 de la Fig. 1 et aux données sensibles 205 de la Fig. 2A, les données sensibles 265 de la Fig. 2B peuvent comprendre un numéro de carte de crédit, un numéro de passeport ou autres données de ce genre. Le dispositif de tokenisation de stockage 263 peut ensuite renvoyer les données sensibles 265 à l'application 261 qui à son tour transmet les données sensibles 265 au dispositif demandeur 259 via le routeur 253. De plus ou 11 autrement, comme illustrée dans la Fig. 2B, l'application 261 peut transmettre les données sensibles 265 à un autre dispositif (p. ex., à un processeur d'information tel que Visa@ ou à un autre processeur de carte de crédit, aux services des douanes et de contrôle des frontières américaines [CBP] ou à un autre processeur de sécurité nationale, à un système d'une organisation de crédit équitable [Fair Isaac Crcdit Organization (FICO)] ou à un autre processeur de notation de crédit, ou à une autre entité de ce genre). Bien que cc ne soit pas illustré dans la Fig. 2B, le dispositif de tokenisation 263 peut générer un token de réseau basé sur des données sensibles 265 et renvoyer le token de réseau à l'application 261 plutôt que de renvoyer les données sensibles 265 directement. [0051] Par conséquent, comme c'est illustré dans la Fig. 2B, l'application 261 peut utiliser une tokenisation de réseau pour protéger les données sensibles 265 telles qu'elles sont envoyées par le processeur de données. En chemin, le routeur 253 peut utiliser le dispositif de tokenisation 251 pour générer un token de réseau 267 pour usage à la place des données sensibles 265. Le token 267 peut être généré en utilisant un cryptage asymétrique ou tout autre cryptage réversible. Le cryptage réversible peut, par exemple, préserver les formats. Dans certains modes de réalisation, le dispositif de tokenisation de réseau 251 peut utiliser un sel pour augmenter encore l'entropie du token de réseau 267. Par exemple, le dispositif de tokenisation de réseau 251 peut saler les données sensibles 265 avant le cryptage des données salées en token de réseau 267. Le token de réseau 267 peut aussi avoir une échéance (p. ex., quelques secondes, quelques minutes, quelques heures, quelques jours, et ainsi de suite). Dans certains modes de réalisation, l'échéance peut être connue uniquement par l'application 261. [0052] De façon similaire au routeur, 203, tout autre composant du système 250, ou en com- munication avec celui-ci, peut implémenter le dispositif de tokenisation de réseau 251. Par exemple, le dispositif de tokenisation de réseau 251 peut comprendre un serveur ou autre dispositif informatique faisant partie du système 250 ou étant au moins en communication avec celui-ci. De plus ou autrement, le routeur 253 peut implémenter le dispositif de tokenisation de réseau 251 en communiquant avec un serveur comprenant le dispositif de tokenisation de réseau 251 plutôt qu'en exécutant des instructions pour implémenter le dispositif de tokenisation de réseau 251 directement. [0053] Le processeur d'information peut ensuite décrypter le token de réseau 267 (et, dans certains modes de réalisation, dessaler les données en résultant) afin de finir le traitement des données sensibles 265 (p. ex. en complétant une transaction, en effectuant un contrôle ou vérification d'antécédents, en fournissant une notation de crédit ou autre information confidentielle à un tiers demandeur, ou autre tierce partie de ce genre). Dans certains modes de réalisation, comme illustré dans la Fig. 2B, le processeur d'information peut fournir une confirmation à l'application 261 et/ou au 12 dispositif demandeur 259. [0054] Les systèmes 200 et 250 peuvent être combinés afin de fournir un mode de réa- lisation du système 100 de la Fig. 1 avec un cryptage de bout en bout. Par exemple, toutes données sensibles incluses dans les demandes où étant renvoyées aux dispositifs et/ou aux processeurs d'informations sur les réseaux peuvent être cryptées en utilisant les dispositifs de tokenisation de réseau (p. ex., les dispositifs de tokenisation 201 et 251) alors que le cryptage de stockage continue à fournir un cryptage à forte entropie qui reste réversible et déterministe. [0055] Un avantage technique de cc cryptage de stockage est illustré dans la Fig. 3. Dans la Fig. 3, deux dispositifs d'entrée (p. ex. les dispositifs d'entrée 309a et 309b) peuvent envoyer des requêtes (p. ex. les requêtes 307a et 307b) qui sont liées au même individu, à la même carte de crédit ou à d'autres portions des données sensibles. Cependant, les requêtes 307a et 307b peuvent être envoyées à partir de divers centres de données (p. ex., les centres de données 301 a et 301b respectivement) dans un environnement dématérialisé. [0056] Si les centres de données 301a et 301b cryptent séparément, alors les enregistrements correspondants dans leur base de données seront indexés sur des tokens distincts. Par conséquent, un système de gestion de clés (KMS) 303 peut distribuer la clé 305 aux centres de données 301a et 301b en assurant que les tokens générés, basés sur le même individu, la même carte de crédit ou autres portions des données sensibles, sont cohérents les uns avec les autres et ne résultent pas en enregistrements conflictuels. L'utilisation de cryptage déterministe à des fins de stockage évite donc des problèmes avec des systèmes de cryptage à forte entropie, tels que ceux qui reposent sur le salage et autres propriétés non déterministes. En outre, en combinaison avec la tokenisation de réseau non déterministe (p. ex. telle qu'illustrée dans les Figs. 2A et 2B), les tokens de stockage peuvent être conservés de façon encore plus sécurisée en assurant que seuls les tokens non déterministes puissent être interceptés sur les réseaux. [0057] La Fig. 4 illustre un système 400 configuré pour distribuer un des tokens de réseau de la Fig. 2A à travers une pluralité de composants. De façon similaire à la Fig. 2A, le dispositif d'entrée 401 peut être configuré pour envoyer une requête incluant des données sensibles 403 à l'application 411a via le routeur 405a. En chemin, le routeur 405a peut utiliser le dispositif de tokenisation de réseau 407a pour générer un token de réseau 409 pour usage à la place des données sensibles 403. Le token de réseau 409 peut être généré en utilisant un cryptage asymétrique ou toute autre technique de tokenisation réversible. La technique de tokenisation réversible peut être, par exemple, à préservation de formats. Dans certains modes de réalisation, le dispositif de tokenisation de réseau 407a peut utiliser un sel pour augmenter encore plus l'entropie du token de réseau 409. Par exemple, le dispositif de tokenisation de 13 réseau 407a peut ajouter le sel aux données sensibles 403 avant la tokenisation. Le token de réseau 409 peut aussi avoir une échéance (p. ex., quelques secondes, quelques minutes, quelques heures, quelques jours, et ainsi de suite). Dans certains modes de réalisation, l'échéance peut être connue uniquement des applications 411a et 411b. [0058] En réponse, l'application 411a peut être configurée pour traiter le token de réseau 409 et fournir le token de réseau 409 pour stockage par le dispositif de tokenisation de stockage 413. Le dispositif de tokenisation de stockage 413 peut avoir une clé privée du dispositif de tokenisation de réseau 407a afin de décrypter le token de réseau 409 avant utiliser une fonction de hachage clavetée pour transformer les données sensibles décryptées en un token différent (p. ex. de stockage) et générer une entrée dans une base de données crypte° reliant le nouveau token de stockage aux données sensibles décryptées. Le dispositif de tokenisation de stockage 413 peut ensuite renvoyer le token de stockage 415 à l'application 411a, p. ex. pour traitement et/ou pour stockage. [0059] De plus, l'application 411a peut aussi transmettre un token de réseau 409 pour un autre traitement par l'application 411b. Par exemple, comme illustré dans la Fig. 4, le token de réseau 409 peut être envoyé via le routeur 405b à l'application 411b. Du fait que le token de réseau 409 est déjà crypte, le routeur 405b n'a plus besoin de crypter par ailleurs le token de réseau 409. [0060] En réponse, l'application 41111 peut traiter le token de réseau 409. Par conséquent, l'application 411b peut aussi avoir une clé privée du dispositif de tokenisation de réseau 407a afin de décrypter le token de réseau 409 et de traiter les données sensibles 403 selon le besoin. De plus ou autrement, l'application 411b peut transmettre le token de réseau 409 pour un autre traitement par un autre dispositif d'entrée 417. Par exemple, comme illustré dans la Fig. 4, le token de réseau 409 peut être envoyé via le routeur 405c au dispositif d'entrée 417. Du fait que le dispositif d'entrée 417 requiert des données sensibles 403 et que le token de réseau 409 est crypte', le routeur 405c peut utiliser le dispositif de tokenisation de réseau 407b pour décrypter le token de réseau 409. Par exemple, le dispositif de tokenisation de réseau 407b peut synchroniser des clés (et dans certains modes de réalisation, des sels) avec le dispositif de tokenisation de réseau 407a afin de décrypter le token de réseau 409. Le système 400, tel qu'il est illustré dans la Fig. 4 permet ainsi un stockage sécurisé et le transfert de requêtes à travers un réseau simultanément. [0061] La Fig. 5 fournit un exemple graphique illustrant comment des tokens de stockage sont cohérents à travers les renouvellements de clé pour la tokenisation de réseau, conformément aux modes de réalisation révélés. Comme le montre la Fig. 5, et de façon similaire à la Fig. 1, le dispositif d'entrée 501 peut fournir des données sensibles 503 (p. ex. incluses dans une requête) via un routeur 505. Bien que non 14 illustré dans la Fig. 5, le routeur 505 peut utiliser un dispositif de tokenisation de réseau sur des données sensibles 503 pour générer un token de réseau 507a. L'application 509 peut traiter le token de réseau 507a (p. ex. en utilisant une clé du dispositif de tokenisation de réseau pour décrypter le token de réseau 507a et traiter les données sensibles 503, selon le besoin) et fournir la même chose au gestionnaire de stockage 511 pour un stockage sécurisé sur la base de données 515. Par exemple, le gestionnaire de stockage 511 et la base de données 515 peuvent comprendre ensemble un dispositif de tokenisation de stockage (p. ex. similaire au dispositif de tokenisation de stockage 101a ou 101b de la Fig. 1). Par conséquent, le gestionnaire de stockage 511 peut décrypter le token de réseau 507a avant d'appliquer une fonction de hachage clavetée aux données décryptées (comprenant les données sensibles 503) pour générer le token de stockage 513 pour le stockage. Dans certains modes de réalisation, le dispositif de tokenisation de réseau peut aussi saler les données sensibles 503 avant la tokenisation. Dans ces modes de réalisation, le gestionnaire de stockage 511 peut dessaler les données décryptées avant de générer le token de stockage 513. [0062] Le même token de stockage 513 sera généré pour les mêmes données sensibles (dans cet exemple les données sensibles 503) même lorsque le dispositif de tokenisation de réseau utilisé par le routeur 505 renouvelle sa clé de cryptagc. Par exemple, les données sensibles 503 peuvent maintenant être transformées en token de réseau 507b en utilisant la nouvelle clé plutôt que le token de réseau 507a. Cependant, le gestionnaire de stockage 511 peut aussi renouveler sa clé (et, dans certains modes de réalisation, son sel) lorsque le dispositif de tokenisation de réseau utilisé par le routeur 505 renouvelle sa clé afin de décrypter (et, dans certains modes de réalisation, de dessaler) le token de réseau 507b et générer le même token de stockage 513 basé sur les mêmes données décryptées (comprenant les données sensibles 503). Par conséquent, l'exemple 500 décrit comment la résolution de conflit peut être préservée même lorsque la tokenisation de réseau non déterministe (p. ex., décrite dans les Figs. 2A et 2B) est incorporée dans la tokenisation de stockage décrite dans la présente divulgation. [0063] La Fig. 6 décrit un organigramme illustrant un procédé exemplaire 600 pour tokeniser des données de stockage dans un environnement dématérialisé, conforme aux modes de réalisation divulgués. Dans certains modes de réalisation, le procédé 600 peut inclure des étapes de réception d'entrée et une fonction de hachage clavetée, en générant un token pour l'entrée, en créant une entrée de base de données reliant le token à l'entrée et en fixant et appliquant une échéance au token. Comme le reconnaîtra l'homme de métier, cette séquence particulière d'étapes n'a pas vocation à être limitative. Les étapes du procédé 600 peuvent être combinées ou divisées et le procédé 600 peut inclure des étapes supplémentaires ou un plus petit nombre d'étapes sans s'écarter des modes de réalisation envisagés. Le procédé 600 peut être exécuté par au moins un processeur (p. ex., le processeur(s) 801a et/ou 80111 du dispositif 800 de la Fig. 8). Par exemple, ledit au moins un processeur peut exécuter les instructions stockées sur au moins une mémoire non transitoire et ledit au moins un processeur et ladite au moins une mémoire non transitoire peuvent être répartis dans un environnement dématérialisé. [0064] Après avoir débuté à l'étape 601, le système peut être configuré pour recevoir des entrées devant être tokenisées à l'étape 603. Par exemple, comme cela a été exposé ci-dessus, l'entrée peut comprendre des données sensibles, telles qu'un numéro de passeport, une carte de crédit, un numéro de sécurité sociale ou toutes autres données sensibles, pour un stockage et par la suite une récupération. Dans certains modes de réalisation, l'entrée peut être incluse dans une requête plus large, telle qu'une requête pour une réservation, pour un contrôle ou vérification d'antécédents et ainsi de suite. De plus ou autrement, l'entrée peut comprendre un token de réseau généré par un dispositif de tokenisation de réseau en communication avec le système. Par exemple, comme cela a été exposé ci-dessus par rapport à la Fig. 2A, le dispositif de tokenisation de réseau peut crypter les données sensibles avant la transmission au système. Dans ces modes de réalisation, le dispositif de tokenisation de réseau peut générer le token de réseau en utilisant la tokenisation réversible, telle qu'un cryptage à préservation de formats ou tout autre technique de tokenisation réversible. Cette tokenisation réversible peut être asymétrique de sorte que la clé publique utilisée par le routeur pour crypter est distincte d'une clé privée utilisée pour décrypter. Dans d'autres modes de réalisation, la tokenisation réversible peut être symétrique. [0065] Dans des modes de réalisation dans lesquels l'entrée comprend le token de réseau, le système peut être configuré par ailleurs pour obtenir une clé correspondant à une clé utilisée par le dispositif de tokenisation de réseau pour générer le token de réseau et, en utilisant de la clé correspondante, pour décoder le token de réseau avant de générer un token en utilisant la fonction de hachage clavetée à l'étape 605. Par conséquent, dans des modes de réalisation asymétriques, la clé utilisée par le dispositif de tokenisation de réseau peut comprendre la clé publique et la clé correspondante peut comprendre la clé privée. Dans des modes de réalisation symétriques, la clé utilisée par le dispositif de tokenisation de réseau peut comprendre la clé correspondante. Dans l'un ou l'autre de ces modes de réalisation, le système peut aussi être configuré pour renouveler périodiquement la clé correspondante, p. ex., en s'autoauthentifiant auprès d'un système de gestion de clés (KMS). Le système peut s'autoauthentifier en utilisant un mot de passe ou autre authentifiant en utilisant un certificat numérique ou autre authentifiant similaire. [0066] Dans des modes de réalisation dans lesquels l'entrée comprend le token de réseau, le 16 dispositif de tokenisation de réseau peut saler les données sensibles avant de générer le token. Par exemple, le sel peut comprendre un ou plusieurs caractères aléatoires ajoutes aux données sensibles avant la tokenisation ou ajoutés au token pour finaliser le token. Par conséquent, le système peut aussi être configure pour obtenir le sel utilise par le dispositif de tokenisation de réseau et pour retirer le sel du token de réseau décodé avant de générer un token de stockage en utilisant la fonction de hachage clavetée à l'étape 605. Par exemple, le système peut retirer le sel du token de réseau afin d'assurer que la propriété de clé correspondante décode le token de réseau et/ou peut retirer le sel du token de réseau décode afin d'assurer que la propriété de l' information décodée corresponde aux données sensibles. [0067] Dans des modes de réalisation incluant un dispositif de tokenisation de réseau, le système peut aussi être configure pour authentifier le dispositif de tokenisation de réseau avant d'accepter l'entrée. Le système peut s'autoauthentifier en utilisant un mot de passe ou d'autres authentifiants, en utilisant un certificat numérique, ou autre authentifiant similaire. [0068] Dans certains modes de réalisation, le système peut aussi être configure pour obtenir une fonction de hachage clavetée à partir d'un système de gestion de clés à l'étape 603. Par exemple, le système peut s'autoauthentifier auprès du système de gestion de clés à l'étape 603. Le système peut s'autoauthentifier en utilisant un mot de passe ou d'autres authentifiants, en utilisant un certificat numérique, ou autre authentifiant similaire. Dans des modes de réalisation dans lesquels le système obtient aussi une clé correspondant à une clé utilisée par le dispositif de tokenisation de réseau pour générer le token de réseau, le système de gestion de clés qui distribue la fonction de hachage clavetée peut comprendre le même système de gestion de clés qui distribue la clé correspondante ou un système de gestion de clés différent. De plus ou autrement, la fonction de hachage clavetée peut être récupérée à partir du stockage, p. ex. localement dans le système, ou situé sur un serveur distant. Dans des modes de réalisation dans lesquels la fonction de hachage clavetée est récupérée dans le stockage distant, le système peut s'autoauthentifier en utilisant un mot de passe, ou d'autres authentifiants, en utilisant un certificat numérique, ou autre authentifiant de ce genre. [0069] Après l'étape 603, le système peut être configure pour utiliser la fonction de hachage clavetée afin de générer un token de stockage pour l'entrée à l'étape 605. Par exemple, le système peut soumettre l'entrée (ou, dans certains modes de réalisation dans lesquels l'entrée comprend un token de réseau, le token d'entrée décodé) directement à la fonction de hachage clavetée. Dans d'autres modes de réalisation, comme cela a été expliqué ci-dessus, le système peut extraire les données sensibles comprenant l'entrée (p. ex., un nom, une carte de crédit, un numéro d'identification, ou autres données de ce genre) d'une requête globale qui inclut l'entrée, et soumettre la portion extraite à la 17 fonction de hachage clavetée. [0070] Après l'étape 605, le système peut être configure pour créer une entrée dc base de données cryptée reliant le token de stockage à l'entrée reçue à l'étape 607. Par exemple, la base de données peut être indexée par les tokens de stockage générés à partir de la fonction de hachage clavetée et fournir les données sensibles en réponse à une requête autorisée incluant le token de stockage. Dans certains modes dc réalisation, la base de données peut comprendre une mémoire dc valeurs clés, tel qu'une base de données NoSQL, telle qu'une base de données ArangoDB, une base de données Oracle® NoSQL, ou autre base de données similaire. La base de données elle-même peut être cryptée (p. ex. en utilisant une clé) et/ou des entrées dans la base de données peuvent être cryptées (p. ex. en utilisant une ou plusieurs clés. [0071] Dans certains modes de réalisation, le système peut aussi être configure pour syn- chroniser l'entrée de base de données cryptée à travers un ou plusieurs serveurs. Par conséquent, la base dc données peut comprendre une base dc données distribuée. Dans ces modes de réalisation, le système peut aussi être configure pour authentifier ledit un ou plusieurs serveurs avant la duplication. Le système peut authentifier ledit un ou plusieurs serveurs en utilisant un mot dc passe ou d'autres authentifiants, en utilisant un certificat numérique ou autre authentification similaire. [0072] La duplication de la base de données cryptée peut permettre la reprise en cas de système sinistré. Par exemple, lorsque la base de données est défaillante, le système peut être configure par ailleurs pour récupérer des entrées de la base de données cryptée à partir d'un ou de plusieurs serveurs et pour reconstruire la base de données cryptée en utilisant les entrées récupérées. Dans ces modes de réalisation, le système peut aussi être configure pour authentifier ledit un ou plusieurs serveurs avant de récupérer des entrées, de la façon expliquée ci-dessus. [0073] Après l'étape 607, le système peut être configure pour fixer une échéance pour le token de stockage à l'étape 609. Par exemple, si l'entrée comprend au moins une portion d'une réservation, l'échéance peut être fixée sur la base d'une date de réservation (p. ex., le jour même, le jour après, ou autre échéance de ce type). Dans un autre exemple non limitatif, si l'entrée comprend au moins une portion d'une transaction, l'échéance peut être fixée sur la base d'un horaire estimé pour la finalisation de la transaction (p. ex. 3 jours ouvrés, 5 jours ouvrés, ou autre délai de ce genre). Dans certains modes de réalisation, le système peut aussi être configure pour fournir l'entrée liée en réponse à la réception du token de stockage avant l'échéance, à l'étape 609. Par conséquent, le système peut appliquer l'échéance en bloquant l'accès aux données sensibles après l'expiration du token. [0074] Dans un quelconque des modes de réalisation ci-dessus, l'entrée peut être reçue à partir d'une première application et le token de stockage peut être reçu avant 18 l'échéance à partir d'une deuxième application. Par exemple, l'entrée peut comprendre un token de réseau généré par un dispositif de tokenisation de réseau en communication avec le système et une échéance du token de réseau peut être connue uniquement de la première application. Autrement, l'entrée peut comprendre un token de réseau généré par un dispositif de tokenisation de réseau en communication avec le système et une échéance du token de réseau peut être connue de la première application et de la deuxième application. [0075] Le procédé 600 peut par ailleurs inclure des étapes supplémentaires qui ne sont pas illustrées dans la Fig. 6. Par exemple, le procédé 600 peut utiliser des dispositifs de tokenisation de réseau pour gérer une quelconque panne du système. Par exemple, lorsque la base de données est en dysfonctionnement, le système peut être configuré pour distribuer la fonction de hachage clavetée à un dispositif de tokenisation de réseau en communication avec le système et, lorsque la base de données fonctionne, pour recevoir le token de stockage du dispositif de tokenisation de réseau généré en utilisant la fonction de hachage clavetée. Un dysfonctionnement peut inclure une quelconque erreur d'indexation, une erreur de dépassement de capacité ou toute autre erreur telle que des entrées qui ne sont pas récupérables dans la base de données. Dans ces modes de réalisation, le système peut aussi être configuré pour authentifier le dispositif de tokenisation de réseau avant de distribuer la fonction de hachage clavetée. Le dispositif de tokenisation de réseau peut s'autoauthentifier en utilisant un mot de passe ou d'autres authentifiants, en utilisant un certificat numérique ou autre authentification de ce genre. [0076] De plus ou autrement, le procédé 600 peut utiliser des antémémoires pour gérer les pannes par le système. Par exemple, l'entrée peut comprendre un token de réseau généré par un dispositif de tokenisation de réseau en communication avec le système et le système peut par ailleurs être configuré pour, lorsque la base de données est défaillante, stocker l'entrée dans une antémémoire. Ensuite, lorsque la base de données fonctionne, le système peut par ailleurs être configuré pour décoder le token de réseau et procéder à la génération d'un token de stockage en utilisant la fonction de hachage clavetée. Dans ces modes de réalisation, l'antémémoire peut comprendre un stockage crypté. Par exemple, l'antémémoire peut inclure un lac de données ou autre stockage non structuré qui est protégé par un mot de passe ou d'autres authentifiants, un certificat, ou autre authentification de ce genre. [0077] Dans certains modes de réalisation, le système peut recevoir une identification avec les données sensibles. Dans ces modes de réalisation, le système peut aussi stocker l'identification avec le token de stockage. Par exemple, le système peut stocker l'identification et le token de stockage dans une base de données d'application (p. ex., la base de données (l'application 103a ou 103b). Par conséquent, si l'identification est 19 fournie au système (p. ex., avant l'échéance du token de stockage), le système peut récupérer le token de stockage dans la base de données d'application. Cela peut permettre au système d'effectuer tout autre traitement sur le token de stockage et/ d'obtenir les données sensibles correspondant au token de stockage. [0078] Le procédé 600 peut permettre une tokcnisation des données sensibles dénuée de conflits, p. ex., comme illustrée dans la Fig. 3. Par conséquent, dans un exemple non limitatif, un processeur différent de l'environnement dématérialisé incluant le système peut recevoir une deuxième entrée devant être tokenisée, en obtenant la fonction de hachage clavetée du système de gestion de clés et utiliser la fonction de hachage clavetée pour générer un deuxième token dc stockage pour l'entrée. Tant que l'entrée est la même, le deuxième token de stockage généré par le processeur différent sera le même que le token de stockage généré par le système empêchant des conflits à travers les centres de données de l'environnement dématérialisé. [0079] La Fig. 7 décrit un organigramme illustrant un procédé 700 pour utiliser une toke- nisation de réseau dans un environnement dématérialisé, conforme aux modes de réalisation divulgués. Dans certains modes de réalisation, le procédé 700 peut inclure des étapes de réception d'entrée pour le stockage, en utilisant un cryptage à préservation de format pour remplacer l'entrée avec un token, en fixant une échéance pour le token et en passant le token à une application pour stockage. Comme le reconnaîtra l'homme de métier, cette séquence particulière d'étapes n'a pas vocation à être exhaustive. Les étapes du procédé 700 peuvent être combinées ou divisées et le procédé 700 peut inclure des étapes supplémentaires ou un plus petit nombre d'étapes sans s'écarter des modes de réalisation envisagés. Le procédé 700 peut être exécuté par au moins un processeur (p. ex., le processeur(s) 801a et/ou 801b du dispositif 800 de la Fig. 8). [0080] Après le début de l'étape 701, le système peut être configuré pour recevoir des données sensibles devant être stockées à l'étape 703. Par exemple, comme cela a été exposé ci-dessus, les données sensibles peuvent comprendre un numéro de passeport, une carte de crédit, un numéro de sécurité sociale ou toutes autres données sensibles, pour un stockage et par la suite une récupération. Dans certains modes de réalisation, les données sensibles peuvent être incluses dans une requête plus large, telle qu'une requête pour une réservation, pour un contrôle ou vérification d'antécédents et ainsi de suite. Une ou plusieurs applications peuvent être des réceptacles prévus de l'entrée pour traitement et pour stockage. Par conséquent, le système peut comprendre un centre de réseau ou autre intermédiaire configuré pour tokeniser l'entrée avant le traitement et le stockage [0081] Dans certains modes de réalisation, le système peut aussi être configuré pour re- nouveler une clé pour un cryptage asymétrique à l'étape 703. Autrement, le système peut être configuré pour renouveler une clé pour un cryptage symétrique à l'étape 703. Dans l'un ou l'autre de ces modes de réalisation, le système peut renouveler la clé en s'autoauthentifiant auprès d'un système de gestion de clés (KMS). Le système peut s'autoauthentifier en utilisant un mot de passe ou d'autres identifiants, en utilisant un certificat numérique, ou autre protection de ce genre. [0082] Après l'étape 703, le système peut être configure pour utiliser la tokenisation ré- versible afin de remplacer l'entrée par un token à l'étape 705. Par exemple, le système peut utiliser la clé (qu'elle soit une clé publique dans une paire de clés asymétriques ou une clé symétrique) pour crypter les données sensibles en token. Dans certains modes de réalisation, le système peut recevoir les données sensibles directement comme entrée. Dans d'autres modes de réalisation, le système peut extraire les données sensibles d'une requête globale comprenant l'entrée et soumettre la portion extraite aux clés. [0083] Après l'étape 705, le système peut être configure pour fixer une échéance pour le token de stockage à l'étape 707. Dans certains modes de réalisation, l'échéance peut être limitée à des composants particuliers du système. Par exemple, l'échéance peut être connue uniquement d'une ou de plusieurs applications configurécs pour traiter le token. De plus ou autrement, l'échéance peut être connue d'un ou de plusieurs centres de données configurés pour décoder le token et recrypter l'entrée pour un stockage à long terme. [0084] Après l'étape 707, le système peut être configure pour remplacer les données sensibles par le token à l'intérieur d'un message, p. ex., adressé à une application pour stockage, à l'étape 709. Par exemple, le message peut comprendre une requête globale comprenant l'entrée (comme décrit ci-dessus) avec les données sensibles remplacées par le token. De plus ou autrement, le message peut comprendre une enveloppe pour le token. Dans un quelconque de ces modes de réalisation, le système peut transmettre le token à travers un ou plusieurs réseaux, p. ex., en transmettant le message à travers ledit un ou plusieurs réseaux. Le réseau (x) peut être tout type de réseau (incluant une infrastructure) qui fournit des communications, des échanges d'informations et/ou qui facilite l'échange d'informations, tel que l'internet, un réseau à zone étendue (LAN) ou autre connexion(s) appropriée. [0085] Dans certains modes de réalisation, les procédés 600 et 700 peuvent fonctionner sur les mêmes dispositifs informatiques. Par exemple, les procédés 600 et 700 peuvent tous deux être fournis par un ou plusieurs serveurs d'un environnement dématérialisé (p. ex., les dispositifs de tokenisation 101a et 101b). Dans d'autres modes de réalisation, le procédé 600 peut être fourni par un ou plusieurs serveurs d'un environnement dématérialisé (p. ex., les dispositifs de tokenisation de stockage 101a et 101b) alors que le procédé 700 peut être fourni par un ou plusieurs serveurs de l'environnement dématérialisé (p. ex., les dispositifs de tokenisation de réseau 201 et 21 251) et/ou par les centres de réseaux (p. ex., le routeur 505) en communication avec l'environnement dématérialisé et/ou avec des applications accédant à l'environnement dématérialisé. [0086] La divulgation qui précède décrit des modes de réalisation d'un système pour la toke- nisation de stockage de données sensibles. Un tel système peut généralement être utilisé avec des applications connectées à un environnement dématérialisé de la façon décrite dans la Fig. 1. Par exemple, une application peut être configuree pour traiter des réservations d'un client en utilisant un dispositif d'entrée. Dans cet exemple non limitatif, l'application peut stocker la requête du client pour une récupération ultérieure lors de l'enregistrement du client. Dans un autre exemple, une application peut être configure° pour traiter les achats d'un client en utilisant un dispositif d'entrée. Dans cet exemple non limitatif, l'application peut stocker une carte de crédit du client en plus de transmettre un token de la carte de crédit à un processeur de transaction. [0087] La Fig. 8 est un diagramme bloc d'un exemple de dispositif avec lequel les systèmes, les procédés et les dispositifs de la présente invention peuvent être implémentés. Par exemple, le dispositif 800 peut comprendre un quelconque des dispositifs de tokenisation décrits dans la présente (p. ex., les dispositifs de tokenisation de stockage 101a et 101b de la Fig 1, ou autre dispositif similaire) et/ou un quelconque des dispositifs de tokenisation de réseau décrits dans la présente (p. ex., le dispositif de tokenisation de réseau 201 de la Fig. 2A, le dispositif de tokenisation 251 de la Fig. 2B, ou autre dispositif similaire). [0088] Le dispositif exemplaire 800 peut inclure au moins un processeur (p. ex., le processeur 801a et/ou le processeur 801b) et au moins une mémoire (p. ex., les mémoires 805a et 805b). Le processeur(s) 801a et/ou 801b peuvent comprendre une unité de traitement centrale (CPU), une unité de traitement de graphiques (GPU), ou autre circuiterie similaire capable de mettre en oeuvre une ou plusieurs opérations sur un flux de données. Le processeur(s) 801a et/ou 801b peuvent être configurés pour exécuter les instructions qui peuvent, par exemple, être stockées sur une ou plusieurs des mémoires 805a et 805b. Les mémoires 805a et 805b peuvent être des mémoires volatiles (telles que la RAM ou autre mémoire similaire) et/ou des mémoires non volatiles (telles que la mémoire flash, un disque dur, ou autre mémoire similaire). Comme cela a été expliqué ci-dessus, les mémoires 805a et 805b peuvent stocker des instructions pour une exécution par le processeur(s) 801a et/ou 801b. Comme décrit par ailleurs dans la FIG. 8, le dispositif 800 peut inclure au moins un contrôleur d'interface de réseau (NIC) (p. ex., NIC 807). Le NIC 807 peut être configure pour faciliter la communication sur au moins un réseau informatique (p. ex., le réseau 809). Les fonctions de communication peuvent donc être facilitées à travers un ou plusieurs NICs qui peuvent être sans fil et/ou filaires et peuvent inclure un port Ethernet, des ré- ceptcurs et des transmetteurs de fréquence radio et/ou des transmetteurs et récepteur optiques (p. ex., infrarouges). La conception spécifique et l'implémentation dudit un ou plusieurs NICs dépendent du réseau informatique 807 sur lequel le dispositif 800 est prévu pour fonctionner. Par exemple, dans certains modes de réalisation, le dispositif 800 peut inclure un ou plusieurs NICs sans fil et/ou filaires conçus pour fonctionner sur un réseau GSM, un réseau GPRS, un réseau EDGE, un réseau Wifi ou WiMax et un réseau Bluetooth®. Autrement ou concomitamment, le dispositif 800 peut inclure un ou plusieurs NICs sans fil et/ou filaires conçus pour fonctionner sur un réseau TCP/IP. Comme cela a été décrit dans la FIG. 8, le dispositif 800 peut inclure et/ou être connecté à un dispositif de stockage 803 de façon fonctionnelle. Le dispositif de stockage 803 peut être volatile (tel que la RAM ou autre dispositif similaire) ou non volatile (tel que la mémoire flash, un disque dur, ou autre dispositif similaire). Un module I/0 peut permettre les communications entre le processeur(s) 801a et/ou 801b, les mémoires 805a et 805b, le NIC 807 et/ou le dispositif de stockage 803. Le processeur(s) 801a et/ou 801b, les mémoires 805a et 805b, le NIC 807 et/ou le dispositif de stockage 803 peuvent comprendre des composants séparés ou peuvent être intégrés dans un ou plusieurs circuits intégrés. Les divers composants dans le dispositif 800 peuvent être couplés par un ou plusieurs bus de communication ou ligne de transmission de signaux (non illustrées). [0089] Dans certains exemples, un système pour tokeniser des données dans un envi- ronnement dématérialisé peut comprendre au moins un processeur et au moins une mémoire non transitoire comprenant des instructions qui, lorsqu'elles sont exécutées par ledit au moins un processeur, amènent le système à mettre en oeuvre des opérations. Les opérations peuvent comprendre la réception d'entrées devant être tokenisées, l'obtention d'une fonction de hachage clavetée, l'utilisation de la fonction de hachage clavetée par un dispositif de tokenisation, la génération d'un token de stockage pour l'entrée, la création d'une entrée de base de données cryptée reliant le token généré à l'entrée reçue, la fixation d'une échéance pour le token de stockage et lorsque le token de stockage est reçu avant l'échéance, la remise de l'entrée liée en réponse. [0090] Dans certains exemples, la fonction de hachage clavetée peut être obtenue à partir d'un système de gestion de clés. De plus ou autrement, l'entrée peut comprendre un token de réseau (207) généré par un dispositif de tokenisation de réseau. Dans certains exemples, ledit au moins un processeur et ladite au moins une mémoire non transitoire peuvent être distribués dans un environnement dématérialisé. Dans certains exemples, le système peut par ailleurs comprendre un serveur fonctionnant comme un dispositif de tokenisation de réseau et l'entrée peut comprendre un token de réseau généré par le serveur à partir de données sensibles. [0091] Dans certains exemples, le système peut par ailleurs comprendre un dispositif de to- 23 kcnisation de réseau et l'entrée peut comprendre un token de réseau généré par le dispositif de tokenisation de réseau à partir de données sensibles. Dans certains modes de réalisation, les opérations peuvent par ailleurs comprendre : la réception d'une identification; et le stockage de l'identification avec le token de stockage dans une base de données d'application. Dans ces exemples, les opérations peuvent par ailleurs comprendre : la réception d'une identification ; et l'obtention du token de stockage stocké dans la base de données d'application. [0092] Dans certains exemples, le système peut par ailleurs comprendre un dispositif de to- kenisation de réseau en communication avec ledit au moins un processeur et configure pour générer un token de réseau à partir de données sensibles, dans lequel l'entrée peut comprendre ledit token de réseau, et les opérations peuvent comprendre par ailleurs : la réception du token de stockage, l'obtention du token de réseau du dispositif de tokenisation de stockage, le routage du token de réseau vers le dispositif de tokcnisation de réseau et l'obtention des données sensibles à partir du token de réseau. Dans un quelconque des exemples incluant un dispositif de tokenisation de réseau, le dispositif de tokenisation de réseau peut générer le token de réseau en utilisant la tokenisation réversible. Par exemple, la tokenisation réversible peut comprendre le cryptage à préservation de format. [0093] Dans un quelconque des exemples incluant un dispositif de tokenisation dc réseau, les opérations peuvent comprendre par ailleurs : l'obtention d'une clé correspondant à une clé utilisée par le dispositif de tokenisation de réseau pour générer le token de réseau; l'utilisation de la clé correspondante, le décodage du token de réseau; et ensuite la génération d'un token de stockage en utilisant la fonction de hachage clavetée. Dans ces exemples, les opérations peuvent par ailleurs comprendre le renouvellement périodique de la clé correspondante. Dans ces exemples incluant un dispositif de tokenisation de réseau, le dispositif de tokenisation de réseau peut saler les données sensibles avant de générer le token de réseau, et les opérations peuvent comprennent par ailleurs : l'obtention du sel utilisé par le dispositif de tokenisation de réseau; et l'enlèvement du sel du token de réseau décodé avant de générer le token de stockage en utilisant la fonction de hachage clavetée. [0094] Dans certains modes de réalisation, les opérations peuvent par ailleurs comprendre la synchronisation de la base de données cryptée à travers un ou plusieurs serveurs. Dans ces exemples, les opérations peuvent comprendre par ailleurs l'authentification dudit un ou plusieurs serveurs avant la synchronisation. Dans certains exemples, la base de données peut comprendre une mémoire de valeurs clés. Par exemple, la mémoire de valeurs clés peut comprendre une base de données NoSQL. Dans certains exemples, les opérations peuvent comprendre par ailleurs, lorsque la base de données est défaillante : la récupération d'entrées de la base de données cryptée à partir d'un ou de 24 plusieurs autres serveurs ; et la reconstruction de la base de données cryptée en utilisant les entrées récupérées. Dans ces exemples, les opérations peuvent comprendre par ailleurs l'authentification dudit un ou plusieurs serveurs avant dc récupérer des entrées. [0095] Dans certains exemples, les opérations peuvent par ailleurs comprendre : la réception, au niveau d'un processeur différent de l'environnement dématérialisé, d'une deuxième entrée devant être tokenisée, l'obtention, pour le processeur différent, de la fonction de hachage clavetée du système de gestion de clés et l'utilisation de la fonction de hachage clavetée, la génération, au niveau du processeur différent, d'un deuxième token dc stockage pour l'entrée, dans lequel le deuxième token de stockage généré par le processeur différent est le même que le token de stockage généré par ledit au moins un processeur. [0096] Dans certains exemples, les opérations peuvent comprendre par ailleurs : lorsque la base de données cryptée est en dysfonctionnement, la distribution dc la fonction dc hachage clavetée au dispositif de tokenisation de réseau et la génération d'un token en utilisant la fonction de hachage clavetée au niveau du dispositif de tokcnisation de réseau ; et lorsque la base de données cryptée fonctionne, la réception comme token de stockage, du token généré en utilisant la fonction de hachage clavetée du dispositif de tokenisation de réseau. Dans ces exemples, les opérations peuvent comprendre par ailleurs l'authentification du dispositif de tokenisation de réseau avant la distribution de la fonction de hachage clavetée. [0097] Dans certains exemples, l'entrée peut comprendre un token généré par un dispositif de tokenisation de réseau et les opérations peuvent comprendre par ailleurs : lorsque la base de données cryptée est en dysfonctionnement, le stockage de l'entrée dans une antémémoire ; et lorsque la base de données cryptée fonctionne, le décodage du token de réseau et le stockage d'une entrée liant le token de stockage à l'entrée décodée. Dans ces exemples, l'antémémoire peut comprendre un stockage crypté. Dans un quelconque des exemples exposés ci-dessus, le système peut être en communication avec au moins un routeur de réseau. Dans ces exemples, ledit au moins un routeur de réseau peut exécuter des instructions pour fonctionner comme dispositif de tokenisation de réseau. De plus, les opérations peuvent par ailleurs comprendre l'authentification du routeur de réseau avant l'acceptation de l'entrée. [0098] La description précédente a été présentée à titre d'illustration. Elle n'est pas ex- haustive et n'est pas limitée à des formes précises ou aux modes de réalisation divulgués. Des modifications et des adaptations des modes de réalisation seront évidentes à l'examen de la spécification et à la mise en pratique des modes de réalisation divulgués. Par exemple, l'implémentation décrite inclut du matériel et des logiciels, mais les systèmes et les procédés cohérents avec la présente divulgation peuvent être implémentés seulement sur du matériel. De plus, alors que certains composants ont été décrits comme étant couplés les uns aux autres, ces composants peuvent être intégrés les uns aux autres ou distribués de manière appropriée. [0099] En outre, alors que des modes de réalisation illustratifs ont été décrits dans la présente, le champ d'application inclut un quelconque et tout mode de réalisation ayant des éléments équivalents, des modifications, des omissions, des combinaisons (p. ex. d'aspects à travers divers modes de réalisation), des adaptations et/des altérations basées sur la présente divulgation. [0100] Les instructions ou les étapes fonctionnelles stockées par un support lisible par or- dinateur peuvent être sous la forme de programmes informatiques, de modules de programmes ou de codes. Comme cela a été exposé dans la présente, les programmes informatiques, les modules de programmes et le code basés sur la description écrite dans cette spécification, tels que ceux qui sont utilisés par le processeur, relèvent aisément de la compétence d'un développeur de logiciel. Les programmes informatiques, les modules de programmes ou le code peuvent être créés en utilisant une variété de techniques de programmation. Par exemple, ils peuvent être conçus dans, ou au moyen de, Java, C, C++, le langage d'assemblage ou tout autre langage de programmation de ce type. Un ou plusieurs de ces programmes, modules ou codes peuvent être intégrés dans un dispositif de système ou des logiciels de communication existants. Les programmes, modules, ou codes peuvent aussi être implémentés ou répliqués comme micrologiciel ou circuit logique. [0101] Les caractéristiques et les avantages de la divulgation sont évidents à partir de la spé- cification détaillée. D'autres modes de réalisation seront évidents à l'examen de la spécification et à la mise en pratique de l'invention divulguée dans les présentes. La spécification et les exemples sont censés être considérés uniquement à titre d'exemples. 26 REVENDICATIONS[Revendication 1] Un système pour tokeniscr des informations dans un environnement dé- matérialisé, comprenant : au moins un processeur ; et au moins une mémoire non transitoire contenant des instructions qui, lorsqu'elles sont exécutées par ledit au moins un processeur, amènent le système à mettre en oeuvre des opérations comprenant : la réception d'une entrée (207) devant être tokeniséc, l'obtention d'une fonction de hachage clavetée, l'utilisation de la fonction de hachage clavetée dans un dispositif de to- kenisation de stockage, la génération d'un token de stockage (215) pour l'entrée, la création d'une entrée de base de données cryptée reliant le token généré à l'entrée reçue, la fixation d'une échéance pour le token de stockage et lorsque le token de stockage est reçu avant l'échéance, la remise de l'entrée liée en réponse. [Revendication 2] Le système de la revendication 1, dans lequel la fonction de hachage clavetée est obtenue à partir d'un système de gestion de clés. [Revendication 3] Le système de la revendication 2, dans lequel les opérations com- prennent par ailleurs : la réception, au niveau d'un processeur différent de l'environnement matérialisé, d'une deuxième entrée (307b) devant être tokenisée, l'obtention, pour le processeur différent, de la fonction de hachage clavetée à partir du système de gestion de clés (303), et l'utilisation de la fonction de hachage clavetée, la génération au niveau du processeur différent, d'un deuxième token de stockage pour l'entrée, dans lequel le deuxième token de stockage généré par le processeur différent est similaire au token de stockage généré par ledit au moins un processeur. [Revendication 4] Le système de l'une quelconque des revendications 1 à 3, dans lequel les opérations comprennent par ailleurs : la réception d'une identification (id) ; et le stockage de l'identification (id) avec le token de stockage (215) dans une base de données d'application. [Revendication 5] Le système de l'une quelconque des revendications 1 à 4, dans lequel les opérations comprennent par ailleurs la synchronisation de la base de 27 [Revendication 6] [Revendication 7] [Revendication 8] [Revendication 9] [Revendication 10] [Revendication 11] [Revendication 12] [Revendication 13] données encryptée à travers un ou plusieurs serveurs. Le système de la revendication 5, dans lequel les opérations comprennent par ailleurs l'authentification dudit un ou plusieurs serveurs avant la synchronisation. Le système de l'une quelconque des revendications 1 à 6, dans lequel les opérations peuvent comprendre par ailleurs, lorsque la hase de données est défaillante, la récupération d'entrées de la base de données cryptée à partir d'un ou de plusieurs autres serveurs ; et la reconstruction de la base de données cryptée en utilisant les entrées récupérées. Le système de la revendication 7, dans lequel les opérations comprennent par ailleurs l'authentification dudit un ou plusieurs autres serveurs avant de récupérer les entrées. Le système de l'une quelconque des revendications 1 à 8, dans lequel le système comprend, ou est en communication avec, un dispositif de tokenisation de réseau (251, 201, 203). Le système de la revendication 13, dans lequel les opérations peuvent comprendre par ailleurs : lorsque la base de données cryptée est en dysfonctionnement, la distribution de la fonction de hachage clavetée au dispositif de tokenisation de réseau (251. 201. 203.) et la génération d'un token en utilisant la fonction de hachage clavetée au niveau du dispositif de tokenisation de réseau; et lorsque la base de données cryptée fonctionne, la réception comme token de stockage, du token généré en utilisant la fonction de hachage clavetée du dispositif de tokenisation de réseau. Le système de la revendication 10, dans lequel les opérations peuvent comprendre par ailleurs l'authentification du dispositif de tokenisation de réseau (251. 201. 203) avant la distribution de la fonction de hachage clavetée. Le système de l'une quelconque des revendications 9 à 11, dans lequel l'entrée comprend un token de réseau (207) généré par le dispositif de tokenisation de réseau (201, 203). Le système de la revendication 11, dans lequel les opérations peuvent comprendre par ailleurs : lorsque la base de données cryptée est en dysfonctionnement, le stockage des entrées dans une antémémoire ; et 28 [Revendication 14] [Revendication 15] [Revendication 16] [Revendication 17] [Revendication 18] lorsque la base de données cryptée fonctionne, le décodage du token de réseau et le stockage d'une entrée liant le token de stockage à l'entrée décodée. Le système de la revendication 12 ou 13, dans lequel le token de réseau (207) est généré par le dispositif de tokenisation de réseau (201) à partir de données sensibles (267). Le système de la revendication 14, dans lequel le dispositif de tokenisation de réseau (251, 201) peut are en communication avec ledit au moins un processeur et dans lequel les opérations peuvent comprendre par ailleurs : la réception d'un token de stockage (257), l'obtention du token de réseau (265) à partir du dispositif de tokenisation de stockage, le routage du token de réseau vers le dispositif de tokenisation de réseau (251, 201), et l'obtention des données sensibles (267) à partir du token de réseau. Le système de l'une quelconque des revendications 12 à 15, dans lequel le dispositif de tokenisation de réseau (251, 201, 203) génère le token de réseau en utilisant la tokenisation réversible. Le système de l'une quelconque des revendications 12 to 16, dans lequel les opérations comprennent par ailleurs : l'obtention d'une clé correspondant à une clé utilisée par le dispositif de tokenisation de réseau (251, 201, 203) pour générer le token de réseau ; et l'utilisation de la clé correspondante, le décodage du token de réseau ; et ensuite la génération d'un token de stockage en utilisant la fonction de hachage clavetée. Le système de la revendication 14 à 17, dans lequel le dispositif de tokenisation de réseau (251, 201, 203) sale les informations sensibles (267) avant de générer le token de réseau, et dans lequel les opérations comprennent par ailleurs : l'obtention du sel utilisé par le dispositif de tokenisation de réseau (251, 201, 203); et l'enlèvement du sel du token de réseau décodé avant de générer le token de stockage en utilisant la fonction de hachage clavetée.