Self-protected processor against erasure or modification of firmware

Abstract

The invention relates to a method for securing the installation and updating of different versions 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 firmware of rank N (DB3N, DB4N) comprising an executable code of rank N (DB1N) and an authentication signature of rank N (SIGNN), the executable code of rank N (DB1N) including a protection module (PM), applying to the processor a command for installing in the program memory a firmware of rank N+1 (DB3N+1, DB4N+1) intended to overwrite the firmware of rank N (DB3N, DB4N) by simultaneously overwriting the protection module (PM) included in the executable code of rank N (DB1N), and by means of the protection module executed by the firmware of rank N (DB3N, DB4N),verify that the N+1 rank authentication signature (SIGNN+1) is valid and authorize the installation of the N+1 rank firmware if the signature is valid, otherwise reject the installation command. Fig. 8B,

Description

Title of the invention: Self-protected processor against erasure or modification of a microprogram Technical field

[0001] The present invention relates to a method for securing the installation and updating of different versions of a firmware in a program memory of a processor, and a system for securing the installation and updating of different versions of a firmware in a program memory of a processor, the system comprising means for generating the different versions of the firmware and means for installing the different versions of the firmware in the 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 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 has been produced by the approved designer, thanks to the communication by the latter of the corresponding public key. On the other hand, 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 all the rights to its program memory. A person who manages to steal his access codes could make modifications to the firmware aimed at modifying 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 updating of different versions 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 firmware of rank N comprising an executable code of rank N and an authentication signature of rank N, the executable code of rank N including a protection module; applying to the processor a command for installing in the program memory a firmware of rank N+1 intended to overwrite the firmware of rank N by simultaneously overwriting the protection module included in the executable code of rank N, the firmware of rank N+1 comprising an executable code of rank N+1 and an authentication signature of rank N+1, the executable code of rank N+1 including the protection module;and by means of the protection module executed by the firmware of rank N, verify that the authentication signature of rank N+l is valid and authorize the installation of the firmware of rank N+l if the signature is valid otherwise reject the installation command. ;

[0012] According to one embodiment, the method comprises the step of, by means of the executable code of rank N, modifying a function allocation table of the processor so that the protection module receives any installation command that can be applied to the processor for the installation in the program memory of a new version of the firmware, and in which the executable code of the firmware of rank N+1 is also configured to modify the function allocation table of the processor so that the protection module of the firmware of rank N+1 receives any installation command that can be applied to the processor for the installation in the program memory of a new version of the firmware.

[0013] According to one embodiment, the method comprises the step of configuring the protection module of each version of the firmware to reject any command to erase the program memory, such that each version of the firmware, once installed, can no longer be erased, and can only be replaced by a new version having a valid authentication signature.

[0014] According to one embodiment, the method comprises the step of modifying the function allocation table of the processor by means of the executable code of each version of the firmware, so that the protection module receives any command to erase the program memory which can be applied to the processor.

[0015] According to one embodiment, the different authentication signatures are generated by means of at least one secret data item held by a first party, the different versions of the firmware are installed in a processor owned and operated by a second party not having knowledge of the secret data item, in such a way that the second party, once a version of the firmware has been installed, cannot replace it with a version which does not include an authentication signature which only the first party is able to generate.

[0016] According to one embodiment, N is an integer at least equal to 2, the method comprising a step of first installation of a microprogram of rank N=1 in the program memory of the processor in the factory state, the microprogram of rank 1 comprising an executable code including the protection module.

[0017] According to one embodiment, the N-rank firmware comprises a N-rank public key corresponding to a N-rank private key, the N+1-rank firmware comprises a N+1-rank public key corresponding to a N+1-rank private key, and the N+1-rank authentication signature is generated using the N-rank private key and from at least the N+1-rank public key, the N+1-rank public key and the N+1-rank private key possibly being identical to or different from the N-rank public key and the N-rank private key.

[0018] According to one embodiment, the authentication signature of rank N+1 is generated by means of the private key of rank N and from a data block comprising at least the executable code of rank N+1 and the public key of rank N+1.

[0019] According to one embodiment, the authentication signature of rank N+1 is generated by means of the private key of rank N and from a data block comprising at least the executable code of rank N+1, a version number of the firmware of rank N+1 and the authentication key of rank N+1.

[0020] According to one embodiment, the method comprises the step of configuring each protection module to reject a command to install firmware not having a version number later than the firmware that executes the protection module.

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

