CH716295A2 - A method of multiple signature of a transaction intended for a blockchain, by means of cryptographic keys distributed among the nodes of a peer-to-peer network. - Google Patents

Abstract

The invention relates to a method of multiple digital signature of a transaction (TX) intended to be registered in a new block (4) of a blockchain (5), in which the transaction (TX) is initiated by an issuer and transmitted. to a cryptographic enclave (8) of a computing node; fragments (15.i) of a first private key (15) associated with the sender, as well as fragments (16.i) of a second private key (16) associated with a third-party terminal, and stored on nodes of the network, are loaded into the enclave (8), the keys (15, 16) are reconstituted from these fragments (15.i, 16.i) and applied to the transaction (TX) to form a transaction ( STX) signed, which is then registered in a new block (4) of the blockchain (5).

Description

TECHNICAL AREA

The invention relates to the field of computing, and more specifically to blockchain technology or, in Anglo-Saxon terminology, blockchain (in what follows, the Anglo-Saxon terminology is preferred, in because of its current use in most languages, including French).

PRIOR ART

[0002] Blockchain technology is organized in layers. She understands : A layer of hardware infrastructure, called a “blockchain network”; A protocol layer called the “blockchain protocol”; An information layer, called the “blockchain register”.

[0003] The blockchain network is a decentralized computer network, called a peer-to-peer network (in Peer-to-Peer or P2P terminology), consisting of a plurality of computers (in the functional sense of the term: it is a device provided with a programmable computer processing unit, which can be in the form of a smartphone, a tablet, a desktop computer, a workstation, a physical or virtual server, i.e. computing and memory space allocated within a physical server and on which an operating system or operating system emulation runs), called "nodes" with reference to the theory of graphs, capable of communicating with each other (ie exchanging computer data), two by two, by means of wired or wireless links.

A network1blockchain comprising nodes2communicating by links3 is illustrated in theFIG.1. For the sake of simplification and conformity with graph theory, on FIG.1, the nodes2 of the network1 are represented by circles; the bonds3, by edges connecting the circles. In order not to overload the drawing with lines, only certain links3 between nodes2 are shown.

[0005] Nodes2 can be scattered over large geographic regions; they can also be grouped into smaller geographic regions.

[0006] The blockchain protocol is in the form of a computer program implemented in each node2 of the network1blockchain, and which includes, in addition to dialogue functions - that is to say exchange of computer data - with the other nodes2 of the network1 , a calculation algorithm which, from input data called "transactions" (which are transcriptions of interactions between one or more transmitting computer terminals and one or more recipient computer terminals): <tb> <SEP> - Builds structured data files4 called "blocks", each block4 including a body4containing digital transaction fingerprints, and a header4Bcontaining: <tb><SEP> <SEP> o A sequence number, or row, or height (height in English), in the form of an integer which designates the position of block4 within a chain in the order growing from an initial block (Genesis block); <tb><SEP> <SEP> o A unique digital fingerprint of body4A data; <tb><SEP> <SEP> o A unique digital fingerprint, called a pointer, of the header of the previous block4, <tb><SEP> <SEP> o A timestamp data; <tb> <SEP> - Implements a mechanism for validating blocks4 by consensus between all or part of the nodes2; <tb> <SEP> - Concatenates validated blocks4 to form a register5 (the blockchain register) in the form of an aggregate in which each block4 is mathematically linked to the previous one by its pointer.

[0007] The slightest modification of the data of the corps4Aou of the header4B of a bloc4affects the value of its digital fingerprint and consequently breaks the existing link between this bloc4 thus modified and the following bloc4 whose pointer no longer corresponds.

[0008] According to a particular embodiment, the digital fingerprint of each bloc4 is a digest (or hash) of the data of bloc4, that is to say the result of a hash function applied to the data of block4 (including body4A and header4B except for the digital fingerprint itself). The hash function is typically SHA-256.

[0009] For a bloc4donné of rank N (N an integer), the pointer ensures an unalterable link with the preceding bloc4 of rank N-1. Indeed, any modification of the data of block4 of rank N-1 would lead to the modification of its fingerprint, and therefore to a lack of correspondence between this (modified) fingerprint of block4 of rank N-1 and the pointer stored among the metadata of block4 of rank NOT.

