FR3035248A1 - Systeme-sur-puce a fonctionnement securise et ses utilisations - Google Patents

Systeme-sur-puce a fonctionnement securise et ses utilisations Download PDF

Info

Publication number
FR3035248A1
FR3035248A1 FR1553328A FR1553328A FR3035248A1 FR 3035248 A1 FR3035248 A1 FR 3035248A1 FR 1553328 A FR1553328 A FR 1553328A FR 1553328 A FR1553328 A FR 1553328A FR 3035248 A1 FR3035248 A1 FR 3035248A1
Authority
FR
France
Prior art keywords
wallet
chip
message
executable code
hash
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.)
Withdrawn
Application number
FR1553328A
Other languages
English (en)
Inventor
Enrico Maim
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to FR1553328A priority Critical patent/FR3035248A1/fr
Priority to CN202111067292.7A priority patent/CN113946817A/zh
Priority to CN201680011866.XA priority patent/CN107408174B/zh
Priority to PCT/IB2016/050440 priority patent/WO2016120826A2/fr
Priority to EP21164203.8A priority patent/EP3872666A1/fr
Priority to EP16712463.5A priority patent/EP3251046B1/fr
Publication of FR3035248A1 publication Critical patent/FR3035248A1/fr
Priority to US15/662,855 priority patent/US10715326B2/en
Priority to HK18105367.4A priority patent/HK1248005A1/zh
Priority to US16/894,961 priority patent/US11444768B2/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Un système-sur-puce (SoC) comprend en combinaison: - un processeur (Microcontroller), - un sous-système de codes exécutables quelconques (Wallet Programs) aptes à être exécutés par le système-sur-puce, - un sous-système de gestion des codes exécutables (Check/Load) comprenant un code exécutable spécifique de sélection/chargement desdits codes exécutables quelconques, - un sous-système d'entrée/sortie (I/O) permettant au système-sur-puce de communiquer avec d'autres systèmes-sur-puce, - un sous-système de messagerie permettant au système-sur-puce d'échanger des messages (Wallet Messages) avec d'autres systèmes-sur-puce , au moins certains des messages contenant le hash du contenu d'un code exécutable, - un sous-système de signature (Sign) des messages échangés, le système-sur-puce étant apte : * en réaction à la réception d'un message (Wallet Message), à amener ledit code exécutable spécifique de sélection/chargement à sélectionner et charger, à partir dudit sous-système de codes exécutables quelconques (Wallet Programs), le code exécutable quelconque dont le hash du contenu correspond audit hash inclus contenu dans ledit message (Wallet Message) ; * avant la signature d'un message (Wallet Message) à émettre, à amener le sous-système de signature (Sign) à vérifier le hash du code exécutable quelconque en cours d'exécution pour inclusion dans ledit message, garantissant ainsi que le même hash est re-propagé d'un message reçu à un message émis.

Description

