Method for securing a firmware update

Abstract

The invention relates to a method for securing the installation and updating of a firmware in a program memory of a processor, comprising the steps of installing in the program memory of the processor a first version of the firmware (DB3N, DB4N) comprising an executable code (DB1N) a first public key (PKN), and upon receipt of an installation command in the program memory of a second version of the firmware (DB3N+1, DB4N+1), verifying the validity of an authentication signature (SIGNN+1) of the second version of the firmware by means of the first public key (PKN) present in the first version (DB3N+1, DB4N+1) of the firmware and from a first data block (DB2N+1) of the second version of the firmware comprising at least a second public key (PKN+1), and rejecting the installation command if the authentication signature of the second version of the firmware is not valid,the authentication signature of the second version of the firmware being generated by means of a first private key (pKN) corresponding to the first public key (PKN), and from the first data block of the second version of the firmware. Fig. 8B,

Description

Title of the invention: Method for securing the updating of a firmware Technical field

[0001] The present invention relates to a method for securing the installation and updating of a firmware in a program memory of a processor, and a processor comprising a first version of a firmware installed in a program memory of the processor. Background

[0002] Hardware Security Modules (HSMs) are hardened, tamper-resistant physical devices that secure cryptographic processes by generating, protecting, and managing keys used for encrypting and decrypting data and creating digital signatures and certificates. Hardware Security Modules are tested, validated, and certified to the highest security standards. They have become essential tools for enhancing data and transaction security in various environments and applications.

[0003] Hardware security modules are used in financial or crypto-asset management applications, to secure transactions and sensitive data, for identity management and authentication of individuals, to secure the issuance and management of digital certificates and authentication keys, for the encryption of databases and archives, to secure network communications, and finally to manage keys and certificates in public key infrastructures (PKI).

[0004] Regular maintenance of a hardware security module, which includes updating its firmware, is essential to ensure that it remains protected against new vulnerabilities and threats. In this regard, the person operating a hardware security module must be assured that each new version of the firmware communicated to him is authentic and has not passed into the hands of a fraudster. To this end, each new version or update is generally delivered accompanied by a signature generated by the designer using a private key known only to him. Before installing this update, the operator verifies the validity of this signature using a public key communicated to him by the designer.

[0005] This method provides a guarantee to the operator that the firmware was produced by the approved designer, thanks to the latter's communication of the corresponding public key. On the other hand, it does not allow the designer to ensure that the micro program and its subsequent updates, are correctly implemented by the operator. In particular, the administrator of a hardware security module generally has full rights over its program memory. A person who manages to steal its access codes could make changes to the firmware aimed at altering its operation, or even replacing it with a corrupted version.

[0006] Furthermore, in some applications, the firmware designer uses the hardware security module for his own needs as part of a service he offers to the public, but uses third-party partners to deploy this service. In this case, the firmware is used by the third-party partners in their own computing environments, which are not under the designer's control. It is therefore essential, particularly when an update is sent to a third-party partner, that the designer can ensure that no one at the third-party partners will be able to take advantage of it to tamper with the program memory of the system concerned.

[0007] However, it is known that securely updating a system remotely can be difficult when the underlying operating system, which is responsible for checking updates, is not fully reliable for this task. In particular, operating systems of hardware security modules are generally not protected against insider threats when signing firmware or insider threats when installing firmware. Another type of attack that may be feared, called a "rollback attack", consists of installing a previous version with a security vulnerability.

[0008] It might therefore be desirable to provide a means of securing firmware updates and ensuring that no one can take advantage of these operations to corrupt the operation of a processor such as a hardware security module.

[0009] More particularly, it might be desirable to provide a method for securing the updating of a firmware, making it possible to ensure, after the installation of an initial version of the firmware, that all subsequent versions will be installed without the possibility for a person holding administrator access codes to erase the firmware or to modify it, or even to downgrade it.

[0010] It might also be desirable to provide a method for authenticating successive versions of a computer file, in particular a firmware file, in a simple and efficient manner, and a method for manufacturing different versions of a computer file linked together by an authentication link. Summary

[0011] Embodiments relate to a method for securing the installation and the updating a firmware in a program memory of a processor, the method comprising the steps of installing in the program memory of the processor a first version of the firmware comprising an executable code a first public key; and, upon receipt of a command to install in the program memory a second version of the firmware intended to overwrite the first version of the firmware and comprising an executable code, a second public key and an authentication signature of the second version of the firmware: verifying the validity of the authentication signature of the second version of the firmware by means of the first public key present in the first version of the firmware and from a first data block of the second version of the firmware comprising at least the second public key,and rejecting the installation command if the authentication signature of the second firmware version is invalid, the authentication signature of the second firmware version being generated using a first private key corresponding to the first public key present in the first firmware version, and from the first data block of the second firmware version comprising at least the second public key.

[0012] According to one embodiment, the method comprises the step of providing a protection module in the first version of the firmware, and the steps of sending to the protection module any installation command in the program memory of a new version of the firmware, and by means of the protection module, ensuring the verification of the validity of the authentication signature of the second version of the firmware, and refusing the execution of the installation command if the signature is not valid, so that after installation of the first version of the firmware in the program memory, the first version of the firmware is self-protected by the protection module and can only be replaced by a second version of the firmware comprising an authentication signature recognized as valid by the protection module.

[0013] According to one embodiment, the first and second versions of the firmware are provided by a first party holding the first private key and having generated the authentication signature of the second version of the firmware, and the first and second versions of the firmware are installed in the memory of a processor owned and operated by a second party not having knowledge of the first private key, such that the second party, once the first version of the firmware is installed, cannot replace the first version of the firmware with a version which does not include a valid authentication signature generated using the first private key.

[0014] According to one embodiment, the first data block of the second version of the firmware also comprises the executable code of the second version of the firmware.

[0015] According to one embodiment, the first data block of the second firmware version also comprises a firmware version number, the method comprising the step of checking the version number of the second firmware version and refusing to update the first firmware version if the second firmware version is not a later version of the first firmware version.

[0016] According to one embodiment, the first data block of the second version of the firmware also comprises markers making it possible to distinguish metadata concatenated with the executable code of the firmware, the method comprising the step of refusing to update the first version of the firmware if the markers are not identified.

[0017] According to one embodiment, the second public key is identical to the first public key.

[0018] According to one embodiment, the second public key is different from the first public key.

[0019] According to one embodiment, the second version of the firmware further comprises an installation signature generated by means of a private installation key and from a second data block comprising at least the executable code of the second version of the firmware and the authentication signature, and the installation of the second version of the firmware comprises a step of providing the processor with a public installation key corresponding to the private installation key, and a step of verification by the processor, by means of the public installation key, of the validity of the installation signature.

[0020] According to one embodiment, the processor is a hardware security module, and the firmware is configured to receive and store secrets relating to cryptoasset accounts.

[0021] Embodiments also relate to a processor comprising a first version of a firmware installed in a program memory of the processor, the firmware comprising an executable code and a first public key, the processor being configured to, during the execution of the first version of the firmware and upon receipt of a command to install in the program memory a second version of the firmware intended to overwrite the first version of the firmware and comprising an executable code, a second public key and an authentication signature: verify the validity of the authentication signature of the second version of the firmware by means of the first public key present in the first version of the firmware and from a first data block of the second version of the firmware comprising at least the second public key, and rejecting the installation command if the authentication signature of the second version of the firmware is not valid, the authentication signature of the second version of the firmware being generated by means of a first private key corresponding to the first public key present in the first version of the firmware, and from the first data block of the second version of the firmware comprising at least the second public key.

[0022] According to one embodiment, the first version of the firmware comprises a protection module, the processor being configured to send to the protection module any installation command in the program memory of a new version of the firmware, and by means of the protection module, ensure the verification of the validity of the authentication signature of the second version of the firmware and refuse the execution of the installation command if this signature is not valid, such that after installation of the first version of the firmware in the program memory, the first version of the firmware is self-protected by the protection module and can only be replaced by a second version of the firmware comprising an authentication signature recognized as valid by the protection module.

[0023] According to one embodiment, the processor is configured to send to the protection module any command to erase the program memory, the protection module is also configured to reject any command to erase the program memory, and an administrator of the processor can neither erase the first version of the firmware nor replace it with a firmware that does not include an authentication signature generated using the first private key.

[0024] According to one embodiment, the first data block of the second version of the firmware also comprises the executable code of the second version of the firmware.

[0025] According to one embodiment, the first data block of the second firmware version also includes a firmware version number, the processor being configured to check the version number of the second firmware version and refuse to update the first firmware version if the second firmware version is not a later version of the first firmware version.

[0026] According to one embodiment, the first data block of the second version of the firmware also comprises markers making it possible to distinguish me- data concatenated to the executable code of the firmware, the method comprising the step of refusing to update the first version of the firmware if the markers are not identified.

[0027] According to one embodiment, the processor is configured not to check whether the second public key is identical to or different from the first public key.

[0028] According to one embodiment, the second version of the firmware further comprises an installation signature generated by means of a private installation key and from a second data block comprising at least the executable code of the second version of the firmware and the authentication signature, the processor being configured to, during the installation of the second version of the firmware, verify the validity of the installation signature by means of a public installation key corresponding to the private installation key.

[0029] According to one embodiment, the processor is a hardware security module.

[0030] According to one embodiment, the firmware is configured to receive and store secrets relating to crypto-asset accounts. Summary description of the drawings

[0031] These characteristics and advantages of the subject of the present disclosure will be better understood upon reading the following description of detailed exemplary embodiments, given without limitation in relation to the attached figures, among which:

[0032] - the previously described [Fig.l] shows steps of a manufacturing process classic firmware,

[0033] - [Fig.2] shows the classic software structure of a security module ma material,

[0034] - [Fig.3] shows steps of modification of the software architecture of a hardware security module to secure its updates,

[0035] - [Fig.4] shows the software structure of a secure hardware security module as illustrated in [Fig.3],

[0036] - [Fig.5] is a flowchart illustrating the processing of erase commands and updated by the secure hardware security module of [Fig.4],

[0037] - [Fig.6A] and [Fig.6B] illustrate an embodiment of a method of fa building successive secure versions of a firmware,

[0038] - [Fig.7] shows authentication steps of successive secure versions of the firmware,

[0039] - [Fig.8A] illustrates another embodiment of a method of manufacturing successive secure versions of a firmware,

[0040] - [Fig.8B] shows the structure of three successive versions of firmware secured according to the method of [Fig.8A],

[0041] - [Fig.9A] is a sequence diagram showing in more detail steps of the manufacturing process of [Fig.8A],

[0042] - [Fig.9B] describes the steps of [Fig.9A],

[0043] - [Fig.10A] is a sequence diagram showing steps in installing a initial version of a secure firmware in a hardware security module,

[0044] - [Fig.lOB] describes the steps of [Fig.lOA],

[0045] - [Fig. 11 A] and [Fig.l2A] are sequence diagrams showing steps installing a later secure firmware version,

[0046] - [Fig.llB] and [Fig.l2B] describe the steps of [Fig. 11 A] and [Fig.l2A], And

[0047] - [Fig. 13] shows a system architecture using security modules ma material secured in accordance with this disclosure. Detailed description

[0048] [Fig.l] schematically shows a conventional method for signing a firmware, intended for example to be installed in a hardware security module. A source code of the firmware FW is first transformed by an integration server BSRV0 ("Build Server") into object code or executable code forming a data block DB1, for example in ELF format (Executable and Linkable Format). An installation signature ISIGN is then calculated, by means of an installation private key IpK. For this purpose, the data block DB1 is applied to a hash function FH1 which provides a digest H1 thereof. The digest H1 and the installation private key IpK are applied to a signature function FS1 which provides the ISIGN signature. The operation can be carried out by a hardware security module HSMa, which provides the installation private key IpK as well as a corresponding installation public key IPK.The ISIGN signature is then concatenated with the DB1 data block preceded by a SIZE(ISIGN) field indicating the size of the signature, followed by an OID(FSl) field ("Object Identifier") giving information on the FS1 signature function used. The OID field is preceded by a SIZE(OID) field indicating the size of the OID identifier. A SIZE(DBl) field can also be inserted before the DB1 data block, to indicate its size.

[0049] The executable code DB1 concatenated with the metadata SIZE(DB1), SIZE(ISIGN), ISIGN, SIZE(OID) and OID(FS1) forms a final data block DBF which is provided to the operator of a hardware security module HSMo as the final firmware version. The installation public key IPK is also provided to the operator, who saves it in an administrator account of the hardware security module. At the time of firmware installation, the operating system of the hardware security module checks the validity of the ISIGN signature by means of the public key IPK installation, and refuses to proceed with this installation if the signature is found invalid.

[0050] For example, if the ISIGN signature is an RSA signature, the verification of the signature comprises the operations consisting on the one hand in finding the original digest H1 by providing a function FS1 1 inverse of FS1 with the data block DB1 and the public key IPK, and on the other hand calculating the digest H1' of the data block DB1 by means of the function FH1. The two digests are then compared (COMP). If the result of the COMP comparison is positive ("OK"), the operating system OS of the hardware security module HSMo agrees to load the microprogram into its program memory PMEM.

[0051] [Fig.2] shows the classic software architecture of the hardware security module HSMo. The latter is connected to an HDV host device such as a server, via a PCI (Peripheral Component Interconnect Express) or Ethernet connection. The host device executes a PGR application program that calls on the HSMo hardware security module to perform cryptographic calculations and store keys. For this purpose, the HDV device uses a standard SLIB1 library, for example the Cryptoki (Cryptography Token Interface Standard) library composed of PKCS#11 functions. It will be recalled here that the PKCS#11 standard is an API (Application Programming Interface) intended for cryptographic tokens such as hardware security modules and smart cards. The SLIB1 library provides standard functions to an MDA (Message Dispatch API) interface that sends SF standard function commands to the HSMo hardware security module via the PCI or Ethernet interface.

[0052] In the HSMo hardware security module, the standard SF function calls are received by a message processing module MPM0 (“Message Processing Module”) designed for example to process PKCS#11 functions. The MPM0 module transmits the function calls to a SLIB2 library of the OS operating system. The SLIB2 library is of the same nature as the SLIB1 library, for example a Cryptoki library. Among these standard functions, a function for erasing the PMEM program memory of the hardware security module and a function for updating the firmware present in the program memory are generally provided.

[0053] Thus, the hardware security module constitutes a sort of hardware extension of the HDV host device, providing hardware and software security against attacks, allowing sensitive data to be stored securely and cryptographic calculations to be carried out through a library of standard functions.

[0054] According to one aspect of the present disclosure, the processing of the erase and update functions of the hardware security module HSMo is modified by implementing in the operation of the machine a protection module PM which filters these two types of commands, likely to be used by a malicious person.

[0055] Various manufacturers of hardware security modules provide commands allowing the operation of hardware security modules to be modified by injecting user firmware ("custom firmware") that can modify the dispatching of messages received or implement proprietary commands. In relation to the software architecture that has just been described, the possibility is therefore often offered to add custom functions to the SLIB2 library or to modify the execution of standard functions. This is for example possible by means of the Cprov command with certain hardware security modules. In particular, in certain hardware security modules, the "OS_GetCprovFuncTable" function makes it possible to obtain the address of the structure of a Cprov function table used by a Cprov Filter component of the firmware.Changing the function addresses in the table allows custom functions to be called when the Cprov function is requested from the host side.

[0056] [Fig. 3] is a simplified flowchart describing steps of a method of implementing the PM protection module in the HSMo hardware security module. An embodiment of this method will be described in more detail in relation to FIGS. 10A, 10B.

[0057] In a step 101, the host device sends a call to the "Install Firmware" function to the hardware security module HSMo and provides it with a corrective firmware FW1. The command is received by the message processing module MPM0 and is passed on to the operating system OS. In a step 102, the operating system checks that the standard execution conditions for the installation function are met. In a step 103, the operating system installs and then executes the corrective firmware FW1. In a step 104, the firmware FW1 is executed and puts into service the protection module PM, which is an integral part of the firmware.At a step 105, the FW1 firmware then corrects the function allocation table of the message management module MPM0 so that the latter, upon receiving calls to the standard “erase” or “update” functions, passes them on to the PM protection module instead of addressing them directly to the SLIB2 library of the operating system. The message management module MPM0 in its modified version will now be designated MPM1.

[0058] Thus, the standard SF functions “program installation” and “program deletion” become modified PF functions (“Patched Functions”) which are processed by the PM protection module in the following manner:

[0059] - Deletion: prohibited;

[0060] - Installation: only if admissibility conditions are met (conditions managed by the PM protection module).

[0061] [Fig. 4] shows the software architecture of a hardware security module HSMp that has been modified as just described. The hardware security module is, as previously, connected to the HDV host device, the structure and operation of which are unchanged. The HDV host device sends commands for executing standard SF functions, or "function calls," to the hardware security module HSMp. Unlike the message processing module MPMO, the module MPM1 does not systematically send all received function calls to the SLIB2 library of the OS operating system. Since its function allocation table has been modified, the calls to the "erase" function and to the "update" function are sent to the protection module PM.Calls to the "erase" function are rejected by the PM protection module, while calls to the "update" function are processed to determine whether the admissibility conditions are met. If these conditions are met, the update request is transferred to the SLIB2 standard library for execution by the operating system, loading the update involving overwriting the current firmware version in the PMEM program memory.

[0062] [Fig. 5] is a flowchart illustrating the processing of function calls by the hardware security module HSMp. At a step E01, the message management module MPM1 receives a call to a function. At a step E02, the module MPM1 determines whether the command received relates to a modified function PF, namely erasing or updating the firmware (this step may be implicit and simply result from the modification of the function allocation table). If the response is negative, it is a standard function and the module MPM1 transmits the command to the library SLIB2 at a step E03. If the response is positive, at a step E04 the module MPM1 transmits the command to the protection module PM. At a step E05, the protection module PM determines whether the command received is a request to erase the program memory PMEM.If the response is positive, the PM protection module sends a refusal response to the message processing module MPM1. If the response is negative, which here means that the received command is a firmware update request, the PM protection module determines in a step E06 whether the conditions for admissibility of the command are met. If the response is negative, the PM protection module sends a refusal response to the message processing module MPM1. If the response is positive, the PM protection module transmits the command to the SLIB2 library in a step E07. In a step E08, the SLIB2 library checks whether the conditions for executing the modified PF or standard SF function are satisfied. If the response is negative, the SLIB2 library sends a refusal message to the message processing module MPM1. If the response is positive, the operating system executes the function in a step E09.

[0063] A method has been described in the above for modifying the processing of calls to functions to reject an erasure request and apply admissibility conditions to a request to update a firmware.

[0064] Another aspect of the present disclosure relates to a method for authenticating a firmware update, implemented by the PM protection module. The result of the authentication of the update is used by the PM module as a condition for the admissibility of an update request. In other words, the hardware security module will only agree to carry out an update if this update is deemed authentic according to the rules and steps defined by this method.

[0065] In some embodiments, such an authentication method uses a symmetric secret key that is provided to the HSMp hardware security module during the first installation of the corrective firmware FW1. This key is present only in the first installed version of the firmware and is saved by it in a secure memory of the HSMp hardware security module, which will not be erased during future updates. Then, each subsequent version of the firmware is provided with a signature thereof that is generated using this secret key. The PM module verifies that this signature is valid before accepting the installation of the update. In other embodiments, the authentication method uses a public key provided in the first corrective firmware, to verify the authenticity of the signature inserted in each subsequent update.This public key corresponds to a private key that is never revealed.

[0066] In an advantageous embodiment, an iterative authentication method is provided, which is based on the establishment of a chain of signatures between each version of the microprogram and the following version, so that from an initial version whose authenticity is assured or admitted, the chain of signatures of the subsequent versions certifies that all these versions are authentic.

[0067] According to this method:

[0068] - a single source for generating authentication key pairs is designated, each key pair comprising a public authentication key and a private authentication key. In the following examples, this single source is for example a college of APRV approvers which may comprise one or more people. In one embodiment, this college of approvers generates the key pairs by means of a hardware security module of its own, cited later in relation to figures 8, 9A, 9B with the reference HSM1a.

[0069] - for the installation of the first version of the firmware, the college approvers issue a first pair of authentication keys comprising a first public authentication key PKi and a first private key pKb authentication

[0070] - the first installed firmware version includes the first key public PKb Optionally, it can also include a SIGNi signature generated using the private key pKl and from a data block including the first public key PKI.

[0071] - the college of approvers issues a second pair of authentication keys comprising a second public authentication key PK2 and a second private authentication key pK2,

[0072] - a second version of the firmware, designed as an update of the first version includes the public key PK2 and a signature SIGN2 generated using the private key pKi and from a data block including at least the public key PK2,

[0073] - the authenticity of the second version of the firmware is verified by the first version of the firmware and more particularly, in the application considered here, by the PM protection module,

[0074] - verification of the authenticity of the second version of the firmware by the The first firmware version includes a step of verifying the SIGN2 signature using the PKi public key and from the data block of the second firmware version from which the SIGN2 signature was generated.

[0075] The same procedure is followed for each subsequent version of the firmware, as illustrated in FIGS. 6A and 6B. [Fig. 6A] illustrates a step of forming a version of rank N of the firmware. The firmware initially comprises executable code forming a data block DB1N. A pair of authentication keys of rank N1 comprising a public authentication key PKN i and a private authentication key pKx । has been previously generated by the college of approvers and associated with a previous version of rank N1 of the firmware, not shown. A pair of authentication keys of rank N comprising a public authentication key PKN and a private authentication key pKN is now generated by the college of approvers and is associated with the data block DB1N. The public key PKN is concatenated with the data block DB1N to form a data block DB2N.The DB2N data block is applied to a hash function FH2 which provides an H2N digest. The H2N digest and the private key pKx । are applied to a signature function FS2 which provides a signature SIGNN such that: .

[0076] SIGNn ^82^4]^) = FS2lpKN-1j(FH2(DB 1NIIPKN))

[0077] “It” representing the concatenation operation.

[0078] The SIGNn signature is then concatenated to the DB2N data block to obtain a DB3N data block which here forms the final version of the firmware, of which authenticity can be verified using the PKX public key । present in the previous firmware version.

[0079] [Fig.6B] illustrates a step of forming a version of rank N+1 of the firmware. The firmware initially comprises an executable code forming a data block DB1n+i. A pair of authentication keys of rank N+1 comprising a public authentication key PKn+i and a private authentication key pKN+i is generated by the college of approvers and is associated with the data block DB1n+i. The public key PKn+i is concatenated with the data block DB1n+i to form a data block DB2N+i. The data block DB2N+i is applied to the hash function FH2 which provides a digest H2N+i. The digest H2N+i and the private key pKN are applied to the signature function FS2 which provides a signature SIGNn+i, such that:

[0080] SIGNn+1 = FS2lpKNJ(H2N+1) = FS2lpKNJ(FH2(DB 1N+1IIPKN+1))

[0081] The signature SIGNn+i is then concatenated to the data block DB2N+i to obtain a data block DB3N+i which here forms the final version of the firmware, the authenticity of which can be verified by means of the public key PKN present in the version of rank N installed in the hardware security module.

[0082] It will be noted that at each new iteration of the method, the “new key pair” may be identical to the previous key pair, the method also being able to be implemented by keeping the same key pair for all versions of the firmware. In practice, the college of approvers may decide to keep the same key pair from one version of the firmware to another, or decide to generate a new key pair from time to time. Seen from the perspective of this method, an authentication key of rank N is however a “new key” relative to the key of rank N1, even if it is the same key since the authentication signature of the firmware of rank N is made with the private authentication key of rank N1 and the verification of this signature is made by means of the public authentication key of rank NL

[0083] [Fig.7] shows steps for verifying the authenticity of the DB3n and DB3n+i data blocks. The SIGNn signature of the DB3N block is verified by means of a signature verification function VRFY which receives as input:

[0084] - the signature to be verified SIGNn, present in the DB3N block,

[0085] - the DB2N data block from which the SIGNn signature was generated, present in the DB3N block, this data block here comprising the DB1N data block (the executable code) and the public key PKN,

[0086] - the public key PKN i present in the block DB3N i, corresponding to the private key pK nor by means of which the SIGNn signature was generated

[0087] In the same way, the signature SIGNn+i of the block DB3N+i is verified by means of the function VRFY which receives as input:

[0088] - the signature to be verified SIGNn+i, present in the block DB3N+i,

[0089] - the DB2N+i data block from which the SIGNn+i signature was generated, present in the DB3N+i block, this data block here comprising the DB1n+i data block and the public key PKn+i, and