The succession of blocks4 interconnected two by two by correspondence of the pointer of a bloc4donné of rank N with the digital imprint of the previous block of rank N-1 therefore constitutes the register5blockchain in the form of an aggregate of correlated blocks4, in which the slightest modification of the data of a block4 of rank N-1 results in a breaking of the link with the following block4 of rank N - and therefore the breaking of the blockchain register.

It is this particular structure which gives the data contained in the ledger5blockchain a reputation for immutability, guaranteed by the fact that the ledger5blockchain is replicated on all the nodes2 of the network1, forcing any attacker, not only to modify all the blocks4 of rank greater than the modified block4, but to deploy these modifications (even though the register5blockchain continues to be constituted by the nodes2 applying the blockchain protocol) to all the nodes2.

[0012] Unless otherwise stated, and for the sake of simplicity, the simple expression "blockchain" or "blockchain" designates the register5blockchain itself.

Whatever the type of consensus applied by the block validation mechanism4, most blockchain technologies have the primary function of recording, in the blockchain5, transactions between one or more issuing terminals, and one or more receiving terminals, interchangeably called "users".

Each user is associated with an account, called in a simplified manner "electronic wallet" (in English digital wallet), which contains a memory area and a programmatic interface having interaction functions with the network1blockchain to submit transactions to it, and synchronization functions with the blockchain5 to enter, in the memory area, the transactions validated by registration in the blockchain5.

[0015] The wallet further comprises a set of keys, and more precisely at least one pair of matched keys, namely a public key and an associated private key. The public key is generally used (directly as such, or indirectly through a hash) as the user's identifier. As for the private key, it is generally used to sign transactions issued from the wallet.

It is therefore understood that the private key is critical data, of which it is necessary, for the user, to maintain strict confidentiality vis-à-vis third parties who, in possession of the private key, could usurp the user identity and sign transactions for them. Since these transactions are immutable in the blockchain5, it is not possible for the authentic user to cancel or reverse them.

Losing an electronic wallet amounts, for the user, to losing his ability to sign transactions. For the user to be stolen or hacked into an electronic wallet amounts to allowing a third party (usually malicious) to sign the transactions in his place.

[0018] There are different versions of electronic wallets, depending on their method of installation.

In a first purely software version, the electronic wallet is installed locally, on a communicating terminal (typically a desktop, fixed or portable computer, or even a smartphone).

This first version is not without flaw: as the terminal is networked, it requires protecting it from intrusions, by installing filters and gateways, the infallibility of which cannot however be guaranteed. Cases of loss of keys (following a hardware or software failure, or even an untimely uninstallation of the wallet) are not rare. There are also many cases of key theft.

In a second physical version, the electronic wallet is still installed locally, on a dedicated electronic device (of the USB key type).

This portfolio only becomes active when the device is plugged into a terminal providing connection to the blockchain network.

[0023] However, physical portfolios are not flawless either. They suffer from a great sensitivity to degradation (in particular due to exposure to humidity and shocks), are likely to be lost, or to be stolen (with the same consequences as the purely software version of the wallet ).

[0024] In a third version, the electronic wallet is installed on a remote server, administered by a third party (which therefore holds the cryptographic keys) and to which the user connects via a terminal.

If this version is presumed to be better secure than the first version (purely software and local) against loss and theft by third parties, it nevertheless has a major flaw: the theft of keys by the administrator himself (and in fact, cases have been identified).

In summary, the first version is practical, but unreliable.

[0027] The second version is a little more reliable than the first, but much less practical.

As for the third version, it seems more practical than the first two, while being more reliable than the first but less, however, than the second.

However, none of the versions of electronic wallets is both practical and reliable.

In all cases, to protect themselves in particular from the loss of the keys, users are encouraged to keep a printed version, which should be kept in a discreet and protected place, such as a safe. Some even recommend keeping this printed version in a bank safe. These anachronistic secrecy techniques are significantly slowing the large-scale adoption of blockchain technologies.

