Safeguarding and retrieving a secret proving possession of digital assets

Abstract

A method for safeguarding a secret (seed) stored by a hardware token such as a smart card, the secret enabling proof of possession of digital assets, the method comprising the following steps implemented by the hardware token: encryption (108) of a reference biometric template stored by the hardware token relating to a reference individual and the secret, so as to produce encrypted data (c1, c2); generation (112) of a backup (BU) from the encrypted data; and sending (114) the backup to a device separate from the hardware token. Figure for the abstract: Fig. 3

Description

Title of the invention: Safeguarding and retrieving a secret proving possession of digital assets. FIELD OF THE INVENTION

[0001] The present invention relates to a method of safeguarding a secret enabling proof of possession of digital assets, and a method of recovering such a secret on the basis of a safeguard. STATE OF THE ART

[0002] Private keys are fundamental secrets in cryptocurrency systems. They allow users to sign transactions and prove their ownership of digital assets. The security of these secrets is crucial, as their disclosure can lead to the loss of digital assets.

[0003] It is known to store these keys securely in hardware tokens, sometimes also called "hardware wallets" in this context. Of course, a user holding digital assets must carefully safeguard their hardware token, since they need it to sign transactions.

[0004] However, if the user loses or has their hardware token stolen, or if the hardware token is damaged, the user can no longer carry out transactions. Furthermore, a private key is not easy to memorize, so the problem arises of its recovery in the absence of the hardware token. Description of the invention

[0005] A technical problem to be solved is that of securely saving and retrieving a secret that can be used to prove possession of digital assets.

[0006] This technical problem is solved by a method of saving a secret stored by a hardware token such as a smart card, the secret allowing proof of possession of digital assets, the method comprising the following steps implemented by the hardware token: encryption of a reference biometric template stored by the hardware token relating to a reference individual and of the secret, so as to produce encrypted data; generation of a backup from the encrypted data; and sending the backup to a device separate from the hardware token.

[0007] The backup process, which constitutes a first object, may also include the following optional features, taken alone or in combination.

[0008] Preferably, the backup process includes the following steps: encryption of the reference biometric template to produce a first ciphertext, encryption of the secret so as to produce a second ciphertext, and generation of the backup from the first ciphertext and the second ciphertext.

[0009] Preferably, the encryption of the biometric template is carried out using a first encryption key, and the encryption of the secret is carried out using a second encryption key different from the first encryption key.

[0010] Preferably, the first encryption key is generated by the hardware token from a first master key and from a first diversifier, and the second encryption key is generated by the hardware token from a second master key and from a second diversifier, each diversifier being included in the backup.

[0011] Preferably, the second master key is different from the first master key, and the first diversifier and the second diversifier are one and the same diversifier included in the backup.

[0012] Preferably, at least one key among the first encryption key and the second encryption key is generated from a PIN code entered by the reference individual.

[0013] Preferably, the backup includes an authentication code generated from the encrypted data, the authentication code being usable to control the integrity of the backup.

[0014] Preferably, the authentication code is generated using an authentication key different from the first encryption key and the second encryption key.

[0015] Preferably, the authentication key is generated using a master key of the hardware token and from an authentication diversifier, and the authentication diversifier is included in the backup.

[0016] Preferably, the first diversifier and the authentication diversifier are one and the same diversifier included in the backup, or the second diversifier and the authentication diversifier are one and the same diversifier included in the backup.

[0017] Preferably, the backup is encoded in the form of a two-dimensional barcode.

[0018] The technical problem is further solved by a method for retrieving a secret that proves possession of digital assets, the method comprising the following steps implemented by a hardware token such as a smart card: receiving a backup from a device separate from the hardware token; decrypting the backup to retrieve a saved biometric template and the secret; acquiring a proof biometric template by a biometric sensor of the hardware token, the proof biometric template relating to an individual; verifying the correspondence between the saved biometric template and the proof biometric template; and storing the secret in a memory of the physical token, in which the decryption of the secret or the memorization of the secret is carried out provided that the verification reveals that the saved template and the biometric proof template match.

[0019] The recovery process, which constitutes a second object, may also include the following optional features, taken alone or in combination.

[0020] Preferably, the recovery process includes the following steps: decrypting a first ciphertext extracted from the backup, so as to recover the saved biometric template, and decrypting a second ciphertext extracted from the backup so as to recover the secret, wherein the decryption of the second ciphertext is carried out on the condition that the verification reveals that the saved template and the proof biometric template correspond.

[0021] Preferably, the decryption of the first ciphertext is carried out using a first decryption key, and the decryption of the second ciphertext is carried out using a second decryption key different from the first decryption key.

[0022] Preferably, the first decryption key is generated by the hardware token from a first master key and from a first diversifier extracted from the backup, and the second encryption key is generated by the hardware token from a second master key and from a second diversifier extracted from the backup.

[0023] Preferably, the second master key is different from the first master key, and the second diversifier and the first diversifier are one and the same diversifier present in the backup.

