Method for storing and sharing confidential data between multiple instances of application programs

Abstract

The invention relates to a method for storing and sharing data between instances of application programs, comprising steps of defining a structure (DS1) of data fields (DF1-DF8), defining an encryption key derivation tree structure comprising key derivation paths based on a root node (Nr), defining an association rule whereby each data field is associated with a leaf node and with a derivation path, identifying the derivation path (m / 1 / 1 / 1... m / 1 / 3 / 4) associated with a data field pursuant to the association rule, generating an encryption key (K111-K134) by way of a key derivation function and based on the root encryption key (Kr) and the associated derivation path, encrypting the datum with the encryption key and storing the encrypted datum.

Description

A method for storing and sharing confidential data between multiple instances of application programs.

[0001] The present invention relates to a method of storing and sharing confidential data between one or more instances of one or more application programs executed by one or more application processors, in a system comprising a data storage means.

[0002] Background

[0003] Using symmetric keys to encrypt secret data intended to be shared by multiple entities or individuals is a common technique. In this case, the main problem to be solved is the distribution of asymmetric keys among the participants. Indeed, sharing encrypted secret data belonging to party A with party B requires that the symmetric key associated with the data be communicated to party B without being compromised. Another solution is to store a second version of the secret data in encrypted form with a symmetric encryption key assigned to party B. This latter solution requires encrypting each piece of data for each user and associating a new key with each new user, which implies managing numerous keys and duplicating the encrypted data.

[0004] We are also familiar with decentralized data architectures in which the same encryption key is shared by multiple users, each user possessing the key being able to decrypt and re-encrypt data. With such methods, all users must be contacted before adding a new user and a new encryption key. These methods require significant computing power and large-capacity data storage.

[0005] We are also familiar with key management methods such as PGP ("Pretty Good Privacy"), GPG ("GNU Privacy Guard"), E3Kit (a development library that allows adding end-to-end encryption to applications), and Group Encryption (https: / / eprint.iacr.org / 2007 / 015), which allows multiple participants to communicate securely by sharing a common encryption key and creating data encryption groups. Elliptic Curve Diffie-Hellman (ECDH) is another well-known method that allows two entities, each with a private / public key pair based on elliptic curves, to establish a shared secret.

[0006] PGP, GPG, and ECDH alone cannot support the creation of dynamic user groups. Adding a member requires re-encrypting all the relevant data. E3Kit and Group Encryption rely on complex cryptographic primitives that are unsuitable for embedded applications using a secure processor with limited computing power, such as a secure element, and require significant resources to compute the keys.

[0007] It might therefore be desirable to provide a secret sharing method based on symmetric keys that is suitable for applications embedded in electronic devices with limited computing resources.

[0008] It might be desirable to provide a symmetric key-based data storage and sharing process that emphasizes key sharing and allows, in particular, the creation of an unlimited number of secret keys, the sharing of the same secret key with a list of trusted actors, and the organization of sets of secret keys to allow certain actors to access several secret keys at once.

[0009] Summary

[0010] Embodiments relating to a method for storing and sharing confidential data between one or more instances of one or more application programs executed by one or more application processors, in a system comprising a data storage means, the method comprising the steps of defining a data field structure, defining an encryption key derivation tree structure, the key derivation tree structure comprising a root node, intermediate nodes and leaf nodes to which encryption key derivation paths based on the root node are associated, defining an association rule whereby each data field is associated with a leaf node of the key derivation tree structure and a corresponding derivation path, assigning a root encryption key to the root node, assigning at least one piece of data to a data field of the data field structure,Identify the derivation path associated with the data field according to the association rule, generate a data encryption key using a key derivation function and from the root encryption key and the derivation path associated with the data field, encrypt the data with the encryption key, and store the encrypted data in the data storage medium.

[0011] According to one embodiment, the process includes a preliminary step of classifying the data fields by category according to one or more classification criteria representative of the potential data access needs that the data fields may include, and wherein the association rule is configured so as to associate with data fields of the same category leaf nodes of the key derivation tree having the same parent node.

[0012] According to one embodiment, the method includes a step of configuring the application program, prior to the execution of an instance of an application program, to have the key derivation function, the data field structure, the key derivation tree structure, and the association rule, said configuration of the application program being written into the code of the application program or provided to the instance of the application program by another instance of an application program or during a dynamic configuration step of the application program.

[0013] According to one embodiment, the method includes, before the execution of an instance of an application program intended not to have access to the contents of all data fields, a step of partial configuration of the application program so that it has the key derivation function, a portion of the data field structure, a portion of the key derivation tree structure corresponding to the portion of the data field structure, and the association rule corresponding to the data fields to which the application program may have access, said partial configuration of the application program being able to be written in the code of the secondary application program or provided to the instance of the application program by another instance of an application program or during a dynamic configuration step of the application program.

[0014] According to one embodiment, the process includes the steps of providing a master key, generating the root node encryption key from the master key, basing key derivation paths on the master key, and generating the encryption key associated with a data field from the master key.

[0015] According to one embodiment, the method includes a step of generating, from the master key, an encryption key for the root node of at least one other key derivation tree structure corresponding to another data field structure and another association rule, and encrypting data assigned to data fields of the other data field structure at the request of an application program instance using the other data field structure.

[0016] According to one embodiment, the method is implemented in a system comprising at least one secure processor, the steps of generating the data encryption key and encrypting the data are carried out by the secure processor at the request of an application program instance executed by an application processor, and the step of storing the encrypted data is carried out by an application program instance executed by an application processor.

[0017] According to one embodiment, the method comprises the steps of, by means of an application program instance, sending a command to the secure processor to supply the root encryption key of the key derivation tree, and by means of the secure processor, providing the root encryption key to the application program instance, in an encrypted form decipherable by the application program instance.

[0018] According to one embodiment, the method includes the steps of, by means of an application program instance, addressing to the secure processor a request for access to data in a data field associated with a node of the key derivation tree which may be a leaf node or a parent node, and by means of the secure processor, providing to the application program instance, in an encrypted form decipherable by the application program instance, the encryption key associated with the relevant node of the key derivation tree.

[0019] According to one embodiment, the method comprises the steps of, by means of the secure processor, receiving a public key from the application program, generating an ephemeral private key and an ephemeral public key, generating, from the ephemeral private key and the public key of the application program, an ephemeral Diffie-Hellman encryption key based on an elliptic curve, generating an initialization vector, encrypting the encryption key associated with the node in question by means of an encryption function, the ephemeral Diffie-Hellman encryption key, and the initialization vector, and providing the application program instance with the encryption key associated with the node in question in its encrypted form accompanied by the ephemeral public key and the initialization vector.

[0020] According to one embodiment, the method includes steps consisting of creating, in a data storage means, a trust chain object comprising child and parent command flow blocks linked together in a tree structure identical to that of the key derivation tree, each command flow block forming a node of the trust chain object corresponding to a node of the key derivation tree and comprising descriptive blocks of commands concerning that node having been addressed to the secure processor by application program instances and executed by the secure processor.

[0021] According to one embodiment, the method includes forecasting a node derivation command to create, in the trust chain object, a child command flow block intended to receive descriptive blocks of commands addressed to the secure processor in relation to that node by application program instances, the node derivation command including an identifier of the node targeted by the command, such as the derivation path associated with the node or some other type of identifier.

[0022] According to one embodiment, the execution of the node derivation command includes the steps of, by means of the secure processor, in response to the command and subject to any conditions of acceptance of the command: encrypting the encryption key associated with the node targeted by the command in a manner indecipherable by the application program instance that issued the command; providing the application program instance that issued the command with the encryption key associated with the node targeted by the command in its encrypted form not decipherable by the application program instance, as well as parameters that may allow the secure processor to subsequently decrypt the encryption key associated with the node targeted by the command;by means of the application program instance that issued the command, upon receipt of the response from the secure processor: write in the chain of trust object a command flow block concerning the node targeted by the command, and write a descriptive block of the node derivation command in the command flow block, the descriptive block of the command including the identifier of the node targeted by the command, the encryption key associated with the node targeted by the command, in its encrypted form, and said parameters that may allow the secure processor to subsequently decrypt the encryption key associated with the node targeted by the command.

[0023] According to one embodiment, the execution of the node derivation command also includes the steps of using the secure processor to: generate an ephemeral private key and an ephemeral public key; generate, from the ephemeral private key and the ephemeral public key, an ephemeral Diffie-Hellman encryption key based on an elliptic curve; generate an initialization vector for the encryption key associated with the node targeted by the command; encrypt the encryption key associated with the node targeted by the command using an encryption function, the ephemeral Diffie-Hellman encryption key, and the initialization vector; and provide the application program instance that issued the command, as parameters that allow the secure processor to subsequently decrypt the encryption key associated with the node targeted by the command.the initialization vector and the ephemeral public key used by the secure processor to generate the ephemeral Diffie-Hellman encryption key.