The invention aims to propose an alternative technique of electronic wallet dedicated to blockchain transactions, which is at the same time practical, reliable and secure, and which frees users from having to make physical backups of their keys.

SUMMARY OF THE INVENTION

There is proposed a method for digitally signing a transaction initiated by a computer processing unit, called the sender, connected to a peer-to-peer network, this digital transaction being intended to be recorded in a new block of a chain of blocks, this method comprising the following operations: <tb> <SEP> - Generate the transaction by the sender, this transaction containing an sender identifier; <tb> <SEP> - Select from the network a so-called computing node, equipped with a processing unit in which an execution environment secured by cryptography, called an enclave, is implemented; <tb> <SEP> - Instantiate the enclave; <tb> <SEP> - Load the digital transaction into the enclave, via a secure communication line; <tb> <SEP> - Identify at least one third-party terminal, separate from the sender, to whose authorization the signature of the transaction is subject; <tb> <SEP> - Submit to the third-party terminal the transaction accompanied by an authorization request and authentication data; <tb> <SEP> - Load the authorization into the enclave, from the third-party terminal, via a secure communication line, this authorization being accompanied by authentication data; <tb> <SEP> - In the enclave, check if this authentication data satisfies a predefined authentication condition; <tb> <SEP> - If the authentication data satisfies the predefined authentication condition, select from the network nodes on which are stored fragments of a first private cryptographic key associated with the issuer identifier contained in the transaction ; <tb> <SEP> - Load said fragments of the first key into the compute node enclave; <tb> <SEP> - Select from the network nodes on which are stored fragments of a second private cryptographic key associated with the authentication data content loaded from the third-party terminal; <tb> <SEP> - Load the fragments of the second key into the compute node enclave <tb> <SEP> - In the compute node enclave: <tb><SEP> <SEP> o Reconstitute the first private cryptographic key from its fragments thus loaded; <tb><SEP> <SEP> o Reconstitute the second private cryptographic key from its fragments thus loaded; <tb><SEP> <SEP> o Digitally sign the transaction by encryption of all or part of the information thereof by means of each private cryptographic key thus reconstituted, to form a signed transaction; <tb> <SEP> - Write the signed transaction in a new block intended for the chain (5) of blocks.

BRIEF DESCRIPTION OF THE FIGURES

Other objects and advantages of the invention will become apparent in the light of the description of an embodiment, given below with reference to the accompanying drawings in which: <tb> <SEP> LaFIG.1 is a simplified block diagram illustrating a peer-to-peer network on which a chain of blocks is distributed; <tb> <SEP> LaFIG.2 is a simplified functional diagram illustrating different components of a computer processing unit involved in the creation and operation of a secure execution environment called an enclave; <tb> <SEP> LaFIG.3 is a functional diagram illustrating the stages of control prior to a signature of a transaction intended for a blockchain; <tb> <SEP> TheFIG.4 is a functional diagram extending the diagram of theFIG.3 and illustrating the steps of signing and recording the transaction in the blockchain.

DETAILED DESCRIPTION OF THE INVENTION

The environment for which the proposed method is intended is a network1blockchain comprising a plurality of nodes2 interconnected by links3. On this network1 is deployed a register5containing blocks4constituted in a chain, or chain of blocks (blockchain), the characteristics of which conform to the description given above in the introduction.

On the network 1 is implemented an application layer which is in the form of a development environment for programming applications, called "smart contracts", which can be deployed on the blockchain5 from the nodes2.

[0036] A smart contract comprises two elements: An account, called a “Contract account”, in the memory area of which is written a source code containing computer instructions implementing the functions assigned to the smart contract; An executable code (in English Executable Bytecode) resulting from a compilation of the source code, this executable code being stored or deployed within the register5blockchain, that is to say inserted as a transaction in a block4 of the register5blockchain.

In the blockchain technology proposed by Ethereum, a smart contract is activated by a call (in English Call) sent by another account, said initiator account (which can be a user account or a contract account), this call is presenting in the form of a transaction containing, on the one hand, a reserve fund to be transferred (i.e. a payment) from the initiating account to the contract account and, on the other hand, initial conditions.