[0022] Embodiments also relate to a system for securing the installation and updating of different versions of a firmware in a program memory of a processor, the system comprising means for generating the different versions of the firmware and means for installing the different versions of the firmware in the program memory of the processor, the system being configured to install in the program memory of the processor a firmware of rank N comprising an executable code of rank N and an authentication signature of rank N, the executable code of rank N including a protection module, and applying to the processor an installation command in the memory program of a firmware of rank N+l intended to overwrite the firmware of rank N by simultaneously overwriting the protection module included in the executable code of rank N, the firmware of rank N+l comprising an executable code of rank N+l and an authentication signature of rank N, the executable code of rank N+l including the protection module, the protection module of the firmware of rank N being configured to verify that the authentication signature of rank N+l is valid, authorize the installation of the firmware of rank N+l if the signature is valid otherwise reject the installation command.

[0023] According to one embodiment, the executable code of each version of the firmware is configured to modify a function allocation table of the processor so that the protection module of rank N and following receives any installation command that can be applied to the processor for the installation in the program memory of a new version of the firmware.

[0024] According to one embodiment, the protection module of each version of the firmware is configured to reject any command to erase the program memory, such that each version of the firmware, once installed, can no longer be erased, and can only be replaced by a new version having a valid authentication signature.

[0025] According to one embodiment, the executable code of each version of the firmware is also configured to modify the function allocation table of the processor so that the protection module receives any command to erase the program memory that can be applied to the processor.

[0026] According to one embodiment, the N-rank firmware comprises a N-rank public key corresponding to a N-rank private key, the N+1-rank firmware comprises a N+1-rank public key corresponding to a N+1-rank private key, and the N+1-rank authentication signature is generated using the N-rank private key and from at least the N+1-rank public key, the N+1-rank public key and the N+1-rank private key possibly being identical to or different from the N-rank public key and the N-rank private key.

[0027] According to one embodiment, the system is configured to generate the authentication signature of rank N+1 using the private key of rank N and from a data block comprising at least the executable code of rank N+1 and the public key of rank N+1.

[0028] According to one embodiment, the system is configured to generate the authentication signature of rank N+1 is generated by means of the first private key and from a data block comprising at least the executable code of rank N+1, a version number of the firmware of rank N+1 and the authentication key of rank N+1.

[0029] According to one embodiment, each protection module is configured to reject a command to install a firmware that does not have a version number later than the firmware that executes the protection module.