1 Domaine de l'invention La présente invention concerne d'une façon générale la sécurisation des interactions entre dispositifs de traitement de données.
Arrière plan de l'invention On connaît déjà le procédé de « secure boot » en terminologie anglo-saxonne qui, dans un dispositif muni d'un processeur, à partir d'instructions sécurisées et non modifiables (dites « Roots of Trust », RoT) de chargement d'un code exécutable, vérifie la signature numérique du code exécutable en question avant d'autoriser son exécution. Ce procédé est notamment mis en oeuvre dans les puces TPM (Trusted Platform Module) sur des cartes-mères d'ordinateurs pour rassurer les utilisateurs propres de ces ordinateurs de l'authenticité du code qui s'y exécute, sous réserve de manipulations telles que le « cuckoo attack » [Bryan Parno, « Bootstrapping Trust in a "Trusted" Platform », 2008]. Résumé de l'invention La présente invention vise à proposer un procédé et un système permettant de sécuriser, de manière plus efficace et moins couteuse que ce qu'offre l'état de l'art, les interactions entre des dispositifs munis d'un processeur. Selon l'invention, en réaction à la réception d'un message par un dispositif muni d'un processeur, des instructions sécurisées et non modifiables (analogues au RoT) chargent un code exécutable dont le code de hachage (c'est-à-dire le résultat de l'application d'une fonction de hachage cryptographique sur son contenu) correspond à un code de hachage inclus dans ledit message reçu. L'exécution qui suit de ce code exécutable, dans ledit dispositif, est ainsi prédéterminée par rapport à ce message reçu. Le code exécutable ainsi imposé par l'émetteur du message est quelconque et apte à mettre à jour des variables d'état et générer encore 3035248 2 d'autres messages qui vont eux-mêmes propager ce même code de hachage vers encore d'autres tels dispositifs. L'invention permet ainsi de garantir des « contrats » (« smart contract ») que représentent lesdits codes exécutables. En effet, le procédé 5 et le système de l'invention garantissent (i) que le dispositif récepteur d'un tel message réagit selon le « smart contract » que ce message impose et (ii) que ce message a lui-même été généré dans le cadre du même « smart contract » (puisque produit par le même code exécutable). Dans une application, le procédé et système de l'invention visent à 10 permettre de mettre en oeuvre des protocoles transactionnels équivalents à Bitcoin ou ses descendants (tels que Ethereum), avec ou sans l'utilisation d'une chaîne de blocs, sans besoin d'attente de confirmations de transactions (qui, selon l'approche adoptée, prennent aujourd'hui de l'ordre de la dizaine de secondes à la dizaine de minutes chacune) et avec des 15 volumes de transactions théoriquement illimités (alors que Bitcoin est aujourd'hui limité à 7 transactions par seconde environ - par comparaison, le réseau Visa est conçu pour opérer avec des pics de volumes de 10,000 transactions par seconde). Plus particulièrement, on propose selon l'invention un système-sur- 20 puce (SoC), caractérisé en ce qu'il comprend en combinaison: - un processeur (Microcontroller), - un sous-système de codes exécutables quelconques (Wallet Programs) aptes à être exécutés par le système-sur-puce et par d'autres systèmes-sur-puce, 25 - un sous-système de gestion des codes exécutables (Select/Load) comprenant un code exécutable spécifique de sélection/chargement desdits codes exécutables quelconques, - un sous-système d'entrée/sortie (I/O) permettant au système-sur- puce de communiquer avec d'autres systèmes-sur-puce pour échanger des 30 des messages (Wallet Messages) avec d'autres systèmes-sur-puce, au 3035248 3 moins certains des messages contenant le hash du contenu d'un code exécutable, - un sous-système de signature (Sign) des messages échangés, apte à générer un hash d'un code exécutable couramment chargé dans le 5 système-sur puce, le système-sur-puce étant apte : * en réaction à la réception d'un message (Wallet Message) contenant un hash, à amener ledit code exécutable spécifique de sélection/chargement à sélectionner et charger pour exécution, à partir dudit sous-système de 10 codes exécutables quelconques (Wallet Programs), le code exécutable quelconque dont le hash du contenu correspond audit hash inclus contenu dans ledit message (Wallet Message) ; avant la signature d'un message (Wallet Message) à émettre, à amener le sous-système de signature (Sign) à générer ou à vérifier le hash 15 du code exécutable quelconque couramment chargé pour inclusion dans ledit message, garantissant ainsi que le même hash est re-propagé d'un message reçu à un message émis. De façon avantageuse mais facultative, le système-sur-puce comprend une mémoire rémanente pour un ensemble de variables d'état, 20 seul le code exécutable (Wallet Program) possédant une variable d'état étant apte à la modifier. Selon une autre caractéristique avantageuse mais facultative, une clé privée est mémorisée de façon rémanente dans le système-sur-puce, une clé publique de signature (certificat) associée à la clé privée étant partagée entre 25 une pluralité de systèmes-sur-puce d'un même fabricant, aptes à communiquer entre eux, et ladite clé privée étant utilisée pour signer les messages. L'invention propose également l'utilisation d'au moins un système-sur- puce tel que défini ci-dessus pour réaliser une identification anonyme à partir 30 de documents d'identité à partir desquels peuvent être lues des signatures officielles.
3035248 4 L'invention propose aussi l'utilisation de deux systèmes-sur-puce tels que définis ci-dessus, pour réaliser un transfert d'unités de valeur par débit d'un solde (Balance) constitué par une variable d'état dans l'un des systèmes-sur-puce et crédit d'un solde constitué par une variable d'état dans 5 l'autre système-sur-puce. Avantageusement mais facultativement, ces utilisations peuvent mettre également en oeuvre au moins un système-sur-puce témoin associé à un système-sur-puce d'identification ou de transfert de valeur et apte répliquer au moins en partie les opérations exécutées dans ce dernier.
10 On propose enfin selon l'invention un dispositif de traitement de données, comprenant des moyens de traitement et de mémorisation et des moyens de communication avec d'autres dispositifs de traitement de données, caractérisé en ce qu'il comprend un système-sur-puce tel que défini ci-dessus et un canal de communication bidirectionnelle filaire ou sans 15 fil entre les moyens de traitement et le système-sur-puce, ce dernier étant apte à échanger des messages avec d'autres systèmes-sur-puce via lesdits moyens de communication du dispositif. Dans une première implémentation, le système-sur-puce est logé dans une unité distincte du dispositif de traitement.
20 Dans une autre implémentation, le système-sur-puce est intégré au dispositif de traitement. Brève description des figures D'autres aspects, buts et avantages de la présente invention 25 apparaîtront mieux à la lecture de la description détaillée suivante de formes de réalisation préférées de celle-ci, donnée à titre d'exemple non limitatif et faite en référence aux dessins annexés, sur lesquels : La Figure 1 illustre schématiquement les constituants d'une puce électronique implémentant un Wallet Node selon l'invention, 30 La Figure 2 illustre schématiquement un processus d'identification anonyme à partir d'un passeport selon l'invention, 3035248 5 La Figure 3 illustré schématiquement un procédé de paiement d'unités de valeur mettant en jeu deux Wallet Nodes selon l'invention, La Figure 4 illustre schématiquement un procédé de blocage d'unités de valeur mettant en jeu un Wallet Node « aidant » et un Wallet Node 5 « aidé », La Figure 5 illustre la mise en oeuvre d'un nonce cryptographique en relation avec un Wallet Node, et La Figure 6 illustre un procédé de transfert d'unités de valeur entre Wallet Nodes, mettent en jeu en outre des Wallet Nodes « témoins ».
10 Description détaillée de formes de réalisation préférées Définitions Hash : Code de hachage - c'est le résultat de l'application d'une fonction de 15 hachage prédéterminée (sur un contenu donné), telle que SHA-256. SoC : Système sur une puce (System on Chip) - c'est un circuit intégré qui intègre tous les composants nécessaires à des programmes d'ordinateur. Description 20 Le système et procédé de l'invention visent tout d'abord à garantir le fonctionnement d'un SoC d'un type particulier appelé « Wallet Node » (ou Noeud-Valeur) comprenant au moins les sous-systèmes suivants : un processeur (« Microcontroller » ou Micro-contrôleur), un sous-système « Wallet Programs » comprenant des codes 25 exécutables quelconques dénommés « Wallet Program » (ou Programme-Valeur) aptes en particulier des variables d'état « Persistent State Variables » qui leurs sont exclusifs, un sous-système « Select / Load » (ou Sélectionne/Charge) comprenant un code exécutable spécifique de sélection et chargement de 30 Wallet Program, 3035248 6 un sous-système de signature « Sign » (ou Signe - du verbe Signer) de messages « Wallet Message » (ou Message-Valeur) échangés entre Wallet Nodes, et offrant encore d'autres fonctions cryptographiques, un sous-système d'entrée/sortie « I/O » (ou E/S) apte à recevoir une 5 entrée comprenant le hash du contenu d'un code exécutable. Un « Manifest » (ou Manifeste) est associé à chaque Wallet Program, pour spécifier la nature et la structure de ses entrées via le sous-système I/O. Chaque Wallet Node est couplé à un dispositif tel que smart phone ou ordinateur avec lequel il est apte à communiquer via le sous-système I/O.
10 Les Wallet Nodes sont aptes à interagir les uns avec les autres en réseau et, via le sous-système I/O (et le cas échéant via les dispositifs respectifs avec lesquels ils sont couplés, ceci dépendant du mode de réalisation), les Wallet Nodes sont aptes à s'échanger des Wallet Messages 15 comprenant également le hash du contenu d'un code exécutable, et en réaction à la réception d'un Wallet Message - respectivement en réaction à ladite entrée (comprenant le hash du contenu d'un code exécutable) -, ledit code exécutable Select/Load sélectionne et charge, à partir dudit sous-système Wallet Programs, le Wallet Program spécifique 20 dont le hash du contenu correspond audit hash inclus dans ladite entrée - respectivement dans ledit Wallet Message. Pour chaque émission d'un Wallet Message lors de l'exécution d'un Wallet Program, avant de signer ledit Wallet Message, le sous-système Sign génère (ou vérifie) le hash (dudit Wallet Program en cours d'exécution) que 25 doit comprendre ledit Wallet Message, garantissant ainsi que le même hash est repropagé de message en message. Ledit message (Wallet Message) peut avantageusement inclure la signature (certificat) par le fabricant de la clé publique du Wallet Node au moyen de laquelle ladite signature a été générée par le sous-système Sign.
30 Enfin, dans un mode de réalisation particulier, le réseau en question comprend des Wallet Nodes (sécurisés) et des Wallet Nodes non-sécurisés.
3035248 7 Au moins à chaque « Wallet Node non sécurisé » correspond au moins un « Wallet Node témoin » apte à valider ses modifications de variables d'état. Le fait d'avoir au moins un Wallet Node témoin qui valide les mise-à-jour de variables d'état, permet de ne pas exiger que le Wallet Node 5 (dont il est témoin) soit mis en oeuvre de manière sécurisée selon le SoC de la présente invention, et offre encore d'autres avantages, comme décrit plus loin. Un Wallet Node non sécurisé peut être mis en oeuvre directement dans un ordinateur ou un smartphone classique, ou encore en tirant parti de technologies génériques de sécurisation telles que ARM® TrustZone®.
10 Lesdites clés de signature des Wallet Nodes sécurisés sont certifiées par leur fabricant : la signature par le fabricant de ces clés est publique et disponible (mais peut néanmoins être aussi incluse dans la Wallet Message en question). Dans la suite, par « Wallet Node », on entend « Wallet Node 15 sécurisé » à moins de préciser qu'il ne l'est pas. On va maintenant décrire les Wallet Nodes en détail en en présentant les différentes caractéristiques. A chaque Wallet Node est associée une paire de clés cryptographiques publique/privée : 20 - la clé privée est secrète (c'est-à-dire cachée dans la puce et non connue hors de la puce) - elle est soit gravée dans la puce comme dans les TPM ou les cartes à puce, soit stockée de manière sécurisée, soit automatiquement générée dans la puce selon la technologie « PUF » (Physically Unclonable Function) introduite dans [P. S. Ravikanth, « Physical 25 one-way functions », PhD Thesis, MIT, 2001] et [Pappu& al., « Physical one- way functions, Science, 297(5589):2026-2030, 2002] et mise en oeuvre notamment dans les SoC FPGA Smartfusion2 et d'autres puces du fabricant Microsemi, ou selon une technique analogue ; - la clé publique est signée par le fabricant (pour certifier que la puce 3 0 est bien une Wallet Node).
3035248 8 Chaque Wallet Message émis par une Wallet Node comprend, outre un contenu de message proprement dit, - le hash du Wallet Program qui a généré ce Wallet Message ; - la signature par ce Wallet Node dudit hash, ainsi que du contenu 5 proprement dit du Wallet Message, pour signifier : « ce message a bien été généré par ce Wallet Program tournant dans ce Wallet Node » - la clé publique correspondant à la clé privée ayant servi à cette signature est également jointe ; - (et la clé publique correspondant à la clé privée du Wallet Node, ayant 10 servi à cette signature, est elle-même certifiée par le fabricant, comme déjà mentionné - le Wallet Message peut inclure cette signature ainsi que la clé du fabricant). Ladite signature (dudit hash et du contenu proprement dit du Wallet Message) est effectuée par le sous-système Sign qui génère ledit hash à 15 partir du contenu du Wallet Program en cours d'exécution. L'architecture du système garantit ainsi que le hash figurant dans les Wallet Messages est bien le hash du Wallet Program qui l'a généré. Les Wallet Nodes proviennent d'un même fabricant ou d'un ensemble de fabricants mutuellement agréés. Lorsqu'un Wallet Message est reçu par 20 un Wallet Node, ce dernier vérifie que la clé publique permettant de déchiffrer ladite signature (censée être produite par le Wallet Node émetteur de ce Wallet Message) est certifiée par un fabricant agréé (et ignore ce Wallet Message dans le cas contraire). Ainsi, le système et le procédé de l'invention garantissent que, 25 lorsqu'un Wallet Node communique un Wallet Message à un Wallet Node destinataire (le cas échéant via les dispositifs respectifs, tels que smart phone ou ordinateur, auxquels ils sont couplés) et que ledit Wallet Message est vérifié par ledit Wallet Node destinataire, - ledit Wallet Message a été généré par un Wallet Program dont le hash 30 est inclus dans ledit Wallet Message lui-même ; 3035248 9 - ledit Wallet Message n'a pas été altéré - en effet, l'intégrité du Wallet Message est garantie par le fait que le Wallet Message a été signé par le Wallet Node qui l'a produit et que cette signature est certifiée par un fabricant agréé ; 5 - l'authenticité dudit Wallet Message est aussi garantie (du fait que la clé de signature de la part du Wallet Node est certifiée par un fabricant agréé, c'est-à-dire signée par ce dernier) - cette authenticité signifie non seulement que le Wallet Node est ainsi identifié mais aussi que ce Wallet Node qui est identifié a bien exécuté ledit Wallet Program pour générer ce 10 Wallet Message. Ledit Wallet Node destinataire qui reçoit le Wallet Message y réagit nécessairement en exécutant le même Wallet Program (ceci est décrit plus bas lors de la présentation du sous-système Select/ Load). Dans la mesure où les Wallet Messages sont chiffrés (avec la clé 15 publique du Wallet Node destinataire, par exemple dans le cadre d'un protocole de messagerie tel que TeleHash) et donc non dévoilés avant leur prise en charge par le Wallet Node destinataire, on décourage des volontés éventuelles de filtrage ayant pour but d'empêcher leur réception (et dès le moment où ces Wallet Messages sont décryptés par le Wallet Node 20 destinataire, le code exécutable Select / Load se charge de faire exécuter le même Wallet Program imposé par ce Wallet Message décrypté, ceci s'effectue automatiquement). Chaque Wallet Node est couplé avec un dispositif tel qu'un smartphone sous système d'exploitation Android® ou avec un ordinateur, par 25 des canaux d'entrée sortie appropriés. Plusieurs modes de réalisation sont possibles pour ce couplage, notamment : - le Wallet Node peut être couplé au smartphone par Wifi, Bluetooth, Bluetooth LE, NFC, etc. et toute technologie de communication sans fil existante ou à venir, 30 - le Wallet Node peut être un composant ARA dans le cadre de Project ARA proposé par Google, 3035248 10 - le Wallet Node peut être mis en oeuvre dans un dispositif portatif selon le protocole filaire USB ou toute technique de communication filaire existante ou à venir. Le Wallet Node est ici implémenté sous forme d'une puce ayant les 5 parties suivantes (sous-systèmes) qui sont schématiquement représentées sur la Figure 1 : I/O- - Microcontroller - Select / Load 10 - Wallet Programs - Pers. State Variables - Sign - (Secret Key) Le Wallet Node est mis en oeuvre en un « système-sur-puce » (SoC - 15 System on Chip) garantissant la non altération des restrictions d'accès (énoncés ci-après) entre ses différentes parties, système auquel des entrées/sorties (I/O) sont fournies par un dispositif (Computer or Smartphone) tel qu'un smartphone ou un ordinateur. Au sein du SoC se trouve un microcontrôleur (Microcontroller) 20 comprenant un processeur généraliste (« general-purpose processor », tel qu'un processeur implémentant l'architecture ARM v7-M) muni d'une mémoire interne. Seul ce processeur peut accéder à la partie « Sign » fournissant des fonctions cryptographiques, notamment la fonctionnalité de signature par la puce, cette dernière étant à son tour la seule à pouvoir 25 accéder à la partie contenant la clé secrète de la puce (Secret Key). Alternativement, la technologie PUF (déjà mentionnée plus haut) permet d'éviter de stocker la clé secrète et ne la générer que sur demande (au sein de la partie Sign). En plus, des fabricants tels que Microsemi fournissent encore d'autres moyens (des moyens d'offuscation) permettant de ne jamais 30 voir la clé secrète in extenso. Ces options possibles sont les raisons pour lesquelles la partie « (Secret Key) » est présentée entre parenthèses dans la 3035248 11 figure puisque dans certaines options de mise en oeuvre la clé secrète n'est pas stockée. La partie Wallet Programs mémorise des Wallet Programs ainsi que leurs hash respectifs. Le Microcontroller charge dans sa mémoire de manière 5 sécurisée, en fonction du hash du Wallet Message entrant (ou de l'entrée via 1'1/0) comme décrit ci-après, l'un ou l'autre de ces Wallet Programs. Ces derniers sont aptes à manipuler, dans une mémoire non volatile, des variables d'état persistantes (Pers. State Variables) qui ne sont accessibles que par le Microcontroller. Le sous-système Pers. State Variables ne rend 10 accessible lesdites Pers. State Variables que seulement pour l'exécution des Wallet Programs respectifs spécifiques auxquels ces variables appartiennent. Ces variables d'état ne peuvent ainsi être accédées/manipulées que (exclusivement) par leurs Wallet Program respectifs.
15 Au power-up et power-reset, le code exécutable stocké dans la partie « Select/Load » est le premier à être chargé et exécuté dans le Microcontroller, et des hash sont alors associés aux Wallet Programs disponibles dans la partie « Wallet Programs ». Lorsqu'un Wallet Message arrive (via l'1/0), cette partie Select / Load en vérifie l'intégrité et l'authenticité 20 (la clé publique du Wallet Node émetteur de ce Wallet Message est utilisée pour (i) décrypter la signature par ce Wallet Node émetteur, (ii) vérifier l'intégrité du message et (iii) obtenir le hash du Wallet Program ; la clé de la signature de certification du fabricant est vérifiée et la clé publique qu'elle certifie comme étant une clé de Wallet Node permet de confirmer 25 l'authenticité dudit Wallet Message), le Wallet Program correspondant audit hash est, le cas échéant, sélectionné dans la partie « Wallet programs » et chargé pour exécution. L'émission de Wallet Message, le cas échéant, par ledit Wallet program, se fait par l'intermédiaire de la partie Sign qui vérifie le hash inséré dans le Wallet Message avant de le signer. Par ailleurs, un 30 « Manifest » déclarant les entrées (via la partie « I/O ») prévues pour un Wallet Program est associé à ce dernier ; à chaque entrée I/O un hash du 3035248 12 Wallet Program visé doit être associé ; et lors d'une entrée I/O, sa conformité (au Manifest) est vérifiée par le code exécutable « Select / Load » avant que le Wallet Program correspondant audit hash soit, le cas échéant, sélectionné dans la partie « Wallet programs » et chargé pour exécution.
5 En variante, le code exécutable qui est chargé dans le Microcontroller n'est pas le Wallet Program en entier dont le hash est fournit dans le Wallet Message, mais une partie seulement (un module) de ce Wallet program, et pour le permettre l'information fournit dans le Wallet Message peut avantageusement inclure, en plus du hash de l'ensemble de tels modules, la 10 spécification du ou des modules qui sont susceptibles de réagir au Wallet Message. Dans la suite de ce texte, on considère pour simplifier et de façon non limitative que le Wallet Program est chargé en entier. Par ailleurs, les Wallet Programs (ou leurs modules) peuvent être organisés en versions ; les hash de versions précédentes accompagnent 15 alors le hash du Wallet Program fournit dans le Wallet Message et, pour chaque variable d'état (Persistent State Variables) stocké dans la puce, le hash de la version courante du Wallet Program qui l'a dernièrement manipulée lui est associé. Ainsi les variables d'états d'un Wallet Program peuvent être mis à jour par celui-ci même lorsque sa version évolue.
20 A noter que cette puce peut être mise en oeuvre en une carte à puce, ou dans un SoC (« customizable SoC FPGA ») classique du marché tel que le SmartFusiore2, du fabricant Microsemi, offrant une partie FPGA (Field Programmable Gate Array) sécurisable, dans lequel peut avantageusement être généré une clé secrète SRAM PUF (« physically unclonable function 25 (PUF) key enrollment and regeneration capability from Intrinsic ID ») et qui inclut au sein même de la puce, en technologie ASIC, un micro-contrôleur (processeur ARM° CortexTm-M3 implémentant l'architecture ARM v7-M) avec sa mémoire interne. Bien évidemment, l'architecture de l'invention peut aussi être mise en 30 oeuvre entièrement en ASIC ou en encore d'autres technologies de fabrication de puces.
3035248 13 On va maintenant décrire divers protocoles d'interaction entre Wallet Nodes. On va dans la suite considérer qu'initialement un Wallet Program est déclenché par l'arrivée d'une entrée I/O à partir d'un smartphone avec lequel 5 un Wallet Node est couplé. Cette entrée comprend le hash du Wallet Program à exécuter, des paramètres d'entrée, tels qu'un montant ou l'adresse (ou clé publique) d'un Wallet Node destinataire d'un Wallet Message qui est à émettre, ainsi que le moyen de l'émettre (on peut par exemple prévoir de l'envoyer par email). Comme déjà décrit, le code 10 « Select/Load » vérifie la conformité de l'entrée I/O au « Manifest » associé au Wallet Program visé par cette entrée I/O, avant que ce dernier soit sélectionné (dans la partie Wallet Programs) et chargé pour exécution. Toutefois, cette sélection et chargement ne se font que si le Wallet Program en question est déjà stocké (dans la partie Wallet Programs). Pour simplifier 15 la description, on considère dans la suite que le Wallet Program visé par l'entrée en question est déjà stocké. On va tout d'abord décrire un procédé d' « identification anonyme » en utilisant le système et le procédé de l'invention. Selon [http://en.wikipedia.org/wiki/Biometric_passport], un passeport 20 électronique comprend une puce permettant aux données du passeport d'être transférées par la technologie sans fil RFID. Les caractéristiques de la puce sont documentées dans le document 9303 de l'Organisation de l'aviation civile internationale (OACI). La puce contient un fichier (SOD) qui stocke les hash de tous les fichiers stockés dans la puce (photo, empreintes 25 digitales, etc.) ainsi qu'une signature numérique de ces hash. La signature numérique est réalisée en utilisant une clé de signature de document qui est elle-même signée par une clé de signature de pays. Les lecteurs RFID doivent avoir la liste de toutes les clés publiques de pays utilisés pour vérifier si la signature numérique est générée par un pays.
30 Pour simplifier la description (l'extension au cas réel étant triviale), supposons qu'un passeport électronique comprenne une puce RFID (qui 3035248 14 peut être lue par un lecteur RFID), et que cette puce présente le contenu du passeport signé par un gouvernement dont la clé publique est connue, ainsi que cette clé publique. Ainsi, par le biais de la partie I/O (à partir du smartphone du 5 possesseur du passeport, avec lequel un Wallet Node est couplé), les données suivantes sont communiquées à ce Wallet Node: le contenu du passeport, la signature par le gouvernement du contenu de passeport, la clé publique du gouvernement correspondant à cette signature, l'adresse (la clé publique) du Wallet Node destinataire du Wallet Message à émettre (pour communiquer le résultat de l'identification anonyme à effectuer) et le mode de communication de ce Wallet Message à ce destinataire, en l'occurrence on considère ici qu'il s'agit du protocole TeleHash (ou analogue) et le Wallet Message est chiffré avec la clé publique 15 du Wallet Node destinataire, - le hash du Wallet Program visé (l'application d'identification anonyme). Le Select/Load analyse cette entrée I/O, vérifie que ledit hash du Wallet Program correspond bien à un Wallet Program stocké (dans la partie Wallet Programs de la puce) et vérifie la conformité de cette entrée par 20 rapport aux paramètres d'entrée spécifiés dans le Manifest associé à ce Wallet Program. Une fois chargé dans le Microcontroller, le Wallet Program est exécuté et effectue les étapes suivantes : 1. Vérifier si la clé publique du gouvernement est authentique (en 25 vérifiant si elle est incluse dans une liste de clés publiques de gouvernement connus); 2. Vérifier si la signature peut être décryptée avec cette clé; 3. Obtenir le hash résultant de ce décryptage; 4. Vérifier si le hash du contenu de passeport est le même que le hash 30 résultant du décryptage de la signature, et 10 - - - - 3035248 15 5. Produire un Wallet Message pour le destinataire spécifié, avec seulement ce hash en guise d'identifiant anonyme fourni (le contenu de passeport n'est pas révélé). Outre ce contenu proprement dit, le Wallet Message comprend le hash dudit Wallet Program, ainsi que la signature par 5 le Wallet Node de ce contenu proprement dit et de ce hash du Wallet Program. En conséquence, le titulaire du passeport est identifié avec seul le hash du contenu de ce passeport (et donc de manière anonyme). En variante, au lieu de communiquer (dans le Wallet Message) le 10 hash du contenu de passeport, le Wallet Program communique le hash du {contenu de passeport + une autre chaîne donnée}, cette dernière peut par exemple être le mois et l'année en cours (en l'occurrence, l'identification générée ne servira alors que pendant le mois en cours), offrant ainsi un degré plus élevé d'anonymat. A noter que, dans ce cas, si cet identifiant est 15 utilisé plusieurs fois dans le même mois, l'utilisateur ne pourra cacher qu'il s'agit de l'identification de la même personne, ce qui correspond bien à la fonction attendue d'un identifiant. Ledit Wallet Node destinataire (receveur dudit Wallet Message) va trouver cet identifiant anonyme au sein dudit Wallet Message reçu après 20 l'avoir décrypté (si l'option de chiffrage du Wallet Message est adopté). Voici donc les étapes à la réception de ce Wallet Message (après l'avoir décrypté) : Au sein du Wallet Node receveur, le code Select / Load sélectionne le Wallet Program correspondant au hash (de Wallet Program) reçu et le 25 charge dans le Microcontroller. Le Wallet Program est exécuté pour communiquer l'identifiant anonyme au smartphone via 1'1/0. A noter que cette même application d'identification anonyme à partir d'un passeport peut se faire avec seulement un Wallet Node pour le titulaire du passeport (sans avoir besoin d'un deuxième Wallet Node pour le 30 récepteur de l'identifiant anonyme), le Wallet Program communiquant au smartphone via 1'1/0 l'identifiant anonyme du titulaire du passeport, ainsi que 3035248 16 le Wallet Program utilisé, dûment signés par le Wallet Node (dont la clé est certifiée par le fabricant). L'utilisateur du smartphone auquel le Wallet Node est couplé pourra ensuite se faire valoir de cet identifiant anonyme en le communiquant à un destinataire par un moyen de son choix (par exemple 5 par email) et ce destinataire pourra vérifier que l'identifiant anonyme a bien été généré par le bon Wallet Program (non altéré vis-à-vis de son hash) puisque généré dans un Wallet Node qui a signé que c'est le cas, Wallet Node lui-même digne de confiance puisque certifié par le fabricant dont la clé est elle-même vérifiable. (Mais évidemment, il est plus aisé de passer par un 10 Wallet Node 2 qui prend toutes ces vérifications en charge automatiquement.) La Figure 2 présente schématiquement ce procédé. On y voit que le contenu du passeport lu par RFID sur le smartphone est fourni au Wallet Node 1 via son I/O, avec le hash « #Wallet Pgm ». A réception de cette 15 entrée I/O, le Wallet Node 1 exécute le Wallet Program « Wallet Pgm » (dont le hash est celui communiqué dans la même entrée I/O), pour (i) vérifier la signature du gouvernement « Govt Signature » dans le contenu du passeport, (ii) générer l'identifiant anonyme « Anonymous ID » et finalement (iii) émettre un Wallet Message « Wallet Msg » comprenant « Anonymous 20 ID » et le même hash « #Wallet Pgm » à destination de Wallet Node 2. De façon non illustrée, « Anonymous ID, #Wallet Pgm » est signé par Wallet Node 1, dont la clé est certifiée par le fabricant (certification qui peut aussi être communiquée dans Wallet Msg), et avantageusement Wallet Msg peut être chiffré avec la clé publique de Wallet Node 2. Enfin, Wallet Node 2 reçoit 25 Wallet Msg (et le décrypte), sélectionne ainsi le même Wallet Program « Wallet Pgm » pour transmettre Anonymous ID au smartphone via l'1/0 pour affichage (« Display the Anonymous ID »). Dans le Wallet Node 1, au lieu de baser l'identification sur une signature numérique d'un gouvernement, on peut bien entendu la baser sur 30 une signature fournie par un dispositif d'identification biométrique.
3035248 17 Il est à noter ici que le fait de pouvoir identifier les utilisateurs (de manière anonyme et minimale, c'est-à-dire sans restreindre leur privacy) est pertinent vis-à-vis de la technologie de la chaîne de blocs (de Bitcoin et ses descendants incluant le procédé Proof-of-Work ou analogue) évoquée dans 5 l'introduction. En effet, le Proof-of-Work est nécessaire tant que l'on ne peut pas identifier les utilisateurs qui effectuent les transactions et estimer leur nombre. Si on peut les identifier et estimer leur nombre, il suffit d'obtenir une majorité à plus de 50% pour garantir le consensus sur les transactions effectuées. Un protocole mis en oeuvre sur Wallet Nodes est décrit à la fin de 10 ce texte pour la formation d'une communauté en P2P (de pair à pair). Ce protocole peut être adapté dans ce sens. On va maintenant décrire un procédé très simple de paiement d'unités de valeur de la part d'un premier Wallet Node en faveur d'un second Wallet Node. On remarquera que la sécurisation de la bonne exécution de Wallet 15 Programs au niveau des Wallet Nodes rend impossible le « double- spending » (contre lequel les technologies de construction de Chaîne de blocs de Bitcoin et ses descendants apportent une solution - ainsi le problème que ces technologies tentent de résoudre, c'est-à-dire leur raison d'être, n'existe tout simplement plus).
20 La Figure 3 présente schématiquement le cas d'un Wallet Program « Wallet Pgm » qui dans « Wallet Node 1 » prend comme entrée I/O un paiement de 10 unités de valeur, en faveur de « Wallet Node 2 », et soustrait en conséquence 10 unités d'une variable d'état « Balance » (signifiant ici le solde d'unités de valeur disponibles dans ce Wallet Node). Ici encore, la 25 figure ne montre pas que dans le Wallet Message « Wallet Msg » généré, le contenu du message proprement dit « +10 » et le hash « #Wallet Pgm » sont signés par Wallet Node 1, dont la clé de signature est certifiée par le fabricant. Le receveur (Wallet Node 2) de Wallet Msg y réagit en sélectionnant (par Select/Load) le même Wallet Program « Wallet Pgm » qui 30 ajoute 10 unités à sa propre variable d'état « Balance » et fournit (au 3035248 18 smartphone auquel il est couplé), via 1'1/0, la nouvelle valeur de la variable Balance ainsi que la source Wallet Node 1 de sa mise à jour. Dans la mesure où, automatiquement, pour chaque paiement d'un montant donné, un Wallet Program spécifique (en l'occurrence, « Wallet 5 Pgm ») soustrait ce montant dans la variable d'état « Balance » (solde disponible), et puisque seul ledit Wallet Program spécifique peut manipuler cette variable d'état, un « double-spending » est impossible. On va maintenant décrire un procédé « P2P Insurance » consistant en deux étapes : (1) un blocage d'unités de valeur par un Wallet Node 10 « aidant » en faveur d'un Wallet Node « aidé » et une émission par ce Wallet Node aidant d'un Wallet Message vers ce Wallet Node aidé indiquant ce blocage et (2) paiement par le Wallet Node aidant (à noter que dans le cas réel, il y aura plusieurs Wallet Nodes aidants) sur réception d'un Wallet Message « Claim » de la part d'un Wallet Node aidé muni d'une signature 15 (prévue d'avance) d'un arbitre pour valider le Claim en question. La Figure 4 présente schématiquement ces deux étapes : l'étape de blocage et l'étape d'aide lors de la présentation d'un Claim. Dans l'étape de blocage (Step 1), Wallet Node 1 bloque 10 unités de valeur comme aide potentielle de Wallet Node 2. Ainsi, le Wallet Program 20 « p2p lnsurance » augmente la variable d'état Refill[WN2] de 10 unités de valeurs (WN2 signifiant Wallet Node 2) et génère le Wallet Message « Wallet Msg 1 » informant Wallet Node 2 de cette aide potentielle de +10. Wallet Node 2 le reçoit, le décrypte et met à jour d'une part une variable d'état mémorisant que Wallet Node 1 l'aide potentiellement pour +10 et que d'autre 25 part la variable d'état « Help » (aide potentielle totale) est augmentée de 10. L'étape (Step 2) de paiement sur présentation de « Claim » est initiée par « l'aidé » Wallet Node 2 qui au préalable recueille la signature de l'arbitre, pour un Claim de 5 unités de valeur à verser à Wallet Node 3, et notifie les aidants, en l'occurrence Wallet Node 1 seulement (par le Wallet Message 30 « Wallet Msg 2 ») qui inclut ladite signature recueillie et le montant du Claim en question. Dès que Wallet Msg 2 est reçu et décrypté pour y trouver le 3035248 19 hash « #p2pinsurance », le code « Select / Load » de Wallet Node 1 sélectionne le Wallet Program « p2pinsurance » (ayant ce hash #p2pinsurance) qui, après avoir vérifié ladite signature de l'arbitre, effectue le paiement de 5 unités de valeur à Wallet Node 3.
5 Dans le protocole mis en oeuvre, le Wallet Node aidant (Wallet Node 1) ne peut fuir ses engagements (de payer en cas de « Claim » justifié par signature de l'arbitre). En effet, d'une part le Wallet Message reçu « Wallet message 2 » est chiffré et il n'y a donc pas moyen de savoir s'il s'agit d'un message de demande de paiement (ce pourrait aussi bien être au contraire 10 un paiement en faveur de Wallet Node 1 par exemple), et d'autre part les Wallet Messages sont régulièrement ré-envoyés tant que le récepteur n'a pas confirmé réception (par un Accusé de Réception, décrit plus bas). L'utilisateur qui reçoit ces Wallet Messages ne peut savoir ni de quel Wallet Message (et quel contenu de message proprement-dit) il s'agit, ni qu'il s'agit 15 d'un même Wallet Message qui est ré-envoyé (ou s'il s'agit d'un tout nouveau Wallet Message), dans la mesure où tous les Wallet Messages sont chiffrés. Dans un mode de réalisation préféré, le Wallet Program qui est exécuté attend de recevoir un Accusé de Réception pour chaque Wallet 20 Message émis, ou pour un ensemble de Wallet Messages émis, avant d'exécuter les instructions qui suivent ces émissions de Wallet Message. Utilisation d'un Nonce pour les Accusés de réception La Figure 5 présente schématiquement la réception par un Wallet 25 Node « ReceiverWN » d'un Wallet Message. Ce dernier est chiffré avec la clé publique de ReceiverWN (ce qui n'est pas montré dans la figure) et inclut un nonce cryptographique (un nombre aléatoire utilisé une seule fois). L'Accusé de Réception « ACK » que le ReceiverWN retourne reproduit ce nonce et démontre ainsi que ReceiverWN a bien reçu le Wallet Message 30 spécifique en question. ACK peut aussi être chiffré (avec la clé publique de SenderWN, l'émetteur du Wallet Message en question). La Figure 5 montre 3035248 20 aussi qu'un Wallet Message émis inclut la signature du Wallet Node qui l'émet. Toutefois, ce que cette figure ne montre pas est que les Wallet Messages comprennent aussi normalement (de préférence) la signature par le fabricant de la clé publique du Wallet Node émetteur (c'est à dire le 5 certificat du fabricant). Enfin, comme déjà mentionné, les Wallet Messages sont (de préférence) réémis régulièrement tant que les accusés de réception (ACK) ne sont pas reçus en retour. On va maintenant décrire une architecture comprenant, en plus des 10 Wallet Nodes (sécurisés) tels que décrits, des Wallet Nodes « témoins » dont le rôle est de témoigner de la bonne exécution des Wallet Programs dans les Wallet Node « de base », que ces derniers soient sécurisés ou pas. Ainsi, au moins un Wallet Node « témoin » est associé à chaque Wallet Node i « de base » (sécurisé ou pas) émettant des Wallet Messages.
15 Lorsqu'un Wallet Node de base reçoit une entrée I/O, il notifie le (ou les) Wallet Node témoin qui lui a été affecté. Ce dernier exécute alors le même Wallet Program, qui le cas echéant manipule des variables d'état et émet des Wallet Messages. Les mises-à-jours de variables d'état dans les Wallet Nodes de base sont aussi notifiées aux Wallet Nodes témoins. La 2 0 concordance entre les résultats des traitements et lesdites notifications est vérifiée. Toute non-concordance, le cas échéant, invalide l'opération du Wallet Node de base correspondant. Les Wallet Nodes témoins peuvent être sélectionnés aléatoirement dans un DHT [http://en.wikipedia.org/wiki/Distributed_hash_table] et un ou 25 plusieurs témoins peuvent ainsi être affectés aléatoirement (et de manière aveugle) à chaque Wallet Node. Les Wallet Nodes témoins peuvent être spécifiquement générés ou sélectionnés par le ou les fabricants. La Figure 6 présente l'exemple du paiement présenté à la Figure 3, 30 mais avec les témoins respectifs Wallet Node 1' et Wallet Node 2'. L'entrée I/O déclenchant l'exécution de Wallet Pgm, ainsi que chaque opération sur 3035248 21 les variables d'état de Wallet Node 1 et 2, sont communiquées au Wallet Node témoin correspondant (ceci est représenté par la flèche « Notification »). Les témoins exécutent ainsi les mêmes Wallet programs, mettent à jours les mêmes variables d'état (mais pas forcément sur de 5 mêmes valeurs, comme décrit ci-après) et s'envoient les mêmes Wallet Messages que leurs Wallet Nodes correspondants. Les résultats de traitements sont comparés auxdites notifications pour validation. Ce schéma peut être appliqué à des Wallet Nodes de base qui sont sécurisés ou non sécurisés.
10 Avantageusement, des techniques de chiffrement homomorphique peuvent être mis en oeuvre pour ne pas dévoiler aux témoins les valeurs dans les variables d'états. On peut aussi, dans certains Wallet Programs, mettre en oeuvre une simple translation de valeurs dans les variables d'état telles que « Balance » 15 (solde). Ainsi, dans cette approche, dans la Figure 6, les variables d'état « Balance' » de Wallet Node 1' et Wallet Node 2' respectivement ne sont pas initialisées aux mêmes valeurs que les valeurs initiales respectives de « Balance » dans Wallet Node 1 et Wallet Node 2. Lorsque les opérations sur les variables d'état de Node Wallet 1 et Node Wallet 2 sont 2 0 communiquées au Wallet Nodes témoins respectifs correspondants (communication représentée par la flèche « Notification »), les valeurs courantes de ces variables d'état ne sont pas communiquées, seules les opérations telles que -10 et +10 le sont. Une telle architecture de système et procédé où des Wallet Nodes 25 témoins confirment des résultats d'exécution de Wallet Nodes de base, permet de relaxer les exigences de sécurisation au niveau du hardware. On peut alors tolérer dans un ensemble de Wallet Nodes un certain nombre de Wallet Nodes qui ne sont pas sécurisés au sens de la présente invention, en particulier ceux dont les montants traités sont relativement faibles et limités.
3035248 22 Un autre avantage d'une telle architecture est que les Wallet Nodes témoins peuvent servir à garder des données dont les possesseurs de Wallet Nodes de base (sécurisés ou pas) peuvent se prévaloir en cas de perte. On notera enfin qu'un ensemble de Wallet Nodes formant 5 communauté, et/ou les Wallet Nodes témoins correspondants, peuvent faire appel à un ensemble de « Wallet Nodes séquenceurs » pour ordonner leurs opérations lorsqu'il s'agit de les mémoriser de manière ordonnée dans une base de données partagée (et éventuellement distribuée) telle qu'une chaîne de blocs. Ladite communauté élit un nombre impair de Wallet Nodes 10 séquenceurs (appelé liste de Wallet Nodes séquenceurs) aptes à fournir conjointement le service de séquencement désiré. Une demande d'un numéro de séquence peut être soumis par un Wallet Node (ou un Wallet Node témoin) à n'importe quel Wallet Node séquenceur. En cas de non réponse, le Wallet Node demande un numéro de 15 séquence au Wallet Node séquenceur suivant disponible dans la liste de Wallet Nodes séquenceurs. Ces derniers décident entre eux comment attribuer les numéros de séquence, comme suit : - Lorsqu'une demande de séquence est reçue par un Wallet Node séquenceur, ce dernier propose le numéro de séquence suivant le dernier 20 utilisé connu aux autres Wallet Nodes séquenceurs, - Si cette proposition vient avant une autre demande de numéro de séquence, alors elle est approuvée, sinon elle est rejetée. - Lorsque le nombre d'approbations est supérieur à la moitié du nombre de Wallet Nodes séquenceurs accessibles, le numéro de séquence proposé 25 est attribué. L'algorithme de ce procédé peut être comme présenté en annexe A. On va maintenant décrire la partie d'un Wallet Program de formation de communauté en P2P (de pair à pair) tout d'abord en en présentant l'usage : 3035248 23 Une nouvelle communauté est créée par un Wallet Node qui lui donne comme identifiant sa clé publique suivie ou précédée d'un nom de communauté (ou simplement un Nonce). Supposons que cet identifiant de la communauté soit connu par l'utilisateur 5 d'un autre Wallet Node (par un moyen quelconque), qui demande à devenir membre par le moyen décrit ci-après. Il le devient si tous les membres existants l'acceptent. (Bien entendu, l'application décrite ici peut être adaptée à d'autres règles de formation de communauté.) Ainsi, pour devenir membre, il lui faut envoyer ou faire envoyer, via un 10 membre_existant, un Wallet Message de requête « Membership Request » destiné aux membres déjà existants et obtenir leur acceptation. Le protocole est le suivant : Le Wallet Node du requérant envoie un Wallet Message « Membership Request » à chaque membre déjà existant qu'il connaît, qui 15 vont eux-mêmes - l'accepter, ou pas, et - la retransmettre à tous les membres qu'ils connaissent eux-mêmes, à moins qu'il l'aient déjà et qu'ils l'aient donc déjà retransmis, auquel cas (cas où la requête en question a déjà été reçue par le Wallet Node 20 dudit membre par un autre chemin), ils retournent un Wallet Message « Request already received ». Chaque requête traverse ainsi une structure d'arbre, chaque sous-arbre étant formée de membres déjà existants mais qui n'étaient pas encore pris en compte, et chaque feuille de cet arbre représentant un membre qui ne 25 plus propager ladite requête du fait que tous les membres qu'il connaît lui- même l'ont déjà. Au passage (pour chaque noeud touché dans cette structure d'abre), au moins deux jetons sont créés et transmis dans ledit Wallet Message (c'est-à-dire la requête « Membership Request ») qui est propagé de noeud 3 0 en noeud dans cette structure d'arbre : 3035248 24 - un jeton « +1 accept » qui est créé en cas d'acceptation, jeton qui inclut l'identifiant de la communauté en question et l'identifiant (l'adresse, la clé publique) du Wallet Node qui souhaite devenir membre, ainsi que, 5 - et dans tous les cas (acceptation ou pas), un jeton « +1 reply » qui va servir à estimer le nombre d'utilisateurs touchés. Ce jeton inclut également l'identifiant de la communauté en question et l'identifiant (l'adresse, la clé publique) du Wallet Node qui demande à devenir membre.
10 Si la communauté est grande, on peut aussi y inclure une profondeur « Depth » qui permette de limiter la diffusion de la requête de membre en membre. Lorsqu'une feuille de l'arbre est touchée, c'est-à-dire dans le cas où un Wallet Message « Request already received » est reçu par un Wallet 15 Node en réponse à toutes ses propagation de « Membership Request », les jetons accordés à cette feuille remontent l'arbre en s'ajoutant à des compteurs respectifs de jetons remontés. En plus, en remontant, d'autres types de données (en fonction de l'application) peuvent se cumuler dans chaque Wallet Node traversé, pour 20 former la liste complète de ces données à la racine de l'arbre. La requête est globalement acceptée si un nombre suffisant de jetons est atteint. A noter que cette décision globale d'acceptation ou pas peut se baser sur un rapport Sigma(« +1 accept ») / Sigma(« +1 reply »), pour une certaine valeur de Depth.
25 Bien entendu, la présente invention n'est nullement limitée aux formes de réalisation décrites et représentées, mais l'homme du métier saura y apporter de nombreuses variantes et modifications.
3035248 25 Annexe A SequencerNode 1 List<SequencerNode> otherSequencerNodes; 5 int nextSequenceNumber = 0; synchronized int getSequenceNumber() 1 int votes = 0; while ( votes < (otherSequencerNodes.size() + 1)/2) 1 10 nextSequenceNumber++; vote = 1; for ( SequencerNode sn : otherSequencerNodes) 1 int v = 15 sn.getApproval(nextSequenceNumber); votes += v; } } return nextSequenceNumber; 20 } synchronized int getApproval( int nextN ) 1 int result = 0; if (nextN > this.nextSequenceNumber) 1 result = 1; 25 this.nextSequenceNumber = nextN ; } return result; } } 30