This call is recorded as a transaction in the register5blockchain. It triggers: The transfer of the reserve fund from the initiating account to the contract account; The designation, among the network1blockchain, of an execution node associated with a user account; The activation, in a computer processing unit of the execution node, of an execution environment or virtual machine (called Ethereum Virtual Machine or EVM in the case of Ethereum); The step-by-step execution of the steps for calculating the executable code by the virtual machine from the initial conditions, each step of calculation being accompanied by a transfer of a fraction (called gas in the case of Ethereum) of the reserve fund from the contract account to the user account of the execution node, until the calculation steps are exhausted, at the end of which a result is obtained; The entry (possibly in the form of a digital fingerprint) of this result as a transaction in the ledger5blockchain.

The initiating account retrieves (that is to say, in practice, downloads) the result when it is synchronized to the register5blockchain.

[0040] Furthermore, at least some of the nodes2 are equipped with processing units6 on which a secure execution environment is implemented or, in English terminology, trusted execution environment (TEE).

A secure execution environment (Trusted execution environment or TEE) is, within a computer processing unit provided with a processor or CPU (Central Processing Unit) 7, a temporary space for calculation and data storage. , called (by convention) an enclave, or even cryptographic enclave, which is isolated, by cryptographic means, from any unauthorized action resulting from the execution of an application outside this space, typically the operating system.

[0042] Intel®, for example, from 2013 revised the structure and interfaces of its processors to include enclave functions, under the name Software Guard Extension, better known by the acronym SGX. SGX equips most of the XX86 type processors marketed by Intel® since 2015, and more specifically from the sixth generation incorporating the so-called Skylake microarchitecture. The enclave functions offered by SGX are not automatically accessible: they must be activated via the elementary input / output system (Basic Input Output System or BIOS).

It does not come within the requirements of the present description to detail the architecture of the enclaves, insofar as: Despite its relative youth, this architecture is relatively well documented, in particular by Intel® which has filed numerous patents, cf. e.g., among the most recent, the US patent application US 2019/0058696; Processors making it possible to implement them are available on the market - in particular the aforementioned Intel® processors; Only the functionalities allowed by the enclave are of interest to us here, these functionalities being able to be implemented via specific command lines. As such, those skilled in the art may refer to the guide published in 2016 by Intel®: Software Guard Extensions, Developer Guide.

For a more accessible description of the enclaves, and more particularly of Intel® SGX, those skilled in the art can also refer to A. Adamski, Overview of Intel SGX - Part 1, SGX Internai, or to D. Boneh , Nickaming Schemes, Fast Verification, and Applications to SGX Technology, in Topics in Cryptology, CT - RSA 2017, The Cryptographers' Track at the RSA Conférence 2017, San Francisco, CA, USA, Feb. 14-17, 2017, Proceedings, pp. 149-164, or to K. Severinsen, Secure Programming with Intel SGX and Novel Applications, Thesis submitted for the Degree of Master in Programming and Networks, Dept. Of Informatics, Faculty of Mathematics and Natural Science, University of Oslo, Autumn 2017.

To summarize, with reference to theFIG.2, an enclave8includes, first of all, a secure memory zone9 (called Enclave Page Cache, in English Enclave Page Cache or EPC), which contains code and data relating to the 'enclave itself, and the content of which is encrypted and decrypted in real time by a dedicated chip called the Memory Encryption Engine (MEE). The EPC9 is implemented within a part of the dynamic random access memory (DRAM) 10 allocated to the processor7, and to which ordinary applications (in particular the operating system) do not have access.

The enclave8 includes, secondly, cryptographic keys used to encrypt or sign on the fly the data leaving the EPC9, whereby the enclave8 can be identified (in particular by other enclaves), and the The data it generates can be encrypted to be stored in unprotected memory areas (i.e. outside of the EPC9).

In order to be able to operate such an enclave8, an application11 must be segmented into, on the one hand, one or more unsecured parts12 (untrusted part (s)), and, on the other hand, one or more secure parts13 (in English trusted part (s)).

