WO2017162930A2 - Dispositif d'authentification biométrique adaptatif par échographie, photographies en lumière visible de contraste et infrarouge, sans divulgation, à travers un réseau informatique décentralisé - Google Patents

Dispositif d'authentification biométrique adaptatif par échographie, photographies en lumière visible de contraste et infrarouge, sans divulgation, à travers un réseau informatique décentralisé Download PDF

Info

Publication number
WO2017162930A2
WO2017162930A2 PCT/FR2017/000054 FR2017000054W WO2017162930A2 WO 2017162930 A2 WO2017162930 A2 WO 2017162930A2 FR 2017000054 W FR2017000054 W FR 2017000054W WO 2017162930 A2 WO2017162930 A2 WO 2017162930A2
Authority
WO
WIPO (PCT)
Prior art keywords
message
receiving device
valid
robot
peer
Prior art date
Application number
PCT/FR2017/000054
Other languages
English (en)
Other versions
WO2017162930A3 (fr
Inventor
Sébastien Dupont
Original Assignee
Sébastien Dupont
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 Sébastien Dupont filed Critical Sébastien Dupont
Priority to CN201780018900.0A priority Critical patent/CN108780501B/zh
Publication of WO2017162930A2 publication Critical patent/WO2017162930A2/fr
Publication of WO2017162930A3 publication Critical patent/WO2017162930A3/fr
Priority to US16/133,989 priority patent/US11038693B2/en

Links

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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3231—Biological data, e.g. fingerprint, voice or retina
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V40/00—Recognition of biometric, human-related or animal-related patterns in image or video data
    • G06V40/10—Human or animal bodies, e.g. vehicle occupants or pedestrians; Body parts, e.g. hands
    • G06V40/12—Fingerprints or palmprints
    • G06V40/1382—Detecting the live character of the finger, i.e. distinguishing from a fake or cadaver finger
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V40/00—Recognition of biometric, human-related or animal-related patterns in image or video data
    • G06V40/10—Human or animal bodies, e.g. vehicle occupants or pedestrians; Body parts, e.g. hands
    • G06V40/12—Fingerprints or palmprints
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V40/00—Recognition of biometric, human-related or animal-related patterns in image or video data
    • G06V40/10—Human or animal bodies, e.g. vehicle occupants or pedestrians; Body parts, e.g. hands
    • G06V40/12—Fingerprints or palmprints
    • G06V40/13—Sensors therefor
    • G06V40/1306—Sensors therefor non-optical, e.g. ultrasonic or capacitive sensing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V40/00—Recognition of biometric, human-related or animal-related patterns in image or video data
    • G06V40/10—Human or animal bodies, e.g. vehicle occupants or pedestrians; Body parts, e.g. hands
    • G06V40/12—Fingerprints or palmprints
    • G06V40/1365—Matching; Classification
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/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

Definitions

  • the present invention relates to the field of message chains. More particularly, the invention relates to means for validating said message chains, particularly adapted to secure
  • This invention integrates the notion of message chains, which in contrast to current technologies, especially those based on centralized databases that they are distributed or not, which although gaining performance are irretrievably limited by their character
  • Blockchain to validate blocks of transactions across a network
  • An object of the invention is to provide means for managing the
  • Another object of this invention is to rely on the mechanism of NoSQL databases to introduce the notion of "referring" nodes to a given transaction chain, thus enabling the validation of a unit message on a planetary decentralized network and instantaneously.
  • Another object of this invention is to provide a new mechanism for validating message chains independently of each other and thus to make the process unlimited in terms of performance.
  • Another object is to provide enhanced security and privacy for users of this technology.
  • Another object is to allow validation complexity that is all the more important that the messages to be validated have a high criticality, this complexity is managed both by the number of validations required for a given message, but also in terms of the geographical distribution of the messages. validations.
  • Another object of this invention is to transparently process data hosted by external devices.
  • Another object of this invention is to rely on a decentralized network of trust-limited trusted third parties who both possess the necessary knowledge to validate the messages, but who by transparency of the process makes it possible to restore a real confidence to the users.
  • an embodiment provides a method implemented in a network, capable of implementing a message chain protocol, comprising at least one transmitting device and at least a first and at least a second receiver device adapted to perform calculations.
  • a first step where at least one transmitting device transmits at least a first message to at least a first receiving device comprising at least:
  • control key generated from a second cryptographic key
  • CPUBJDA1 public key
  • DATA data area
  • At least one first cryptographic signature (SIGJDA1) generated by calculating and encrypting the content control key of the at least one first message with the first cryptographic private key and;
  • At least one second cryptographic signature (SIG_DISPEM) generated by calculating and encrypting the content control key of the at least one first message with the cryptographic private key associated with the transmitting device.
  • CTRL_PUBU public key corresponding to the signature of said sending device (SIG_DISPEM) from public cryptographic keys previously known by at least one receiving device and associated with the sending devices and; generates at least a second validation message associated with said at least one first message and comprising at least:
  • CTRL_PUBU associated with the cryptographic public key which made it possible to verify the signature of said sending device (SIG_DISPEM) and;
  • a public key (PUB_ROBOT) of the at least one first receiving device generated from at least one cryptographic key specific to the at least one first receiving device and;
  • the cryptographic signature (SIG_ROBOT) generated by calculating and encrypting the content control key of the at least one first message and the content of the at least one second message with the cryptographic private key associated with the at least one first receiving device and;
  • a third step wherein at least a second receiving device of said at least one first and at least one second message transmitted by the at least one first receiving device performs the following operations:
  • control key computed from the contents of the at least one first message and
  • control key associated with the cryptographic public key which made it possible to verify the signature of said at least one transmitting device (SIG_DISPEM) and;
  • a public key (PUB_ROBOT2) of said at least one second receiver device generated from at least one cryptographic key specific to said at least one second receiver device and;
  • the cryptographic signature (SIG_ROBOT2) generated by calculating and encrypting the content control key of the at least one first message and the content of the at least one second message with the cryptographic private key associated with the at least one second receiving device.
  • the method is able to connect at least one first message to at least one second message via at least two control keys, a public key and a signature, the method being characterized in that said at least one second message comprises:
  • At least one control key (CCJDA2) generated from a second cryptographic key and;
  • At least one control key (CCJDA1), at least one public key (CPUBJDA1) and at least one signature (SIGJDA1) of the at least one first message generated from a first cryptographic key and;
  • the signature (SIGJDA1) being generated by calculating the control key of the content of the second message and encrypting the result with the first cryptographic private key.
  • the method is able to implement a decentralized peer-to-peer network, comprising at least a first and a second receiver device adapted to store data and a device. list of at least one receiving device of said decentralized peer-to-peer network, characterized in that it comprises the following steps:
  • a first step where at least a first receiving device interrogates at least a second receiving device of said peer-to-peer distributed network in order to retrieve the list of at least one receiving device of said peer-to-peer distributed network;
  • the method is able to transmit at least one message to at least one receiving device of said network
  • decentralized peer-to-peer characterized in that it comprises the following steps:
  • a second step where said transmitting device transmits at least one message on at least one receiving device listed in said list of at least one receiving device of said decentralized peer-to-peer network.
  • the method is capable of identifying at least one referent receiver device (7) relating to at least one piece of information of at least one message characterized in that it makes it possible to identify the at least one device ( 7) from: At least one piece of information contained in said at least one message and;
  • At least one message distribution algorithm At least one message distribution algorithm and
  • the method is able to validate and transmit at least one message to at least one referencing receiver device (7), characterized in that it comprises the following steps:
  • the at least one receiving device after receiving said at least one message:
  • the method is characterized in that it further comprises at least one database.
  • the method is capable of storing and replicating at least one message in at least one database of at least one receiving device according to a data distribution algorithm, the method being characterized in that said at least one receiving device identifies for said at least one message at least one database and at least one receiving device based on:
  • At least one piece of information relating to said at least one message and
  • the method is adapted to connect at least one message to at least one message chain via at least one validation message of at least one receiving device, characterized in that it comprises the following steps:
  • ⁇ calculates the public key (CTRL_PUBU) corresponding to the private key of the transmitting device that generated the signature (SIG_DISPEM) of the at least one second message.
  • a second step or said at least one receiving device adds at least one validation message to said at least one second message including the following information:
  • CTR_PUBU said public key corresponding to the signature of the sending device (SIG_DISPEM) of the at least one second message.
  • ⁇ information relating to the validation of said at least one receiving device comprising:
  • the cryptographic signature (SIG_ROBOT) generated by calculating and encrypting the content control key of the at least one second message with the cryptographic private key associated with the at least one receiving device.
  • the method is able to independently and asynchronously validate at least one message of at least one message chain, characterized in that it comprises the following steps: a first step where the at least one first receiving device, valid, identifies the receiving device referent (7) relating to said at least one first message, and:
  • diffuse at least one receiving device refer to:
  • a second step where at least a second receiving device, valid, identifies the receiving device referent (7) relating to said at least one first message, and:
  • diffuse at least one receiving device refer to:
  • said at least one receiving device refers to at least a first reception of said at least one transmitted message, the message (PREMSG_VALID) and the message (VALID_ROBOT) of at least one receiving device and:
  • a fourth step where at least one receiving device receives at least one second message having the control key (CCJDA2) and whose previous control key indicated (CCJDA1) corresponds to the control key of said first message, and performs the following operations:
  • the method is adapted to validate at least one message of at least one message chain, taking into account the geographical position of at least one other receiving device having previously validated said message, characterized by the steps following
  • At least one receiving device receives at least a second message having the control key (CCJDA2) and whose previous control key indicated (CCJDA1) corresponds to the control key of at least a first message, and performs the operations following:
  • ⁇ identifies the at least one first receiver device referenced (7) relating to said at least one first message and;
  • ⁇ identifies the at least one second receiver device referencing (7) relating to said at least one second message and;
  • ⁇ retrieves the message (PRE SG_VALID) and the set of messages (VALID_ROBOT) relative to said at least one first message from said at least one first receiving device refer to (7) of said at least one first message and; ⁇ verifies the validity of each of the messages (PREMSG_VALID) and (VALID_ROBOT) and the geographical position of each of the at least one receiving device at the origin of at least one validation message (VALID_ROBOT) of the at least one first message and;
  • VALID_ROBOT a validation message relating to said at least one second message
  • the method is adapted to validate a message in a message chain, taking into account the number of receiving devices having previously validated said message, the method being characterized in that it comprises the following steps:
  • At least one receiving device receives at least a second message having the control key (CCJDA2) and whose previous control key indicated (CCJDA1) corresponds to the control key of at least a first message, and performs the operations following:
  • ⁇ identifies the at least one first receiver device referencing (7) relating to said at least one first message and;
  • ⁇ identifies the at least one second receiver device referencing (7) relating to said at least one second message and;
  • ⁇ retrieves the message (PREMSG_VALID) and the set of messages (VALID_ROBOT) relative to said at least a first message from said at least one first receiving device relate said at least one first message and; ⁇ verifies the validity of each of the messages (PREMSG_VALID) and (VALID_ROBOT) and the number of receiving devices at the origin of at least one validation message (VALID_ROBOT) of said first message and;
  • VALID_ROBOT a validation message relating to said at least one second message
  • FIG. 1 Diagrammatic view of the transmission and validation of a message comprising transmitting devices (2), (3) and (4) and receiving devices (1) and (7) integrated in a decentralized network (8). ) according to one embodiment of the invention
  • FIG. 3 schematic view of the link between biometric keys, cryptographic private keys, cryptographic public keys and control keys according to one embodiment of the invention
  • FIG. 5 schematic view of the content of a message transmitted by a transmitting device accompanied by the validation messages of the receiving devices according to one embodiment of the invention
  • FIG. 7 schematic view of the asynchronous operation of the validations of the messages transmitted by the transmitting devices and validated by the receiving devices according to one embodiment of the invention.
  • a method implemented in a network comprising at least one transmitting device (9) and at least one first and one second receiving device (1), all adapted to perform cryptographic calculations, will now be described. .
  • the invention is composed on the one hand of sending devices (2), (3) and (4) adapted to transmit and retrieve messages to and from the receiving devices (1).
  • the messages are stored through message chains themselves stored on databases hosted by the receiving devices implemented in a decentralized peer-to-peer network (8).
  • each host a first group of NoSQL-type databases
  • the messages are thus accessible through a decentralized peer-to-peer network of NoSQL databases, these databases being of data are related to a specific use, but remain associated with each other - Fig.2:
  • Identity database relating to messages specific to digital identities, for example of an individual, an object, a group of individuals, to the storage of biometric data, but also to messages relating to an identity digitally from any external base.
  • ID identity-specific digital identities stored in the database (ID)
  • ID identity-specific digital identities stored in the database (ID)
  • ID external digital identities
  • rules for sending and receiving devices but also messages relating to a smart contract from any external base.
  • BANQ meta-database
  • this database is related to messages waiting or refused on the whole system, it stores messages waiting for example as part of the notification of the sender or the recipient during a transfer of values.
  • the peer-to-peer network - or more commonly referred to as the Anglo-Saxon peer-to-peer - is the keystone of any decentralized system.
  • the message strings as used in this invention use this type of network to share the information and the totality of the resources of this system.
  • the nodes of these networks are carried by the receiving devices (1) which in addition to the validation of messages ensure the storage and dissemination of information wherever the receiving devices (1) are connected to the network - Fig.1. In the context of a message sent by a transmitting device, the transmitting device will therefore not contact a particular receiving device (1), but any receiving device (1) for validating the message, the receiving device (1) will directly process the validation of said message or propagate it to a receiver device referent (7) in particular.
  • the unresolved issues so far on decentralized networks are; management of the distribution of data and validations across the nodes, the organization of the data to allow each node to validate / refute a message without having to modify everything, the control of latency so that a message can be validated on both sides of the planet, the organization of data to prevent a device from downloading several messages of a chain to consult for example its portfolio of values and without going through a centralized service, the distribution of data so that all the data is not replicated on all the nodes and thus optimize the occupation rate of the disks and significantly increase the overall admissible size.
  • NoSQL database that is particularly efficient for this type of decentralized system.
  • This database will contain, for example, 5 database schemas, each of which may have a different replication strategy.
  • the division of the databases makes it possible to apply different replication strategies according to at least one primary key.
  • the data relating to the storage of values, materialized by the database (BANQ) must for example be replicated on all the nodes to ensure maximum availability.
  • the messages relating to the biometric identity data may be distributed less systematically, the need for a user to access them quickly (collocation on several nodes nearby), and some other nodes further to ensure the persistence of data even in the event that a country loses its Internet connection and / or its electricity network as is regularly the case in many developing countries.
  • One of the particularly interesting features in this type of database is the indexing of the nodes according to the address of the primary key.
  • Smart contracts also known by the term “smart-contract” as defined in this invention, represent programs whose execution is controlled and verifiable, designed to execute the terms of a contract automatically when certain conditions are met »
  • Figure 4 shows a series of messages to the receiver device databases:
  • each column (CC), (PUB) ... must be able to contain an infinity of columns (BioPubDoigtl [1, 2,3], BioPubDoigt2 [1 , 2,3,4] ... or BioHashDoigtl -1, BioHashDoigtl -2 ); in practice there will be potentially as many columns relating to the validation messages of the receiving devices as of receiving devices, these columns are also called “supercolumns" ..
  • Blockchain in fact, it is through the mining that each transaction is validated and that network security is assured, because in each mining job the whole chain must be checked, if a transaction is added or modified then the whole branch of the chain is denied.
  • the mining work is provided by receiving devices, or more precisely autonomous software agents also called “Iris Robots” (1) that will respond to calls for tenders (the mining is a) which are published in the contract databases (CONTRACTS) and technical data (TECH).
  • the Iris Robots accept or not this tender according to the proposed remuneration and with the obligation to execute the contract and to follow the general rules of the system (which is constantly checked by the other Iris Robots - Fig.1 -1) - in the unlikely event of a "crazy miner robot", the other minor robots never use the blocks it has generated and revoke it from the list of Iris Robots enabled by the device.
  • Iris robots (1) are the trusted third parties of this network, but with limited confidence, because each transaction must be proven since its origin.
  • Dedicated mining calculation centers have the effect of annihilating the interest for a user to take part in the mining network which is catastrophic for the security of the system that is found in the problems of centralized systems.
  • Blockchain uses blocks containing several transactions, which has the effect of making the system slow (on average 10 minutes) for the actual validation of a transaction, on the other hand, this operation has the effect of making part of the work of unnecessary mining, because for example using already validated transactions, one of the last major drawbacks of this block validation and requiring a given user to download all blocks to know the status of its accounts (except to go through a centralized system who does the work for him, but who centralizes the system again).
  • each message is thus associated with at least one validation message generated by at least one receiving device or Iris Robot
  • the succession of validated messages associated with a key control relative to a previous message will thus represent a message chain
  • the mechanism of distribution of the messages associated with referent receiver devices - Fig.1 - (7) will have the major advantage of making the system asynchronous and thus to allow a number unlimited simultaneous message validations;
  • the operation of the Iris Robot (1) is therefore an essential link in the system, this autonomous software robot has functionalities allowing it to be the trusted third trusted limited all the processes described in this invention.
  • the Iris Robots (1) integrate a set of cryptographic keys stored in a cryptoprocessor, allowing it both to identify itself on the network, to renew its keys, but also to provide the computing power necessary while allowing a
  • the private keys of the Iris robots (1) are generated directly by said cryptoprocessor so as never to leave the sequestration zone, thus enabling them to guard against any software or hardware attack.
  • it includes a GPS chip to determine for example to 50 km near the position of the robot (which is also verified by network latency between the different robots). Only the operation of the NoSQL database requires more resources that are provided by embedded devices such as those integrated in the "Internet box", "Raspberry PI" or smart mobile phones.
  • the work done by at least one Iris robot is as follows:
  • FIG. 5 represents the materialization of the proof of the work of a robot
  • the first validation message (PREMSG_VALID) (FIG. 7) comprises the following data:
  • the message (VALID_ROBOT) contains the following data:
  • robots' compensation algorithms are focused on favoring the receiving devices or Iris robots (1), hosted by the largest number of individuals. , relying for example on the ability of issuing devices to certify the uniqueness of a digital identity.
  • the transmitter device shown in FIG. 2 will for example display several performance indices, both to maximize the gains associated with mining, but also to enable the various robots to be able to maximize the efficiency of their work, the performance indices displayed on the screen. For example, there are the network, the filling rate of the disks, the utilization rates of the microprocessor or of the memory. All of these indices aim to allow the entire network to function optimally.
  • the system will impose for example d as many validations as the value (VAL) indicated in the message (15) will be high - Fig.6, for example, to validate a message indicating a value of 0.0001 it will take five validations is 5 x 500 km distance while to validate a value of 100 it will for example 77 validations or 77 x 500km or approximately the perimeter of the Earth cumulative distance.
  • VAL value indicated in the message
  • the validations are performed asynchronously .
  • Fig.7- the transfer of value realized on the operation
  • TXN1 can be used instantly to be transferred to the "account 3", against the operation (TXN3), which has obtained only three validations out of the five needed, must wait for the validation of two robots
  • TXN2 message (TXN2) to be validated, no robot having the right, through intelligent contracts, to validate a message referring to a previous message that would not have been validated.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Measurement Of The Respiration, Hearing Ability, Form, And Blood Characteristics Of Living Organisms (AREA)
  • Information Transfer Between Computers (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Ultra Sonic Daignosis Equipment (AREA)
  • Measuring Pulse, Heart Rate, Blood Pressure Or Blood Flow (AREA)
  • Measurement Of Velocity Or Position Using Acoustic Or Ultrasonic Waves (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention se rapporte à un procédé permettant de valider des chaînes de messages à travers un réseau décentralisé. Ledit procédé permet en outre de gérer les validations des messages relatifs à une chaîne de messages de façon unitaire et asynchrone rendant ainsi le procédé illimité en termes de performance. Le procédé permet également une sécurité et une confidentialité renforcées notamment par l'intégration des contraintes en nombre et en géolocalisation des validations des messages. Le procédé permet ainsi, par l'intermédiaire d'un réseau décentralisé de tiers de confiance à confiance limitée, de redonner une véritable confiance aux utilisateurs.

Description

Dispositif d'authentification biométrique adaptatif par échographie, photographies en lumière visible de contraste et infrarouge, sans divulgation, à travers un réseau informatique décentralisé
La présente invention se rapporte au domaine des chaînes de messages. Plus particulièrement, l'invention a trait à des moyens de validation desdites chaînes de messages, adaptés notamment pour sécuriser des
transactions, sans divulgation, à travers un réseau informatique décentralisé.
Cette invention intègre la notion de chaînes de messages, qui contrairement aux technologies courantes, notamment celles reposant sur des bases de données centralisées qu'elles soient distribuées ou non, qui bien que gagnant en performance sont irrémédiablement limitées par leur caractère
centralisé.
D'autres procédés visant à pallier ces limitations sont ainsi connus.
En particulier, il est possible, par l'intermédiaire de la technologie des chaînes de blocs - plus généralement désigné par le terme anglo-saxon de
« Blockchain » de valider des blocs de transactions à travers un réseau
décentralisé. Néanmoins avec ce type de technologies il n'est pas possible de valider les transactions une par une. Cette technologie oblige de traiter la
validation des transactions par blocs de messages ce qui a pour conséquence de générer une latence importante sur la validation des transactions et donc
de réduire notablement la capacité de cette technologie à traiter un nombre
élevé de transactions en parallèle, chaque bloc ayant une taille limitée et
nécessitant un temps fixé par la complexité à résoudre un calcul. En outre,
cette technologie « brûle » beaucoup d'énergie, à la fois par les calculs
complexes qu'elle nécessite, mais également par le nombre très important de validations inutiles, en effet un seul dispositif de validation pourra valider un
bloc de transaction.
C'est pourquoi il existe un besoin pour des moyens de gestion de chaîne de messages permettant à la fois de se reposer sur des dispositifs de
validation à travers un réseau décentralisé, mais également de permettre une
validation des messages d'une chaîne de messages non plus par blocs, mais de façon unitaire.
Un objet de l'invention est de fournir des moyens de gérer les
validations des messages relatifs à une chaîne de message de façon unitaire à travers un réseau de validation décentralisé. Un autre objet de cette invention est de se reposer sur le mécanisme des bases de données NoSQL pour introduire la notion de noeuds « référents >> à une chaîne de transaction donnée permettant ainsi de valider un message unitaire sur un réseau décentralisé planétaire et de façon instantanée. Un autre objet de cette invention est d'apporter un nouveau mécanisme permettant de valider des chaînes de messages indépendamment les unes des autres et ainsi de rendre le procédé illimité en termes de performance. Un autre objet est de permettre une sécurité et une confidentialité renforcées pour les utilisateurs de cette technologie. Un autre objet est de permettre une complexité de validation d'autant plus importante que les messages à valider possèdent une criticité élevée, cette complexité est gérée à la fois par nombre de validations nécessaires pour un message donné, mais également en termes de répartition géographique des validations. Un autre objet de cette invention est de pouvoir traiter de façon transparente des données hébergées par des dispositifs externes. Enfin l'objet, peut-être le plus important de cette invention, est de s'appuyer sur un réseau décentralisé de tiers de confiance à confiance limitée qui à la fois possèdent les connaissances nécessaires à la validation des messages, mais qui de par la transparence du procédé permet de redonner une véritable confiance aux utilisateurs.
RÉSUMÉ
Ainsi un mode de réalisation prévoit un procédé mis en œuvre dans un réseau, apte à mettre en œuvre un protocole de chaîne de messages, comportant au moins un dispositif émetteur et au moins un premier et au moins un deuxième dispositif récepteur adaptés pour réaliser des calculs
cryptographiques, caractérisé en ce qu'il comporte les étapes suivantes :
• une première étape où au moins un dispositif émetteur transmet au moins un premier message à au moins un premier dispositif récepteur comportant au moins :
- au moins une clé de contrôle (CCJDA2) générée à partir d'une deuxième clé cryptographique et ;
- au moins une clé publique (CPUBJDA1 ) générée à partir d'une première clé cryptographique et ;
- au moins une zone de données (DONNEES) et ;
- au moins une première signature cryptographique (SIGJDA1 ) générée en calculant et en chiffrant la clé de contrôle du contenu du au moins un premier message avec la première clé privée cryptographique et ;
- au moins une deuxième signature cryptographique (SIG_DISPEM) générée en calculant et en chiffrant la clé de contrôle du contenu du au moins un premier message avec la clé privée cryptographique associée au dispositif émetteur.
• une deuxième étape où au moins un premier dispositif récepteur dudit au moins un premier message réalise les opérations suivantes :
- vérifie la concordance entre au moins une clé publique (CPUBJDA1 ) et une signature cryptographique (SIGJDA1 ) du au moins un premier message et ;
- vérifie la concordance entre la au moins une deuxième signature cryptographique du dispositif (SIG_DISPEM) et une liste de clés publiques cryptographiques préalablement connues par au moins un dispositif récepteur et associées aux dispositifs émetteurs et ;
- calcule la clé publique (CTRL_PUBU) correspondante à la signature dudit dispositif émetteur (SIG_DISPEM) à partir de clés publiques cryptographiques préalablement connues par au moins un dispositif récepteur et associées aux dispositifs émetteurs et ; - génère au moins un deuxième message de validation associé audit au moins un premier message et comportant au moins :
- la clé de contrôle calculée du contenu du au moins un premier message (SIG_MSG) et ;
- la clé de contrôle (CTRL_PUBU) associée à la clé publique cryptographique ayant permis de vérifier la signature dudit dispositif émetteur (SIG_DISPEM) et ;
- un code de statut relatif à la validité dudit au moins un premier message (STATUT) et ;
- une clé publique (PUB_ROBOT) dudit au moins un premier dispositif récepteur générée à partir d'au moins une clé cryptographique propre au au moins un premier dispositif récepteur et ;
- la signature cryptographique (SIG_ROBOT) générée en calculant et en chiffrant la clé de contrôle du contenu du au moins un premier message et du contenu du au moins un deuxième message avec la clé privée cryptographique associée au au moins un premier dispositif récepteur et ;
- diffuse le premier et le deuxième message à au moins un deuxième dispositif récepteur.
une troisième étape, où au moins un deuxième dispositif récepteur desdits au moins un premier et au moins un deuxième message transmis par le au moins un premier dispositif récepteur réalise les opérations suivantes :
- vérifie la concordance entre au moins une clé publique (CPUBJDA1 ) et une signature cryptographique (SIGJDA1 ) du au moins un premier message transmis par le dispositif émetteur et ;
- vérifie la concordance entre la signature (SIG_ROBOT) et la clé publique cryptographique (PUB_ROBOT) dudit premier dispositif récepteur et ;
- vérifie la concordance entre la signature du au moins un premier message du dispositif émetteur (SIG_DISPEM) et la clé publique calculée (CTRL_PUBU) par le au moins un premier dispositif récepteur et ;
- vérifie la cohérence du code de statut (STATUT) et ; - génère au moins un troisième message de validation associé au au moins un premier et au au moins un deuxième message comportant :
- la clé de contrôle (SIG_MSG) calculée du contenu du au moins un premier message et ;
- la clé de contrôle (CTRL_PUBU) associée à la clé publique cryptographique ayant permis de vérifier la signature dudit au moins un dispositif émetteur (SIG_DISPEM) et ;
- un code de statut relatif à la validité dudit au moins un premier message (STATUT) et ;
- une clé publique (PUB_ROBOT2) dudit au moins un deuxième dispositif récepteur générée à partir d'au moins une clé cryptographique propre audit au moins un deuxième dispositif récepteur et ;
- la signature cryptographique (SIG_ROBOT2) générée en calculant et en chiffrant la clé de contrôle du contenu du au moins un premier message et du contenu du au moins un deuxième message avec la clé privée cryptographique associée au au moins un deuxième dispositif récepteur.
Selon un mode de réalisation, le procédé est apte à relier au moins un premier message à au moins un deuxième message par l'intermédiaire d'au moins deux clés de contrôle, une clé publique et une signature, le procédé étant caractérisé en ce que ledit au moins un deuxième message comporte :
• au moins une clé de contrôle (CCJDA2) générée à partir d'une deuxième clé cryptographique et ;
• au moins une clé de contrôle (CCJDA1 ), au moins une clé publique (CPUBJDA1 ) et au moins une signature (SIGJDA1 ) dudit au moins un premier message générée à partir d'une première clé cryptographique et ;
• la signature (SIGJDA1 ) étant générée en calculant la clé de contrôle du contenu du deuxième message et en chiffrant le résultat avec la première clé privée cryptographique.
Selon un mode de réalisation, le procédé est apte à mettre en oeuvre un réseau décentralisé de pair à pair, comportant au moins un premier et un deuxième dispositif récepteur adaptés pour stocker des données et une liste d'au moins un dispositif récepteur dudit réseau décentralisé de pair-à- pair, caractérisé en ce qu'il comporte les étapes suivantes :
• une première étape où au moins un premier dispositif récepteur interroge au moins un deuxième dispositif récepteur dudit réseau décentralisé de pair à pair afin de récupérer la liste d'au moins un dispositif récepteur dudit réseau décentralisé de pair à pair ;
• une deuxième étape où ledit premier dispositif récepteur récupère les données provenant du au moins un dispositif récepteur dudit réseau décentralisé de pair à pair à partir de la liste du au moins un dispositif récepteur dudit réseau décentralisé de pair à pair ;
• une troisième étape où ledit premier dispositif récepteur s'inscrit auprès du au moins un dispositif récepteur dudit réseau décentralisé de pair à pair en tant que nouveau dispositif récepteur dudit réseau décentralisé de pair à pair ;
• une quatrième étape où ledit premier dispositif récepteur mets à disposition d'au moins un autre dispositif récepteur ladite liste d'au moins un dispositif récepteur dudit réseau décentralisé de pair à pair ainsi que les données provenant du au moins un dispositif récepteur dudit réseau décentralisé de pair à pair.
Selon un mode de réalisation, le procédé est apte à transmettre au moins un message à au moins un dispositif récepteur dudit réseau
décentralisé de pair à pair, caractérisé en ce qu'il comporte les étapes suivantes :
• une première étape où au moins un dispositif émetteur interroge au moins un dispositif récepteur dudit réseau décentralisé de pair à pair afin de récupérer la liste d'au moins un dispositif récepteur dudit réseau décentralisé de pair à pair ;
• une deuxième étape où ledit dispositif émetteur transmet au moins un message sur au moins un dispositif récepteur listé dans ladite liste d'au moins un dispositif récepteur dudit réseau décentralisé de pair à pair.
Selon un mode de réalisation, le procédé est apte à identifier au moins un dispositif récepteur réfèrent (7) relatif à au moins une information d'au moins un message caractérisé en ce qu'il permet d'identifier le au moins un dispositif réfèrent (7) à partir : • d'au moins une information contenue dans ledit au moins un message et ;
• au moins un algorithme de répartition des messages et ;
• et au moins une liste d'au moins un dispositif récepteur.
Selon un mode de réalisation, le procédé est apte à valider et à transmettre au moins un message à au moins un dispositif récepteur réfèrent (7) , caractérisé en ce qu'il comporte les étapes suivantes :
• le au moins un dispositif récepteur après réception dudit au moins un message :
- vérifie la validité dudit au moins un message et calcul le dispositif récepteur réfèrent (7) relatif à la clé de contrôle dudit au moins un message ;
- génère au moins un message de validation associé audit au moins un message ;
- diffuse ledit au moins un message et ledit au moins un message de validation audit au moins un dispositif récepteur réfèrent (7) relatif à la clé de contrôle dudit au moins un message.
Selon un mode de réalisation, le procédé est caractérisé en ce qu'il comporte en outre au moins une base de données.
Selon un mode de réalisation, le procédé est apte à stocker et à répliquer au moins un message dans au moins une base de données d'au moins un dispositif récepteur selon un algorithme de répartition des données, le procédé étant caractérisé en ce que ledit au moins un dispositif récepteur identifie pour ledit au moins un message au moins une base de données et au moins un dispositif récepteur en fonction :
• d'au moins une information relative audit au moins un message et ;
• en fonction d'au moins un algorithme de répartition des données et ;
• en fonction d'au moins une liste d'au moins un dispositif récepteur.
Selon un mode de réalisation, le procédé est adapté pour relier au moins un message à au moins une chaîne de messages par l'intermédiaire d'au moins un message de validation d'au moins un dispositif récepteur, caractérisé en ce qu'il comporte les étapes suivantes :
• une première étape où au moins un dispositif récepteur : ■ valide qu'au moins un deuxième message ayant pour clé de contrôle (CCJDA2) est relié à au moins un premier message ayant pour clé de contrôle (CCJDA1 ) en vérifiant la cohérence entre la clé de contrôle (CCJDA1 ), la clé publique (CPUBJDA1 ) et la signature (SIGJDA1 ) indiquées dans le au moins un deuxième message et ;
■ calcul la clé publique (CTRL_PUBU) correspondante à la clé privée du dispositif émetteur ayant permis de générer la signature (SIG_DISPEM) du au moins un deuxième message.
• une deuxième étape ou ledit au moins un dispositif récepteur ajoute au moins un message de validation audit au moins un deuxième message comportant les informations suivantes :
■ informations relatives audit message (PREMSG_VALID) comprenant :
- la liste (LIST_VALID) d'au moins un dispositif récepteur ayant préalablement validé ledit au moins un premier message et ;
- la clé de contrôle (SIG_MSG) du contenu du deuxième message et ;
- une zone de donnée (DON) et ;
- ladite clé publique (CTRL_PUBU) correspondante à la signature du dispositif émetteur (SIG_DISPEM) du au moins un deuxième message.
■ informations relatives à la validation dudit au moins un dispositif récepteur (VALID_ROBOT) comprenant :
- le statut (STATUT) de la validation dudit dispositif récepteur et ;
- la clé publique associée audit au moins un dispositif récepteur (PUB_ROBOT) et ;
- la signature cryptographique (SIG_ROBOT) générée en calculant et en chiffrant la clé de contrôle du contenu du au moins un deuxième message avec la clé privée cryptographique associée audit au moins un dispositif récepteur.
Selon un mode de réalisation, le procédé est apte à valider indépendamment et de manière asynchrone au moins un message d'au moins une chaîne de messages, caractérisé en ce qu'il comporte les étapes suivantes : une première étape où le au moins un premier dispositif récepteur réceptionne, valide, identifie le dispositif récepteur réfèrent (7) relatif audit au moins un premier message, et :
- génère un message (PREMSG_VALID) et ;
- génère un message (VALID_ROBOT) attestant de la validation dudit au moins un premier message et ;
- diffuse audit au moins un dispositif récepteur réfèrent :
- ledit au moins un premier message et ;
- le message (PREMSG_VALID) et ;
- et le message (VALID_ROBOT).
une seconde étape où au moins un deuxième dispositif récepteur réceptionne, valide, identifie le dispositif récepteur réfèrent (7) relatif audit au moins un premier message, et :
- génère un message (PREMSG_VALID) et ;
- génère un message (VALID_ROBOT) attestant de la validation dudit au moins un premier message et ;
- diffuse audit au moins un dispositif récepteur réfèrent :
- ledit au moins un premier message et ;
- le message (PREMSG_VALID) et ;
- et le message (VALID_ROBOT).
une troisième étape où ledit au moins un dispositif récepteur réfèrent relatif au au moins un premier réceptionne ledit au moins un premier message transmit, le message (PREMSG_VALID) et le message (VALID_ROBOT) d'au moins un dispositif récepteur et :
- stocke ledit au moins un premier message transmit seulement si celui-ci n'est pas déjà stocké et vérifie dans le cas contraire qu'il est concordant avec ledit au moins un premier message précédemment stocké et ;
- stocke ledit message (PREMSG_VALID) seulement si ledit message (PREMSG_VALID) n'est pas déjà stocké et vérifie dans le cas contraire qu'il est concordant avec ledit au moins un message (PREMSG_VALID) précédemment stocké et ;
- stocke ledit message (VALID_ROBOT) seulement si ledit message (VALID_ROBOT) n'est pas déjà stocké.
une quatrième étape où au moins un dispositif récepteur réceptionne au moins un deuxième message disposant de la clé de contrôle (CCJDA2) et dont la précédente clé de contrôle indiquée (CCJDA1 ) correspond à la clé de contrôle dudit premier message, et réalise les opérations suivantes :
- identifie le au moins un dispositif récepteur réfèrent (7) du au moins un premier et du au moins un deuxième message et ;
- récupère ledit au moins un premier message, le message (PREMSG_VALID) et l'ensemble des messages (VALID_ROBOT) auprès dudit au moins un dispositif récepteur réfèrent (7) dudit au moins un premier message et ;
- vérifie la validité de chacun des messages et les critères de conformité relatifs aux dispositifs récepteurs ayant généré un message de validation (VALID_ROBOT) et ;
- seulement si les critères de conformité sont respectés :
- génère un message (PREMSG_VALID) et un message de validation (VALID_ROBOT) relatif au au moins un deuxième message et ;
- diffuse ledit au moins un deuxième message, le message (PREMSG_VALID) et le message (VALID_ROBOT) audit au moins un dispositif récepteur réfèrent relatif au au moins un deuxième message.
Selon un mode de réalisation, le procédé est adapté pour valider au moins un message d'au moins une chaîne de messages, en prenant en compte la position géographique d'au moins un autre dispositif récepteur ayant préalablement validé ledit message, caractérisé par les étapes suivantes
• au moins un dispositif récepteur réceptionne au moins un deuxième message disposant de la clé de contrôle (CCJDA2) et dont la précédente clé de contrôle indiquée (CCJDA1 ) correspond à la clé de contrôle d'au moins un premier message, et réalise les opérations suivantes :
■ identifie le au moins un premier dispositif récepteur réfèrent (7) relatif audit au moins un premier message et ;
■ identifie le au moins un deuxième dispositif récepteur réfèrent (7) relatif audit au moins un deuxième message et ;
■ récupère le message (PRE SG_VALID) et l'ensemble des messages (VALID_ROBOT) relatifs audit au moins un premier message auprès dudit au moins un premier dispositif récepteur réfèrent (7) dudit au moins un premier message et ; ■ vérifie la validité de chacun des messages (PREMSG_VALID) et (VALID_ROBOT) et la position géographique de chacun des au moins un dispositif récepteur à l'origine d'au moins un message de validation (VALID_ROBOT) du au moins un premier message et ;
■ seulement si les critères de conformité relatifs à la position géographique des au moins un dispositif récepteur ayant générés un message de validation (VALID_ROBOT) sont réunis :
- génère un message (PREMSG_VALID) contenant la liste (LIST_VALID) du au moins un dispositif récepteur à l'origine d'un message de validation relatif audit premier message et répondant aux critères de conformités relatifs à la position géographique du au moins un dispositif récepteur à l'origine d'un message de validation relatif audit premier message et ;
- génère un message de validation (VALID_ROBOT) relatif audit au moins un deuxième message et ;
- et diffuse au au moins un deuxième dispositif récepteur réfèrent (7) relatif au deuxième message :
- ledit au moins un deuxième message et ;
- le message (PREMSG_VALID) associé et ;
- et le message (VALID_ROBOT) associé.
Selon un mode de réalisation, le procédé est adapté pour valider un message dans une chaîne de messages, en prenant en compte le nombre de dispositifs récepteurs ayant préalablement validé ledit message, le procédé étant caractérisé en ce qu'il comprend les étapes suivantes :
• au moins un dispositif récepteur réceptionne au moins un deuxième message disposant de la clé de contrôle (CCJDA2) et dont la précédente clé de contrôle indiquée (CCJDA1 ) correspond à la clé de contrôle d'au moins un premier message, et réalise les opérations suivantes :
■ identifie lé au moins un premier dispositif récepteur réfèrent (7) relatif audit au moins un premier message et ;
■ identifie le au moins un deuxième dispositif récepteur réfèrent (7) relatif audit au moins un deuxième message et ;
■ récupère le message (PREMSG_VALID) et l'ensemble des messages (VALID_ROBOT) relatifs audit au moins un premier message auprès dudit au moins un premier dispositif récepteur réfèrent dudit au moins un premier message et ; ■ vérifie la validité de chacun des messages (PREMSG_VALID) et (VALID_ROBOT) et le nombre de dispositifs récepteurs à l'origine d'au moins un message de validation (VALID_ROBOT) dudit premier message et ;
■ seulement si les critères de conformité relatifs au nombre de dispositifs récepteurs ayant générés un message de validation (VALID_ROBOT) sont réunis :
- génère un message (PRE SG_VALID) contenant la liste (LIST_VALID) du au moins un dispositif récepteur à l'origine d'un message de validation relatif audit premier message et répondant aux critères de conformités relatifs au nombre de dispositifs récepteurs à l'origine d'un message de validation relatif audit premier message et ;
- génère un message de validation (VALID_ROBOT) relatif audit au moins un deuxième message et ;
- diffuse au au moins un deuxième dispositif récepteur réfèrent (7) relatif au deuxième message :
- ledit au moins un deuxième message et ;
- le message (PREMSG_VALID) associé et ;
- le message (VALID_ROBOT) associé.
BRÈVE DESCRIPTION DES FIGURES
D'autres particularités et avantages de la présente invention apparaîtront, dans la description ci-après de modes de réalisation, en référence aux dessins annexés, dans lesquels :
[Figure 1 ] vue schématique de la transmission et de la validation d'un message comportant des dispositifs émetteurs (2), (3) et (4) et des dispositifs récepteurs (1 ) et (7) intégrés dans un réseau décentralisé (8) selon un mode de réalisation de l'invention ;
[Figure 2] vue schématique des bases de données hébergées par les dispositifs récepteurs selon un mode de réalisation de l'invention ;
[Figure 3] vue schématique du lien entre les clés biométriques, les clés privées cryptographiques, les clés publiques cryptographiques et les clés de contrôle selon un mode de réalisation de l'invention ;
[Figure 4] vue schématique des messages transmis par les dispositifs émetteurs (2) (3) et (4) selon un mode de réalisation de l'invention ;
[Figure 5] vue schématique du contenu d'un message transmis par un dispositif émetteur accompagné des messages de validation des dispositifs récepteurs selon un mode de réalisation de l'invention ;
[Figure 6] vue schématique du nombre de validations de dispositifs récepteurs à réaliser en fonction de la valeur indiquée dans un message de type transfert de valeurs selon un mode de réalisation de l'invention ;
[Figure 7] vue schématique du fonctionnement asynchrone des validations des messages émis par les dispositifs émetteurs et validés par les dispositifs récepteurs selon un mode de réalisation de l'invention.
DESCRIPTION DÉTAILLÉE
En référence notamment à la figure 1 , un procédé mis en œuvre dans un réseau comportant au moins un dispositif émetteur (9) et au moins un premier et un deuxième dispositif récepteur (1 ), tous adaptés pour réaliser des calculs cryptographiques va maintenant être décrit.
L'invention est composée d'une part de dispositifs émetteurs (2), (3) et (4) adaptés pour transmettre et récupérer des messages vers et à partir des dispositifs récepteurs (1 ). Les messages sont stockés à travers des chaînes de messages elles-mêmes stockées sur des bases de données hébergées par les dispositifs récepteurs mis en œuvre dans un réseau de pair à pair décentralisé (8).
Dans la suite de la description, vont être abordés les points suivants auxquels l'invention répond : comment garantir la réplication des données sur l'ensemble de la planète afin de s'affranchir de tout désastre qui pourrait toucher un ou plusieurs continents ? Comment garantir à ce système décentralisé qu'il puisse reposer sur un maximum de petits nœuds plutôt que sur une poignée de centre de données qui créeraient une faille en termes de sécurité dans le système ? Comment couvrir les frais d'électricité et de réseaux qu'aurait un individu qui souhaiterait héberger un nœud ? Comment réduire au minimum la consommation électrique liée à la validation des messages, et comment rendre la validation des messages réellement utile au système ? Comment permettre à un système prévu pour accueillir la totalité de la population de la planète d'optimiser les données qui doivent transiter sur le réseau afin de couvrir les régions qui en sont le plus dépourvues ? Comment garantir la réelle confidentialité des transactions alors même que toutes les transactions seront publiques ? Comment garantir que le dispositif puisse survivre à l'arrivée de l'hypothétique ordinateur quantique ?
Les dispositifs récepteurs (1 ), selon un mode de réalisation, hébergent chacun un premier groupe de bases de données de type NoSQL, les messages sont ainsi accessibles à travers un réseau de pair à pair décentralisé de bases de données de type NoSQL, ces bases de données sont relatives à un usage spécifique, mais restent associées les unes par rapport aux autres - Fig.2 :
• base de données identité (ID) : relative aux messages spécifiques aux identités digitales par exemple d'un individu, d'un objet, d'un groupe d'individus, au stockage de données biométriques, mais également aux messages relatifs à une identité digitale provenant de n'importe quelle base externe.
• base de données contrat (CONTRATS) : relative aux messages
spécifiques à la gestion de contrats intelligents, mettant en jeux des identités digitales spécifiques aux identités stockées dans la base des données (ID), aux identités digitales externes, aux règles relatives aux dispositifs émetteurs et récepteurs, mais également aux messages relatifs à un contrat intelligent provenant de n'importe quelle base externe.
• une meta-base de données (BANQ) : permettant de stocker les valeurs relatives aux messages identités, aux messages contrats, mais également aux messages provenant de n'importe quelle base externe.
• base technique (TECH) : permettant de stocker les données techniques nécessaires au fonctionnement de l'ensemble du système, par exemple la liste et la répartition des nœuds du réseau de pair à pair, les différents messages permettant de renouveler les clés des différents dispositifs.
• base des transactions en attente ou refusées (ATTENTKO) : cette base est relative aux messages en attente ou refusés sur l'ensemble du système, elle stocke les messages en attente par exemple dans le cadre de la notification de l'émetteur ou du destinataire lors d'un transfert de valeurs.
Le réseau pair-à-pair ou— plus généralement désigné par le terme anglo-saxon de « peer-to-peer » est la clé de voûte de tout système décentralisé. Les chaînes de messages telles qu'utilisées dans cette invention utilisent ce type de réseau pour partager les informations et la totalité des ressources de ce système. Les nœuds de ces réseaux sont portés par les dispositifs récepteurs (1 ) qui en plus de la validation des messages assurent le stockage et la diffusion des informations partout où les dispositifs récepteurs (1 ) sont connectés au réseau - Fig.1 . Dans le cadre d'un message émis par un dispositif émetteur, le dispositif émetteur ne contactera donc pas un dispositif récepteur (1 ) en particulier, mais n'importe quel dispositif récepteur (1 ) pour valider le message, le dispositif récepteur (1 ) traitera directement la validation dudit message ou le propagera jusqu'à un dispositif récepteur réfèrent (7) en particulier.
Les problèmes non résolus à ce jour sur les réseaux décentralisés sont ; la gestion de la répartition des données et des validations à travers les nœuds, l'organisation des données pour permettre à chaque nœud de valider/réfuter un message sans avoir à tout modifier, le contrôle de la latence pour qu'un message puisse être validé de part et d'autre de la planète, l'organisation des données pour éviter à un dispositif de télécharger plusieurs messages d'une chaîne pour consulter par exemple son portefeuille de valeurs et sans pour autant passer par un service centralisé, la répartition des données pour que toutes les données ne soient pas répliquées sur l'ensemble des nœuds et optimiser ainsi le taux d'occupation des disques et augmenter significativement la taille globale admissible.
Ces problèmes sont résolus par cette invention, notamment par l'utilisation d'une base de données NoSQL de type « orientée colonnes » particulièrement efficace pour ce type de système décentralisé. Cette base contiendra par exemple 5 schémas de base de données chacun pouvant avoir une stratégie de réplication différente— le découpage des bases de données permet d'appliquer des stratégies de réplication différentes en fonction d'au moins une clé primaire. Les données relatives au stockage des valeurs, matérialisé par la base (BANQ), devront par exemple être répliquées sur l'ensemble des nœuds pour assurer une disponibilité maximale. Les messages relatifs aux données d'identité biométriques pourront, par contre, être réparties de façon moins systématique, le besoin étant pour un utilisateur d'y accéder rapidement (colocalisation sur plusieurs nœuds à proximité), et sur quelques autres nœuds plus éloignés pour assurer la persistance des données même dans le cas ou un pays perdrait sa connexion Internet et/ou son réseau électrique comme cela est régulièrement le cas dans bon nombre de pays en voie de développement. Une des fonctionnalités particulièrement intéressantes dans ce type de base est l'indexation des nœuds en fonction de l'adresse de la clé primaire. Par ce biais, il est donc possible pour chaque nœud, ou dispositif récepteur (1 ) dans le cadre de cette invention, de connaître le ou les dispositif(s) récepteur(s) « référents » (7) à une donnée spécifique. Ainsi, le problème de validation « planétaire » par message est résolu par la connaissance à priori des dispositifs récepteurs référents (7) en charge de ces messages spécifiques.
Les contrats intelligents, également connus sous le terme anglo- saxon de « smart-contract » tels que définis dans cette invention, représentent des programmes dont l'exécution est contrôlée et vérifiable, conçus pour exécuter les termes d'un contrat de façon automatique lorsque certaines conditions sont réunies »
Également, et pour résoudre le problème de « point individuel de défaillance » connu sous le terme anglo-saxon de « Single Point of Failure », la configuration des bases de données ne se fera pas de façon centralisée, mais directement par des algorithmes publiés sur la base relative aux données techniques (TECH), chaque nouveau dispositif récepteur (1 ) qui s'enregistrera dans le système se verra alors automatiquement et dynamiquement attribué un rôle connu et partagé avec les autres dispositifs récepteurs (1 ).
La figure 4 représente une série de messages à destination des bases de données relatives aux dispositifs récepteurs :
• (1 1 ) : un message permettant de relier des clés biométriques à une
identité digitale principale
• (12) : un message relatif à une identité digitale principale
• (13) : un message relatif à une identité digitale
• (14) : un message relatif à un contrat intelligent
• (15) : un message relatif à un transfert de valeurs
Une fois un message transmis, il est alors vérifié puis validé ou non par les dispositifs récepteurs qui ajoutent un message de validation relié audit message transmis. La capacité de la base de données orientée colonne prend tout son sens dans la figure 4 où chaque colonne (CC), (PUB) ... doit pouvoir contenir une infinité de colonnes (BioPubDoigtl [1 ,2,3], BioPubDoigt2[1 ,2,3,4] ... ou encore BioHashDoigtl -1 , BioHashDoigtl -2... ), dans la pratique il y aura potentiellement autant de colonnes relatives aux messages de validation des dispositifs récepteurs que de dispositifs récepteurs, ces colonnes sont également appelées « supercolonnes »..
Pour la compréhension des paragraphes suivants il est à noter que le travail de minage est une étape fondamentale des technologies de chaînes de blocs plus généralement désigné par le terme anglo-saxon de
« Blockchain », en effet, c'est par le biais du minage que chaque transaction est validée et que la sécurité du réseau est assurée, car dans chaque travail de minage l'ensemble de la chaîne doit être vérifiée, si une transaction est ajoutée ou modifiée alors c'est toute la branche de la chaîne qui est refusée. Dans le cadre de cette invention, le travail de minage est assuré par des dispositifs récepteurs, ou plus exactement des agents logiciels autonomes aussi appelés « Robots d'Iris » (1 ) qui vont répondre à des appels d'offres (le minage en est un) qui sont publiés dans les bases relatives aux contrats (CONTRATS) et relatives aux données techniques (TECH). Les Robots d'Iris acceptent ou non cet appel d'offres suivant la rémunération proposée et avec l'obligation d'exécuter le contrat et de suivre les règles générales du système (ce qui est vérifié en permanence par les autres Robots d'Iris - Fig.1 -1 )— dans le cas improbable d'un « robot mineur fou », les autres robots mineurs n'utilisent jamais les blocs qu'il a généré et le révoquent de la liste des Robots d'Iris habilités du dispositif. Les robots d'Iris (1 ) sont donc les tiers de confiance de ce réseau, mais à confiance limitée, car chaque transaction devra être prouvée depuis son origine.
Le minage est la grande révolution intégrée dans les protocoles de chaînes de blocs, ce dispositif permet en effet de gérer la sécurité d'un réseau distribué grâce au travail de minage qui, à la fois valide chaque bloc de transactions, mais où chaque mineur surveille aussi depuis le début que chaque bloc d'une chaîne est valide, et lié au précédent. Néanmoins ce système « réellement démocratique » pose trois problèmes de taille qui sont :
• l'attaque des 51 %, qui consiste pour l'attaquant à fournir 51 % des
ressources disponibles et donc statistiquement et temporairement d'avoir le quasi-monopole sur la validation des blocs (6 transactions statistiquement pour être certain qu'un transfert de bitcoin
(cryptomonnaie fonctionnant à travers un réseau décentralisé) est bien intégrée dans la chaîne principale)
• deuxième problème, plus pervers celui-ci, qui est l'émergence des
centres dédiés de calcul de minage ayant pour effet d'annihiler l'intérêt pour un utilisateur de prendre part au réseau de minage ce qui est catastrophique pour la sécurité du système qui se retrouve dans les problèmes des systèmes centralisés.
• Bien que la preuve de travail soit nécessaire pour vérifier le travail effectif d'un mineur, le fonctionnement actuel qui consiste à résoudre des problèmes mathématiques « brûle de l'énergie » sans pour autant être utile au système. Cette invention s'attarde particulièrement sur ce point pour que la preuve de travail soit réellement utile au système dans son ensemble.
Enfin, la totalité des systèmes actuels basés sur une technologie
Blockchain utilise des blocs contenant plusieurs transactions, ce qui a pour effet de rendre le système lent (en moyenne 10 minutes) pour la validation réelle d'une transaction, d'autre part, ce fonctionnement a pour effet de rendre une partie du travail de minage inutile, car utilisant par exemple des transactions déjà validées, un des derniers inconvénients majeurs de cette validation par bloc et de nécessiter pour un utilisateur donné de télécharger tous les blocs pour connaître l'état de ses comptes (sauf à passer par un système centralisé qui fait le travail pour lui, mais qui centralise à nouveau le système).
Le système de minage proposé dans le cadre de cette invention donc :
De garantir une exécution transparente des règles ou contrats de minage par la publication d'au moins un contrat dans la base de donnée relative aux données techniques (TECH) ;
De contrôler la distribution du « droit de minage » pour ne pas annihiler l'intérêt du plus grand nombre à participer à la sécurité du réseau (avec une répartition égalitaire des gains pour l'ensemble des robots (1 ) qui contribuent à la validation des messages, en d'autres termes, la chaîne technique (TECH) intégrera un algorithme qui limite le nombre de robots (1 ) afin qu'il reste en permanence rentable pour ceux qui l'hébergent ;
De fournir comme preuve de travail, la vérification des clés publiques associées aux clés privées utilisées pour la signature des dispositifs émetteurs habilités. Le travail consistant à indiquer la clé de contrôle de ladite clé publique associée à la signature utilisée par ledit dispositif émetteur (la liste des clés publiques relatives aux dispositifs habilités étant stockée sur la base technique (TECH)). Ce procédé permet d'ajouter une sécurité et une confidentialité supplémentaire tout en maîtrisant la taille des données des messages de validation ;
De valider chaque message un à un en lieu et place d'une validation par bloc de messages, chaque message est ainsi associé à au moins un message de validation généré par au moins un dispositif récepteur ou Robot d'Iris, la succession de messages validés associés à une clé de contrôle relative à un précèdent message représentera ainsi une chaîne de message, en outre le mécanisme de répartition des messages associés à des dispositifs récepteurs référents - Fig.1 - (7) aura pour avantage majeur de rendre le système asynchrone et donc de permettre un nombre illimité de validations de messages simultanés ;
• Enfin le fonctionnement des Robots d'Iris (1 ) aura le double avantage de prouver à la fois la validité des messages, mais également de prouver la réplication du stockage des messages.
Le fonctionnement du Robot d'Iris (1 ) est donc un maillon essentiel du système, ce robot logiciel autonome dispose de fonctionnalités lui permettant d'être le tiers de confiance à confiance limitée de l'ensemble des procédés décrit dans cette invention. Les Robots d'Iris (1 ) intègrent un jeu de clés cryptographiques stockées dans un cryptoprocesseur, lui permettant à la fois de s'identifier sur le réseau, de renouveler ses clés, mais également de fournir la puissance de calcul nécessaire tout en permettant une
consommation électrique la plus faible possible. Les clés privées des robots d'Iris (1 ) sont générées directement par ledit cryptoprocesseur de sorte à ne jamais sortir de la zone de séquestre, leur permettant ainsi de se prémunir contre toute attaque logicielle ou matérielle. Pour assurer une réplication planétaire des données, celui-ci intègre une puce GPS permettant de déterminer par exemple à 50 km près la position du robot (ce qui est également vérifié par les temps de latence réseau entre les différents robots). Seul le fonctionnement de la base de données NoSQL demande des ressources plus importantes qui sont assurées par des dispositifs embraqués tels que ceux intégrés dans les « box Internet », les « Raspberry PI » ou encore les téléphones portables intelligents.
Les travaux effectués par au moins un robot d'Iris sont les suivants :
• réceptionnent des messages émis (10) par les dispositifs émetteurs (9) ;
• propagent lesdits messages émis vers les robots référents (7) ;
• vérifient que la signature du dispositif émetteur (SIG_DISPEM) est valide et qu'elle correspond à au moins une des clés publiques listées dans la liste des clés publiques correspondantes aux dispositifs émetteurs autorisés ;
• si le message n'est pas encore associé à un message de validation sur le robot référant associé à la clé de contrôle relative au message, alors ledit robot générera un message (PREMSG_VALID) - Fig.5 - auquel il associera un message de validation (VALID_ROBOT), sinon ledit robot vérifiera le message (PREMSG_VALID) et si le résultat est concordant avec ses calculs, il ajoutera alors un message supplémentaire
(VALID_ROBOT), dans le cas contraire, si les données ne sont pas correctes ledit robot alertera les autres robots par l'intermédiaire de la base (TECH).
La figure 5 représente la matérialisation de la preuve du travail d'un robot, le premier message de validation (PREMSG_VALID) (Fig.7) comporte les données suivantes :
• (LIST_VALID) : cette zone liste les clés publiques des robots ayant
validés le précédent message, seul le nombre nécessaire de robots est mentionné et par ordre de date de validation ;
• (DON) : zone de donnée chiffrée ou non avec la clé publique de la clé partagée des robots ;
• (SIG_MSG) : la signature du message comprenant les messages de validations des robots mentionnés dans la zone (LIST_VALID) ;
• (CTRL_PUBU) : la clé de contrôle correspondante à la clé publique
utilisée par le dispositif émetteur pour signer le message ;
• (CTRL_AMO) : la clé de contrôle correspondante par exemple à la clé publique utilisée par le cryptoprocesseur amovible du dispositif émetteur pour signer le message, cette zone est chiffrée avec la clé publique de la clé partagée des robots.
Le message (VALID_ROBOT) comporte les données suivantes :
• (STATUT) : contenant le code de statut du message de validation ;
• (D) : contenant la date de génération du message de validation ;
• (PUB_ROBOT) : zone contenant la clé publique propre au robot ayant validé le message ;
• (SIG_ROBOT) : signature associée au message de validation et associée à la clé publique dudit robot.
Il est à noter que la vérification du calcul est instantanée pour les robots qui en font la vérification, car la clé de contrôle de la signature du dispositif émetteur est déjà indiquée dans le message (PREMSG_VALID) généré préalablement. Le message d'alerte relatif à un calcul erroné ou à un non-respect du contrat d'un robot donné est stocké sur la base (TECH), un nombre significatif d'autres robots devront alors confirmer l'erreur ou la fraude, si un tel cas devait se produire le robot à l'origine du message frauduleux serait alors révoqué ainsi que l'individu qui l'aurait enregistré.
La répartition géographique des robots (1 ) étant un élément fondamental de la sécurité du réseau, les algorithmes de rémunération des robots s'attachent à favoriser les dispositifs récepteurs ou robots d'Iris (1 ), hébergés par le plus grand nombre d'individus, en s'appuyant par exemple sur la capacité des dispositifs émetteurs à certifier l'unicité d'une identité digitale. Le dispositif émetteur représenté en figure 2 affichera par exemple plusieurs indices de performance, à la fois pour maximiser les gains liés au minage, mais également pour permettre aux différents robots de pouvoir maximiser l'efficacité de leurs travaux, les indices de performance affichés sur le boîtier sont par exemple le réseau, le taux de remplissage des disques, les taux d'usage du microprocesseur ou de la mémoire. L'ensemble de ces indices vise à permettre à l'ensemble du réseau de fonctionner de façon optimale.
Pour assurer une plus grande sécurité à l'ensemble de la chaîne (en nombre de validations et également en nombre et distance de réplications) et augmenter significativement la complexité d'un attaquant en fonction de la criticité du message, le système imposera par exemple d'autant plus de validations que la valeur (VAL) indiquée dans le message (15) sera élevée - Fig.6, par exemple, pour valider un message indiquant une valeur de 0,0001 il faudra cinq validations soit 5 x 500 km de distance alors que pour valider une valeur de 100 il faudra par exemple 77 validations soit 77 x 500km soit approximativement le périmètre de la Terre en distance cumulée.
Pour réaliser ces opérations sans engendrer une latence réseau trop importante et tout en assurant une sécurité d'autant plus importante que la criticité est élevée, ce qui, de fait, est une des innovations majeures de cette invention, les validations sont réalisées de façon asynchrone. Par exemple de la façon suivante— Fig.7— le transfert de valeur réalisé sur l'opération
(TXN2), qui a été validée par un nombre suffisant de robots pendant
l'opération (TXN1 ) est utilisable instantanément pour être transférée sur le « compte 3 », par contre l'opération (TXN3), qui n'a obtenu que trois validations sur les cinq nécessaires, doit attendre la validation de deux robots
supplémentaires sur le message (TXN2) pour être validée, aucun robot n'ayant le droit, par l'intermédiaire de contrats intelligents, de valider un message faisant référence à un message précédent qui n'aurait pas été validé.
Il est à noter également dans cet exemple de la figure 7, que l'attente nécessaire au transfert des valeurs du « compte 3 », ne concerne que le « compte 3 » et seulement si celui ne possède pas d'autres valeurs que celles mentionnées dans l'exemple - Fig.7. La validation complète, par exemple jusqu'à 322 validations, n'est nécessaire qu'au moment de la réutilisation des fonds pour d'autres transactions.
Ainsi, non seulement les vérifications effectuées sont d'autant plus importantes que la criticité du message est élevée, mais également, il n'est pas nécessaire d'attendre la validation des messages précédents pour traiter les nouveaux messages. Ce qui permet d'autoriser un nombre quasiment illimité de transactions simultanées, ce qui à l'heure actuelle n'existe pas, d'autant moins sur des messages de transferts de valeurs.
C'est la présence de l'adresse d'un robot dans la liste des robots listés qui permet la rémunération de chacun, si toutefois la transaction est bien validée. Ainsi, pour éviter le phénomène de validations infinies, seules les validations nécessaires et indiquées dans (LIST_VALID) donneront lieu à rémunération.