[0024] Preferably, at least one key among the first decryption key and the second decryption key is generated from a proof PIN code entered by the individual.

[0025] Preferably, the recovery process further includes steps for checking the integrity of the backup using an authentication code extracted from the backup, and for blocking the hardware token provided that the integrity check reveals that the backup is not intact, the blocking preventing any transfer of digital assets using the hardware token.

[0026] Preferably, the integrity check is implemented using an authentication key different from the first decryption key and the second decryption key.

[0027] Preferably, the authentication key is generated by the hardware token using a master key stored by the hardware token and from an authentication diversifier extracted from the backup.

[0028] Preferably, the first diversifier and the authentication diversifier are one and the same diversifier present in the backup, or the second diversifier and the authentication diversifier are one and the same diversifier present in the backup.

[0029] Preferably, the recovery process includes a dummy process to delay the recovery of the secret.

[0030] Preferably, the recovery process further includes the following steps implemented by a server: receiving a backup in encrypted form using a server-specific public key; decrypting the encrypted backup using a server-specific private key to obtain the backup; and, using a hardware token's own public key, re-encrypting the backup obtained after decryption with the server's own private key to obtain the backup in a re-encrypted form. The backup received by the hardware token is the backup in re-encrypted form. Furthermore, the recovery process includes the following step implemented by the hardware token: decrypting the re-encrypted backup using a hardware token's own private key before the hardware token decrypts the backup to recover the saved biometric template and secret.

[0031] A third object is a process comprising: saving a secret stored by a first hardware token via the saving process constituting the first object, the secret enabling proof of possession of digital assets; and retrieving the secret by a second hardware token via the retrieval process constituting the second object.

[0032] A fourth object is a computer program product comprising program code instructions for executing the steps of the process according to the first object, according to the second object or according to the third object, when this program is executed by at least one processor.

[0033] A fifth object is a hardware token, such as a smart card, comprising: a memory for storing a secret to prove possession of digital assets; a communication interface for communicating with a device separate from the hardware token; and at least one processor configured to save the secret via the saving process according to the first object, and / or retrieve the secret via the retrieval process according to the second object. DESCRIPTION OF THE FIGURES

[0034] Other features, objectives and advantages of the invention will become apparent from the following description, which is purely illustrative and not limiting, and which should be read in conjunction with the accompanying drawings on which:

[0035] Fig. 1 and Fig. 2 schematically illustrate a system for saving and retrieving a secret, according to one embodiment.

[0036] The [Fig.3] is a flowchart of steps of a secret safeguarding process, according to one embodiment of the invention.

[0037] Fig. 4 is a flowchart of steps of a secret recovery process, according to one embodiment of the invention.

[0038] The [Fig.5] is a flowchart of steps of a secret safeguarding process, according to another embodiment of the invention.

[0039] Fig. 6 is a flowchart of steps of a secret recovery process, according to another embodiment of the invention.

[0040] Throughout the figures, similar elements bear identical references. DETAILED DESCRIPTION OF THE INVENTION 1) System

[0041] With reference to Figure 1, a system for saving and restoring a secret, denoted seed, includes a hardware token 1, a terminal 2 and optionally a server 3.

[0042] The secret seed serves to prove ownership of digital assets. In one embodiment, the digital assets are cryptocurrency (e.g., bitcoins), and the secret seed is used to derive an arbitrary number of keys, these keys being used to carry out transactions. A cryptocurrency transaction, in particular a cryptocurrency transfer, cannot be carried out without knowing the associated private key. 1.1) Physical token

[0043] With reference to [Fig.2], the hardware token 1 comprises a biometric sensor 10, a memory 12, a processor 14 and a communication interface 16.

[0044] The biometric sensor 10 is configured to generate a biometric template relating to an individual who possesses the hardware token 1. For example, the biometric sensor 10 is a fingerprint sensor, presenting a surface on which the user can place their finger for this acquisition.

[0045] Memory 12 is a non-volatile memory intended to persistently store the secret seed and other data. Preferably, memory 12 is part of a secure element (referred to in the literature as a "secure element"). In this case, memory 12 is protected against reading and modification by means of physical countermeasures.

[0046] Because the secret seed is stored in its memory 12, the hardware token 1 can sometimes be called a "hardware wallet". However, it should be noted that the digital assets to which the secret relates are not themselves stored by the hardware token 1; the hardware token 1 can in fact to limit themselves to storing the right to use them (the secret). For example, when digital assets are cryptocurrency, they are stored in a chain of blocks ("blockchain"), which is actually a database distributed across several network devices.

[0047] Among the other data stored in memory, there is buK master data, including at least one master key.

[0048] The hardware token 1 can be part of a fleet of hardware tokens that store the same master keys. Even though these keys are common between these hardware tokens, they constitute secret data stored in the hardware tokens during factory configuration, and are not intended to be communicated to other devices during their subsequent use.