[0024] According to one embodiment, the method includes forecasting a command to access a node of the trust chain object, and wherein the execution of this command includes the steps of, using the secure processor, in response to the command, and subject to any conditions of acceptance of the command: encrypting the encryption key associated with the node targeted by the command in a manner decipherable by the application program instance that issued the command; providing the application program instance that issued the command with the encryption key associated with the node targeted by the command in its encrypted form decipherable by the application program instance, as well as parameters enabling the application program instance to decipher the encryption key associated with the node targeted by the command;by means of the application program instance, upon receipt of the response from the secure processor: write a descriptive block of the node access command in the node command flow block, the descriptive block of the command including an identifier of the node targeted by the command, the encryption key associated with the node targeted by the command, in its encrypted form, and said parameters enabling the application program instance to decrypt the encryption key associated with the node targeted by the command.

[0025] According to one embodiment, the execution of the command to access a node of the chain of trust object includes the steps of using the secure processor to: generate an ephemeral private key and an ephemeral public key; generate, from the ephemeral public key and a public key of the application program instance that issued the command, an ephemeral Diffie-Hellman encryption key based on an elliptic curve; generate an initialization vector for the encryption key associated with the node targeted by the command; encrypt the encryption key associated with the node targeted by the command using an encryption function, the ephemeral Diffie-Hellman encryption key, and the initialization vector; and provide the application program instance that issued the command with parameters enabling the application program instance to decrypt the encryption key associated with the node targeted by the command.the initialization vector and the ephemeral public key used by the secure processor to generate the ephemeral Diffie-Hellman encryption key.

[0026] According to one embodiment, the method includes forecasting a command to create a first command flow block in the trust chain object, and wherein the execution of this command includes the steps of: using the secure processor, in response to the command and subject to any conditions of command acceptability, generating the root encryption key of the key derivation tree from a master key, encrypting the root encryption key in a way that is undecipherable by the application program instance that issued the command, providing the application program instance that issued the command with the root encryption key in its encrypted form that is undecipherable by the application program instance, as well as parameters that may allow the secure processor to subsequently decrypt the root encryption key;using the application program instance, upon receiving the response from the secure processor: write the first command flow block in the trust chain object, and write a command description block in the command flow block, the command description block including the identifier of the node targeted by the command, the root encryption key in its encrypted form, and said parameters that may allow the secure processor to subsequently decrypt the root encryption key.

[0027] According to one embodiment, the execution of the command to create the first command flow block also includes the steps of using the secure processor to: generate an ephemeral private key and an ephemeral public key, generate, from the ephemeral private key and the ephemeral public key, an ephemeral Diffie-Hellman encryption key based on an elliptic curve, generate an initialization vector for the encryption of the root encryption key, encrypt the root encryption key using an encryption function, the ephemeral Diffie-Hellman encryption key, and the initialization vector, and provide the application program instance that issued the command, as parameters that allow the secure processor to subsequently decrypt the root encryption key, with the initialization vector for the encryption of the root encryption key.and the ephemeral public key used by the secure processor for this encryption.

[0028] According to one embodiment, the secure processor is configured to, after generating the Ephemeral Diffie-Hellman encryption key, erase the ephemeral private key from which the Ephemeral Diffie-Hellman encryption key was generated.

[0029] According to one embodiment, each command flow block is signed by the last application program instance that created the block or modified the block by adding a command description block, the signature being generated using a private key of the application program instance and being verifiable by other application program instances using the public key of the signing application program instance.

[0030] According to one embodiment, the process includes the step of providing, in each command flow block, a hash code of all or part of a parent command flow block, such that the trust chain object forms a chain of blocks.

[0031] According to one embodiment, the secure processor is configured to, before the execution of a command, read the entire trust chain object and verify its integrity.

[0032] According to one embodiment, the secure processor is a secure element present in a hardware crypto-asset wallet, an application processor is a processor of a host device of the hardware wallet, and the application program instance is an application executed by the application processor of the host device of the hardware wallet.

[0033] According to one embodiment, the data field structure includes data fields relating to crypto-asset accounts held by a user.

[0034] According to one embodiment, the data field structure includes data field labels written in a text file, data present in a data field is written in its encrypted form in the text file, alongside or in relation to the data field label, and the text file is itself stored in an unencrypted form in the data storage means.

[0035] Brief description of the drawings

[0036] Examples of data storage and sharing methods as described in this disclosure will be outlined below, without limitation, in relation to the attached figures, including:

[0037] - Lamontre is an example of a system in which the process is implemented.

[0038] - lamontre, a step in constructing a key derivation tree for encryption,

[0039] - lamontre, a step in organizing a set of data fields into subsets of juxtaposed or nested data fields,

[0040] - lamontre des chemins derivation assignés aux subsets de champs de données de laen relation à l'arbre derivation de la,

[0041] - lamontre another step in organizing a set of data fields into subsets of juxtaposed or nested data fields,

[0042] - lamontre a step in constructing a key derivation tree for encryption based on the organization of the set of data fields shown on the,

[0043] - lamontre des chemins de derivation de clés de cryptographies quis attribu aux subsets de champs de data en relation à l'arbre derivation de la,

[0044] - lamontre is a method of implementing the system by putting in place a chain of trust object,

[0045] - lamontre provides an example of how to organize data fields present in a JSON file,

[0046] - lamontre a step of assigning encryption keys to subsets of data fields of the,

[0047] - lamontre the JSON file of lasous in encrypted form,

[0048] - lamontre schematically represents the command flow blocks present in the trust chain object of the,

[0049] - la, la, laet lamontrent examples of descriptive command blocks present in command flow blocks of the trust chain object of la,

[0050] - lamontre of the calculation steps involved in the execution of certain commands,

[0051] - lamontre of the deployment steps of a chain of trust object,

[0052] - lamontre of additional deployment steps for the chain of trust object,

[0053] - This is a sequence diagram showing examples of steps for sharing data and managing the trust chain object,

[0054] - describes the steps of the,

[0055] - This is a sequence diagram showing further examples of data sharing steps and trust chain object management, and

[0056] - describes the steps of the.

[0057] Lamontre provides an example of a system in which the data storage and sharing method described in this disclosure is implemented. The system includes electronic devices DV1, DV2, ..., DVn, a secure electronic device SDV, and a data storage medium SRV1, for example, a data server. Each device DV1, DV1, ..., DVn includes an application processor PROC1, PROC2, ..., PROCn configured to run at least one application program AP1, AP2, ..., APn. By means of the method, devices DV1, DV1, ..., DVn store confidential data DTi, ...DTj in the data storage medium SRV1, share it with other devices, or access data stored in the data storage medium SRV1 by other devices. These data DTi,… DTj are stored in encrypted form using a symmetric encryption function ENC, and each data is encrypted with a symmetric encryption key Ki,…Kj which is unique to it.The secure SDV device is equipped with a secure SPROC processor which runs a secure SAP application program through which it controls and supervises access to the encryption keys of the data stored in the SRV1 data storage medium.

[0058] The data storage and sharing process described herein includes aspects related to assigning encryption keys to the data Di,….Dj and generating these keys, as well as aspects related to managing and sharing these keys once they have been generated. The first aspect of the process will be described first.

[0059] The process includes a preliminary step of defining a DS1 data field structure, for example, the structure shown in the illustration, comprising data fields DF1 to DF8. This structure includes as many data fields as there is data to be saved, each data field being designed to receive one piece of data. Each data field is also individually identifiable. In the example shown, each field is identified by an assigned name or label, here DF1, DF2… DF8. In practice, more explicit field labels can be used, for example, as will be seen later with an example, labels such as "last name", "first name", "address", "date of birth", "place of birth", "nationality", etc.

[0060] Once the number of data fields has been defined, a second step in the process is to define a key derivation tree structure for encryption, as illustrated in the figure. The derivation tree includes a root node Nr, intermediate nodes N11, N12, N13, and leaf nodes N111, N112, N121, N122, N131, N132, N133, N134, each linked to intermediate nodes that act as parent nodes. The number of leaf nodes in the tree should preferably be at least equal to the number of data fields in the DS1 data field structure.