Only the processes induced by the secure part (s) 13 of the application11 can access the enclave8. The processes induced by the unsecured part (s) 12 cannot access the enclave8, i.e. they cannot dialogue with the processes induced by the part (s) (s) 13secure (s).

The creation (also called instantiation) of the enclave8 and the flow of processes within it are controlled via a set of particular instructions executable by the processor7et called by the part (s) 13secure (s) of the application11.

Among these instructions: ECREATE commands the creation of an enclave8; EINIT commands the initialization of the enclave8; EADD commands code loading into the enclave8; EENTER commands code execution in the enclave8; ERESUME commands a new execution of code in the enclave8; EEXIT controls the exit of enclave8, typically at the end of a process running in enclave8.

We have, on laFIG.2, functionally represented the enclave8 in the form of a block (in dotted lines) encompassing the secure part13 of the application11, the set14d'instructions of the processor7, and the EPC9. This representation is not realistic; it simply aims to visually group together the elements that make up or exploit the enclave8.

We will explain below how the enclaves are exploited.

The proposed method aims to allow the decentralized digital signature of a digital TX transaction intended for a blockchain5.

The signature must be performed by encryption of the TX transaction by means of several private cryptographic keys15,16 (at least two in number), stored on the network1 in application of Shamir's rules (known as Shamir's Secret Sharing, in English Shamir's Secret Sharing).

According to Shamir's rules, each private key15,16 has previously been fragmented into a set of N respective fragments15.i, 16.i (N a predetermined integer, N> 3, i an integer index, 1≤i ≤N), such that a subset of K fragments15.i, 16.i (K a predetermined integer, 1 <K <N, with 1≤i≤K) is sufficient to reconstitute the respective key15,16.

Each fragment15.i, 16is stored separately in a node2 of the network1.

The transactionTX is initiated by a computer processing unit (eg equipping a fixed or portable personal computer, a tablet or even a smartphone), connected to the network1and called the transmitter.

This method comprises several phases, namely: A loading phase; A control phase; A signing phase; A deployment phase.

The loading phase comprises a first operation 101 which consists, on the initiative of the transmitter, in establishing a connection to the network 1, via a request (REQ) addressed to the latter.

A second operation 102 consists, among the network 1, in selecting a computing node 2 Pdit, equipped with a processing unit in which an enclave 8 is implemented.

A third operation 103 consists, within the computation node2P, in instantiating the enclave8.

A fourth operation104 consists, within the issuerE, in generating the transactionTX.

This transactionTX typically contains an identifier associated with the issuer or with its user, a physical person (this identity is for example in the form of a public cryptographic key, or a derivative of this public cryptographic key, for example a condensate of this key, in particular by the SHA-256 method).

In the event that the transactionTX is sent to a recipient, it also contains an identifier associated with this recipient (eg in the form of a public key or a derivative of this public key, e.g. condensate).

It also contains an asset (which can be in the form of any data - it can be a number, corresponding for example to an amount expressed in a currency).

A fifth operation105 consists in loading the transactionTX in the enclave, via a secure communication line (eg using the Transport Layer Security or TLS protocol).

The control, signature and deployment phases are carried out within or from the enclave8.

According to a preferred embodiment, the operations relating to the control and to the signature are carried out according to the instructions of an intelligent contract SC deployed on the blockchain5.

As illustrated in laFIG.3, a sixth operation 106consists, for the enclave8, in calling (CALL) the intelligent contract SC.

A seventh operation 107 consists, in return, in loading the code of the intelligent contract SC in the enclave 8 for execution. Also loaded into the enclave8 is a virtual machine (EVM when the smart contract SC is programmed according to Ethereum's specifications) intended to allow execution of the code of the smart contract SC.

The objective of the control phase is to verify that certain conditions concerning the transaction TX are met, by subjecting the transaction TX to the authorization of at least one trusted third party, placed behind a third party terminal TT, to minimize the risks of theft. 'identity.

The control phase comprises in particular authentication operations of the trusted third party.

According to a particular embodiment, the control phase even comprises an authentication of the individual (s) physical person (s) behind the transmitter.

Authentication is performed here by comparison of biometric data.

The transmitter E is equipped with (or connected to) a biometric capture device or scanner. The scanner18 is configured to capture biometric data19 of the individual at a limb (e.g. one or more finger (s), a hand) or organ (e.g. an eye, face, body). ear, part of the venous system) of this individual.

