CH716298A2 - A method of storing, in encrypted form, an application on a blockchain network, with prior audit of the source code of this application. - Google Patents

Abstract

The invention relates to a method for storing, on a blockchain network (1), an encrypted container (23) containing an executable (21) derived from a source code (15) of an application; the source code (15) is previously audited, in a cryptographic enclave (8), by means of an audit program (16) to verify that it does not contain any order declared prohibited.

Description

TECHNICAL AREA

The invention relates to the field of computing. It concerns, more precisely, the storage of an application, in encrypted form, on a blockchain network.

PRIOR ART

An application is a computer program comprising instructions for processing input data (in English, input) in order to produce a result (in English, output).

[0003] The instructions are usually written in the form of source code written in a high-level computer language, understandable by a human being but unusable by a processor. The source code therefore undergoes a compilation, which produces a file in machine language, executable by a processor. By convention, such a file is generally called an "executable".

[0004] While many applications are executed locally to process local data, the proportion of applications executed remotely to process data online is increasing.

Now that the processing of mass data (in English big data) tends to industrialize, specialized applications scrutinize the data flows (especially the personal data of users) circulating on the Web, carry out analyzes of these data, perform calculations (in particular statistics) then store their results in databases for the purposes of subsequent exploitation (in particular commercial).

[0006] The users have neither the knowledge, nor a fortiori the control of the applications which process their personal data. However, the unlimited use of these personal data is increasingly contested.

[0007] Encrypting data is a radical solution which, on the one hand, has the advantage of preserving their confidentiality, but, on the other hand, has the drawback of preventing any processing of the data by a third party.

[0008] However, there are many cases where users may wish their data to be processed by third parties.

[0009] Thus, certain medical data of patients must be able to be processed by health organizations (hospitals, clinics, doctors); certain administrative data of citizens must be able to be processed by the administrations; certain financial data must be able to be processed by the tax authorities.

[0010] However, it may be desirable for the user, owner of the data, to have a right to inspect the functionalities of the applications which process his data.

[0011] However, third-party application editors are not necessarily willing to communicate their source code.

[0012] There is therefore a need for a solution making it possible to verify that the instructions of an application intended to process data satisfy certain conditions (typically, that these instructions do not execute an outright copy of the processed data), all by preserving the confidentiality of the application, in order to protect its publisher against copies.

SUMMARY OF THE INVENTION

A method is proposed for storing a third-party application determined by a source code, from a computer processing unit, called the transmitter, connected or integrated into a peer-to-peer network composed of a plurality nodes forming a distributed database on which is stored, by replication on each node, a chain of blocks, this method comprising the following operations: <tb> <SEP> - From the transmitter, send a storage request to the network; <tb> <SEP> - On receipt of the request by the network: <tb><SEP> <SEP> o Select a so-called computation node, equipped with a processing unit in which an execution environment secured by cryptography, called an enclave, is implemented; <tb><SEP> <SEP> o Select a storage node on which is stored a source code audit program, this audit program comprising a list of commands declared prohibited, and instructions for verifying that a code source does not contain a command declared prohibited; <tb> <SEP> - Instantiate the compute node enclave; <tb> <SEP> - From the transmitter, load the source code of the third-party application into the enclave, via a secure communication line; <tb> <SEP> - From the storage node, load the source code audit program into the enclave; <tb> <SEP> - In the enclave: <tb><SEP> <SEP> o Run the audit program on the source code of the third party application; <tb><SEP> <SEP> o If the source code thus audited does not contain any command declared prohibited, compile it to obtain an executable file of the third-party application; <tb><SEP> <SEP> o Encrypt the executable file to form an encrypted container, by associating it with a cryptographic decryption key; <tb><SEP> <SEP> o Designate, among the network, one or more primary storage nodes and one or more secondary storage nodes distinct from the primary storage nodes; <tb><SEP> <SEP> o Distribute the encrypted container to the primary storage node (s); <tb><SEP> <SEP> o Distribute the cryptographic decryption key to the secondary storage node (s); <tb> <SEP> - Outside the enclave: <tb><SEP> <SEP> o Store the encrypted container within each primary storage node; <tb><SEP> <SEP> o Store the cryptographic decryption key within each secondary storage node; <tb> <SEP> - Enter in a block of the chain of blocks, by one or more nodes of the network, at least one transaction containing a digital fingerprint of the distributions or memorizations thus carried out.

[0014] According to a preferred embodiment, the following operations are also provided: <tb> <SEP> - In the enclave: <tb><SEP> <SEP> o Fragment the cryptographic decryption key to form a predetermined number of fragments; <tb><SEP> <SEP> o Designate, among the network, a group of secondary storage nodes in a number equal to the fragments; <tb><SEP> <SEP> o Distribute each fragment of the cryptographic decryption key to a secondary storage node, each secondary storage node receiving a unique fragment; <tb> <SEP> - Outside the enclave: <tb><SEP> <SEP> o Store each fragment of the decryption cryptographic key within each secondary storage node.

BRIEF DESCRIPTION OF THE FIGURES

[0015] 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 steps of a process for storing an application, in the form of an encrypted executable, on a blockchain network.

DETAILED DESCRIPTION OF THE INVENTION

The proposed method aims to store, in the form of an executable, an application initially determined by a source code, after having audited the source code to verify that it satisfies certain predetermined conditions.

Without being limited thereto, the proposed control method exploits, by combining them, the functionalities offered by two relatively recent technologies of which it seems useful to make a preliminary description before going into the details of the method, namely: Blockchain technology or, in Anglo-Saxon terminology, blockchain (in what follows, Anglo-Saxon terminology will be preferred, because of its common use in most languages, including French); The technology of the secure execution environment or, in English terminology, of the trusted execution environment (TEE).

[0018] 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”.

The blockchain network is a decentralized computer network, called a peer-to-peer network (in Peer-to-Peer or P2P terminology), made up 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, that is to say a computing and memory space allocated within a physical server and on which an operating system or an operating system emulation is running), 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 links 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.

[0021] The nodes2 can be scattered over large geographic regions; they can also be grouped into smaller geographic regions.

The blockchain protocol is in the form of a computer program implemented in each node2 of the network1 blockchain, 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.

The slightest modification of the data of the body4Aou 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.

[0024] 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.

For a bloc4donné of rank N (N an integer), the pointer ensures an unalterable link with the bloc4précè 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 register5blockchain a reputation for immutability, guaranteed by the fact that the register5blockchain 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.

Whatever the type of consensus applied by the block validation mechanism4, most blockchain technologies have the primary function of recording, in their blockchain ledger5, 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 1blockchain network to submit transactions to it, and synchronization functions with the 5blockchain register to register, in the memory area, the transactions validated by registration in the 5blockchain register.

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

Some recent blockchain technologies (Ethereum, typically) add to the three hardware (blockchain network), protocol (blockchain protocol) and informational (blockchain register) layers an application layer which is in the form of a development environment for programming applications, called “smart contracts”, which can be deployed on the ledger5blockchain from nodes2.

We will now briefly describe the technology of smart contracts.

[0033] 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 offered 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 recording (possibly in the form of a digital fingerprint) of this result as a transaction in the register 5 blockchain.

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

We now briefly introduce secure execution environments.

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.

[0039] 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 whose content 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 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 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 enclave8sous 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.

In theFIG.3, there is shown a functional diagram which illustrates different steps of the method of storing an application. This application is determined by a source code15, which is stored on a computer processing unit, called transmitterE, connected to the network1blockchain.

According to a preferred embodiment, the method is implemented by an intelligent contract SC deployed on the blockchain5.

The application is intended to process data (not shown), such as personal, medical, financial data of a user.

The source code15 is auditable, that is to say that it can be examined to detect any undesirable instructions; however, it is not applicable as it is: it should be compiled to derive an executable capable of being applied to the data to be processed.

To this end, a source code audit program is provided, which comprises a predetermined list of commands declared prohibited (such as at least partial copying of the data to be processed), and instructions for verifying that the source code is not contains no order declared prohibited.