[0061] The root node Nr is intended to be assigned a root key Kr when the process is initialized within the system. Above node Nr is represented a master key Km, or seed, from which the root key Kr can be generated instead of being randomly drawn, using an m / x derivation path, where "x" is a variable. The m / 1 derivation path will be chosen as an example and retained throughout the description. Below the root node Nr, each node in the derivation tree is also assigned an encryption key defined by a derivation path. Thus, nodes N11, N12, and N13 are assigned keys K11, K12, and K13 defined by the m / 1 / 1, m / 1 / 2, and m / 1 / 3 derivation paths. Under node N11, nodes N111 and N112 are assigned keys K111 and K112 defined by derivation paths m / 1 / 1 / 1, m / 1 / 1 / 2.Under node N12, nodes N121 and N122 are assigned keys K121 and K122 defined by derivation paths m / 1 / 2 / 1, m / 1 / 2 / 2. Finally, under node N13, nodes N131, N132, N133, N134 are assigned keys K131, K132, K133, K134 defined by derivation paths m / 1 / 3 / 1, m / 1 / 3 / 2, m / 1 / 3 / 3, m / 1 / 3 / 4. Nodes N111, N112, N121, N122, N131, N132, N133, N134, located at the terminals of the derivation tree, will be referred to as "leaf nodes" in what follows.

[0062] Thus, from a given value to the master key Km, an encryption key derived from the key Km can therefore be assigned to each node of the derivation tree, starting with the root key Kr.

[0063] Once the derivation tree is defined, an association rule is established whereby each data field DF1 to DF8 is associated with a leaf node of the derivation tree and the corresponding encryption key. In one embodiment, each data field is arbitrarily assigned to a leaf node of the derivation tree. In an "optimized" embodiment, the data field structure is pre-organized by subdividing it into subgroups of data fields sharing a common characteristic and likely to be read simultaneously by entities within the system. These subgroups may consist of data fields of the same type, complementary data fields, or any other criteria depending on the nature of the data fields and the intended application. For example, "last name" and "first name" fields can be grouped together, as well as "date of birth" and "place of birth" fields, since it is rare for one to be read without the other.

[0064] In the example illustrated on the, we have therefore defined three first subsets S11, S12, S13 of data fields, two subsets S111, S112 of subset S11, two subsets S121, S122 of subset S12, and four subsets S131, S132, S133, S134 of subset S13.

[0065] Data field DF1 is classified in subset S111. Data field DF2 is classified in subset S112. Data field DF3 is classified in subset S121. Data field DF8 is classified in subset S122. Data field DF5 is classified in subset S131. Data field DF6 is classified in subset S132. Data field DF7 is classified in subset S133, and data field DF4 is classified in subset S134. By analogy with the key derivation tree, the subsets S111, S112, S121, S122, S131, S132, S132 and S134 are leaf subsets and the subsets S11, S12, S13 are parent subsets of these leaf subsets.

[0066] Once the data field structure is organized as described above, each data field is associated with a leaf node of the tree, while each subset of data fields, including one or more subsets, is associated with a parent node of the derivation tree. As a result of this association rule between data fields and leaf nodes, an entity wishing to access two data fields attached to the same parent node will not need to request the two corresponding encryption keys. It will only need to know the encryption key associated with the parent node to derive the two encryption keys associated with the child nodes. This optimization reduces the number of encryption key requests by grouping information fields that are typically read together.

[0067] Once the derivation tree and the association rule have been defined, a derivation path assignment table can be drawn up, for example the following table, also shown in the:

[0068] "Name""Path""Value"DF1m / 1 / 1 / 1DF2m / 1 / 1 / 2DF3m / 1 / 2 / 1DF4m / 1 / 3 / 4DF5m / 1 / 3 / 1DF6m / 1 / 3 / 2DF7m / 1 / 3 / 3DF8m / 1 / 2 / 2

[0069] The "Name" column contains the label for each data field. The "Path" column contains the encryption key derivation path assigned to each data field. The "Value" column is initially empty and is intended to contain the data assigned to the data fields after the process is initialized.

[0070] This table, which includes the selected derivation tree, is provided to the designers of the application programs AP1, AP2, ..., APn, who can then hardcode it into the program code. Alternatively, this information lookup table can be provided dynamically to the application programs afterward, during a configuration step, via a secure file transfer, or by any other means. In other embodiments, this table can also be provided to one instance of an application program by another instance of an application program.

[0071] In some embodiments, "secondary" application programs designed to use only certain data from the data field structure may only have access to a portion of this lookup table, specifically the data they are likely to manipulate. As before, this portion of the table may be hard-coded into the code of these programs, provided later during a configuration step, or by another instance of an application program.

[0072] It should be noted that the example of a data field organization model just described is simplified for the sake of clarity in this description. Those skilled in the art will have the necessary latitude to design complex models for managing numerous data fields.

[0073] According to another approach to the process, the organization of the data field structure can be defined before defining the structure of the derivation tree, as illustrated in Figures 3A and 3B. In the example shown, data fields DF1 and DF2 are placed in subsets S11 and S12. Data fields DF3 and DF8 are placed in subsets S131 and S132, which are included in subset S13. Data field DF5 is placed in subset S141, which is itself included in subset S14. Data fields DF4, DF6, and DF7 are placed in subsets S1421, S1422, and S1423, which are themselves included in subset S142, which is itself included in subset S14.

[0074] The derivation tree is then constructed to reflect this organization of the data fields, as shown in Figure 1. Consequently, the leaf nodes associated with the data fields are not necessarily all at the same level in the derivation tree. We thus distinguish leaf nodes N11, N12, N131, N132, N1421, N1422, and N1423. The data fields associated with nodes have derivation paths of varying lengths, as shown in the following table, also shown in Figure 1. The corresponding encryption keys are labeled K11, K12, K131, K132, K1421, K1422, and K1423 in Figure 1.

[0075] Table 2: "Name" "Path" "Value" DF1m / 1 / 1 DF2m / 1 / 2 DF3m / 1 / 3 / 1 DF4m / 1 / 4 / 2 / 1 DF5m / 1 / 4 / 1 DF6m / 1 / 4 / 2 / 2 DF7m / 1 / 4 / 2 / 3 DF8m / 1 / 3 / 2

[0076] Various key derivation algorithms can be used by those skilled in the art to derive different encryption keys from the master key Km. In one embodiment, the standard BIP32 algorithm applied to the secp256k1 elliptic curve can be used. This algorithm allows the derivation of an unlimited number of secrets from a single random secret. The SPROC secure processor first randomly generates a 512-bit number. This number is interpreted as two 256-bit numbers: a private key and a string code. From the private key, the processor can compute a public key using the secp256k1 curve. The string code is another source of entropy for the derivation algorithm. The derivation function can thus be expressed as follows:

[0077] (Kchild, Cchild) = CKDpriv((Kpar, Cpar),i)

[0078] with :

[0079] - Kchild is the private key of the child node,

[0080] - Cchild is the code for the child node's chain,

[0081] - CKDpriv, the algorithm for deriving the key of the child node,

[0082] - Kpar the private key of the parent node,

[0083] - By the chain code of the parent node, and

[0084] - i is an unsigned 32-bit integer called the index.

[0085] This algorithm can be used consecutively with an index list where the result of the last derivation is used as Kpar and Cpar for the next derivation. This index list is here the list of derivation paths of the target key. For example, the path indicating a derivation from the seed Km through index 1 and then index 2 is marked as equal to "m / 1 / 2".

[0086] In one embodiment, the process uses only the hardened derivation portion of the BIP32 standard for security reasons. BIP32 provides two derivation modes, "hardened" and "soft," which have different properties. The "hardened" version allows the publication of a child private key without revealing the parent key.

[0087] Furthermore, as mentioned above, all derivation paths can be hard-coded into application programs, meaning they can be written directly into the code of those programs. The root of the tree containing the Km cryptographic seed can therefore be used to deterministically generate all the secret keys for the branches of the tree.

[0088] The process just described includes an initialization phase where initial data is collected, then encrypted and stored in the data storage medium SRV1. In an example implementation, the first application program instance implementing the process, for example, an instance of the AP1 program executed by the PROC1 processor, requests the SPROC secure processor to provide it with the root key Kr of the tree. The SPROC secure processor then derives the key Kr from the master key Km and provides it to the AP1 application program instance in encrypted form that can only be decrypted by the AP1 instance. After collecting the data from the data fields DF1 to DF8, the AP1 application program instance can calculate, from Kr, and using the BIP32 algorithm and the derivation table (,), the encryption keys that are assigned to these data fields.The instance then encrypts each piece of data with its assigned key and saves the data in its encrypted form in the data storage medium SRV1.

