Generation of a multi-user contextual portfolio of private keys and use of such a portfolio

Abstract

A method of generating a hierarchical deterministic keys portfolio, in particular to sign transactions sent to a blockchain. The generation method includes an initialization phase by an administrator and a phase of setting parameters for at least one user. Private key usage contexts are created from the administrator account, each context specifying conditions for use of the private key in said context. User accounts are also created, each user account being associated with a private key in the tree structure, the private key of said user being obtained from a master private key of the administrator, the usage context to which the user account is attached, and the user's identifier.

Claims

1. A method of generating a hierarchical deterministic keys portfolio containing private keys according to a tree structure to sign transactions sent to a blockchain, said method comprising: creating, during an initialization phase, an administrator account; protecting, during the initialization phase, access to the administrator account by an administrator authentication element; generating, during the initialization phase, a master private key (k.sub.m) by hashing a random seed, the master private key being stored in a secure memory area of a mobile device; creating, during a parameter setting phase, a plurality of usage context identifiers from the administrator account, each usage context identifier pointing to an address in the secure memory area in which conditions for use of a private key in said context are stored; creating, during the parameter setting phase, a plurality of user accounts from the administrator account, each user account being associated with a private key in the tree structure, each user account being identified by an identifier and access to each user account being protected by a user authentication element, the private key of a corresponding user being obtained from the master private key, the usage context identifier to which the user account is attached, and an identifier of the user; hashing the identifier and using the hashed identifier to deduce at least one index; and using the at least one index to generate the private key of the user.

2. The method according to claim 1, wherein the private key of the user, k.sub.user, is obtained by calculating k.sub.user=CKD.sub.priv(CKD.sub.priv(CKD.sub.priv(k.sub.m,c(i)),Ind.sub.1)),Ind.sub.2) wherein CKD.sub.priv designates a normal or hardened operation to generate a child private key from a parent private key in a tree structure, c(i) is the usage context identifier to which the user account is attached and Ind.sub.1,Ind.sub.2 represents a pair of indices extracted from a result of hashing the user identifier using at least one hashing function.

3. The method according to claim 2, wherein the normal generation operation comprises the generation of a parent public key (PK.sub.parent) from the corresponding parent private key (k.sub.parent), concatenation with the parent public key of a parent chain code (CCK.sub.parent) to obtain an extended public key (PK.sub.parent.sup.ext), the combination of said extended public key with a child key index (i) that it is wished to generate, the result of said combination being hashed to provide a hashing result, a first part of the hashing result being combined with the parent private key to give the child private key, a second part of the hashing result providing a child chain code (CCK.sub.child).

4. The method according to claim 2, wherein the hardened generation operation comprises concatenation with the parent private key (k.sub.parent) of a parent chain code (CCK.sub.parent) to obtain an extended private key (PK.sub.parent.sup.ext), the combination of said extended private key with a child key index (i) that it is wished to generate, the result of said combination being hashed to provide a hashing result, a first part of the hashing result being combined with the parent private key to give the child private key, a second part of the hashing result providing a child chain code (CCk.sub.child).

5. The method according to claim 1, wherein the stored usage conditions with regard to an initialisation context are chosen from among a predetermined geographic area, a predetermined time range, an association with a predetermined host device or a connection to a predetermined network.

6. The method according to claim 1, wherein the private key of the user is used as a starting point to generate a corresponding public key (PK.sub.user) of the user in an asymmetric cryptosystem and in that the public key of the user is hashed to obtain a user account address (account.sub.user), the address of the user account being stored in the user account.