[0090] - the public key PKN present in the DB3N block, corresponding to the private key pKN by means of which the SIGNn signature was generated.

[0091] For each verification, the verification function VRFY provides a “VALID” or “INVALID” result depending on the input data provided to it. Thus, each signature SIGN of a data block of a given rank can be verified by means of the public key present in the data block of the previous rank and the data present in the data block in question. The validity of this signature implies the validity of the public key present in the data block that it signs. Thus, each DB3 data block is authenticated relative to the previous data block, and each authentication of a DB3 data block implies the validation of the public key PK that it contains, which will then enable the validation of the following data block.

[0092] The VRFY verification function is itself conventional and depends on the type of signature used. Various signature and signature verification functions are available to designers. If the SIGN signature is an RSA signature, the verification function uses the public authentication key to retrieve the original digest H2 from the SIGN signature, then calculates an H2' digest of the DB2 data block with the same hash algorithm, and finally compares the H2 and H2' digests. If the SIGN signature is an ECDSA (Elliptic Curve Digital Signature Algorithm) signature, this same algorithm can be used for signature verification using the public authentication key and the data that has been signed with the private authentication key.For example, ECDSA implemented with the P-256 elliptic curve verifies electronic signatures using this elliptic curve, standardized by NIST ("National Institute of Standards and Technology"), cf. FIPS Publication 186-3.

[0093] [Fig.8A] illustrates a variant of the step of forming a firmware of rank N+1 which was described in relation to FIGS. 6A, 6B. In this embodiment, other metadata are added to the initial data block DB1 but the principle of authentication of each new version relative to the previous version remains the same.

[0094] A version FWn+i of rank N+l of the firmware is first designed, in the form of source code. This version includes an application program AFWn+i (“Application Firmware”) and a modification program PFWn+i (“Patch Firmware”). The application program aims to carry out operations provided for in the within the framework of a specific application. An example of such an application will be described later in relation to [Fig. 13]. The PFWn+i modification program aims to implement the PM protection module previously described in the operation of the machine, while transforming the MPMO message processing module ([Fig.2]) into an MPM1 message processing module ([Fig.4]) configured to pass on to the PM protection module calls to the erase function or the update function.

[0095] The firmware version FWn+j is first sent to an integration server BSRV1 which compiles the firmware to provide object code or executable code forming the DB1n+i data block. The integration server then adds to the DB1n+i data block, by concatenation, the following metadata:

[0096] - a first marker MK1,

[0097] - a version number VN. This version number can consist of any in formation other than a simple number allowing the version concerned to be identified with certainty, for example a design date, a serial number, etc.

[0098] - a second MK2 marker,

[0099] - the public authentication key PKn+i associated with this version of the micro program, and

[0100] - a third MK3 marker.

[0101] The data block DB1n+i concatenated with these different metadata forms the data block DB2N+i, which differs from that previously described with the same reference in that it comprises a greater number of metadata. Then, and as previously described, the data block DB2N+i is applied to the hash function FH2 which provides the digest H2N+i. The digest H2N+i and the private authentication key pKN are applied to the function FS2 which provides the signature SIGN N+1. This step of generating the signature SIGNn+i can, in one embodiment, be carried out by a hardware security module HSMla of the college of approvers APRV.

[0102] The signature SIGNn+i is then concatenated to the data block DB2N+i to obtain the data block DB3N+i which previously formed the final version of the firmware. Here, the data block DB3N+i undergoes an additional processing step before obtaining the final version of the firmware. During this step, the data block DB3N+i is signed using a function FS1. This signature is conventionally generated by a signing hardware security module HSMlb, which generates a public installation key IPKn+i and a private installation key IpKN+i and then proceeds with the data block DB3N+i in the same way as the hardware security module HSMa of [Fig.l] proceeds with the data block DB1. Thus, the data block DB3N+i is applied to a hash function FH1 which provides a digest H1n+i. The digest H1n+i as well as the private key IpKN+i installation parameters are applied to the FS1 function which provides an ISIGN N+1 signature. The ISIGNn+i signature is then concatenated by the signing hardware security module HSMlb with the DB3N+i data block, being preceded by a SIZE(ISIGN) field indicating the size of this signature, followed by an OID(FSl) field (“Object Identifier”) giving information on the FS1 signature function used, itself preceded by a SIZE(OID) field indicating the size of this identifier. A SIZE(DB3) field can also be added before the DB3N+i data block to indicate its size.

[0103] The set forms a DB4N+i data block which here constitutes the final version of the firmware. In order to allow the installation of this DB4N+i version of the firmware, the public installation key IPKn+i is provided to the administrator of the HSMp hardware security module, who saves it in an administrator account of the hardware security module. The HSMp hardware security module then checks the validity of the installation signature ISIGNn+i by means of the public installation key IPKn+i. If the signature is valid, the operating system of the HSMp hardware security module agrees to load the firmware into its PMEM program memory. However, here, the PM protection module intervenes before the verification of the validity of the installation signature ISIGNn+i by the operating system, to verify the authentication signature SIGNn+i.

[0104] [Fig.8B] shows the structure of three successive microprograms of respective ranks N, N+1, N+2 produced according to the method of [Fig.8A].

[0105] The firmware of rank N comprises, in the order shown, the SIZE(DB3n) field, the executable code forming the DB1N block, the MK1 marker, the VN(n) version number, the MK2 marker, the PKN authentication public key, the MK3 marker, the SIGNn authentication signature, the SIZE(ISIGN) field, the ISIGNn installation signature, the SIZE(OID) field and the OID(FSl) identifier.

[0106] Similarly, the firmware of rank N+1 comprises the field SIZE(DB3 N+i), the executable code forming the block DB1n+i, the marker MK1, the version number VN(n+i), the marker MK2, the authentication public key PKn+i, the marker MK3, the authentication signature SIGNn+i, the field SIZE(ISIGN), the installation signature ISIGNn+i, the field SIZE(OID) and the identifier OID(FS1).

[0107] Similarly, the firmware of rank N+2 includes the field SIZE(DB3N+2), the executable code forming the block DB1n+2, the marker MK1, the version number VN(N+2), the marker MK2, the public authentication key PKN+2, the marker MK3, the authentication signature SIGNn+2, the field SIZE(ISIGN), the installation signature ISIGNn+2, the field SIZE(OID) and the identifier OID(FSl).

[0108] [Fig.8B] also shows the different authentication key pairs generated by the APRV approver college:

[0109] - the private authentication key pKx । used to generate the signature authentication key SIGNn, and the corresponding public key PKX h The latter is inserted into a DB3N i block of a previous version of the firmware, not shown in the figure,

[0110] - the private authentication key pKN used to generate the signature authentication key SIGNn+i, and the corresponding public key PKN which is inserted into the DB3N data block,

[0111] - the private authentication key pKN+i used to generate the signature authentication key SIGNn+2, and the corresponding public key PKn+i which is inserted into the data block DB3N+i, and

[0112] - the private authentication key pKN+2 which will generate the signature authentication of a subsequent firmware version, and the corresponding public key PKn+2, which is inserted into the data block DB3N+2. and

[0113] [Fig.8B] also shows:

[0114] - the DB2N, DB2N+i, DB2N+2 blocks from which the authentication signatures SIGNn, SIGNn+i, SIGNn+2 are generated,

[0115] - the IpKN installation private key used to generate the installation signature ISIGNn, and the corresponding public key IPKN,

[0116] - the private installation key IpKN+i used to generate the installation signature ISIGNn+i, and the corresponding public key IPKn+i, as well as

[0117] - the private installation key IpKN+2 used to generate the installation signature ISIGNn+2, and the corresponding public key IPKn+i.

[0118] In summary, each subsequent microprogram is linked to the previous microprogram by an authentication link which resides in the private authentication key corresponding to the public authentication key inserted in the previous microprogram. This private key is used to generate the authentication signature inserted in the subsequent microprogram, while the public authentication key inserted in the previous microprogram makes it possible to verify this signature. Furthermore, the inviolability of the signature chain is obtained by the fact that the public authentication key which is inserted in the previous microprogram forms the input data of the authentication signature inserted in the previous microprogram, itself generated by means of the private key associated with the microprogram which precedes the previous microprogram.Adding other firmware data such as the VN version number and the DB1 executable code to this input data also makes it possible to verify that this data has not been altered, which is in itself the classic function of a signature. Thus, the authentication signature here fulfills a dual function, on the one hand to verify the validity of the data present in the firmware, and on the other hand to make in- . violable the iterative authentication process.

[0119] As mentioned above, according to one aspect of the present disclosure, the iterative authentication method which has just been described is implemented by the protection module PM which is incorporated in the firmware of the hardware security module.

[0120] [Fig.9A] is a sequence diagram describing an embodiment of the firmware manufacturing method of [Fig.8A]. [Fig.9B] describes the steps of [Fig.9A]. The rank of the firmware concerned, as well as the rank of the public and private keys, are not shown in Figures 9A, 9B. In the following, it will be considered to be rank N, unless otherwise indicated.

[0121] [Fig.9A] shows four entities: the integration server BSRV1, the hardware security module HSMla of the college of approvers APRV, the signing hardware security module HSMlb and the FW firmware under manufacture.

[0122] At a step SOI, the hardware security module HSM1a generates a private authentication key pK and a public authentication key PK and communicates the public key PK to the server BSRV1.

[0123] At a step S03, the server BSRV1 compiles a source code and generates the compiled binary code of the firmware forming the data block DB1.

[0124] In a step S05, the server BSRV1 adds a version number VN to the data block DB1. This step may include the insertion of a first marker MK1 before the version number.

[0125] In a step S07, the server BSRV1 adds the authentication public key PK to the data block DB1, to obtain the data block DB2. This step may include the insertion of a second marker MK2 before the public key.

[0126] At a step S09, the hardware security module HSM1a audits the binary code to verify that its structure is correct.

[0127] At a step SI 1, the hardware security module HSM1a verifies that the version number VN added to the firmware is correct.

[0128] In a step S13, the hardware security module HSM1a verifies that the public authentication key PK added to the firmware is correct.

[0129] In a step S15, the hardware security module HSM1a calculates the digest H2 of the block DB2 using the hash function FH2, i.e. H2 = FH2(DB2). In one embodiment, the function FH2 is the SHA256 function.

[0130] In a step S17, the hardware security module HSM1a calculates the signature SIGN of the digest with the signature function FS2 and the private key of the previous iteration of rank N1, i.e., assuming that the version being produced is a version of rank N: SIGN = FS21pKn ij(H2). In one embodiment, the signature function FS2 is the function ECDSA-secp256kl.

[0131] At a step S19, the hardware security module HSM1a compiles the signature SIGN with DB2 to obtain the data block DB3.

[0132] In a step S21, the data block DB3 is provided to the signing hardware security module HSMlb.

[0133] In a step S23, the hardware security module HSMlb calculates the digest H1 with the hash function FH1, i.e. FH1(DB3). In one embodiment, the hash function FH1 is the SHA512 function.

[0134] In a step S24, the hardware security module HSMlb generates an installation private key IpK and an installation public key IPK, calculates the installation signature ISIGN using the signature function FS1 and the installation private key IpK, i.e. ISIGN = FSlllpKj(Hl). In one embodiment, the signature function FS1 is the function RSA2048_pkcs.

[0135] At a step S25, the hardware security module HSMlb adds to the data block DB3 the identifier OID of the function FS1 and the signature ISIGN, to obtain the data block DB4.

[0136] [Fig.10A] is a sequence diagram describing a detailed embodiment of a step of installing in the hardware security module HSMp, a first version FW1 of the firmware according to the present disclosure. [Fig.10B] is a flowchart describing the steps of [Fig.10A]. This is a first installation which is subject to various precautions in terms of computer security and is notably accompanied by the intervention of an observer to supervise its implementation, verify that the hardware security module in which it is carried out is free of any firmware and that the firmware installed is authentic. Once installed, the firmware implants the PM protection module at the heart of the operation of the hardware security module HSMp.The latter is then self-protected against deletion or installation of later versions that are not authentic, and it is no longer necessary to involve an observer. Installations of subsequent versions are then considerably simplified, and can even be carried out remotely.

[0137] The process here involves four entities:

[0138] - a PARTI party, for example a company that developed the firmware as described in connection with Figures 9A, 9B,

[0139] - an OBS observer, for example a person who is a member of the PARTI party,

[0140] - a PART2 part which will exploit the firmware on a security module HSMp hardware that belongs to it,

[0141] - the message processing module MPM0 of the hardware security module HSMp in its initial state when it leaves the factory (this will become the MPM1 message processing module at some stage of the installation process), and

[0142] - the OS operating system of the HSMp hardware security module.

[0143] At a step S27, the PARTI party communicates to the PART2 party the public key IPK installation key. In step S28, the PART2 part communicates the IPK installation key to the HSMp hardware security module. The OS operating system of the HSMp hardware security module saves the key in a register AREG accessible only to an administrator.

[0144] At a step S30, the observer OBS audits the hardware security module HSMp and ensures that it is free of any program and that it is in the factory state (state in which it is delivered by the manufacturer).

[0145] At a step S32, the observer OBS audits the process of provisioning the firmware by the party PART2.

[0146] In a step S34, the party PARTI sends the firmware FW1 to the party PART2. In one embodiment, the party PARTI also communicates to the party PART2 the source code of the firmware, as well as the public authentication key PK and the version number. On the other hand, the private authentication key pK is not communicated to it. With this data, the party PART2 can audit the source code and verify by compiling it that it corresponds to the executable code that it will install on its hardware security module. It can also verify the authentication signature SIGN with the public authentication key PK.

[0147] At a step S36, the part PART2 audits the firmware FW1 in the manner just indicated.

[0148] At a step S38, the PART2 sends to the message processing module MPM0 a command to install the firmware FW1. At this stage, the message processing module MPM0 is in its factory-output state and directly transmits the function call to the operating system.

[0149] At a step S40, the message processing module MPM0 requests the operating system to install the firmware FW1.

[0150] At a step S42, the operating system OS installs the firmware FW1 with the classic installation mechanism, which consists of verifying that the installation signature ISIGN is correct by using for this purpose the public key IPK which it has in the register AREG.

[0151] In a step S44, the operating system OS executes the firmware FW1 and installs the protection module PM.

[0152] At a step S46, the protection module PM modifies the function allocation table of the message processing module MPM0 to lock the entry points of the HSM: the message processing module MPM0 becomes the message processing module MPM1, designed to reject the erasure requests and verify, before executing an update request, that the update firmware is authentic.

[0153] In a step S48, the protection module PM generates a pair of random attestation keys AKEYP comprising a private attestation key ApK and a public attestation key APK. The pair of keys is for example generated on the ECDSA P-256 curve. This pair of attestation keys is saved in a secure memory of the hardware security module HSMp, which will not be erased during future updates.

[0154] At a step S50, the protection module PM communicates the public attestation key APK to the message processing module MPM1.

[0155] At a step S52, the message processing module MPM1 communicates the APK key to the party PART2.

[0156] At a step S54, the party PART2 communicates the APK key to the observer OBS.

[0157] At a step S56, the observer OBS calculates an OSIGN signature of the APK key with an FS3 signature function and using its own private key OpK, i.e.: OSIGN = FS310pkj(APK). The FS3 function is for example the ECDSA algorithm.

[0158] At a step S58, the observer OBS communicates to the party PARTI the attestation key APK and its signature OSIGN.

[0159] In a step S60, the PARTI party uses the public key OPK of the observer to verify the authenticity of the APK signature, by verifying the OSIGN signature using the public key OPK.

[0160] From this step, the establishment of a trust link is possible by using the public attestation key APK of the pair AKEYP. For example, in one embodiment, the party PARTI integrates the hardware security module HSMp into a public key infrastructure PKI ("Public Key Infrastructure") of its own. For this purpose, the party PARTI communicates the public attestation key APK to the certification authority CA of this infrastructure. The certification authority CA returns a signature SIGNCA(APK) of the public key APK generated with its own private key, forming with the public key APK a certificate {APK, SIGNCA(APK)}. In a step S62, the party PARTI returns the certificate to the protection module PM of the hardware security module HSMp, via the message processing module MPM1.The SIGNCA(APK) signature is saved by it in the secure memory in which the private attestation key ApK and the public attestation key APK are already stored. No API interface is provided, which would allow this part of the memory of the hardware security module to be modified, only the firmware modified in accordance with this disclosure can do so.