[0089] As an example of implementing the process, we will assume here that another application program instance, for example, an instance of application program AP2, then wishes to access the data in data field DF2. The AP2 instance then sends a request to the secure processor SPROC for access to the leaf node N112() to which the DF2 field is associated. After the secure processor grants the request, the processor transmits the key K112 of this node in encrypted form, which can only be decrypted by the AP2 instance. After decrypting the key K112, the AP2 instance is then able to decrypt the DF2 data field.

[0090] It should be noted here that the so-called "secure processor agreement" may be subject to command acceptance conditions, which must be met. In many cases, these acceptance conditions may include, for example, the requirement that the secure processor seek prior consent from a USR user before executing the command. Until this consent is received, the command is not acceptable; in other words, it cannot be executed. In other embodiments, different rights may be granted to application programs. Some application programs may be able to execute certain commands, while others must receive consent from a user or from another application program with higher rights before the commands, or certain commands, that they send to the secure processor are executed.

[0091] In one embodiment, secure communication of an encryption key to an application program instance is performed using the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) algorithm, for example, based on the secp256k1 elliptic curve. The ECDHE algorithm is a specific implementation of the Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm, in which an ephemeral private key is used to generate a shared encryption key. Once the data is encrypted, the ephemeral private key is not retained, and only the recipient of the encrypted data can decrypt it.

[0092] Within the framework of this process, the ECDHE algorithm can be used in two ways, as will be seen later:

[0093] - to allow the secure SPROC processor to encrypt a data encryption key using a key that only it will then be able to decrypt,

[0094] - to enable the secure SPROC processor to encrypt a data encryption key using a key that only an instance of the application program will then be able to decrypt.

[0095] For this purpose, the secure SAP application program executed by the secure processor is provided with a private key pK1 and a public key PK1, and each application program AP1, AP2…APn is itself provided with a private key pK2 and a public key PK2.

[0096] In one embodiment of the process, when an application program instance requests a child node's encryption key Kj+1 derived from the parent node's key Kj, the application program instance provides the secure processor with its public key PK2. The secure processor SPROC generates a 32-bit ephemeral private key pK1e and then computes a ephemeral public key PK1e from this ephemeral private key pK1 using the secp256k1 function. The secure processor then generates an ECDHE encryption key, denoted Ek, from the application program's ephemeral private key pK1e and public key pK2. The secure processor then generates a 16-byte (128-bit) random initialization vector IV. Finally, the secure processor encrypts the requested encryption key, for example, using the Advanced Encryption Standard (AES) function, the key Ek, and the vector IV.The secure processor then communicates the encrypted key to the application program instance along with the ephemeral public key PK1e and the vector IV. To decrypt the key Kj+1, the application program instance first generates the key Ek using its private key pK2 and the secure processor's ephemeral public key PK1e, using the ECDHE algorithm. The application program instance can then decrypt the key Kj+1 using the AES decryption function. -1 , of the key Ek and of the vector IV.

[0097] The process just described thus makes it possible to generate in a hierarchical and deterministic way encryption keys assigned to data fields which themselves could be grouped in a desired way, the hierarchy of the keys then being in the image of the organization of the data fields chosen.

[0098] In some applications, implementing this process requires addressing application-specific technical issues. One such issue concerns key storage by the secure processor. As discussed above, the secure processor, after generating all the keys in the key derivation tree from a master key (Km), must store them to avoid having to generate them again each time they are needed. However, if different key derivation trees are planned in relation to different data field structures, for unrelated application programs that manipulate different data field structures, the secure processor (SPROC) may end up managing a large number of keys.However, in some applications, the secure processor has only a small amount of secure memory available, as is the case when the secure processor is a secure element or a hardware security module (HSM). Therefore, in such cases, it may be desirable for the secure processor not to clutter its memory with numerous encryption keys belonging to multiple different derivation trees.

[0099] Another issue to consider concerns the consistency control of all operations performed on the nodes of the key derivation tree, including consistency control of access requests to nodes that have been granted to application program instances, and control of the member instances of each node, i.e., those that have received the encryption key of the node.

[0100] Lamontre provides an example of an implementation of the system in which these problems can arise. In this example implementation, the secure SDV device is a hardware crypto-asset wallet (HW, "Hardware Wallet"), for example, a device marketed by the applicant under the name Ledger Stax. TM The hardware wallet (HW) is equipped with a secure element (SE) forming the aforementioned secure processor (SPROC) and possessing limited memory. In this example, devices DV1, DV2, ..., DVn are host devices HD1, HD2, ..., HDn of the hardware wallet (HW), to which they can connect via a wired or wireless connection, such as USB, NFC, or Bluetooth. ® The host device HW1 is, for example, a personal computer, and the host device HW2 is, for example, a mobile phone. The application program AP1 and the application program AP2 can be LedgerLive software. TMmarketed by the applicant, allowing the use of the HW hardware wallet for commissioning, configuration, and transaction processing. In this case, the data associated with the data field structure may relate to crypto-asset accounts.

[0101] In one example of using the method, an application program was initially installed on the host device HD1 as application program AP1, and the user USR provides a number of data points relating to their identity, such as last name, first name, date of birth, country of birth, etc. The instance of application program AP1 must then update a JSON file (a text file saved with the .json extension, which stores structured data in key / value pairs) in which this information is to be recorded. To this end, it encrypts this information individually according to the method just described, writes it in encrypted form to the JSON file, and saves this file in the data storage medium SRV1.

[0102] To illustrate, here is an example of how data fields are organized within this JSON file. Only four data fields are shown for simplicity. The JSON file initially contains the following information: the terms "title", "content", "created_at", "created_by" form the labels of the data fields, also called "keys", while the terms "Note title", "This note is about...", "01-01-2024", "0x3..." are the data stored in these data fields (also called "values" in the key / value approach):

[0103] {

[0104] "title": "Note title",

[0105] "content": "This note is about…",

[0106] "created_at": "01-01-2024",

[0107] "created_by": "0x3....",

[0108] }

[0109] Lamontre shows the organization of the data fields in the JSON file. The key / value pairs {"title": "Note title"} and {"content": "This note is about…"} are placed in subsets S111, S112 of the same subset S11, while the key / value pairs {"created_at": "01-01-2024"} and {"created_by": "0x3...."} are placed in subsets S121, S122 of the same subset S12, because the "title" and "content" keys are often called together when read, as are the "created_at" and "created_by" keys.

[0110] Lamontre shows the architecture of the key derivation tree that results from this organization of the data fields and the association rule chosen. The "title" and "content" fields are associated with nodes N111, N112, children of a node N11 which is itself a child of node Nr, while the "created_at" and "created_by" fields are associated with nodes N121, N122, children of a node N12 which is itself a child of node Nr.

[0111] Thus, as shown in the image, after data encryption using the ENC function, the data "Note title" is encrypted in the JSON file using a K111 key with a derivation path of m / 1 / 1 / 1. The data "This note is about…" is encrypted in the JSON file using a K112 key with a derivation path of m / 1 / 1 / 2. The data "01-01-2024" is encrypted in the JSON file using a K121 key with a derivation path of m / 1 / 2 / 1. Finally, the data "0x3...." is encrypted in the JSON file using a K122 key with a derivation path of m / 1 / 2 / 2.

[0112] We will now assume that an instance of the AP2 program running on the host device HD2 (for example, a mobile phone) wants to retrieve the encrypted data from the JSON file. The AP2 program instance then sends a request to the hardware wallet HW to obtain the root key Kr from the key derivation tree, and receives it with the consent of the user USR. With the key Kr, the AP2 instance is able to calculate all the derived keys and retrieve and decrypt the data from the JSON file, after retrieving it from the storage medium SRV1.

[0113] As mentioned above, in this type of application, it might be desirable to provide implementation methods for the process that allow, in particular:

[0114] - to avoid cluttering the memory of the secure SPROC processor, here the secure SE element, with numerous encryption keys, but without forcing the secure SPROC processor to recalculate the derived keys each time it receives a request to access a given node,

[0115] - to allow the secure processor, without cluttering its memory, to control the consistency of all operations performed on the nodes of the tree, namely the access requests granted and the application programs authorized to access certain nodes, and to verify the legitimacy of the members of a node to be members of that node.

[0116] According to one embodiment of the process illustrated schematically on the, it is provided for this purpose the constitution of a TCO ("Trusted Chain Object") which is stored in an SRV2 data storage medium, for example a server, but could also be stored in the same SRV1 storage medium as the encrypted data.

