CH716301A2 - Method of signing a transaction intended for a blockchain deployed on a peer-to-peer network, by means of a cryptographic key distributed among the nodes of another peer-to-peer network. - Google Patents

Abstract

The invention relates to a method of digitally signing a transaction (TX) intended to be registered in a new block (4 ') of a blockchain (5') deployed on a peer-to-peer network (1 '), wherein the transaction (TX) is initiated by a transmitter and transmitted to a cryptographic enclave (8) of a computing node of another peer-to-peer network (1); fragments (15.i) of the private key (15) associated with the sender, and stored on nodes of this other network (1), are loaded into the enclave (8), the key (15) is reconstituted from these fragments (15.i) and applied to the transaction (TX) to form a signed transaction (STX), which is then written into 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 block 4 of rank N-1 results in a breaking of the link with the next block 4 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.

It also aims to provide an electronic wallet technique which makes it possible to register transactions in separate blockchains.

SUMMARY OF THE INVENTION

There is proposed a method of digitally signing a transaction initiated by a computer processing unit, called the sender, connected to a primary peer-to-peer network composed of a plurality of nodes forming a database distributed over which is stored by replication on each node a primary blockchain, this digital transaction being intended to be recorded in a new block of a secondary blockchain stored by replication on each node of a secondary peer-to-peer network, this process comprising the following operations: <tb> <SEP> - Generate the transaction by the sender, this transaction containing an sender identifier; <tb> <SEP> - Select from the primary 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> - Select from among the primary network nodes on which are stored fragments of a private cryptographic key associated with the sender identifier contained in the transaction; <tb> <SEP> - Load said fragments into the compute node enclave; <tb> <SEP> - In the compute node enclave: <tb><SEP> <SEP> o Reconstitute the private cryptographic key from the fragments thus loaded; <tb><SEP> <SEP> o Digitally sign the transaction by encryption of all or part of the information thereof by means of the private cryptographic key thus reconstituted, to form a signed transaction; <tb><SEP> <SEP> o Transmit the signed transaction to the secondary network; <tb> <SEP> - Within at least one node of the secondary network: <tb><SEP> <SEP> o Check the signed transaction; <tb><SEP> <SEP> o The signed transaction verified, write it in a new block intended for the secondary blockchain; <tb> <SEP> - Write a trace of the signed transaction in a new block intended for the primary blockchain.

BRIEF DESCRIPTION OF THE FIGURES

Other objects and advantages of the invention will appear 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 in which the proposed method is executed 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 network1 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 nodes2.

[0037] 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 with the register5blockchain.

Moreover, 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 computing and storing data. , 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.

[0043] 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 Internal, 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.

[0047] The enclave8 comprises, 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 set14d'instructions particular 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 enclave8s in the form of a block (in dotted lines) including 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, within the network1, said primary network, on which is deployed a primary blockchain, the decentralized digital signature of a digital TX transaction intended for a secondary so-called blockchain, distinct from the primary blockchain, this secondary blockchain being deployed on a secondary peer-to-peer network distinct from the primary network.

Note 2 'the nodes of the secondary network. Some nodes2,2 'can be common to the two networks1,1'.

This signature must be performed by encryption of the transaction TX by means of a private cryptographic key, stored on the primary network in application of Shamir's rules (known as Shamir's Secret Sharing, in English Shamir's Secret Sharing).

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

Each fragment15.iest stored separately in a storage node2A of the primary network.

The transaction TX is initiated by a computer processing unit (eg equipping a fixed or portable personal computer, a tablet or even a smartphone), connected to the primary network and 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 E, in establishing a connection to the network 1, via a request (REQ) addressed to the latter.

A second operation 102 consists, among the primary network, 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 transmitter, in generating the transactionTX.

This transactionTX typically contains an identifier associated with the issuerEor its user who is a natural person (this identity is for example in the form of a public cryptographic key, or of 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 transaction TX 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).

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

A fifth operation consists in loading the transaction TX into 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 primary blockchain.

As illustrated in laFIG.3, a sixth operation 106 consists, 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 authenticate the individual (or individuals) physical person (s) behind the transmitter E, to minimize the risks of identity theft.

This authentication is performed here by comparison of biometric data.

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

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

A ninth operation109 consists, at the level of the transmitterE, in carrying out, by means of its scanner17, a capture of the biometric data 18 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, in 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 primary network1 a storage node2B on which is stored an encrypted container19 containing reference biometric data20, and in transmitting to this storage node2B a request (REQ) of communication of this container 19.

A twelfth operation112consist, from the storage node2B, to be loaded into the encrypted enclave8le container19.

The decryption of the reference biometric data20 of the first encrypted container19 requires a decryption cryptographic key21, stored on the network1.

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

More precisely, according to Shamir's rules, the key21a, previously, was fragmented into a set of N fragments21.i (N a predetermined integer, N> 3, i an integer index, 1≤i≤N), such as that a subset of K fragments21.i (K a predetermined integer, 1 <K <N, with 1≤i≤K) is sufficient to reconstitute the key21, each fragment21.ietant stored separately in a storage node2C of the primary1 network.

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

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

A fifteenth operation115 consists, for the enclave8, in reconstituting the key21 from the K fragments21.iainsi loaded.

A sixteenth operation116 consists, for the enclave8, in decrypting the reference biometric data of the container19 by applying the key21 to it, thus reconstituted.

A seventeenth operation117 consists, for the enclave8, in comparing the biometric data18 resulting from the capture carried out by the scanner17 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 this comparison is unsuccessful, the data18,20 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 18,20 are declared to correspond, and the signing phase is initiated. To run this, the enclave8 must have the private key15.

An eighteenth operation118 consists, for the enclave8, in selecting from the primary network K storage nodes2A on which K fragments15.irespectives are stored, and in transmitting to each storage node2A a request (REQ) for communication of its fragment15.i (FIG. 4).

As illustrated in laFIG.4, a nineteenth operation119 consists, from the storage nodes2Ade thus selected, in loading into the enclave8the K fragments15.i.

A twentieth operation120 consists, for the enclave8, in reconstituting the key15 from the K fragments21.iainsi loaded.

A twenty-first operation121 consists in signing the transactionTX by encrypting all or part of the information thereof by means of the private key15 thus reconstituted, the result being a signed transactionSTX.

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

To this end, and according to an embodiment illustrated in theFIG.4, a twenty-second operation122 consists, for the enclave8, in establishing a communication session (SESS) with at least one node2 'of the secondary network1, a twenty-third operation 123 then consisting in transmitting the signed STX transaction to this node2 ', with a view to its registration in the secondary blockchain5'. The signed STX transaction is then distributed to several validator nodes of the secondary network, for verification purposes 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 secondary blockchain5, of the identifiers of the sender and recipient, and the observation that the sender does indeed have a sufficient balance.

After the signed STX transaction has been verified, a twenty-fourth operation124 consists, for one or more validator nodes 2 of the secondary 1's network, in registering it in a new block 4 intended for the secondary blockchain 5. A twenty-fifth operation125 consists, for one of the validator nodes of the secondary network, adding the new block4 'containing the signed transaction STX to the secondary blockchain5, after the completion of a consensus mechanism such as proof of work ( in English proof-of-work or PoW), proof of authority (in English proof-of-authority or PoA) or proof of stake (in English proof-of-stake or PoS).

A twenty-sixth operation126 consists in entering a TRC trace (in practice, it is a condensate) of the transactionSTX in the primary blockchain - and more exactly in a new block4 intended for the primary blockchain.

[0100] 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. The sender does not have the private15 key used to sign the TX transactions: this key15 is stored in a distributed manner on nodes2A of the primary1 network. The electronic wallet is thus independent of the issuer, while remaining associated with its user as a natural person.

[0102] This results in increased convenience, reliability and safety. The user is exempted from making backups of his private key.

[0103] The key15 being fragmented, no node2 of the primary network alone has it, and can therefore reconstitute the key15 to usurp the identity of the user and validate transactions in his place, for the benefit of confidentiality.

[0104] In addition, the proposed method makes it possible, from a primary network on which a primary blockchain 5 is deployed, to perform the decentralized signature of a TX transaction intended for a secondary blockchain 5 separate from the primary blockchain, and deployed on a secondary1 network distinct from primary1 network.

[0105] The primary blockchain5 serves in particular as a support for the intelligent contract SC, the instructions of which, loaded in the enclave8 of the computing node2P, make it possible to perform the operations necessary for the signing of the transactionTX. As mentioned, the primary5 blockchain is also used to record a TRC trace of this transaction (once signed), although it is intended for the secondary5 blockchain.

In other words, the proposed method makes it possible to offer a decentralized electronic wallet service that can be used on a blockchain5 'deployed on a network 1' to which the sender is not necessarily connected.

Claims (1)

1. Method of digitally signing a transaction (TX) initiated by a computer processing unit, called the sender (E), connected to a primary peer-to-peer network (1) composed of a plurality of nodes (2) forming a distributed database on which is stored by replication on each node (2) a chain (5) of primary blocks (4), this digital transaction (TX) being intended to be recorded in a new block (4 ') d 'a chain (5') of secondary blocks stored by replication on each node (2 ') of a secondary peer-to-peer network (1'), this method comprising the following operations: - Generate the transaction (TX) by the sender (E), this transaction (TX) containing an sender identifier; - Selecting from the primary network (1) a so-called computing node (2P), equipped with a processing unit in which an execution environment secured by cryptography, called an enclave (8) is implemented; - Instantiate the enclave (8); - Load the digital transaction (TX) into the enclave (8), via a secure communication line (16); - Select from among the primary network (1) nodes (2A) on which are stored fragments (15.i) of a private cryptographic key (15) associated with the sender identifier contained in the transaction (TX); - Load the said fragments (15.i) into the enclave (8) of the computing node (2P): - In the enclave (8) of the compute node (2P): o Reconstitute the private cryptographic key (15) from the fragments (15.i) thus loaded; o Digitally sign the transaction (TX) by encryption of all or part of the information thereof by means of the private cryptographic key (15) thus reconstituted, to form a signed transaction (STX); o Transmit the signed transaction (STX) to the secondary network (1 '); - Within at least one node (2 ') of the secondary network (1'): o Check the signed transaction (STX); o The signed transaction (STX) verified, write it in a new block (4 ') intended for the chain (5') of secondary blocks; - Write a trace of the signed transaction (STX) in a new block (4) intended for the primary block chain (5).