Method for securing the updating of firmware

Abstract

The invention relates to a method for securing the installation and updating of firmware, the method comprising the steps of installing, in the program memory of the processor, a first version of the firmware (DB3N, DB4N) comprising a first public key (PKN); and, on receiving a command to install a second version of the firmware (DB3N+1, DB4N+1) in the program memory, checking 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 using a first data block (DB2N+1) of the second version comprising at least one second public key (PKN+1).

Description

Method for securing a firmware update

[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 data encryption and decryption and the creation of 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 a variety of 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 personal authentication, 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 firmware version 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 process provides the operator with a guarantee that the firmware was produced by the approved designer, thanks to the latter's communication of the corresponding public key. However, it does not allow the designer to ensure that the firmware and its subsequent updates are correctly implemented by the operator. In particular, the administrator of a hardware security module generally has full rights to its program memory. A person who manages to steal his access codes could make changes to the firmware aimed at altering its operation, or even replace it with a corrupted version.

[0006] Furthermore, in some applications, the firmware developer uses the hardware security module for its own purposes as part of a service it 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 developer's control. It is therefore essential, particularly when an update is sent to a third-party partner, that the developer can ensure that no one at the third-party partners can 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 for updates, is not fully trusted for this task. In particular, operating systems in hardware security modules are generally not protected against insider threats during firmware signing or insider threats during firmware installation. Another type of attack that may be feared, called a "rollback attack", involves the installation of 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 to downgrade it.

[0010] It might also be desirable to provide a method for simply and efficiently authenticating successive versions of a computer file, in particular a firmware file, 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 updating of 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 receiving 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 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. Advantageously, the method also 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 refuse execution of the installation command if the signature is invalid, 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 including an authentication signature recognized as valid by the protection module.,

[0012] 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.

[0013] 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.

[0014] According to one embodiment, the first data block of the second firmware version also includes a firmware version number, the method comprising 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.

[0015] According to one embodiment, the first data block of the second version of the firmware also comprises markers for distinguishing metadata 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.

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

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

[0018] 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.

[0019] 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.

[0020] 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 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.,

[0021] 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.

[0022] 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.

[0023] 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.

[0024] In 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.

[0025] According to one embodiment, the first data block of the second version of the firmware also comprises markers for distinguishing metadata 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.

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

[0027] 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.

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

[0029] According to one embodiment, the firmware is configured to receive and store secrets relating to cryptoasset accounts. Summary description of the drawings

[0030] 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:

[0031] - the previously described shows steps of a conventional manufacturing process of a microprogram,

[0032] - shows the classic software structure of a hardware security module,

[0033] - shows the steps involved in modifying the software architecture of a hardware security module to secure its updates,

[0034] - shows the software structure of a secure hardware security module as illustrated in the,

[0035] - is a flowchart illustrating the processing of erase and update commands by the secure hardware security module of the,

[0036] - illustrate an embodiment of a method for manufacturing successive secure versions of a microprogram,

[0037] - shows the authentication steps of successive secure versions of the firmware,

[0038] - illustrates another embodiment of a method for manufacturing successive secure versions of a microprogram,

[0039] - shows the structure of three successive versions of secure microprograms produced using the method of the,

[0040] - is a sequence diagram showing in more detail the steps of the manufacturing process of the,

[0041] - describes the stages of the,

[0042] - is a sequence diagram showing steps for installing an initial version of secure firmware into a hardware security module,

[0043] - describes the stages of the,

[0044] - laet lasont sequence diagrams showing steps for installing a later secure firmware version,

[0045] - laet ladescribe the steps of laet of the, and

[0046] - shows a system architecture using secure hardware security modules in accordance with this disclosure. Detailed description

[0047] This schematically shows a typical method for signing a firmware, for example, intended to be installed in a hardware security module. A firmware source code FW is first transformed by a BSRV0 integration server ("Build Server") into object code or executable code forming a DB1 data block, for example in ELF (Executable and Linkable Format). An ISIGN installation signature is then calculated using an installation private key IpK. For this purpose, the DB1 data block is applied to a hash function FH1, which provides a digest H1 of it. The digest H1 and the installation private key IpK are applied to a signature function FS1, which provides the ISIGN signature. This operation can be carried out by a hardware security module HSMa, which provides the installation private key IpK and 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(FS1) ("Object Identifier") field providing 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(DB1) field can also be inserted before the DB1 data block, to indicate its size.

[0048] The DB1 executable code concatenated with the metadata SIZE(DB1), SIZE(ISIGN), ISIGN, SIZE(OID), and OID(FS1) forms a final DBF data block that is provided to the operator of an HSMo hardware security module 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. When installing the firmware, the hardware security module operating system checks the validity of the ISIGN signature using the installation public key IPK, and refuses to proceed with this installation if the signature is found to be invalid.

[0049] For example, if the ISIGN signature is an RSA signature, the verification of the signature includes the operations consisting on the one hand of finding the original digest H1 by providing to a function FS1 -1inverse of FS1 the data block DB1 and the public key IPK, and on the other hand calculate 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 OS operating system of the HSMo hardware security module agrees to load the firmware into its PMEM program memory.

[0050] Lamontre shows the classic software architecture of the HSMo hardware security module. 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 (Cryptographic 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 a Message Dispatch API (MDA) interface that sends SF standard function commands to the HSMo hardware security module via the PCI or Ethernet interface.

[0051] In the HSMo hardware security module, 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.

[0052] Thus, the hardware security module constitutes a kind 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 performed through a library of standard functions.

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

[0054] Various hardware security module manufacturers provide commands to modify the operation of hardware security modules by injecting custom firmware into them that can modify the dispatching of received messages or implement proprietary commands. In connection with the software architecture just described, it is therefore often possible to add custom functions to the SLIB2 library or to modify the execution of standard functions. This is possible, for example, using the Cprov command with some hardware security modules. In particular, in some hardware security modules, the "OS_GetCprovFuncTable" function can be used 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.

[0055] This 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 Figures 10A, 10B.

[0056] In step I01, the host device sends a call to the hardware security module HSMo for the "Install Firmware" function 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 step I02, the operating system checks that the typical execution conditions for the installation function are met. In step I03, the operating system installs and then executes the corrective firmware FW1. In step I04, the firmware FW1 is executed and puts into operation the protection module PM, which is an integral part of the firmware.At step I05, the FW1 firmware then corrects the function allocation table of the MPM0 message management module so that it, upon receiving calls to the standard “erase” or “update” functions, forwards them to the PM protection module instead of addressing them directly to the SLIB2 library of the operating system. The modified version of the MPM0 message management module will now be designated MPM1.

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

[0058] - Deletion: prohibited;

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

[0060] The software architecture of a HSMp hardware security module that has been modified as just described is shown. The hardware security module is, as before, connected to the HDV host device, whose structure and operation are unchanged. The HDV host device sends commands to execute standard SF functions, or "function calls," to the HSMp hardware security module. Unlike the MPM0 message processing module, the MPM1 module 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, calls to the "erase" function and the "update" function are sent to the PM protection module.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 involves overwriting the current firmware version in the PMEM program memory.

[0061] This is a flowchart illustrating the processing of function calls by the hardware security module HSMp. In a step E01, the message management module MPM1 receives a call to a function. In a step E02, the module MPM1 determines whether the received command relates to a modified function PF, namely erasing or updating the firmware (this step can 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 in a step E03. If the response is positive, in a step E04 the module MPM1 transmits the command to the protection module PM. In a step E05, the protection module PM determines whether the received command is a request to erase the program memory PMEM. If the response is positive, the protection module PM 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 command admissibility conditions 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 execution conditions of the modified PF or standard SF function are met. 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.

[0062] The above describes a method for modifying the processing of function calls to reject an erase request and to apply admissibility conditions to a firmware update request.

[0063] 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 update authentication 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.

[0064] 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 FW1 patch firmware. 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 patch 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.

[0065] 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 firmware 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.

[0066] According to this process:

[0067] - 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.

[0068] - for the installation of the first version of the firmware, the college of approvers issues a first pair of authentication keys comprising a first public authentication key PK1 and a first private authentication key pK1.

[0069] - the first installed firmware version includes the first public key PK1. Optionally, it can also include a signature SIGN1 generated using the private key pK1 and from a data block including the first public key PK1.

[0070] - 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,

[0071] - 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 pK1 and from a data block including at least the public key PK2,

[0072] - 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,

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

[0074] The same procedure is followed for each subsequent version of the firmware, as illustrated in Figures 6A and 6B. This illustrates a step in forming a version of the firmware of rank N. The firmware initially comprises executable code forming a data block DB1 N . A pair of authentication keys of rank N-1 including a public authentication key PK N-1 and a private authentication key pK N-1was previously generated by the college of approvers and associated with a previous version of rank N-1 of the firmware, not shown. A pair of authentication keys of rank N including a public authentication key PK N and a private authentication key pK N is now generated by the approver college and is associated with the DB1 data block N . The public key PK N is concatenated with the DB1 data block N to form a DB2 data block N . The DB2 data block N is applied to a hash function FH2 which provides an H2 digest N . The H2 condensate N and the private key pK N-1 are applied to a FS2 signature function which provides a SIGN signature N such as :

[0075] SIGN N = FS2 [pKN-1] (H2 N ) = FS2 [pKN-1] (FH2(DB1 N ||PK N ))

[0076] “||” representing the concatenation operation.

[0077] The SIGN signature N is then concatenated to the DB2 data block N to get a DB3 data block N which here forms the final version of the firmware, the authenticity of which can be verified using the public key PK N-1 present in the previous firmware version.

[0078] Illustrates a step in the formation of a version of the firmware of rank N+1. The firmware initially comprises an executable code forming a DB1 data block N+1 . A pair of authentication keys of rank N+1 including a public authentication key PK N+1 and a private authentication key pK N+1 is generated by the approver college and is associated with the DB1 data block N+1 . The public key PK N+1 is concatenated with the DB1 data block N+1 to form a DB2 data block N+1. The DB2 data block N+1 is applied to the hash function FH2 which provides an H2 digest N+1 . The H2 condensate N+1 and the private key pK N are applied to the FS2 signature function which provides a SIGN signature N+1 , such as :

[0079] SIGN N+1 = FS2 [pKN] (H2 N+1 ) = FS2 [pKN] (FH2(DB1 N+1 ||PK N+1 ))

[0080] The SIGN signature N+1 is then concatenated to the DB2 data block N+1 to get a DB3 data block N+1 which here forms the final version of the firmware, the authenticity of which can be verified using the public key PK N present in the N-rank version installed in the hardware security module.

[0081] 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 can also 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 N-1, 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 N-1 and the verification of this signature is made by means of the public authentication key of rank N-1.

[0082] Shows steps to verify the authenticity of DB3 data blocks N and DB3 N+1. The SIGN signature N from the DB3 block N is verified using a VRFY signature verification function which receives as input:

[0083] - the signature to be verified SIGN N , present in the DB3 block N ,

[0084] - the DB2 data block N from which the signature SIGN N was generated, present in block DB3 N , this data block here including the DB1 data block N (the executable code) and the public key PK N ,

[0085] - the public key PK N-1 present in the DB3 block N-1 , corresponding to the private key pK N-1 by means of which the signature SIGN N was generated

[0086] Similarly, the SIGN signature N+1 from the DB3 block N+1 is checked using the VRFY function which receives as input:

[0087] - the signature to be verified SIGN N+1, present in the DB3 block N+1 ,

[0088] - the DB2 data block N+1 from which the signature SIGN N+1 was generated, present in block DB3 N+1 , this data block here including the DB1 data block N+1 and the public key PK N+1 , And

[0089] - the public key PK N present in the DB3 block N , corresponding to the private key pK N by means of which the signature SIGN N was generated.

[0090] For each check, the VRFY verification function provides a "VALID" or "INVALID" result depending on the input data provided to it. Thus, each SIGN signature of a data block of a given rank can be verified using 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 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 it contains, which will then be used to validate the next data block.

[0091] The VRFY verification function is itself classical 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 H2 digest 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 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.

[0092] Illustrates a variant of the step of forming a firmware of rank N+1 which was described in relation to Figures 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.

[0093] A FW version N+1 of rank N+1 of the firmware is first designed, in the form of source code. This version includes an AFW application program N+1 (“Firmware Application”) and a PFW modifier program N+1("Firmware Patch"). The application program is intended to carry out operations intended within the framework of a specific application. An example of such an application will be described later in relation to the. The PFW modification program N+1 aims to implement the previously described PM protection module into the machine operation, while transforming the message processing module MPM0() into a message processing module MPM1() configured to pass on to the PM protection module calls to the erase function or the update function.

[0094] The FW version N+1 The firmware is first sent to a BSRV1 integration server which compiles the firmware to provide object code or executable code forming the DB1 data block N+1 The integration server then appends to the DB1 data block N+1 , by concatenation, the following metadata:

[0095] - a first MK1 marker,

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

[0097] - a second MK2 marker,

[0098] - the public authentication key PK N+1 associated with this firmware version, and

[0099] - a third MK3 marker.

[0100] The DB1 data block N+1 concatenated with these different metadata forms the DB2 data block N+1 , which differs from the one previously described with the same reference in that it includes a greater number of metadata. Then, and as previously described, the DB2 data block N+1 is applied to the hash function FH2 which provides the digest H2 N+1 . The H2 condensate N+1and the private authentication key pK N are applied to the FS2 function which provides the SIGN signature N+1 . This step of generating the SIGN signature N+1 may, in one embodiment, be performed by a hardware security module HSM1a of the APRV approver college.

[0101] The SIGN signature N+1 is then concatenated to the DB2 data block N+1 to get the DB3 data block N+1 which previously formed the final version of the firmware. Here, the DB3 data block N+1 undergoes an additional processing step before obtaining the final firmware version. During this step, the DB3 data block N+1 is signed using an FS1 function. This signature is typically generated by a signing hardware security module HSM1b, which generates a public installation key IPK N+1 and an IpK installation private key N+1then proceed with the DB3 data block N+1 in the same way as the hardware security module HSMa does with the DB1 data block. Thus, the DB3 data block N+1 is applied to a hash function FH1 which provides a digest H1 N+1 . The H1 digest N+1 as well as the IpK installation private key N+1 are applied to the FS1 function which provides an ISIGN signature N+1 . The ISIGN signature N+1 is then concatenated by the signing hardware security module HSM1b with the DB3 data block N+1 , being preceded by a SIZE(ISIGN) field indicating the size of this signature, followed by an OID(FS1) 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 DB3 data block N+1 to indicate the size of it.

[0102] The whole thing forms a DB4 data block N+1 which is the final version of the firmware. In order to allow the installation of this DB4 version N+1 firmware, the public installation key IPK N+1 is provided to the HSMp hardware security module administrator, who registers it in a hardware security module administrator account. The HSMp hardware security module then verifies the validity of the ISIGN installation signature N+1 using the public installation key IPK N+1 If the signature is valid, the HSMp hardware security module operating system agrees to load the firmware into its PMEM program memory. However, here, the PM protection module intervenes before verifying the validity of the ISIGN installation signature. N+1 by the operating system, to verify the SIGN authentication signature N+1 .

[0103] Lamontre shows the structure of three successive microprograms of respective ranks N, N+1, N+2 produced according to the process of la.

[0104] The N-rank firmware includes, in the order shown, the SIZE(DB3 N ), the executable code forming the DB1 block N , the MK1 marker, the VN version number( N ), the MK2 marker, the public authentication key PK N , the MK3 marker, the SIGN authentication signature N , the SIZE(ISIGN) field, the ISIGN installation signature N , the SIZE(OID) field and the OID(FS1) identifier.

[0105] Similarly, the N+1 rank firmware includes the SIZE(DB3 N+1 ), the executable code forming the DB1 block N+1 , the MK1 marker, the VN version number( N+1 ), the MK2 marker, the public authentication key PK N+1 , the MK3 marker, the SIGN authentication signature N+1, the SIZE(ISIGN) field, the ISIGN installation signature N+1 , the SIZE(OID) field and the OID(FS1) identifier.

[0106] Similarly, the N+2 rank firmware includes the SIZE(DB3 N+2 ), the executable code forming the DB1 block N+2 , the MK1 marker, the VN version number( N+2 ), the MK2 marker, the public authentication key PK N+2 , the MK3 marker, the SIGN authentication signature N+2 , the SIZE(ISIGN) field, the ISIGN installation signature N+2 , the SIZE(OID) field and the OID(FS1) identifier.

[0107] It also shows the different authentication key pairs generated by the APRV approver college:

[0108] - the private authentication key pK N-1 having allowed the SIGN authentication signature to be generated N , and the corresponding public key PK N-1 . The latter is inserted into a DB3 block N-1 of a previous firmware version, not shown in the figure,

[0109] - the private authentication key pK N having allowed the SIGN authentication signature to be generated N+1 , and the corresponding public key PK N which is inserted into the DB3 data block N ,

[0110] - the private authentication key pK N+1 having allowed the SIGN authentication signature to be generated N+2 , and the corresponding public key PK N+1 which is inserted into the DB3 data block N+1 , And

[0111] - the private authentication key pK N+2 which will generate the authentication signature of a next version of the firmware, and the corresponding public key PK N+2 , which is inserted into the DB3 data block N+2 . And

[0112] Lamontre also:

[0113] - DB2 blocks N , DB2 N+1 , DB2N+2 from which the SIGN authentication signatures N , SIGN N+1 , SIGN N+2 are generated,

[0114] - the IpK installation private key N having allowed the generation of the ISIGN installation signature N , and the corresponding public key IPK N ,

[0115] - the IpK installation private key N+1 having allowed the generation of the ISIGN installation signature N+1 , and the corresponding public key IPK N+1 , as well as

[0116] - the IpK installation private key N+2 having allowed the generation of the ISIGN installation signature N+2 , and the corresponding public key IPK N+1 .

[0117] In summary, each subsequent firmware is linked to the previous firmware by an authentication link that resides in the private authentication key corresponding to the public authentication key inserted in the previous firmware. This private key is used to generate the authentication signature inserted in the subsequent firmware, while the public authentication key inserted in the previous firmware is used to verify this signature. Furthermore, the inviolability of the signature chain is achieved by the fact that the public authentication key that is inserted in the previous firmware forms the input data of the authentication signature inserted in the previous firmware, itself generated by means of the private key associated with the firmware that precedes the previous firmware.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 the iterative authentication process inviolable.

[0118] As discussed above, according to one aspect of the present disclosure, the iterative authentication method just described is implemented by the PM protection module which is incorporated into the firmware of the hardware security module.

[0119] This is a sequence diagram describing an embodiment of the firmware manufacturing method of the. This describes the steps of the. 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.

[0120] Lamontre four entities: the BSRV1 integration server, the APRV approver college HSM1a hardware security module, the signing hardware security module HSM1b and the FW firmware being manufactured.

[0121] In step S01, 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.

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

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

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

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

[0126] At step S11, the hardware security module HSM1a verifies that the version number VN added to the firmware is correct.

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

[0128] 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.

[0129] At 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 N-1, i.e., assuming that the version being produced is a version of rank N: SIGN = FS2 [pKN-1] (H2). In one embodiment, the FS2 signature function is the ECDSA-secp256k1 function.

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

[0131] In step S21, the data block DB3 is provided to the signing hardware security module HSM1b.

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

[0133] In step S24, the hardware security module HSM1b 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 = FS1 [IpK] (H1). In one embodiment, the signature function FS1 is the RSA2048_pkcs function.

[0134] At step S25, the hardware security module HSM1b adds the function OID FS1 and the signature ISIGN to the data block DB3, to obtain the data block DB4.

[0135] This is a sequence diagram describing a detailed embodiment of a step of installing in the HSMp hardware security module, a first FW1 version of the firmware according to the present disclosure. This is a flowchart describing the steps of the. 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 HSMp hardware security module. The latter is then self-protected against erasure or installation of later versions which would not be authentic, and it is notably no longer necessary to involve an observer.Installations of subsequent versions are then considerably simplified, and can even be carried out remotely.

[0136] The process here involves four entities:

[0137] - a PART1 part, for example a company having developed the firmware as described in relation to figures 9A, 9B,

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

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

[0140] - the MPM0 message processing module of the HSMp hardware security module in its initial state upon leaving the factory (this will become the MPM1 message processing module at a certain stage of the installation process), and

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

[0142] In step S27, PART1 communicates the public installation key IPK to PART2. In step S28, PART2 communicates the installation key IPK to the HSMp hardware security module. The HSMp hardware security module's OS saves the key in a register AREG accessible only to an administrator.

[0143] At 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).

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

[0145] In a step S34, the party PART1 sends the firmware FW1 to the party PART2. In one embodiment, the party PART1 also communicates to the party PART2 the source code of the firmware, as well as the public authentication key PK and the version number. However, 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.

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

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

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

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

[0150] At step S44, the OS executes the FW1 firmware and installs the PM protection module.

[0151] In 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 erase requests and verify, before executing an update request, that the update firmware is authentic.

[0152] 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 key pair is for example generated on the ECDSA P-256 curve. This attestation key pair is saved in a secure memory of the hardware security module HSMp, which will not be erased during future updates.

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

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

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

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

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

[0158] At step S60, party PART1 uses the observer's public key OPK to verify the authenticity of the APK signature, by verifying the OSIGN signature using the public key OPK.

[0159] 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 PART1 integrates the hardware security module HSMp into a public key infrastructure PKI ("Public Key Infrastructure") of its own. For this purpose, the party PART1 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 PART1 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 modification of this part of the memory of the hardware security module, only the firmware modified in accordance with this disclosure can do so.

[0160] In summary, installing the first firmware version differs from subsequent update installations by the fact that:

[0161] - that it is not necessary to provide the SIGN authentication signature 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 ISIGN installation signature, etc. This does not exclude, however, that in an embodiment this signature is provided and verified.

[0162] - that the first version generates the AKEYP attestation key allowing the creation of the aforementioned trust link with the PART1 party.

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

[0164] 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.

[0165] The process here involves four entities:

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

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

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

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

[0170] 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 that is modified to be processed by the PM protection module is broken down into three PKCS#11 function calls:

[0171] - C_VerifyInit,

[0172] - C_VerifyUpdate,

[0173] - C_VerifyFinal.

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

[0175] FunctionTable *table = OS_GetFunctionTable();

[0176] table->C_VerifyInit = Custom_C_VerifyInit;

[0177] table->C_VerifyUpdate = Custom_C_VerifyUpdate;

[0178] table->C_VerifyFinal = Custom_C_VerifyFinal;

[0179] table->C_SetAttributeValue = Custom_C_SetAttributeValue

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

[0181] - a processing phase of the function call “VerifyInit(mechanism= FirmwareUpdate)”, the “mechanism” field included in the command meaning that the VerifyInit function is called here to prepare an update operation,

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

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

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

[0185] Phase 1, processing the function call “VerifyInit(mechanism= FirmwareUpdate)”

[0186] At step S70, part PART2 downloads data block DB4.

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

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

[0189] At step S76, the PM protection module initializes a state machine that it will need to analyze the structure of the DB4 data block.

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

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

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

[0193] This processing may include looping through a plurality of "VerifyUpdate(BUF)" commands until the entire DB4 data block is stored in the BUF buffer.

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

[0195] At 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.

[0196] At 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 authentication public key PK N , because this key is of rank N and will only be used after installation of the update, for the authentication of a following update.

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

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

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

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

[0201] At step S96, the PM protection module has completed the preparatory step and transfers the VerifyUpdate(BUF) command to the operating system so that the operating system can perform the usual steps for processing this command.

[0202] Phase 3, processing the function call "VerifyFinal(ISIGN)" ().

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

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

[0205] If the protection module PM could not identify the valid markers MK1 and MK3 during the previous phase, the PM module 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.

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

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

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

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

[0210] At step S114, if the signature is invalid, the protection module PM sends an “Invalid Signature” message to the message processing module MPM1 and refuses to transfer the command to the operating system for firmware update.

[0211] At a step S116, if step S114 has been implemented, the message processing module MPM1 passes on the message “Invalid Signature” to the party PART2.

[0212] At step S118, if none of the above errors have been found, the PM module transfers the command "VerifyFinal(ISIGN)" to the operating system for firmware update. The latter then executes this command in the usual way, verifying the ISIGN installation signature.

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

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

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

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

[0217] At 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.

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

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

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

[0221] Lamontre a CW1 cryptoasset wallet and a system designed to implement a process for saving the seed S of cryptoasset accounts held by the CW1 wallet. Such a process is, for example, offered to the public under the trade name “Recover”.

[0222] The CW1 cryptoasset wallet comprises a hardware device and a host device HDV. The hardware 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 hardware device has no 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 via a USB or Bluetooth connection.

[0223] The seed backup system comprises a set of BCKi backup servers (BCK1,…BCKi,…BCKm) each equipped with an HSM hardware security module (HSM1,…HSMi,…HSMm). Each backup server has a back-end program designed to implement the seed backup process.

[0224] The hardware wallet HW is configured to divide the seed S into a plurality of secret data Si (S1,…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 achieved by means of a secret sharing function SS allowing to generate a number of secret data called "shares", allowing the reconstitution of the seed from a threshold of secret data Si.

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

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

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

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

[0229] - 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,

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

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

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

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

[0234] The CA is preferably owned by the manufacturer of the HW device, to enable it to control the allocation of CBi certificates to the BCKi backup servers, so that these can be members of the public key infrastructure. This manufacturer is for example the party PART1 cited in the above. The BCKi backup servers and the HSMi hardware security modules 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 PART1 and is updated by it. The single source of authentication keys pKi, PKi of the HSMi hardware security modules is owned by the party PART1, for example the APRV approver college and the HSM1a hardware security module.

[0235] Thanks to the process described above, PART1 has the assurance that the firmware of the various HSMi hardware security modules cannot be corrupted by a fraudster who interferes with the server maintenance teams 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 in 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.

[0236] To implement a secure communication channel, a key exchange is planned between the HW device and each BCKi backup server, allowing the generation of kBi session keys specific to each BCKi server but known to the HW device. This key exchange includes, for example, the following steps:

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

[0238] CeBi = [PeBi, SIGN [ApKi] (PeBi)]

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

[0240] ii) the HW device itself generates an ephemeral private key pair peD and public key PeD, then communicates its ephemeral public key PeD to the BCKi backup servers 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.:

[0241] CeD = [PeD, SIGN [pD] (PeD)]

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

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

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

[0245] 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 (Elliptic Curve Diffie–Hellman key exchange), i.e.:

[0246] kBi = ECDH(peBi, PeD)

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

[0248] kBi = ECDH(peD, PeBi)

[0249] 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 S1, S2, S3 (the threshold n can then be equal to 2 or 3) and three backup servers BCK1, BCK2, BCK3 are provided. Each server BCKi generates its own session key kB1, kB2, kB3. The HW device generates each of these session keys after an exchange of keys with each server, in the manner just described. Then, the HW device conducts symmetric encryption steps for the shares S1, S2, S3 using these keys, namely:

[0250] - encrypts the part S1 with the key kB1, i.e. {S1}kB1, then sends it to the server BCK1,

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

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

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

[0254] It will be clear to those skilled in the art that the iterative authentication method described in the foregoing is susceptible to 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 can 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 can 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 scanned 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.

[0255] Additionally, the encapsulation of the DB3 data block into the DB4 data block, specific to the requirements of hardware security modules when installing firmware, may not be provided in another application, or may be replaced by another type of encapsulation.

[0256] Also, as indicated in the above, the successive authentication key pairs used to authenticate the different versions of the DB1 data block may all be different or all identical, or sometimes identical and sometimes different, the method only requiring 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 refer to 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 N-1, otherwise it will not be able to sign the public key of rank N using the private key of rank N-1.Thus, if a change in the generating source of the authentication key pairs occurs during the iterative process, this means that there has been a "passing of secrecy", namely that the new source of key pairs has received, from the source of previous key pairs, the last private key that the previous source generated. Even in this case, two sources can be considered as the "same generating source" since there is continuity in the knowledge of the private keys from one iteration to the next.

Claims

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 (DB3 N , DB4 N ) including executable code (DB1 N ) and a first public key (PK N ), and- upon receipt of a command to install a second version of the firmware (DB3) in the program memory N+1 , DB4 N+1 ) intended to overwrite the first version of the firmware and including executable code (DB1 N+1 ), a second public key (PK N+1 ) and an authentication signature (SIGN N+1 ) of the second firmware version: - check the validity of the authentication signature (SIGN N+1 ) of the second firmware version using the first public key (PK N) present in the first version (DB3 N+1 , DB4 N+1 ) of the firmware and from a first data block (DB2 N+1 ) of the second firmware version including at least the second public key (PK N+1 ), and- reject the installation command if the authentication signature (SIGN N+1 ) of the second firmware version is not valid, the authentication signature (SIGN N+1 ) of the second firmware version being generated using a first private key (pK N ) corresponding to the first public key (PK N ) present in the first firmware version, and from the first data block of the second firmware version including at least the second public key (PK N+1), method further comprising the step of providing a protection module (PM) in the first version of the firmware, and the steps of:- sending (MPM1, E02, E04) to the protection module any command to install a new version of the firmware in the program memory, and- by ​​means of the protection module, ensuring verification of the validity of the authentication signature (SIGN N+1 ) of the second firmware version, and refuse to execute the installation command if the signature is invalid, so that after installing 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 (SIGN N+1 ) recognized as valid by the protection module. Method according to claim 1, in which:- the first and second versions of the firmware are provided by a first party (PART1) holding the first private key (pK N ) and having generated the authentication signature (SIGN N+1 ) 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 (PART2) not having knowledge of the first private key (pK N ), such 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 that does not include a valid authentication signature generated using the first private key. Method according to one of claims 1 and 2, in which the first data block (DB2 N+1) of the second firmware version also includes the executable code (DB1 N+1 ) of the second firmware version. Method according to one of claims 1 to 3, in which the first data block (DB2 N+1 ) of the second firmware version also includes a version number (VN) of the firmware, the method including 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. Method according to one of claims 1 to 4, in which the first data block (DB2 N+1 ) of the second firmware version also includes markers (MK1, MK2, MK3) to distinguish metadata (VN, PK N+1 , SIGN N+1 ) concatenated to the executable code (DB1 N+1) of the firmware, the method comprising the step of refusing to update the first version of the firmware if the markers are not identified. Method according to one of claims 1 to 5, in which the second public key (PK N+1 ) is identical to the first public key (PK N ). Method according to one of claims 1 to 5, in which the second public key (PK N+1 ) is different from the first public key (PK N ). Method according to one of claims 1 to 7, in which the second version of the firmware further comprises an installation signature (ISIGN N+1 ) generated using an installation private key (IpK N+1 ) and from a second data block (DB3 N+1 ) including at least the executable code (DB1 N+1 ) of the second firmware version and the authentication signature (SIGN N+1), and wherein the installation of the second version of the firmware includes a step of providing the processor with an installation public key (IPK N+1 ) corresponding to the installation private key (IpK N+1 ), and a verification step by the processor, using the public installation key, of the validity of the installation signature. The method of one of claims 1 to 8, wherein the processor is a hardware security module (HSM), and wherein the firmware is configured to receive and store secrets relating to cryptoasset accounts. Processor (HSMp) including a first version (DB3 N , DB4 N ) of a firmware installed in a program memory (PMEM) of the processor, the firmware comprising an executable code (DB1 N ) and a first public key (PK N), the processor being configured to, during 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 (DB3 N+1 , DB4 N+1 ) intended to overwrite the first version of the firmware and including executable code (DB1 N+1 ), a second public key (PK N+1 ) and an authentication signature (SIGN N+1 ) :- check the validity of the authentication signature (SIGN N+1 ) of the second firmware version using the first public key (PK N ) present in the first version (DB3 N , DB4 N ) of the firmware and from a first data block (DB2 N+1 ) of the second firmware version including at least the second public key (PK N+1 ), and- reject the installation command if the authentication signature (SIGN N+1) of the second firmware version is not valid, the authentication signature (SIGN N+1 ) of the second firmware version being generated using a first private key (pK N ) corresponding to the first public key (PK N ) present in the first firmware version, and from the first data block of the second firmware version including at least the second public key (PK N+1 ), and 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 command to install a new version of the firmware in the program memory, and- by ​​means of the protection module, ensure verification of the validity of the authentication signature (SIGN N+1) of the second firmware version and refuse execution of the installation command if this signature is not valid, so 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 (SIGN N+1 ) recognized as valid by the protection module. Processor according to claim 10, 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 does not include an authentication signature generated by means of the first private key (pK N ). Processor according to one of claims 10 and 11, in which the first data block (DB2 N+1 ) of the second firmware version also includes the executable code (DB1 N+1 ) of the second firmware version. Processor according to one of claims 10 to 12, in which the first data block (DB2 N+1) of the second firmware version also includes 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. Processor according to one of claims 10 to 14, in which the first data block (DB2 N+1 ) of the second firmware version also includes markers (MK1, MK2, MK3) to distinguish metadata (VN, PK N+1 , SIGN N+1 ) concatenated to the executable code (DB1 N+1 ) of the firmware, the method comprising the step of refusing to update the first version of the firmware if the markers are not identified. Processor according to one of claims 10 to 14, configured not to check whether the second public key (PK N+1 ) is identical to the first public key (PK N ) or different from it. Processor according to one of claims 10 to 15, in which the second version of the firmware further comprises an installation signature (ISIGN N+1 ) generated using an installation private key (IpK N+1 ) and from a second data block (DB3 N+1 ) including at least the executable code (DB1 N+1 ) of the second firmware version and the authentication signature (SIGN N+1 ), the processor being configured to, when installing the second version of the firmware, verify the validity of the installation signature by means of an installation public key (IPK N+1 ) corresponding to the installation private key (IpK N+1 ). Processor according to one of claims 10 to 16, forming a hardware security module (HSM). The processor of claim 17, wherein the firmware is configured to receive and store secrets relating to cryptoasset accounts.

Images