[0049] Memory 12 also stores a BioRef reference biometric template relating to a reference individual, the reference individual being the legitimate holder of the hardware token 1.

[0050] The reference biometric template was written to memory 12 during a prior enrollment phase of the reference individual. It should be noted that this reference biometric template may have been generated by the hardware token 1, typically by its processor 14, from one or more biometric image(s) acquired by the biometric sensor 10 of the hardware token 1, but not necessarily. The reference biometric template may indeed have been generated by another device or by the hardware token 1, from one or more biometric image(s) acquired by another device, typically the other device, and then transmitted to the hardware token 1 via its communication interface 16.

[0051] The reference biometric template is called a "template" in English. The generation of a biometric template from one or more biometric image(s) is known from the prior art.

[0052] Memory 12 also stores a backup program and / or a recovery program comprising instructions of code executable by the processor.

[0053] The processor 14 of the hardware token 1 is configured to execute the program or programs. This execution causes the implementation of steps of a backup and / or recovery process which will be described later.

[0054] The communication interface 16 is suitable for communicating with the terminal 2. The communication interface 16 may include a port for electrical connection with a port of terminal 2, or with a port of an interconnecting device intended to interconnect the hardware token 1 and terminal 2. Alternatively or as a complement, the communication interface 16 includes a chip or antenna to establish a wireless radio communication channel with terminal 2 (NFC or Bluetooth for example).

[0055] In one embodiment, the physical token 1 is a smart card. 1.2) Terminal

[0056] Terminal 2 includes a first communication interface 20 for communicating with the hardware token 1, a memory 22, a processor 24, a human-machine interface 26, and, optionally, a second communication interface 28 for communicating with the server 3.

[0057] The first communication interface 20 is designed to communicate with the communication interface of the hardware token 1 (via electrical contact and / or radio waves, for example, NFC). When the hardware token 1 is a smart card, the terminal 2 may include a slot into which the smart card can be inserted to establish an electrical contact between the port of the hardware token 1 and a port of the terminal 2. In another embodiment, the communication interfaces 16 and 20 are not of the same type, but an interconnecting device may be used to interconnect them. The interconnecting device may include a first port designed to be electrically connected to the communication interface 16 and a second port designed to be electrically connected to the communication interface 20.For example, when the hardware token is a smart card, the interconnect device includes a slot into which the card can be inserted to establish a connection with the first port, and the second port is a USB port.

[0058] Memory 22 also stores an application comprising code instructions executable by processor 24.

[0059] Processor 24 is configured to execute the application. This execution causes the implementation of steps which will be described later.

[0060] The human-machine interface 26 includes an output device, typically a display screen, for providing information to a user.

[0061] The human-machine interface 26 further includes an input device enabling a user of the terminal 2 to detect user actions that may be processed by the application during its execution. For example, the input device is or includes a touch-sensitive element, forming a touchscreen with the display screen.

[0062] Terminal 2 is for example a generic smartphone or laptop computer, customized with the aforementioned program.

[0063] The second communication interface 28 may be identical or different from the first communication interface 20. The second interface is of any type, wired (Ethernet) or wireless radio (cellular, Wi-Fi, etc.). 1.3) Server 3

[0064] Server 3 is an optional component of the system. Server 3 includes a communication interface 30, a memory 32 and a processor 34.

[0065] The communication interface 30 is suitable for communicating with the second communication interface of terminal 2.

[0066] The memory stores a program comprising code instructions executable by the processor 34.

[0067] Processor 34 is configured to execute the program. This execution causes the implementation of steps which will be described later in section 4).

[0068] 2) Methods for saving and recovering a secret - first method of realization

[0069] We will now describe a method for safeguarding the secret and a method for recovering the secret, according to one embodiment. 2.1) Safeguarding secrecy

[0070] With reference to [Fig. 3], the backup process according to the first embodiment comprises the following steps. Unless explicitly stated otherwise, the steps described below are implemented or caused by processors 14, 24.

[0071] It is assumed that the secret seed was stored in memory 12 during a prior configuration phase of the hardware token 1, known from the prior art.

[0072] It is also assumed that the reference individual has in his possession the hardware token 1 as well as the terminal 2. He is the legitimate holder of the digital assets associated with the secret seed.

[0073] In a step 200, terminal 2 detects that the reference individual requests the execution of a backup of the secret stored in the hardware token 1. For example, this request is made through a dedicated button or menu of the application, displayed on the display screen of terminal 2, and which the reference individual has pressed.

[0074] In step 202, terminal 2 sends a request to hardware token 1 to save the secret. The request is transmitted via a communication channel previously established between the communication interface 16 of hardware token 1 and the first communication interface 20 of terminal 2.

[0075] In a step 100, the hardware token 1 receives the save request via its communication interface 16; the save request is transmitted to the processor 14.

[0076] In step 102, the hardware token 1 generates a random number, denoted div hereafter. The random number is a random or pseudo-random value intended to change with each new implementation of this step.

