Method for executing an application program using a hardware security module equipped with secure memory.
The use of a sparse Merkle tree structure in HSMs with secure processors addresses memory limitations and replay attacks by verifying hash codes, ensuring robust data security and efficient memory utilization.
Patent Information
- Authority / Receiving Office
- FR · FR
- Patent Type
- Patents
- Current Assignee / Owner
- LEDGER
- Filing Date
- 2024-07-08
- Publication Date
- 2026-06-26
Abstract
Description
Title of the invention: Method for executing an application program using a hardware security module equipped with secure memory. technical field
[0001] The present invention 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 also 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. Background
[0002] 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.
[0003] 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.
[0004] 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 is 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 take advantage of the high storage capacity of mass storage systems while ensuring that data remains secure. In practice, this means that sensitive data is encrypted before being written to mass storage. The HSM generates, stores, and manages encryption keys securely, ensuring that even if an attacker manages to access mass storage, the data remains unreadable without the appropriate keys.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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 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 operation or transaction that results in the modification of data. Thus, when a When data is recorded 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 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, enabling the detection of any alteration or attempt to reread outdated data.
[0009] 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.
[0010] 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.
[0011] 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 for the creation and modification by the hardware security module of a large amount of data that cannot be stored in its secure memory. Summary
[0012] Embodiments relate to a method for executing an application program using a secure processor equipped with secure non-volatile memory, the execution of the application program comprising steps of creation and modification by the secure processor of data necessary for the execution of the application program, the method comprising the steps of: providing a non-volatile memory space having sufficient storage capacity to store the data necessary for the execution of the application program; 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 data;provide in the non-volatile memory space a second 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 able to be associated with a leaf node, each leaf node receiving a hash code from the; data present in the location to which it is associated or an empty node hash code), each higher-level node receiving a hash code calculated from the concatenation of the hash codes present in two previous-level nodes, up to the top node, the top node comprising a root hash code; provide at least one management processor to manage the first and second databases; by means of the management processor, read from the first database or store in the first database data created or modified by the secure processor, and update the second database after each modification of the contents of the first database, so that its current state reflects the current state of the first database;using the secure processor, calculate or determine and then store in secure non-volatile memory a root hash code of the Merkle tree representative of the current state of the second database, and update the stored root hash code before or after each recording of at least one new data item in the first database by the management processor.
[0013] According to one embodiment, the method comprises, when data is read by the management processor in a target location of the first database, the steps of: using the management processor, providing the secure processor with the Merkle proof of a target leaf node associated with the target location, and, using the secure processor: calculating or determining a first root hash code of the Merkle tree based on the current state of the second database; comparing the first root hash code to the root hash code stored in the secure non-volatile memory, and considering the data as valid if the first root hash code is equal to the stored root hash code.
[0014] According to one embodiment, the method comprises, when at least one new piece of data is to be generated by the secure processor and then stored in a target location of the first database, the steps of: using the management processor, providing the secure processor with the Merkle proof of a target leaf node associated with the target location, and data located in the target location or an indication that the location is empty; using the secure processor: calculating or determining a 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; if the first root hash code is identical to the stored root hash code: generating the new data;calculate or determine a second root hash code of the Merkle tree 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, and store the second root hash code; in secure non-volatile memory, replacing the previously stored root hash code, and, using the management processor, update the first and second databases based on the new data.
[0015] According to one embodiment, the calculation or determination by the secure processor of the second root hash code comprises the steps of: identifying nodes linked to the target leaf node, the linked nodes being on a path connecting the target leaf node to the top node, 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, calculating or determining hash codes that the nodes linked to the target leaf node will contain; 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 and the new hash codes that the nodes linked to the target leaf node will contain.
[0016] According to one embodiment, the calculation or determination by the secure processor of the first root hash code includes the steps of identifying nodes linked to the target leaf node, the linked nodes being on a path connecting the target leaf node to the top node; calculating or determining a hash code that the target leaf node is assumed to contain; on the basis of the hash code that the target leaf node is assumed to contain and the Merkle proof, calculating or determining hash codes that nodes linked to the target leaf node are assumed to contain; calculating or determining the first root hash code on the basis of the hash code that the target leaf node is assumed to contain, the Merkle proof and the hash codes that the nodes linked to the target leaf node are assumed to contain.
[0017] 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.
[0018] According to one embodiment, the empty node hash code) is equal to zero.
[0019] According to one embodiment, a parent node of two empty nodes is an empty node containing by convention the empty node hash code).
[0020] 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.
[0021] 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.
[0022] According to one embodiment, the secure processor stores only the root hash code in the secure non-volatile memory, and no other data from the first or second database.
[0023] According to one embodiment, the management processor stores in the second database at least all the hash codes contained in non-empty nodes of the Merkle tree.
[0024] According to one embodiment, the method includes providing a user entity operationally interposed between the management processor and the secure processor, and the steps of, by means of the user entity, receiving data provided by the management processor and transferring it to the secure processor, or receiving data provided by the secure processor and transferring it to the management processor.
[0025] According to one embodiment, the data are data assigned to holders of crypto-asset accounts.
[0026] Embodiments also relate to a secure system comprising a hardware security module equipped with secure memory and configured to execute at least one application program, wherein the execution of the application program includes steps of creation and modification by the hardware security module of data necessary for the execution of the application program, the system comprising a non-volatile memory space comprising a first indexed database comprising a plurality of locations each identifiable by an index, each location being able to receive data, and a second 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 able to be associated with a leaf node,Each leaf node receives 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 receives a hash code calculated from the concatenation of the hash codes present in two preceding nodes, up to the apex node. The apex node includes a root hash code. At least one management processor is required to manage the first and second databases. The management processor is configured to read from or store in the first database data created or modified by the hardware security module, and to update the second database after each modification of the contents of the first database.so that its current state reflects the current state of the first database. The hardware security module is configured to calculate or determine and then store in secure non-volatile memory a code of , root hash of the Merkle tree representative of the current state of the second database, and update the root hash code stored before or after each record of at least one new data item in the first database by the management processor.
[0027] According to one embodiment, 15, when data is read by the management processor into a target location of the first database, the management processor is configured to provide the hardware security module with the Merkle proof of a target leaf node associated with the target location, and the hardware security module is configured to compute or determine a first root hash code of the Merkle tree based on the current state of the second database; compare the first root hash code to the root hash code stored in secure non-volatile memory, and consider the data valid if the first root hash code is equal to the stored root hash code.
[0028] According to one embodiment, when at least one new data item is to be generated by the hardware security module and then stored in a target location of the first database, the management processor is configured to provide the hardware security module with Merkle proof of a target leaf node associated with the target location, and data in the target location or an indication that the location is empty, and the hardware security module is configured to compute or determine 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 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: generate the new data;calculate or determine a second root hash code of the Merkle tree based on the state that the second database will be in after the new data is recorded in the first database and the second database is updated, and store the second root hash code in secure non-volatile memory, replacing the previously stored root hash code, the management processor also being configured to update the first and second databases on the basis of the new data.
[0029] According to one embodiment, to calculate or determine the second root hash code, the hardware security module is configured to identify nodes connected to the target leaf node, the connected nodes being located on a path linking the target leaf node to the top node; 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, calculate or determine hash codes that the nodes connected to the target leaf node will 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, and the new hash codes that the nodes linked to the target leaf node will contain.
[0030] According to one embodiment, to calculate or determine the first root hash code, the hardware security module is configured to identify nodes linked to the target leaf node, the linked nodes being on a path connecting the target leaf node to the top node; calculate or determine a hash code that the target leaf node is assumed to contain; on the basis of the hash code that the target leaf node is assumed to contain and the Merkle proof, calculate or determine hash codes that nodes linked to the target leaf node are assumed to contain; calculate or determine the first root hash code on the basis of the hash code that the target leaf node is assumed to contain, the Merkle proof and the hash codes that the nodes linked to the target leaf node are assumed to contain.
[0031] According to one embodiment, the hardware security module stores only the root hash code in the secure non-volatile memory, and no other data from the first or second database.
[0032] According to one embodiment, the management processor stores in the second database at least all the hash codes contained in non-empty nodes of the Merkle tree.
[0033] According to one embodiment, the system includes a user entity operationally interposed between the management processor and the hardware security module, and in which data provided by the management processor to the secure processor is received by the user entity which provides it to the secure processor and vice versa.
[0034] Embodiments also 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 data; providing in the non-volatile memory space a second indexed database associated with the first database and configured to form a sparse Merkle tree as defined above; 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; providing secure non-volatile memory;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; 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.
[0035] 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;Update the first database with the new data, and update the Merkle tree in the second database.
[0036] 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 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.
[0037] 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 data, 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. Brief description of the drawings
[0038] 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:
[0039] - Fig. 1 shows an example of a data storage system architecture implementing a method of carrying out the process,
[0040] - Figure 2 shows a simplified example of a Merkle tree,
[0041] - Figure 3 shows the assignment of predetermined hash codes to nodes empty leaves and their parent nodes, according to a first convention,
[0042] - Figure 4 shows the assignment of specific hash codes to leaf nodes voids and their parent nodes, according to a second convention,
[0043] - [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,
[0044] - [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,
[0045] - [Fig.7] shows a simplified example of a Merkle tree,
[0046] - [Fig.8] shows the Merkle tree from [Fig.7] after writing a new given,
[0047] - [Fig. 9A] is a sequence diagram showing writing steps of the new data,
[0048] - [Fig.9B] describes steps in the diagram of [Fig.9A],
[0049] - [Fig.10] shows the Merkle tree of [Fig.8] after modification of a data point,
[0050] - [Fig. 1 1 A] is a sequence diagram showing modification steps of the new data, and
[0051] - [Fig.llB] describes steps of the diagram in [Fig.llA]. Detailed description
[0052] 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.
[0053] The system also includes a secure SMEM memory controlled by 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, ensuring that only the SPROC processor can access it. In one embodiment, the secure SPROC processor is a hardware security module or "HSM," and the DPROC processor forms an HDV host device for the hardware security module.
[0054] 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.
[0055] The system also includes a user entity (USR), which is connected to the DPROC processor via an LK2 data link. The user entity (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 data link is preferably a secure HTTPS (Hypertext Transfer Protocol Secure) link. For even greater security, the LK2 link can consist of an encrypted SCP (Secure Channel Protocol) channel based on a Diffie-Hellman key exchange.
[0056] 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 data The aforementioned DTi and the TDB database contain Hi hash codes. The Merkle tree is of the so-called "sparse Merkle Tree" 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 as the "Merkle tree" or simply "tree" in what follows.
[0057] 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.
[0058] The DPROC processor also executes an MDA (Message Dispatch API) interface program which allows the user entity USR, via the LK2 link, to send to the SPROC processor the commands which arrive at it via the PCI or Ethernet LK1 interface. In the SPROC processor, these commands are received by an MPP (Message Processing Program) which transmits them to a SAP (Secure Application Program), both programs being executed by the SPROC processor.
[0059] 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 require it to generate or modify DTi data, or may require, in order to be executed, the generation or modification of DTi data.
[0060] The user entity USR executes a User Application Program (UAP) that requests the secure processor's SAP application program to perform operations that lead the latter, as previously described, 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 via the LK2 link if necessary, or can be modified by the SAP application program using parameters received from the UAP program via the LK2 link. However, in this instance, the data remains the property of the SAP application program with respect to both reading and writing.
[0061] 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 database ADB is encrypted using an encryption key known only to the secure processor. The DMEM memory space is therefore an extension of the SPROC processor's SMEM memory, which is insufficient to hold such data. Specifically, the SMEM memory here does not store any application or contextual DTi data and only receives the root hash code RHm. However, it goes without saying that this memory can contain other sensitive data, including secret keys, which will not be described here.
[0062] 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.
[0063] 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] to
[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] .
[0064] 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), where "H" is 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).
[0065] 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 H2 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, that is, have not received any data, the symbol for an empty location being "0" on [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).
[0066] 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 contains a root hash code 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). The node
[118] or vertex node TN receives the root hash code RH=H(H14IH58)
[0067] 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 I
[78] , 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.
[0068] 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.
[0069] 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:
[0070] H5=FH(0)=0
[0071] H6=FH(DT6)=H(DT6)
[0072] H7=FH(0)=0
[0073] H8=FH(0)=0
[0074] H56=FH(0,H6)=H6IO=H(DT6)IO
[0075] H78=FH(0,0)=0
[0076] H58=FH(H56.0)=H56I1=H(DT6)IOI 1.
[0077] In this notation, the comma indicates that the highest-level function FH is being used. 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 convention adopted, here the FH function. Thus, this term does not only designate the result of hashing a piece of data. In certain cases, such as those just described, it only designates the code conventionally assigned to the node in question.
[0078] 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 I
[78] , is equal to H(0l0), that is, the result of hashing by means of the function H of 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(010). 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.
[0079] 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 database of TDB data without needing to know the hash codes contained in the tree nodes unaffected by this modification. 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.
[0080] More precisely, after modifying a piece of data in the database, calculating a new value for the root hash code simply requires calculating the hash codes contained in the nodes linked LN to the leaf node in question, that is, 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 nodes neighboring these linked nodes, together forming what is commonly called a "Merkle proof" MP.
[0081] 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.
[0082] 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 ABD 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 processor SPROC is able to store
[18] . data that it has just created in empty locations of the ADB database, and first verifying that they are empty, as will be seen later.
[0083] This property of the Merkle tree is exploited here by storing in the SMEM memory of the SPROC secure processor 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 ADB database, that the current root hash code of the Merkle tree is identical to the previously stored RHm. To this end, the ADB database management program AMP is configured to provide, in addition to the value contained by the location in question, the Merkle proof associated with the target location, that is, the Merkle proof of the leaf node associated with that location.
[0084] 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 9A and 9B. 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
[11] ,
[12] ,
[13] ,
[14] .
[0085] In [Fig.7], 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.
[0086] In [Fig. 8], location [II] of the ADB database always contains the data "user=bob", while location
[12] contains the data "user=alice", locations
[13] ,
[14] being again 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", the index leaf node
[12] contains a hash code H2 equal to the SHA256 digest of the data "user=alice", while the index leaf nodes
[13] ,
[14] conventionally contain hash codes H3, H4. At the next level of the Merkle tree, the index leaf node
[112] contains a hash code H12 equal to the digest of the The SHA256 function of the concatenation of the hash codes H1, H2, and the index leaf node
[134] contains a hash code equal to the hash obtained by the SHA256 function of the concatenation of the hash codes H3 and H4. At the top of the Merkle tree, the node TN contains a root hash code RH equal to the hash obtained by the SHA256 function of the concatenation of the hash codes H12, H34.
[0087] Figures 9A and 9B describe steps executed by the system in [Fig. 1] to add the data "user=alice" to the database in the state shown in [Fig. 7], in order to obtain the database in the state shown in [Fig. 8]. The acting entities are:
[0088] - the TMP program for managing the Merkle tree, executed by the processor DPROC,
[0089] - the AMP program for managing the ADB database, executed by the DPROC processor,
[0090] - the user entity USR, executing the user program UAP,
[0091] - the SPROC processor running the SAP secure application program, and
[0092] - SMEM secure memory.
[0093] 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:
[0094] get empty index()
[0095] At a step S12, the AMP program provides the index
[12] to the user entity USR.
[0096] 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:
[0097] GetMP([I2])
[0098] 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] :
[0099] MP=[
[0100] Node II =9fe0ad 17617f7c7dada0b94bl6fa2ee009f9b61fcl95a3f6aea9448de532145a
[0101] Node I34=f5a5fd42dl6a20302798ef6ed309979b43003d2320d9f0e8ea9831a9275 9fb4b
[0102] 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:
[0103] create data([I2], MP)
[0104] 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:
[0105] RHl=2613bb239dd614364de3224ee093a36c436c975al8323308303c34dfb2046e57
[0106] For this purpose, the SPROC processor, by means of the SAP application program:
[0107] - identifies the nodes linked to the target leaf node with index
[12] , here the node with index
[112]
[0108] - 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,
[0109] - 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.
[0110] - 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].
[0111] 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:
[0112] getRHm
[0113] At step S24, the SMEM memory provides the SPROC processor with the stored root hash code RHm:
[0114] RHm=2613bb239dd614364de3224ee093a36c436c975al8323308303c34dfb2046e57
[0115] 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.
[0116] At step S28, the SPROC processor creates the data user=alice
[0117] At an S30 step, 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:
[0118] b0280d3d756c53e0a69333103cb5d456db3459bbdab4d6cl4e986fa677574249
[0119] For this purpose, the SPROC processor, by means of the SAP application program:
[0120] - identifies the nodes linked to the target leaf node with index
[12] , here the node with index
[112]
[0121] - determines a hash code that the empty leaf node at index
[12] will contain, here H(user=alice),
[0122] - 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 index node [II] contains.
[0123] - 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.
[0124] At an S32 step, the SPROC processor saves the new root hash code in SMEM memory by means of a command of the type:
[0125] set RHm=RH2
[0126] At an S34 step, the SMEM memory confirms that the root hash code has been recorded by sending an "OK" message.
[0127] At step S36, the SPROC processor sends the new data along with its index to the user entity USR:
[0128] (
[12] , "user=alice")
[0129] 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:
[0130] set data([I2], "user=alice")
[0131] At an S40 step, the ADB database management AMP program confirms the registration by returning an "OK" message.
[0132] 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:
[0133] update merkletree([I2], "user=alice")
[0134] 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].
[0135] At step S44, the TMP program confirms the tree update by returning an "OK" message.
[0136] In [Fig. 10], 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 SHA256 hash of the data "user=bob", and the index leaf node
[12] contains an H2 hash code equal to the SHA256 hash of the data "user=eve". The data "user=eve" is used, while the index leaf nodes
[13] ,
[14] conventionally contain hash codes H3, H4. 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 hash codes H1, H2, and the index leaf node
[134] contains a hash code equal to the SHA256 digest of the concatenation of the hash codes H3 and H4. At the top of the tree, the top node TN contains a root hash code RH equal to the SHA256 digest of the concatenation of the hash codes H12, H34.
[0137] Figures 1 IA, 1 IB describe steps executed by the system of [Fig.1] to replace the data "user=alice" with the data "user=eve".
[0138] 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:
[0139] get data([I2])
[0140] At step S52, the AMP program provides the user entity USR with the data "user=alice" at index
[12] :
[0141] (
[12] , "user=alice")
[0142] 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:
[0143] GetMP([I2])
[0144] 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] :
[0145] MP=[
[0146] Nodell=9fe0adl7617f7c7dada0b94bl6fa2ee009f9b61fcl95a3f6aea9448de532145a
[0147] Node I34=f5a5fd42dl6a20302798ef6ed309979b43003d2320d9f0e8ea983 la9275 9fb4b,
[0148] 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:
[0149] modify data([I2], "user=alice", MP)
[0150] 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":
[0151] RHl=b0280d3d756c53e0a69333103cb5d456db3459bbdab4d6cl4e986fa677574249
[0152] 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).
[0153] 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:
[0154] getRHm
[0155] At an S64 step, the SMEM memory provides it with the stored root hash code RHm:
[0156] RHm=b0280d3d756c53e0a69333103cb5d456db3459bbdab4d6cl4e986fa677574249
[0157] 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.
[0158] At step S68, the SPROC processor modifies the data:
[0159] "user=eve"
[0160] 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:
[0161] ab2d731487f9c5ddl2ba0d58c6698fe7ecl675ca62a2cdd6c94d8ee2c7aff359
[0162] For this purpose, 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).
[0163] At step S72, the SPROC processor saves the new root hash code in SMEM memory, using a command of the type:
[0164] set RHm=RH2
[0165] At an S74 step, the memory confirms the recording of the root hash code by returning an "OK" message.
[0166] At an S76 step, the SPROC processor sends the modified data (
[12] , "user=eve") to the user entity USR.
[0167] At step S78, the user entity USR requests the AMP program to save the modified data by sending it a command of the type:
[0168] set data([I2], “user=eve”)
[0169] At an S80 step, the AMP program confirms the recording of the data by returning an "OK" message.
[0170] 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:
[0171] update merkletree(
[12] , "user=eve")
[0172] After this step, conducted as in step S42, the Merkle tree contains the values shown in [Fig. 10].
[0173] At an S84 step, the TMP program confirms the update of the Merkle tree by returning an "OK" message.
[0174] 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 256-level Merkle tree 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. Moreover, the size of each location can vary, and each location can hold 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).
[0175] 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.
[0176] 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.
[0177] 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.
[0178] Another advantage of this 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 monotone counter, it is necessary to verify the validity of the data one after the other by communicating them to the secure processor.
[0179] 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.
[0180] 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.
[0181] 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 envisaged 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, 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.
[0182] In certain applications, the same Merkle tree can be used to secure several databases or several different tables within the same database, each table or database being, for example, 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 used if the database contains a mixture of sensitive and non-sensitive data. In this case, only the locations receiving sensitive data are associated with leaf nodes in the Merkle tree.In conclusion, it appears 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.
[0183] 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.
[0184] 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 in the Merkle tree, There is no need to populate the TDB database with these values and unnecessarily occupy memory space. It is sufficient to store the hash code values once, as these values are invariant for each level of the Merkle tree. The TMP program for managing the Merkle tree then uses these predefined values when needed to provide the Merkle proof.
[0185] The method just described is also susceptible to numerous applications. In one application, it allows for the implementation of HSM 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.), these users' rights to crypto-asset accounts and / or, in the context of shared management of crypto-asset accounts, these users' statuses with respect to such crypto-asset accounts (administrator, account manager, account holder, etc.), secret keys to such crypto-asset accounts, etc.
Claims
1. Demands A method for executing an application program using a secure processor (SPROC, HSM) equipped with secure non-volatile memory (SMEM), the execution of the application program comprising steps of creation and modification by the secure processor of data (DTi) necessary for the execution of the application program, a method characterized in that it comprises the steps of: - providing a non-volatile memory space (DMEM) having sufficient storage capacity to store the data necessary for the execution of the application program, - to provide in the non-volatile memory space a first indexed database (ADB) and to store the data in the first database (ADB), the first database comprising a plurality of locations each identifiable by an index, each location being able to receive a data point, - provide in the non-volatile memory space a second database (TDB) associated with the first database (ADB) 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 (TN), each location of the first database (ADB) being able to be associated with a leaf node, each leaf node receiving a hash code of the data present in the location (LO) to which it is associated or an empty node hash code (H(0)), each higher-level node receiving a hash code calculated from the concatenation of the hash codes present in two previous-level nodes, up to the top node, the top node comprising a root hash code (RH), - at least one management processor (DPROC) is required to manage the first and second databases, - using the management processor, read (S52) from the first database (ADB) or store (S38, S78) in the first database the data created or modified by the secure processor, and update (S42, S82) the second database (TDB) after each modification of the content of the first database (ADB), so that its current state reflects the current state of the first database (ADB), - by means of the secure processor, compute or determine (S30, S70) and then store (S32, S72) in secure non-volatile memory (SMEM) a root hash code (RHm) of the Merkle tree representative of the current state of the second database (TDB), and update (S72) the stored root hash code (RHm) before or after each record (S78) of at least one new data item in the first database by the management processor.
2. A method according to claim 1, comprising, when data is read by the management processor into a target location of the first database (ADB), the steps of: - using the management processor, providing (S16, S56) to the secure processor the Merkle proof of a target leaf node associated with the target location, and - using the secure processor: - calculating or determining (S20, S60) a first root hash code (RH1) of the Merkle tree based on the current state of the second database (TDB), - comparing (S26, S66) the first root hash code (RH1) to the root hash code (RHm) stored in the secure non-volatile memory (SMEM), and - considering the data as valid if the first root hash code (RH1) is equal to the stored root hash code (RHm).
3. A method according to claim 2 comprising, where at least one new data item is to be generated by the secure processor and then stored in a target location of the first database (ADB), the steps of: - using the management processor, providing (S16, S56) to the secure processor, the Merkle proof of a target leaf node associated with the target location, and data located in the target location or an indication that the location is empty, - using the secure processor: - calculating or determining (S20, S60) a first root hash code (RH1) of the Merkle tree based on the current state of the second database (TDB), and - compare (S26, S66) the first root hash code (RH1) to the root hash code (RHm) stored in secure non-volatile memory (SMEM), - if the first root hash code (RH1) is identical to the stored root hash code (RHm): - generate (S28, S68) the new data, - calculate or determine (S30, S70) a second root hash code (RH2) of the Merkle tree based on the state of the second database after the new data is recorded in the first database (ADB) and the second database is updated, and - store (S32, S72) the second root hash code (RH2) in secure non-volatile memory (SMEM), replacing the previously stored root hash code (RHm), - using the management processor, update (S38, S78, S42, S82) the first and second databases on the basis of the new data.
4. A method according to claim 3, wherein the calculation or determination (S30, S70) by the secure processor of the second root hash code (RH2) comprises the steps of: - identifying nodes linked to the target leaf node, the linked nodes being on a path connecting the target leaf node to the top node (TN), - 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, calculating or determining hash codes that the nodes linked to the target leaf node will contain, - calculating or determining the second root hash code (RH2) on the basis of the new hash code that the target leaf node will contain, the Merkle proof and the new hash codes that the nodes linked to the target leaf node will contain.
5. A method according to any one of claims 2 to 4, wherein the calculation or determination (S20, S60) by the secure processor of the first root hash code (RH1) comprises the steps of: - identifying nodes linked to the target leaf node, the linked nodes being on a path connecting the target leaf node to the top node, - calculate or determine 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, calculate or determine hash codes that nodes linked to the target leaf node are assumed to contain, - calculate or determine the first root hash code (RH1) based on the hash code that the target leaf node is assumed to contain, the Merkle proof and the hash codes that the nodes linked to the target leaf node are assumed to contain.
6. A method according to any one of claims 1 to 5, 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.
7. Method according to claim 6, wherein the empty node hash code (H(0)) is equal to zero.
8. A method according to any one of claims 6 and 7, wherein a parent node of two empty nodes is an empty node conventionally containing the empty node hash code (H(0)).
9. A method according to any one of claims 6 to 8, 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.
10. A method according to any one of claims 6 and 7, 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.
11. A method according to any one of claims 1 to 10, wherein the secure processor stores only the root hash code in the secure non-volatile memory (SMEM), and no other data from the first or second database (TDB).
12. A method according to any one of claims 1 to 11, wherein the management processor stores in the second database (TDB) at least all hash codes contained in non-empty nodes of the Merkle tree.
13. A method according to any one of claims 1 to 12, comprising providing a user entity (USR) operationally interposed between the management processor and the secure processor, and the steps of, by means of the user entity, receiving data provided by the management processor and transferring it to the secure processor, or receiving data provided by the secure processor and transferring it to the management processor.
14. A method according to any one of claims 1 to 13, wherein the data are data assigned to crypto-asset account holders.
15. A secure system comprising a hardware security module (SPROC, HSM) equipped with secure memory (SMEM) and configured to execute at least one application program, wherein the execution of the application program includes steps of creation and modification by the hardware security module of data (DTi) necessary for the execution of the application program, a system characterized in that it comprises: - a non-volatile memory space (DMEM) comprising: - a first indexed database (ADB) comprising a plurality of locations each identifiable by an index, each location being able to receive data, - a second database (TDB) associated with the first database (ADB) 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 (TN),each location of the first database (ADB) can be associated with a leaf node, each leaf node receiving a hash code of the data present in the location (LO) to which it is associated or an empty node hash code (H(0)), each higher-level node receiving a hash code calculated from the concatenation of the hash codes present in two previous-level nodes, up to the top node (TN), the top node (TN) comprising a root hash code, - at least one management processor (DPROC) to manage the first and second databases,
16.
17. and in which: - The management processor is configured to read (S52) from the first database (ADB) or store (S38, S78) in the first database data created or modified by the hardware security module, and update (S42, S82) the second database (TDB) after each modification of the contents of the first database (ADB), so that its current state reflects the current state of the first database (ADB), - The hardware security module is configured to calculate or determine (S30, S70) and then store (S32, S72) in secure non-volatile memory (SMEM) a root hash code (RHm) of the Merkle tree representative of the current state of the second database, and update (S72) the stored root hash code (RHm) before or after each recording (S78) of at least one new data item in the first database by the management processor. System according to claim 15, wherein, when data is read by the management processor in a target location of the first database (ADB), the management processor is configured to provide (S 16, S56) to the hardware security module the Merkle proof of a target leaf node associated with the target location, and the hardware security module is configured to: - compute or determine (S20, S60) a first root hash code (RH1) of the Merkle tree based on the current state of the second database (TDB), - compare (S26, S66) the first root hash code (RH1) to the root hash code (RHm) stored in secure non-volatile memory (SMEM), and - consider the data valid if the first root hash code (RH1) is equal to the stored root hash code (RHm). System according to claim 16, wherein when at least one new data item is to be generated by the hardware security module and then stored in a target location of the first database (ADB), the management processor is configured to provide (S16, S56) to the hardware security module, the Merkle proof of a target leaf node associated with the target location, and data located in the target location or an indication that the location is empty, and the hardware security module is configured to: - calculate or determine (S20, S60) a first root hash code (RH1) of the Merkle tree based on the current state of the second database (TDB), and - compare (S26, S66) the first root hash code (RH1) to the root hash code (RHm) stored in secure non-volatile memory (SMEM), - if the first root hash code (RH1) is identical to the stored root hash code (RHm): - generate (S28, S68) the new data, - calculate or determine (S30, S70) a second root hash code (RH2) of the Merkle tree based on the state the second database will be in after the new data is written to the first database (ADB) and the second database is updated, and - store (S32, S72) the second code root hashing (RH2) in secure non-volatile memory (SMEM),replacing the previously stored root hash code (RHm), - the management processor is also configured to update (S38, S78, S42, S82) the first and second databases based on the new data.
18. A system according to claim 17, wherein to calculate or determine (S30, S70) the second root hash code (RH2), the hardware security module is configured to: - identify nodes linked to the target leaf node, the linked nodes being on a path connecting the target leaf node to the top node (TN), - 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, calculate or determine hash codes that the nodes linked to the target leaf node will contain, - calculate or determine the second root hash code (RH2) based on the new hash code that the target leaf node will contain, the Merkle proof and the new hash codes that the nodes linked to the target leaf node will contain.
19. A system according to any one of claims 16 to 18, wherein, in order to calculate or determine the first root hash code (RH1), the hardware security module is configured to: - identify nodes linked to the target leaf node, the linked nodes being on a path connecting the target leaf node to the top node, - calculate or determine a hash code that the target leaf node is assumed to contain, - on the basis of the hash code that the target leaf node is assumed to contain and the Merkle proof, calculate or determine hash codes that nodes linked to the target leaf node are assumed to contain, - calculate or determine the first root hash code (RH1) on the basis of the hash code that the target leaf node is assumed to contain, the Merkle proof and the hash codes that the nodes linked to the target leaf node are assumed to contain.
20. A system according to any one of claims 15 to 19, wherein the hardware security module stores only the root hash code in secure non-volatile memory (SMEM), and no other data from the first or second database (TDB).
21. A system according to any one of claims 15 to 19, wherein the management processor stores in the second database (TDB) at least all the hash codes contained in non-empty nodes of the Merkle tree.
22. A system according to any one of claims 15 to 21, comprising a user entity (USR) operationally interposed between the management processor (DPROC) and the hardware security module (SPROC), and wherein data provided by the management processor to the secure processor is received by the user entity which provides it to the secure processor and vice versa.