Claims (9)

  1. REVENDICATIONS1. Système-sur-puce (SoC), caractérisé en ce qu'il comprend en combinaison: - un processeur (Microcontroller), - un sous-système de codes exécutables quelconques (Wallet Programs) aptes à être exécutés par le système-sur-puce et par d'autres systèmes-sur-puce, - un sous-système de gestion des codes exécutables (Select/Load) comprenant un code exécutable spécifique de sélection/chargement desdits codes exécutables quelconques, - un sous-système d'entrée/sortie (I/O) permettant au système-surpuce de communiquer avec d'autres systèmes-sur-puce pour échanger des des messages (Wallet Messages) avec d'autres systèmes-sur-puce, au moins certains des messages contenant le hash du contenu d'un code exécutable, - un sous-système de signature (Sign) des messages échangés, apte à générer un hash d'un code exécutable couramment chargé dans le système-sur puce, 2 0 le système-sur-puce étant apte : * en réaction à la réception d'un message (Wallet Message) contenant un hash, à amener ledit code exécutable spécifique de sélection/chargement à sélectionner et charger pour exécution, à partir dudit sous-système de codes exécutables quelconques (Wallet Programs), le code exécutable 2 5 quelconque dont le hash du contenu correspond audit hash inclus contenu dans ledit message (Wallet Message) ; avant la signature d'un message (Wallet Message) à émettre, à amener le sous-système de signature (Sign) à générer ou à vérifier le hash du code exécutable quelconque couramment chargé pour inclusion dans 3 0 ledit message, garantissant ainsi que le même hash est re-propagé d'un message reçu à un message émis. 3035248 27
  2. 2. Système-sur-puce selon la revendication 1, lequel comprend une mémoire rémanente pour un ensemble de variables d'état, seul le code exécutable (Wallet Program) possédant une variable d'état étant apte à la 5 modifier.
  3. 3. Système-sur-puce selon la revendication 1 ou 2, dans lequel est mémorisée de façon rémanente une clé privée, une clé publique de signature (certificat) associée à la clé privée étant partagée entre une pluralité de 10 systèmes-sur-puce d'un même fabricant, aptes à communiquer entre eux, et ladite clé privée étant utilisée pour signer les messages.
  4. 4. Utilisation d'au moins un système-sur-puce selon l'une des revendications 1 et 3 pour réaliser une identification anonyme à partir de 15 documents d'identité à partir desquels peuvent être lues des signatures officielles.
  5. 5. Utilisation de deux systèmes-sur-puce selon l'une des revendications 1 à 3, pour réaliser un transfert d'unités de valeur par débit d'un solde (Balance) constitué par une variable d'état dans l'un des systèmes-sur-puce et crédit d'un solde constitué par une variable d'état dans l'autre systèmesur-puce.
  6. 6. Utilisation selon l'une des revendications 4 et 5, laquelle met 25 également en oeuvre au moins un système-sur-puce témoin associé à un système-sur-puce d'identification ou de transfert de valeur et apte répliquer au moins en partie les opérations exécutées dans ce dernier.
  7. 7. Dispositif de traitement de données, comprenant des moyens de 30 traitement et de mémorisation et des moyens de communication avec d'autres dispositifs de traitement de données, caractérisé en ce qu'il 3035248 28 comprend un système-sur-puce selon l'une des revendications 1 à 3 et un canal de communication bidirectionnelle filaire ou sans fil entre les moyens de traitement et le système-sur-puce, ce dernier étant apte à échanger des messages avec d'autres systèmes-sur-puce via lesdits moyens de 5 communication du dispositif.
  8. 8. Dispositif selon la revendication 7, dans lequel le système-sur-puce est logé dans une unité distincte du dispositif de traitement. 10
  9. 9. Dispositif selon la revendication 7, dans lequel le système-sur-puce est intégré au dispositif de traitement.
