FR3137769A1 - Procédé de sauvegarde de données personnelles sensibles sur une chaîne de blocs - Google Patents
Procédé de sauvegarde de données personnelles sensibles sur une chaîne de blocs Download PDFInfo
- Publication number
- FR3137769A1 FR3137769A1 FR2207041A FR2207041A FR3137769A1 FR 3137769 A1 FR3137769 A1 FR 3137769A1 FR 2207041 A FR2207041 A FR 2207041A FR 2207041 A FR2207041 A FR 2207041A FR 3137769 A1 FR3137769 A1 FR 3137769A1
- Authority
- FR
- France
- Prior art keywords
- user
- blockchain
- personal data
- terminal
- encrypted
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 55
- 239000000284 extract Substances 0.000 claims abstract description 7
- 230000003993 interaction Effects 0.000 claims description 5
- 238000012550 audit Methods 0.000 description 3
- 230000029305 taxis Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 235000021183 entrée Nutrition 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 239000002184 metal Substances 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0464—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload using hop-by-hop encryption, i.e. wherein an intermediate entity decrypts the information and re-encrypts it before forwarding it
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Storage Device Security (AREA)
Abstract
L’invention concerne un procédé qui prévoit de : signer les données personnelles (2) avec une clé privée (7a) liée à un terminal (5) de l’utilisateur (1), les chiffrer avec une clé publique (12b) d'une boite noire transactionnelle (11) ; les enregistrer sur une chaîne de blocs (3) en les liant à l’utilisateur (1) ; puis de, lorsque l’utilisateur (1) souhaite récupérer ses données (2) enregistrées sur la chaine de blocs (3) : envoyer une requête en restauration comprenant une clé publique liée à son terminal ; authentifier l’utilisateur (1) ; extraire les données (2) signées et chiffrées enregistrées sur la chaîne de blocs (3) ; déchiffrer les données (2) avec la clé privée (12a) de la boite noire transactionnelle (11) ; rechiffrer lesdites données avec la clé publique liée au terminal ; communiquer lesdites données rechiffrées audit terminal. Figure 1a
Description
L’invention concerne un procédé pour permettre à un utilisateur de sauvegarder des données personnelles sensibles sur une chaîne de blocs, ainsi qu’une architecture comprenant des moyens pour mettre en œuvre un tel procédé.
De manière générale, les opérations numériques, notamment les transactions nécessitant une certaine confidentialité, reposent essentiellement sur l’utilisation de protocoles cryptographiques, afin de garantir la sécurité des parties impliquées dans la transaction.
On connait des protocoles cryptographiques qui utilisent des clés de déchiffrement qui sont soit secrètes (cryptographie dite « symétrique »), soit privées et publiques (cryptographie dite « asymétrique »).
Les clés secrètes ou privées doivent rester confidentielles vis-à-vis des tiers pour éviter une perte des données ou des actifs protégés par lesdites clés, ou une usurpation de l’identité de leur utilisateur. Et, en cas de perte de ses clés de déchiffrement, un utilisateur doit réaliser un processus long et contraignant pour mettre à jour ses actifs, et risque même de perdre les actifs liés auxdites clés.
Pour éviter ces désagréments, il est nécessaire pour un utilisateur de sauvegarder ses clés de signature et/ou d’accès à une chaîne de blocs. Pour ce faire, il est connu d’écrire ces clés sous forme d’une liste de mots normalisés, que l’utilisateur peut copier sur un support matériel ou informatique, par exemple une feuille de papier, une plaque en métal, un périphérique de stockage informatique de type clé USB (pour l’anglais Universal Serial Bus) ou un disque dur, ledit support devant ensuite être conservé dans un lieu sûr connu dudit utilisateur, par exemple le coffre-fort d’une banque.
L’invention vise à perfectionner l’art antérieur en proposant notamment un procédé pour permettre à un utilisateur de sauvegarder facilement ses clés d’accès à une chaîne de blocs au moyen de son identité digitale, ledit procédé pouvant s’étendre à tout type de données personnelles sensibles dudit utilisateur.
A cet effet, selon un premier aspect, l’invention propose un procédé pour permettre à un utilisateur de sauvegarder des données personnelles sensibles sur une chaîne de blocs, ledit procédé prévoyant de :
- signer les données personnelles au moyen d’une clé privée liée à un terminal de l’utilisateur ;
- chiffrer lesdites données personnelles avec une clé publique d'une boite noire transactionnelle ;
- enregistrer les données personnelles signées et chiffrées sur la chaîne de blocs en les liant à l’utilisateur ;
ledit procédé prévoyant en outre, lorsque l’utilisateur souhaite récupérer ses données personnelles enregistrées sur la chaine de blocs, de :
- envoyer une requête en restauration comprenant une clé publique liée à un terminal de l’utilisateur ;
- authentifier l’utilisateur ;
- extraire les données personnelles signées et chiffrées enregistrées sur la chaîne de blocs ;
- déchiffrer les données personnelles extraites avec la clé privée liée à la clé publique de la boite noire transactionnelle ;
- rechiffrer lesdites données personnelles avec la clé publique extraite de la requête en restauration ;
- communiquer lesdites données personnelles rechiffrées audit terminal.
Selon un second aspect, l’invention propose une architecture pour permettre à un utilisateur de sauvegarder des données personnelles sensibles sur une chaîne de blocs, ladite architecture comprenant :
- une boîte noire transactionnelle comprenant une paire de clés asymétriques privée et publique, ladite boîte noire comprenant des moyens pour chiffrer et déchiffrer des données au moyen d’une clé de chiffrement donnée ;
- au moins un terminal comprenant, notamment au moyen d’une application installée sur ledit terminal, des moyens pour permettre à l’utilisateur de :
- signer ses données personnelles au moyen d’une clé privée liée audit terminal ;
- chiffrer lesdites données personnelles avec la clé publique de ladite boite noire transactionnelle ;
- envoyer les données personnelles signées et chiffrées sur la chaîne de blocs, afin de les enregistrer sur ladite chaîne de blocs en les liant à l’utilisateur ;
- envoyer sur la chaîne de blocs une requête en restauration comprenant une clé publique liée audit terminal, afin de récupérer ses données personnelles enregistrées sur la chaîne de blocs ;
- une plateforme intermédiaire liée à la chaîne de blocs, ladite plateforme intermédiaire comprenant des moyens pour, après réception d’une requête en restauration envoyée par un terminal de l’utilisateur :
- authentifier l’utilisateur ;
- extraire les données personnelles signées et chiffrées enregistrées sur la chaîne de blocs ;
- communiquer à la boîte noire transactionnelle les données personnelles signées et chiffrées extraites et la clé publique extraite de la requête en restauration, afin que ladite boîte noire transactionnelle :
- déchiffre les données personnelles extraites avec la clé privée de ladite boite noire transactionnelle ;
- rechiffre lesdites données personnelles avec la clé publique extraite de la requête en restauration ;
- communique lesdites données personnelles rechiffrées au terminal ayant envoyé ladite requête en restauration.
D’autres particularités et avantages de l’invention apparaîtront dans la description qui suit, faite en référence aux figures annexées, dans lesquelles :
En relation avec ces figures, on décrit ci-dessous un procédé pour permettre à un utilisateur de sauvegarder des données personnelles sensibles 2 sur une chaîne de blocs 3, ainsi qu’une architecture comprenant des moyens techniques pour permettre la mise en œuvre d’un tel procédé.
L’architecture comprend une plateforme intermédiaire 4 liée à la chaîne de blocs 3, ladite plateforme intermédiaire comprenant une interface de programmation d’applications (API, pour l’anglais « Application Programming Interface ») réalisant l’activation des moyens techniques pour recevoir des requêtes d’utilisateurs 1 connectés à la chaîne de blocs 3, cette dernière étant formée par un ensemble de plateformes 27 de communication et de calcul permettant son fonctionnement, et servant de moyens d’accès à ladite chaîne de blocs.
L’architecture comprend en outre au moins un terminal 5, 5’ équipé de moyens pour permettre à l’utilisateur 1 d’interagir avec la chaîne de blocs 3 et/ou la plateforme intermédiaire 4, notamment pour envoyer des requêtes telles que susmentionnées.
Comme représenté sur les figures, le terminal 5, 5’ peut être un téléphone portable de type « intelligent » (pour l’anglais « smartphone »). Le terminal 5, 5’ peut également être d’un autre type, notamment une tablette numérique, un assistant personnel (PDA, pour l’anglais « Personal Digital Assistant »), un ordinateur portable ou un ordinateur de bureau, sous réserve d’être équipé de moyens techniques adaptés pour la mise en œuvre du procédé.
En particulier, l’architecture peut comprendre au moins une application 6 avec des moyens adaptés pour la mise en œuvre du procédé, que l’utilisateur 1 peut télécharger pour l’installer sur son terminal 5, 5’ notamment en envoyant une requête adaptée à ladite architecture.
Pour pouvoir interagir avec la chaîne de blocs 3, l'utilisateur 1 doit générer une paire de clés privée 7a, 7a’ et publique 7b, 7b’, notamment lors de sa première connexion à ladite chaîne de blocs et en cas de perte ou de vol de ses précédentes clés. La clé privée 7a, 7a’ est tenue secrète par l’utilisateur 1 et la clé publique 7b, 7b’ permet audit utilisateur d’interagir avec la chaîne de blocs 3 pour y effectuer des opérations. En particulier, une adresse numérique personnelle est dérivable de la clé publique 7b, 7b’ pour représenter l’utilisateur 1 sur la chaîne de blocs 3.
Pour générer de telles clés 7a, 7b, 7a’, 7b’ l'utilisateur 1 peut lancer une procédure adaptée sur son terminal 5, 5’ notamment au moyen de l’application 6 décrite précédemment. Les clés 7a, 7b, 7a’, 7b’ sont ainsi liées au terminal 5, 5’ au sein duquel elles sont générées sous le contrôle de l'utilisateur 1, qui n’utilise que la clé publique 7b, 7b’. De ce fait, la clé privée 7a, 7a’ ne quitte jamais le terminal 5, 5’ ce qui garantit à l’utilisateur 1 une sécurité optimale.
Pour finaliser ou mettre à jour son adhésion à la chaîne de blocs 3, l’utilisateur 1 enregistre sa clé publique 7b, 7b’ sur ladite chaîne de blocs. En particulier, l’utilisateur 1 peut effectuer cet enregistrement en associant la clé publique 7b, 7b’ à une empreinte numérique liée à l’identité dudit utilisateur.
Pour ce faire, l’utilisateur 1 peut authentifier son identité auprès d’une plateforme tierce 8, afin de créer une empreinte numérique au moyen de données d’identité fournies par ladite plateforme tierce, ladite empreinte numérique étant ensuite enregistrée sur la chaîne de blocs 3 pour être associée avec la clé publique 7b, 7b’.
La plateforme tierce 8 présente un niveau de confiance qui peut être évalué dans le cadre de la réglementation eIDAS (pour l’anglais « Electronic IDentification And Trust Services ») ou de tout autre système d’évaluation de la confiance basé sur l’identité, et peut être par exemple une plateforme de fourniture d’un service d’identification publique et/ou administratif tel que la sécurité sociale, un service pour le paiement de taxes officielles telles que les impôts sur le revenu, ou tout autre service d’identification permettant d’atteindre le niveau de confiance eIDAS requis par les utilisateurs, ou encore tout autre système fournissant une identité, par exemple un système d’identification des employés d’une entreprise. En particulier, la plateforme tierce 8 peut fournir pour l’utilisateur 1 un identifiant unique, notamment basé sur ses données d’identité.
Cet enregistrement peut notamment être effectué dans un coffre-fort numérique personnel 9 détenu par l’utilisateur 1 sur la chaîne de blocs, comme représenté sur les figures 3a et 3b.
L’utilisateur 1 peut créer un tel coffre-fort personnel 9 pour pouvoir interagir ultérieurement avec la chaîne de blocs 3 uniquement au moyen de l’adresse numérique 10 dudit coffre-fort personnel, ce qui permet audit utilisateur d’enregistrer plusieurs clés publiques 7b, 7b’ dans un même coffre-fort personnel 10 et d’accéder à la chaîne de blocs 3 avec n’importe laquelle desdites clés, et donc d’éviter la perte de son accès à la chaîne de blocs 3 en cas de perte et/ou de vol de ses clés 7a, 7a’, 7b, 7b’ et/ou de son terminal 5, 5’.
Pour ce faire, l’architecture peut comprendre une plateforme pour le déploiement de coffres-forts sur la chaîne de blocs 3, le terminal 5, 5’ et/ou l’application 6 comprenant des moyens pour interagir avec ladite plateforme de déploiement pour créer un coffre-fort personnel 9, notamment par l’envoi d’une requête adaptée (non représentée).
Cette fonctionnalité peut être réalisée par la plateforme intermédiaire 4 représentée sur les figures, ou par une plateforme additionnelle liée à la chaîne de blocs 3.
Tous les coffres-forts numériques de l’architecture peuvent être créés sous la forme de protocoles informatiques de type contrats intelligents (pour l’anglais « smart contracts »), qui sont accessibles sur la chaîne de blocs 3 au moyen d’une adresse numérique publique.
La plateforme de déploiement comprend une interface de programmation d’applications (API), ladite interface comprenant des moyens techniques adaptés pour permettre la création de coffres-forts sur la chaîne de blocs.
De façon avantageuse, la plateforme de déploiement est agencée pour permettre la création automatique de coffres-forts numériques sur simple requête d’un utilisateur 1. A cet effet, l’architecture peut comprendre :
- un coffre-fort numérique lié à la plateforme de déploiement, dans lequel est enregistré au moins un identifiant de ladite plateforme de déploiement sur la chaîne de blocs 3 ;
- un coffre-fort numérique central, qui comprend notamment :
- une liste répertoriant les plateformes de déploiement de coffres-forts appartenant à un réseau de confiance, ladite liste comprenant les adresses numériques des coffres-forts liés à chacune de ces plateformes de confiance ; et
- une liste répertoriant l’ensemble des coffres-forts numériques créés par ces plateformes de confiance sur la chaîne de blocs 3, ladite liste comprenant des entrées qui contiennent chacune l’adresse numérique d’un coffre-fort créé par une plateforme de déploiement, associée à l’adresse numérique du coffre-fort lié à cette plateforme de déploiement.
En variante, la plateforme de déploiement peut être agencée pour permettre la création de coffres-forts numériques par un administrateur de la chaîne de blocs 3, notamment suite à la réception d’une requête par un utilisateur 1.
Après création de son coffre-fort numérique personnel 9, un utilisateur 1 peut authentifier son identité auprès de la plateforme tierce 8, afin de créer une empreinte numérique au moyen de données d’identité fournies par ladite plateforme tierce, ladite empreinte numérique étant ensuite enregistrée dans ledit coffre-fort numérique personnel par la plateforme de déploiement.
A l’issue de cet enregistrement, la plateforme de déploiement envoie à l'utilisateur 1 une notification contenant l’adresse numérique publique 10 de son coffre-fort personnel 9, afin que ledit utilisateur puisse accéder audit coffre-fort personnel.
L’architecture comprend en outre une boite noire transactionnelle 11 (BNT ou HSM, pour l’anglais « Hardware Security Module »), qui est raccordée à la plateforme intermédiaire 4 et pilotée par ladite plateforme.
La boite noire 11 comprend une paire de clés asymétrique privée 12a et publique 12b, la clé privée 12a étant gardée secrète, la clé publique 12b étant dérivée mathématiquement de ladite clé privée et destinée à être communiquée aux utilisateurs 1 de la chaîne de blocs 3.
La boîte noire 11 comprend en outre des moyens pour chiffrer et déchiffrer des données au moyen d’une clé de chiffrement donnée, notamment sa propre clé privée 12a ou n’importe quelle clé de chiffrement tierce qui lui a été communiquée.
Le procédé prévoit en premier lieu de signer les données personnelles 2 de l’utilisateur 1 au moyen d’une clé privée 7a liée à un terminal 5 dudit utilisateur, puis de chiffrer les données personnelles 2 signées avec la clé publique 12b de la boîte noire 11.
Pour ce faire, comme représenté sur les figures 1a, 2a et 3a, le terminal 5 ou l’application 6 comprend des moyens pour permettre à l’utilisateur 1 de signer ses données personnelles 2 au moyen de sa clé privée 7a, puis de chiffrer lesdites données personnelles avec cette clé publique 12b, notamment en lançant une procédure adaptée 13 sur ledit terminal ou ladite application.
En particulier, la signature électronique des données personnelles 2 par leur utilisateur 1 permet d’attester que lesdites données proviennent bien dudit utilisateur, afin d’éviter toute usurpation de son identité numérique sur la chaîne de blocs 3. Ainsi, on empêche toute personne autre que l’utilisateur 1 d’enregistrer ses données personnelles 2 sur la chaîne de blocs 3 et, grâce au chiffrement par la clé 12b, on empêche également une autre personne de lire et récupérer ultérieurement lesdites données sur ladite chaîne de blocs.
Pour obtenir la clé publique 12b de la boîte noire 11, le terminal 5 ou l’application 6 peut notamment envoyer une requête à la plateforme intermédiaire 4, ladite plateforme intermédiaire envoyant en retour une notification comprenant ladite clé publique.
En particulier, la clé publique 12b peut être inscrite sans risque dans une base de données liée au terminal 5 ou à l’application 6, comme représenté sur ces mêmes figures 1a, 2a, 3a.
Sur les figures 2a et 2b, la clé publique 12b est préalablement enregistrée dans un coffre-fort numérique 14 de stockage collectif prévu à cet effet sur la chaîne de blocs 3, le terminal 5 envoyant une requête 15 à ce coffre-fort 14 pour y lire ladite clé publique. En particulier, l’utilisateur 1 peut interagir avec la chaîne de blocs 3 et/ou la plateforme intermédiaire 4 pour obtenir l’adresse numérique 16 du coffre-fort collectif 14 sur ladite chaîne de blocs, afin de pouvoir envoyer la requête 15 audit coffre-fort collectif.
Le coffre-fort 14 de stockage collectif peut être créé par un administrateur de la chaîne de blocs 3, notamment au moyen d’une plateforme de déploiement telle que décrite précédemment.
Le procédé prévoit ensuite d’enregistrer les données personnelles 2 signées et chiffrées avec les clés 7a, 12b sur la chaîne de blocs 3, en les liant à l’utilisateur 1. Pour ce faire, le terminal 5 ou l’application 6 comprend des moyens pour envoyer les données personnelles 2 signées et chiffrées sur la chaîne de blocs 3, afin de les enregistrer sur ladite chaîne de blocs en les liant à l’utilisateur 1.
En particulier, cet enregistrement peut être effectué soit directement par le terminal 5 ou l’application 6, soit au travers de la plateforme intermédiaire 4, qui comprend alors des moyens adaptés pour enregistrer les données 2 signées et chiffrées sur la chaîne de blocs 3 en effectuant une telle liaison.
Selon une réalisation, le procédé prévoit de signer et chiffrer ensemble les données personnelles 2 et un numéro aléatoire 17 généré en complément d’un identifiant unique 18 de l’utilisateur 1 fourni par une plateforme tierce 8 telle que décrite précédemment, puis d’enregistrer lesdites données et ledit numéro aléatoire signés et chiffrés par les clés 7a, 12b sur la chaîne de blocs 3, en les associant à une empreinte numérique 18’ dudit identifiant unique.
L’ajout d’un tel numéro aléatoire 17 permet :
- d’éviter l’usurpation de l’identifiant unique 18 et/ou des données d’identité de l’utilisateur 1, notamment en cas de piratage de la plateforme d’identité tierce 8 ;
- d’attester la pertinence des données personnelles 2, et notamment qu’elles n’ont pas été recyclées à partir d’un ancien enregistrement de l’utilisateur 1 sur la chaîne de blocs 3.
Pour ce faire, en relation avec les figures 1a et 2a, le terminal 5 ou l’application 6 comprend des moyens pour envoyer à la plateforme intermédiaire 4 une requête 19 en connexion contenant une clé publique 7b valide liée audit terminal.
Après réception de la requête 19, la plateforme intermédiaire 4 envoie à la plateforme d’identité 8 une notification 20 pour requérir l’authentification de l’utilisateur 1, l’utilisateur 1 interagissant ensuite avec ladite plateforme d’identité pour fournir un identifiant unique 18. Ensuite, la plateforme d’identité 8 envoie à la plateforme intermédiaire 4 une notification 21 comprenant cet identifiant unique 18.
De façon avantageuse, la plateforme intermédiaire 4 peut enregistrer l’identifiant unique 18 dans une base de données prévue à cet effet, afin de faciliter les procédures ultérieures nécessaires à l’enregistrement des données 2 sur la chaîne de blocs 3 et/ou à leur restauration à l’utilisateur 1.
La plateforme intermédiaire 4, grâce à des moyens techniques adaptés :
- génère un numéro aléatoire 17 en complément de l’identifiant unique 18 communiqué dans cette notification 21 ;
- communique au terminal 5 de connexion de l’utilisateur 1 une notification 22 contenant ledit numéro aléatoire, afin que ledit terminal lance la procédure 13 pour signer et chiffrer ensemble les données personnelles 2 et ledit numéro aléatoire, respectivement au moyen de sa clé privée 7a liée à la clé publique 7b (pour la signature) et avec la clé publique 12b de la boîte noire 11 (pour le chiffrement).
Le terminal 5 ou l’application 6 envoie ensuite à la plateforme intermédiaire 4 une notification 23 contenant les données 2 et le numéro aléatoire 17 ainsi signés et chiffrés, afin que ladite plateforme intermédiaire vérifie leur signature au moyen de la clé publique 7b correspondant à la clé privée 7a et préalablement envoyée via la requête en connexion 19, notamment en lançant une procédure 24 adaptée.
Cette vérification permet d’effectuer une authentification de l’utilisateur 1 à l’épreuve des attaques par rejeu, afin de s’assurer que les données 2 communiquées lui appartiennent bien.
Une fois cette procédure 24 de vérification effectuée, la plateforme intermédiaire 4, grâce à des moyens techniques adaptés :
- calcule une empreinte numérique 18’ à partir de l’identifiant unique 18 communiqué dans la notification 21 ;
- enregistre les données personnelles 2 et le numéro aléatoire 17 signés et chiffrés sur la chaîne de blocs 3, notamment par l’envoi d’une notification 25 adaptée, en les associant à ladite empreinte numérique.
Cette empreinte numérique 18’ peut notamment être calculée au moyen d’un algorithme de hachage à sens unique. Ainsi, il est impossible de retrouver l’identifiant numérique 18 dont l’empreinte 18’ est dérivée, ce qui permet d’éviter l’utilisation dudit identifiant numérique par une personne autre que l’utilisateur 1.
Enfin, la plateforme intermédiaire 4 envoie au terminal 5 ou à l’application 6 une notification 26 pour attester l’enregistrement des données 2 signées et chiffrées sur la chaîne de blocs 3. Cette notification 26 peut être communiquée à l’utilisateur 1 directement après l’enregistrement, avec un numéro de transaction correspondant fourni par la chaîne de blocs 3, ou de manière différée, après validation dudit enregistrement par ladite chaîne de blocs.
Sur la , la plateforme intermédiaire 4 comprend des moyens pour enregistrer les données personnelles 2 et le numéro aléatoire 17 chiffrés et signés par inscription directe dans la chaîne de blocs 3, notamment dans un nœud 27 de ladite chaîne de blocs, en les associant à l’empreinte numérique 18’ décrite précédemment.
Cette réalisation permet d’enregistrer les données personnelles 2 signées et chiffrées d’un utilisateur 1 directement dans la chaîne de blocs 3, en s’affranchissant d’une base de données additionnelle à implanter dans la plateforme intermédiaire 4.
Sur la , le procédé prévoit, grâce à des moyens techniques adaptés de la plateforme intermédiaire 4, d’enregistrer les données personnelles 2 et le numéro aléatoire 17 signés et chiffrés dans le coffre-fort de stockage collectif 14 décrit précédemment, en les associant à l’empreinte numérique 18’.
Par rapport à la réalisation représentée sur la , cette réalisation permet en plus de mettre à la disposition de la plateforme intermédiaire 4 un espace de stockage adapté et facilement accessible sur la chaîne de blocs 3 pour effectuer l’enregistrement des données 2 chiffrées et signées. En effet, la plateforme intermédiaire 4 doit simplement utiliser l’adresse numérique 16 pour accéder au coffre-fort collectif 14 et enregistrer les données 2 signées et chiffrées sur la chaîne de blocs 3.
Dans ces deux réalisations, il est nécessaire que l’ensemble des étapes de signature, chiffrage et enregistrement des données personnelles 2 de l’utilisateur 1 sur la chaîne de blocs 3 soient effectuées durant une même session de connexion de l’application 6 à l’interface API de la plateforme intermédiaire 4, afin de garantir la sécurité dudit enregistrement, mais également d’éviter le dépassement de la période de validité du numéro aléatoire 17 contrôlée par la plateforme intermédiaire 4, qui pourrait empêcher l’enregistrement ultérieur de données 2 signées et chiffrées au sein d’un même datagramme avec ledit numéro aléatoire, et obligerait l’utilisateur 1 à relancer toute la procédure d’enregistrement depuis le début.
En relation avec la , dans le cas où l’utilisateur 1 détient un coffre-fort personnel 9 sur la chaîne de blocs 3, le procédé prévoit d’enregistrer directement les données personnelles 2 signées et chiffrées dans ledit coffre-fort personnel.
Pour ce faire, le terminal 5 ou l’application 6 comprend des moyens pour effectuer cet enregistrement directement après signature et chiffrement des données personnelles 2, en accédant au coffre-fort personnel 9 via l’adresse numérique 10 communiquée à l’utilisateur 1 lors de son enrôlement initial sur la chaîne de blocs 3.
Cet agencement permet de limiter l’implication des plateformes 8, 4, et notamment de s’affranchir de l’utilisation d’une interface de programmation d’applications API fournie par la plateforme intermédiaire 4 pour l’enregistrement des données 2 signées et chiffées sur la chaîne de blocs 3. En effet, l’utilisateur 1 a juste besoin des clés publiques 10, 12b respectives de son coffre-fort personnel 9 et de la boîte noire 11.
Par ailleurs, l’utilisation d’un identifiant personnel 18, notamment avec l'ajout d’un numéro aléatoire 17 et d’une empreinte 18’ tel que décrit précédemment, n’est pas nécessaire dans cette troisième réalisation pour enregistrer les données 2 sur la chaîne de blocs, dans la mesure où l’utilisateur 1 a déjà fourni un tel identifiant personnel 18 à la chaine de blocs 3 lors de la création de son coffre-fort personnel 9, dont la présence permet ainsi d’authentifier ledit utilisateur sans risque d’attaque par rejeu.
Toutefois, dans cette réalisation, la signature des données personnelles 2 et leur chiffrement reste nécessaire, car cela permet de garantir leur appartenance à l’utilisateur 1.
En relation avec les figures 1b, 2b et 3b, le procédé prévoit en outre, lorsque l’utilisateur 1 souhaite récupérer ses données personnelles 2 enregistrées sur la chaîne de blocs 3, d’envoyer une requête en restauration 28 comprenant une clé publique 7b’ liée à un terminal 5, 5’ dudit utilisateur, notamment via des moyens adaptés installés sur le terminal 5, 5’ ou intégrés à l’application 6 décrite précédemment.
La plateforme intermédiaire 4 comprend des moyens adaptés pour recevoir cette requête 28, notamment intégrés à son interface de programmation d’applications API adaptée pour communiquer avec les utilisateurs 1 de la chaîne de blocs 3.
La plateforme intermédiaire 4 comprend en outre des moyens pour, après réception de la requête en restauration 28, authentifier l’utilisateur 1 ayant envoyé ladite requête.
Sur les figures 1b et 2b, le procédé prévoit d’authentifier l’utilisateur 1 au moyen de l’identifiant unique 18 fourni par la plateforme d’identité 8, ledit identifiant étant communiqué en même temps que la requête en restauration 28 par interaction dudit utilisateur avec ladite plateforme tierce. Pour ce faire, après réception de la requête 28, la plateforme intermédiaire 4 envoie à la plateforme d’identité 8 une notification 29 similaire à la notification 20 de la procédure d’enregistrement des données 2, afin de requérir une authentification de l’utilisateur 1 auprès de ladite plateforme d’identité.
Ensuite, la plateforme d’identité 8 répond à la plateforme intermédiaire 4 par une notification 30 contenant l’identifiant unique 18 de l’utilisateur 1, afin que la plateforme intermédiaire 4 :
- calcule une empreinte numérique 18’ à partir dudit identifiant numérique, au moyen de l’algorithme de hachage à sens unique utilisé lors de l’enregistrement des données 2 ;
- vérifie la correspondance de cette empreinte numérique 18’ avec des données personnelles 2 chiffrées et signées préalablement enregistrées dans un nœud 27 (
Si la plateforme intermédiaire 4 trouve une telle correspondance, elle extrait de la chaîne de blocs 3 les données 2 signées et chiffrées préalablement enregistrées directement dans le nœud 27 de la chaîne de blocs 3 ou dans le coffre-fort 14.
Ensuite, sur chacune des figures 1b et 2b, la plateforme intermédiaire 4 communique à la boite noire 11 les données 2 signées et chiffrées extraites de la chaine de blocs 3 et la clé publique 7b’ communiquée via la requête 28, afin que ladite boite noire lance successivement :
- une procédure 32 pour déchiffrer les données personnelles 2 avec la clé privée 12a de ladite boite noire liée à la clé publique 12b ayant servi à leur chiffrement ;
- une procédure 33 pour rechiffrer lesdites données personnelles avec la clé publique 7b’ extraite de la requête en restauration 28 ;
- une procédure pour communiquer lesdites données personnelles rechiffrées au terminal 5, 5’ ayant envoyé la requête 28, via une notification 34 adaptée, afin que ledit terminal ou l’application 6 lance une procédure 35 adaptée pour déchiffrer lesdites données avec la clé privée 7a’ associée à la clé publique 7b’ de rechiffrement.
Sur la , le procédé prévoit d’authentifier l’utilisateur 1 au moyen de la clé publique 7b’ communiquée dans la requête en restauration 28, en vérifiant la présence de ladite clé publique dans le coffre-fort personnel 9 de l’utilisateur 1 sur la chaîne de blocs 3.
Pour ce faire, comme représenté sur la , le terminal 5, 5’ ou l’application 6 comprend des moyens pour envoyer en plus la clé publique 10 du coffre-fort personnel 9 dans la requête en restauration 28 comprenant une clé publique 7b’ liée audit terminal. Ainsi, la plateforme intermédiaire 4 accède au coffre-fort personnel 9 au moyen d’une adresse numérique dérivée de la clé publique 10 extraite de la requête 28, via une requête 31 adaptée, afin de vérifier la présence dans ledit coffre-fort personnel de la clé publique 7b’ liée au terminal 5, 5’ pour authentifier l’utilisateur 1.
En variante, comme représenté sur la , la clé publique 10 du coffre-fort personnel 9 est préalablement enregistrée dans une base de données 36 de la chaîne de blocs 3, en étant associée à l’identifiant unique 18 fourni par une plateforme tierce 8 telle que décrite précédemment, cet enregistrement pouvant notamment s’effectuer au moment de l’enregistrement des données 2 chiffrées et signées dans ledit coffre-fort personnel.
Dans cette variante, le terminal 5, 5’ communique sa clé publique actuelle 7b’ dans la requête en restauration 28, et la plateforme intermédiaire 4 accède au coffre-fort personnel 9 en envoyant une requête 29 telle que décrite précédemment pour solliciter la fourniture d’un identifiant unique 18 de l’utilisateur 1 par la plateforme tierce 8. L’utilisateur 1 interagit avec la plateforme 8 pour déclencher l’envoi de la notification 30 contenant son identifiant 18 à la plateforme intermédiaire 4, qui consulte la base de données 36 pour extraire la clé publique 10 associée audit identifiant.
Dans cette troisième réalisation, le terminal 5, 5’ ou l’application 6 accède directement au coffre-fort personnel 9 et communique à la plateforme intermédiaire 4 les données personnelles 2 signées et chiffrées qui y sont enregistrées dans la requête en restauration 28. Ainsi, la plateforme centrale 4 extrait les données 2 signées et chiffrées directement depuis cette requête 28.
La plateforme intermédiaire 4 lance ensuite :
- par interaction avec la boîte noire 11, une procédure 32 similaire à celle des figures 1b et 2b pour déchiffrer les données 2 extraites de la requête 28 au moyen de la clé publique 12b de ladite boîte noire ; puis
- une procédure pour authentifier l’utilisateur 1 au moyen de la clé publique 7b’ communiquée dans cette même requête 28, en vérifiant que cette clé 7b’ est bien enregistrée dans le coffre-fort personnel 9 de l’utilisateur 1, et éventuellement, si la clé 7b’ n’est pas liée à la clé privée 7a de signature des données 2 déchiffrées, qu’une clé publique 7b liée à cette clé privée 7a est bien présente dans ledit coffre-fort personnel 9.
Enfin, de manière similaire aux précédentes réalisations, la boîte noire 11 lance :
- une procédure 33 pour rechiffrer les données 2 avec la clé publique 7b’ extraite de la requête en restauration 28 ;
- une procédure pour communiquer au terminal 5, 5’ ayant émis la requête 28 une notification 34 comprenant les données 2 ainsi rechiffrées, afin que ledit terminal ou l’application 6 lance une procédure 35 pour déchiffrer lesdites données avec la clé 7b’.
Dans chacun des modes de réalisation présentés ci-dessus, les étapes de chiffrement initial et d’enregistrement des données personnelles 2 de l’utilisateur 1 dans la chaîne de blocs 3, ainsi que l’étape d’authentification de l’utilisateur 1 lorsqu’il souhaite récupérer lesdites données, sont effectuées indépendamment du terminal 5 et/ou des clés privée 7a et publique 7b employées par ledit utilisateur au moment de la procédure d’enregistrement.
Ainsi, en cas de perte des clés 7a, 7b et/ou du terminal 5 ayant servi à cet enregistrement, l’utilisateur 1 peut récupérer ses données 2 enregistrées sur la chaîne de blocs 3 au moyen de nouvelles clés 7a’, 7b’ et/ou d’un nouveau terminal 5’. En outre, si la clé publique 7b correspondant à la clé privée 7a perdue de signature des données 2 a été initialement enregistrée dans un coffre-fort personnel 9 de l’utilisateur 1 sur la chaîne de blocs 3, le procédé peut utiliser cette ancienne clé publique 7b pour authentifier l’utilisateur 1, en dérivant la clé privée 7a de signature extraite desdites données et en comparant le résultat avec la(les) clé(s) publique(s) 7b, 7b’ de connexion à ladite chaîne de blocs enregistrée(s) dans ledit coffre-fort personnel, afin d’éviter le recours à une plateforme tierce 8 d’identification dudit utilisateur.
Sur les figures 1b à 3b, l’utilisateur 1 récupère ses données personnelles 2 chiffrées et signées enregistrées sur la chaîne de blocs 3 avec une clé publique 7b’ qui est distincte de la clé publique 7b liée à la clé privée 7a qu’il a utilisée pour signer lesdites données au moment dudit enregistrement, cette nouvelle clé publique 7b’ pouvant être enregistrée sur le même terminal 5 que celui utilisé lors dudit enregistrement ou sur un nouveau terminal 5’.
En variante non représentée, l’utilisateur 1 peut également requérir la restauration de ses données personnelles 2 chiffrées et signées au moyen de la clé publique 7b correspondant à la clé privée 7a avec laquelle il a signé lesdites données lors de leur enregistrement sur la chaîne de blocs 3.
Claims (14)
- Procédé pour permettre à un utilisateur (1) de sauvegarder des données personnelles sensibles (2) sur une chaîne de blocs, ledit procédé prévoyant de :
- signer les données personnelles (2) au moyen d’une clé privée (7a) liée à un terminal (5) de l’utilisateur ;
- chiffrer lesdites données personnelles avec une clé publique (12b) d'une boite noire transactionnelle (11) ;
- enregistrer les données personnelles (2) signées et chiffrées sur la chaîne de blocs (3) en les liant à l’utilisateur (1) ;
- envoyer une requête en restauration (28) comprenant une clé publique (7b’) liée à un terminal (5, 5’) de l’utilisateur (1) ;
- authentifier l’utilisateur (1) ;
- extraire les données personnelles (2) signées et chiffrées enregistrées sur la chaîne de blocs (3) ;
- déchiffrer les données personnelles (2) extraites avec la clé privée (12a) liée à la clé publique (12b) de la boite noire transactionnelle (11) ;
- rechiffrer lesdites données personnelles avec la clé publique (7b’) extraite de la requête en restauration (28) ;
- communiquer lesdites données personnelles rechiffrées audit terminal.
- Procédé selon la revendication 1, caractérisé en ce qu’il prévoit de signer et chiffrer ensemble les données personnelles (2) et un numéro aléatoire (17) généré en complément d’un identifiant unique (18) de l’utilisateur (1) fourni par une plateforme d’identité tierce (8), puis d’enregistrer lesdites données personnelles et ledit numéro aléatoire signés et chiffrés sur la chaîne de blocs (3), en les associant à une empreinte numérique (18’) dudit identifiant unique.
- Procédé selon la revendication 2, caractérisé en ce qu’il prévoit d’enregistrer les données personnelles (2) et le numéro aléatoire (17) signés et chiffrés par inscription directe dans la chaîne de blocs (3), en les associant à l’empreinte numérique (18’).
- Procédé selon la revendication 2, caractérisé en ce qu’il prévoit d’enregistrer les données personnelles (2) et le numéro aléatoire (17) signés et chiffrés dans un coffre-fort (14) de stockage collectif sur la chaîne de blocs (3), en les associant à l’empreinte numérique (18’).
- Procédé selon l'une quelconque des revendications 2 à 4, caractérisé en ce qu’il prévoit d’authentifier l’utilisateur (1) au moyen de l’identifiant unique (18), ledit identifiant unique étant communiqué en même temps que la requête en restauration (28) par interaction dudit utilisateur (1) avec la plateforme tierce (8).
- Procédé selon la revendication 1, caractérisé en ce qu’il prévoit d’enregistrer directement les données personnelles (2) signées et chiffrées dans un coffre-fort personnel (9) détenu par l’utilisateur (1) sur la chaîne de blocs (3).
- Procédé selon la revendication 6, caractérisé en ce qu’il prévoit d’authentifier l’utilisateur (1) au moyen de la clé publique (7b’) envoyée dans la requête en restauration (28), en vérifiant la présence de ladite clé publique dans un coffre-fort personnel (9) de l’utilisateur (1) sur la chaîne de blocs (3).
- Architecture pour permettre à un utilisateur (1) de sauvegarder des données personnelles sensibles (2) sur une chaîne de blocs (3), ladite architecture comprenant :
- une boîte noire transactionnelle (11) comprenant une paire de clés asymétriques privée (12a) et publique (12b), ladite boîte noire comprenant des moyens pour chiffrer et déchiffrer des données au moyen d’une clé de chiffrement (12a, 7b’) donnée ;
- au moins un terminal (5, 5’) comprenant, notamment au moyen d’une application (6) installée sur ledit terminal, des moyens pour permettre à l’utilisateur (1) de :
- signer ses données personnelles (2) au moyen d’une clé privée (7a) liée audit terminal ;
- chiffrer lesdites données personnelles avec la clé publique (12b) de ladite boite noire transactionnelle ;
- envoyer les données personnelles (2) signées et chiffrées sur la chaîne de blocs (3), afin de les enregistrer sur ladite chaîne de blocs en les liant à l’utilisateur (1) ;
- envoyer sur la chaîne de blocs (3) une requête en restauration (28) comprenant une clé publique (7b’) liée audit terminal, afin de récupérer ses données personnelles (2) enregistrées sur la chaîne de blocs (3) ;
- une plateforme intermédiaire (4) liée à la chaîne de blocs (3), ladite plateforme intermédiaire comprenant des moyens pour, après réception d’une requête en restauration (28) envoyée par un terminal (5, 5’) de l’utilisateur (1) :
- authentifier l’utilisateur (1) ;
- extraire les données personnelles (2) signées et chiffrées enregistrées sur la chaîne de blocs (3) ;
- communiquer à la boîte noire transactionnelle (11) les données personnelles (2) signées et chiffrées extraites et la clé publique (7b’) extraite de la requête en restauration (28), afin que ladite boîte noire transactionnelle :
- déchiffre les données personnelles (2) extraites avec la clé privée (12a) de ladite boite noire transactionnelle ;
- rechiffre lesdites données personnelles avec la clé publique (7b’) extraite de la requête en restauration (28) ;
- communique lesdites données personnelles rechiffrées au terminal (5, 5’) ayant envoyé ladite requête en restauration.
- Architecture selon la revendication 8, caractérisée en ce qu’elle comprend une plateforme d’identité tierce (8) apte à fournir un identifiant unique (18) pour l’utilisateur (1), la plateforme intermédiaire (4) comprenant des moyens pour :
- générer un numéro aléatoire (17) en complément dudit identifiant unique fourni par ladite plateforme tierce ;
- communiquer ledit numéro aléatoire à un terminal (5) de l’utilisateur (1), afin que ledit terminal signe et chiffre ensemble les données personnelles (2) et ledit numéro aléatoire ;
- enregistrer les données personnelles (2) et ledit numéro aléatoire signés et chiffrés sur la chaîne de blocs (3), en les associant à une empreinte numérique (18’) dudit identifiant unique.
- Architecture selon la revendication 9, caractérisée en ce que la plateforme intermédiaire (4) comprend des moyens pour enregistrer les données personnelles (2) et le numéro aléatoire (17) signés et chiffrés par inscription directe dans la chaîne de blocs (3), en les associant à l’empreinte numérique (18’).
- Architecture selon la revendication 9, caractérisée en ce que la chaîne de blocs (3) comprend un coffre-fort (14) de stockage collectif, la plateforme intermédiaire (4) comprenant des moyens pour enregistrer dans ledit coffre-fort collectif les données personnelles (2) et le numéro aléatoire (17) signés et chiffrés, en les associant à l’empreinte numérique (18’).
- Architecture selon l'une quelconque des revendications 9 à 11, caractérisée en ce que la plateforme intermédiaire (4) comprend des moyens pour authentifier l’utilisateur (1) au moyen de l’identifiant unique (18), ledit identifiant unique étant communiqué à ladite plateforme intermédiaire en même temps que la requête en restauration (28) par interaction dudit utilisateur (1) avec la plateforme tierce (8).
- Architecture selon la revendication 8, caractérisée en ce que le terminal (5) comprend des moyens pour enregistrer directement les données personnelles (2) signées et chiffrées dans un coffre-fort personnel (9) détenu par l’utilisateur (1) sur la chaîne de blocs (3).
- Architecture selon la revendication 13, caractérisée en ce que la plateforme intermédiaire (4) comprend des moyens pour authentifier l’utilisateur (1) au moyen de la clé publique (7b’) envoyée dans la requête en restauration (28), en vérifiant la présence de ladite clé publique dans un coffre-fort personnel (9) de l’utilisateur (1) sur la chaîne de blocs (3).
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2207041A FR3137769A1 (fr) | 2022-07-08 | 2022-07-08 | Procédé de sauvegarde de données personnelles sensibles sur une chaîne de blocs |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2207041 | 2022-07-08 | ||
| FR2207041A FR3137769A1 (fr) | 2022-07-08 | 2022-07-08 | Procédé de sauvegarde de données personnelles sensibles sur une chaîne de blocs |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3137769A1 true FR3137769A1 (fr) | 2024-01-12 |
Family
ID=83899943
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2207041A Pending FR3137769A1 (fr) | 2022-07-08 | 2022-07-08 | Procédé de sauvegarde de données personnelles sensibles sur une chaîne de blocs |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3137769A1 (fr) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020062668A1 (fr) * | 2018-09-29 | 2020-04-02 | 平安科技（深圳）有限公司 | Procédé d'authentification d'identité, dispositif d'authentification d'identité et support lisible par ordinateur |
| CN112989415A (zh) * | 2021-03-23 | 2021-06-18 | 广东工业大学 | 一种基于区块链的隐私数据存储与访问控制方法及系统 |
| US20220141014A1 (en) * | 2020-11-05 | 2022-05-05 | PolySign, Inc. | Storing secret data on a blockchain |
-
2022
- 2022-07-08 FR FR2207041A patent/FR3137769A1/fr active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020062668A1 (fr) * | 2018-09-29 | 2020-04-02 | 平安科技（深圳）有限公司 | Procédé d'authentification d'identité, dispositif d'authentification d'identité et support lisible par ordinateur |
| US20220141014A1 (en) * | 2020-11-05 | 2022-05-05 | PolySign, Inc. | Storing secret data on a blockchain |
| CN112989415A (zh) * | 2021-03-23 | 2021-06-18 | 广东工业大学 | 一种基于区块链的隐私数据存储与访问控制方法及系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3590223B1 (fr) | Procédé et dispositif pour mémoriser et partager des données intégrés | |
| US10659444B2 (en) | Network-based key distribution system, method, and apparatus | |
| US20050193198A1 (en) | System, method and apparatus for electronic authentication | |
| US20100313018A1 (en) | Method and system for backup and restoration of computer and user information | |
| US20070130462A1 (en) | Asynchronous encryption for secured electronic communications | |
| EP1908215A1 (fr) | Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d'ordinateur correspondants | |
| WO2012031755A2 (fr) | Procede d'authentification pour l'acces a un site web | |
| EP3446436A1 (fr) | Procédé d'obtention par un terminal mobile d'un jeton de sécurité | |
| EP2509025A1 (fr) | Procédé d'accès à une ressource protégée d'un dispositif personnel sécurisé | |
| FR3137769A1 (fr) | Procédé de sauvegarde de données personnelles sensibles sur une chaîne de blocs | |
| EP2071799B1 (fr) | Procédé et serveur pour l'accès a un coffre-fort électronique via plusieurs entités | |
| FR2901081A1 (fr) | Procede d'activation d'un terminal | |
| WO2017005644A1 (fr) | Procédé et système de contrôle d'accès à un service via un média mobile sans intermediaire de confiance | |
| FR2898423A1 (fr) | Procede securise de configuration d'un dispositif de generation de signature electronique. | |
| US20220239489A1 (en) | Identity verification program, identity verification method, user terminal, and user authentication program | |
| EP1262860B1 (fr) | Système et procédé d'authentification d'un utilisateur | |
| EP3166252A1 (fr) | Procédé d'enregistrement sécurisé de données, dispositif et programme correspondants | |
| FR2869176A1 (fr) | Procede de verification dans un terminal radio de l'authenticite de certificats numeriques et systeme d'authentification | |
| WO2022153005A1 (fr) | Procede et systeme de controle d'acces | |
| WO2024134037A1 (fr) | Procédé pour la sauvegarde et la restauration d'un secret détenu par un portefeuille de cryptoactifs | |
| EP3029878B1 (fr) | Procédé de transmission de secret à durée de vie limitée pour réaliser une transaction entre un terminal mobile et un équipement | |
| WO2024134040A1 (fr) | Procédé pour la sauvegarde et la restauration sécurisée d'une graine détenue par un portefeuille de cryptoactifs | |
| WO2023001846A1 (fr) | Procédé de transaction entre un organisme et un établissement sur une chaîne de blocs | |
| FR3144334A1 (fr) | Procédé pour la sauvegarde et la restauration sécurisée d'une graine détenue par un portefeuille de cryptoactifs | |
| FR3007929A1 (fr) | Procede d'authentification d'un utilisateur d'un terminal mobile |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20240112 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |