A method for securing data stored in non-volatile memory space.

Abstract

A method for securing data stored in a non-volatile memory space (DMEM) comprising: providing in memory space a first indexed database (ADB) and a second indexed database (TDB) configured to form a sparse Merkle tree; after each update of the first database, updating the Merkle tree in the second database so that its current state reflects the current state of the first database, storing in a secure non-volatile memory space (SMEM) a root hash code (RHm) of the Merkle tree representative of the current state of the second database, and using it to verify the validity of data read from the first database. Figure 1

Description

Title of the invention: Method for securing data stored in a non-volatile memory space. technical field

[0001] The present invention relates to a method for securing data stored in a non-volatile memory space and a data storage system. The present invention also relates to a method for executing an application program using a hardware security module equipped with secure memory, the execution of the application program comprising steps of creation and modification by the hardware security module of data necessary for the execution of the program. The present invention further relates to a secure system comprising a hardware security module equipped with secure memory and configured to execute at least one application program, the execution of the application program comprising steps of creation and modification of data by the hardware security module.

[0002] Background

[0003] Securing data stored in non-volatile memory is a major concern in sensitive sectors such as banking and cryptocurrencies. The use of secure processors, such as hardware security modules or "HSMs," offers a robust solution for protecting this information. The integration of robust security protocols and the application of international security standards, such as FIPS 140-2, ensure that the implementation of a security infrastructure meets the most stringent requirements. These measures, combined with the judicious use of an HSM for key management, make it possible to effectively secure large amounts of data in non-volatile memory, thus meeting the critical needs of the banking and cryptocurrency sectors.

[0004] However, a significant challenge lies in the fact that secure processors such as HSMs have limited memory space. This poses a particular problem when it comes to securing large amounts of data that require mass storage while ensuring a high degree of security against hacker attacks.

[0005] A known and effective solution to overcome this limitation is to use the HSM not to directly store all the data, but to manage the encryption keys, the data itself being stored in less secure mass storage systems, but encrypted in such a way that it is unusable without the appropriate keys, which are protected by the HSM. This approach makes it possible to Leveraging the high storage capacity of mass storage systems while ensuring data security is crucial. In practice, this means encrypting sensitive data before writing it to the mass storage. The HSM securely generates, stores, and manages encryption keys, ensuring that even if an attacker gains access to the mass storage, the data remains unreadable without the proper keys.

[0006] In the banking sector, for example, financial transactions and customers' personal information can be protected by strong encryption. The HSM ensures that the encryption keys used to secure this data cannot be extracted or manipulated by unauthorized entities. Similarly, in the cryptocurrency sector, the private keys needed to sign transactions can be securely stored in an HSM, thus providing protection against theft and fraud.

[0007] The use of advanced encryption techniques makes it possible to optimize the use of the limited memory space of an HSM. For example, data can be encrypted using a symmetric key, while this key is itself encrypted using a symmetric key stored in the HSM, called a wrapping key. When it is necessary to decrypt the data, the symmetric key is retrieved and decrypted by the HSM. This wrapping key is usually inserted into the HSM using one or more smart cards, which allows it to be inserted into a new HSM in case of a problem with the current HSM.

[0008] These known solutions, however, have their own limitations, notably in that they do not protect data against so-called "replay attacks," namely the fraudulent insertion of initially authentic but outdated data. Furthermore, in some implementations, the programs running these applications, or application programs, are directly executed by a Hardware Security Module (HSM), which must therefore handle a large amount of data. This data changes constantly during program execution and is manipulated in real time by the HSM. When the execution of the application program is interrupted, the data must be stored securely and then retrieved by the HSM when program execution resumes.

[0009] Another known solution, which can be combined with the previous ones, consists of using monotonic counters whose values ​​are stored in the memory of an HSM, each piece of data to be protected being associated with a monotonic counter. Such a solution is described, for example, in international patent application WO 2019 / 175482. In addition to the security provided by the encryption / signature techniques mentioned above, monotonic counters add protection against replay attacks by associating a unique and incremental value with each An operation or transaction that results in the modification of data. Thus, when data is saved or updated, the monotonic counter associated with the data is incremented by the HSM, and this value is stored with the encrypted data on mass storage. Meanwhile, the HSM retains the counter value in secure memory, preventing any unauthorized modification. When reading or verifying the data or data block, the associated monotonic counter is compared with the expected value stored in the HSM, allowing for the detection of any alteration or attempt to reread outdated data.

[0010] This solution makes it possible to effectively secure large amounts of data from mass storage while maintaining a high degree of security. It ensures that even if an attacker gains access to the mass storage, they will not be able to modify or replay data undetected, thanks to the monotonic counter management by the HSM. This provides robust protection against hacker attacks, while optimizing the use of the HSM's limited memory space.

[0011] However, this solution shows its limitations in that it leads to a multiplication of the number of monotonic counters that must be stored by the HSM, which can lead to saturation of its secure memory.

[0012] It might therefore be desirable to provide a method for executing an application program using a hardware security module equipped with secure memory, the execution of the application program including steps of creation and modification by the hardware security module of a large amount of data that cannot be stored in its secure memory.

[0013] Summary

[0014] Embodiments relate to a method for securing data stored in a non-volatile memory space, the method comprising the steps of: providing in the non-volatile memory space a first indexed database and storing the data in the first database, the first database comprising a plurality of locations each identifiable by an index, each location being able to receive a data;provide in the non-volatile memory space a second indexed database associated with the first database and configured to form a sparse Merkle tree comprising leaf nodes and internal nodes extending over a plurality of levels of the tree up to a top node, each location of the first database being associated with a leaf node, each leaf node receiving a hash code of the data present in the location to which it is associated (or a hash code of an empty node), each higher-level node receiving a hash code based on the hash codes present in two preceding nodes, up to the top node, the top node comprising a root hash code; after each update; to update the first database, update the Merkle tree in the second database so that its current state reflects the current state of the first database; store in secure non-volatile memory a root hash code of the Merkle tree representative of the current state of the second database, and, when data is to be read from the first database: read the data from the first database; compute a first root hash code of the Merkle tree based on the current state of the second database, and compare the first root hash code to a root hash code stored in secure non-volatile memory, the data being valid if the first root hash code is equal to the stored root hash code.

[0015] According to one embodiment, the method comprises, when data is to be stored in a target location of the first database, the steps of: calculating the first root hash code of the Merkle tree based on the current state of the second database, and comparing the first root hash code to the root hash code stored in secure non-volatile memory, and if the first root hash code is identical to the stored root hash code: calculating a second root hash code based on the state in which the second database will be after the new data has been recorded in the first database and the second database has been updated, storing the second root hash code in secure non-volatile memory, replacing the previously stored root hash code, and updating the first database with the new data.and update the Merkle tree in the second database.

[0016] According to one embodiment, the step of computing the first root hash code of the Merkle tree based on the current state of the second database comprises the steps of: reading data contained in the target location or determining that the location is empty; identifying a target leaf node associated with the target location; identifying nodes linked to the target leaf node, the linked nodes being on a path connecting the target leaf node to the top node; extracting from the second database a Merkle proof of the target leaf node, the Merkle proof comprising hash codes contained in nodes neighboring the linked nodes; computing or determining a hash code that the target leaf node is assumed to contain;based on the hash code that the target leaf node is assumed to contain and the Merkle proof extracted from the second database, calculate or determine hash codes that the nodes linked to the target leaf node are assumed to contain, and calculate or determine the first root hash code based on the hash code that the target leaf node is assumed to contain, the proof of; Merkle extracted from the second database, and hash codes that the nodes linked to the target leaf node are supposed to contain.

[0017] According to one embodiment, the step of calculating the second root hash code based on the state in which the second database will be after recording the new data in the first database and updating the second database, includes the steps of: on the basis of the new data, calculating or determining a new hash code that the target leaf node will contain; on the basis of the new hash code that the target leaf node will contain and the Merkle proof extracted from the second database, calculating or determining new hash codes that the nodes linked to the target leaf node are assumed to contain, and calculating or determining the second root hash code on the basis of the new hash code that the target leaf node will contain, the Merkle proof extracted from the second database, and the new hash codes that the nodes linked to the target leaf node are assumed to contain.

[0018] According to one embodiment, an empty leaf node is a node associated with an empty location in the database, and an empty leaf node conventionally contains an empty node hash code of predetermined value.

[0019] According to one embodiment, the empty node hash code) is equal to zero.