[0117] The TCO trust chain object is structured as a tree composed of nodes, each node being formed by a CSB (Command Stream Block). Each CSB allows for the secure sharing of one of the keys in the derivation tree implemented by the application program instances. Thus, the TCO trust chain object has the same architecture as the key derivation tree to which it is attached, for example, the one shown here, except that each node in the tree is a CSB.

[0118] Thus, we can distinguish, on the CSB111 and CSB112 command flow blocks, which are children of a CSB11 command flow block, itself a child of a CSBr root block, as well as CSB121 and CSB122 blocks, which are children of a CSB12 block, itself a child of the CSBr root block. Above the CSBr root block, a CSBm master block can be provided in cases where the secure processor is configured to manage multiple key derivation trees associated with different data field structures.

[0119] As shown in the figure, each CSB command stream block can include one or more command descriptor blocks, referenced CMD1…CMDn, which relate to the commands executed by the secure processor. Each CMD command stream block also includes a block signature (SIGN) and a hash code (HC). This can be the hash of the first CSBm block in the command stream block tree, or the hash of all or part of a parent block. Thus, the TCO trust object forms a chain of blocks whose validity can be verified block by block using the SIGN signatures, and globally using the HC hash codes that link the blocks together.

[0120] The SIGN signature can, in one embodiment, be generated using the SHA-256 hashing algorithm followed by a signature of the hash code obtained using the ECDSA (Elliptic Curve Digital Signature Algorithm). The SHA-256 algorithm can also be used to calculate the aforementioned HC hash code.

[0121] Each command descriptor block (CMD) can include information about a command executed in relation to the node to which the CSB command flow in which it is arranged is attached (hereafter simply "the node to which it is attached"). It can also include information about the execution of the command. In one embodiment, a command descriptor block can also include, in encrypted form, the encryption key associated with the node to which it is attached, for example, one of the keys K111, K112, K121, K122, K11, K12, or Kr(). The encryption key can be decrypted only by the instance that issued the command, or, in some cases, only by the secure processor.For this purpose, information relating to the execution of the command may include information enabling the instance or secure processor to decrypt the encryption key, to avoid having to recalculate it by derivation of the root key Kr or the master key Km.

[0122] Therefore, the encryption key associated with the corresponding node can, within the same command flow block, be present in one or more command descriptor blocks, in different encrypted forms, each encrypted form being decryptable only by the instance that issued the command, or, in some cases, by the secure processor. In one embodiment, the aforementioned ECDHE algorithm and the secp256k1 curve are used to generate keys for encrypting encryption keys before including them in the command descriptor blocks.

[0123] Thus, with a judicious choice of commands and the recording of these commands as command descriptor blocks arranged in command flow blocks, the secure processor can retain no node encryption key and completely free its own secure memory.

[0124] To better understand the advantages of this implementation, we will describe, without limitation, examples of commands and command descriptor blocks used to deploy the chain of trust object. The command descriptor blocks are described here in their simplest form. In practice, they may include fields other than those listed below.

[0125] Figures 7A, 7B, 7C and 7D represent the descriptor blocks of four basic commands: "SEED", "DERIVE", "ADDMEMBER" and "PUBKEY", and are reproduced below.

[0126] The SEED command descriptor block comprises four fields: TP, IV, pK1e and ENC(Kr):

[0127] TP Subject of the tree IV Initialization vector PK1 e Ephemeral public key generated by the secure processor ENC(Kr) Root node encryption key, in encrypted form decipherable only by the secure processor

[0128] The DERIVE command descriptor block includes four fields: "Path", IV, pK1e, and ENC(Kj):

[0129] Path: Derivation path of the node "j" concerned; IV: Initialization vector; PK1e: Ephemeral public key generated by the secure processor; ENC(Kj): Encryption key of the node "j" concerned by the command, in encrypted form decipherable only by the instance that issued the command

[0130] The ADDMEMBER command descriptor block includes two fields: "Name" and "PK2":

[0131] NameMember name (application program name)PK2Member public key

[0132] The PUBKEY command descriptor block includes four fields: "Beneficiary", IV, pK1e, and ENC(Kj):

[0133] Beneficiary: Public key of the instance that received the encryption key associated with the relevant node "j" (instance identifier) ​​IV Initialization vector PK1e Ephemeral public key generated by the secure processor ENC(Kj) Encryption key of the node "j" concerned by the command, in encrypted form decipherable only by the instance that issued the command

[0134] The reason why the VI (Initialization Vector) and PK1e (Ephemeral Public Key generated by the secure processor) fields are provided in the SEED, DERIVE and ADDMEMBER commands will become clear from reading the following description of the execution of these commands by the secure processor, made with reference to the.

[0135] Executing the SEED command:

[0136] At one stage (A1), the secure processor receives the SEED command.

[0137] At one stage (A2), the secure processor generates a 64-byte (512-bit) master key Km (seed):

[0138] Km=Random(64).

[0139] At one stage (A3), the secure processor generates a temporary private key of 32 bytes, or 256 bits:

[0140] pK1e=Random(32).

[0141] At one step (A4), the secure processor calculates an ephemeral public key PK1e from its ephemeral private key pk1e:

[0142] PK1e=secp256k1_priv2pub(pk1e)

[0143] At one stage (A5), the secure processor generates an encryption key Ek from its ephemeral public key PK1e and its private key pK1:

[0144] Ek=ECDHE(PK1e,pK1)

[0145] At one stage (A6), the secure processor erases the ephemeral private key pK1e from its memory.

[0146] At one stage (A7), the secure processor generates a 16-byte random initialization vector IV:

[0147] IV=Random(16)

[0148] At one step (A8), the secure processor encrypts the key Km with the key Ek and the vector VI, using the AES function:

[0149] ENC(Km) = AES(IV, Ek, Km)

[0150] At one step (A9), the secure processor populates the command descriptor block with the parameters "derivation path", vector IV, ephemeral public key PK1e, and the encryption key associated with the node, in its encrypted form, here the encrypted master key ENC(Km).

[0151] At one stage (A10), the secure processor signs the relevant command flow block with its private key pK1.

[0152] At one stage (A11), the secure processor sends the signed command stream block to the instance that issued the command, which records it in the SRV2 storage medium.

[0153] From the foregoing, it appears that the secure processor is then the only one capable of decrypting the master key Km using the information present in the SEED command descriptor block, because the encryption key Ek was generated in step A5 with the ECDHE algorithm from its ephemeral public key PK1e and its private key pK1. Therefore, after reading the PK1e key stored in the command descriptor block, and using its private key, it can regenerate the key Ek, and then, using the initialization vector IV and the inverse AES function -1 decipher the root key Kr.

[0154] It should be noted here that the SEED command leads to the creation of the first command flow block of the TCO trust chain object. Strictly speaking, this command flow block is not part of the TCO trust chain object but is "above" it. Indeed, the SEED command leads the secure processor to generate the master key Km, from which several TCO trust chain objects can be derived using the DERIVE command described below. A multitude of TCO trust chain objects, each with its own root key Kr derived from the master key Km, can therefore be "grafted" onto this first command flow block. These other trust chain objects correspond to other data field structures for which other key derivation tree structures and other association rules have been defined.This appears on the diagram, which represents the first steps in creating the TCO trust chain object.

[0155] The creation of the TCO trust chain object begins with the SEED command and leads to the creation of a CSBm command flow block, which will subsequently contain no command description blocks other than the SEED command itself, which is executed only once. As also shown in the diagram, the creation of the TCO trust chain object only truly begins with the DERIVE command executed with the derivation path m / 1, which leads to the generation of the root key Kr and the creation of the CSBr root block of the TCO trust chain object. As shown in the dashed line, sending the DERIVE command again to the secure processor, with a derivation path m / 2 instead of m / 1, would lead to the creation of the root command flow block of a different TCO trust chain object, corresponding to a different DS2 data field structure for which a different key derivation tree structure has been defined, along with a different association rule.

[0156] In one variant, the SEED command is omitted, and the master key Km is pre-recorded in non-volatile memory of the secure processor. However, this variant offers less security. In another variant, there is no master key Km, and the root key Kr is pre-recorded in non-volatile memory of the secure processor. It is then not possible to generate multiple chain of trust objects, except by using the key Kr as the seed.

[0157] We will now describe the execution of the DERIVE command:

[0158] At one stage (A10), the secure processor receives the DERIVE command along with the derivation path of the parent node.

[0159] At one step (A20), the secure processor derives the key Kj+1=(pkj+1, cj+1) of the child node from the key Kj=(pkj, cj) of the parent node and the derivation path of the child node used as index i:

[0160] Kj+1=(pkj+1, cj+1)=BIP32((pkj, cj),i)