Likewise, the third-party terminal is equipped with (or connected to) a biometric device or scanner. The scanner20 is configured to capture data21 of the individual at a limb (e.g. one or more finger (s), hand) or organ (e.g. eye, face, ear , part of the venous network) of this individual.

Thus, an eighth operation 108 consists, for the enclave8, in transmitting to the sender an authentication request.

A ninth operation109 consists, at the level of the transmitterE, in carrying out, by means of its scanner18, a capture of the biometric data19 of the individual. In the example illustrated, these biometric data come from a fingerprint.

A tenth operation 110 consists, from the transmitter E, in loading, into the computation node 2 P enclave 8 via a secure communication line (eg using the Transport Layer Security or TLS protocol), the biometric data thus captured.

At the same time, or subsequently, an eleventh operation111 consists, for the enclave8, in selecting from the network1a storage node2B on which is stored a first encrypted container 22 containing first reference biometric data23, and in transmitting to this storage node2B a request ( REQ) of communication of this container 22.

A twelfth operation112 consists, from the storage node2B, in loading into the enclave8 the first encrypted container22.

The decryption of the biometric reference data23 of the first encrypted container22 requires a first decryption cryptographic key24, stored on the network1.

According to a preferred embodiment, and as illustrated in theFIG.3, the first key 24 is distributed over the network 1 in application of Shamir's rules (known as Shamir's Secret Sharing, in English Shamir's Secret Sharing).

More specifically, according to Shamir's rules, the first key24a, previously, was fragmented into a set of N fragments24.i (N a predetermined integer, N> 3, i an integer index, 1≤i≤N) such that a subset of K fragments24.i (K a predetermined integer, 1 <K <N, with 1≤i≤K) is sufficient to reconstitute the key24, each fragment24.iet being stored separately in a storage node2C of the network1.

A thirteenth operation113 therefore consists, for the enclave8, in selecting from among the network1K storage nodes2C on which K fragments24.irespectives are stored, and in transmitting to each storage node2C a request (REQ) to communicate its fragment24.i.

As illustrated in laFIG.3, a fourteenth operation114 consists, from the storage nodes2C thus selected, to be loaded into the enclave8the K fragments24.i.

A fifteenth operation115 consists, for the enclave8, in reconstituting the first key24 from the K fragments24.iainsi loaded.

A sixteenth operation116 consists, for the enclave8, in decrypting the reference biometric data23 of the first container22 by applying the first key24 to it, thus reconstituted.

A seventeenth operation117 consists, for the enclave8, in comparing the biometric data19 resulting from the capture carried out by the scanner18 and the reference biometric data23 thus deciphered. The comparison can be carried out by a conventional technique (typically by measuring the distances between minutiae in the case of the fingerprint).

At the same time, or subsequently, an eighteenth operation118consists, for the enclave, in submitting the transactionTX to the third party terminalTT, accompanied by a request (REQ) for authorization and authentication data.

A nineteenth operation119 consists, at the level of the third TT terminal, in carrying out, by means of the scanner 20, a capture of the biometric data of the individual user of the third TT terminal. In the example illustrated, these biometric data come from a fingerprint.

A twentieth operation120 consists, from the third-party TT terminal, to be loaded into the enclave8, via a secure communication line17 '(eg using the Transport Layer Security or TLS protocol), an authorization of theTX transaction, accompanied by the data21 (biometric) authentication.

At the same time, or subsequently, a twenty-first operation121 consists, for the enclave8, in selecting from the network1a storage node2B on which is stored a second encrypted container25 containing second reference biometric data26, and in transmitting to this storage node2B a communication request (REQ) from this container 25.

A twenty-second operation122 consists, from the storage node2B, in loading into the enclave8 the second encrypted container25.