[0020] According to one embodiment, a parent node of two empty nodes is an empty node containing by convention the empty node hash code.

[0021] According to one embodiment, a parent node of an empty node and a non-empty node conventionally contains a hash code present in the non-empty node followed by a bit equal to 0 or 1 depending on whether the empty leaf node is located in the Merkle tree to the right or left of the non-empty leaf node, or vice versa.

[0022] According to one embodiment, a parent node of two empty leaf nodes conventionally contains a hash code equal to the result of hashing the concatenation of the empty node hash codes contained by each of the two empty leaf nodes.

[0023] According to one embodiment, only the root hash code is stored in secure non-volatile memory, and no data from the first or second database.

[0024] According to one embodiment, at least all the hash codes contained in non-empty nodes of the Merkle tree are stored in the second database.

[0025] According to one embodiment, the process includes the steps of: providing at least one first processor to manage the first and second databases, and providing a second secure-type processor to manage the secure non-volatile memory.

[0026] According to one embodiment, the steps of calculating the first root hash code and comparing the first code are executed using the second processor. root hash to the root hash code stored in secure non-volatile memory.

[0027] According to one embodiment, when new data is to be stored in a target location of the first database, the second processor is provided by means of the first processor with an index of the target leaf node corresponding to the target location, data contained in that location or an indication that the location is empty, and the corresponding Merkle proof.

[0028] Embodiments also relate to a data storage system comprising: a non-volatile memory space comprising a first indexed database in which the data are stored, the first database comprising a plurality of locations each identifiable by an index, each location being able to receive data, a second indexed database associated with the first database and configured to form a sparse Merkle tree comprising leaf nodes and internal nodes extending over a plurality of levels of the tree up to a top node, each location of the first database being associated with a leaf node, each leaf node receiving a hash code of the data present in the location to which it is associated or a hash code of an empty node, each higher-level node receiving a hash code based on the hash codes present in two preceding-level nodes,up to the apex node, the apex node comprising a root hash code; secure non-volatile memory, in which is stored a root hash code of the Merkle tree representative of the current state of the second database. The system is configured to, after each update of the first database, update the Merkle tree in the second database so that its current state reflects the current state of the first database, and when data needs to be read from the first database, to: read the data from the first database; calculate a first root hash code of the Merkle tree based on the current state of the second database, and compare the first root hash code to a root hash code stored in secure non-volatile memory, the data being valid if the first root hash code is equal to the stored root hash code.

[0029] According to one embodiment, the system is configured so that, when data is to be stored in a target location of the first database: calculate the first root hash code of the Merkle tree based on the current state of the second database, and compare the first root hash code to the root hash code stored in secure non-volatile memory, and if the first root hash code is identical to the stored root hash code: calculate a second root hash code based on the state in which the second database will be data after recording the new data in the first database and updating the second database; store the second root hash code in secure non-volatile memory, replacing the previously stored root hash code; update the first database with the new data, and update the Merkle tree in the second database.

[0030] According to one embodiment, the system is configured to conduct the calculation step of the first root hash code of the Merkle tree based on the current state of the second database as follows: read data contained in the target location or determine that the location is empty; identify a target leaf node associated with the target location; identify nodes linked to the target leaf node, the linked nodes being on a path connecting the target leaf node to the top node; extract from the second database a Merkle proof of the target leaf node, the Merkle proof comprising hash codes contained in nodes neighboring the linked nodes; calculate or determine a hash code that the target leaf node is assumed to contain;Based on the hash code assumed to be present in the target leaf node and the Merkle proof extracted from the second database, calculate or determine hash codes assumed to be present in the nodes linked to the target leaf node; calculate or determine the first root hash code based on the hash code assumed to be present in the target leaf node, the Merkle proof extracted from the second database, and the hash codes assumed to be present in the nodes linked to the target leaf node.

[0031] According to one embodiment, the system is configured to conduct the step of calculating the second root hash code based on the state of the second database after recording the new data in the first database and updating the second database as follows: based on the new data, calculate or determine a new hash code that the target leaf node will contain; based on the new hash code that the target leaf node will contain and the Merkle proof extracted from the second database, calculate or determine new hash codes that the nodes linked to the target leaf node are assumed to contain;and calculate or determine the second root hash code based on the new hash code that the target leaf node will contain, the Merkle proof extracted from the second database, and the new hash codes that the nodes linked to the target leaf node are assumed to contain.

[0032] According to one embodiment, the secure non-volatile memory stores only the root hash code and no data from the first or second database.

[0033] According to one embodiment, the second database stores at least all the hash codes contained in non-empty nodes of the Merkle tree.

[0034] According to one embodiment, the system includes at least a first processor to manage the first and second databases, a second secure-type processor to manage the secure non-volatile memory, the secure non-volatile memory not being accessible for reading or writing to the first processor.

[0035] According to one embodiment, the system is configured to execute, using the second processor, the steps of calculating the first root hash code of the Merkle tree based on the current state of the second database, and comparing the first root hash code to the root hash code stored in the secure non-volatile memory.

[0036] According to one embodiment, the system is configured so that, when new data is to be stored in a target location of the first database, the first processor provides the attention of the second processor with an index of the target leaf node corresponding to the target location, data contained in that location or an indication that the location is empty, and the corresponding Merkle proof.

[0037] According to one embodiment, the system includes a user entity operationally interposed between the first and second processors, the data provided by the second processor to the first processor being received by the user entity which provides it to the first processor.

[0038] Brief description of the drawings

[0039] Examples of embodiments of a process and a system implementing the process according to this disclosure will be described below, without limitation, in connection with the accompanying figures, including:

[0040] - Figure 1 shows an example of a data storage system architecture implementing a method of carrying out the process,

[0041] - [Fig.2] shows a simplified example of a Merkle tree,

[0042] - Figure 3 shows the assignment of predetermined hash codes to nodes empty leaves and their parent nodes, according to a first convention,

[0043] - Figure 4 shows the assignment of specific hash codes to leaf nodes voids and their parent nodes, according to a second convention,

[0044] - [Fig. 5] shows a part of the Merkle tree of [Fig. 2] and shows, for a a given leaf node, a set of nodes connected to the leaf node, and a set of nodes forming a Merkle proof for the leaf node in question,

[0045] - [Fig. 6] shows a part of the Merkle tree of [Fig. 2] and shows, for two determined leaf nodes, a set of nodes linked to the two leaf nodes and a set of nodes forming a Merkle proof for the two leaf nodes considered,

[0046] - [Fig.7] is a flowchart describing steps for securing reading of a piece of data in the system of [Fig. 1], according to one embodiment of the process,

[0047] - [Fig. 8] is a flowchart describing steps for securing the writing of a data point in the system of [Fig. 1], according to one embodiment of the process,

[0048] - [Fig. 9] shows a second example of a storage system architecture of data implementing an alternative embodiment of the process,

[0049] - [Fig. 10] shows a simplified example of a Merkle tree,

[0050] - [Fig.11] shows the Merkle tree from [Fig.10] after writing a new given,

[0051] - [Fig. 12A] is a sequence diagram showing writing steps of the new data from the system of [Fig.9],

[0052] - [Fig.12B] describes steps in the diagram of [Fig.12A],

[0053] - [Fig. 13] shows the Merkle tree of [Fig. 11] after modification of a given,

[0054] - [Fig. 14A] is a sequence diagram showing modification steps of the new data from the system of [Fig.9], and

[0055] - [Fig.14B] describes steps in the diagram of [Fig.14A]. Detailed description

[0056] Figure 1 shows a data storage system implementing an embodiment of the secure data storage method according to this disclosure. The system includes a non-volatile DMEM memory space of sufficient size to receive a large amount of DTi data. This memory space can be implemented in various known ways, for example, by being composed of an integrated circuit memory such as FLASH or EEPROM, or an assembly of several integrated circuit memories on an interconnect medium, or by being composed of one or more hard drives, in particular magnetic or solid-state drives (SSDs). The DMEM memory space is controlled by a DPROC processor that manages the DTi data it contains and has read and write rights to data in the DMEM memory space.DTi data is generally application or contextual data, i.e., data generated, modified, or deleted by one or more application programs that perform various tasks.

[0057] The system also includes a secure SMEM memory under the control of a secure SPROC processor, which has exclusive read and write access rights to the SMEM memory. Access to the SMEM memory can be controlled by authentication and authorization mechanisms ensure that only the SPROC processor can access it. In one embodiment, the secure SPROC processor is a hardware security module or "HSM".