Claims

REVENDICATIONS
1 ) Procédé mis en œuvre dans un réseau, apte à mettre en œuvre un protocole de chaîne de messages, comportant au moins un dispositif émetteur et au moins un premier et au moins un deuxième dispositif récepteur adaptés pour réaliser des calculs cryptographiques, caractérisé en ce qu'il comporte les étapes suivantes :
• une première étape où au moins un dispositif émetteur transmet au moins un premier message à au moins un premier dispositif récepteur comportant au moins :
- au moins une clé de contrôle (CCJDA2) générée à partir d'une deuxième clé cryptographique et ;
- au moins une clé publique (CPUBJDA1 ) générée à partir d'une première clé cryptographique et ;
- au moins une zone de données (DONNEES) et ;
- au moins une première signature cryptographique (SIGJDA1 ) générée en calculant et en chiffrant la clé de contrôle du contenu du au moins un premier message avec la première clé privée cryptographique et ;
- au moins une deuxième signature cryptographique (SIGJDISPEM) générée en calculant et en chiffrant la clé de contrôle du contenu du au moins un premier message avec la clé privée cryptographique associée au dispositif émetteur.
• une deuxième étape où au moins un premier dispositif récepteur dudit au moins un premier message réalise les opérations suivantes :
- vérifie la concordance entre au moins une clé publique (CPUBJDA1 ) et une signature cryptographique (SIGJDA1 ) du au moins un premier message et ;
- vérifie la concordance entre la au moins une deuxième signature cryptographique du dispositif (SIG_DISPEM) et une liste de clés publiques cryptographiques préalablement connues par au moins un dispositif récepteur et associées aux dispositifs émetteurs et ;
- calcule la clé publique (CTRL_PUBU) correspondante à la signature dudit dispositif émetteur (SIG_DISPEM) à partir de clés publiques cryptographiques préalablement connues par au moins un dispositif récepteur et associées aux dispositifs émetteurs et ;
- génère au moins un deuxième message de validation associé audit au moins un premier message et comportant au moins : - la clé de contrôle calculée du contenu du au moins un premier message (SIG_MSG) et ;
- la clé de contrôle (CTRL_PUBU) associée à la clé publique cryptographique ayant permis de vérifier la signature dudit dispositif émetteur (SIG_DISPEM) et ;
- un code de statut relatif à la validité dudit au moins un premier message (STATUT) et ;
- une clé publique (PUB_ROBOT) dudit au moins un premier dispositif récepteur générée à partir d'au moins une clé cryptographique propre au au moins un premier dispositif récepteur et ;
- la signature cryptographique (SIG_ROBOT) générée en calculant et en chiffrant la clé de contrôle du contenu du au moins un premier message et du contenu du au moins un deuxième message avec la clé privée cryptographique associée au au moins un premier dispositif récepteur et ;
- diffuse le premier et le deuxième message à au moins un deuxième dispositif récepteur.
• une troisième étape, où au moins un deuxième dispositif récepteur desdits au moins un premier et au moins un deuxième message transmis par le au moins un premier dispositif récepteur réalise les opérations ' suivantes :
- vérifie la concordance entre au moins une clé publique (CPUBJDA1 ) et une signature cryptographique (SIGJDA1 ) du au moins un premier message transmis par le dispositif émetteur et ;
- vérifie la concordance entre la signature (SIG_ROBOT) et la clé publique cryptographique (PUB_ROBOT) dudit premier dispositif récepteur et ;
- vérifie la concordance entre la signature du au moins un premier message du dispositif émetteur (SIG_DISPE ) et la clé publique calculée (CTRL_PUBU) par le au moins un premier dispositif récepteur et ;
- vérifie la cohérence du code de statut (STATUT) et ;
- génère au moins un troisième message de validation associé au au moins un premier et au au moins un deuxième message comportant :
- la clé de contrôle (SIG_MSG) calculée du contenu du au moins un premier message et ; - la clé de contrôle (CTRL_PUBU) associée à la clé publique cryptographique ayant permis de vérifier la signature dudit au moins un dispositif émetteur (SIG_DISPEM) et ;
- un code de statut relatif à la validité dudit au moins un premier message (STATUT) et ;
- une clé publique (PUB_ROBOT2) dudit au moins un deuxième dispositif récepteur générée à partir d'au moins une clé cryptographique propre audit au moins un deuxième dispositif récepteur et ;
- la signature cryptographique (SIG_ROBOT2) générée en calculant et en chiffrant la clé de contrôle du contenu du au moins un premier message et du contenu du au moins un deuxième message avec la clé privée cryptographique associée au au moins un deuxième dispositif récepteur.
2) Procédé selon la revendication 1 , apte à relier au moins un premier message à au moins un deuxième message par l'intermédiaire d'au moins deux clés de contrôle, une clé publique et une signature, le procédé étant caractérisé en ce que ledit au moins un deuxième message comporte :
• au moins une clé de contrôle (CCJDA2) générée à partir d'une deuxième clé cryptographique et ;
• au moins une clé de contrôle (CCJDA1 ), au moins une clé publique (CPUBJDA1 ) et au moins une signature (SIGJDA1 ) dudit au moins un premier message générée à partir d'une première clé cryptographique et ;
• la signature (SIGJDA1 ) étant générée en calculant la clé de contrôle du contenu du deuxième message et en chiffrant le résultat avec la première clé privée cryptographique.
3) Procédé selon la revendication 1 , apte à mettre en œuvre un réseau décentralisé de pair à pair, comportant au moins un premier et un deuxième dispositif récepteur adaptés pour stocker des données et une liste d'au moins un dispositif récepteur dudit réseau décentralisé de pair-à-pair, caractérisé en ce qu'il comporte les étapes suivantes :
• une première étape où au moins un premier dispositif récepteur interroge au moins un deuxième dispositif récepteur dudit réseau décentralisé de pair à pair afin de récupérer la liste d'au moins un dispositif récepteur dudit réseau décentralisé de pair à pair ; • une deuxième étape où ledit premier dispositif récepteur récupère les données provenant du au moins un dispositif récepteur dudit réseau décentralisé de pair à pair à partir de la liste du au moins un dispositif récepteur dudit réseau décentralisé de pair à pair ;
• une troisième étape où ledit premier dispositif récepteur s'inscrit auprès du au moins un dispositif récepteur dudit réseau décentralisé de pair à pair en tant que nouveau dispositif récepteur dudit réseau décentralisé de pair à pair ;
• une quatrième étape où ledit premier dispositif récepteur mets à disposition d'au moins un autre dispositif récepteur ladite liste d'au moins un dispositif récepteur dudit réseau décentralisé de pair à pair ainsi que les données provenant du au moins un dispositif récepteur dudit réseau décentralisé de pair à pair.
4) Procédé selon l'une quelconque des revendications précédentes, adapté pour transmettre au moins un message à au moins un dispositif récepteur dudit réseau décentralisé de pair à pair par l'intermédiaire d'au moins un dispositif émetteur, caractérisé en ce qu'il comporte les étapes suivantes :
• une première étape où au moins un dispositif émetteur interroge au moins un dispositif récepteur dudit réseau décentralisé de pair à pair afin de récupérer la liste d'au moins un dispositif récepteur dudit réseau décentralisé de pair à pair ;
• une deuxième étape où ledit dispositif émetteur transmet au moins un message sur au moins un dispositif récepteur listé dans ladite liste d'au moins un dispositif récepteur dudit réseau décentralisé de pair à pair.
5) Procédé selon l'une quelconque des revendications précédentes, adapté pour identifier au moins un dispositif récepteur réfèrent (7) relatif à au moins une information d'au moins un message caractérisé en ce qu'il permet d'identifier le au moins un dispositif réfèrent (7) à partir :
• d'au moins une information contenue dans ledit au moins un message et ;
• au moins un algorithme de répartition des messages et ;
• et au moins une liste d'au moins un dispositif récepteur.
6) Procédé selon l'une quelconque des revendications précédentes, apte à valider et à transmettre au moins un message à au moins un dispositif récepteur réfèrent (7) , caractérisé en ce qu'il comporte les étapes suivantes :
• le au moins un dispositif récepteur après réception dudit au moins un message :
- vérifie la validité dudit au moins un message et calcul le dispositif récepteur réfèrent (7) relatif à la clé de contrôle dudit au moins un message ;
- génère au moins un message de validation associé audit au moins un message ;
- diffuse ledit au moins un message et ledit au moins un message de validation audit au moins un dispositif récepteur réfèrent (7) relatif à la clé de contrôle dudit au moins un message.
7) Procédé selon l'une quelconque des revendications précédentes, comportant au moins un dispositif récepteur caractérisé en ce qu'il comporte en outre au moins une base de données.
8) Procédé selon l'une quelconque des revendications précédentes, apte à stocker et à répliquer au moins un message dans au moins une base de données d'au moins un dispositif récepteur selon un algorithme de répartition des données, le procédé étant caractérisé en ce que au moins un dispositif récepteur identifie pour au moins un message au moins une base de données et au moins un dispositif récepteur en fonction :
• d'au moins une information relative audit au moins un message et ;
• en fonction d'au moins un algorithme de répartition des données et ;
• en fonction d'au moins une liste d'au moins un dispositif récepteur.
9) Procédé selon l'une quelconque des revendications précédentes, adapté pour relier au moins un message à au moins une chaîne de messages par l'intermédiaire d'au moins un message de validation d'au moins un dispositif récepteur, caractérisé en ce qu'il comporte les étapes suivantes :
• une première étape où au moins un dispositif récepteur :
■ valide qu'au moins un deuxième message ayant pour clé de contrôle (CCJDA2) est relié à au moins un premier message ayant pour clé de contrôle (CCJDA1 ) en vérifiant la cohérence entre la clé de contrôle (CCJDA1 ), la clé publique (CPUBJDA1 ) et la signature (SIGJDA1 ) indiquées dans le au moins un deuxième message et ;
■ calcul la clé publique (CTRL_PUBU) correspondante à la clé privée du dispositif émetteur ayant permis de générer la signature (SIG_DISPEM) du au moins un deuxième message.
• une deuxième étape ou ledit au moins un dispositif récepteur ajoute au moins un message de validation audit au moins un deuxième message comportant les informations suivantes :
■ informations relatives audit message (PREMSG_VALID) comprenant :
- la liste (LIST_VALID) d'au moins un dispositif récepteur ayant préalablement validé ledit au moins un premier message et ;
- la clé de contrôle (SIG_MSG) du contenu du deuxième message et ;
- une zone de donnée (DON) et ;
- ladite clé publique (CTRL_PUBU) correspondante à la signature du dispositif émetteur (SIG_DISPEM) du au moins un deuxième message.
■ informations relatives à la validation dudit au moins un dispositif récepteur (VALID_ROBOT) comprenant :
- le statut (STATUT) de la validation dudit dispositif récepteur et ;
- la clé publique associée audit au moins un dispositif récepteur (PUB_ROBOT) et ;
- la signature cryptographique (SIG_ROBOT) générée en calculant et en chiffrant la clé de contrôle du contenu du au moins un deuxième message avec la clé privée cryptographique associée audit au moins un dispositif récepteur.
10) Procédé selon l'une quelconque des revendications précédentes, apte à valider indépendamment et de manière asynchrone au moins un message d'au moins une chaîne de messages, caractérisé en ce qu'il comporte les étapes suivantes :
• une première étape où le au moins un premier dispositif récepteur réceptionne, valide, identifie le dispositif récepteur réfèrent (7) relatif audit au moins un premier message, et :
- génère un message (PREMSG_VALID) et ; - génère un message (VALID_ROBOT) attestant de la validation dudit au moins un premier message et ;
- diffuse audit au moins un dispositif récepteur réfèrent :
- ledit au moins un premier message et ;
- le message (PREMSG_VALID) et ;
- et le message (VALID_ROBOT).
» une seconde étape où au moins un deuxième dispositif récepteur réceptionne, valide, identifie le dispositif récepteur réfèrent (7) relatif audit au moins un premier message, et :
- génère un message (PREMSG_VALID) et ;
- génère un message (VALID_ROBOT) attestant de la validation dudit au moins un premier message et ;
- diffuse audit au moins un dispositif récepteur réfèrent :
- ledit au moins un premier message et ;
- le message (PREMSG_VALID) et ;
- et le message (VALID_ROBOT).
• une troisième étape où ledit au moins un dispositif récepteur réfèrent relatif au au moins un premier réceptionne ledit au moins un premier message transmit, le message (PREMSG_VALID) et le message (VALID_ROBOT) d'au moins un dispositif récepteur et :
- stocke ledit au moins un premier message transmit seulement si celui-ci n'est pas déjà stocké et vérifie dans le cas contraire qu'il est concordant avec ledit au moins un premier message précédemment stocké et ;
- stocke ledit message (PREMSG_VALID) seulement si ledit message (PREMSG_VALID) n'est pas déjà stocké et vérifie dans le cas contraire qu'il est concordant avec ledit au moins un message (PREMSG_VALID) précédemment stocké et ;
- stocke ledit message (VALID_ROBOT) seulement si ledit message (VALID_ROBOT) n'est pas déjà stocké.
• une quatrième étape où au moins un dispositif récepteur réceptionne au moins un deuxième message disposant de la clé de contrôle (CCJDA2) et dont la précédente clé de contrôle indiquée (CCJDA1 ) correspond à la clé de contrôle dudit premier message, et réalise les opérations suivantes :
- identifie le au moins un dispositif récepteur réfèrent (7) du au moins un premier et du au moins un deuxième message et ; - récupère ledit au moins un premier message, le message (PREMSG_VALID) et l'ensemble des messages (VALID_ROBOT) auprès dudit au moins un dispositif récepteur réfèrent (7) dudit au moins un premier message et ;
- vérifie la validité de chacun des messages et les critères de conformité relatifs aux dispositifs récepteurs ayant généré un message de validation (VALID_ROBOT) et ;
- seulement si les critères de conformité sont respectés :
- génère un message (PREMSG_VALID) et un message de validation (VALID_ROBOT) relatif au au moins un deuxième message et ;
- diffuse ledit au moins un deuxième message, le message (PREMSG.VALID) et le message (VALID_ROBOT) audit au moins un dispositif récepteur réfèrent relatif au au moins un deuxième message.
1 1 ) Procédé selon l'une quelconque des revendications précédentes, adapté pour valider au moins un message d'au moins une chaîne de messages, en prenant en compte la position géographique d'au moins un autre dispositif récepteur ayant préalablement validé ledit message, caractérisé par les étapes suivantes :
• au moins un dispositif récepteur réceptionne au moins un deuxième message disposant de la clé de contrôle (CCJDA2) et dont la précédente clé de contrôle indiquée (CCJDA1 ) correspond à la clé de contrôle d'au moins un premier message, et réalise les opérations suivantes :
■ identifie le au moins un premier dispositif récepteur réfèrent (7) relatif audit au moins un premier message et ;
■ identifie le au moins un deuxième dispositif récepteur réfèrent (7) relatif audit au moins un deuxième message et ;
■ récupère le message (PREMSG_VALID) et l'ensemble des messages (VALID_ROBOT) relatifs audit au moins un premier message auprès dudit au moins un premier dispositif récepteur réfèrent (7) dudit au moins un premier message et ;
■ vérifie la validité de chacun des messages (PREMSG_VALID) et (VALID_ROBOT) et la position géographique de chacun des au moins un dispositif récepteur à l'origine d'au moins un message de validation (VALID_ROBOT) du au moins un premier message et ; ■ seulement si les critères de conformité relatifs à la position géographique des au moins un dispositif récepteur ayant générés un message de validation (VALID_ROBOT) sont réunis :
- génère un message (PREMSG_VALID) contenant la liste (LIST_VALID) du au moins un dispositif récepteur à l'origine d'un message de validation relatif audit premier message et répondant aux critères de conformités relatifs à la position géographique du au moins un dispositif récepteur à l'origine d'un message de validation relatif audit premier message et ;
- génère un message de validation (VALID_ROBOT) relatif audit au moins un deuxième message et ;
- et diffuse au au moins un deuxième dispositif récepteur réfèrent (7) relatif au deuxième message :
- ledit au moins un deuxième message et ;
- le message (PREMSG_VALID) associé et ;
- et le message (VALID_ROBOT) associé.
•12) Procédé selon l'une quelconque des revendications précédentes, adapté pour valider un message dans une chaîne de messages, en prenant en compte le nombre de dispositifs récepteurs ayant
préalablement validé ledit message, le procédé étant caractérisé en ce qu'il comprend les étapes suivantes :
• au moins un dispositif récepteur réceptionne au moins un deuxième message disposant de la clé de contrôle (CCJDA2) et dont la précédente clé de contrôle indiquée (CCJDA1 ) correspond à la clé de contrôle d'au moins un premier message, et réalise les opérations suivantes :
■ identifie le au moins un premier dispositif récepteur réfèrent (7) relatif audit au moins un premier message et ;
■ identifie le au moins un deuxième dispositif récepteur réfèrent (7) relatif audit au moins un deuxième message et ;
■ récupère le message (PREMSG_VALID) et l'ensemble des messages (VALID_ROBOT) relatifs audit au moins un premier message auprès dudit au moins un premier dispositif récepteur réfèrent dudit au moins un premier message et ;
■ vérifie la validité de chacun des messages (PREMSG_VALID) et (VALID_ROBOT) et le nombre de dispositifs récepteurs à l'origine d'au moins un message de validation (VALID_ROBOT) dudit premier message et ;
■ seulement si les critères de conformité relatifs au nombre de dispositifs récepteurs ayant générés un message de validation (VALID_ROBOT) sont réunis :
- génère un message (PREMSG_VALID) contenant la liste (LIST_VALID) du au moins un dispositif récepteur à l'origine d'un message de validation relatif audit premier message et répondant aux critères de conformités relatifs au nombre de dispositifs récepteurs à l'origine d'un message de validation relatif audit premier message et ;
- génère un message de validation (VALID_ROBOT) relatif audit au moins un deuxième message et ;
- diffuse au au moins un deuxième dispositif récepteur réfèrent (7) relatif au deuxième message :
- ledit au moins un deuxième message et ;
- le message (PREMSG_VALID) associé et ;
- le message (VALID_ROBOT) associé.
PCT/FR2017/000054 2016-03-21 2017-03-21 Dispositif d'authentification biométrique adaptatif par échographie, photographies en lumière visible de contraste et infrarouge, sans divulgation, à travers un réseau informatique décentralisé WO2017162930A2 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201780018900.0A CN108780501B (zh) 2016-03-21 2017-03-21 通过分散验证网络单独管理与消息链相关的消息验证的方法
US16/133,989 US11038693B2 (en) 2016-03-21 2018-09-18 Method for managing the validation of messages relating to a message chain individually via a decentralised validation network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1600460A FR3049090B1 (fr) 2016-03-21 2016-03-21 Dispositif d'authentification biometrique adaptatif par echographie, photographies en lumiere visible de contraste et infrarouge, sans divulgation, a travers un reseau informatique decentralise
FR1600460 2016-03-21

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/133,989 Continuation US11038693B2 (en) 2016-03-21 2018-09-18 Method for managing the validation of messages relating to a message chain individually via a decentralised validation network