[0077] In a diversification step 104, the processor generates dbuk\, dbukl, and dbuKi keys from the master data buK stored in memory. An embodiment in which the master data includes Three distinct master keys, denoted buK1, buK2, and buKi. However, it should be kept in mind that the master data buK can consist of a single master key; in other words, buK = buK1 = buK2 = buKi. More precisely, buKi is an encryption key generated by processor 14 from the master key buK1 and the random div. In fact, this generation is a diversification operation of the master key buK1 using the random div, which acts as a diversifier.

[0078] We can therefore write:

[0079] dbuKi = Diversify (buKi, div)

[0080] where Diversify is a cryptographic diversification function.

[0081] Furthermore, dbuK2 is an encryption key, different from dbuK1, generated by processor 14 from the master key buK2 and the random div. This generation is a diversification operation of the master key buK2 using the random div.

[0082] We can therefore write:

[0083] dbuK2 = Diversify(buK2, div)

[0084] Furthermore, dbuKi is an authentication key, different from dbuKi and dbiiKl, generated by processor 14 from the master key buKi and the random div. This generation is a diversification operation of the master key buKi using the random div.

[0085] We can therefore write:

[0086] dbuKi = Diversify(buKi, div)

[0087] The preceding diversifications allow the keys used for different successive backups performed by the hardware token 1 to be varied, without consuming much memory since all the generated keys are obtained from the buK data. This variation improves the level of confidentiality of the backup.

[0088] In the embodiment discussed above, the same diversification function Diversif y and the same random number div are used to produce the keys dbuK 1, dbuK2 and dbuKi. But in other embodiments, different diversification functions and / or different random numbers may be used.

[0089] Furthermore, in the case where the master data consists of a single master key (buK = buKi-buK2 = buKi\), then one of the following situations may arise: • dbuK 1 and dbuK2 are the same key; see • dbuK 1, dbuK2 and dbuKi are the same key (in this case, an authenticated encryption function, such as GCM# or CCM, can be used).

[0090] In a step 106, the hardware token 1 reads the BioRef biometric template relating to the reference individual, which is stored in its memory 12.

[0091] In an encryption step 108, the processor 14 encrypts the reference biometric template BioRef using the encryption key dbuK\, thus producing a first ciphertext cl. This operation can be written as:

[0092] c 1 - Enc (dbuK 1, BioRef)

[0093] where Enc denotes a cryptographic encryption function.

[0094] Furthermore, in an encryption step 110, the processor 14 encrypts the secret seed using the encryption key dbuKl, thus producing a second ciphertext c2. This operation can be written as:

[0095] cl = Enc (dbuKl, seed)

[0096] In the embodiment discussed above, the same Enc encryption function is used in both encryptions. In other embodiments, different encryption functions could be used to encrypt the secret and the biometric reference template.

[0097] These ciphers 108, 110 can be symmetric ciphers, in which case the encryption keys dbuK\ dbuKl used also constitute decryption keys.

[0098] The 108, 110 ciphers can be implemented in any order.

[0099] In a step 112, the processor 14 generates a backup, denoted BU, from the first cipher cl and second cipher cl.

[0100] The BU backup also includes an authentication code M that can be used to check the integrity of the backup, in particular to verify that the backup as generated by the hardware token 1 has not undergone any modification, for example after a transmission.

[0101] The BU backup generation 112 may, for example, comprise a concatenation of the following data: the first ciphertext cl, the second ciphertext c2, each random number used (here, the random number div), and the authentication code M. In this case, the BU backup may be the result of this concatenation, or a data point obtained from this concatenation. Such a data point is, for example, representative of a two-dimensional barcode, such as a QR code; this data point is obtained by an encoding known from the prior art, which can be applied to the aforementioned concatenation result.

[0102] It will be noted that the use of a single random div to diversify the master buK data, in accordance with the embodiment described above, makes it possible to advantageously reduce the size of the backup, compared to solutions using several diversifying randoms.

[0103] In a step 114, the hardware token 1 sends the backup BU to terminal 2.

[0104] In step 204, terminal 2 receives the BU backup.

[0105] Terminal 2 can then store this backup in its memory 22, or transmit it to a third-party storage device. 2.2) Retrieving the secret

[0106] We will now describe a method for recovering a secret seed previously saved via the method described above in section 2.1, with reference to [Fig.4],

[0107] It should be noted that saving and retrieving are processes that are implemented at different times, and that can be carried out by the same hardware token 1, or by different hardware tokens. In particular, a user may have made a backup of the secret seed that was stored in a first hardware token 1, and then find themselves in a situation where they need a second hardware token 1, different from the first hardware token 1, to retrieve the secret seed, for example, due to the loss or theft of the first hardware token 1.

[0108] In what follows, we will assume that the recovery process is implemented by the hardware token 1 on the basis of a backup BU' accessible by the terminal 2 (either because this backup is stored in the memory of the terminal 2, or because the terminal 2 is able to recover the backup stored by a third-party device).