[0058] The DPROC processor is connected to the SPROC processor by an LK1 data link. The LK1 link can be a link within a local area network (LAN), a link on the motherboard via a PCI bus (Peripheral Component InterConnect), or another type of secure link.

[0059] The system also includes a user entity (USR), which is connected to the DPROC processor via an LK2 data link and to the SPROC processor via an LK3 data link. The USR can be a server, a personal computer, a hardware cryptocurrency wallet such as those marketed by the applicant, or used via a companion application such as Ledger Live®. The LK2 and LK3 data links are preferably secure HTTPS (Hypertext Transfer Protocol Secure) links. For even greater security, the LK2 and LK3 links can consist of SCP (Secure Channel Protocol) encrypted channels based on a Diffie-Hellman key exchange. In one embodiment, the LK3 link takes the form of an SCP encrypted channel based on a Diffie-Hellman key exchange, which is established via the LK2 and LK1 links.

[0060] The DMEM memory space contains an ABD ("Application Data Database") and a TDB ("Merkle Tree Database") configured as a Merkle tree. The ADB contains the aforementioned DTi data, and the TDB contains Hi hash codes. The Merkle tree is of the so-called "sparse" type, meaning that its topology is preconfigured and does not evolve as it receives hash codes, starting from an initial state where it is completely empty. However, for the sake of simplicity, this sparse Merkle tree will be referred to hereafter as the "Merkle tree" or simply the "tree."

[0061] The DPROC processor executes an AMP (Application Data Database Management Program) for managing the ADB database and a TMP (Merkle Tree Management Program), in other words, a TDB database management program. The two programs operate in coordination so that the two databases, ADB and TDB, are synchronized in a manner that will become apparent later.

[0062] Furthermore, the secure processor SPROC executes an Application Data Database Check Program (ACP), the function of which will also be described later. The user entity USR executes a User Application Program (UAP) that uses the ADB database to store data.

[0063] A simplified example of a Merkle tree is shown in [Fig. 2]. The Merkle tree comprises leaf nodes LN and internal nodes IN extending over a plurality of levels of the tree up to a top node TN (also called the root node). In this example, the tree contains eight leaf nodes with indices [II] to

[18] , four level 1 internal nodes IN with indices

[112] ,

[134] ,

[156] , and

[178] , two level 2 internal nodes IN with indices

[114] and

[158] , and one top node TN with index

[118] . Each node corresponds to a block of data indexed in the database TDB.

[0064] The ABD database comprises a plurality of indexed LO locations, each location having a specific index associated with a specific LN leaf node of the TDB database. Preferably, the index of each LO location is chosen to be identical to the index of the LN leaf node to which it is associated, thus avoiding the need for a lookup table. Therefore, in the example shown, the ABD database comprises eight LO locations with indices [II] through

[18] . Index location [II] is associated with the index leaf node [II], index location

[12] is associated with the index leaf node

[12] , and so on up to index location

[18] , which is associated with the index leaf node

[18] .

[0065] In a conventional manner, each leaf node has a hash code obtained by hashing the DTi data contained in the LO location to which it is associated. In the example shown, location [II] (i.e., index location [II]) contains DTI data, and the leaf node [II] (i.e., the leaf node with index [II]) associated with it receives a hash code H1 equal to H(DT1), "H" being a hash function used to construct the Merkle tree. This hash function is, in one embodiment, the SHA256 (Secure Hash Algorithm) function, a cryptographic hash function that generates, regardless of the size of the input data, a fixed-size hash code of 256 bits (32 bytes).

[0066] Similarly, location

[12] contains data DT2 and the associated leaf node

[12] receives a hash code H2 equal to H(DT2). Location

[14] contains data DT4 and the associated leaf node

[14] receives a hash code H4 equal to H(DT4). Location

[16] contains data DT6 and the associated leaf node

[16] receives a hash code H6 equal to H(DT6). Locations

[13] ,

[15] ,

[17] , and

[18] are empty, i.e., they have not received any data, the symbol for an empty location being "0" in [Fig. 2]. By convention, the leaf nodes

[13] ,

[15] ,

[17] ,

[18] associated with empty locations receive an empty node hash code denoted H(0), i.e., here H3=H5=H7=H8=H(0).

[0067] Each internal node IN receives a hash code calculated by hashing a bit string formed by concatenating the hash codes present in two previous level nodes, or child nodes, up to the top node, which includes a The root hash code is RH. Thus, in the example shown, node

[112] receives a hash code H12=H(H1IH2), where "I" is the concatenation symbol. Node

[134] receives a hash code H34=H(H3IH4). Node

[156] receives a hash code H56=H(H5IH6). Node

[178] receives a hash code H78=H(H7IH8). Node

[114] receives a hash code H14=H(H12IH34). Node

[158] receives a hash code H58=H(H56IH78). Node

[118] , or the top node TN, receives the root hash code RH=H(H14IH58).

[0068] The empty node hash code H(0) is a predetermined value chosen by convention, as is the way it propagates through the Merkle tree. In one embodiment shown in [Fig. 3], which represents only a portion of the Merkle tree in [Fig. 2], the empty node hash code H(0) is equal to 0, which in practice is a string of zero-valued bits containing a number of 0 bits, for example, 256 bits. The hash code of a parent node of two empty nodes H(0), here node

[178] , is also equal to 0 and is of the same length. By convention, the hash code of a parent node of an empty child node and a non-empty child node is equal to the hash code of the non-empty child node followed by a bit equal to 0 or 1 depending on whether the empty child node is in the Merkle tree to the right or left of the non-empty child node, or vice versa.

[0069] Thus, in the example shown, the hash code H78 of node

[178] is equal to H(0), or 0, because the hash code H7 of node

[17] is equal to H(0) and the hash code H8 of node

[18] is equal to H(0). The hash code H56 of node

[156] is equal to H6I0, or H(DT6)IOI, because the empty node

[15] is located to the left of the non-empty node

[16] , whose hash code H6 is equal to H(DT6). The H56 code is 257 bits if the hash code H(DT6) is 256 bits. Finally, the hash code H58 of node

[158] is equal to H56I1, or H(DT6)IOI1, because the empty node

[178] is located to the right of the non-empty node

[156] . This code is 258 bits long if the hash code H(DT6) is 256 bits long.

[0070] In other words, determining the hash codes according to this convention involves a higher-level HF function than the hash function H itself. The rules just described can be formalized with the following notation:

[0071] H5=FH(0)=0

[0072] H6=FH(DT6)=H(DT6)

[0073] H7=FH(0)=0

[0074] H8=FH(0)=0

[0075] H56=FH(0,H6)=H6IO=H(DT6)IO

[0076] H78=FH(0,0)=0

[0077] H58=FH(H56.0)=H5611=H(DT6)IOI 1.

[0078] In this notation, the comma indicates that the highest-level function FH is being called. It should be noted that the term "hash code" can therefore cover The concatenation of a hash code with one or more bits, due to the chosen convention, here the FH function. Thus, this term does not only refer to the result of hashing a piece of data. In some cases, such as those just described, it only refers to the code conventionally assigned to the node in question.

[0079] In another embodiment of the Merkle tree shown in [Fig. 4], which represents the same part of the tree in [Fig. 2] as that shown in [Fig. 3], the hash code of an empty node H(0) is equal to 0, but the hash code of a parent node of two empty child nodes, here node

[178] , is equal to H(0000), that is, the result of hashing by means of the function H the concatenation of the two empty hash codes, for example, a 512-bit zero-value binary string if each of the child nodes' hash codes is a 256-bit zero-value binary string. The result of such a hash of a zero-value bit string is never equal to 0.By convention, the hash code of a parent node of an empty child node and a non-empty child node is calculated normally as the hash code of a bit string obtained by concatenating the hash code of the empty node present in the empty child node and the hash code present in the non-empty child node, if the latter is to the right of the empty child node, or obtained by concatenating the hash code present in the non-empty child node and the hash code of the empty node present in the empty child node, if the latter is to the right of the non-empty child node. Thus, in the example shown, the hash code H56 of node

[156] is equal to H(H5IH6), or H(0IH(DT6)). The hash code H78 of node

[178] is equal to H(0IO). The H58 hash code of node

[158] is equal to H(H56IH78) or H(H(01 H(DT6))IH(OIO)). In this case, all hash codes are 256 bits if the hash function used provides 256-bit codes.