Publications (2)

Publication Number Publication Date
WO2017162930A2 true WO2017162930A2 (fr) 2017-09-28
WO2017162930A3 WO2017162930A3 (fr) 2017-12-07

Family

ID=56896590

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2017/000054 WO2017162930A2 (fr) 2016-03-21 2017-03-21 Dispositif d'authentification biométrique adaptatif par échographie, photographies en lumière visible de contraste et infrarouge, sans divulgation, à travers un réseau informatique décentralisé

Country Status (4)

Country Link
US (1) US10985920B2 (fr)
CN (2) CN109074478B (fr)
FR (1) FR3049090B1 (fr)
WO (1) WO2017162930A2 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3049090B1 (fr) * 2016-03-21 2021-06-25 Sebastien Jean Serge Dupont Dispositif d'authentification biometrique adaptatif par echographie, photographies en lumiere visible de contraste et infrarouge, sans divulgation, a travers un reseau informatique decentralise
US10893415B2 (en) * 2016-11-29 2021-01-12 P&P Ultra G Ltd. Preventing unauthorized use of devices
WO2020123192A1 (fr) * 2018-12-14 2020-06-18 Mastercard International Incorporated Systèmes, procédés et supports lisibles par ordinateur non transitoires pour identification individuelle sécurisée

Family Cites Families (70)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5111817A (en) * 1988-12-29 1992-05-12 Medical Physics, Inc. Noninvasive system and method for enhanced arterial oxygen saturation determination and arterial blood pressure monitoring
US6063108A (en) * 1997-01-06 2000-05-16 Salansky; Norman Method and apparatus for localized low energy photon therapy (LEPT)
US7890158B2 (en) * 2001-06-05 2011-02-15 Lumidigm, Inc. Apparatus and method of biometric determination using specialized optical spectroscopy systems
US6980670B1 (en) * 1998-02-09 2005-12-27 Indivos Corporation Biometric tokenless electronic rewards system and method
US20020030359A1 (en) * 1998-04-02 2002-03-14 Jerker Bergenek Fingerprint system
US6507662B1 (en) * 1998-09-11 2003-01-14 Quid Technologies Llc Method and system for biometric recognition based on electric and/or magnetic properties
US6676655B2 (en) * 1998-11-30 2004-01-13 Light Bioscience L.L.C. Low intensity light therapy for the manipulation of fibroblast, and fibroblast-derived mammalian cells and collagen
JP2002222424A (ja) * 2001-01-29 2002-08-09 Nec Corp 指紋照合システム
WO2003002186A2 (fr) * 2001-06-26 2003-01-09 Photomed Technologies, Inc. Methodes therapeutiques faisant appel a un rayonnement electromagnetique
US7263213B2 (en) * 2003-12-11 2007-08-28 Lumidigm, Inc. Methods and systems for estimation of personal characteristics from biometric measurements
JP2005284629A (ja) * 2004-03-29 2005-10-13 Sharp Corp 画像照合装置、画像照合方法、画像照合プログラムおよび画像照合プログラムを記録したコンピュータ読取り可能な記録媒体
CN102034095B (zh) * 2004-06-01 2014-04-16 光谱辨识公司 对个体进行生物识别测量的方法及多光谱传感器
US7363504B2 (en) * 2004-07-01 2008-04-22 American Express Travel Related Services Company, Inc. Method and system for keystroke scan recognition biometrics on a smartcard
JP4556111B2 (ja) * 2004-09-02 2010-10-06 ソニー株式会社 情報処理装置
US7711158B2 (en) * 2004-12-04 2010-05-04 Electronics And Telecommunications Research Institute Method and apparatus for classifying fingerprint image quality, and fingerprint image recognition system using the same
CN101142617B (zh) * 2005-02-23 2012-06-20 杰龙公司 数据输入方法和装置
NZ565662A (en) * 2005-08-09 2010-10-29 Univ Sunderland Fingerprint analysis using mass spectrometry
JPWO2007066589A1 (ja) * 2005-12-06 2009-05-21 株式会社疲労科学研究所 近赤外分光を用いた生活習慣病に関する検査・診断法および装置
US8762733B2 (en) * 2006-01-30 2014-06-24 Adidas Ag System and method for identity confirmation using physiologic biometrics to determine a physiologic fingerprint
US8323189B2 (en) * 2006-05-12 2012-12-04 Bao Tran Health monitoring appliance
JP2008020942A (ja) * 2006-07-10 2008-01-31 Rohm Co Ltd 個人識別装置及びこれを用いた電子機器
KR20140124868A (ko) * 2006-07-19 2014-10-27 루미다임 인크. 스펙트럼 생체인식 센서
EP2047622B1 (fr) * 2006-07-31 2019-05-22 HID Global Corporation Détection spectrale-spatiale d'usurpation d'empreinte digitale
US9152837B2 (en) * 2007-06-11 2015-10-06 Jeffrey A. Matos Apparatus and method for verifying the identity of an author and a person receiving information
US8495383B2 (en) * 2006-12-14 2013-07-23 Nokia Corporation Method for the secure storing of program state data in an electronic device
KR101484566B1 (ko) * 2007-03-21 2015-01-20 루미다임 인크. 국소적으로 일관된 피처를 기초로 하는 생체인식
JP4539683B2 (ja) * 2007-06-13 2010-09-08 日本電気株式会社 生体特徴入力システム、画像合成装置、画像合成方法および、画像合成プログラム
US20090043180A1 (en) * 2007-08-08 2009-02-12 Nonin Medical, Inc. Sensor and system providing physiologic data and biometric identification
JP5151396B2 (ja) * 2007-10-29 2013-02-27 株式会社日立製作所 指静脈認証装置
JP5292821B2 (ja) * 2008-01-16 2013-09-18 ソニー株式会社 静脈画像取得装置および静脈画像取得方法
US8335356B2 (en) * 2008-05-08 2012-12-18 Sonavation, Inc. Mechanical resonator optimization using shear wave damping
CN101567780B (zh) * 2009-03-20 2011-05-18 武汉理工大学 一种针对加密数字证书的密钥管理与恢复方法
US8331775B2 (en) * 2009-10-15 2012-12-11 Jack Harper Fingerprint scanning systems and methods
WO2011092829A1 (fr) * 2010-01-28 2011-08-04 富士通株式会社 Dispositif d'authentification d'empreintes digitales, procédé d'authentification d'empreintes digitales et programme d'authentification d'empreintes digitales
FR2956502B1 (fr) * 2010-02-17 2012-02-10 Sagem Securite Procede et dispositif de detection de l'orientation d'une zone du corps d'un individu posee sur une zone d'apposition d'un support d'un capteur biometrique
US8977013B2 (en) * 2010-07-12 2015-03-10 The Institute For Diagnostic Imaging Research, University Of Windsor Biometric sensor and method for generating a three-dimensional representation of a portion of a finger
US8799167B2 (en) * 2010-07-13 2014-08-05 Tec Solutions, Inc. Biometric authentication system and biometric sensor configured for single user authentication
KR101459982B1 (ko) * 2010-10-08 2014-11-07 애플 인크. 차동 측정 회로를 포함하는 손가락 감지 디바이스 및 관련 방법들
US9125596B2 (en) * 2011-09-29 2015-09-08 The Regents Of The University Of California Nanostructure-initiator mass spectrometry biometrics
US9092652B2 (en) * 2012-06-29 2015-07-28 Apple Inc. Zero reference based ridge flow map
US9517022B2 (en) * 2012-07-20 2016-12-13 Apple Inc. Finger biometric sensor including magnetic field finger biometric sensing pixels and related methods
FR2997528B1 (fr) * 2012-10-26 2021-10-15 Oberthur Technologies Identification biometrique
GB2507539A (en) * 2012-11-02 2014-05-07 Zwipe As Matching sets of minutiae using local neighbourhoods
US9118645B2 (en) * 2012-12-19 2015-08-25 Jive Software, Inc. Distributed authentication using persistent stateless credentials
EP2954458A4 (fr) * 2013-02-06 2016-11-09 Sonavation Inc Dispositif de détection biométrique pour l'imagerie tridimensionnelle de structures sous-cutanées intégrées dans un tissu de doigt
US9111125B2 (en) * 2013-02-08 2015-08-18 Apple Inc. Fingerprint imaging and quality characterization
US20140237256A1 (en) * 2013-02-17 2014-08-21 Mourad Ben Ayed Method for securing data using a disposable private key
US9046650B2 (en) * 2013-03-12 2015-06-02 The Massachusetts Institute Of Technology Methods and apparatus for mid-infrared sensing
US9818020B2 (en) * 2013-04-02 2017-11-14 Precise Biometrics Ab Fingerprint pore analysis for liveness detection
US9798372B2 (en) * 2013-06-03 2017-10-24 Qualcomm Incorporated Devices and methods of sensing combined ultrasonic and infrared signal
JP6556705B2 (ja) * 2013-06-10 2019-08-07 バイオナノ ジェノミクス、 インコーポレイテッド ポリヌクレオチドの分析
CN103646202A (zh) * 2013-12-09 2014-03-19 东南大学 一种指纹信息的编码加密及应用方法
US9473494B2 (en) * 2014-01-09 2016-10-18 Fujitsu Limited Access credentials using biometrically generated public/private key pairs
JP6428761B2 (ja) * 2014-03-19 2018-11-28 コニカミノルタ株式会社 生体情報測定装置、およびパルスオキシメーター
CA2980707A1 (fr) * 2014-03-25 2015-10-01 Botanic Technologies, Inc. Systemes et procedes pour executer des transactions securisees de maniere cryptographique a l'aide de la voix et d'un traitement de langage naturel
US10877041B2 (en) * 2014-05-05 2020-12-29 Nicolas H. VOELCKER Methods of detecting biological prints, fluids or analytes therein using porous semiconductor substrates
WO2015171941A1 (fr) * 2014-05-08 2015-11-12 Northrop Grumman Systems Corporation Procédés, dispositifs et supports lisibles par ordinateur pour une collecte, une vérification de qualité et une mise en correspondance d'attributs biométriques
US10599932B2 (en) 2014-06-09 2020-03-24 Lawrence Livermore National Security, Llc Personal electronic device for performing multimodal imaging for non-contact identification of multiple biometric traits
DE102014109682B4 (de) * 2014-07-10 2016-04-28 Bundesdruckerei Gmbh Mobiles Terminal zum Erfassen biometrischer Daten
US9633269B2 (en) * 2014-09-05 2017-04-25 Qualcomm Incorporated Image-based liveness detection for ultrasonic fingerprints
US20160092665A1 (en) * 2014-09-27 2016-03-31 Intel Corporation Liveness Detection for User Authentication
JP6673213B2 (ja) * 2014-10-29 2020-03-25 日本電気株式会社 生体認証装置及び生体認証方法
CN104463001A (zh) * 2014-12-19 2015-03-25 比特卡国际有限公司 一种独立生成和保存加密数字货币私钥的方法及承载加密数字货币私钥的装置
CA2968295A1 (fr) * 2015-01-30 2016-08-04 Sicpa Holding Sa Realisation simultanee de l'authentification d'un article de securite et de l'identification de l'utilisateur de cet article de securite
US9374373B1 (en) * 2015-02-03 2016-06-21 Hong Kong Applied Science And Technology Research Institute Co., Ltd. Encryption techniques for improved sharing and distribution of encrypted content
US9424458B1 (en) * 2015-02-06 2016-08-23 Hoyos Labs Ip Ltd. Systems and methods for performing fingerprint based user authentication using imagery captured using mobile devices
CN105205439B (zh) * 2015-02-13 2017-05-03 比亚迪股份有限公司 指纹重叠区域面积的计算方法及电子装置
US10542118B2 (en) * 2015-09-24 2020-01-21 Intel Corporation Facilitating dynamic filtering and local and/or remote processing of data based on privacy policies and/or user preferences
FR3049090B1 (fr) * 2016-03-21 2021-06-25 Sebastien Jean Serge Dupont Dispositif d'authentification biometrique adaptatif par echographie, photographies en lumiere visible de contraste et infrarouge, sans divulgation, a travers un reseau informatique decentralise
KR101882282B1 (ko) * 2017-09-22 2018-08-24 엘지전자 주식회사 디지털 디바이스 및 그의 생체 인증 방법

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None