[0109] In a normal situation, the backup BU' is the backup BU, resulting from the backup process described above. However, in an abnormal situation, the backup BU' results from an alteration of the backup BU, and this possibility must be taken into account during the recovery process.

[0110] In a step 250, the application detects that an individual, conventionally called a "test individual", requests the retrieval of a secret seed' based on the backup BU' in the hardware token 1. For example, this request is made through a dedicated button or menu of the application, displayed on the display screen, and which the test individual has pressed.

[0111] In a step 252, terminal 2 sends to hardware token 1 a retrieval request with the backup BU', via a communication channel previously established between the communication interface 16 of hardware token 1 and the first communication interface 20 of terminal 2.

[0112] In a step 150, the hardware token 1 receives the retrieval request and the backup BU'.

[0113] In step 152, the processor 14 extracts from the backup BU': a first ciphertext cl', a second ciphertext c2, a random number div', and an authentication code M'. The extraction is a reciprocal operation of the backup generation step 112 as discussed previously. Under these conditions, if we assume that the backup being extracted is indeed identical to the backup BU generated in step 112, then the processor will retrieve the first ciphertext cl, the second encrypted c2, the random div and the authentication code M generated during the backup process.

[0114] In a step 154, the processor 14 generates a first decryption key dbuKV to decrypt the first ciphertext from the master key buKl, a second decryption key dbuK2' to decrypt the second ciphertext from the master key buKl, and an authentication key dbuKi' to control the integrity of the backup BU'.

[0115] These keys are generated in the same way as in step 104 of the backup process. Thus:

[0116] dbuKV = Diversif yibuKl, div')

[0117] dbuKT = Diversify{buK2, div')

[0118] dbuKi' = DiversifylbuKi, div')

[0119] Thus, the master keys used during the backup are reused during the recovery, but the random div' involved in the recovery is that extracted from the BU' backup.

[0120] In step 156, the processor checks the integrity of the backup BU' using the authentication code M' and the key dbuKi'. The implemented integrity check is known from the prior art. The result of this integrity check is stored by the hardware token; this result is positive when the backup BU' is considered intact, and negative when the backup BU' is considered incomplete.

[0121] In step 164, the processor decrypts the first ciphertext cl' using the first decryption key dbuKV, the result of this decryption being interpreted by the hardware token 1 as a biometric template BioRef', which is conventionally called the "saved biometric template". The decryption function used is an inverse function of the encryption function used to encrypt a biometric template during saving.

[0122] In an acquisition step 166, the biometric sensor 10 acquires a biometric proof template Bio relating to the test individual. For example, the application prompts the test individual to place their finger on the biometric sensor 10 in a message displayed on the terminal 2 display screen, so that this acquisition step takes place. The biometric sensor 10 then acquires a proof image relating to the test individual, and the hardware token generates a biometric proof template from the biometric proof image.

[0123] In step 168, the processor 14 checks whether the saved biometric template BioRef' and the proof biometric template Bio match. This check aims to determine whether the two templates relate to the same individual. This check is known from the prior art.

[0124] If the saved biometric template BioRef' and the proof biometric template Bio match and if in addition the result of the integrity check is positive (case "OK"), then the processor decrypts in a step 172 the second cipher c2' using the second decryption key dbuK2\ the result of this decryption being interpreted by the hardware token 1 as a secret seed' proving a possession of digital assets.

[0125] Next, the processor 14 causes a memorization of the secret seed' in the memory 12 of the hardware token 1 (step 174).

[0126] Conversely, if the saved biometric template BioRe f' and the proof biometric template Bio do not match, or if the integrity check result is negative (the "NOK" case), then the processor 14 increments a recovery error counter in the memory of the hardware token 1 (step 158), and then compares the counter with a predefined threshold N (step 160). N is an integer greater than or equal to 1.

[0127] If the counter equals the threshold N, then the processor causes a block on the hardware token 1, so as to prevent any use of the hardware token 1 in a digital asset transfer (step 162). In other words, if the counter equals the threshold N, then the processor causes a block on the hardware token 1, so as to prevent any secret retrieval from this hardware token 1. We are indeed in a situation where N errors have been detected, which is interpreted as a situation in which the hardware token 1 is under attack.

[0128] If the counter is not equal to the threshold N, then the process proceeds to step 173 during which the hardware token generates a dummy secret seed, for example, randomly. This incorrect secret will not allow transactions to be carried out. This offers a compromise between security and user experience.

[0129] Next, the processor 14 causes a memorization of the secret seed' in memory 12 of the hardware token 1 (step 174).

[0130] The steps described above can be implemented in different orders. In particular, the acquisition step 166 could be carried out before the integrity check 156, or even before the key generation step, but it may be more advantageous to carry it out after the integrity check 156 for the purpose of saving processing time (in the event of blocking of the hardware token 1 or in the event of stopping the recovery process on detection of lack of integrity, the acquisition would be carried out in pure loss).