[0080] In a conventional manner, any change in the value of a DTi data point causes a corresponding change in the hash code contained in its associated leaf node, which in turn causes a change in the root hash code. A remarkable property of the Merkle tree is that it is possible to calculate the change in the root hash code without recalculating all the hash codes contained in the Merkle tree. It is therefore possible to modify a data point in the ADB database and update the Merkle tree in the TDB database without needing to know the hash codes contained in the tree nodes unaffected by this change. It is also possible to prove that a hash code is valid and belongs to the Merkle tree without needing to reveal the other hash codes or the Merkle tree as a whole.

[0081] More precisely, after modifying a piece of data in the database, it suffices, in order to calculate a new value of the root hash code, to calculate the hash codes contained in the nodes linked LN to the leaf node in question, i.e. the nodes located on a path connecting the leaf node in question to the root node. Now, to calculate the hash codes of the nodes linked to the leaf node in question, it suffices to know the hash codes contained in the neighboring nodes of these linked nodes, together forming what is commonly called "Merkle proof" MP.

[0082] By way of example, [Fig. 5] shows the nodes connected to the leaf node [II] in the Merkle tree of [Fig. 1], here nodes

[112] and

[114] . Furthermore, the neighboring nodes to the connected nodes are

[12] ,

[134] , and

[158] . The hash codes contained in these nodes together form the MP Merkle proof for the leaf node [II]. Thus, if the DTI data at index [1] is known, and the MP Merkle proof is known, it is possible to calculate the hash code contained in the leaf node [II], then, using the Merkle proof, to calculate the hash code contained in node

[112] , then the hash code contained in node

[114] , and finally the root hash code RH.

[0083] This property also applies to several leaf nodes simultaneously, as a Merkle MP proof can be provided for two or more leaf nodes. In the example in [Fig. 6], the Merkle proof concerning two leaf nodes [II] and

[16] is highlighted by arrows. The nodes

[112] ,

[114] linked to the leaf node [II], denoted LN1, are distinguished from the leaf nodes

[178] ,

[158] linked to the leaf node

[18] , denoted LN2. The Merkle proof here contains the hash codes of the nodes

[12] ,

[134] ,

[17] ,

[156] and allows the calculation of the hash codes of the nodes

[112] ,

[114] ,

[178] ,

[158] , and then the calculation of the root hash code RH.In this example, location

[18] of the ADB database is empty, and the hash code contained in the leaf node

[18] is the empty node hash code H(0), whose value and propagation in the Merkle tree are defined by convention, for example, one of the two conventions described above in relation to Figures 3 and 4. Thus, the root hash code of the top node not only proves the value of a non-empty node but also proves that a node is empty, since an empty node receives a conventionally defined hash code. Those skilled in the art will note that this point is essential for implementing the method according to this disclosure, so that the secure SPROC processor can store newly created data in empty locations of the ADB database and verify beforehand that they are empty, as will be seen later.

[0084] This property of the Merkle tree is exploited here by storing in the SMEM memory of the secure processor SPROC an RHm value of the root hash code of the Merkle tree and by verifying, at each read or before each write of data in a target location of the ABD database, that the current root hash code of the Merkle tree is identical to the previously stored RHm. For this purpose, the AMP management program of the ABD database is configured to provide, in addition to the value contained by the location in question, the Merkle proof associated with the target location, i.e., the Merkle proof of the leaf node associated with that location.

[0085] Figures 7 and 8 describe an example of an implementation of this method for reading and writing data in the ADB database. Figure 7 describes the reading steps and Figure 8 describes the writing or erasing steps for the ADB database. The actions described in these figures are performed:

[0086] - by the DPROC processor using the AMP database management program ADB data and the TMP program for managing the Merkle tree,

[0087] - by the user entity USR using the user program UAP, and

[0088] - by the secure SPROC processor, using the ACP verification program the ADB database.

[0089] In [Fig. 7], the DPROC processor is waiting for a read or write command at step D01. At step U01, the user entity sends it a command to read an index location [li]. At step D02, the DPROC processor receives the command. At step D03, the processor communicates the DTi data at index [li] and the corresponding Merkle MP proof to the user entity USR. If the index location [li] is empty (DTi=0), the DPROC processor sends an indication that the location is empty. At step U02, the user entity receives this information and communicates it to the SPROC processor, requesting it to validate the DTi data.

[0090] At step H01, the SPROC processor receives the data DTi (or the information that the location is empty), the index [li], and the Merkle MP proof. At step H02, the SPROC processor calculates a root hash code RH1 that the database TDB is assumed to contain, from DTi, the index [li], and the Merkle MP proof. To this end, the SPROC processor, using the ACP program:

[0091] - identifies the nodes linked to the target leaf node with index [li],

[0092] - calculates a hash code Hi that the target leaf node is assumed to contain, or the determines by convention (case where DTi=0 for which H(DTi)= H(0)), and

[0093] - calculates hash codes that the nodes linked to the target leaf node are assumed to have to contain, based on the hash code that the target leaf node is assumed to contain and the Merkle proof,

[0094] - then calculates the root hash code RH1 based on the hash code that the target leaf node is assumed to contain, from the Merkle proof and hash codes that the nodes linked to the target leaf node are assumed to contain.

[0095] At step H03, the SPROC processor checks that the root hash code RH1 that it has just calculated is identical to the root hash code RHm stored in SMEM memory. If the two codes are different, the SPROC processor sends An error message is sent to the user entity, which then proceeds to an error handling step U10. If the two codes are identical, the SPROC processor goes to step H04 where it sends the user entity confirmation of the validity of the DTi data. At step U03, the user entity receives confirmation of the DTi's validity and can use it for its application.

[0096] Reference will now be made to [Fig. 8]. At step D01, the DPROC processor is waiting for a command. At step U11, the user entity USR sends the DPROC processor a command to write new data DTj to an index location [li], or a command to delete that location. At step D12, the DPROC processor receives the command. At step D13, the DPROC processor communicates to the user entity USR data DTi present at index location [li] and the corresponding Merkle MP proof. If index location [li] is empty (DTi=0), the DPROC processor sends an indication that the location is empty. At step U12, the user entity receives the data DTi and the Merkle MP proof, then sends the SPROC processor:

[0097] - the DTi data where an indication that the location is empty,

[0098] - the index [li] of the location,