The decryption of the biometric reference data26 of the second encrypted container25 requires a second decryption cryptographic key27, stored on the network1.

According to a preferred embodiment, and as illustrated in theFIG.3, the second key 27 is distributed over the network 1 in application of Shamir's rules (called Shamir's Secret Sharing, in English Shamir's Secret Sharing).

More precisely, according to Shamir's rules, the second key27a, previously, was fragmented into a set of N fragments27.i (N a predetermined integer, N> 3, i an integer index, 1≤i≤N), such that a subset of K fragments27.i (K a predetermined integer, 1 <K <N, with 1≤i≤K) is sufficient to reconstitute the key27, each fragment27.i being stored separately in a storage node2C of the network 1.

A twenty-third operation123 therefore consists, for the enclave8, in selecting from among the network1K storage nodes2C on which K fragments27.irespectives are stored, and in transmitting to each storage node2C a request (REQ) to communicate its fragment27. i.

As illustrated in laFIG.3, a twenty-fourth operation124 consists, from the storage nodes2C thus selected, in loading into the enclave8the K fragments27.i.

[0100] A twenty-fifth operation125 consists, for the enclave8, in reconstituting the second key27 from the K fragments27.iainsi loaded.

A twenty-sixth operation 126 consists, for the enclave8, in decrypting the reference biometric data26 of the second container25 by applying the second key27 to it, thus reconstituted.

A twenty-seventh operation 127 consists, for the enclave8, in comparing the second biometric data 21 resulting from the capture carried out by the scanner 20 and the reference biometric data thus deciphered. The comparison can be carried out by a conventional technique (typically by measuring the distances between minutiae in the case of the fingerprint).

If the comparison of the biometric data from the transmitter E and / or the third-party terminal TT is a failure, the data19,23 and / or the data21,26 are declared not to correspond, and the signing process is terminated. The sender is informed. The biometric data capture and comparison operations can be repeated, to minimize the risk of false negatives.

If, on the contrary, the comparison is successful, the data 19,23 and the data 21,26 are declared to correspond, and the signing phase is initiated. To drive this, the enclave8 must have the first private key15 (corresponding to the transmitterE) and the second private key16 (corresponding to the third party TT terminal).

A twenty-eighth operation128 consists, for the enclave8, in selecting from the network1K storage nodes2A on which are stored K fragments15.ide the first key15, and in transmitting to each storage node2A a request (REQ) for communication of its fragment15 .i (FIG. 4).

As illustrated in laFIG.4, a twenty-ninth operation129 consists, from the storage nodes2A thus selected, in loading into the enclave8the K fragments15.i.

A thirtieth operation 130 consists, for the enclave8, in reconstituting the key15 from the K fragments16.iainsi loaded.

A thirty-first operation131 consists, for the enclave8, in selecting from among the network1K storage nodes2A on which are stored K fragments16.ide the second key16, and in transmitting to each storage node2A a communication request (REQ) of its fragment16.i (FIG. 4).

As illustrated in laFIG.4, a thirty-second operation132 consists, from the storage nodes2A thus selected, in loading the K fragments16.i into the enclave8.

[0110] A thirty-third operation133 consists, for the enclave8, in reconstituting the second key16 from the K fragments16.iainsi loaded.

[0111] A thirty-fourth operation134 consists in signing the transactionTX by encrypting all or part of the information of the latter by means of each private key15,16 thus reconstituted, the result being a signed transactionSTX.

The deployment phase can then be initiated: it involves submitting the signed transaction STX to the network1 for validation and registration in the blockchain5.

To this end, and according to an embodiment illustrated in theFIG.4, a thirty-fifth operation135 consists, for the enclave8, in establishing a communication session with at least one node2 of the network1, a thirty-sixth operation136 then consisting of transmit the signed STX transaction to this node2, with a view to its registration in the blockchain5. The signed STX transaction is then distributed to several validator nodes2 of the network1, for the purpose of verification prior to registration.

The verification of the transactionSTX comprises at least the verification (that is to say the recognition) of the signature; it can also include the recognition, on the blockchain5, of the identifiers of the sender and the recipient, and the observation that the sender E does indeed have a sufficient balance.