As illustrated in laFIG.3, the audit program is stored (in the form of a file, preferably directly in the form of an executable) on a storage node 2S of the network.

A first operation 101 consists, from the transmitter, in transmitting to the network 1 a storage request. In the example illustrated, this request is executed by a call (CALL) of the intelligent contractSC.

A second operation 102 consists, on receipt of the storage request, in: <tb> <SEP> o Select a calculation node2Cdit, equipped with a processing unit in which an enclave 8 is implemented; <tb> <SEP> o Select a storage node 2 on which the audit program is stored.

These operations are typically carried out by executing the instructions of the intelligentSC contract.

A third operation consists in instantiating the computation enclave8du node2C. The smart contract code SC is loaded into the enclave8 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.

A fourth operation104 consists, from the transmitterE, in loading the source code15of the third-party application into the enclave8, via a secure communication line (eg using the Transport Layer Security or TLS protocol). For this purpose, the enclave8 can be provided, as soon as it is instantiated, with a communication interface 18 emulation supporting the chosen protocol (here TLS) for the exchange of secure data.

A fifth operation105 consists, from the storage node2S, in loading into the enclave8 (also, preferably, via a secure communication line) the audit program16.

A sixth operation 106 consists, in the enclave 8, in executing the audit program 16 on the source code 15 of the third-party application, for the purpose of verifying that it does not contain an instruction declared prohibited. For this purpose, the enclave8 includes an audit module19.

If the source code15 thus audited does not contain any order declared prohibited, it is declared certified. In FIG. 3, for the sole purpose of understanding, the audited source code15 is accompanied by a certificate which illustrates the success of the audit carried out.

In this case, a seventh operation 107 then consists in compiling the source code15 thus audited, by means of a compiler20 (previously loaded in the enclave5), the result of this compilation being an executable file21 of the third-party application. For this purpose, the enclave8 includes a compilation module22.

An eighth operation108consists in encrypting the executable file21 to form an encrypted container23, by means of an encryption cryptographic key, by associating it with a decryption cryptographic key24. According to a preferred embodiment, the encryption is symmetrical, so that the encryption key and the decryption key are one and the same key.

The encryption is carried out within an encryption module25 with which the enclave8 is provided.

The encrypted container23 containing the executable file21 of the third-party application, on the one hand, and the associated decryption key24, on the other hand, can then be distributed over the blockchain network.

[0068] However, according to a preferred embodiment, the key 24 is previously fragmented.

Thus, as illustrated in theFIG.3, a ninth operation109 consists in fragmenting the decryption key24. More precisely, the decryption key24 is fragmented into a predetermined number N of fragments24.i, (i an integer, 2≤i≤N).

According to a preferred embodiment, N is such that N> 3 and the fragmentation is carried out in application of Shamir's rules (known as Shamir's Secret Sharing, in English Shamir's Secret Sharing), and more precisely of the threshold diagram , where a predetermined integer K (1 <K <N) is chosen such that a number K of fragments24 is sufficient to reconstitute the decryption key24.

A tenth operation 110 then consists in designating, among the network 1, one or more primary storage nodes 2 intended to receive the encrypted container 23, and one or more secondary storage nodes 2 B distinct from the primary storage nodes 2, and intended for to receive the key 24.

More precisely, in the case where the key24 is fragmented, this tenth operation comprises the designation, among the network1, of a group of several secondary storage nodes2B, in number N equal to the number of fragments24.ide the decryption key24.

As seen in Fig.3, these secondary storage 2B nodes are preferably distinct from primary storage nodes2 - in other words, primary storage nodes2 and secondary storage nodes2B form two disjoint groups (shown in dotted lines in FIG. 3).

An eleventh operation consists in distributing the encrypted container23 to the primary storage node or nodes.

A twelfth operation112 consists in distributing the key24de decryption to the secondary storage node (s) 2B (s). More precisely, in the example illustrated, this twelfth operation112 consists in distributing the fragments24.ide the cryptographic decryption key24 to the secondary storage nodes2B, each secondary storage node2B receiving a unique fragment24.i.