[0099] - the Merkle MP proof for this location (even an empty location having (always an associated Merkle proof since the hash code of the associated leaf node has been defined by convention),

[0100] - the new DTj data or an indication that DTj=0 in the case of a command erasure, and

[0101] - information that DTj must replace DTi in the location considered.

[0102] At step H11, the SPROC processor receives the current DTi data, the index [li], the Merkle MP proof for index location [li], and new data DTj.

[0103] At a step H12, the SPROC processor calculates, using the ACP program, the root hash code RH1 that the ADB database is assumed to contain, in the same way as at step H02, namely from the DTi data, the index [li] and the Merkle proof.

[0104] At step H13, the SPROC processor verifies that the root hash code RH1 that it has just calculated is identical to the root hash code RHm stored in SMEM memory. If the two codes are different, the SPROC processor sends an error message to the user entity, which then proceeds to the aforementioned error handling step U10.

[0105] If the two codes are identical, the SPROC processor goes to a step H14 where it computes a new root hash code RH2 from the new data DTj, the index [li], and the Merkle proof MP, and stores the new root hash code RH2 in SMEM memory. To calculate the new root hash code RH2, the SPROC processor uses the ACP program:

[0106] - identifies the nodes linked to the target leaf node with index [li],

[0107] - calculates a hash code Hi that the target leaf node will contain when the tree Merkel's in the TDB database will have been updated with the DTj data, or determined by convention (case where DTj=0 for which H(DTj)= H(0)),

[0108] - calculates hash codes that the nodes linked to the target leaf node will contain, based on the hash code that the target leaf node will contain and the Merkle proof,

[0109] - calculates hash codes that the nodes linked to the target leaf node will contain, based on the hash code that the target leaf node will contain and the Merkle proof,

[0110] - then calculates the root hash code RH2 based on the hash code that the target leaf node will contain, Merkle proof and hash codes that the nodes linked to the target leaf node will contain.

[0111] The SPROC processor then proceeds to a step H15 where it sends to the user entity USR a confirmation of the validity of the DTi data along with the root hash code RH2 that the Merkle tree in the TDB database must contain when the DTj data has been recorded in the ADB database. This confirmation of the validity of the DTi data may be implicit in the sending of the future root hash code RH2.

[0112] At a step U13, the user entity USR receives confirmation of validity and the root hash code RH2 for the data DTj. At a step U14, the user entity can therefore decide to send the processor DPROC a command to write the data DTj or to erase the data DTi if DTj=0, the command including the data DTj or an indication that the data DTi should be erased, and the index [li]. In an optional embodiment, the user entity also sends the root hash code RH2 to the processor DPROC.

[0113] In the latter case, at an optional step D14, the DPROC processor itself calculates the RH2 root hash code from the data it holds in the TDB database, and compares it to the received RH2 root hash code.

[0114] If the two RH2 codes are identical or if the optional step D14 is not implemented, the DPROC processor, at a step D15, stores the new DTj data or clears the DTi data in the ADB database, and updates the Merkle tree in the TDB database.

[0115] If the two RH2 codes are not identical when the optional step D14 is implemented, the DPROC processor goes to an error handling step D20.

[0116] It will be evident to those skilled in the art that the reading and writing process just described can be implemented in the same way for the simultaneous reading or writing of several data points. The steps just described remain substantially the same, except that the proof of Merkel extracted from the ADB database concerns several data points at the same time, as previously seen.

[0117] In the embodiments just described, the SPROC secure processor is used as a trusted entity to verify that the ADB database is healthy each time one or more data items are read, written, or deleted, so that it is impossible for a fraudster to alter the ADB database without this being immediately detected. The secure processor is therefore, in a certain way, at the service of the database and the user entity.

[0118] In an embodiment illustrated in [Fig. 9], the secure processor SPROC is a hardware security module or "HSM," and the processor DPROC forms an HDV host device for the hardware security module. The DPROC and SPROC processors are connected by a PCI ("Peripheral Component Interconnect Express") or Ethernet LK1 link. The DPROC processor executes a Message Dispatch API (MDA) interface that allows the user entity USR, via the LK2 link, to send commands received through the PCI or Ethernet interface to the SPROC processor. In the SPROC processor, these commands are received by a Message Processing Program (MPP), which forwards them to a Secure Application Program (SAP), both programs being executed by the SPROC processor.

[0119] The SAP application program, schematically represented by a block, can in practice be loaded into non-volatile memory of the SPROC processor or be loaded on the fly into external volatile memory (RAM) for the duration of its execution. The SAP application program is configured to execute commands sent by the user entity. At least some of these commands may request it to generate or modify DTi data, or may require, in order to be executed, the generation or modification of DTi data. This program also supports the function of the previously described ACP program, which verifies the ADB database by comparing the stored root hash code RHm with the calculated root hash code RH1 or RH2.

[0120] The UAP user program executed by the USR user entity here requests the SAP application program of the secure processor to perform operations that lead the latter to generate or modify DTi data. The SAP application program uses the ADB database to store such data, in encrypted or unencrypted form. This data can be returned to the UAP program if necessary, or can be modified by the SAP application program from parameters received from the UAP program. However, they are the property of the SAP application program here, with regard to reading and writing.

[0121] The DTi data generated or modified by the SAP application program is stored in the ADB database of the DMEM memory space. In some embodiments, it is stored, in whole or in part, in the ADB database in encrypted form using an encryption key known only to the secure processor. The DMEM memory space thus constitutes an extension of the SMEM memory of the SPROC processor, the latter being insufficient to receive such data. More specifically, the SMEM memory here does not store any DTi application or context data and receives only the RHm root hash code. It is understood, however, that this memory may contain other sensitive data, including secret keys, which will not be described here.

[0122] An example of the execution by the SPROC processor, using the SAP application program, of a sequence of instructions for writing new data into the ABD database will now be described in relation to Figures 12A, 12B. This example is considered in relation to a simplified example of an ABD database and Merkel tree shown in Figures 10 and 11, in which the database comprises only four index locations [II],

[12] ,

[13] ,

[14] .

[0123] In [Fig. 10], location [II] of the ADB database contains the data "user=bob" while locations

[12] ,

[13] ,

[14] are empty (0). In the TDB database, the index leaf node [II] contains a hash code H1 equal to the SHA256 digest of the data "user=bob", while the index leaf nodes

[12] ,

[13] ,

[14] conventionally contain hash codes H2, H3, H4. At the next level of the Merkle tree, the index leaf node

[112] contains a hash code H12 equal to the SHA256 hash of the concatenation of the hash codes H1 and H2, and the index leaf node

[134] contains a hash code equal to the SHA256 hash of the concatenation of the hash codes H3 and H4. Finally, the top node TN contains a root hash code RH equal to the SHA256 hash of the concatenation of the hash codes H12 and H34.

[0124] In [Fig. 11], location [II] of the ADB database still contains the data "user=bob", while location

[12] contains the data "user=alice", locations

[13] ,

[14] are again empty (0). In the TDB database, the index leaf node [II] contains an H1 hash code equal to the SHA256 hash of the data "user=bob", the index leaf node

[12] contains an H2 hash code equal to the SHA256 hash of the data "user=alice", while the index leaf nodes

[13] ,

[14] contain by The H3 and H4 hash codes are governed by the convention. At the next level of the Merkle tree, the index leaf node

[112] contains an H12 hash code equal to the SHA256 digest of the concatenation of the H1 and H2 hash codes, and the index leaf node

[134] contains a hash code equal to the SHA256 digest of the concatenation of the H3 and H4 hash codes. At the top of the Merkle tree, the TN node contains a root RH hash code equal to the SHA256 digest of the concatenation of the H12 and H34 hash codes.

[0125] Figures 12A and 12B describe steps executed by the system in [Fig. 9] to add the data "user=alice" to the database in the state shown in [Fig. 10], in order to obtain the database in the state shown in [Fig. 11]. The acting entities here are:

[0126] - the TMP program for managing the Merkle tree, executed by the processor DPROC,

[0127] - the AMP program for managing the ADB database, executed by the DPROC processor,

[0128] - the user entity USR, executing the user program UAP,

[0129] - the SPROC processor running the SAP secure application program, and

[0130] - SMEM secure memory.

[0131] At step S10, the user entity USR requests the AMP program to provide it with the index of an unused location (empty node index) by sending it a command of the type:

[0132] get empty index()

[0133] At a step S12, the AMP program provides the index

[12] to the user entity USR.

[0134] At step S14, the user entity USR requests the TMP program to communicate Merkle's proof for index location

[12] , by sending him a command of the type:

[0135] GetMP([I2])

[0136] At step S16, the TMP program provides the Merkle proof to the user entity. This consists of the hash codes present in nodes [II] and

[134] :

[0137] MP=[

[0138] Node II =9fe0ad 17617f7c7dada0b94bl6fa2ee009f9b61fcl95a3f6aea9448de532145a

[0139] Node I34=f5a5fd42dl6a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b

[0140] At step S18, the user entity USR requests the secure processor SPROC to create data at index location

[12] , by sending it a command of the type:

[0141] create data(

[12] , MP)

[0142] At step S20, the SPROC processor calculates a root hash code RH1 that the Merkle tree is assumed to contain, from the Merkle MP proof:

[0143] RHl=2613bb239dd614364de3224ee093a36c436c975al8323308303c34dfb2046e57

[0144] For this purpose, the SPROC processor, using the SAP application program:

[0145] - identifies the nodes linked to the target leaf node with index

[12] , here the node with index

[112]

[0146] - determines a hash code that the empty target leaf node of index

[12] is assumed to contain, by applying the chosen convention, for example H(0))=O,

[0147] - calculates hash codes that the nodes linked to the target leaf node are assumed to have contain, here only the index node

[112] , based on the hash code that the target leaf node is assumed to contain and the Merkle proof, which here contains the hash code that the neighboring index node [II] contains.

[0148] - then calculates the root hash code RH1 based on the hash code that the target leaf node with index [II] is assumed to contain, hash codes that the nodes linked to the target leaf node are assumed to contain, here only the node with index

[112] , and the Merkle proof which here contains the hash code that the neighboring node with index 1134 contains].

[0149] At step S22, the SPROC processor requests the SMEM memory to provide it with the root hash code RHm by sending it a command of the type:

[0150] getRHm

[0151] At step S24, the SMEM memory provides the SPROC processor with the stored root hash code RHm:

[0152] RHm=2613bb239dd614364de3224ee093a36c436c975al8323308303c34dfb2046e57