7. A method of using a hierarchical deterministic keys portfolio generated by a generation method to sign a transaction addressed to a blockchain, said portfolio having been parameterized for at least one user and being hosted on a mobile device connected to a host device through a secure channel, the generation method comprising: creatin, during an initialization phase, an administrator account; protecting, during the initialization phase, access to the administrator account by an administrator authentication element; generating, during the initialization phase, a master private key (k.sub.m) by hashing a random seed, the master private key being stored in a secure memory area of a mobile device; creatin, during a parameter setting phase, a plurality of usage context identifiers from the administrator account, each usage context identifier pointing to an address in the secure memory area in which conditions for use of a private key in said context are stored; and creatin, during the parameter setting phase, a plurality of user accounts from the administrator account, each user account being associated with a private key in a tree structure, each user account being identified by an identifier and access to each user account being protected by a user authentication element stored in the secure memory area of the mobile device, the private key of a corresponding user being obtained from the master private key, the usage context identifier to which the user account is attached, and an identifier of the user, the method of using the hierarchical deterministic keys portfolio further comprising: identifying the user using the corresponding user identifier and authenticates the user with the mobile device or the host device using an authentication element; filling in, by the user, a usage context identifier with the mobile device or the host device; hashing, by the mobile device, the identifier and using, by the mobile device, the hashed identifier to deduce at least one index; verifying, by the mobile device, that there is an existing user account in the portfolio associated with the usage context identifier and with the at least one index, then verifying that the user's authentication element is the same as that stored in the secure memory area of the mobile device, at an address specified by the user account; and when the verifying is successful, verifying when context data supplied by a sensor of the mobile device satisfy the usage conditions stored in the secure memory area at an address stored in the user account; and if these conditions are satisfied, and signing a transaction formed by the host device by the private key of the user, the signed transaction being returned to the host device to be transmitted to the blockchain.

8. The method according to claim 7, wherein a signature of the transaction using the private key of the user is made automatically by the host device, without any action by the user.

9. The method according to claim 7, wherein a signature of the transaction using the private key of the user also requires a physical action by the user on an element of the mobile device.

10. The method according to claim 8, wherein the transaction is sent from the user account address obtained by hashing the public key of the user stored in the user account.

11. The method according to claim 9, wherein the transaction is sent from the user account address obtained by hashing the public key of the user stored in the user account.

12. A method of generating a hierarchical deterministic keys portfolio containing private keys according to a tree structure to sign transactions sent to a blockchain, said method comprising: creating, during an initialization phase, an administrator account; protecting, during the initialization phase, access to the administrator account by an administrator authentication element; generating, during the initialization phase, a master private key (k.sub.m) by hashing a random seed, the master private key being stored in a secure memory area of a mobile device; creating, during a parameter setting phase, a plurality of usage context identifiers from the administrator account, each usage context identifier pointing to an address in the secure memory area in which conditions for use of a private key in said context are stored; creating, during the parameter setting phase, a plurality of user accounts from the administrator account, each user account being associated with a private key in the tree structure, each user account being identified by an identifier and access to each user account being protected by a user authentication element stored in the secure memory area of the mobile device, the private key of a corresponding user being obtained from the master private key, the usage context identifier to which the user account is attached, and an identifier of the user; hashing the identifier and using the hashed identifier to deduce at least one index; and verifying that there is an existing user account in the portfolio associated with the usage context identifier and with the at least one index, then verifying that the user's authentication element is the same as that stored in the secure memory area of the mobile device, at an address specified by the user account.

13. The method according to claim 12, wherein the private key of the user, k.sub.user, is obtained by calculating k.sub.user=CKD.sub.priv(CKD.sub.priv(CKD.sub.priv(k.sub.m,c(i)),Ind.sub.1)),Ind.sub.2) wherein CKD.sub.priv designates a normal or hardened operation to generate a child private key from a parent private key in a tree structure, c(i) is the usage context identifier to which the user account is attached and Ind.sub.1,Ind.sub.2 represents a pair of indices extracted from a result of hashing the user identifier using at least one hashing function.

14. The method according to claim 13, wherein the normal generation operation comprises the generation of a parent public key (PK.sub.parent) from the corresponding parent private key (k.sub.parent), concatenation with the parent public key of a parent chain code (CCK.sub.parent) to obtain an extended public key (PK.sub.parent.sup.ext) the combination of said extended public key with a child key index (i) that it is wished to generate, the result of said combination being hashed to provide a hashing result, a first part of the hashing result being combined with the parent private key to give the child private key, a second part of the hashing result providing a child chain code (CCK.sub.child).

15. The method according to claim 13, wherein the hardened generation operation comprises concatenation with the parent private key (k.sub.parent) of a parent chain code (CCk.sub.parent) to obtain an extended private key (PK.sub.parent.sup.ext), the combination of said extended private key with a child key index (i) that it is wished to generate, the result of said combination being hashed to provide a hashing result, a first part of the hashing result being combined with the parent private key to give the child private key, a second part of the hashing result providing a child chain code (CCk.sub.child).

16. The method according to claim 12, wherein the stored usage conditions with regard to an initialisation context are chosen from among a predetermined geographic area, a predetermined time range, an association with a predetermined host device or a connection to a predetermined network.

17. The method according to claim 12, wherein the private key of the user is used as a starting point to generate a corresponding public key (PK.sub.user) of the user in an asymmetric cryptosystem and in that the public key of the user is hashed to obtain a user account address (account.sub.user), the address of the user account being stored in the user account.

18. The method according to claim 12, comprising using the at least one index to generate the private key of the user.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Other characteristics and advantages of the invention will become clear after reading a preferred embodiment of the invention, described with reference to the appended figures among which:

(2) FIG. 1, already described, diagrammatically represents the structure of a hierarchical deterministic type of keys portfolio;

(3) FIG. 2A and FIG. 2B diagrammatically illustrate first and second known methods of generating private keys in a hierarchical deterministic type of keys portfolio;

(4) FIG. 3 diagrammatically represents the structure of a keys portfolio that can be generated by the portfolio generation method according to this invention;

(5) FIG. 4 represents the flowchart for an initialization phase in a method of generating a keys portfolio according to one embodiment of the invention;

(6) FIG. 5 represents the flowchart for a parametering phase in a method of generating a keys portfolio according to one embodiment of the invention;

(7) FIG. 6 diagrammatically represents the structure of a mobile device on which there is an onboard keys portfolio, according to one embodiment of the invention;

(8) FIG. 7 represents an example of the use of a mobile device hosting a keys portfolio according to one embodiment of the invention.

DETAILED PRESENTATION OF PARTICULAR EMBODIMENTS

(9) In the following, we will consider a hierarchical deterministic keys portfolio according to the meaning used above, particularly a portfolio conforming with standards BIP-32 and BIP-44. Such a portfolio has a tree structure in which a private key associated with a node ν of the tree structure, is generated by means of a hashing function from the extended public key or the extended private key associated with the parent node of ν and with an index, i, giving the birth rank of the key as described with reference to FIGS. 2A and 2B.

(10) FIG. 3 diagrammatically represents the structure of an HD keys portfolio that can be generated in the framework of this invention.

(11) Level “0” of the tree structure, or the root, corresponds to a master private key, k.sub.m, obtained by hashing a random seed (or entropy) advantageously coded in the form of a mnemonic code. Hashing may be done by a hashing function, or even a combination of hashing functions. The hashing result provides firstly the master private key, and secondly a chain code, CCk.sub.m, associated with this same key. The master public key, PK.sub.m, is obtained from the master private key using an asymmetric cryptographic algorithm (for example PK.sub.m=k.sub.m.Math.G for a cryptography algorithm on elliptical curve).

(12) An administrator account can be created at level “0” of the tree structure, access to which is protected by an administrator authentication element (PIN code or administrator password).

(13) The administrator account can be associated with the master private key, k.sub.m, and with the corresponding master public key, PK.sub.m=k.sub.m.Math.G, and is identified by an administrator account identifier (login.sub.adm). The administrator account contains an address in a secure memory area in which the administrator authentication element is stored as described below.

(14) Alternatively, the administrator account can be associated with a node located lower down in the tree structure.

(15) Access to the administrator account makes it possible to create a plurality of context identifiers, at level “1” of the tree structure, each context identifier pointing to an associated memory area in which conditions for use of a private key in said context are stored.

(16) Context identifiers are denoted c(1), . . . , c(n), each context identifier pointing to a memory area in which the conditions under which a private key is authorized for use are stored.

(17) In particular, a usage context can be a geographic area, a time range, an association with a host device, a connection to a network, etc.

(18) Usage conditions for a geographic area may for example be being or not being in a given perimeter.

(19) Usage conditions for a time range can be being or not being inside this time range.

(20) A condition of association with a host device or connections to a network can be associated with this device or connected to this network.

(21) Obviously, usage contexts can be composite and include combinations of several types of conditions. For example, the use of a private key can be authorized only within a certain perimeter and within a certain time range.

(22) When connected to the administrator account, level “2” user accounts in the structure can also be created. In general, each user account is associated with a usage context. However in some cases, a user account may not be associated with a context, regardless of whether this context is considered to be explicit or defined by default, or the user account may for example be an administrator account itself, delegate of an administrator account located at a higher level in the tree structure.

