EP4396716A1 - Procede de fourniture de service mis en oeuvre par ordinateur dans une chaine de blocs, noeud d'un reseau de chaine de blocs et programme d'ordinateur correspondants - Google Patents

Procede de fourniture de service mis en oeuvre par ordinateur dans une chaine de blocs, noeud d'un reseau de chaine de blocs et programme d'ordinateur correspondants

Info

Publication number
EP4396716A1
EP4396716A1 EP22776971.8A EP22776971A EP4396716A1 EP 4396716 A1 EP4396716 A1 EP 4396716A1 EP 22776971 A EP22776971 A EP 22776971A EP 4396716 A1 EP4396716 A1 EP 4396716A1
Authority
EP
European Patent Office
Prior art keywords
service
offers
encrypted
computer
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22776971.8A
Other languages
German (de)
English (en)
Inventor
Tiphaine HENRY
Julien HATIN
Nassim Laga
Blaise CARNEVILLIER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Publication of EP4396716A1 publication Critical patent/EP4396716A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • 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/008—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping

Definitions

  • TITLE Blockchain computer-implemented service delivery method, blockchain network node and corresponding computer program.
  • the field of the invention is that of computer-implemented technologies, and more particularly, the exchange of goods or services based on a decentralized information storage technology of the blockchain type. More specifically, the invention relates to a mechanism, implemented by a computer interfacing with at least one node of a blockchain network executing a smart contract, for the selection and decentralized linking of a service provider and a customer.
  • transactions made between network users are grouped into blocks. Each block is validated by the nodes of the network, according to cryptographic techniques which depend on the type of blockchain. Once the block is validated, it is timestamped and added to the blockchain, which all users have access to. The transaction is then visible to all nodes in the network. Once added to the chain, a block can no longer be modified or deleted, which guarantees the authenticity and security of the network.
  • the invention meets this need by proposing a method for processing service offers implemented by a computer interfacing with at least one node belonging to a blockchain network configured to execute a smart contract.
  • said method comprises:
  • Such a process can, for example, help to reduce transaction costs by delegating the tasks of evaluating service offers to the oracle.
  • Such a recording medium can be any entity or device capable of storing programs.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a USB key or a hard disk.
  • the set P of objective selection criteria CSEL 23 that can be chosen by the instructing nodes 102 to formulate a service request addressed to the platform.
  • the service provider nodes 101 will have to fill in these different selection criteria when proposing a resource, or service offer, on the linking platform.
  • the platform 100 is operational to record and process the resources offered by different nodes providing goods or services 101 , as illustrated by the sequence diagram of the [Fig. 3].
  • a step G6 the oracle 1030 initializes the algorithm I .
  • the content o of the offers n 0A , n 0B is encrypted by means of the key FHE.
  • the oracle 1030 compares the different offers two by two. Thus, in a step G7, corresponding to lines 6 to 8 of algorithm 1, the oracle 1030 determines a local maximum between a first offer C[i] and a second offer C[/]. Once the value m corresponding to the local maximum has been obtained, the oracle 1030 can for example implement algorithm 2 in order to determine the value of the variable b to be applied. Such an algorithm 2 is also presented in the appendix.
  • testEquality function is based on Fermat's little theorem.
  • the oracle can apply algorithm 2 to the variables C[i] and m. If the variable C[i] is greater than the local maximum m then the variable b of algorithm 1 which corresponds to the variable t of algorithm 2 takes the value c n . If on the contrary the variable C[i] is less than the local maximum m then the variable b takes the value c 0 (the figure of 0).
  • Step G7 can be executed until all the service offers received have been compared two by two.
  • a value B[i]+b can be stored as being a coordinate of the vector argmax B.
  • Such a vector argmax B can include as many coordinates as the number of comparisons of offers to be made.
  • the coordinates of vector argmax B can only take two values: 0 or B[i]+b.
  • the smart contract SC 11 sorts the profiles of the delivery companies LA, LB and LC on the basis of registered public data such as availability and location.
  • each of the companies LA and LB asks the smart contract SC 11 for the public key RSAPub in order to encrypt its service offer. Then, each of the companies LA and LB encrypts each of the elements of its offer: the price and the capacity, by sequentially applying the homomorphic encryption using the FHE encryption key then the symmetrical encryption using the AES encryption key. Companies LA and LB then encrypt their AES symmetric encryption key using the RSAPub key. The offers thus encrypted and the encrypted AES encryption keys are transmitted to the intelligent contract SC 11 which records them in the chain of blocks.
  • the smart contract SC 11 then swaps the encrypted bids to keep the order of the bids confidential: it therefore swaps the bids OA of company LA and OB of company LB. It then transmits the permuted offers to the oracle 1030 and asks it for a comparison of the OA and OB offers.
  • the oracle 1030 uses the private key RSAPriv to decrypt each of the elements making up the offers n 0A , n 0B received.
  • the Oracle 1030 sends a request to decrypt the argmax vector B to the AutoCertif certification authority.
  • the AutoCertif certification authority then returns to the oracle 1030 a decrypted vector argmax B, i.e., [10,0].
  • the oracle 1030 returns this decrypted argmax vector to the smart contract SC 1 1.
  • the smart contract SC 1 1 applies an inverse permutation on the decrypted vector argmax B and identifies the offer of the company LB as the winning offer.
  • the smart contract SC 11 then generates a contract between the company LB and the service requester. At the same time, he sends a notification to the LA company to warn it that its offer has not been accepted. All these exchanges are recorded in the blockchain.
  • the [Fig. 5] represents a node N1 -N5 belonging to a blockchain network capable of implementing certain steps of the solution previously described.
  • Processor 501 controls the operations of node N1-N5.
  • the storage unit 502 stores at least one program for the implementation of the various methods which are objects of the invention to be executed by the processor 501, and various data, such as parameters used for calculations carried out by the processor 501, intermediate data of calculations performed by the processor 501, etc.
  • Processor 501 may be formed by any known and suitable hardware or software, or by a combination of hardware and software.
  • the processor 801 can be formed by dedicated hardware such as a processing circuit, or by a programmable processing unit such as a Central Processing Unit which executes a program stored in a memory of this one.
  • Storage unit 502 may be formed by any suitable means capable of storing the program or programs and data in a computer readable manner. Examples of storage unit 502 include non-transitory computer-readable storage media such as semiconductor memory devices, and magnetic, optical, or magneto-optical recording media loaded in a read-and-write unit. 'writing.
  • Interface 503 provides an interface between node N1-N5 and another node N1-N5 of the blockchain network.
  • the network interface 504 provides a connection between the node N1 -N5 and the oracle 1030.
  • FIG. 6 represents a computer or oracle 1030 able to implement certain steps of the solution previously described.
  • An oracle 1030 can include at least one hardware processor 601 corresponding to processor nPr in FIG. 1], a storage unit 602 corresponding to the STOR memory of FIG. 1], a first interface 603, and at least a second network interface 604 which are connected to each other through a bus 605.
  • the constituent elements of the oracle 1030 can be connected by means of a connection other than a bus.
  • the processor 601 controls the operations of the oracle 1030.
  • the storage unit 602 stores at least one program for the implementation of the various methods which are objects of the invention to be executed by the processor 601, and various data, such as parameters used for calculations performed by the processor 601, intermediate data for calculations performed by the processor 601, etc.
  • Processor 601 may be any known and suitable hardware or software, or a combination of hardware and software.
  • the processor 601 can be formed by dedicated hardware such as a processing circuit, or by a programmable processing unit such as a Central Processing Unit which executes a program stored in a memory of this one.
  • Interface 603 provides an interface between oracle 1030 and another computer also acting as an oracle.
  • the network interface 604 provides a connection between the oracle 1030 and at least one node N1 N5 of the blockchain network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Le domaine de l'invention est celui de biens ou de services reposant sur une technologie de stockage décentralisé d'informations de type blockchain. Les infrastructures blockchain se sont enrichies de contrats intelligents. L'émergence de ces contrats intelligents ouvre de nouvelles applications aux blockchain, notamment dans le domaine de l'échange de services. Cependant, le manque de confidentialité des solutions reposant sur l'utilisation des contrats intelligent constitue un frein à leur développement. Afin de résoudre ce problème, l'invention s'appuie sur l'introduction d'un oracle capable de traiter des offres chiffrées sans avoir accès au contenu déchiffré de ces offres. Un oracle est un service tiers exécuté par plusieurs nœuds, interfaçant le réseau blockchain avec le monde. Un oracle peut remonter des informations externes vers un contrat intelligent, ou encore effectuer des calculs pour le compte du contrat intelligent afin diminuer les coûts de calcul de ce dernier. Les oracles sont des entités de confiance.

Description