[0161] It will be noted here that if the derivation path is m / 1, the parent node is the seed Km (Kj=Km), so the command leads to the generation of the root key Kr (Kj=Km and Kj+1=Kr) and the creation of the root command flow block CSBr, as stated above and shown on the.

[0162] At one step (A3), the secure processor generates an ephemeral private key pK1e=Random(32).

[0163] At one step (A4), the secure processor calculates an ephemeral public key PK1e from pk1e.

[0164] PK1e=secp256k1_priv2pub(pk1e)

[0165] At one stage (A5), the secure processor generates an ECDHE Ek encryption key from its ephemeral public key PK1e and its private key pK1:

[0166] Ek=ECDHE(PK1e,pK1).

[0167] At one stage (A6), the secure processor erases the ephemeral private key pK1e from its memory.

[0168] At one stage (A7), the secure processor generates a 16-byte random initialization vector IV:

[0169] IV=Random(16)

[0170] At one step (A80), the secure processor encrypts the key Kj+1 with the key Ek and the vector VI:

[0171] ENC(Kj+1) = AES(IV, Ek, Kj+1)

[0172] At one step (A9), the secure processor populates the command descriptor block with the parameters "derivation path", vector IV, ephemeral public key PK1e, and encryption key associated with the node, in its encrypted form ENC(Kj+1).

[0173] At one stage (A10), the secure processor signs the relevant command flow block with its private key pK1.

[0174] At one stage (A11), the secure processor sends the signed command stream block to the instance that issued the command, which records it in the SRV2 storage medium.

[0175] Similar to the SEED command, the secure processor will then be the only one capable of decrypting the ENC(Kj+1) encryption key using the information in the command's descriptor block, since the Ek encryption key was generated in step A5 using the ECDHE algorithm from its ephemeral public key PK1e and its private key pK1. Therefore, after reading the PK1e key stored in the command's descriptor block, and using its private key, it can regenerate the Ek key, and then, using the IV initialization vector and the AES inverse function -1 decipher the key Kj+1.

[0176] Referring again to Figure 9A, or Figure 9B, which shows the TCO trust chain object at a more advanced stage of deployment, we see that the DERIVE command allows the creation of command flow blocks CSBr, CSB11, CSB12, CSB111, and CSB112 of the TCO trust chain object, starting with the CSBr root block, with path m / 1. This command cannot be used to create other command flow blocks under the SEED node, except to create a new trust chain object that will be associated with a different data field structure. For a given trust chain object, subdividing the derivation paths and creating new command flow blocks can only occur from the CSBr root block, using derivation paths m / 1 / 1, m / 1 / 2, etc., as seen by comparing Figures 9A and 9B.On the, the command flow block CSB11 of path m / 1 / 1 was created under the root block CSBr using the DERIVE command, and on the a second block CSB12 of path m / 1 / 2 was created under the SCB1 block using the DERIVE command.

[0177] It follows from the above that the DERIVE command's descriptive block, like the SEED command's command block, is intended exclusively for the secure processor and allows it to save the encryption key associated with the node in an encrypted form that it can later decrypt. The command does not grant any rights to application program instances, but the descriptive block of this command can be read by them. This will allow them to know the deployment stage of the chain of trust object and which commands they can send to the secure processor. In particular, the ADDMEMBER and PUBKEY commands can be sent if the DERIVE command has already been executed on a given node. Otherwise, if the command flow block does not exist for the given node, the instances must first send the DERIVE command to the secure processor to create this block.

[0178] Executing the ADDMEMBER command:

[0179] The ADDMEMBER command allows an instance to obtain access to a node, or rather, the right to request access to a node, since access to the node is only truly finalized after the execution of the PUBKEY command described later, which can only be executed if the ADDMEMBER command has already been executed. In its simplest form, as described here, the command's descriptive block contains only two fields: the name of the member requesting access to the node (in practice, the name of the application program, usually a code assigned to the application program), and the member's PK2 public key, which identifies them. The ADDMEMBER command is issued by the instance that wants to join a node. The requesting instance also sends other information to the secure processor, such as the node targeted by the command and an identifier for the instance, for example, its public key.If the command is accepted, possibly with the agreement of the USR user, the command is entered into the corresponding command flow block. Figures 9A and 9B show that a description of the ADDMEMBER command appears in each command flow block: CSBr, CSB11, CSB12, CSB111, and CSB112. However, like the SEED command, this command does not grant the designated member any rights to the node in which it is entered. To obtain these rights, the member must then issue a PUBKEY command to publish the encryption key associated with the node, in an encrypted form that only they can decrypt. We will now describe the execution of the PUBKEY command.

[0180] Executing the PUBKEY command:

[0181] At one stage (A11), the secure processor receives the PUBKEY command along with the parent node derivation path and the PK2 public key of the instance issuing the command.

[0182] At one step (A20), the secure processor derives the key Kj+1=(pkj+1, cj+1) of the child node from the key Kj=(pkj, cj) of the parent node and the derivation path of the child node used as index i.

[0183] Kj+1=(pkj+1, cj+1)=BIP32((pkj, cj),i)

[0184] At one stage (A3), the secure processor generates an ephemeral private key:

[0185] pK1e=Random(32)

[0186] At one step (A4), the secure processor calculates an ephemeral public key PK1e from pk1e:

[0187] PK1e=secp256k1_priv2pub(pk1e)

[0188] At one stage (A50), the secure processor generates an ECDHE Ek encryption key from its private key pK1e and the instance's public key pK2:

[0189] Ek=ECDHE(pK1e,PK2)

[0190] At one stage (A6), the secure processor erases the ephemeral private key pK1e from its memory.

[0191] At one stage (A7), the secure processor generates a 16-byte random initialization vector IV:

[0192] IV=Random(16)

[0193] At one step (A80), the secure processor encrypts the key Kj+1 with the key Ek and the vector VI:

[0194] ENC(Kj+1) = AES(IV, Ek, Kj+1)

[0195] At one step (A9), the secure processor populates the command descriptor block with the parameters "derivation path", vector IV, ephemeral public key PK1e, and encryption key associated with the node, in its encrypted form ENC(Kj+1).

[0196] At one stage (A10), the secure processor signs the relevant command flow block with its private key pK1.

[0197] At one stage (A11), the secure processor sends the signed command stream block to the instance that issued the command, which records it in the SRV2 storage medium.

[0198] It follows from the above that, unlike the SEED and DERIVE commands, the instance that issued the command will be the only one capable of decrypting the encrypted key ENC(Kj+1) using the information present in the command's descriptor block. Indeed, the encryption key Ek was generated at step A50 using the ECDHE algorithm from the secure processor's private key pK1e and the instance's public key pK2. The instance can therefore, after reading the secure processor's ephemeral public key PK1e stored in the command's descriptor block, and using its private key, generate the key Ek again with the ECDHE algorithm. Then, using the initialization vector IV and the inverse function AES -1 , she will be able to decipher the key Kj+1.

[0199] Referring again to Figures 9A and 9B, we see that each CSB command flow block contains, after the DERIVE command that led to its creation, the ADDMEMBER command followed by the PUBKEY command. These two commands could have been sent simultaneously with the DERIVE command by the instance that requested the creation of the node in question. Within each command flow block thus created, other pairs of ADDMEMBER and PUBKEY commands can then be entered by other instances. For example, in Figure 9A, block CSB11 contains two successive pairs of ADDMEMBER and PUBKEY commands, meaning that after the block was created by a first instance and it acquired access rights to the node, a second instance also requested access rights to the node. In Figure 9B, the same CSB11 block contains a third pair of ADDMEMBER and PUBKEY commands, meaning that a third instance requested access to the node.Each of these three instances can therefore find, within the description of the PUBKEY command which concerns it (i.e. the one which contains its public key), an encrypted version of the encryption key associated with the node, which it will be able to decrypt in order to then be able to decrypt encrypted data located in the data storage medium SRV1.

[0200] This is a sequence diagram illustrating a phase of creating a trust chain object by an AI instance of an application program, followed by a phase of initializing the object by the AI ​​instance, itself followed by a phase of sharing data with an IB instance. This describes the steps of the...

[0201] Creation phase of the trust chain object:

[0202] At step (B1), the AI ​​instance sends a user's ID to the secure processor SPROC and requests it to create a trust chain object. This step occurs, for example, during a user's first installation of the application. At step (B2), the secure processor receives the user's ID. At step (B3), the AI ​​instance requests the SRV2 data storage medium to provide it with the trust chain object associated with the user's ID. At step (B4), the AI ​​instance receives an empty response, meaning that no such object exists. This is therefore the first installation of the application for this user. At step (B5), the AI ​​instance requests the secure processor to create the trust chain object and to be added to it as a member. This step corresponds to the successive sending of the SEED, DERIVE, ADDMEMBER, and PUBKEY commands and the creation of the CSBm and CSBr blocks.At one stage (B6) the AI ​​instance receives the trust chain object and at another stage (B7) it loads it into the data storage medium SRV2. At this stage, the data storage medium SRV1 does not contain any data encrypted by the instance.

[0203] Data initialization phase:

[0204] In step B10, the user USR provides the AI ​​instance with application data to be written to the JSON file. In step B11, the AI ​​instance finds the root key Kr of the trust chain object in encrypted form within the PUBKEY descriptive block located in the root block CSBr (for example). It decrypts it using the ephemeral public key present in the PUBKEY descriptive block and the initialization vector IV. In step B12, the AI ​​instance encrypts the data in the JSON file using keys derived from the root key Kr. In step B13, the AI ​​instance loads the JSON file into the data storage medium SRV1.

[0205] Data sharing phase in preparation for publication

[0206] At step B15, an IB instance of an application program sends a user's ID to the secure processor SPROC and requests access to the chain of trust object. At step B16, the secure processor receives the user's ID. At step B17, the IB instance requests the SRV2 data storage medium to provide it with the chain of trust object associated with the ID. At step B18, the IB instance receives the chain of trust object. At step B19, the IB instance requests that the secure processor add it to the chain of trust object. For example, this request is assumed to target the root node so that the instance can have the root key Kr. This request is made using the ADDMEMBER and PUBKEY commands.At step B20, and possibly after user consent, the IB instance receives the modified trust chain object from the secure processor after the latter has verified the signatures and hash codes present in the blocks, inserted the ADDMEMBER and PUBKEY commands into the relevant command flow block, and signed the modified command flow block. At step B21, the IB instance loads the modified trust chain object into the SRV2 data storage medium. At step B22, the IB instance requests the encrypted JSON file from the SRV1 data storage medium. At step B23, the IB instance receives the encrypted file. At step B24, the IB instance finds the encrypted root key Kr within the trust chain object, specifically within the PUBKEY command description block relevant to it (the one that mentions its public key).The instance decrypts the root key Kr using the ephemeral public key also found in the PUBKEY command descriptor block, and derives the encryption keys for the leaf nodes associated with data fields in the JSON file that contain data. At one stage (B25), the IB instance decrypts each encrypted data item in the JSON file using the derived encryption keys, and at another stage (B26), it edits the file, for example, by presenting it to a user via the screen of the secure device in which the secure processor is embedded.

[0207] As another example of using the trust chain object according to the process, there is a sequence diagram showing the creation of a new branch of the trust chain object by the AI ​​instance. There are steps in this process.

[0208] In step C1, the AI ​​instance requests the data storage medium SRV2 to provide it with the chain of trust object associated with the user's ID. In step C2, it receives the chain of trust object. In step C3, the AI ​​instance locates the appropriate parent command flow block within the chain of trust object. In step C4, the AI ​​instance sends the parent command flow block to the secure processor. In step C5, the secure processor parses the parent command flow block. It finds the parent node's key Kj in encrypted form within the DERIVE command, along with the previously generated ephemeral public key PK1e and the initialization vector IV. The secure processor uses this information to decrypt the key Kj as described above and then saves it in step C6.At step C7, the secure processor sends an "OK" message to the AI ​​instance to indicate that it can add a branch to the parent command flow block. At step C8, the instance requests the secure processor to create a new branch in the trust chain object using the DERIVE command. At step C9, the secure processor derives the child node's key Kj+1 from the saved key Kj. At step C10, the secure processor creates and then signs the new child command flow block. At step C11, it sends the signed block to the AI ​​instance. At step C12, the AI ​​instance adds the new child command flow block to the trust chain object and then loads it into the SRV2 data storage medium at step C13. At step C14, the SRV2 data storage medium saves the updated trust chain object.

[0209] It will be readily apparent to those skilled in the art that the method just described is susceptible to various other embodiments and applications. The commands described, which allow the creation, management, and deployment of the chain of trust object, are susceptible to various variants, as are all the cryptographic functions implemented by the method. For the sake of simplicity, simplified embodiments of these commands have been described above, which may in practice include other data or information fields. Similarly, other commands may be provided, for example, a CLOSESTREAM command indicating that the key Kj of a command flow block has been revoked and that the block is no longer usable, and consequently, so are all its child blocks.Key rotation steps can also be implemented after a member of a command flow has been excluded. Command combinations could also be implemented. For example, the ADDMEMBER and PUBLISHKEY commands could be merged into a single command.

Claims

1. A method for storing and sharing confidential data (DTi, DTj) between one or more instances of one or more application programs (AP1, AP2,…APn) executed by one or more application processors (PROC1, PROC2,…PROCn), in a system comprising a data storage means (SRV1, SRV2), characterized in that it comprises the steps of: - defining a data field structure (DS1) (DF1-DF8), - defining an encryption key derivation tree structure, the key derivation tree structure comprising a root node (Nr), intermediate nodes, and leaf nodes (N111-N134, N11-N1423) to which encryption key derivation paths based on the root node (Nr) are associated, - defining an association rule whereby each data field is associated with a leaf node of the key derivation tree structure and with a corresponding bypass path,- Assign a root encryption key (Kr) to the root node (Nr), - Assign at least one data item to a data field in the data field structure (DS1) (DF1-DF8), - Identify the derivation path (m / 1 / 1 / 1… m / 1 / 3 / 4, m / 1 / 1…m / 1 / 4 / 2 / 3) associated with the data field according to the association rule, - Generate a data encryption key (K111… K134, K11…K1423) using a key derivation function and from the root encryption key (Kr) and the derivation path associated with the data field, - Encrypt the data with the encryption key, and - Store the encrypted data in the data storage medium (SRV1, SRV2).

2. A method according to claim 1, comprising a preliminary step of classifying the data fields (DF1-DF8) by category according to one or more classification criteria representative of the potential data access needs that the data fields may include, and wherein the association rule is configured so as to associate with data fields of the same category leaf nodes of the key derivation tree having the same parent node.

3. A method according to any one of claims 1 and 2, comprising a step of configuring the application program (AP1, AP2,…APn) before the execution of an instance of an application program to have the key derivation function, the data field structure (DF1-DF8), the key derivation tree structure and the association rule, said configuration of the application program being able to be written into the code of the application program or provided to the instance of the application program by another instance of an application program or during a dynamic configuration step of the application program.

4. A method according to any one of claims 1 to 3, comprising, before the execution of an instance of an application program (AP1, AP2,…APn) intended not to have access to the contents of all the data fields (DF1-DF8), a step of partial configuration of the application program so that it has the key derivation function, a part of the data field structure, a part of the key derivation tree structure corresponding to the part of the data field structure, and the association rule corresponding to the data fields to which the application program may have access, said partial configuration of the application program being able to be written in the code of the secondary application program or provided to the instance of the application program by another instance of an application program or during a dynamic configuration step of the application program.

5. A method according to any one of claims 1 to 4, comprising the steps of: - providing a master key (Km), - generating the root node encryption key (Nr) from the master key, and - basing the key derivation paths (m / 1 / 1 / 1… m / 1 / 3 / 4, m / 1 / 1…m / 1 / 4 / 2 / 3) on the master key and generating the encryption key associated with a data field from the master key.

6. A method according to claim 5, comprising a step of generating, from the master key (Km), an encryption key for the root node (Nr) of at least one other key derivation tree structure corresponding to another data field structure and another association rule, and encrypting data assigned to data fields of the other data field structure at the request of an application program instance using the other data field structure.

7. A method according to any one of claims 1 to 6, implemented in a system comprising at least one secure processor, wherein: - the data encryption key generation and data encryption steps are conducted by the secure processor (SPROC) at the request of an application program instance executed by an application processor, and - the encrypted data storage step is conducted by an application program instance executed by an application processor.

8. A method according to claim 7, comprising the steps of: - using an application program instance, sending (A1) to the secure processor (SPROC) a command (DERIVE) to supply the root encryption key (Kr) of the key derivation tree, and - using the secure processor, supplying (A10, A20, A3, A4, A5, A6, A7, A80, A9) the root encryption key to the application program instance, in an encrypted form decipherable by the application program instance.