[0161] In summary, the installation of the first version of the firmware differs from the ins- following update statements by the fact:

[0162] - that it is not necessary to provide the authentication signature SIGN in the first firmware, since there is no previous version, the authentication of the first version being ensured by appropriate measures, some of which have just been described: audit of the binary code, presence of an observer, use of the public installation key IPK and verification of the installation signature ISIGN, etc. This does not exclude, however, that in an embodiment this signature is provided and verified.

[0163] - that the first version generates the AKEYP attestation key allowing the creation of the aforementioned trust relationship with the PARTI party.

[0164] Once the first installation is complete, the hardware security module can be added to the PKI infrastructure of the PARTI party, which will allow it to be used securely even if it is located in a data center managed by the PART2 party.

[0165] Figures 11A, 12A are sequence diagrams describing a detailed embodiment of a step of updating, in the hardware security module HSMp, the first version of the firmware. Figures 11B, 12B are flowcharts describing the steps of Figures 11A, 12A. For the sake of simplicity, the rank of the firmware concerned, of the public and private keys, is not shown in these figures. It will be considered that it is for example rank N, unless otherwise indicated.

[0166] The process here involves four entities:

[0167] - the PART2 part, which controls the HSMp hardware security module.

[0168] - the message processing module MPM1 in its version modified in step S46 of the first firmware installation previously described,

[0169] - the PM protection module of the HSMp hardware security module installed at during step S44 of the first firmware installation, and

[0170] - the OS operating system of the hardware security module HSMp (considered here as including the SLIB2 library of [Fig.4]).

[0171] The firmware to be installed is in the form of the DB4 data block, the structure of which was previously described in relation to Figures 8A, 8B and 9A, 9B. In this exemplary embodiment, the firmware update function which is modified to be processed by the PM protection module is broken down into three PKCS#11 function calls:

[0172] - C_VerifyInit,

[0173] - C_VerifyUpdate,

[0174] - C_VerifyFinal.

[0175] Furthermore, to transform the message processing module MPM0 into the module MPM1, the command "CprovFnTable" is used. This command allows to modify a function assignment table in order to return the processing of calls to the three aforementioned functions to the PM protection module. The following example is a program sequence that allows the processing of these three functions to be returned to the PM protection module:

[0176] FunctionTable *table = OS_GetFunctionTable();

[0177] table->C_Verify!nit = Custom_C_VerifyInit;

[0178] table->C_Verify Update = Custom_C_VerifyUpdate;

[0179] table->C_VerifyFinal = Custom_C_VerifyFinal;

[0180] table->C_SetAttributeV alue = Custom_C_SetAttributeV alue

[0181] We thus distinguish in the process shown in figures 1 1A, 1 1B, 12A and 12B:

[0182] - a processing phase of the function call “Verifylnit(mechanism= Firmwa- reUpdate)”, the “mechanism” field included in the command means that the Verifylnit function is called here to prepare an update operation,

[0183] - a processing phase of the function call “VerifyUpdate(BUF)”; this step will be repeated several times until the entire DB4 data block is stored in a memory buffer BUF, and

[0184] - a processing phase of the function call “VerifyFinal(ISIGN)”. In the art Previously, this processing only consists of the verification of the ISIGN installation signature by the operating system. This processing will be preceded by the verification of the SIGN authentication signature by the PM protection module.

[0185] We will now describe these three phases of installing the update.

[0186] Phase 1, processing of the function call “Verifylnit(mechanism= Firmwa-reUpdate)”

[0187] At a step S70, the part PART2 downloads the data block DB4.

[0188] At a step S72, the PART2 part sends to the message processing module MPM1 the command “VerifyInit(mechanism=FirmwareUpdate)”.

[0189] At a step S74, the message processing module MPM1 transfers the command “VerifyInit(mechanism=FirmwareUpdate)” to the protection module PM.

[0190] At a step S76, the protection module PM initializes a state machine which it will need for analyzing the structure of the data block DB4.

[0191] In a step S78, the protection module PM initializes the hash function FH2, for example the SHA256 function.

[0192] At a step S80, the protection module PM has completed the initialization phase and transmits the command “VerifyInit(mechanism=FirmwareUpdate)” to the operating system.

[0193] Phase 2, processing of the function call “VerifyUpdate(BUF)”.

[0194] This processing may include loop processing of a plurality of commands “VerifyUpdate(BUF)” until the entire DB4 data block is stored in the BUF memory buffer.

[0195] At a step S82, the part PART2 sends the command “VerifyUpdate(BUF)” to the message processing module MPM1.

[0196] At a step S84, the message processing module MPM1 transfers the command “VerifyUpdate(BUF)” to the protection module PM, the command being accompanied by a portion of the data block DB4.

[0197] At a step S86, the protection module PM analyzes the portion of the data block DB4 and seeks to detect the markers MK1 (marker of the version number VN) and MK3 (marker of the authentication signature SIGN). It will be noted that at this stage, the protection module does not need to find the marker MK2 of the public authentication key PKN, because this key is of rank N and will only be used after installation of the update, for the authentication of a following update.

[0198] In a step S88, the protection module PM analyzes the portion of the data block DB4 which is attached to the command and searches for the authentication signature SIGN.

[0199] At a step S90, the protection module PM prepares the DB2 data to be provided to the hash function FH2 (without including the authentication signature SIGN).

[0200] At a step S92, the protection module PM stores the version number VN.

[0201] At a step S94, the protection module PM adds the contents of the buffer BUF to the FH2 hash function

[0202] At a step S96, the protection module PM has completed the preparatory step and transfers the VerifyUpdate(BUF) command to the operating system so that the operating system executes the conventional steps for processing this command.

[0203] Phase 3, processing of the function call “VerifyFinal(ISIGN)” ([Fig.l2A]).

[0204] At a step S98, the PART2 part sends to the message processing module MPM1 the VerifyFinal(ISIGN) command.

[0205] At a step S100, the message processing module MPM1 transfers the command to the protection module PM,

[0206] If the protection module PM was unable to identify the valid markers MK1 and MK3 during the previous phase, the module PM sends to the message processing module MPM1 an “Invalid Format (marker fault)” message in a step S102, and refuses to transfer the control to the operating system for firmware update.

[0207] At a step S104, if step S102 is implemented, the message processing module MPM1 passes on the message “Invalid Format” to the part PART2.

[0208] If an invalid version number VN was detected during the previous phase, the protection module PM returns to the message processing module MPM1, at a step S106, a message "Rollback detected", and also refuses to transfer the control to the operating system for updating the firmware.

[0209] At a step S108, if step S106 is implemented, the message processing module MPM1 transmits to the part PART2 a “Backtrack detected” message.

[0210] At a step SI 10, the protection module PM calculates the digest H2' from the data block DB2 (see [Fig.8A]). The hash function FH2 is for example the SHA256 function. The module PM then verifies the authentication signature SIGN from H2' and by means of the public authentication key PK of rank N1 present in the current code of the firmware (and not in the code of the update which has just been analyzed), this key being identifiable by means of the marker MK2.

[0211] At a step SI 14, if the signature is not valid, the protection module PM sends to the message processing module MPM1 an “Invalid Signature” message and refuses to transfer the command to the operating system for updating the firmware.

[0212] At a step SI 16, if step SI 14 has been implemented, the message processing module MPM1 passes on the message “Invalid Signature” to the party PART2.

[0213] At a step SI 18, if none of the errors cited above have been found, the PM module transfers the command “VerifyFinal(ISIGN)” to the operating system for updating the firmware. The latter then executes this command in a conventional manner, by verifying the ISIGN installation signature.

[0214] Thus, at a step S120, the operating system OS calculates the digest H1 from the data block DB3, i.e. Hl' = FH1(DB3) (see [Fig.8A]). The hash function FH1 is for example the SHA512 function. The operating system then calculates the digest Hl of the ISIGN signature using the public installation key IPK, then verifies that the two digests Hl' and Hl are equal.

[0215] At a step S122, if the digests are not equal, which means that the installation signature ISIGN is invalid, the operating system OS sends to the protection module PM an “Invalid Signature” message.

[0216] At a step S124, the protection module PM passes on the message “Invalid Signature” to the message processing module MPM1.