FR1553328A 2015-01-30 2015-04-15 Systeme-sur-puce a fonctionnement securise et ses utilisations Withdrawn FR3035248A1 (fr)

Priority Applications (9)

Application Number Priority Date Filing Date Title
FR1553328A FR3035248A1 (fr) 2015-04-15 2015-04-15 Systeme-sur-puce a fonctionnement securise et ses utilisations
CN202111067292.7A CN113946817A (zh) 2015-01-30 2016-01-28 用于管理安全实体的连网承诺的系统和方法
CN201680011866.XA CN107408174B (zh) 2015-01-30 2016-01-28 用于管理安全实体的连网承诺的系统和方法
PCT/IB2016/050440 WO2016120826A2 (fr) 2015-01-30 2016-01-28 Systèmes et procédés pour la gestion d'engagements en réseau d'entités sécurisées
EP21164203.8A EP3872666A1 (fr) 2015-01-30 2016-01-28 Systèmes et procédés pour la gestion d'engagements en réseau d'entités sécurisées
EP16712463.5A EP3251046B1 (fr) 2015-01-30 2016-01-28 Systèmes et procédés pour la gestion d'engagements en réseau d'entités sécurisées
US15/662,855 US10715326B2 (en) 2015-01-30 2017-07-28 Systems and methods for managing networked commitments of secure entities
HK18105367.4A HK1248005A1 (zh) 2015-01-30 2018-04-25 用於管理安全實體的連網承諾的系統和方法
US16/894,961 US11444768B2 (en) 2015-01-30 2020-06-08 Systems and methods for managing networked commitments of secure entities

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1553328A FR3035248A1 (fr) 2015-04-15 2015-04-15 Systeme-sur-puce a fonctionnement securise et ses utilisations