TITRE : Procédé de fourniture de service mis en œuvre par ordinateur dans une chaîne de blocs, nœud d’un réseau de chaîne de blocs et programme d’ordinateur correspondants.
Domaine de l'invention
Le domaine de l'invention est celui des technologies mises en œuvre par ordinateur, et plus particulièrement, de l’échange de biens ou de services reposant sur une technologie de stockage décentralisé d’informations de type chaîne de blocs. Plus précisément, l'invention concerne un mécanisme, mis en œuvre par un ordinateur s’interfaçant avec au moins un nœud d’un réseau de chaîne de blocs exécutant un contrat intelligent (en anglais « smart contract »), pour la sélection et la mise en relation décentralisée d’un fournisseur de service et d’un client.
Art antérieur et ses inconvénients
La « blockchain », ou en français chaîne de blocs, est une technologie de stockage et de transmission d’informations transparente, sécurisée, et fonctionnant sans organe central de contrôle. Plus précisément, une chaîne de blocs est une base de données distribuée, qui contient l’historique de tous les échanges effectués entre ses utilisateurs depuis sa création : les informations envoyées par les utilisateurs et les échanges internes à la base de données sont vérifiés et groupés à intervalles de temps réguliers en blocs, formant ainsi une chaîne. L’ensemble est sécurisé par cryptographie.
Plus précisément, les transactions effectuées entre les utilisateurs du réseau sont regroupées par blocs. Chaque bloc est validé par les nœuds du réseau, selon des techniques cryptographiques qui dépendent du type de blockchain. Une fois le bloc validé, il est horodaté et ajouté à la chaîne de blocs, à laquelle tous les utilisateurs ont accès. La transaction est alors visible pour l’ensemble des nœuds du réseau. Une fois ajouté à la chaîne, un bloc ne peut plus être ni modifié ni supprimé, ce qui garantit l’authenticité et la sécurité du réseau.
Il existe des chaînes de blocs publiques, ouvertes à tous, et des chaînes de blocs privées, ou de consortium, dont l’accès et l’utilisation sont limitées à un certain nombre d’acteurs définis à l’avance.
Les premières chaînes de blocs ont trouvé des applications dans le domaine de la monnaie numérique, telle que le bitcoin, qui est un exemple de monnaie programmable. Cependant, le caractère décentralisé de la chaîne de blocs, couplé avec sa sécurité et sa transparence, laisse entrevoir des applications bien plus larges que le seul domaine monétaire.
Les infrastructures de chaînes de blocs se sont ainsi récemment enrichies de contrats intelligents, ou « smart contracts », que l’on peut définir comme des programmes qui exécutent automatiquement les conditions et termes d’un contrat, sans nécessiter d’intervention humaine. En d’autres termes, un contrat intelligent est un programme informatique compilé qui porte un ensemble de caractéristiques lui permettant d’exécuter automatiquement et en autonomie au moins certaines des clauses spécifiques du contrat qu’il porte. L’émergence de ces contrats intelligents ouvre de nouvelles applications aux chaînes de blocs, notamment dans le domaine de l’échange de biens et de services.
En effet, le recours aux places de marché (i.e. aux plateformes de mise en relation entre un fournisseur de service et un demandeur de service) pour la sous-traitance de tâches rencontre à ce jour un certain nombre de problématiques techniques, auxquelles l’infrastructure de chaîne de blocs, couplée à l’utilisation de contrats intelligents, pourrait aider à apporter des solutions efficaces :
Parmi les problématiques techniques rencontrées, on peut citer par exemple : une problématique de manque de transparence dans la gestion des données et l’allocation des offres. En effet un seul acteur ne doit pas avoir le contrôle sur le protocole d’allocation des offres, et chaque fournisseur de service ayant soumis une offre doit pouvoir être considéré de la même manière lors de l’allocation des offres; un besoin de confidentialité ; dans un contexte de compétition, les différentes offres de services proposées en réponse à un appel d’offres doivent être gardées secrètes vis à vis de l’ensemble des fournisseurs de service soumettant une offre de service. Par exemple, le prix, ou la capacité d’un camion, facteurs déterminants dans le choix d’allocation, ne peuvent être fournis de manière publique à une quelconque entité.
Pour répondre à ces différentes problématiques, différentes solutions ont été envisagées. Cependant, même si ces différentes solutions de l’art antérieur sont intéressantes en ce qu’elles montrent l’intérêt de l’utilisation des chaînes de blocs et de contrats intelligents dans un contexte de mise en relation de fournisseurs de services et de clients, elles ne permettent pas de répondre à au moins certaines des problématiques mentionnées ci-avant et notamment la problématique de la confidentialité des offres.
Il existe donc un besoin d'une technique de mise en relation de fournisseurs de services et de clients, ou de tâches et de ressources, qui ne présente pas l’ensemble des différents inconvénients de l’art antérieur, et qui vise à répondre à au moins certaines de ces différentes problématiques.
Exposé de l'invention
L'invention répond à ce besoin en proposant un procédé de traitement d’offres de service mis en œuvre par un ordinateur s’interfaçant avec au moins un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent.
Selon au moins un mode de réalisation de la présente solution, ledit procédé comprend:
- une réception d’offres de service chiffrées , en association avec ledit contrat intelligent ; - un déchiffrement de premières clés de déchiffrement au moyen d’une clé de chiffrement privée dudit ordinateur,
- un déchiffrement desdites offres de service chiffrées au moyen desdites premières clés de déchiffrement,
- une transmission, à destination d’au moins un nœud dudit réseau de chaîne de blocs, d’un identifiant d’au moins une desdites offres de service déchiffrées.
Selon au moins un mode de réalisation, ladite au moins une offre de service déchiffrée dont l’identifiant est transmis est une desdites offres de service déchiffrées, satisfaisant au moins un critère de sélection de service pour ledit contrat intelligent.
Selon au moins un mode de réalisation, le contenu des offres de service est chiffré selon un chiffrement homomorphe, et le résultat binaire d’une comparaison de deux offres de service entre elles est obtenu en testant une égalité entre une offre de service testée et un extremum local déterminé en comparant l’offre de service testée et une autre offre de service.
Selon au moins un mode de réalisation, le procédé comprend en outre :
- une transmission du vecteur binaire de comparaison à destination d’un équipement en possession d’une clé de chiffrement homomorphe au moyen de laquelle le contenu des offres de service a été chiffré,
- une réception dudit vecteur binaire déchiffré,
- une étape de détermination dudit identifiant en tenant compte dudit vecteur binaire déchiffré .
Selon au moins un mode de réalisation, le procédé comprend, préalablement à la réception des offres de service chiffrées, une transmission d’une clé de chiffrement publique correspondant à ladite clé privée à destination du contrat intelligent.
Selon au moins un mode de réalisation de la présente solution, ledit procédé comprend les étapes suivantes de :
- réception d’offres de service chiffrées ;
- déchiffrement des clés de chiffrement symétrique correspondant auxdites offres de services et enregistrées dans ladite chaîne de blocs, au moyen d’une clé de chiffrement privée dudit ordinateur,
- déchiffrement desdites offres de service chiffrées au moyen desdites clés de chiffrement symétrique correspondantes,
- identification d’au moins une offre de service satisfaisant au moins un critère de sélection de service, dite offre candidate, parmi les offres de service déchiffrées,
- transmission, à destination du contrat intelligent, d’un identifiant d’au moins une offre candidate. Un tel procédé de traitement d’offres de service se caractérise par sa capacité à identifier au moins une offre de service d’un fournisseur de services répondant à un appel d’offres de manière autonome, objective, et confidentielle.
Pour ce faire, le procédé décrit ci-dessus s’appuie sur la technologie des chaînes de blocs et sur l’introduction d’un oracle. Un oracle est un service tiers exécuté par un ou plusieurs nœuds, ci-après ordinateurs, interfaçant le réseau de chaîne de blocs avec le monde extérieur comme par exemple l’Internet. Un oracle peut remonter des informations externes vers un contrat intelligent, ou encore effectuer des calculs pour le compte du contrat intelligent afin de diminuer les coûts de calcul de ce dernier. Les oracles sont, par définition, des entités de confiance.
Un tel procédé peut par exemple aider à diminuer les coûts de transaction en déléguant les tâches d’évaluation des offres de service à l’oracle.
Cette délégation de l’évaluation des offres de service couplée à un double niveau de chiffrement des offres de service peut par exemple aider à garantir l’intégrité du processus d’évaluation des offres de service ainsi que la confidentialité de ces dernières puisqu’aucune entité n’a accès au contenu des offres de service.
Ainsi, un tel procédé peut aider à offrir une solution intéressante à la problématique de manque de transparence souvent pointée du doigt dans le domaine de la gestion des données et l’allocation des offres. En effet, contrairement aux solutions de l’art antérieur dans lesquelles la mise en relation est souvent effectuée par des plateformes tierces, centralisées, souvent enclines à un manque de transparence vis à vis du stockage des informations des acteurs, la présente solution repose sur l’utilisation d’un contrat intelligent qui enregistre toutes ses actions dans la chaîne de bloc et sur l’utilisation d’un oracle qui n’accède pas au contenu sensible des offres traitées.
La présente solution répond à au moins certains des besoins de confidentialité des parties grâce au chiffrement de leurs offres tout en offrant une gouvernance plus transparente grâce à la décentralisation offerte par la chaîne de blocs.
Selon au moins un mode de réalisation, le procédé comprend une détermination d’un vecteur binaire de comparaison des offres de service, une composante binaire dudit vecteur de comparaison des offres de service représentant un résultat d’une comparaison de deux offres de services entre elles.
Dans au moins certains modes de réalisation de la présente solution, l’identification d’au moins une offre candidate comprend, en outre, une détermination d’un vecteur binaire de comparaison des offres de service, une composante binaire dudit vecteur de comparaison des offres de service représentant un résultat d’une comparaison de deux offres de services entre elles. Le résultat des différentes comparaisons étant présenté sous forme binaire, cela contribue à maintenir la confidentialité des offres et de leur contenu. En effet, la seule information disponible est une information indiquant qui a remporté la comparaison contrairement aux approches de type « zero knowledge proof, » qui bien que préservant la confidentialité des offres de service sont limitées par le fait que la valeur des offres de services étudiées devient accessible sur le réseau de chaîne de blocs une fois les enchères clôturées.
Dans certains cas de figure où le contenu des offres de service est chiffré selon un chiffrement homomorphe, le résultat binaire d’une comparaison de deux offres de service entre elles est obtenu en testant une égalité entre une offre de service testée et un extremum local déterminé en comparant l’offre de service testée et une autre offre de service.
La présente solution peut aussi bien mettre en œuvre un chiffrement homomorphe partiel, c’est-à-dire qui ne s’applique qu’à certains types d’opérations mathématiques, qu’un chiffrement homomorphe total, c’est-à-dire qui s’applique à tout type d’opération mathématiques.
Ainsi, en cryptographie, un chiffrement totalement homomorphe (Fully Homomorphic Encryption ou FHE en anglais) est un chiffrement qui possède certaines caractéristiques algébriques qui le font commuter avec toutes les opérations mathématiques, c'est-à-dire que le déchiffrement du résultat par diverses opérations mathématiques, en particulier la multiplication et l’addition pour mettre en œuvre des fonctions comme la moyenne, le maximum ou le minimum par exemple, sur des données chiffrées donne le même résultat que cette opération mathématique sur des données non chiffrées; cette propriété permet de confier des calculs à un agent externe, sans que les données ni les résultats ne soient accessibles à cet agent.
Certains modes de réalisation peuvent en particulier mettre en œuvre un chiffrement homomorphe partiel s’appliquant notamment sur la multiplication et l’addition.
Un chiffrement homomorphe peut permettre une évaluation aveugle des offres des nœuds d’un fournisseurs de services compétiteurs au sens où il n’est pas nécessaire d’avoir accès au contenu déchiffré des offres de service pour les évaluer. Cette technique peut permettre en effet d’effectuer des calculs sur des nombres chiffrés. Il devient donc possible de comparer des offres chiffrées dans un système d’allocation décentralisé géré par une chaîne de blocs.
Ainsi, la présente solution ne présente pas les inconvénients d’approches de type enclaves de confiance. En effet, de telles enclaves de confiance consistent à proposer une enclave au sein de laquelle les offres de services soumises sont déchiffrées afin d’être évaluées et comparées. Le contrat intelligent fait le pont entre les nœuds d’un fournisseur de service, les nœuds de client ayant posté l’appel d’offres et l’enclave. Une limitation majeure de cette approche réside dans le fait qu’au sein de cette enclave il est possible d’accéder au contenu des offres de services en clair.
Dans au moins certains modes de réalisation de la présente solution, une fois l’évaluation des offres de service dont le contenu est chiffré au moyen d’un chiffrement homomorphe effectuée, le procédé comprenant en outre:
- une étape de transmission du vecteur binaire de comparaison des offres de service à destination d’un équipement en possession d’une clé de chiffrement homomorphe au moyen de laquelle le contenu des offres de service a été chiffré,
- une étape de réception d’un vecteur binaire de comparaison d’offres de service déchiffré,
- une étape de détermination d’un identifiant d’au moins une offre candidate.
.Ainsi, tout en conservant la confidentialité des données, il est possible d’obtenir le résultat des différentes comparaisons effectuées. En effet, le contenu binaire du vecteur de comparaison donne des informations sur les offres maximales : la i-ème coordonnée du vecteur binaire de comparaison qui correspond à une offre maximale a une valeur non nulle.
Dans au moins certains modes de réalisation de la présente solution, le procédé peut comprendre une transmission d’une clé de chiffrement publique correspondant à ladite clé publique à destination du contrat intelligent.
L’invention concerne également un procédé de fourniture de service mis en œuvre par un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent de ladite chaîne de blocs pour la fourniture d’au moins un service.
Selon au moins un mode de réalisation, ledit procédé comprend :
- une transmission, à destination d’un ordinateur s’interfaçant avec ledit nœud, d’une liste d’offres de service associées audit contrat intelligent et chiffrées, et des premières clés de déchiffrement, enregistrées dans ladite chaîne de blocs, desdites offres de services chiffrées, lesdites premières clés de déchiffrement transmises étant elles-mêmes chiffrées au moyen d’une clé de chiffrement publique éditée par ledit ordinateur,
- une réception d’un identifiant d’au moins une desdites offres de service chiffrées transmises audit ordinateur.
Selon au moins un mode de réalisation, ledit procédé comprend une sélection d’une offre de service dont un identifiant est reçu par ledit nœud en fonction d’informations relatives à ladite offre de service dont ledit identifiant est reçu par ledit nœud enregistrées dans ladite chaîne de blocs.
Selon au moins un mode de réalisation, ladite offre de service sélectionnée est l’offre de service dont un identifiant est reçu par ledit nœud présentant l’horodatage d’enregistrement dans ladite chaîne de blocs le plus ancien. Selon au moins un mode de réalisation, le procédé comprend, préalablement à la transmission des offres de service chiffrées à destination dudit ordinateur, une permutation des offres de services et, préalablement à la sélection d’une offre de service dont un identifiant est reçu par ledit nœud, une permutation inverse des offres de services.
Selon au moins un mode de réalisation de la présente invention, ledit procédé comprend:
- transmission, à destination d’un ordinateur s’interfaçant avec ledit nœud, d’offres de service chiffrées selon des clés de chiffrement symétrique correspondantes enregistrées dans ladite chaîne de blocs, elles-mêmes chiffrées au moyen d’une clé de chiffrement publique éditée par ledit ordinateur,
- réception d’un identifiant d’au moins une offre de service candidate, parmi les offres de service chiffrées transmises audit ordinateur,
- sélection d’une offre de service parmi la dite au moins une offre candidate en fonction d’informations relatives à la dite au moins une offre candidate enregistrée dans ladite chaîne de blocs.
Dans au moins certains modes de réalisation de la présente solution, en cas de pluralité d’offres candidates, l’offre sélectionnée est l’offre candidate présentant un horodatage d’enregistrement dans ladite chaîne de blocs le plus ancien.
Ainsi, dans de tels modes de réalisation de la présente solution, lorsque plusieurs offres de services ont été identifiées comme répondant aux critères d’un appel d’offre, l’offre de service sélectionnée est celle qui a été soumise en premier.
Dans au moins certains modes de réalisation de la présente solution, afin d’améliorer l’intégrité et la confidentialité du traitement des offres de service par l’oracle, une étape de permutation des offres de services est mise en œuvre par le contrat intelligent préalablement à la transmission des offres de service chiffrées à destination de l’oracle.
Lorsque les offres de service ont été permutées en vue de leur traitement par l’oracle, le contrat intelligent met en œuvre, préalablement à l’étape de sélection d’une offre de service parmi les offres candidates, une étape de permutation inverse des offres de services afin de pouvoir identifier ces dernières.
Ainsi, la présente solution, dans au moins certains de ses modes de réalisation, ne présente pas les inconvénients de l’approche de type « multi-party computing ». Pour rappel, une telle approche propose des comparaisons pair à pair : les fournisseurs de service proposant une offre de service comparent leurs offres de services chiffrées deux à deux, via des canaux privés. Ils révèlent ensuite le résultat de chacune des comparaisons au contrat intelligent grâce à des techniques de preuve à divulgation nulle de connaissance. Une limitation bien connue de cette approche « multi-party computing », et que ne présente pas la solution proposée par les inventeurs, réside dans le fait que le contrat intelligent est capable de reconstituer l’ordre des enchères (du plus au moins cher si les enchères sont sur un prix par exemple). Ce n’est pas le cas de l’oracle qui n’a pas accès à cette information. Ainsi, l’oracle évalue les offres de manière neutre.
L’invention concerne également un ordinateur s’interfaçant avec au moins un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent.
Dans au moins certains modes de réalisation de la présente solution, ledit ordinateur comprend au moins un processeur configuré pour :
- recevoir des offres de service chiffrées en association avec ledit contrat intelligent ;
- déchiffrer de premières clés de chiffrement au moyen d’une clé de chiffrement privée dudit ordinateur,,
- déchiffrer lesdites offres de service chiffrées au moyen desdites premières clés de déchiffrement,
- transmettre, à destination d’au moins un nœud dudit réseau de chaîne de blocs,, un identifiant d’au moins une desdites offres de services déchiffrées
Dans au moins certains modes de réalisation, ladite au moins une offre de service déchiffrée dont l’identifiant est transmis est une desdites offres de service déchiffrée satisfaisant au moins un critère de sélection de service pour ledit contrat intelligent.
Dans au moins certains modes de réalisation, ledit au moins un processeur est configuré pour déterminer un vecteur binaire de comparaison des offres de service, une composante binaire dudit vecteur de comparaison des offres de service représentant un résultat d’une comparaison de deux offres de services entre elles.
Dans au moins certains modes de réalisation de la présente solution, ledit ordinateur comprend au moins un processeur configuré pour :
- recevoir des offres de service chiffrées ;
- déchiffrer des clés de chiffrement symétrique correspondant auxdites offres de services et enregistrées dans ladite chaîne de blocs, au moyen d’une clé de chiffrement privée dudit ordinateur,
- déchiffrer lesdites offres de service chiffrées au moyen desdites clés de chiffrement symétrique correspondantes,
- identifier au moins une offre de service satisfaisant au moins un critère de sélection de service, dite offre candidate, parmi les offres de service déchiffrées,
- transmettre, à destination du contrat intelligent, un identifiant d’au moins une offre candidate.
L’invention a également pour objet un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent de ladite chaîne de blocs.
Dans au moins certains modes de réalisation de la présente solution, ledit nœud comprend au moins un processeur configuré pour : - transmettre, à destination d’un ordinateur s’interfaçant avec ledit nœud, des offres de service associées audit contrat intelligent et chiffrées, et des premières clés de déchiffrement enregistrées dans ladite chaîne de blocs desdites offres de services chiffrées, lesdites premières clés de déchiffrement transmises étant elles-mêmes chiffrées au moyen d’une clé de chiffrement publique éditée par ledit ordinateur,
- recevoir un identifiant d’au moins une desdites offres de service chiffrées transmises audit ordinateur.
Dans au moins certains modes de réalisation, ledit au moins un processeur est configuré pour sélectionner une offre de service dont un identifiant est reçu par ledit nœud en fonction d’informations relatives à la dite au moins une offre de service, dont un identifiant est reçu par ledit nœud, enregistrées dans ladite chaîne de blocs.
Dans au moins certains modes de réalisation de la présente solution, ledit nœud comprend au moins un processeur configuré pour :
- transmettre, à destination d’un ordinateur s’interfaçant avec ledit nœud, des offres de service chiffrées selon des clés de chiffrement symétrique correspondantes enregistrées dans ladite chaîne de blocs, elles-mêmes chiffrées au moyen d’une clé de chiffrement publique éditée par ledit ordinateur,
- recevoir un identifiant d’au moins une offre de service candidate, parmi les offres de service chiffrées transmises audit ordinateur,
- sélectionner une offre de service parmi la dite au moins une offre candidate en fonction d’informations relatives à la dite au moins une offre candidate enregistrée dans ladite chaîne de blocs.
L’invention concerne enfin des produits programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre des procédés tels que décrits précédemment, lorsqu’ils sont exécutés par un processeur.
L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel sont enregistrés des programmes d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes des procédés selon l’invention tels que décrits ci-dessus.
Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur.
D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que les programmes d’ordinateur qu’il contient sont exécutables à distance. Le/les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau par exemple le réseau Internet.
Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel les programmes sont incorporés, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés objets de l’invention précités.
Liste des figures
D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
[fig- 1] : cette figure représente l’architecture d’un système de fourniture de service à base de chaîne de blocs selon un mode de réalisation de l’invention,
[fig- 2] : cette figure représente un temps d’instanciation de la plateforme pour l’adapter par exemple au domaine d’application souhaité par l’utilisateur,
[fig. 3] : cette figure représente un diagramme séquentiel des étapes d’enregistrement et de traitement des ressources proposées par différents fournisseurs de biens ou de services, [fig- 4] : cette figure représente un diagramme séquentiel des étapes de traitement des offres de services à transmettre cAES(cFHE(OS)) par l’oracle 1030 et le contrat intelligent SC 11 ,
[fig- 5] : cette figure représente un nœud du système de fourniture de service à base de chaîne de blocs selon un mode de réalisation de l’invention,
[fig- 6] : cette figure représente un ordinateur du système de fourniture de service à base de chaîne de blocs selon un mode de réalisation de l’invention.
Description détaillée de modes de réalisation de l'invention
Le principe général de l'invention repose sur l’utilisation d’une structure de chaînes de blocs, dans un réseau de communication, pour concevoir une plateforme de mise en relation de clients et de fournisseurs de service, aidant à une affectation décentralisée, transparente et/ou objective d’offres de service aux demandes de service formulées par les clients. Plus particulièrement, la présente solution repose sur la délégation de certaines opérations de traitement des offres de services soumises par des fournisseurs de service à un service tiers interfaçant la structure de la chaîne de blocs avec le monde extérieur comme par exemple l’Internet, afin de garantir la confidentialité et l’intégrité du processus de traitement des offres de service. Une telle plateforme correspond à un système de fourniture de service à base de chaîne de blocs décrit en référence à la figure [Fig. 1],
On présente désormais, en relation avec la [Fig. 1], l’architecture d’un système de fourniture de service à base de chaîne de blocs selon un mode de réalisation de l’invention. Un tel système peut comprendre un réseau de chaînes de blocs 100, également appelé par la suite réseau blockchain 100, comprenant une pluralité de nœuds N1 à N5 interconnectés les uns aux autres. La structure du nœud N1 est illustrée plus en détail. Chaque nœud N2 à N5 présente une architecture similaire à celle du nœud N1 , bien que cela n’ait pas été détaillé, par souci de simplification, sur la figure [Fig. 1],. Dans la présente exemple illustré, le terme nœud se réfère exclusivement aux nœuds N1 -N5 réseau de chaînes de blocs 100.
Le terme nœud peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.
Plus généralement, un nœud Ni comprend une mémoire vive (par exemple une mémoire RAM), une unité de traitement équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur, représentatif des instructions de code du contrat intelligent SC 11 , stocké dans une mémoire morte (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive avant d'être exécutées par le processeur de l'unité de traitement.
Ainsi, dans certains modes de réalisation, le nœud N1 peut comprendre en outre :
- une machine virtuelle Ethereum EVM 10, qui est l’environnement d’exécution des contrats intelligents dans Ethereum. On rappelle qu’Ethereum est un protocole d’échanges décentralisés permettant la création par les utilisateurs de contrats intelligents grâce à un langage Turing-complet ;
- une zone de stockage de données STOR 12 ;
- le code à octets (en anglais « bytecode ») du contrat intelligent SC 1 1 , i.e. le code déterministe exécutable sur le réseau blockchain 100, dont les variables peuvent être stockées sur le réseau 100, et dont les fonctions peuvent être appelées.
Le système dorsal (ou « backend ») de la plateforme de fourniture de service est ainsi décentralisé, et réside dans le contrat intelligent SC 11 implémentant un panel de fonctions nécessaires à la mise en relation de fournisseurs de service et de donneurs d’ordre. Comme on le verra plus en détail par la suite, ces fonctions qui peuvent être implémentées par le contrat intelligent SC 1 1 sont les suivantes :
- Register(), pour l’enregistrement de requêtes de services ou d’offres de service dans le réseau blockchain 100 ;
- Filter() , pour le filtrage des offres de service en fonction de critères de sélection de service listés dans une requête de service ;
- Sort(), pour le tri des offres de service répondant aux critères stipulés dans la requête de service ; - generateContract(), pour l’établissement d’un contrat entre un fournisseur de service et un donneur d’ordre ;
- updateQoS(), pour l’enregistrement dans le réseau blockchain 100 d’une qualité de service correspondant à un service fourni.
Les utilisateurs de la plateforme sont par exemple les nœuds fournisseurs de service 101 et des nœuds donneurs d’ordre, ou clients, 102. Ils peuvent interagir avec la plateforme via leur interface, ou frontend selon la terminologie anglaise. Des requêtes API (pour « Application Programming Interface », en français, interface de programmation d’application) permettent l’interaction entre les nœuds 101 , 102 d’une part, et le contrat intelligent SC 1 1 déployé sur le réseau blockchain 100 d’autre part.
Le dispositif client d’un donneur d’ordre 102 peut comprendre un module d’émission/réception RX/TX 1020, configuré pour émettre des requêtes de service à destination de la plateforme ainsi qu’une évaluation d’un service fourni, et pour recevoir des offres de service candidates, sélectionnées par la plateforme. Un tel dispositif client peut comprendre notamment un ou plusieurs processeurs, configurés pour exécuter des instructions de code de programme pour l’émission et la réception de telles données, notamment conformes aux langages de programmation HTML (pour « HyperText Markup Language »), et JS (pour Java Script).
Le nœud fournisseur de service 101 comprend un module d’émission/réception RX/TX 1010, configuré pour émettre des offres de service à destination de la plateforme, et pour recevoir des contrats, établis par la plateforme lorsqu’une offre de service a été élue pour répondre à une requête de service d’un dispositif client 102. Un tel nœud fournisseur de service comprend notamment un ou plusieurs processeurs, configurés pour exécuter des instructions de code de programme pour l’émission et la réception de telles données, notamment conformes aux langages de programmation HTML (pour « HyperText Markup Language »), et JS (pour Java Script).
Les transactions répertoriées et validées entre les nœuds fournisseurs de services 101 et les nœuds clients 102 peuvent être stockées sous forme de blocs dans les nœuds N1 à N5 de la chaîne de blocs 100. Des règles de consensus peuvent aider à limiter les nœuds malveillants, et à repérer les transactions invalidées. Des règles cryptographiques peuvent aider à assurer un pseudo-anonymat des transactions et des utilisateurs, et l’authenticité de l’historique de services des nœuds fournisseurs de services 101 .
Enfin, le système de fourniture de service à base de chaîne de blocs selon un mode de réalisation de l’invention comprend en outre un oracle 1030. Un oracle 1030 est un service tiers exécuté par un ou plusieurs modules faisant appel à des API externes, ci-après ordinateurs, interfaçant avec le réseau de chaîne de blocs avec le monde extérieur comme par exemple l’Internet. Par souci de simplification, un seul ordinateur est représenté sur la figure [Fig. 1],.
Un tel ordinateur 1030 peut comprendre :
- au moins un processeur nPr capable d’exécuter au moins un programme pour la mise en œuvre du procédé selon un mode de réalisation de la présente solution ;
- une zone de stockage de données STOR stockant ledit programme ainsi que diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur □ Pr ou encore des données intermédiaires de calculs effectués par le processeur nPr.
La figure [Fig. 1], illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser un nœud Ni et un oracle 1030, afin qu’ils effectuent les étapes du procédé détaillé ci-après, en relation avec les figures [Fig. 2] à [Fig. 6] (dans l’un quelconque des différents modes de réalisation, ou dans une combinaison de ces modes de réalisation). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le nœud Ni ou l’oracle 1030 sont réalisés avec une machine de calcul reprogrammable, les programmes correspondants (c'est-à-dire les séquences d’instructions) pourront être stockés dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Selon un mode de réalisation de l’invention, la plateforme de mise en relation se veut générique, en ce sens qu’elle ne s’inscrit pas dans un cas d’usage particulier, mais peut trouver des applications dans des domaines divers, tels que l’agriculture, la logistique maritime, la logistique de transport routier, les services à la personne, la production industrielle, l’énergie, etc.
Comme illustré par la [Fig. 2], il peut donc être nécessaire, avant que la plateforme ne devienne pleinement opérationnelle, de prévoir un temps d’instanciation de la plateforme pour l’adapter par exemple au domaine d’application souhaité. Notamment, l’ouverture du réseau de chaîne de bloc 100 peut être réglable à l’instanciation (de la chaîne de blocs publique aux chaînes de blocs permissionnées, et aux chaînes de blocs privées). Ainsi, cet utilisateur peut être un acteur privé dans le cas d’une chaîne de blocs privée, ou un consortium d’acteurs, dans le cas d’une chaîne de blocs de consortium. Par exemple, l’instanciation de la plateforme peut être réalisée par un consortium d’entreprises de transport, dans le cas d’une plateforme dédiée au transport de marchandises. La figure [Fig. 2], illustre ce temps d’instanciation par n une entité de régulation, que l’on pourrait noter en anglais « Field Authority » FA 20. Dans l’exemple donné ci-avant, cette entité de régulation FA 20 est le consortium d’entreprises de transport, qui se sont préalablement mises d’accord sur les paramètres d’instanciation de la plateforme.
Ainsi, au cours d’une phase d’initialisation INIT 21 des règles de la plateforme, l’utilisateur mère FA 20 peut par exemple spécifier :
- le corps de contrat légal attendu CONT 22, par exemple une lettre de voiture dans le cas d’un transport de marchandise. Ce corps de contrat CONT 22 est stocké dans le contrat intelligent SC 1 1 . Il s’agit d’un contrat type, correspondant au type de fourniture de service auquel la plateforme va être dédiée, que l’on pourra noter par la suite C ;
- l’ensemble P des critères de sélection objectifs CSEL 23 pouvant être choisis par les nœuds donneurs d’ordre 102 pour formuler une requête de service adressée à la plateforme. Les nœuds fournisseurs de service 101 devront renseigner ces différents critères de sélection lors de la proposition d’une ressource, ou offre de service, sur la plateforme de mise en relation.
Par exemple, dans l’exemple d’une application logistique pour des entreprises de transport, les critères de sélection P peuvent comprendre :
- le poids du colis à livrer ; le volume du colis à livrer ;
- la zone géographique de prise en charge du colis (par exemple sous forme de coordonnées GPS pour « Global Positioning System ») ;
- la zone géographique de livraison du colis (par exemple sous forme de coordonnées GPS pour « Global Positioning System ») ;
- le type d’équipement utilisé pour la livraison ;
- le prix ;
- le temps qui s’écoule entre la prise en charge et la livraison du colis ; un identifiant du livreur (par exemple son IMSI pour « International Mobile Subscriber Identity »).
Dans le mode de réalisation illustré, après finalisation de cette phase d’instanciation, la plateforme 100 est opérationnelle pour procéder à un enregistrement et un traitement des ressources proposées par différents nœuds fournisseurs de biens ou de services 101 , comme illustré par le diagramme séquentiel de la [Fig. 3].
En effet, les nœuds fournisseurs de service 101 intéressés et autorisés par l’utilisateur mère FA 20 peuvent proposer leurs services à la plateforme, pour qu’ils soient référencés dans un catalogue de services enregistré dans la chaîne de blocs. Cet enregistrement des offres de service dans la chaîne de blocs peut aider à offrir une sécurisation forte pour les clients 102 potentiels, car elle leur garantit que les nœuds fournisseurs de service 101 ne puissent pas modifier les paramètres de l’offre de service qu’ils proposent (prix, délai, quantité, type d’équipement, etc.) après contractualisation.
Ainsi, au cours d’une étape E1 , une autorité de certification AutoCertif (différente ou pas de l’entité FA, selon les modes de réalisation) génère une première clé de chiffrement FHE permettant d’appliquer un chiffrement FHE partiellement homomorphe ou totalement homomorphe. Une telle clé de chiffrement FHE est unique et commune à l’ensemble des nœuds fournisseurs de service 101 -1 , 101 -2 répondant à un appel d’offres donné.
Un chiffrement homomorphe partiel est un chiffrement homomorphe qui ne s’applique qu’à certains types d’opérations mathématiques. Un chiffrement homomorphe total, quant à lui, s’applique à tout type d’opération mathématiques.
Ainsi, un chiffrement totalement homomorphe (Fully Homomorphic Encryption ou FHE en anglais) est un chiffrement qui possède certaines caractéristiques algébriques qui le font commuter avec toutes les opérations mathématiques, c'est-à-dire que le déchiffrement du résultat par diverses opérations mathématiques, en particulier la multiplication et l’addition pour mettre en œuvre des fonctions comme la moyenne, le maximum ou le minimum par exemple, sur des données chiffrées donne le même résultat que cette opération mathématique sur des données non chiffrées ; cette propriété permet de confier des calculs à un agent externe, sans que les données ni les résultats ne soient accessibles à cet agent.
Dans la suite du document, il est fait l’hypothèse par simplification que le chiffrement appliqué est un chiffrement homomorphe. Il est clair cependant que la présente demande peut également s’appliquer avec un chiffrement homomorphe partiel s’appliquant notamment sur la multiplication et l’addition.
Une telle clé de chiffrement FHE est transmise aux différents nœuds fournisseurs de service 101 -1 , 101 -2 au cours d’une étape E2.
Parallèlement, l’oracle 1030 génère une paire de clés de chiffrement comprenant une clé de chiffrement publique RSAPub et une clé de chiffrement privée RSAPriv correspondante dans une étape E3. Ces clés de chiffrement RSAPub et RSAPub sont conforme à un chiffrement asymétrique tel qu’un chiffrement RSA pour « Rivest-Shamir- Adleman » du nom de ses créateurs.
Au cours d’une étape E4, l’oracle 1030 transmet la clé de chiffrement publique RSAPub à. destination du contrat intelligent SC 11 qui la transmet à son tour aux nœuds fournisseurs de service 101 -1 , 101 -2 dans une étape E5.
Dans une étape E6, qui peut être préalable, concomitante ou postérieure à l’étape E5, chaque nœud fournisseur de service 101 -1 , 102-2, peut chiffrer une offre de service OS selon une méthode de chiffrement totalement homomorphe au moyen de la clé de chiffrement FHE. On obtient ainsi une première version chiffrée cFHE(OS) de l’offre de service OS. Une telle étape E6 peut être facultative.
Chaque nœud fournisseurs de service 101 -1 , 101 -2 peut chiffrer ensuite, dans une étape E7, la première version chiffrée cFHE(OS) de l’offre de service OS selon une méthode de chiffrement symétrique au moyen d’une clé de chiffrement symétrique AES propre à chaque nœud fournisseurs de service 101 -1 , 101 -2. On obtient ainsi une deuxième version chiffrée cAES(cFHE(OS)) de l’offre de service OS, dite offre de service à transmettre à l’oracle cAES(cFHE(OS)). Un exemple d’un tel chiffrement symétrique est le chiffrement AES pour « Advanced Encryption Standard ».
Dans une étape E8, qui peut être préalable, concomitante ou postérieure à l’étape E6 et/ou à l’étape E7, chaque nœud fournisseur de service 101 -1 , 101 -2 chiffre sa clé de chiffrement symétrique AES selon une méthode de chiffrement asymétrique au moyen de la clé de chiffrement publique RSAPub reçue au cours de l’étape E5. On obtient ainsi une version chiffrée RSAPub(AES) de la clé de chiffrement symétrique AES.
Dans une étape E9, les nœuds fournisseurs de service 101 -1 , 101 -2 adressent à la plateforme de mise en relation leurs offres de services à transmettre cAES(cFHE(OS)) accompagnées des versions chiffrées RSAPub(AES) de leurs clés de chiffrement symétriques AES respectives. Les offres de services à transmettre cAES(cFHE(OS)) et les versions chiffrées RSAPub(AES) de leurs clés de chiffrement symétriques AES respectives peuvent faire l’objet d’une transmission conjointe ou non.
A réception, le contrat intelligent SC 11 peut enregistrer les offres reçues des nœuds fournisseurs de service 101 -1 et 102-2, et les versions chiffrées des clés associées, dans la chaîne de blocs 100, au cours d’une étape E10.
Une fois l’appel d’offres clôturé et l’ensemble des offres de services à transmettre enregistrées dans la chaîne de blocs 100, le contrat intelligent SC 1 1 délègue le traitement de ces offres de services à transmettre à l’oracle. Une telle délégation peut aider à réduire la charge de calcul dans le réseau blockchain et/ou le coût pour les nœuds fournisseurs de service 101 -1 , 101 -2.
Le traitement des offres de services à transmettre cAES(cFHE(OS)) par l’oracle 1030 et le contrat intelligent SC 11 est décrit plus en détails en référence à la [FIG. 4],
Dans une étape G1 , le contrat intelligent SC 11 peut trier les profils des nœuds fournisseurs de services souhaitant soumettre une offre de service en fonction de données publiques enregistrées dans la chaîne de blocs. Le contrat intelligent SC 11 détermine par exemple les nœuds fournisseurs de services éligibles et leur envoie alors une requête leur demandant de fournir des données à caractère privé nécessaires pour discriminer (filtrer par exemple) leurs offres de services. Dans certains modes de réalisation, afin par exemple d’éviter que l’oracle 1030 puisse se servir de l’ordre de réception des offres de service à traiter et ainsi mettre en cause l’intégrité du processus de traitement, le contrat intelligent SC 11 peut permuter, dans une étape G2, l’ordre des offres de service préalablement à leur transmission à l’oracle 1030. Une telle étape G2 est optionnelle. Dans la suite du présent document, on fait l’hypothèse que les offres à transmettre cAES(cFHE(OS)) ont été permutées, ces offres à transmettre cAES(cFHE(OS)) ainsi permutées sont notées n0A, n0B. Ainsi, l’offre OA correspond à l’offre à transmettre du nœud fournisseur de service 101 -1 et l’offre OB correspond à l’offre à transmettre du nœud fournisseur de service 101 -2. L’offre OA a par exemple été soumise en premier auprès du contrat intelligent SC 11 et est associée à au moins une donnée d’horodatage, telle qu’une date et un horaire de soumission, antérieur à la donnée d’horodatage associée à l’offre OB.
Une fois les offres à transmettre permutées, le contrat intelligent SC 11 transmet ces offres TTOA, TIOB à. destination de l’oracle 1030 dans une étape G3. Dans une première implémentation, les offres TTOA, TIOB sont transmises avec des versions chiffrées RSAPub(AES)oA, RSAPub(AES)oB, des clés de chiffrement symétriques AES correspondant respectivement à chacune des offres n0A, n0B . Dans une deuxième implémentation, les offres TTOA, TIOB et des versions chiffrées RSAPub(AES)oA, RSAPub(AES)oB, des clés de chiffrement symétriques AES correspondant respectivement à chacune des offres 0A, 0B.font l’objet de transmissions séparées. Dans cette deuxième implémentation, un premier n-upplet correspond à l’ensemble des offres et un second n- upplet correspond à l’ensemble versions chiffrées RSAPub(AES)oA, RSAPub(AES)oB, des clés de chiffrement symétriques AES correspondant respectivement à chacune des offres ^OA' ^OB- Le premier et le deuxième nu-upplet présentent par exemple tous deux le même ordonnancement afin de permettre l’association des offres et des versions chiffrées RSAPub(AES)oA, RSAPub(AES)oB, des clés de chiffrement symétriques AES correspondantes.
A l’aide de la clé de chiffrement privée RSAPriv correspondant à la clé de chiffrement publique RSAPub, l’oracle 1030 peut déchiffrer les versions chiffrées RSAPub(AES)oA, RSAPub(AES)oB, des clés de chiffrement symétriques AES correspondant respectivement à chacune des offres n0A, n0B au cours d’une étape G4. On obtient alors des clés de chiffrement symétriques AESOA et AESOB correspondant à chacune des offres n0A, n0B .
Au cours d’une étape G5, l’oracle 1030 procède alors au déchiffrement des offres 7TO^, 7TOB au moyen des clés de chiffrement symétriques AESOA et AESOB correspondantes. A l’issue de l’étape G5, on obtient les offres n0A, n0B déchiffrées.
Lorsque l’étape E6 a été mise en œuvre par les nœuds fournisseurs de service 101 - 1 , 101 -2, le contenu des offres TTOA, TIOB ainsi déchiffrées correspond au contenu des offres de services OS chiffré au moyen de la clé FHE. Dans un tel cas de figure, l’oracle 1030 n’a accès qu’au contenu chiffré au moyen du chiffrement homomorphe des offres TTOA, TIOB déchiffrées. L’oracle 1030 traite alors le contenu chiffré des offres n0A,n0B déchiffrées préservant ainsi la confidentialité des offres de services OS.
Une fois les offres TTOA, TIOB déchiffrées, l’oracle 1030 peut identifier alors la ou les offres de service TTOA, TIOB gagnante(s) parmi la liste des offres transmises par le contrat intelligent SC 1 1. Dans l’exemple qui nous concerne, la liste d’offres de service transmise est [TTOA, TIOB], bien entendu cette liste peut comprendre plus de deux offres de service. Les indices respectifs associés aux offres de ser\ ce 0A, 0B afin de les identifier sont 0 et 1 . Si l’oracle 1030 détermine que l’offre de service^ est l’offre gagnante, l’oracle 1030 renverra l’indice correspondant à cette offres, ici 0, au contrat intelligent SC 1 1. Si au contraire l’oracle 1030 détermine que l’offre de service^ est l’offre gagnante, l’oracle 1030 renverra l’indice correspondant à cette offres, ici 1 .
Pour cela, l’oracle peut par exemple mettre en œuvre deux algorithmes décrits ci- après. L’algorithme 1 peut par exemple être mis en œuvre pour générer un vecteur de comparaison des offres dit vecteur des argmax B. l’algorithme 2 peut par exemple être mis en œuvre pour déterminer la valeur d’une variable t utilisée dans l’algorithme 1 présenté en annexe.
Dans une étape G6, l’oracle 1030 initialise l’algorithme I .Dans l’exemple décrit, le contenu o des offres n0A,n0B est chiffré au moyen de la clé FHE. Pour cela, l’oracle 1030 utilise les variables suivantes : la liste C des offres, Ci représente l’élément i du vecteur d’offres C (ci= C[i]). Dans l’algorithme 1 « != » signifie « #= ».
L’oracle 1030 compare alors les différentes offres deux à deux. Ainsi, dans une étape G7, correspondant aux lignes 6 à 8 de l’algorithme 1 , l’oracle 1030 détermine un maximum local entre une première offre C[i] et une deuxième offre C[/]. Une fois obtenue la valeur m correspondant au maximum local, l’oracle 1030 peut par exemple mettre en œuvre l’algorithme 2 afin de déterminer la valeur de la variable b à appliquer. Un tel algorithme 2 est également présenté en annexe.
La fonction « testEquality » repose sur le petit théorème de Fermat.
Pour deux variables chiffrées A et B, le petit théorème de Fermat indique que lorsque A!=B (tout comme dans l’algorithme 1 , ici aussi « != » signifie « ¥= ».), alors (A-B)P' 1 est congru à 1 mod p, donc t = 1 - (A-B)P'1 vaut 0.
Selon le petit théorème de Fermat, lorsque A=B, alors (A-B) vaut 0, tse voit affecter la valeur 1. Dans notre cas d’usage, on multiplie alors f par une variable cn correspondant au chiffré d’un entier naturel n où n est supérieur à 1 afin de mieux faire la différence entre 0 et 1 . En effet, les calculs effectués sur des données chiffrées au moyen d’un chiffrement homomorphe tel qu’un chiffrement du type FHE engendrent du bruit lié aux techniques de chiffrement.
Ainsi, l’oracle peut appliquer l’algorithme 2 aux variables C[i] et m. Si la variable C[i] est supérieure au maximum local m alors la variable b de l'algorithme 1 qui correspond à la variable t de l’algorithme 2prend la valeur cn. Si au contraire la variable C[i] est inférieure au maximum local m alors la variable b prend la valeur c0 (le chiffré de 0).
Le résultat de l’opération B[i]+ b est alors mémorisé comme étant une coordonnée du vecteur argmax B.
L’étape G7 peut être exécutée jusqu’à ce que toutes les offres de services reçues aient été comparées deux à deux. A chaque occurrence, une valeur B[i]+b peut être mémorisée comme étant une coordonnée du vecteur argmax B. Un tel vecteur argmax B peut comprendre autant de coordonnées que le nombre de comparaisons d’offres à effectuer. Les coordonnées du vecteur argmax B ne peuvent prendre que deux valeurs : 0 ou B[i]+b.
Dans un cas de figure où le contenu des offres est chiffré selon un chiffrement homomorphe, l’oracle 1030 peut transmettre, dans une étape G8, le vecteur argmax B obtenu à destination de l’autorité de certification AutoCertif ayant généré la clé de chiffrement FHE afin que l’autorité de certification AutoCertif puisse procéder au déchiffrement du vecteur argmax B.
Une fois le vecteur argmax B déchiffré au moyen de la clé de chiffrement FHE, l’autorité de certification AutoCertif peut transmettre le vecteur argmax B déchiffré à l’oracle 1030 dans une étape G9.
Une fois qu’il a accès à un vecteur argmax B déchiffré, l’oracle 1030 est en capacité de fournir au contrat intelligent SC 1 1 un identifiant d’une ou plusieurs offres gagnantes. Pour cela, l’oracle transmet par exemple le vecteur argmax déchiffré à destination du contrat intelligent SC 1 1 dans une étape G10.
Si le contrat intelligent SC 11 a permuté les offres avant leur transmission à l’oracle 1030, alors il applique, dans une étape G1 1 , une permutation inverse au vecteur argmax B afin de pouvoir identifier correctement la ou les offres de service gagnantes.
Dans une étape G12, le contrat intelligent SC 1 1 peut déterminer le nombre d’offres de service gagnantes. Pour cela, le contrat intelligent SC 11 détermine par exemple si le vecteur argmax B comprend un ou plusieurs maxima globaux. Si le vecteur argmax B comprend un seul maximum global (e.g., B=[val_max, val_min, 0]), cela signifie qu’il n’y a qu’une seule offre de service gagnante. Le contrat intelligent SC 1 1 peut en informer alors le nœud fournisseur de service émetteur de l’offre de service gagnante et enregistrer le résultat dans la chaîne de blocs. Si le vecteur argmax B comprend plusieurs maxima globaux identiques (e.g., B=[val_max, 0, val_max]), cela signifie qu’il y a plusieurs offres de service gagnantes. Le contrat intelligent SC 11 , peut sélectionner alors une offre de service parmi ces offres de service candidates, par exemple l’offre de service associée à une donnée d’horodatage la plus ancienne parmi l’ensembles des données d’horodatage associées aux différentes offres de service candidates.
Le contrat intelligent SC 1 1 peut informer ensuite au moins certains des différents nœuds fournisseurs de service émetteurs des offres de service candidates de l’issue de l’appel d’offre à savoir le déclin de l’offre, ou l’acceptation de l’offre. Tous ces échanges sont enregistrés par le contrat intelligent SC 1 1 dans la chaîne de blocs.
Dans un exemple de cas d’usage de la présente solution, il est supposé que trois sociétés de livraison, LA, LB et LC souhaitent participer à un appel d’offre. Les trois sociétés LA, LB et LC s’inscrivent à l’appel d’offre en amont via le contrat intelligent SC 11 .
Dans le cadre de cet appel d’offre, l’oracle 1030 génère un couple de clé privée RSAPriv/ clé publique RSAPub et met la clé publique RSAPub à disposition du contrat intelligent SC 1 1.
Un demandeur de service demande un recrutement de livreur au contrat intelligent. Il souhaite une livraison longue distance de la ville v1 à la ville v2, avec un camion ayant une capacité minimale de 33m3. Il stipule la durée de l’appel d’offre égale à T=72h.
Durant cette période T le contrat intelligent SC 11 trie les profils des sociétés de livraison LA, LB et LC sur la base de données publiques enregistrées telles que la disponibilité et la localisation.
Le contrat intelligent SC 11 détermine que seules les sociétés LA et LB sont éligibles. Le contrat intelligent SC 1 1 envoie alors une requête aux sociétés LA et LB leur demandant de fournir des données à caractère privé nécessaires pour discriminer leurs offres telles que, par exemple, le prix, et la capacité disponible.
Le contrat intelligent SC 11 envoie en parallèle une liste des adresses dans le réseau blockchain des sociétés LA et LB à l’autorité de certification AutoCertif. En réponse à cette requête, l’autorité de certification AutoCertif transmet la clé de chiffrement FHE aux sociétés LA et LB via le réseau blockchain.
Par la suite, chacune des sociétés LA et LB demande au contrat intelligent SC 1 1 la clé publique RSAPub afin de chiffrer son offre de service. Puis, chacune des sociétés LA et LB chiffre chacun des éléments de son offre : le prix et la capacité, en appliquant séquentiellement le chiffrement homomorphe au moyen de la clé de chiffrement FHE puis le chiffrement symétrique au moyen de la clé de chiffrement AES. Les sociétés LA et LB chiffrent alors leur clé de chiffrement symétrique AES au moyen de la clé RSAPub. Les offres ainsi chiffrées et les clés de chiffrement AES chiffrée sont transmises au contrat intelligent SC 1 1 qui les enregistre dans la chaine de blocs.
Le contrat intelligent SC 11 permute alors les offres chiffrées pour conserver la confidentialité de l’ordre des soumissions: il inverse donc les offres OA de la société LA et OB de la société LB. Il transmet ensuite les offres permutées à l’oracle 1030 et lui demande une comparaison des offres OA et OB.
L’oracle 1030 utilise la clé privée RSAPriv pour déchiffrer chacun des éléments composant les offres n0A,n0B reçues. Pour l’offre n0A, on obtient [C(capacitéLA), C(prixLA)] où C=Chiffré.
L’oracle 1030 calcule la moyenne chiffrée de n0A : n0A = (C(capacitéLA) + C(prixLA))/2. Il fait de même pour n0B, puis applique l’algorithme de comparaison entrer et n0B. Supposons n0A > n0B, alors le vecteur argmax B retourné par l’oracle 1030 est [C(10),C(0)J.
L’oracle 1030 envoie une demande de déchiffrement du vecteur argmax B à l’autorité de certification AutoCertif.
L’autorité de certification AutoCertif renvoie alors à l’oracle 1030 un vecteur argmax B déchiffré, i.e., [10,0]. L’oracle 1030 retourne ce vecteur argmax déchiffré au contrat intelligent SC 1 1.
Le contrat intelligent SC 1 1 applique une permutation inverse sur le vecteur argmax B déchiffré et identifie l’offre de la société LB comme étant l’offre gagnante. Le contrat intelligent SC 1 1 génère alors un contrat entre la société LB et le demandeur de service. En parallèle, il envoie une notification à la société LA pour la prévenir que son offre n’est pas retenue. Tous ces échanges sont enregistrés dans la chaîne de blocs.
La [Fig. 5] représente un nœud N1 -N5 appartenant à un réseau de chaîne de blocs apte à mettre en œuvre certaines étapes de la solution précédemment décrite.
Un nœud N1 -N5 peut comprendre au moins un processeur matériel 501 , une unité de stockage 502 correspondant à la mémoire STOR 12 de la figure [Fig. 1],, une première interface 503, et au moins une deuxième interface de réseau 504 et une machine virtuelle Ethereum EVM 10 qui sont connectés entre eux au travers d’un bus 505. Bien entendu, les éléments constitutifs du nœud N1 -N5 peuvent être connectés au moyen d’une connexion autre qu’un bus.
Le processeur 501 commande les opérations du nœud N1 -N5. L'unité de stockage 502 stocke au moins un programme pour la mise en œuvre des différents procédés objets de l’invention à exécuter par le processeur 501 , et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 501 , des données intermédiaires de calculs effectués par le processeur 501 , etc. Le processeur 501 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 801 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement (Central Processing Unit) qui exécute un programme stocké dans une mémoire de celui-ci.
L'unité de stockage 502 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 502 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi- conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto- optiques chargés dans une unité de lecture et d'écriture.
L'interface 503 fournit une interface entre le nœud N1 -N5 et un autre nœud N1 -N5 du réseau de chaîne de blocs.
L’interface réseau 504 fournit quant à elle une connexion entre le nœud N1 -N5 et l’oracle 1030.
La [Fig. 6] représente un ordinateur ou oracle 1030 apte à mettre en œuvre certaines étapes de la solution précédemment décrite.
Un oracle 1030 peut comprendre au moins un processeur matériel 601 correspondant au processeur nPr de la figure [Fig. 1],, une unité de stockage 602 correspondant à la mémoire STOR de la figure [Fig. 1],, une première interface 603, et au moins une deuxième interface de réseau 604 qui sont connectés entre eux au travers d’un bus 605. Bien entendu, les éléments constitutifs de l’oracle 1030 peuvent être connectés au moyen d’une connexion autre qu’un bus.
Le processeur 601 commande les opérations de l’oracle 1030. L'unité de stockage 602 stocke au moins un programme pour la mise en œuvre des différents procédés objets de l’invention à exécuter par le processeur 601 , et diverses données, telles que des paramètres utilisés pour des calculs effectués par le processeur 601 , des données intermédiaires de calculs effectués par le processeur 601 , etc. Le processeur 601 peut être formé par tout matériel ou logiciel connu et approprié, ou par une combinaison de matériel et de logiciel. Par exemple, le processeur 601 peut être formé par un matériel dédié tel qu'un circuit de traitement, ou par une unité de traitement programmable telle qu'une unité centrale de traitement (Central Processing Unit) qui exécute un programme stocké dans une mémoire de celui-ci.
L'unité de stockage 602 peut être formée par n'importe quel moyen approprié capable de stocker le programme ou les programmes et des données d'une manière lisible par un ordinateur. Des exemples d'unité de stockage 602 comprennent des supports de stockage non transitoires lisibles par ordinateur tels que des dispositifs de mémoire à semi- conducteurs, et des supports d'enregistrement magnétiques, optiques ou magnéto- optiques chargés dans une unité de lecture et d'écriture.
L'interface 603 fournit une interface entre l’oracle 1030 et un autre ordinateur jouant également un rôle d’oracle. L’interface réseau 604 fournit quant à elle une connexion entre l’oracle 1030 et au moins un nœud N1 N5 du réseau de chaîne de blocs.
ANNEXE
Exemple d’algorithme 1

Claims

25 REVENDICATIONS
1. Procédé de traitement d’offres de service mis en œuvre par un ordinateur s’interfaçant avec au moins un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent, ledit procédé comprenant:
- réception d’offres de service chiffrées, en association avec ledit contrat intelligent ;
- déchiffrement de premières clés de déchiffrement au moyen d’une clé de chiffrement privée dudit ordinateur,
- déchiffrement desdites offres de service chiffrées au moyen desdites premières clés de déchiffrement,
- transmission, à destination d’au moins un nœud dudit réseau de chaîne de blocs, d’un identifiant d’au moins une desdites offres de service déchiffrées.
2. Procédé de traitement d’offres de service selon la revendication 1 dans lequel ladite au moins une offre de service déchiffrée dont l’identifiant est transmis est une desdites offres de service déchiffrées, satisfaisant au moins un critère de sélection de service pour ledit contrat intelligent.
3. Procédé de traitement d’offres de service selon la revendication 1 ou 2 dans lequel le procédé comprend une détermination d’un vecteur binaire de comparaison des offres de service, une composante binaire dudit vecteur de comparaison des offres de service représentant un résultat d’une comparaison de deux offres de services entre elles.
4. Procédé de traitement d’offres de service selon la revendication 3, dans lequel le contenu des offres de service est chiffré selon un chiffrement homomorphe, et le résultat binaire d’une comparaison de deux offres de service entre elles est obtenu en testant une égalité entre une offre de service testée et un extremum local déterminé en comparant l’offre de service testée et une autre offre de service.
5. Procédé de traitement d’offres de service selon la revendication 3 ou 4 comprenant en outre :
- une transmission du vecteur binaire de comparaison à destination d’un équipement en possession d’une clé de chiffrement homomorphe au moyen de laquelle le contenu des offres de service a été chiffré,
- une réception dudit vecteur binaire déchiffré,
- une étape de détermination dudit identifiant en tenant compte dudit vecteur binaire déchiffré .
6. Procédé de traitement d’offres de service selon l’une des revendications 1 à 5 comprenant, préalablement à la réception des offres de service chiffrées, une transmission d’une clé de chiffrement publique correspondant à ladite clé privée à destination du contrat intelligent.
7. Procédé de fourniture de service mis en œuvre par un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent de ladite chaîne de blocs, ledit procédé comprenant :
- transmission, à destination d’un ordinateur s’interfaçant avec ledit nœud, d’une liste d’offres de service associées audit contrat intelligent et chiffrées, et des premières clés de déchiffrement, enregistrées dans ladite chaîne de blocs, desdites offres de services chiffrées, lesdites premières clés de déchiffrement transmises étant elles-mêmes chiffrées au moyen d’une clé de chiffrement publique éditée par ledit ordinateur,
- réception d’un identifiant d’au moins une desdites offres de service chiffrées transmises audit ordinateur.
8. Procédé de fourniture de service selon la revendication 7 comprenant une sélection d’une offre de service dont un identifiant est reçu par ledit nœud en fonction d’informations relatives à ladite offre de service, dont ledit identifiant est reçu par ledit nœud, enregistrées dans ladite chaîne de blocs.
9. Procédé de fourniture de service selon la revendication 7 ou 8 dans lequel ladite offre de service sélectionnée est l’offre de service, dont un identifiant est reçu par ledit nœud, présentant l’horodatage d’enregistrement dans ladite chaîne de blocs le plus ancien.
10. Procédé de fourniture de service selon l’une des revendications 7 à 9 comprenant préalablement à la transmission des offres de service chiffrées à destination dudit ordinateur, une permutation des offres de services, et préalablement à la sélection d’une offre de service dont un identifiant est reçu par ledit nœud, une permutation inverse des offres de services.
11. Ordinateur s’interfaçant avec au moins un nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent, ledit ordinateur comprenant au moins un processeur configuré pour :
- recevoir des offres de service chiffrées en association avec ledit contrat intelligent ;
- déchiffrer de premières clés de chiffrement au moyen d’une clé de chiffrement privée dudit ordinateur,
- déchiffrer lesdites offres de service chiffrées au moyen desdites premières clés de déchiffrement,
- transmettre, à destination d’au moins un nœud dudit réseau de chaîne de blocs,, un identifiant d’au moins une desdites offres de services déchiffrées
12. - Ordinateur selon la revendication 11 dans lequel ladite au moins une offre de service déchiffrée dont l’identifiant est transmis est une desdites offres de service déchiffrée, satisfaisant au moins un critère de sélection de service pour ledit contrat intelligent.
13. Ordinateur selon la revendication 1 1 ou 12 dans lequel ledit au moins un processeur configuré pour : déterminer un vecteur binaire de comparaison des offres de service, une composante binaire dudit vecteur de comparaison des offres de service représentant un résultat d’une comparaison de deux offres de services entre elles.
14. Nœud appartenant à un réseau de chaîne de blocs configuré pour exécuter un contrat intelligent de ladite chaîne de blocs, ledit nœud comprenant au moins un processeur configuré pour :
- transmettre, à destination d’un ordinateur s’interfaçant avec ledit nœud, des offres de service associées audit contrat intelligent et chiffrées, et des premières clés de déchiffrement enregistrées dans ladite chaîne de blocs desdites offres de services chiffrées, lesdites premières clés de déchiffrement transmises étant elles-mêmes chiffrées au moyen d’une clé de chiffrement publique éditée par ledit ordinateur,
- recevoir un identifiant d’au moins une desdites offres de service chiffrées transmises audit ordinateur.
15. Noeud selon la revendication 14 dans lequel ledit au moins un processeur est configuré pour sélectionner une offre de service dont un identifiant est reçu par ledit nœud en fonction d’informations relatives à ladite offre de service, dont ledit identifiant est reçu par ledit nœud, enregistrées dans ladite chaîne de blocs
16. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre du procédé selon l’une quelconque des revendications 1 à 6 et/ou du procédé selon l’une quelconque des revendications 7 à 10, lorsqu’il est exécuté par un processeur.
17. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré au moins un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution du procédé selon l’une quelconque des revendications 1 à 6 et/ou du procédé selon l’une quelconque des revendications 7 à 10, lorsqu’il est exécuté par un processeur.
EP22776971.8A 2021-09-03 2022-09-01 Procede de fourniture de service mis en oeuvre par ordinateur dans une chaine de blocs, noeud d'un reseau de chaine de blocs et programme d'ordinateur correspondants Pending EP4396716A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2109204A FR3126831A1 (fr) 2021-09-03 2021-09-03 Procédé de fourniture de service mis en œuvre par ordinateur dans une chaîne de blocs, nœud d’un réseau de chaîne de blocs et programme d’ordinateur correspondants.
PCT/FR2022/051648 WO2023031561A1 (fr) 2021-09-03 2022-09-01 Procede de fourniture de service mis en œuvre par ordinateur dans une chaine de blocs, nœud d'un reseau de chaine de blocs et programme d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP4396716A1 true EP4396716A1 (fr) 2024-07-10

Family

ID=79601900

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22776971.8A Pending EP4396716A1 (fr) 2021-09-03 2022-09-01 Procede de fourniture de service mis en oeuvre par ordinateur dans une chaine de blocs, noeud d'un reseau de chaine de blocs et programme d'ordinateur correspondants

Country Status (4)

Country Link
US (1) US20240380622A1 (fr)
EP (1) EP4396716A1 (fr)
FR (1) FR3126831A1 (fr)
WO (1) WO2023031561A1 (fr)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11133926B2 (en) * 2018-11-05 2021-09-28 Paypal, Inc. Attribute-based key management system
CN110033258B (zh) * 2018-11-12 2021-03-23 创新先进技术有限公司 基于区块链的业务数据加密方法及装置
FR3095733B1 (fr) * 2019-04-30 2021-10-22 Renault Sas Systeme et procede de gestion de communication v2x entre un vehicule et un dispositif recepteur
US11138621B2 (en) * 2019-05-23 2021-10-05 Capital One Services, Llc Normalization grid

Also Published As

Publication number Publication date
FR3126831A1 (fr) 2023-03-10
WO2023031561A1 (fr) 2023-03-09
US20240380622A1 (en) 2024-11-14

Similar Documents

Publication Publication Date Title
EP0456553B1 (fr) Procédé d'obtention d'une attestation en clair sécurisée dans un environnement de système informatique distribué
EP3840286B1 (fr) Plateforme securisee, decentralisee, automatisee et multi-acteurs de gestion d'identites d'objets au travers de l'utilisation d'une technologie de chaine de blocs
WO2003056750A2 (fr) Systeme cryptographique de signature de groupe
EP2279581A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise
WO2018131004A9 (fr) Procedes et systemes pour l'execution de contrats intelligents dans des environnements securises
FR3162088A1 (fr) Partage sécurisé d'informations de justificatif d'identité
EP3840287B1 (fr) Plateforme securisee, decentralisee, automatisee et multi-acteurs de gestion d'identites d'objets au travers de l'utilisation d'une technologie de chaine de blocs
EP2301187A1 (fr) Terminal d'authentification forte d'un utilisateur
US12470383B2 (en) Collaborative computation across blockchain networks
CA2895189C (fr) Signature de groupe utilisant un pseudonyme
WO2003060841A1 (fr) Procede cryptographique de revocation a l'aide d'une carte a puce
EP4396716A1 (fr) Procede de fourniture de service mis en oeuvre par ordinateur dans une chaine de blocs, noeud d'un reseau de chaine de blocs et programme d'ordinateur correspondants
Kumar et al. Comprehensive three-layer trust management model for public cloud environment
FR3054055A1 (fr) Procede de traitement d'au moins une donnee de moyen de paiement, terminal de paiement et programme d'ordinateur correspondant
EP4315741A1 (fr) Gestion de droits d'accès à des fichiers numériques avec possible délégation des droits
FR3104867A1 (fr) Procédé et dispositif de contrôle d’accès anonyme à une plateforme collaborative d’anonymisation
FR3086417A1 (fr) Procede cryptographique de comparaison securisee de deux donnees secretes x et y
FR3134908A1 (fr) Procédé et système de gestion des droits d’accès dans une transaction équitable de données numériques
WO2024261249A1 (fr) Procédé pour détecter la présence d'un élément chiffré homomorphe dans un ensemble chiffré homomorphe
WO2024188822A1 (fr) Procédé et dispositif de paiement confidentiel sur chaîne de blocs
EP3063898B1 (fr) Signature à pseudonyme pour carte à puce
FR3101991A1 (fr) Système et méthode d'authentification et d'assurance d’objets
Bhargav et al. Homomorphic Recommendations for Data Packing-A Survey
WO2008001009A1 (fr) Systeme et procede cryptographique a cle publique pour l'authentification d'une premiere entite par une seconde entite
WO2008017765A1 (fr) Systeme et procede cryptographique a cle publique

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240319

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20250919