9. A method according to any one of claims 7 and 8, comprising the steps of, by means of an application program instance: - addressing to the secure processor (SPROC) a request (PUBKEY) for access to data in a data field associated with a node of the key derivation tree which may be a leaf node or a parent node, - by means of the secure processor, providing (A11, A20, A3, A4, A50, A6, A7, A80, A9) to the application program instance, in an encrypted form decipherable by the application program instance, the encryption key associated with the relevant node of the key derivation tree.

10. A method according to claim 9, comprising the steps of: - using the secure processor (SPROC): - receiving (A11) a public key (PK2) from the application program, - generating (A3, A4) an ephemeral private key (PK1e) and an ephemeral public key (PK1e), - generating, from the ephemeral private key and the public key of the application program, an ephemeral Diffie-Hellman encryption key (Ek) based on an elliptic curve, - generating (A7) an initialization vector (IV), - encrypting (A80) the encryption key associated with the node in question using an encryption function (AES), the ephemeral Diffie-Hellman encryption key (Ek), and the initialization vector (IV), and - providing (A9, A10, A11) to the application program instance, the encryption key associated with the node in question in its form encrypted accompanied by the ephemeral public key and the initialization vector.

11. A method according to any one of claims 7 to 10, comprising steps of creating, in a data storage means, a trust chain object (TCO) comprising child and parent command flow blocks (CSBm, CSBr-CSB12, CSB111, CSB112) linked together in a tree structure identical to that of the key derivation tree, each command flow block forming a node of the trust chain object corresponding to a node of the key derivation tree and comprising descriptive blocks of commands concerning that node having been addressed to the secure processor (SPROC) by application program instances (AP1, AP2,…APn) and executed by the secure processor.

12. A method according to claim 11, comprising providing a node derivation command (DERIVE) for creating, in the trust chain object (TCO), a child command flow block intended to receive descriptive blocks of commands addressed to the secure processor (SPROC) in relation to that node by application program instances (AP1, AP2,…APn), the node derivation command comprising an identifier of the node targeted by the command, such as the derivation path associated with the node or other type of identifier.

13. A method according to claim 12, wherein the execution of the node derivation command (DERIVE) comprises the steps of: - using the secure processor (SPROC), in response to the command and subject to any command acceptance conditions: - encrypting the encryption key (Ek) associated with the node targeted by the command in a manner indecipherable by the application program instance that issued the command, - providing the application program instance that issued the command with the encryption key associated with the node targeted by the command in its encrypted form, which is not decipherable by the application program instance, as well as parameters that allow the secure processor to subsequently decrypt the encryption key associated with the node targeted by the command, - using the application program instance that issued the command,Upon receiving the response from the secure processor: - write a command flow block (CSBr-CSB12, CSB111, CSB112) concerning the node targeted by the command into the Trust Chain Object (TCO); - write a command description block for the node derivation command into the command flow block, the command description block including the identifier of the node targeted by the command, the encryption key associated with the node targeted by the command in its encrypted form, and the parameters that allow the secure processor to subsequently decrypt the encryption key associated with the node targeted by the command.

14. A method according to claim 13, wherein the execution of the node derivation command (DERIVE) also comprises the steps of using the secure processor (SPROC): - generating an ephemeral private key (pK1e) and an ephemeral public key (PK1e), - generating, from the ephemeral private key and the ephemeral public key, an ephemeral Diffie-Hellman encryption key (Ek) based on an elliptic curve, - generating an initialization vector (IV) for the encryption key associated with the node targeted by the command, - encrypting the encryption key associated with the node targeted by the command using an encryption function, the ephemeral Diffie-Hellman encryption key, and the initialization vector, and - providing the application program instance that issued the command with parameters that enable the secure processor to subsequently decrypt the encryption key associated with the node targeted by the command.the initialization vector and the ephemeral public key used by the secure processor to generate the ephemeral Diffie-Hellman encryption key.

15. A method according to any one of claims 11 to 14, comprising providing a command (PUBKEY) for accessing a node of the Trust Chain Object (TCO), and wherein the execution of this command comprises the steps of: - using the secure processor (SPROC), in response to the command, and subject to any conditions of command acceptability: - encrypting the encryption key (Ek) associated with the node targeted by the command in a manner decipherable by the application program instance that issued the command, - providing the application program instance that issued the command with the encryption key associated with the node targeted by the command in its encrypted form decipherable by the application program instance, as well as parameters enabling the application program instance to decrypt the encryption key associated with the node targeted by the command - using the application program instance,Upon receiving the response from the secure processor: - write a descriptive block of the node access command in the node's command flow block; the command descriptive block includes an identifier of the node targeted by the command, the encryption key (Ek) associated with the node targeted by the command, in its encrypted form, and the parameters enabling the application program instance to decrypt the encryption key associated with the node targeted by the command.

16. A method according to claim 15, wherein the execution of the command (PUBKEY) for accessing a node of the trust chain object comprises the steps of, using the secure processor (SPROC): - generating an ephemeral private key (pK1e) and an ephemeral public key (PK1e), - generating, from the ephemeral public key and a public key of the application program instance that issued the command, an ephemeral Diffie-Hellman encryption key (Ek) based on an elliptic curve, - generating an initialization vector (IV) of the encryption key associated with the node targeted by the command, - encrypting the encryption key associated with the node targeted by the command using an encryption function, the ephemeral Diffie-Hellman encryption key, and the initialization vector, and - providing the application program instance that issued the command,as parameters enabling the application program instance to decrypt the encryption key associated with the node targeted by the command, the initialization vector and the ephemeral public key used by the secure processor to generate the Ephemeral Diffie-Hellman encryption key.

17. A method according to any one of claims 11 to 16, comprising forecasting a command (SEED) to create a first command flow block in the Trust Chain Object (TCO), and wherein the execution of this command comprises the steps of: - using the secure processor (SPROC), in response to the command and subject to any conditions of command acceptability: - generating the root encryption key (Kr) of the key derivation tree from a master key (Km), - encrypting the root encryption key in a manner indecipherable by the application program instance that issued the command, - providing the application program instance that issued the command with the root encryption key in its encrypted form, which is indecipherable by the application program instance, as well as parameters that may allow the secure processor to subsequently decrypt the root encryption key.- using the application program instance, upon receiving the response from the secure processor: - write the first command flow block to the trust chain object, - write a command description block to the command flow block, the command description block including the identifier of the node targeted by the command, the root encryption key in its encrypted form, and the parameters that allow the secure processor to subsequently decrypt the root encryption key.

18. A method according to claim 17, wherein the execution of the command (SEED) for creating the first command flow block also comprises the steps of using the secure processor (SPROC): - generating an ephemeral private key (pK1e) and an ephemeral public key (PK1e), - generating, from the ephemeral private key and the ephemeral public key, an ephemeral Diffie-Hellman encryption key based on an elliptic curve, - generating an initialization vector (IV) for the encryption of the root encryption key (Kr), - encrypting the root encryption key using an encryption function, the ephemeral Diffie-Hellman encryption key, and the initialization vector, and - providing the application program instance that issued the command, as parameters enabling the secure processor to subsequently decrypt the root encryption key, with the initialization vector for the encryption of the root encryption key. root,and the ephemeral public key used by the secure processor for this encryption.

19. A method according to any one of claims 10, 14, 16 or 18, wherein the secure processor (SPROC) is configured to, after generating the Ephemeral Diffie-Hellman encryption key, erase the ephemeral private key (pK1e) from which the Ephemeral Diffie-Hellman encryption key was generated.

20. A method according to any one of claims 11 to 18, wherein each command flow block is signed (SIGN) by the last application program instance that created the block or modified the block by adding a command description block, the signature being generated using a private key of the application program instance and being verifiable by other application program instances using the public key of the signing application program instance.

21. A method according to any one of claims 11 to 20, comprising the step of providing in each command flow block, a hash code (HC) of all or part of a parent command flow block, such that the trust chain object (TCO) forms a chain of blocks.

22. A method according to any one of claims 11 to 21, wherein the secure processor is configured to, before the execution of a command, read the entire Trust Chain Object (TCO) and verify its integrity.

23. A method according to any one of claims 7 to 22, wherein: - the secure processor (SPROC) is a secure element present in a hardware crypto-asset wallet, - an application processor is a processor of a host device of the hardware wallet, and - the application program instance is an application executed by the application processor of the host device of the hardware wallet.

24. A method according to any one of claims 1 to 23, wherein the data field structure includes data fields relating to crypto-asset accounts held by a user.

25. A method according to any one of claims 1 to 24, wherein: - the data field structure comprises data field labels written in a text file (JSON), - data present in a data field is written in its encrypted form in the text file, alongside or in relation to the data field label, and - the text file is itself stored in an unencrypted form in the data storage means.

Images