[0131] The embodiment described above is a symmetric embodiment. Indeed, if we assume that BU = BU' (in other words: the backup processed during the recovery procedure is indeed the result of an implementation of the backup procedure described in section 2.1), then the keys used during recovery are the same as the keys used during the previous backup:

[0132] dbuKV = dbuKi

[0133] dbuKT = dbuK2

[0134] dbuKi' -dbuKi

[0135] 3) Method for saving and retrieving the secret - second mode of realization

[0136] A backup method and a recovery method according to a second embodiment differ from the methods described in section 2 by the following characteristics.

[0137] During the backup process, the hardware token 1 receives a PIN code entered by the reference individual, typically via the input interface of terminal 2. The PIN code is used in the generation of at least one of the dbuKi, dbuK2, dbuKi keys involved in the backup. The PIN code can be received at the same time as the backup request at step 100, or at a different step.

[0138] During the retrieval process, the hardware token 1 receives a proof PIN entered by the proof individual, typically via the input interface of terminal 2. The proof PIN, denoted PIN', can be received at step 150 or at a different step. The PIN' is used in the generation of at least one of the dbuK 1', dbuKT, dbuKi' keys involved in the retrieval.

[0139] Incorporating the PIN code improves the security of these processes. Indeed, the PIN code used during the backup is additional information that an attacker must know to hope to hack the system.

[0140] For example, in a particular variant of this second embodiment, the following diversification treatments can be modified as follows.

[0141] At the backup stage:

[0142] dbuK2 = Diversify (buK2, div+PIN)

[0143] At the recovery stage:

[0144] dbuKT - Diversify (buK2, div' + PIN')

[0145] The use of the PIN code amplifies the diversification carried out to obtain the second encryption key buK2 used to encrypt the secret.

[0146] 4) Secret backup and recovery method - third mode of realization

[0147] A backup method (illustrated in [Fig.5]) and a recovery method (illustrated in [Fig.6]) according to a third embodiment use the server 3 in addition to the hardware token 1 and the terminal 2.

[0148] Two pairs of asymmetric keys are used in addition to the keys mentioned above, in order to secure data exchanged between the hardware token 1 and the server 3 via the terminal 2: • a key pair (skW, pkW) specific to hardware token 1, comprising a private key skW stored by hardware token 1 (and unknown to any other device), and a public key pkW which server 3 knows. • a key pair (skS, pkS) specific to server 3, comprising a private key skS stored by server 3 (and unknown to any other device) and a public key pkS which the hardware token 1 pkS knows.

[0149] Server 3 can access an idW, pk\\ database relating to a fleet of hardware tokens, where the idWs are the respective identifiers of the hardware tokens. This database is populated as hardware tokens are produced. In this case, server 3 retrieves the pkW public key that is associated with the idW identifier of hardware token 1 from the database.

[0150] As an alternative to such a database, a certificate (for example, of type x509) is generated and stored in the hardware token 1 during its production. The certificate establishes a link between the public key pkW and the identifier idW specific to the hardware token. Using this certificate, the server 3 can verify that the key pkW is indeed the public key of the token associated with the identifier idW.

[0151] The pkS key may be written into the hardware token 1 during its production. Alternatively, it could be sent to the hardware token via a certificate.

[0152] During the backup, the processor 14 of the hardware token 1 encrypts the backup BU using the public key of the server 3 pkS, so as to obtain a backup in encrypted form (step 113). It is in this encrypted form that the backup BU is sent to terminal 2 in step 114.

[0153] During recovery, the following additional steps are implemented.

[0154] After detecting a retrieval request (step 250), terminal 2 sends a retrieval request to server 3 including the backup in its encrypted form and an identifier of hardware token 1 (or the aforementioned certificate), in step 251. Terminal 2 can query hardware token 1 to obtain this identifier (or certificate).

[0155] Server 3 is used by performing the following steps.

[0156] In a step 300, server 3 receives the retrieval request and saves it in encrypted form.

[0157] In a step 302, server 3 decrypts the backup in encrypted form using its private key skS, so as to recover the BU backup.

[0158] In a step 304, server 3 re-encrypts the BU backup, but this time with the pkW public key of hardware token 1, thus obtaining a backup in re-encrypted form.

[0159] In step 306, server 3 sends the backup in re-encrypted form to terminal 2.

[0160] During step 252, it is the backup in re-encrypted form which is sent by terminal 2 to hardware token 1, after having been received by terminal 2.

[0161] On the hardware token 1 side, the processor 14 implements a step 151 of decrypting the backup in re-encrypted form, using its private key skW, which allows the hardware token 1 to retrieve the backup BU'. The other processing steps described previously can then be implemented by the hardware token 1 on the basis of the backup BU'.

[0162] The preceding additional features have various advantages.

[0163] First, these features provide an additional layer of security, since an attacker will have to obtain at least one of the skW and skS private keys to try to obtain the secret corresponding to a backup.