Also Published As

Publication number Publication date
US10985920B2 (en) 2021-04-20
US20190089539A1 (en) 2019-03-21
CN109074478B (zh) 2021-10-15
CN108780501B (zh) 2021-12-28
WO2017162930A3 (fr) 2017-12-07
FR3049090A1 (fr) 2017-09-22
FR3049090B1 (fr) 2021-06-25
CN108780501A (zh) 2018-11-09
CN109074478A (zh) 2018-12-21

Similar Documents

Publication Publication Date Title
EP3568794B1 (fr) Procédés et systèmes pour l'exécution de contrats intelligents dans des environnements sécurisés
JP6873270B2 (ja) ブロックチェーンにおけるスマートコントラクトに基づくトランザクション活動の取扱注意データを保護するための方法及びデバイス
EP3403213A2 (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'accès à des données personnelles au moyen d'un contrat intelligent
EP3343425A1 (fr) Système et procédé pour la création et la gestion d'autorisations décentralisées pour des objets connectés
KR20200066258A (ko) 정보 보호를 위한 시스템 및 방법
FR3049089A1 (fr) Procede permettant de gerer les validations des messages relatifs a une chaine de messages de facon unitaire a travers un reseau de validation decentralise
EP1829280A2 (fr) PROCEDE D'AUTHENTIFICATION SECURISEE POUR LA MISE EN ŒUVRE DE SERVICES SUR UN RESEAU DE TRANSMISSION DE DONNEES
FR3058243A1 (fr) Procede de controle d'identite d'un utilisateur au moyen d'une base de donnees publique
WO2017162930A2 (fr) Dispositif d'authentification biométrique adaptatif par échographie, photographies en lumière visible de contraste et infrarouge, sans divulgation, à travers un réseau informatique décentralisé
FR3099017A1 (fr) Procédé de vérification d’une transaction dans une base de données de type chaîne de blocs
FR3035248A1 (fr) Systeme-sur-puce a fonctionnement securise et ses utilisations
WO2019092327A1 (fr) Procédé d'obtention d'une identité numérique de niveau de sécurité élevé
FR3062499A1 (fr) Procede de reduction de la taille d'une base de donnees repartie de type chaine de blocs, dispositif et programme correspondant
FR2877453A1 (fr) Procede de delegation securisee de calcul d'une application bilineaire
WO2019228853A1 (fr) Methode d'etablissement de cles pour le controle d'acces a un service ou une ressource
EP3803745B1 (fr) Système transactionnel sécurisé dans une architecture p2p
EP4012972A1 (fr) Méthode de divulgation sélective de données via une chaine de blocs
WO2020136126A1 (fr) Reseau de communication securisee et tracee
CH716294A2 (fr) Procédé de signature décentralisée, sous contrôle biométrique et sous conditions d'identification personnelle et de géolocalisation, d'une transaction destinée à une blockchain.
WO2023203291A1 (fr) Procedes, terminal et serveur de gestion de donnees personnelles
Abegg Security and efficiency of blockchain technologies applied to internet-of-things application
Khacef Trade-off betweew security and scalability in blockchain systems
EP3863219A1 (fr) Procédé et dispositif d'évaluation de correspondance d'ensembles de données structurées protégées par le chiffrement
FR3109234A1 (fr) Procédé de traitement d’une transaction effectuée par une entité débitrice auprès d’une entité créditrice cible

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17732492

Country of ref document: EP

Kind code of ref document: A2

122 Ep: pct application non-entry in european phase

Ref document number: 17732492

Country of ref document: EP

Kind code of ref document: A2