[0030] According to one embodiment, the firmware is configured to receive and store secrets relating to cryptoasset 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 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 BSRVO ("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 version of the firmware. 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 installation public key IPK, 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 MPMO ("Message Processing Module") designed for example to process PKCS#11 functions. The MPMO 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 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, likely to be used by a malicious person.

[0055] Various manufacturers of hardware security modules provide commands for modifying the operation of the hardware security modules by injecting user firmware (“custom firmware”) into them that can modify the dispatching of received messages 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 MPM0, the module MPM1 does not systematically send all received function calls to the SLIB2 library of the operating system OS. Since its function allocation table has been modified, calls to the "erase" function and to 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 to be executed 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 hardware security module HSMp upon first installation of the FW1 patch firmware. This key is present only in the first installed firmware version 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 firmware version is provided with a signature of it 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.

[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 authentication key pKb

[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 key public 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 pKN [ 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 JS21pKN1j(H2n) = 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, the authenticity of which can be verified using the public key PKX । present in the previous version of the firmware.

[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 N1.

[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 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 allow the validation of the next 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+1 of the firmware is first designed, in the form of source code. This version comprises 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 context of a specific application. An example of such an application will be described later in relation to [Fig. 13]. The modification program PFWn+i aims to implement the protection module PM previously described in the operation of the machine, while transforming the message processing module MPM0 ([Fig.2]) into a message processing module MPM1 ([Fig.4]) configured to pass on to the protection module PM calls to the erase function or to the update function.

[0095] The FWn+i version of the firmware 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+i. 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 H1n+i digest along with the IpKN+i installation private key 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, which registers it in a hardware security module administrator account. The HSMp hardware security module then checks the validity of the ISIGNn+i installation signature using the IPKn+i installation public key. 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 the operating system checks the validity of the ISIGNn+i installation signature, to verify the SIGNn+i authentication signature.

[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 PKN4. The latter is inserted into a DB3N i block of a previous firmware version, 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+[ 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 DB3N+2 data block. 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 the iterative authentication process inviolable.

[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 BSRV1 integration server, the module of APRV approver college HSMla hardware security module, HSMlb signing hardware security module and FW firmware in production.

[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 = FS2lpKN_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 = FS 1^(111). In one embodiment, the function FS1 signature function is the RSA2048_pkcs function.

[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 MPMO a command to install the firmware FW1. At this stage, the message processing module MPMO 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 MPMO 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] In a step S46, the protection module PM modifies the function allocation table of the message processing module MPMO to lock the entry points of the HSM: the message processing module MPMO becomes the message processing module MPM1, designed to reject erase 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 key APK to part 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 firmware version differs from subsequent update installations by the fact that:

[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 makes it possible to modify a function allocation table in order to return to the PM protection module the processing of calls to the three aforementioned functions. The example below is a program sequence which makes it possible to return the processing of these three functions to the PM protection module:

[0176] FunctionTable *table = OS_GetFunctionTable();

[0177] table->C_VerifyInit = 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 meaning that the Verifylnit function is called here to prepare an update operation,

[0183] - 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 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 “VerifyInit(mechanism=FirmwareUpdate)” command to the PM protection module.

[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 ins- installation of the update, for authentication of a subsequent 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 firmware update.

[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 has no means of connecting to the Internet and is connected to the host device HDV, which executes a HSW companion software allowing it to connect to the Internet, for example via USB or Bluetooth.

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

[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 certification authority:

[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 backup server BCKi 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 PD public key present in the CD certificate using 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 has received from the HW device, and stores it in its MEM memory, possibly in 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 data block DB1 which is encapsulated in the data block DB3. This data block may be something other than a code executable by a processor. The method may also be used to secure a file of configuration, for example of type JSON, 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-return. The DB1 data block can also be the result of the digitization of a document, including text and / or one or more images, for example a book, a digital or digitized work of art or any other digital file. The method makes it possible in this case to authenticate the different versions of the document or file, from a first version whose authenticity is assured or admitted.

[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 the "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 different versions of a microprogram 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 microprogram of rank N (DB3N, DB4N) comprising an executable code of rank N (DB1N) and an authentication signature of rank N (SIGNn), the executable code of rank N (DB1N) including a protection module (PM), - applying to the processor a command to install in the program memory a microprogram of rank N+1 (DB3N+i, DB4N+i) intended to overwrite the microprogram of rank N (DB3N, DB4N) by simultaneously overwriting the protection module (PM) included in the executable code of rank N (DB1N), the microprogram of rank N+1 (DB3n+i, DB4n+i) comprising an executable code of rank N+1 (DB1n+i) and an authentication signature of rank N+1 (SIGNn+i), the executable code of rank N+1 (DB1n+i) including the protection module (PM), and - using the protection module executed by the N-rank firmware (DB3N, DB4N), check that the N+1 rank authentication signature (SIGNn+i) is valid and authorize the installation of the N+1 rank firmware if the signature is valid, otherwise reject the installation command.

2. Method according to claim 1, comprising the step of: - by means of the executable code of rank N, modifying a function allocation table (MPM1) of the processor so that the protection module (PM) receives (E04) any installation command that can be applied to the processor for the installation in the program memory of a new version of the firmware, and in which the executable code of the firmware of rank N+1 is also configured to modify the function allocation table (MPM1) of the processor so that the protection module of the firmware of rank N+1 receives (E04) any installation command that can be applied to the processor for the installation in the program memory of a new version of the firmware.

3. Method according to one of claims 1 and 2, comprising the step of configuring the protection module (PM) of each version of the firmware to reject any command to erase the program memory, such that each version of the firmware, once installed, can no longer be erased, and can only be replaced by a new version having a valid authentication signature.

4. Method according to one of claims 1 to 3, comprising the step of modifying the function allocation table (MPM1) of the processor by means of the executable code of each version of the firmware, so that the protection module receives (E04) any command to erase the program memory which can be applied to the processor.

5. Method according to one of claims 1 to 4, in which: - the different authentication signatures (SIGNn, SIGNn+i) are generated by means of at least one secret data item (pKNjpKN+i) held by a first party (PART1), - the different versions of the firmware are installed in a processor (HSMp) held and operated by a second party (PART2) not having knowledge of the secret data item, in such a way that the second party, once a version of the firmware (DB3n, DB4n) has been installed, cannot replace it with a version which does not include an authentication signature which only the first party is able to generate.

6. Method according to one of claims 1 to 5, in which N is an integer at least equal to 2, the method comprising a step of first installation of a microprogram of rank N=1 in the program memory of the processor in the factory state, the microprogram of rank 1 comprising an executable code including the protection module.

7. Method according to one of claims 1 to 6, in which: - the firmware of rank N (DB3N, DB4N) comprises a public key of rank N (PKN) corresponding to a private key of rank N (pK n), - the firmware of rank N+1 (DB3N+i, DB4N+i) comprises a public key of rank N+1 (PKn+i) corresponding to a private key of rank N+1 (pKN+i), and - the authentication signature of rank N+1 (SIGNn+i) is generated at using the private key of rank N (pKN) and from at least the public key of rank N+l, the public key of rank N+l (PKn+i) and the private key of rank N+l (pKN+i) being able to be identical or different from the public key of rank N (PKN) and the private key of rank N (pKN).

8. Method according to claim 7, in which the authentication signature of rank N+l (SIGNn+i) is generated by means of the private key of rank N (pKN) and from a data block comprising at least the executable code of rank N+l (DB3N+i, DB4N+i) and the public key of rank N+l.

9. Method according to claim 8, wherein the authentication signature of rank N+1 (SIGNn+i) is generated by means of the private key of rank N (pKN) and from a data block comprising at least the executable code of rank N+1 (DB3N+i, DB4N+i), a version number of the firmware of rank N+1 (DB3N+i, DB4N+i) and the authentication key of rank N+1.

10. The method of claim 9, comprising the step of configuring each protection module to reject a command to install firmware not having a version number later than the firmware that executes the protection module.

11. Method according to one of claims 1 to 10, in which the processor is a hardware security module (HSMp).

12. System for securing the installation and updating of different versions of a firmware in a program memory of a processor (HSMp), the system comprising means for generating the different versions of the firmware and means for installing the different versions of the firmware in the program memory of the processor, characterized in that it is configured to: - install in the program memory of the processor a firmware of rank N (DB3N, DB4N) comprising an executable code of rank N (DB1N) and an authentication signature of rank N (SIGNn), the executable code of rank N (DB1N) including a protection module (PM), and - apply to the processor a command for installing in the program memory a firmware of rank N+1 (DB3N+i, DB4N+i) intended to overwrite the firmware of rank N (DB3N, DB4N) by simultaneously overwriting the protection module (PM) included in the executable code of rank N (DB1N),the N+l rank firmware, (DB3n+i, DB4n+i) including a rank N+l executable code (DB1n+i) and a rank N authentication signature (SIGNn+i), the rank N+l executable code (DB1n+i) including the protection module (PM), the protection module (PM) of the rank N firmware (DB3N, DB4n) is configured to check that the rank N+l authentication signature (SIGNn+i) is valid, authorize the installation of the rank N+l firmware if the signature is valid otherwise reject the installation command.

13. System according to claim 12, in which the executable code of each version of the firmware is configured to modify a function allocation table (MPM1) of the processor so that the protection module (PM) of rank N and following receives (E04) any installation command which can be applied to the processor for the installation in the program memory of a new version of the firmware.

14. System according to one of claims 12 and 13, in which the protection module (PM) of each version of the firmware is configured to reject any command to erase the program memory, such that each version of the firmware, once installed, can no longer be erased, and can only be replaced by a new version having a valid authentication signature.

15. System according to claim 14, in which the executable code of each version of the firmware is also configured to modify the function allocation table (MPM1) of the processor so that the protection module receives (E04) any command to erase the program memory which can be applied to the processor.

16. System according to one of claims 12 to 15, wherein: - the N-rank firmware (DB3N, DB4N) comprises a N-rank public key (PKN) corresponding to a N-rank private key (pK n) - the N+1-rank firmware (DB3N+i, DB4N+i) comprises a N+1-rank public key (PKn+i) corresponding to a N+1-rank private key (pKN+i), and - the N+1-rank authentication signature (SIGNn+i) is generated by means of the N-rank private key (pKN) and from at least the N+1-rank public key, the public key of rank N+l (PKn+i) and the private key of rank N+l (pKN+i) may be identical or different from the public key of rank N (PKN) and the private key of rank N (pKN).

17. System according to claim 16, configured to generate the authentication signature of rank N+l (SIGNn+i) by means of the private key of rank N (pKN) and from a data block comprising at least the executable code of rank N+l (DB3N+i, DB4N+i) and the public key of rank N+l.

18. System according to claim 17, configured to generate the authentication signature of rank N+l (SIGNn+i) by means of the first private key (pKN) and from a data block comprising at least the executable code of rank N+l (DB3N+i, DB4N+i), a version number of the firmware of rank N+l (DB3N+i, DB4N+i) and the authentication key of rank N+l.

19. The system of claim 18, wherein each protection module is configured to reject a command to install firmware not having a later version number than the firmware that executes the protection module.

20. The system of any one of claims 12 to 19, wherein the firmware is configured to receive and store secrets relating to cryptoasset accounts.

Images