Publications (1)

Publication Number Publication Date
FR3035248A1 true FR3035248A1 (fr) 2016-10-21

Family

ID=54199755

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1553328A Withdrawn FR3035248A1 (fr) 2015-01-30 2015-04-15 Systeme-sur-puce a fonctionnement securise et ses utilisations

Country Status (1)

Country Link
FR (1) FR3035248A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107369241A (zh) * 2017-07-13 2017-11-21 深圳怡化电脑股份有限公司 一种票据处理装置及方法
WO2018104890A3 (fr) * 2016-12-06 2018-08-30 Enrico Maim Procédés et entités notamment transactionnels mettant en jeu des dispositifs sécurisés
CN112236792A (zh) * 2018-06-06 2021-01-15 E·马伊姆 P2p架构中的安全交易系统
EP3568794B1 (fr) * 2017-01-16 2024-03-13 Enrico Maim Procédés et systèmes pour l'exécution de contrats intelligents dans des environnements sécurisés

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ALAN REINER: "Bitcoin Wallet Identity Verification Specification Bitcoin Wallet Identity Verification Specification Authors", 27 February 2015 (2015-02-27), XP055245135, Retrieved from the Internet <URL:http://diyhpl.us/~bryan/papers2/bitcoin/armory-verisign-bitcoin-wallet-identity-specification.pdf> [retrieved on 20160127] *
SIGRID GÜRGENS ET AL: "Security Evaluation of Scenarios Based on the TCG's TPM Specification", 24 September 2007, COMPUTER SECURITY - ESORICS 2007; [LECTURE NOTES IN COMPUTER SCIENCE], SPRINGER BERLIN HEIDELBERG, BERLIN, HEIDELBERG, PAGE(S) 438 - 453, ISBN: 978-3-540-74834-2, XP019099831 *
SINGH PRABHJOT ET AL: "Performance Comparison of Executing Fast Transactions in Bitcoin Network Using Verifiable Code Execution", 2013 2ND INTERNATIONAL CONFERENCE ON ADVANCED COMPUTING, NETWORKING AND SECURITY, IEEE, 15 December 2013 (2013-12-15), pages 193 - 198, XP032551793, DOI: 10.1109/ADCONS.2013.42 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018104890A3 (fr) * 2016-12-06 2018-08-30 Enrico Maim Procédés et entités notamment transactionnels mettant en jeu des dispositifs sécurisés
EP3971750A1 (fr) * 2016-12-06 2022-03-23 Enrico Maim Procédés et entités notamment transactionnels mettant en jeu des dispositifs sécurisés
US11843693B2 (en) 2016-12-06 2023-12-12 Enrico Maim Methods and entities, in particular of a transactional nature, using secure devices
EP3568794B1 (fr) * 2017-01-16 2024-03-13 Enrico Maim Procédés et systèmes pour l'exécution de contrats intelligents dans des environnements sécurisés
CN107369241A (zh) * 2017-07-13 2017-11-21 深圳怡化电脑股份有限公司 一种票据处理装置及方法
CN112236792A (zh) * 2018-06-06 2021-01-15 E·马伊姆 P2p架构中的安全交易系统