[0164] Secondly, using server 3 lengthens the total duration of the recovery process, which makes it possible to ensure more effective protection against brute-force attacks, which would consist of carrying out a very large number of recovery attempts based on different biometric proof templates for the same BU backup.

[0165] Furthermore, the recovery process of this embodiment may further include an additional step of checking the validity of the recovery request implemented by server 3 (step 303).

[0166] During this 303 validity check, server 3 increments a request counter associated with the encrypted backup, then checks if the request counter has reached a threshold representing a maximum number of admissible requests.

[0167] If the threshold is not reached, server 3 applies the re-encryption step discussed previously.

[0168] If the threshold is reached, server 3 does not implement the re-encryption step, and may instead return an error message to terminal 2, so that the recovery process is not completed.

[0169] Step 303 thus makes it possible to better protect the system against brute-force attacks, because an attacker will not be able to carry out repeated attempts in large numbers, in particular by using several hardware tokens 1.

[0170] 5) Other aspects / other embodiments and variants

[0171] The recovery process can be artificially slowed down by a method other than by soliciting the server 3: by means of a dummy processing step, carried out by the hardware token 1. This dummy processing step does not change the output of the recovery process in any way, but lasts for a certain number of processor cycles.

[0172] Although advantageous, the authentication code is optional. The BU backup can therefore be performed without an authentication code.

[0173] In the embodiments described above, the backup method separately encrypts the reference biometric template BioRef and the secret seed, and the recovery method performs two decryptions to obtain the backed-up template BioRef' and the secret seed'. In other embodiments, the backup method could encrypt the reference biometric template BioRef and the secret seed in a single encryption step, and the recovery method could perform a single decryption to obtain the backed-up template BioRef' and the secret seed'.

[0174] Furthermore, it was considered above that a lack of integrity ("KO") detected during step 160 does not necessarily interrupt the recovery process, as this process may even result in a fictitious secret; thus, the test individual is not alerted to any error during the recovery process (except in the specific case where the error counter has reached its maximum N). In other embodiments, the recovery process may stop, or the signing device may be blocked regardless of the circumstances upon detection of a lack of integrity.

[0175] Furthermore, we saw earlier that decrypting the secret (step 172) could be carried out under certain conditions. Alternatively, these conditions could be applied to the subsequent step of storing the generated secret seed in memory (12). In other words: • if the saved biometric template BioRef' and the proof biometric template Bio match and if the integrity check result is OK, then the hardware token processor 1 causes the secret seed' to be stored in memory 12, which is non-volatile. • If the saved biometric template BioRef' and the proof biometric template Bio do not match, or if the integrity check result is NOK, then the processor of hardware token 1 does not cause the secret seed' to be stored in any non-volatile memory of hardware token 1. The secret seed' obtained by decryption is then only stored temporarily in volatile memory of hardware token 1 or a register of processor 14, and will be lost as soon as hardware token 1 is powered off.

[0176] The use of randomness is also advantageous for the security of backup and recovery processes, but remains optional. The hardware token could simply use the same encryption / decryption keys without diversifying them. A single key (diversified or not) can even be used to encrypt everything during the backup process. Furthermore, it is possible to use counters as diversifiers instead of randomness.

[0177] In the third embodiment using server 3, the two pairs of asymmetric keys can be replaced by symmetric keys. Thus, it can be provided that skW = pkW (the same key is used on the hardware token 1 side for encryption and on the server 3 side for decryption) and / or that skS - pkS (the same key is used on the server 3 side for encryption and on the hardware token 1 side for decryption).

Claims

Demands

1. A method for safeguarding a secret (seed) stored by a hardware token such as a smart card, the secret enabling proof of possession of digital assets, the method comprising the following steps implemented by the hardware token: • encryption (108) of a reference biometric template stored by the hardware token relating to a reference individual and the secret, so as to produce encrypted data (cl, c2), • generation (112) of a backup (BU) from the encrypted data, • sending (114) of the backup to a device separate from the hardware token.

2. A method according to the preceding claim, comprising steps of: • encryption (108) of the biometric reference template so as to produce a first ciphertext (cl), • encryption (110) of the secret (seed) so as to produce a second ciphertext (c2), and generation (112) of the backup (BU) from the first ciphertext (cl) and the second ciphertext (c2).

3. A method according to the preceding claim, wherein • the encryption of the biometric template is carried out using a first encryption key, and • the encryption of the secret is carried out using a second encryption key different from the first encryption key.

4. A method according to the preceding claim, wherein: • the first encryption key is generated by the hardware token from a first master key and from a first diversifier, • the second encryption key is generated by the hardware token from a second master key and from a second diversifier, and • each diversifier is included in the backup.

5. A method according to the preceding claim, wherein: • the second master key is different from the first master key, and • the first diversifier and the second diversifier are one and the same diversifier included in the backup.