(23) Each user account has an identifier (login.sub.user) and its access is protected by an authentication element (for example a PIN code or a password).

(24) The identifier of a user account is hashed by means of a hashing function (or a combination of hashing functions) and the hashing result provides an index, Ind, or as we will assume later on herein, a pair of indices, Ind.sub.1,Ind.sub.2, used to generate the user's private key, k.sub.user:
(Ind.sub.1,Ind.sub.2)=Hash(login.sub.user)  (6)¶

(25) The user's private key k.sub.user is obtained by normal or hardened generation operations, starting from child key indices along the path, namely:
k.sub.user=CKD.sub.priv(CKD.sub.priv(CKD.sub.priv(k.sub.m,c(i)),Ind.sub.1)),Ind.sub.2)  (7)¶

(26) As before, normal generation operations and hardened generation operations can be envisaged successively along the path in the tree structure.

(27) Starting from the private key k.sub.user, the corresponding public key in the asymmetric cryptosystem is generated, namely for example in the case of a cryptosystem on an elliptical curve PK.sub.user=k.sub.userG.

(28) The private key, k.sub.user, is stored at a memory address in a secure area, appearing in the user account.

(29) The address of the user account from which the user will be able to send transactions to a blockchain, is obtained by hashing the public key PK.sub.user, by means of a hashing function or a combination of hashing functions.
account.sub.user=Hash(PK.sub.user)  (8)¶
wherein Hash corresponds to the hashing function or to the combination of hashing functions. For example, we will use keccack256 as the hashing function to obtain an ethereum account address and the combination of functions sha256 and ripemd160 to obtain a bitcoin address, in a manner per se.

(30) In summary, a user account is associated with a path in the tree structure:
path=m/c(i)/Ind.sub.1/Ind.sub.2  (9)¶
that can be used to generate the private key of this user, using relation (7).