Similar Documents

Publication Publication Date Title
EP3251046B1 (fr) Systèmes et procédés pour la gestion d&#39;engagements en réseau d&#39;entités sécurisées
EP3568794B1 (fr) Procédés et systèmes pour l&#39;exécution de contrats intelligents dans des environnements sécurisés
EP3403213B1 (fr) Procédés et systèmes mis en oeuvre dans une architecture en réseau de noeuds susceptibles de réaliser des transactions basées sur messages
EP3547203A1 (fr) Méthode et système de gestion d&#39;accès à des données personnelles au moyen d&#39;un contrat intelligent
WO2007012584A1 (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&#39;ordinateur correspondants
EP1807967B1 (fr) Procede de delegation securisee de calcul d&#39;une application bilineaire
FR2988196A1 (fr) Procede d&#39;authentification d&#39;un individu porteur d&#39;un objet d&#39;identification
EP1911194A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d&#39;ordinateur correspondants
FR3035248A1 (fr) Systeme-sur-puce a fonctionnement securise et ses utilisations
WO2020064890A1 (fr) Procede de traitement d&#39;une transaction, dispositif, systeme et programme correspondant
WO2016207715A1 (fr) Gestion securisee de jetons électroniques dans un telephone mobile.
EP3991381B1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
CH716295A2 (fr) Procédé de signature multiple d&#39;une transaction destinée à une blockchain, au moyen de clés cryptographiques distribuées parmi les noeuds d&#39;un réseau pair-à-pair.
FR3002056A1 (fr) Authentification de signature manuscrite numerisee.
FR3073998B1 (fr) Procede numerique de controle d&#39;acces a un objet, une ressource ou service par un utilisateur
EP3821564A1 (fr) Gouvernance de sécurité du traitement d&#39;une requête numérique
CH716294A2 (fr) Procédé de signature décentralisée, sous contrôle biométrique et sous conditions d&#39;identification personnelle et de géolocalisation, d&#39;une transaction destinée à une blockchain.
CH716293A2 (fr) Procédé de signature décentralisée, sous contrôle biométrique et sous condition d&#39;identification personnelle, d&#39;une transaction destinée à une blockchain.
FR2898423A1 (fr) Procede securise de configuration d&#39;un dispositif de generation de signature electronique.
EP3371760A1 (fr) Procédé de verification d&#39;identité lors d&#39;une virtualisation
CH716300A2 (fr) Procédé de signature d&#39;une transaction destinée à une blockchain, au moyen d&#39;une clé cryptographique distribuée parmi les noeuds d&#39;un réseau pair-à-pair sur lequel est déployée cette blockchain.
FR3007929A1 (fr) Procede d&#39;authentification d&#39;un utilisateur d&#39;un terminal mobile
CH716299A2 (fr) Procédé de signature d&#39;une transaction destinée à une blockchain, au moyen d&#39;une clé cryptographique distribuée parmi les noeuds d&#39;un réseau pair-à-pair.
CH716302A2 (fr) Procédé de signature décentralisée d&#39;une transaction destinée à une blockchain, suivant les instructions d&#39;un contrat intelligent.
CH716291A2 (fr) Procédé de signature décentralisée, sous contrôle biométrique, d&#39;une transaction destinée à une blockchain.

Legal Events

Date Code Title Description
PLSC Publication of the preliminary search report

Effective date: 20161021

ST Notification of lapse

Effective date: 20161230