[0153] At step S26, the SPROC processor checks that RH1 and RHm are equal; if not, it returns an error message to the user entity USR. If the two codes are equal, the processor has proof that the index node

[12] is empty, and continues the execution of the command.

[0154] At step S28, the SPROC processor creates the data user=alice

[0155] At step S30, the SPROC processor calculates a root hash code RH2 that The Merkle tree will contain the following when the ADB database has been updated with the data user=alice at index location 112, and when the TDB database has been synchronized with the ADB database:

[0156] b0280d3d756c53e0a69333103cb5d456db3459bbdab4d6cl4e986fa677574249

[0157] To this end, the SPROC processor, using the SAP program:

[0158] - identifies the nodes linked to the target leaf node with index

[12] , here the node with index

[112]

[0159] - determines a hash code that the empty leaf node at index

[12] will contain, here H(user=alice),

[0160] - calculates hash codes that the nodes linked to the target leaf node are assumed to have contain, here only, the index node

[112] , based on the hash code that the target leaf node will contain and the Merkle proof, which here contains the hash code that the neighboring node with index [II] contains.

[0161] - then calculates the root hash code RH2 based on the hash code that the target leaf node with index [II] will contain hash codes that the nodes linked to the target leaf node will contain, here only the node with index

[112] , and the Merkle proof which here contains the hash code that the neighboring node with index I

[134] contains.

[0162] At an S32 step, the SPROC processor saves the new root hash code in SMEM memory by means of a command of the type:

[0163] set RHm=RH2

[0164] At an S34 step, the SMEM memory confirms that the root hash code has been recorded by sending an "OK" message.

[0165] At step S36, the SPROC processor sends the new data along with its index to the user entity USR:

[0166] (

[12] , "user=alice")

[0167] At step S38, the user entity USR requests the AMP program to save the new data at the target index location

[12] , by sending it a command of the type:

[0168] set data([I2], "user=alice")

[0169] At an S40 step, the ADB database management AMP program confirms the registration by returning an "OK" message.

[0170] At step S42, the user entity USR requests the TMP program to update the Merkle tree in the ADB database, by sending it a command of the type:

[0171] update merkletree(

[12] , "user=alice")

[0172] This step is carried out by the TMP program of the DPROC processor in a manner similar to that of step S30 carried out by the secure processor, except that the TMP program here modifies the actual data that are in the Merkle tree stored in the TDB database of the DMEM memory, and not just the data that will be assumed to be there. After this step, the Merkle tree stored in the TDB database therefore contains the values ​​shown in [Fig. 8].

[0173] At step S44, the TMP program confirms the tree update by returning an "OK" message.

[0174] In [Fig. 13], the ADB database has been modified again. Location [II] still contains the data "user=bob", but in location

[12] , the data "user=alice" has been replaced by the data "user=eve". Furthermore, locations

[13] and

[14] remain empty (0). In the TDB database, the index leaf node [II] contains an H1 hash code equal to the digest By the SHA256 function of the data "user=bob", the index leaf node

[12] contains an H2 hash code equal to the SHA256 hash code of the data "user=eve", while the index leaf nodes

[13] and

[14] conventionally contain H3 and H4 hash codes. At the next level of the Merkle tree, the index leaf node

[112] contains an H12 hash code equal to the SHA256 hash code of the concatenation of the H1 and H2 hash codes, and the index leaf node

[134] contains a hash code equal to the SHA256 hash code of the concatenation of the H3 and H4 hash codes. At the top of the tree, the top node TN contains a root hash code RH equal to the SHA256 function digest of the concatenation of the hash codes H12, H34.

[0175] Figures 14A, 14B describe steps executed by the system in [Fig.9] to replace the data "user=alice" with the data "user=eve".

[0176] At step S50, the user entity USR requests the AMP program to provide it with the data present at index location

[12] , by sending it a command of the type:

[0177] get data([I2])

[0178] At step S52, the AMP program provides the user entity USR with the data "user=alice" at index

[12] :

[0179] ([I2],"user=alice")

[0180] At step S54, the user entity USR requests the TMP program to provide it with the Merkle proof for the index location (

[12] containing the data "user=alice", by sending it a command of the type:

[0181] GetMP([I2])

[0182] At step S56, the TMP program provides the Merkle proof to the user entity. This consists, as before, of the hash codes present in nodes [II] and

[134] :

[0183] MP=[

[0184] Nodell=9fe0adl7617f7c7dada0b94bl6fa2ee009f9b61fcl95a3f6aea9448de532145a

[0185] Node I34=f5a5fd42dl6a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b,

[0186] At step S58, the user entity requests the SPROC processor to modify the data "user=alice" and provides it with the data, its index

[12] and the corresponding Merkel proof, by sending it a command of the type:

[0187] modify data([I2], "user=alice", MP)

[0188] At step S60, the SPROC processor calculates the root hash code RH1 that the Merkle tree is assumed to contain from the Merkel proof MP and the data "user=alice":

[0189] RHl=b0280d3d756c53e0a69333103cb5d456db3459bbdab4d6cl4e986fa677574249

[0190] To this end, the SPROC processor applies the same method as that described above in relation to step S20, with here the hash code of the target leaf node of index

[12] equal to H(user=alice).

[0191] At an S62 step, the SPROC processor requests the SMEM memory to communicate the root hash code RHm by sending it a command of the type:

[0192] getRHm

[0193] At an S64 step, the SMEM memory provides it with the stored root hash code RHm:

[0194] RHm=b0280d3d756c53e0a69333103cb5d456db3459bbdab4d6cl4e986fa677574249

[0195] At an S66 step, the SPROC processor determines if RH1 is equal to RHm, if not the SPROC processor returns an error message to the user entity USR, otherwise continues to execute the command.

[0196] At step S68, the SPROC processor modifies the data:

[0197] user=eve

[0198] At step S70, the SPROC processor calculates the root hash code RH2 that the Merkle tree will contain when the ADB database has been updated with the data user=eve at index location 112], and the TDB database has been synchronized with the ADB database:

[0199] ab2d731487f9c5ddl2ba0d58c6698fe7ecl675ca62a2cdd6c94d8ee2c7aff359

[0200] To this end, the SPROC processor applies the same method as that described above in relation to step S30, with here the hash code of the target leaf node of index

[12] equal to H(user=eve).

[0201] At step S72, the SPROC processor saves the new root hash code in SMEM memory, using a command of the type:

[0202] set RHm=RH2

[0203] At an S74 step, the memory confirms the recording of the root hash code by returning an "OK" message.

[0204] At an S76 step, the SPROC processor sends the modified data (

[12] , "user=eve") to the user entity USR.

[0205] At step S78, the user entity USR requests the AMP program to save the modified data by sending it a command of the type:

[0206] set data([I2], “user=eve”)

[0207] At an S80 step, the AMP program confirms the recording of the data by returning an "OK" message.

[0208] At step S82, the user entity USR requests the TMP program to update the Merkle tree based on the new data, by sending it a command of the type:

[0209] update merkletree([I2], "user=eve")

[0210] After this step, conducted as in step S42, the Merkle tree contains the values ​​shown in [Fig. 13].

[0211] At an S84 step, the TMP program confirms the update of the Merkle tree by returning an "OK" message.

[0212] Although the preceding description is based on simplified examples of Merkle trees, embodiments of the invention that can be implemented use a very large Merkle tree. For example, a Merkle tree with 256 levels contains 2256 leaf nodes, which allows for a corresponding database with 2256 data locations, i.e., a virtually infinite number of locations, each of which can hold a block of data.

[0213] Moreover, the size of each location can be variable and each location can receive all kinds of data, data blocks or "objects" of different sizes, since the hash function used always provides hash codes of the same size (256 bits with SHA256).

[0214] In practice, managing a very large Merkle tree requires few computational resources when it is mostly empty and therefore contains a very large number of leaf nodes with the empty node hash code H(0) equal to 0, as well as a large number of parent nodes with an empty node hash code H(0) equal to 0 according to the convention illustrated in [Fig. 3] or 4, or a hash code always having the same value such as H(0l 0) according to the convention illustrated in [Fig. 4]. In this case, it is not necessary to calculate the hash code contained in each of these nodes since its value is predetermined. A simplified management of the Merkle tree therefore consists of storing, for each level of the Merkle tree, the hash code assigned to the parent nodes of two nodes receiving the empty node hash code, since the latter is invariable.With regard to the parent nodes of a child node receiving a non-zero hash code and of a child node receiving the hash code of an empty node, it suffices, for example if the convention illustrated in [Fig.3] is retained, to copy the value of the non-zero hash code of the first child node and to add a bit equal to 0 or to 1 depending on whether the second child node is to the right or to the left of the first child node.

[0215] The fact that the ADB database can be very large does not affect its security in any way because the root hash code is a cryptographic proof of the authenticity of the entire database, regardless of its size, and guarantees that there is no way to reverse the change. Indeed, modifying a single bit of any data in the database causes a change in the root hash code.

[0216] In summary, two different applications of a sparse Merkle tree have been described above. In the application illustrated in [Fig. 1], the secure processor SPROC is "at the service" of the DMEM memory space and the DPROC processor which manages the AMP and TMP databases, in that the secure processor SPROC allows the DPROC processor to validate data read or write operations in the AMP database, the data being provided externally by the user entity USR.

[0217] In the application illustrated in [Fig.9], which can notably be implemented with an HSM as a secure SPROC processor, the DMEM memory space and the DPROC processor are instead "at the service" of the secure processor which executes the SAP application, by which it is required to generate or modify a large amount of data, the DMEM memory space forming in this case an extension of the secure processor's own SMEM memory.

[0218] Both applications implement identical or similar security mechanisms, including:

[0219] i) the fact that the root hash code of the Merkle tree is stored in secure memory,