[0217] At a step S126, the message processing module MPM1 passes on the message “Invalid Signature” to the party PART2.

[0218] At a step S128, if no error on the ISIGN signature has been detected, the operating system accepts the firmware update and sends a “firmware being updated” message to the PM protection module.

[0219] At a step S130, the operating system OS then sends an “update successful” message to the protection module PM.

[0220] At a step S132, the protection module PM transmits the message “update successful” to the message processing module MPM1.

[0221] At a step S134, the message processing module MPM1 transmits the message “update successful” to the party PART2.

[0222] [Fig. 13] shows a cryptoasset wallet CW 1 and a system intended to implement a method for saving the seed S of cryptoasset accounts held by the wallet CW1. Such a method is for example offered to the public under the trade name “Recover”.

[0223] The cryptoasset wallet CW 1 comprises an HW device and a host device HDV. The HW device is a hardware wallet providing cold storage of the seed S, which can also be stored in the form of a recovery phrase or mnemonic phrase. The HW device does not have any means of connecting to the Internet and is connected to the host device HDV, which runs HSW companion software allowing it to connect to the Internet, for example by means of a USB or Bluetooth connection.

[0224] The seed backup system comprises a set of m BCKi backup servers (BCKI,.. .BCKi,.. .BCKm) each provided with an HSM hardware security module (HSM1,... HSMi,...HSMm). Each backup server comprises a back-end program, or "back-end" program, designed for implementing the seed backup method.

[0225] The hardware wallet HW is configured to divide the seed S into a plurality of secret data Si (Sl,...Si,...Sm) which will be saved in the hardware security modules HSMi of the BCKi servers. Rather than a simple splitting, this "division" can be carried out by means of a secret sharing function SS making it possible to generate a number m of secret data called "shares", allowing the reconstitution of the seed from a threshold of n secret data Si.

[0226] When the user wishes to back up his seed, the HW device establishes with each BCKi backup server, via the HDV host device, LNKi data links (LNK1 to LNKm), for example of the HTTPS type. These data links then serve as support for the establishment of secure channels of the SCP ("Secure Channel Protocol") type between the HW device and each BCKi backup server, in a manner which will be described.

[0227] The establishment of such secure channels is ensured by means of a public key infrastructure managed by a certification authority CA. The HW device and the BCKi backup servers each have a private key, a public key, a certificate signed by the certification authority, or static certificate, as well as the public key of the certification authority. The following notation will be used in the following

[0228] - pD: private key of the HW device

[0229] - PD: public key of the HW device

[0230] - CD[PD, SIGNCA(PD)]: device certificate, including its public key PD and a signature of its public key using the private key of the certification authority,

[0231] - ApKi: private attestation key of a BCKi server (for i ranging from i to m)

[0232] - APKi: public attestation key of a BCKi server (for i going from i to m)

[0233] - CBi[APKi, SIGNCA(APKi)]: certificate of a BCKi server, including its key public APK attestation and a signature of its public key using the private key of the certification authority.

[0234] The signatures of the certificates by the certification authority are for example generated using the ECDSA algorithm ("Elliptic Curve Digital Signature Algorithm").

[0235] The certification authority CA is preferably owned by the manufacturer of the HW device, to enable it to control the allocation of CBi certificates to the backup servers BCKi, so that these can be members of the public key infrastructure. This manufacturer is for example the party PARTI cited in the above. The backup servers BCKi and the hardware security modules HSMi are, or at least part of them, owned by backup providers, each being for example the party PART2 cited in the above. The firmware executed by the hardware security modules is developed by the party PARTI and is updated by it. The single source of authentication keys pKi, PKi of the hardware security modules HSMi is owned by the party PARTI, for example the college of approvers APRV and the hardware security module HSMIa.

[0236] Thanks to the method described above, the PARTI party has the assurance that the firmware of the various HSMi hardware security modules cannot be corrupted by a fraudster who interferes with the maintenance teams of the servers of one of the PART2 parties. Indeed, as seen above, thanks to the PM protection module, the administrator of a hardware security module of a PART2 party can neither erase the firmware loaded into the hardware security module, nor load an update that does not include a valid SIGN authentication signature with respect to the PK authentication public key present in the firmware version currently installed in the hardware security module.

[0237] To implement a secure communication channel, a key exchange is provided between the HW device and each BCKi backup server, making it possible to generate kBi session keys specific to each BCKi server but known to the HW device. This key exchange includes, for example, the following steps:

[0238] i) each backup server BCKi generates an ephemeral private key peBi and a public key PeBi using an asymmetric key generator, then communicates its ephemeral public key PeBi to the HW device in an ephemeral certificate CeBi that it has signed with its private key ApKi, as well as its certificate CBi signed by the certi- fication:

[0239] CeBi = [PeBi, SIGNlApKij(PeBi)]

[0240] CBi = [APKi, SIGNCA(APKi)]

[0241] ii) the HW device itself generates a pair of ephemeral private key peD and public key PeD, then communicates its ephemeral public key PeD to the backup servers BCKi in an ephemeral certificate CeD that it has signed with its private key pD, as well as its certificate CD signed by the certification authority, i.e.:

[0242] CeD = [PeD, SIGNlpDJ(PeD)]

[0243] CD = [PD, SIGNCA(PD)]

[0244] iii) each BCKi backup server verifies the signature of the ephemeral public key PeD of the HW device by means of the public key PD present in its CD certificate, then verifies the signature of the public key PD present in the CD certificate by means of the public key of the certification authority, or vice versa,

[0245] iv) similarly, the HW device verifies the signature of the ephemeral public key PeBi of each BCKi server by means of the APKi public key present in the CB certificate, then verifies the signature of the APKi public key present in the CB certificate by means of the public key of the certification authority, or vice versa,

[0246] v) each backup server BCKi generates an ephemeral session key kBi from its ephemeral private key peBi and the ephemeral public key PeD of the HW device, by means of a key exchange function such as, for example, the ECDH function (Diffie Hellman key exchange based on elliptic curves or "Elliptic Curve Diffie-Hellman"), i.e.:

[0247] kBi = ECDH(peBi, PeD)

[0248] vi) the HW device generates the ephemeral session key kBi of each backup server BCKi from its ephemeral private key peD and the ephemeral public key PeBi of the backup server BCKi, using the same function, i.e.:

[0249] kBi = ECDH(peD, PeBi)

[0250] After generating the shares Si of the seed S, the HW device conducts symmetric encryption steps for each share Si with the session key kBi common to the backup server BCKi to which the share Si must be sent. In a simple example of implementation, the HW device generates three shares SI, S2, S3 (the threshold n can then be equal to 2 or 3) and three backup servers BCKI, BCK2, BCK3 are provided. Each server BCKi generates its own session key kBi, kB2, kB3. The HW device generates each of these session keys for its part after an exchange of keys with each server, in the manner just described. Then, the HW device conducts symmetric encryption steps for the shares SI, S2, S3 using these keys, namely:

[0251] - encrypts the SI part with the key kBi, i.e. {Sl]kBl, then sends it to the BCKI server,

[0252] - encrypts the part S2 with the key kB2, i.e. {S2]kB2, then sends it to the server BCK2,

[0253] - encrypts the S3 share with the kB3 key, i.e. {S3]kB3, then sends it to the BCK3 server.

[0254] Each backup server BCKi then decrypts the encrypted part {Si]kBi that it received from the HW device, and stores it in its MEM memory, possibly in an encrypted form.

[0255] It will be clear to those skilled in the art that the iterative authentication method described in the foregoing is capable of various applications other than that relating to the updating of a firmware. The method just described is independent of the nature of the DB1 data block which is encapsulated in the DB3 data block. This data block may be something other than a code executable by a processor. The method may also be used to secure a configuration file, for example of the JSON type, which is inserted into a hardware security module to modify its dynamic behavior, the HSM being configured to verify the authenticity of this file and the non-rollback. The DB1 data block may also be the result of the scanning of a document, comprising text and / or one or more images, for example a book, a digital or digitized work of art or any other digital file.In this case, the process allows the different versions of the document or file to be authenticated, starting from a first version whose authenticity is assured or accepted.

[0256] Furthermore, the encapsulation of the DB3 data block in the DB4 data block, specific to the requirements of hardware security modules during the installation of a firmware, may not be provided in another application, or may be replaced by another type of encapsulation.