(31) Although the tree structure in FIG. 3 has a depth N=3, it should be noted that tree structures with greater depths could also be considered. For example, a path may comply with the BIP-44 format for the first levels, continue with a context level and finally, terminate by a user level, in others words at a user account (or equivalently, the user's private key). In general, the path to the user account in the tree structure will be defined by:
path=m/ . . . /c(i)/Ind.sub.1/Ind.sub.2  (10)¶

(32) The user account contains the master private key, k.sub.user, the corresponding master public key, PK.sub.user=k.sub.user.Math.G and the identifier of the user account (login.sub.user). The user account also contains an address in a secure memory area in which a user authentication element is stored as specified below.

(33) Generation of the HD portfolio comprises an initialization phase done by a portfolio administrator and a phase of setting parameters for at least one user.

(34) FIG. 4 represents the flowchart for an initialization phase of a hierarchical deterministic keys portfolio according to one embodiment of the invention.

(35) The portfolio administrator is responsible for configuring the accounts of the different users and particularly for indicating the conditions under which these users can use their private keys.

(36) The administrator account can correspond to a default path in the tree structure. For example, the user account with null index and the null context identifier (no context) can be assigned to the administrator by default. The administrator account will then be characterized by Ind.sub.1=0, Ind.sub.2=0, c(i)=0 and the path will be defined by m/ . . . /0/0/0. It is important to note that in such a case, the administrator account is not located at level 0 in the tree structure, which may be preferred for security reasons. A default PIN code is also assigned to the administrator.

(37) The administrator connects to his account in step 410 at the time of the first connection, authenticating himself using the default PIN code. He then modifies his PIN code for subsequent accesses.

(38) In step 420, the administrator generates the master private key, k.sub.m starting from the random seed, and the corresponding master public key, PK.sub.m.

(39) During his first connection or during a subsequent access, the administrator can create private key usage contexts in 430, c(1), c(2), . . . , c(n), specifying the conditions under which the keys can be used for each context. The conditions associated with a context c(i) are stored in a memory area pointed to by c(i).

(40) Thus for example, a first context can correspond to a geographic context and the associated usage conditions can specify a predetermined area around a reference point. A second context can correspond to a temporal context and the associated usage conditions can specify a predetermined temporal range [T.sub.min, T.sub.max].

(41) The administrator can then create a user account in 440, attaching it to one of the above-mentioned contexts or, in some cases, not attaching it to any context (default usage context or implicit context). The user account will be assigned an identifier, login.sub.user, and a default authentication element (PIN code) that can be personalized during the first connection.

(42) In some cases, the administrator will be able to delegate part of his prerogatives to a secondary administrator.

(43) For example, the portfolio administrator will be able to create general user contexts and delegate the possibility of creating particular usage contexts to secondary administrators. Thus, for example, it could be envisaged that an administrator could delegate his geographic usage context creation rights to regional administrators, each of the regional administrators then only being able to create usage contexts in the region for which he is responsible.

(44) FIG. 5 represents the flowchart for a parameter setting phase of a keys portfolio according to one embodiment of the invention;

(45) This parameter setting phase assumes that the initialization phase of the portfolio had already been done by the administrator.

(46) In step 510, the user is prompted to choose the usage context in which he would like to operate. This step may be optional if the context is selected by default or if it is provided by an external device.

(47) In step 520, the user connects to his account by providing his identifier and his authentication element. It should be noted that a user can have a plurality of accounts under different contexts.

(48) During the first connection, the authentication element is the element that was granted to him by default by the administrator. He is then prompted to personalize his authentication element in a manner known in itself.

(49) In step 530, after the user has identified himself and the authentication element has been successfully verified, the user's identifier is submitted to a hashing function (or a combination of hashing functions). The index, Ind, or the pair of indices, Ind.sub.1, Ind.sub.2, used to generate his private key, is extracted from the hashing result.

(50) In step 540, the user's private key is generated by means of normal or hardened generation operations according to the above-mentioned meaning, starting from the master private key and indices of nodes along the path. For example, the private key can be generated using expression (7) when only normal generation operations are used.

(51) The user's private key is then stored in a secure memory area associated with the user's account.

(52) In 550, the user's corresponding public key is generated in an asymmetric cryptosystem, for example PK.sub.user=k.sub.user.Math.G, as described above.

(53) In step 560, the user's account address is obtained by hashing the public key, account.sub.user=Hash(PK.sub.user). This account address may be used by the user to send transactions to a blockchain provided that the conditions specified in the usage context are satisfied.

(54) Thus for example, when the user has previously formed a transaction and would like to sign it using his private key to send it to the blockchain, the user opens his portfolio application, accesses his user account in the chosen context, identifies himself and authenticates himself as described above.

(55) The private key can be generated and the transaction can be signed consecutively, during the same session. In other words, the private key can be generated and the transaction can be signed automatically if usage conditions for this session are satisfied. Parameter settings and the signature by private key than take place during the same session.

(56) Alternatively, the private key may be generated during the user's first connection and the signature may only be made during a later session, if the usage conditions are satisfied during this session. Parameter settings and the signature by private key than take place in distinct sessions.

(57) According to one variant, the signature of the transaction may require a physical action by the user to validate the signature of the transaction, in addition to context usage conditions being satisfied. For example, if the keys portfolio is hosted in a mobile device such as a dongle provided with a push button, the signature can be validated by the user pressing on the button in question.

(58) FIG. 6 diagrammatically represents the structure of a mobile device on which there is an onboard keys portfolio, according to one embodiment of the invention.

(59) As an illustration, this mobile device may be a smart phone, a badge reader or a dongle equipped with an HMI interface (screen and buttons).

(60) In all cases, this device is composed of different parts with distinct security levels.

(61) A first high security part is composed of a Secure Element (SE), 610, in which the administrator's and the user's (or even several users') random seed and authentication elements (PIN codes, passwords) are stored.

(62) A second part, 620, is composed of a trusted area comprising firstly a secure memory area 623, and secondly a secure execution area.

(63) Whenever possible, the master private key and the private keys of users generated during the initialization phase and the usage phase respectively, are stored in the secure element, 610. By default, they will be saved in the secure memory area, 623. Considering these two options, it will be considered that the secure memory area can extend to the memory of the secure element.

(64) The secure memory area (in the previous extended meaning) also contains the conditions of the different private key usage contexts for the different users. More precisely, each context identifier c(i) points towards an address at which the corresponding usage conditions are stored.

(65) The Trusted Execution Environment comprises in particular a secure processor, 625, an entropic generator, a cryptographic accelerator, etc. Inside this area, in particular cryptographic functions can be executed such as generation of the master key from the random germ, elementary normal and hardened operations to generate private keys CKD.sub.priv.sup.n and CKD.sub.priv.sup.h, the calculation of a public key corresponding to a private key, the digital signature of a transaction by means of a user's private key (for example using the ECDSA algorithm), and the verification that conditions of a usage context are actually satisfied.

(66) The mobile device also comprises a third non-secure part, 630, called the normal area comprising a microprocessor or a microcontroller, RAM and ROM memories. This third part also comprises an HMI interface (screen, buttons, etc.) that the administrator and a user can use to dialogue with the portfolio generation application in the initialization and usage phases respectively.

(67) The man skilled in the art will understand that the administrator starts by initializing the mobile device as described with reference to FIG. 4 and that that parameters for this device are then set and the device is then used as described with reference to FIG. 5. Such a device can be personal to one user or it can be common to several users, each user having his specific account (or specific accounts in different contexts). In case of a loss, it is easy to regenerate the entire tree structure if the random seed (or the mnemonic code), the identifiers of the administrator and users, and usage conditions, are known. It should be noted that when even a hacker manages to regenerate said tree structure or to access a specific account, he could not use the specific account(s) because the authentication elements themselves are protected.

(68) Furthermore, it would be almost impossible for a third party external to the entity to which the administrator/users belong to trace transactions signed by the same user, by correlation. On the other hand, the administrator will find it easy to assure that transactions have actually been signed by authorized users in the required usage contexts.

(69) FIG. 7 represents an example of the use of a mobile object hosting a keys portfolio according to one embodiment of the invention.

(70) This example of use involves a mobile device, 710, of the type illustrated in FIG. 6 and a host device, 720, hosting a light client of the blockchain.

(71) It is assumed that the private keys portfolio was initialized in the mobile device, and possibly parametered by a user.

(72) When this user wants to sign a transaction with his private key to transmit it to the blockchain, he opens a session on the mobile device by entering his identifier (login) and his authentication element(s) (PIN code, password). Alternatively, the user can authenticate himself with the mobile device using a key conforming with the FIDO2 protocol. Optionally, the mobile device can be configured to require a multifactorial authentication.

(73) According to one variant, the user can identify and authenticate himself with the host device, the identifier and the authentication elements then being transmitted to the mobile device using a secure channel.

(74) In most cases, the user is prompted to enter the identifier of the usage context in which he would like to operate, before or after identifying and authenticating himself. As before, this identifier can be entered on the mobile device or the host device. In some cases, the usage context can be a default usage context, for example it can be deduced from the mobile application started by the user or the proximity of the host device.

(75) The portfolio application that is hosted on the mobile device, performs hashing of the user's identifier (login.sub.user) and uses it to deduce an index or a pair of indices (Ind.sub.1,Ind.sub.2). It then checks that here is no user account associated with the usage context and with the index or the pair of indices thus obtained, then verifies that the entered PIN code is the same as the code stored in the secure memory area, at the address stored in the user's account.

(76) In case of an identification failure (no account in the context) or an authentication failure (incorrect authentication element), the mobile device signals this problem to the user.

(77) In case of success, access to the account is unlocked and the user can use his user account to sign a transaction with his private key.

(78) More precisely, the portfolio application firstly verifies that context conditions are actually satisfied. To achieve this, a sensor present in the mobile device or the host device provides context data (for example GPS position, time, Wifi switch identifier, BLE identifier, etc.) and these data are compared with the conditions in question, stored in the secure memory area, at an address stored in the user's account.

(79) When context conditions are not satisfied, an error message is displayed on the mobile device. Conversely, when the conditions in question have been satisfied, the transaction formed by the user on the host device is supplied to the portfolio application.

(80) The transaction can then be signed automatically by the user's private key. This key can be generated dynamically (for example using the expression (7)) if it is not already stored in the trusted area, or read from the trusted area if it has already been generated in a previous session.

(81) According to one variant, signature by the private key may also require a physical action by the user, for example to press on a button on the mobile device to validate signature of the transaction.

(82) The transaction thus signed is then sent to the host device that sends it the blockchain starting from the address of the user's account.