[0220] ii) the fact that each reading of a data item or simultaneous reading of a plurality of data items in the database is validated only after recalculating the corresponding root hash code RH1 from a Merkel proof extracted from the ADB database, and verifying that this corresponds to the stored root hash code RHm,

[0221] iii) the fact that each writing of a new data or simultaneous writing of a plurality of new data into the database is validated only after first verifying, by applying the method mentioned in point ii), that the initial data in the database are valid, and after recalculating the corresponding root hash code RH2 from the Merkle proof (the same as that used in point ii) and storing the root hash code RH2 in secure memory in place of the old value RHm.

[0222] The process according to this disclosure offers the advantage of enabling the implementation of unlimited storage in size and number of data, data being able to consist of a data block or a file, without compromising security compared to internal storage in an HSM.

[0223] Another advantage of the method over methods based on monotone counters is the trivial and instantaneous verification of the synchronization of the root hash code RHm held by the secure processor with that of the Merkel tree stored in external memory space. Conversely, when the data to be stored are Each associated with a monotonic counter, the validity of the data must be checked one after the other by communicating them to the secure processor.

[0224] Yet another advantage of the method is that it is easy to ensure the integrity of the entire external database without involving the secure processor. This simply requires recalculating each node of the Merkel tree and then verifying that the same root hash code is found. This verification can be performed by the DPROC processor without involving the secure processor, which is not possible with monotonic counter-based methods, which require sending each piece of data to the secure processor so that it can verify its signature using its private key. These advantages make it possible to implement database monitoring solutions and to be alerted as quickly as possible in the event of data corruption in the external database, without involving the secure processor.It is therefore possible to detect an error in data within the ADB database without waiting for the secure processor to need that data, which would lead to detecting the error too late.

[0225] It will be readily apparent to those skilled in the art that the method just described is susceptible to numerous variations. The method can be implemented with any known type of database, including a key-value database or a relational database (SQL database). Although it has been stated above that the method involves two databases, ADB and TDB, the notion of "two databases" should be understood in a broad sense. Indeed, in practice, the TDB database of the Merkle tree and the ADB database of the application data can take the form of two different tables within the same database.

[0226] Also, although it has been stated above that each location in the ADB database corresponds to a leaf node in the Merkle tree, the use of a dynamic lookup table could be provided whereby locations in the ADB database are not initially linked to leaf nodes in the TDB database, this link being created dynamically as needed. In this case, each location in the ADB database is not systematically associated with a leaf node in the Merkle tree, but can be associated with a leaf node when necessary. In this case as well, the empty node hash code H(0) could be assigned to leaf nodes not assigned to a location in the ADB database, in addition to being assigned to leaf nodes assigned to an empty location in the ADB database or to a location that has been deleted.

[0227] In certain applications, the same Merkle tree can be used to secure several databases or several different tables of the same database. data, with each table or database, for example, being assigned to a specific person. In this case, viewed from the perspective of one of these databases, the number of leaf nodes in the Merkle tree can be much greater than the number of database locations. Conversely, a Merkle tree with fewer leaf nodes than the number of locations in the ADB database could be expected if the database contains a mix of sensitive and non-sensitive data. In this case, only the locations receiving sensitive data are associated with leaf nodes in the Merkle tree. Ultimately, it is clear from these various examples that the number of leaf nodes in the Merkle tree does not necessarily correspond to the number of locations in the database or in a database that uses this Merkle tree to secure the data it contains.

[0228] Similarly, the "erased" character of a location in the ADB database can vary depending on the database type and the conventions used. This "erased" character can be expressed by the absence of an index for that location in the ADB database and in this case does not correspond to any binary value, even if in practice the corresponding data block may contain data. In this case, the DPROC processor provides only the empty node hash code H(0) and the Merkle proof to the SPROC secure processor in response to a read request. In other embodiments, the erased character can be expressed by the presence of a bit or flag set to 1 or 0 in the data. In this case, the data can be provided to the SPROC processor along with the Merkle proof. The SPROC secure processor infers from examining the flag that it is erased data, hence the corresponding leaf node receives the empty node hash code.

[0229] Finally, as previously stated, the fact that each leaf node receives a hash code of the data present in the location (LO) to which it is associated, or an empty node hash code (H(0)), does not mean that all the data blocks that form the TDB database contain hash codes. As indicated above, since the empty node hash code is known by convention, as are the codes resulting from its propagation through the Merkle tree, it is not necessary to populate the TDB database with these values ​​and occupy memory space unnecessarily. It suffices to store the hash code values ​​once, as they are invariable for each level of the Merkle tree, and the TMP program for managing the Merkle tree uses these predefined values ​​when needed to provide the Merkle proof.

[0230] The method just described is also susceptible to numerous applications. In one application, it allows for the implementation of HSM-based management of data assigned to crypto-asset accounts. This data may include usernames, user addresses, various data relating to these users (photos, scanned identity documents, etc.), the rights of these users on crypto-asset accounts and / or, in the context of a shared management of crypto-asset accounts, the statuses of these users with regard to such crypto-asset accounts (administrator, account manager, account holder, etc.), the secret keys of such crypto-asset accounts, etc.

Claims

1. Demands A method for securing data stored in a non-volatile memory space (DMEM), characterized in that it comprises the steps of: - to provide in the non-volatile memory space a first indexed database (ADB) and to store the data in the first database, the first database comprising a plurality of locations (LO) each identifiable by an index, each location being able to receive a data item, - provide in the non-volatile memory space a second indexed database (TDB) associated with the first database (ADB) and configured to form a sparse Merkle tree comprising leaf nodes (LN) and internal nodes (IN) extending over a plurality of levels of the tree up to a top node (TN), each location (LO) of the first database being associated with a leaf node, each leaf node receiving a hash code (Hi) of the data (DTi) present in the location to which it is associated or an empty node hash code (H(0)), each higher-level node receiving a hash code based on the hash codes present in two previous level nodes, up to the top node, the top node comprising a root hash code (RH), - After each update of the first database (ADB), update the Merkle tree in the second database (TDB) so that its current state reflects the current state of the first database. - store in secure non-volatile memory (SMEM) a root hash code (RHm) of the Merkle tree representing the current state of the second database (TDB), and when data needs to be read from the first database: - read the data from the first database, - calculate (H02) a first root hash code (RH1) of the Merkle tree based on the current state of the second database, and - compare (H03) the first root hash code (RH1) to a root hash code (RHm) stored in secure non-volatile memory (SMEM), the data being valid if the first root hash code is equal to the stored root hash code.

2. A method according to claim 1, comprising, when data is to be stored in a target location of the first database, the steps of: - calculating (H12) the first root hash code (RH1) of the Merkle tree based on the current state of the second database, and - comparing (H13) the first root hash code to the root hash code (RHm) stored in secure non-volatile memory, and - if the first root hash code is identical to the stored root hash code: - calculating (H14) a second root hash code (RH2) based on the state of the second database after the new data has been recorded in the first database and the second database has been updated, - storing (H14) the second root hash code in secure non-volatile memory, replacing the previously stored root hash code (RHm),- Update (DI5) the first database with the new data, and - update (DI5) the Merkle tree in the second database.