According to a preferred embodiment, the enclave8 is provided with a distribution module26 for the encrypted container23, to which the encryption module25 communicates the encrypted container23, as well as a fragmentation and key distribution module27, to which the encryption module25 communicates the decryption key24. for fragmentation and distribution to secondary storage 2B nodes.

These operations completed, the enclave8 can be closed.

Outside the enclave8, the following operations are carried out: <tb> <SEP> o The encrypted container23 is stored within each primary storage node2; <tb> <SEP> o Key24 is stored within each secondary storage node2B - and more specifically, in the example shown, each fragment24.ide the decryption cryptographic key24 is stored within each secondary storage node2B respective.

To ensure the traceability of these operations, at least one transaction28containing a digital imprint of the distributions or memorizations thus carried out is registered in a block4of the chain5de blocks, by one or more nodes2 of the network1. This transaction can be initiated by the Primary2 and Secondary2B storage nodes, but it can also be initiated by the enclave8 itself (and more specifically by a module29blockchain) before it closes.

Thanks to the method which has just been described, it is possible to verify that the instructions of an application intended to process data satisfy certain conditions (typically, that these instructions do not execute a pure and simple copy of the data. processed), while preserving the confidentiality of the application, which makes it possible in particular to protect its publisher against copies.

Once the audit has been performed, the application is compiled and then stored in the form of an executable, ready to use for data processing. The audit carried out on the source code of the application guarantees that the data will not be subjected to undue exploitation.

Claims (2)

1. Method for storing a third-party application determined by a source code (15), from a computer processing unit, called the transmitter (E), connected or integrated into a compound peer-to-peer network (1) of a plurality of nodes (2) forming a distributed database on which is stored, by replication on each node (2), a chain (5) of blocks, this method comprising the following operations: - From the transmitter (E), transmit to the network (1) a storage request; - On receipt of the request by the network (1): o Select a so-called computing node (2C), equipped with a processing unit in which an execution environment secured by cryptography, called an enclave (8) is implemented; o Select a storage node (2S) on which is stored a source code audit program (16), this audit program (16) comprising a list of commands declared prohibited, and instructions for verifying that a code source does not contain a command declared prohibited; - Instantiate the enclave (8) of the compute node (2C); - From the transmitter (E), load the source code (15) of the third-party application into the enclave (8), via a secure communication line (17); - From the storage node (2A), load the source code audit program (16) into the enclave; - In the enclave (5): o Run the audit program (16) on the source code (15) of the third-party application; o If the source code (15) thus audited does not contain any command declared prohibited, compile it to obtain an executable file (21) of the third-party application; o Encrypt the executable file (21) to form an encrypted container (23), by associating it with a cryptographic decryption key (24); o Designate, from among the network (1), one or more primary storage nodes (2A) and one or more secondary storage nodes (2B) distinct from the primary storage nodes (2A); o Distribute the encrypted container (23) to the primary storage node (s) (2A); o Distribute the cryptographic decryption key (24) to the secondary storage node (s) (2B); - Outside the enclave (8): o Store the encrypted container (23) within each primary storage node (2A); o Store the cryptographic decryption key (24) within each secondary storage node (2B); - Enter in a block (4) of the chain (5) of blocks, through one or more nodes (2) of the network (1), at least one transaction containing a digital fingerprint of the distributions or memorizations thus carried out. 2. The method of claim 1, which comprises the following operations: - In the enclave (8): o Fragment the cryptographic decryption key (24) to form a predetermined number of fragments (24.i); o Designate, among the network (1), a group of secondary storage nodes (2B) in a number equal to the fragments (24.i); o Distribute each fragment (24.i) of the cryptographic decryption key (24) to a secondary storage node (2B), each secondary storage node (2B) receiving a single fragment (24.i); - Outside the enclave (8): o Memorize each fragment (24.i) of the cryptographic decryption key (24) within each secondary storage node (2B).