6. A method according to any one of claims 3 to 5, wherein at least one key among the first encryption key and the second encryption key is generated from a PIN entered by the reference individual.

7. A method according to any one of the preceding, wherein the backup includes an authentication code generated from the encrypted data, the authentication code being usable to control the integrity of the backup.

8. A method according to the preceding claim in its dependency claim 3, wherein the authentication code is generated using an authentication key different from the first encryption key and the second encryption key.

9. A method according to the preceding claim, wherein • the authentication key is generated using a master key of the hardware token and from an authentication diversifier, • the authentication diversifier is included in the backup.

10. A method according to the preceding claim in its dependence on any one of claims 4 and 6, wherein: • the first diversifier and the authentication diversifier are one and the same diversifier included in the backup, or • the second diversifier and the authentication diversifier are one and the same diversifier included in the backup.

11. A method according to any one of the preceding claims, wherein the backup is encoded in the form of a two-dimensional barcode.

12. A method for recovering a secret (seed) to prove possession of digital assets, the method comprising the steps the following implemented by a hardware token such as a smart card: • reception (150) of a backup (^^') from a device separate from the hardware token, • decryption (164, 172) of the backup, so as to retrieve a saved biometric template (BioRef>) and the secret (seed\ • acquisition (166) of a proof biometric template (Bio) by a biometric sensor of the hardware token, the proof biometric template relating to an individual, • verification (168) of correspondence between the saved biometric template (BioRef') and the proof biometric template (Bio\ • storage of the secret (seed') in a memory of the hardware token, • in which the decryption of the secret or the storage of the secret is carried out on the condition that the verification reveals that the saved template and the proof biometric template correspond.

13. A method according to the preceding claim, comprising the following steps: • decryption (164) of a first ciphertext extracted from the backup, so as to recover the saved biometric template (BioRef'), • decryption (172) of a second ciphertext extracted from the backup so as to recover the secret, wherein the decryption of the second ciphertext is carried out on the condition that the verification reveals that the saved template and the proof biometric template correspond.

14. A method according to the preceding claim, wherein • the decryption of the first ciphertext is carried out using a first decryption key, • the decryption of the second ciphertext is carried out using a second decryption key different from the first decryption key.

15. A method according to the preceding claim, wherein: • The first decryption key is generated by the hardware token from a first master key and from a first diversifier extracted from the backup, • The second encryption key is generated by the hardware token from a second master key and from a second diversifier extracted from the backup.

16. A method according to the preceding claim, wherein: • the second master key is different from the first master key, and • the second diversifier and the first diversifier are one and the same diversifier present in the backup.

17. A method according to any one of claims 14 to 16, wherein at least one key among the first decryption key and the second decryption key is generated from a proof PIN entered by the individual.

18. A method according to any one of 12 to 17, further comprising steps of • checking the integrity of the backup from an authentication code extracted from the backup, • blocking the hardware token provided that the integrity check reveals that the backup is not intact, the blocking preventing any transfer of digital assets using the hardware token.

19. A method according to the preceding claim in its dependence on claim 14, wherein the integrity control is implemented using an authentication key different from the first decryption key and the second decryption key.

20. A method according to the preceding claim, wherein • the authentication key is generated by the hardware token using a master key stored by the hardware token and from an authentication diversifier extracted from the backup.

21. A method according to the preceding claim in its dependence on any one of claims 15 to 17, in which • The first diversifier and the authentication diversifier are one and the same diversifier present in the backup, or • The second diversifier and the authentication diversifier are one and the same diversifier present in the backup.

22. A method according to any one of claims 12 to 21, comprising • a sham treatment to delay the recovery of the secret.

23. A method according to any one of claims 12 to 22, further comprising: • the following steps implemented by a server: • receiving a backup in encrypted form using a server-specific public key, • decrypting the backup in encrypted form using a server-specific private key, so as to obtain the backup, • using a hardware token-specific public key, re-encrypting the backup obtained after decryption using the server-specific private key, so as to obtain the backup in a re-encrypted form, the backup received by the hardware token being the backup in re-encrypted form, • the following step implemented by the hardware token: • decrypting the backup in re-encrypted form using a hardware token-specific private key,before the hardware token decrypts the backup to retrieve the saved biometric template (BioRef) and the secret (seed).

24. A method comprising: • saving a secret stored by a first physical token via the method according to any one of the claims 1 to 11, the secret enabling proof of possession of digital assets, • recovery of the secret by a second hardware token via the method according to any one of claims 12 to 23.

25. Product computer program comprising program code instructions for carrying out the steps of the process according to any one of the preceding claims, when such program is executed by at least one processor.

26. Hardware token (1), such as a smart card, comprising: • a memory for storing a secret enabling proof of possession of digital assets, • a communication interface for communicating with a device separate from the hardware token, • at least one processor configured to save the secret via the method according to any one of claims 1 to 11, and / or retrieve the secret via the method according to any one of claims 12 to 23.

Images