3. A method according to claim 2, wherein the step of calculating the first root hash code of the Merkle tree based on the current state of the second database comprises the steps of: - reading (D03, D13) data contained in the target location or determining that the location is empty, - identifying a target leaf node associated with the target location, - identifying nodes connected to the target leaf node, the connected nodes being on a path connecting the target leaf node to the top node, - extracting (D03, D13) from the second database a Merkle Proof (MP) of the target leaf node, the Merkle Proof (MP) comprising hash codes contained in nodes neighboring the connected nodes, - calculating or determining (H03, H13) a hash code that the target leaf node is assumed to contain, - based on the hash code that the target leaf node is assumed to contain and the Merkle proof (MP) extracted from the second database, calculate or determine (H03, H13) hash codes that the nodes linked to the target leaf node are assumed to contain, and - calculate or determine (H03, H13) the first root hash code (RH1) based on the hash code that the target leaf node is assumed to contain, the Merkle proof (MP) extracted from the second database, and the hash codes that the nodes linked to the target leaf node are assumed to contain.

4. A method according to any one of claims 2 and 3, wherein the step (H 14) of calculating the second root hash code (RH2) based on the state of the second database after recording the new data in the first database and updating the second database, comprises the steps of: - on the basis of the new data, calculating or determining (H 14) a new hash code that the target leaf node will contain, - on the basis of the new hash code that the target leaf node will contain and the Merkle proof (MP) extracted from the second database, calculating or determining (H 14) new hash codes that the nodes linked to the target leaf node are assumed to contain, and - calculating or determining the second root hash code (H 14) on the basis of the new hash code that the target leaf node will contain, and the Merkle proof (MP) extracted from the second database.and new hash codes that the nodes linked to the target leaf node are supposed to contain.

5. A method according to any one of claims 1 to 4, wherein: - an empty leaf node is a node associated with an empty location in the database, and - an empty leaf node conventionally contains an empty node hash code (H(0)) of predetermined value.

6. Method according to claim 5, wherein the empty node hash code (H(0)) is equal to zero.

7. A method according to any one of claims 5 and 6, wherein a parent node of two empty nodes is an empty node conventionally containing the empty node hash code (H(0)).

8. A method according to any one of claims 5 to 7, wherein a parent node of an empty node and a non-empty node conventionally contains a hash code present in the non-empty node followed by a bit equal to 0 or 1 depending on whether the empty leaf node is in the Merkle tree to the right or left of the non-empty leaf node, or vice versa.

9. A method according to any one of claims 7 and 8, wherein a parent node of two empty leaf nodes conventionally contains a hash code equal to the result of hashing the concatenation of the empty node hash codes contained by each of the two empty leaf nodes.

10. A method according to any one of claims 1 to 9, wherein only the root hash code is stored in secure non-volatile memory, and no data from the first or second database.

11. A method according to any one of claims 1 to 10, wherein at least all hash codes contained in non-empty nodes of the Merkle tree are stored in the second database.

12. A method according to any one of claims 1 to 11, comprising the steps of: - providing at least one first processor (APROC) to manage the first (ADB) and second (TDB) database, and - providing a second secure-type processor (SPROC) to manage the secure non-volatile memory (SMEM).

13. Method according to claim 12, wherein the steps (H02, H12) of calculating the first root hash code (RH1) and comparing (H02, H13) the first root hash code (RHm) to the root hash code stored in the secure non-volatile memory are executed by means of the second processor (SMEM).

14. A method according to claim 13, wherein when new data (DTi, DTj) is to be stored in a target location of the first database, the second processor (SPROC) is provided by means of the first processor (DPROC) with an index of the target leaf node corresponding to the target location, data (DTi) contained in that location or an indication that the location is empty, and the corresponding Merkle proof (MP).

15. Data storage system comprising: - a non-volatile memory space comprising: - a first indexed database (ADB) in which the data is stored, the first database comprising a plurality of locations (LO) each identifiable by an index, each location being able to receive a data item, - a second indexed database (TDB) associated with the first database and configured to form a sparse Merkle tree comprising leaf nodes (LN) and internal nodes (IN) extending over a plurality of levels of the tree up to a top node, each location (LO) of the first database being associated with a leaf node, each leaf node receiving a hash code (Hi) of the data (DTi) present in the location to which it is associated or an empty node hash code (H(0)), each higher-level node receiving a hash code based on the hash codes present in two preceding level nodes, up to the top node, the top node comprising a root hash code,- a secure non-volatile memory, in which is stored a root hash code of the Merkle tree representative of the current state of the second database, the system being configured to, after each update of the first database (ADB), update the Merkle tree in the second database (TDB) so that its current state reflects the current state of the first database, and when data needs to be read from the first database, to: - read the data from the first database, - calculate (H02) a first root hash code (RH1) of the Merkle tree based on the current state of the second database, and - compare (H03, H13) the first root hash code (RH1) to a root hash code (RHm) stored in the secure non-volatile memory (SMEM), the data being valid if the first root hash code is equal to the stored root hash code.

16. A system according to claim 15, configured to, when data is to be stored in a target location of the first database: - calculate the first root hash code (RH1) of the Merkle tree based on the current state of the second database, and - compare the first root hash code to the root hash code (RHm) stored in secure non-volatile memory, and - if the first root hash code is identical to the stored root hash code: - calculate (H14) a second root hash code (RH2) based on the state in which the second database will be after recording the new data in the first database and updating the second database, - store (H14) the second root hash code in secure non-volatile memory, replacing the previously stored root hash code (RHm), - update the first database with the new data, and - update the Merkle tree in the second database.

17. A system according to claim 16, configured to perform the calculation step of the first root hash code of the Merkle tree based on the current state of the second database as follows: - read (D03, D13) data contained in the target location or determine that the location is empty, - identify a target leaf node associated with the target location, - identify nodes connected to the target leaf node, the connected nodes being on a path connecting the target leaf node to the top node, - extract (D03, D13) from the second database a Merkle Proof (MP) of the target leaf node, the Merkle Proof (MP) comprising hash codes contained in nodes neighboring the connected nodes, - calculate or determine (H03, H13) a hash code that the target leaf node is assumed to contain,- Based on the hash code assumed to be present in the target leaf node and the Merkle proof (MP) extracted from the second database, calculate or determine (H03, H13) the hash codes assumed to be present in the nodes linked to the target leaf node; - Calculate or determine (H03, H13) the first root hash code (RH1) based on the hash code assumed to be present in the target leaf node, the Merkle proof (MP) extracted from the second database, and the hash codes assumed to be present in the nodes linked to the target leaf node.

18. A system according to any one of claims 16 and 17, configured to perform the calculation step of the second root hash code based on the state of the second database after the new data has been recorded in the first database and the second database updated, as follows: - based on the new data, calculate or determine (H 14) a new hash code that the target leaf node will contain, - based on the new hash code that the target leaf node will contain and the Merkle proof (MP) extracted from the second database, calculate or determine (H 14) new hash codes that the nodes linked to the target leaf node are assumed to contain, and - calculate or determine the second root hash code (H 14) based on the new hash code that the target leaf node will contain and the Merkle proof (MP) extracted from the second database.and new hash codes that the nodes linked to the target leaf node are supposed to contain...

19. A system according to any one of claims 15 to 18, wherein the secure non-volatile memory stores only the root hash code and no data from the first or second database.

20. A system according to any one of claims 15 to 19, wherein the second database stores at least all the hash codes contained in non-empty nodes of the Merkle tree.

21. A system according to any one of claims 15 to 20, comprising: - at least one first processor (DPROC) for managing the first and second databases, - a second processor (SPROC) of the secure type for managing the secure non-volatile memory, the secure non-volatile memory not being accessible for reading or writing to the first processor.

22. System according to claim 21, configured to execute by means of the second processor (SPROC) the steps of calculating the first root hash code of the Merkle tree based on the current state of the second database, and of comparing the first root hash code to the root hash code stored in the secure non-volatile memory.

23. A system according to claim 22, configured so that, when new data needs to be stored in a target location of the first database, the first processor provides to the attention of the second processor an index of the target leaf node corresponding to the target location, data contained in that location or an indication that the location is empty, and the corresponding Merkle proof (MP).

24. A system according to any one of claims 15 to 23, comprising a user entity (USR) operationally interposed between the first and second processors, the data provided by the second processor to the first processor being received by the user entity which provides it to the first processor.

Images