[0257] Also, as indicated in the above, the successive authentication key pairs used to authenticate the different versions of the DB1 data block may be all different or all identical, or sometimes identical and sometimes different, the method requiring only that there be a single source of generation of the authentication key pairs, described in the above as a college of APRV approvers. The term "single source of generation of the authentication key pairs" does not necessarily designate the same physical or computer entity.For the implementation of the method, it is only necessary that the source of a pair of authentication keys of rank N has knowledge of the private key of rank Nl, otherwise it will not be able to sign the public key of rank N by means of the private key of rank NL. Thus, if a change of generating source of the pairs of authentication keys occurs during the iterative process, this means that there has been a "passing of secrecy", namely that the new source of pairs of keys has received, from the source of pairs of previous keys, the last private key that the previous source generated. Even in this case, two sources can be considered. as a “same generating source” since there is continuity in the knowledge of the private keys from one iteration to another.

Claims

Claims

1. Method for securing the installation and updating of a firmware in a program memory (PMEM) of a processor (HSMp), characterized in that it comprises the steps of: - installing in the program memory of the processor a first version of the firmware (DB3N, DB4N) comprising an executable code (DB1N) a first public key (PKN), and - upon receipt of a command to install in the program memory a second version of the firmware (DB3N+i, DB4 N+i) intended to overwrite the first version of the firmware and comprising an executable code (DB1n+i), a second public key (PKn+i) and an authentication signature (SIGNn+i) of the second version of the firmware: - verifying the validity of the authentication signature (SIGNn+i) of the second version of the firmware by means of the first public key (PKN) present in the first version (DB3N+i, DB4N+i) of the firmware and from a first data block (DB2N+i) of the second version of the firmware comprising at least the second public key (PKn+i), and - reject the installation command if the authentication signature (SIGNn+i) of the second firmware version is not valid, the authentication signature (SIGNn+i) of the second firmware version being generated by means of a first private key (pKN) corresponding to the first public key (PKN) present in the first firmware version, and from the first data block of the second firmware version comprising at least the second public key (PKn+i).

2. The method of claim 1, comprising the step of providing a protection module (PM) in the first version of the firmware, and the steps of: - send (MPM1, E02, E04) to the protection module any command to install a new version of the firmware in the program memory, and - using the protection module, ensure verification of the validity of the authentication signature (SIGNn+i) of the second version of the firmware, and refuse execution of the installation command if the signature is not valid, such that after installation of the first firmware version in the program memory, the first firmware version is self-protected by the protection module (PM) and can only be replaced by a second firmware version including an authentication signature (SIGNn+i) recognized as valid by the protection module.

3. Method according to claim 2, in which: - the first and the second version of the firmware are provided by a first party (PART1) holding the first private key (pKN) and having generated the authentication signature (SIGNn+i) of the second version of the firmware, and - the first and the second version of the firmware are installed in the memory of a processor owned and operated by a second party (PART2) not having knowledge of the first private key (pKN), in such a way that the second party (PART2), once the first version of the firmware is installed, cannot replace the first version of the firmware with a version which would not include a valid authentication signature generated by means of the first private key.

4. Method according to one of claims 1 to 3, in which the first data block (DB2N+i) of the second version of the firmware also comprises the executable code (DB1n+i) of the second version of the firmware.

5. A method according to one of claims 1 to 4, wherein the first data block (DB2N+i) of the second version of the firmware also comprises a version number (VN) of the firmware, the method comprising the step of checking the version number of the second version of the firmware and refusing to update the first version of the firmware if the second version of the firmware is not a later version of the first version of the firmware.

6. Method according to one of claims 1 to 5, wherein the first data block (DB2N+i) of the second version of the firmware also comprises markers (MK1, MK2, MK3) making it possible to distinguish metadata (VN, PKn+i, SIGNn+i) concatenated to the executable code (DB1n+i) of the firmware, the method comprising the step of refusing to update the first version of the firmware if the markers are not identified.

7. Method according to one of claims 1 to 6, in which the second public key (PKn+i) is identical to the first public key (PKN).

8. Method according to one of claims 1 to 6, in which the second public key (PKn+i) is different from the first public key (PKN).

9. Method according to one of claims 1 to 8, in which the second version of the firmware further comprises an installation signature (ISIGNn+i) generated by means of a private installation key (IpKN+i) and from a second data block (DB3 N+i) comprising at least the executable code (DB1n+i) of the second version of the firmware and the authentication signature (SIGNn+i), and in which the installation of the second version of the firmware comprises a step of providing the processor with a public installation key (IPKn+i) corresponding to the private installation key (IpK N+i), and a step of verification by the processor, by means of the public installation key, of the validity of the installation signature.

10. The method of any one of claims 1 to 9, wherein the processor is a hardware security module (HSM), and wherein the firmware is configured to receive and store secrets relating to cryptoasset accounts.

11. Processor (HSMp) comprising a first version (DB3N, DB4N) of a firmware installed in a program memory (PMEM) of the processor, the firmware comprising an executable code (DB1n) and a first public key (PKN), the processor being configured to, during the execution of the first version of the firmware and upon receipt of a command to install in the program memory a second version of the firmware (DB3N+i, DB4N+i) intended to overwrite the first version of the firmware and comprising an executable code (DB1n+i), a second public key (PKn+i) and an authentication signature (SIGNn+1): - verify the validity of the authentication signature (SIGNn+i) of the second version of the firmware by means of the first public key (PKN) present in the first version (DB3N, DB4N) of the firmware and from a first data block (DB2N+i) of the second firmware version comprising at least the second public key (PKn+i), and - reject the installation command if the authentication signature (SIGNn+i) of the second firmware version is not valid, the authentication signature (SIGNn+i) of the second firmware version being generated by means of a first private key (pKN) corresponding to the first public key (PKN) present in the first firmware version, and from the first data block of the second firmware version comprising at least the second public key (PKn+i).

12. Processor according to claim 11, in which the first version of the firmware comprises a protection module (PM), the processor being configured to: - send (MPM1, E02, E04) to the protection module any installation command in the program memory of a new version of the firmware, and - by means of the protection module, ensure the verification of the validity of the authentication signature (SIGNn+i) of the second version of the firmware and refuse the execution of the installation command if this signature is not valid, such that after installation of the first version of the firmware in the program memory, the first version of the firmware is self-protected by the protection module (PM) and can only be replaced by a second version of the firmware comprising an authentication signature (SIGNn+i) recognized as valid by the protection module.

13. Processor according to claim 12, configured to send (MPM1, E02, E04) to the protection module (PM) any command to erase the program memory, in which the protection module is also configured to reject any command to erase the program memory, and in which an administrator of the processor can neither erase the first version of the firmware nor replace it with a firmware which would not include an authentication signature generated by means of the first private key (pKN).

14. Processor according to one of claims 11 to 13, in which the first data block (DB2N+i) of the second version of the firmware also comprises the executable code (DB1n+i) of the second version of the firmware.

15. A processor according to one of claims 11 to 14, wherein the first data block (DB2N+i) of the second firmware version also comprises a firmware version number (VN), the processor being configured to check the version number of the second firmware version and refuse to update the first firmware version if the second firmware version is not a later version of the first firmware version.

16. Processor according to one of claims 11 to 15, wherein the first data block (DB2N+i) of the second version of the firmware also comprises markers (MK1, MK2, MK3) making it possible to distinguish metadata (VN, PKn+i, SIGNn+i) concatenated to the executable code (DB1n+i) of the firmware, the method comprising the step of refusing to update the first version of the firmware if the markers are not identified.

17. Processor according to one of claims 11 to 16, configured not to check whether the second public key (PKn+i) is identical to the first public key (PKN) or different from it.

18. Processor according to one of claims 11 to 17, in which the second version of the firmware further comprises an installation signature (ISIGNn+i) generated by means of a private installation key (IpKN+i) and from a second data block (DB3 N+i) comprising at least the executable code (DB1n+i) of the second version of the firmware and the authentication signature (SIGNn+i), the processor being configured to, during the installation of the second version of the firmware, verify the validity of the installation signature by means of a public installation key (IPKn+i) corresponding to the private installation key (IpKN+i).

19. Processor according to one of claims 11 to 18, forming a hardware security module (HSM).

20. The processor of claim 19, wherein the firmware is configured to receive and store secrets relating to cryptoasset accounts.

Images