[0115] After the signed STX transaction has been verified, a thirtieth operation137 consists, for one or more validator2 nodes, in entering it in a new block4 intended for the blockchain5. A thirty-eighth operation138 consists, for one of the validator nodes2, in adding the new block4 containing the signed STX transaction to the blockchain5, after the completion of a consensus mechanism such as proof-of-work (in English proof-of-work or PoW), proof-of-authority (PoA) or proof-of-stake (PoS).

The process which has just been described has the following advantages.

First, it makes it possible to offer a new, distributed version of an electronic wallet on the blockchain5. The sender does not have the private keys15,16 used to sign the TX transactions: these keys15,16 are stored in a distributed manner on nodes2A of the network1. The electronic wallet is thus independent of the issuer, while remaining associated with its user as a natural person.

The same applies to the third-party TT terminal, which does not have private keys: the electronic wallet is therefore also independent of the latter, while being activated under its control.

[0119] This results in increased practicality, reliability and safety. The user is exempted from making backups of his private key. The fact, in particular, of subjecting the transaction TX to a double signature makes it possible to increase the security of use of the electronic wallet, typically when the amount of a transaction exceeds a predetermined threshold.

[0120] The keys15,16 being fragmented, no node2 of the network1 has them alone, and can therefore reconstitute the keys15,16 to usurp the identity of the user behind the sender or the third party terminal, and sign transactions in their place. .

[0121] Various variant embodiments can be provided.

In the example which has just been described, the signed transaction STX is recorded in a blockchain5 deployed on the network1 to which the computation node2C and the storage nodes2A of the fragments of the private keys15,16 belong. However, we can imagine that the network on which the blockchain5 is deployed, and the network to which the compute2C node and the storage2A nodes belong, are different. In this case, we understand that the computation node2C must be connected to the network on which the blockchain5 is deployed; on the other hand, the senderEand the third-party terminalTT are not necessarily: the computation node2C can then be considered as a proxy of the senderE, authorized to apply the double signature to the transactionTX, to the blockchain5 deployed on this network.

Claims (1)

1. A method of digitally signing a transaction (TX) initiated by a computer processing unit, called the transmitter (E), connected to a peer-to-peer network (1), this digital transaction (TX) being intended to be registered in a new block (4) of a chain (5) of blocks, this method comprising the following operations: - Generate the transaction by the issuer (E), this transaction containing an issuer identifier; - Select from the network (1) a node (2P) called computation, equipped with a processing unit in which is implemented an execution environment secured by cryptography, called enclave (8); - Instantiate the enclave (8); - Load the digital transaction (TX) into the enclave (8), via a secure communication line (16); - Identify at least one third-party terminal (TT), separate from the sender (E), to whose authorization the signature of the transaction (TX) is subject; - Submit to the third-party terminal (TT) the transaction (TX) accompanied by an authorization request and authentication data; - Load the authorization into the enclave (8), from the third-party terminal (TT), via a secure communication line (17), this authorization being accompanied by authentication data; - In the enclave (8), check whether these authentication data satisfy a predefined authentication condition; - If the authentication data satisfy the predefined authentication condition, select from the network (1) nodes (2A) on which are stored fragments (15.i) of a first private cryptographic key (15) associated with the sender identifier contained in the transaction (TX); - Load said fragments (15.i) of the first key (15) into the enclave (8) of the computing node (2P); - Select from the network (1) nodes (2A) on which are stored fragments (16.i) of a second private cryptographic key (16) associated with the content authentication data loaded from the third-party terminal (TT) ; - Load the fragments of the second key into the enclave (8) of the computing node (2P); - In the enclave (8) of the compute node (2P): o Reconstitute the first private cryptographic key (15) from its fragments (15.i) thus loaded; o Reconstitute the second private cryptographic key (16) from its fragments (16.i) thus loaded; o Digitally sign the transaction (TX) by encryption of all or part of the information thereof by means of each private cryptographic key (15,16) thus reconstituted, to form a signed transaction (STX); - Enter the signed transaction (STX) in a new block (4) intended for the chain (5) of blocks.