Method for authenticating successive versions of a computer file

Abstract

The invention relates to a method for authenticating two successive versions of a computer file, the method comprising: forming a final version of a first version of the file comprising at least one first public authentication key (PKN); generating or obtaining a second version of the file (DB1N+1); calculating an authentication signature (SIGNN+1) for the second version of the file by means of a first private authentication key (pKN) and from a data block comprising at least the second version of the file (DB1N+1) and a second public authentication key (PKN+1); and forming a final version of the second version of the file comprising the second public authentication key and the authentication signature for the second version of the file.

Description

Method for authenticating successive versions of a computer file

[0001] The present invention relates to a method for authenticating successive versions of a computer file, and a method for producing at least two versions of a computer file linked together by an authentication link. 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] 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

[0010] Embodiments relate to a method for authenticating successive versions of a computer file without using a public key infrastructure, starting from a first version of the file whose authenticity is certain or admitted, comprising the steps of providing a single source of authentication key pairs, each authentication key pair comprising a private authentication key and a public authentication key; using the single source of authentication key pairs, generating a first authentication key pair comprising a first public authentication key and a first private authentication key; forming a final version of the first version of the file, the final version of the first version of the file comprising the first version of the file and at least the first public authentication key;generating or obtaining a second version of the file, using the single source of authentication key pairs, generating a second authentication key pair comprising a second public authentication key and a second private authentication key; calculating an authentication signature of the second version of the file using the private authentication key of the first authentication key pair and from a data block comprising at least the second version of the file and the second public authentication key; and forming a final version of the second version of the file, the final version comprising at least the second version of the file, the second public authentication key and the authentication signature of the second version of the file, wherein two authentication key pairs of successive ranks may be identical or different.;

[0011] The method also comprises a step of verifying the authenticity of the final version of the second version of the file with reference to the final version of the first version of the file, the step of verifying the authenticity of the final version of the second version of the file comprising the step of verifying the validity of the authentication signature of the second version of the file by means of the first public authentication key present in the final version of the first version of the file and from the data block comprising at least the second version of the file and the second public authentication key.This authenticity verification step is conducted by a machine, processor or software entity not knowing any of the private authentication keys associated with the first public authentication key or the second public authentication key, and without verifying the authenticity of the first public authentication key and the second public authentication key by referring to a certification authority.

[0012] According to one embodiment, the method comprises the steps of assigning to the second version of the file information enabling it to be distinguished from the first version of the file, such as a version number, a creation date or other identifying information, and adding the information concerning the second version of the file to the data block from which the authentication signature of the second version of the file is calculated.

[0013] According to one embodiment, the method comprises the step of inserting markers into the data block from which the authentication signature of the second version of the file is calculated, to distinguish the second version of the file from the second public authentication key and to distinguish the second public authentication key from the information concerning the second version of the file.

[0014] According to one embodiment, the method comprises the steps of generating or obtaining a third version of the file, using the single source of authentication key pairs, generating a third authentication key pair comprising a third authentication public key and a third authentication private key, calculating an authentication signature of the third version of the file using the authentication private key of the second authentication key pair and from a data block comprising at least the third version of the file and the third authentication public key, and forming a final version of the third version of the file, the final version comprising at least the third version of the file, the third authentication public key and the authentication signature of the third version of the file.

[0015] According to one embodiment, the method comprises a step of verifying the authenticity of the final version of the third version of the file with reference to the final version of the second version of the file, the step of verifying the authenticity of the final version of the third version of the file comprising the step of verifying the validity of the authentication signature of the third version of the file by means of the second public authentication key present in the final version of the second version of the file and from the data block comprising at least the third version of the file and the third public authentication key, the step of verifying the authenticity of the final version of the third version of the file being carried out by a machine,a processor or software entity not knowing any of the private authentication keys associated with the second public authentication key or the third public authentication key, and without verifying the authenticity of the second public authentication key and the third public authentication key by referring to a certification authority.,

[0016] According to one embodiment, the method comprises the steps of assigning to the third version of the file information enabling it to be distinguished from the second version of the file, such as a version number, a creation date or other identifying information, and adding the information enabling the third version of the file to be distinguished from the second version of the file to the data block from which the authentication signature of the third version of the file is calculated.

[0017] According to one embodiment, the method comprises the step of inserting markers into the data block from which the authentication signature of the third version of the file is calculated, to distinguish the third version of the file from the third public authentication key and to distinguish the third public authentication key from the information concerning the third version of the file.

[0018] According to one embodiment, the method comprises each version of the file being a version of a document comprising text and / or images.

[0019] In one embodiment, each version of the file is a digital or digitized work of art and each version of the file corresponds to a version of the work at different stages of its creation or at different dates from the finalized work.

[0020] According to one embodiment, each file is a firmware file installed or intended to be installed in a processor.

[0021] According to one embodiment, the authenticity verification step is conducted by a protection module of the processor, the protection module being configured to prevent the firmware file from being erased and to prevent a non-authentic version of an update of the firmware file from being installed in the processor.

[0022] According to one embodiment, the method comprises the steps of concatenating the final version of the second version of the firmware file with an installation signature generated using an installation private key and from the final version of the second version of the firmware file, and providing an installation public key corresponding to the installation private key to the processor in which the second version of the firmware file is to be installed.

[0023] According to one embodiment, final versions of the firmware file are provided to an operator of the processor who does not have access to any private key.

[0024] Embodiments also relate to a method of manufacturing at least two versions of a computer file linked together by an authentication link, comprising the steps of providing a single source of authentication key pairs, each authentication key pair comprising a private authentication key and a public authentication key; using the single source of authentication key pairs, generating a first authentication key pair comprising a first public authentication key and a first private authentication key; generating or obtaining a first version of the file; forming a final version of the first version of the file, the final version of the first version of the file comprising the first version of the file and at least the first public authentication key; recording the final version of the first version of the file on a medium;generating or obtaining a second version of the file; using the single source of authentication key pairs, generating a second authentication key pair comprising a second public authentication key and a second private authentication key; calculating an authentication signature of the second version of the file using the private authentication key of the first authentication key pair and from a data block comprising at least the second version of the file and the second public authentication key; forming a final version of the second version of the file, the final version comprising at least the second version of the file, the second public authentication key and the authentication signature of the second version of the file; and recording the final version of the second version of the file on a medium.;

[0025] According to one embodiment, the method comprises the steps of assigning to the second version of the file at least one piece of information making it possible to distinguish it from the first version of the file, and adding the information concerning the second version of the file to the data block from which the authentication signature of the second version of the file is calculated.

[0026] According to one embodiment, the method comprises the steps of generating or obtaining a third version of the file; using the single source of authentication key pairs, generating a third authentication key pair comprising a third authentication public key and a third authentication private key; calculating an authentication signature of the third version of the file using the authentication private key of the second authentication key pair and from a data block comprising at least the third version of the file and the third authentication public key; forming a final version of the third version of the file, the final version comprising at least the third version of the file, the third authentication public key and the authentication signature of the third version of the file; and recording the final version of the third version of the file on a medium. Summary description of the drawings

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

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

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

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

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

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

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

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

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

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

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

[0038] - describes the stages of the,

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

[0040] - describes the stages of the,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0055] - Deletion: prohibited;

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

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

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

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

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

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

[0062] According to one aspect of the present disclosure, a method is also provided for authenticating successive versions of a computer file simply and efficiently, without relying on a PKI ("Public Key Infrastructure") infrastructure. A method is also provided for manufacturing different versions of a computer file linked together by an authentication link. This aspect of the present disclosure is applicable in particular in the context of the application considered here, namely the authentication of successive versions of a microprogram.

[0063] More specifically, an iterative authentication process is provided, which is based on the establishment of a chain of signatures between each version of the file in question and its subsequent version, so that from an initial version whose authenticity is assured or admitted, the chain of signatures of subsequent versions certifies that all these versions are authentic, without it being necessary to call upon a PKI certification authority. In the following, the file in question will be the previously mentioned firmware.

[0064] According to this process:

[0065] - 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 examples which follow, 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0083] - 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

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

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

[0086] - 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

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

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

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

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

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

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

[0093] - a first MK1 marker,

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

[0095] - a second MK2 marker,

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

[0097] - a third MK3 marker.

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

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

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

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

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

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

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

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

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

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

[0108] - 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

[0109] - 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

[0110] Lamontre also:

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

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

[0113] - 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

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

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

[0116] It will be clear to those skilled in the art that the iterative “non-PKI” authentication method just described is capable of various applications other than that relating to the updating of a firmware. It 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.

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

[0118] Also, 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 for generating the authentication key pairs, described above as a college of APRV approvers. The term "single source for generating 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.

[0119] Furthermore, it will be noted that the "non-PKI" nature of this process lies in the fact that the authentication of successive versions does not require reference to a certification authority. For example, it is not necessary to verify, using a public key provided by a certification authority, certificates that would be issued by the certification authority to certify the public authentication keys involved in the chaining of versions. Thus, the step of verifying two successive versions of a file is implemented without verifying the membership in a PKI infrastructure of the first public authentication key to the first version or of the second public authentication key attached to its second version, by any known means whatsoever.

[0120] Since it does not rely on a PKI infrastructure, the process allows for numerous applications in the field of daily life, as mentioned above (books, works of art, files generated by word processing software, etc.), for the automatic authentication of successive versions of files. By analogy, the different versions of a file form a sort of "blockchain" in which each block is a file and in which the authenticity of each block is certified by the authenticity of the previous block, by means of the public key chaining mechanism just described, up to the initial block of the blockchain, deemed authentic.

[0121] It should be noted that the "non-PKI" nature of the process concerns the authentication of the version chaining, and not the authentication of the file itself. Thus, the process does not exclude the possibility that the file may include a static certificate signed by a certification authority, which is retained from one version to another and therefore does not intervene in the chaining of versions and the verification of the authenticity of the chaining. For example, after a version N has been authenticated, it remains possible to consult the static certificate to ensure that the initial version was itself authentic. In general, the file can include any type of data and in particular any additional means of authentication. Other certificates may also be inserted over time in successive versions of the file, but they do not intervene in the verification of the authenticity of the version chaining.For example, in the case of a collective work, each creator involved in the creation of a subsequent version of the work can affix a certificate of their own. It happens that the public keys contained in such certificates are different from the public key(s) used for the authentication of the version chaining.

[0122] Similarly, the method can be implemented in a PKI infrastructure allowing different entities implementing the method to communicate with each other. When it is indicated that the method is not based on a public key infrastructure, this means that the version verification steps provided by the method do not depend on the public key of this PKI infrastructure, as we have just seen.

[0123] An example of implementation of the method by the PM protection module which is incorporated in the firmware of the hardware security module will now be described.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0141] The process here involves four entities:

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

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

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

[0145] - 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0164] 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 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 signature SIGNCA(APK) is saved by the latter 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 that would allow modification of this portion of the hardware security module's memory; only firmware modified in accordance with this disclosure can do so.

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

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

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

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

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

[0170] The process here involves four entities:

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

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

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

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

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

[0176] - C_VerifyInit,

[0177] - C_VerifyUpdate,

[0178] - C_VerifyFinal.

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

[0180] FunctionTable *table = OS_GetFunctionTable();

[0181] table->C_VerifyInit = Custom_C_VerifyInit;

[0182] table->C_VerifyUpdate = Custom_C_VerifyUpdate;

[0183] table->C_VerifyFinal = Custom_C_VerifyFinal;

[0184] table->C_SetAttributeValue = Custom_C_SetAttributeValue

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

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

[0187] - 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0206] 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 execute the standard steps for processing this command.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0226] 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”.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0240] Thanks to the process described above, PART1 is assured 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.

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

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

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

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

[0245] 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.:

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

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

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

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

[0250] 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.:

[0251] kBi = ECDH(peBi, PeD)

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

[0253] kBi = ECDH(peD, PeBi)

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

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

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

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

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

Claims

Method for authenticating successive versions of a computer file (DB3 N , DB3 N+1 , DB3 N+2 ) without using a public key infrastructure, from a first version (DB1 N ) of the file whose authenticity is certain or admitted, comprising the steps of:- providing a single source (HSM1a, APRV) of authentication key pairs (pK N -PK N , pK N+1 -PK N+1 , pK N+2 -PK N+2 ), each pair of authentication keys including a private authentication key (pK N , pK N+1 , pK N+2 ) and a public authentication key (PK N , PK N+1 , PK N+2 ),- using the single source of authentication key pairs, generate a first authentication key pair (pK N -PK N ) including a first public authentication key (PK N) and a first private authentication key (pK N ),- form a final version (DB3 N ) of the first version (DB1 N ) of the file, the final version of the first version of the file including the first version (DB1 N ) of the file and at least the first public authentication key (PK N ),- generate or obtain a second version (DB1 N+1 ) of the file,- using the single source of authentication key pairs, generate a second authentication key pair (pK N+1 -PK N+1 ) including a second public authentication key (PK N+1 ) and a second private authentication key (pK N+1 ),- calculate an authentication signature (SIGN N+1 ) of the second version (DB1 N+1 ) of the file using the private authentication key (pK N ) of the first authentication key pair (pK N -PK N) and from a data block (DB2 N+1 ) including at least the second version (DB1 N+1 ) of the file and the second public authentication key (PK N+1 ), and- form a final version (DB3 N+1 ) of the second version (DB1 N+1 ) of the file, the final version including at least the second version (DB1 N+1 ) of the file, the second public authentication key (PK N+1 ) and the authentication signature (SIGN N+1 ) of the second version (DB1 N+1 ) of the file, a process in which two pairs of authentication keys of successive ranks can be identical or different, and including a step of verifying the authenticity of the final version (DB3 N+1 ) of the second version (DB1 N+1 ) of the file in reference to the final version (DB3 N ) of the first version (DB1 N ) of the file, the step of verifying the authenticity of the final version (DB3N+1 ) of the second version (DB1 N+1 ) of the file including the step of verifying the validity of the authentication signature (SIGN N+1 ) of the second version (DB1 N+1 ) of the file using the first public authentication key (PK N ) present in the final version (DB3 N ) of the first version (DB1 N ) of the file and from the data block including at least the second version (DB1 N+1 ) of the file and the second public authentication key (PK N+1), the authenticity verification step being carried out by a machine, a processor or a software entity not knowing any of the private authentication keys associated with the first public authentication key or the second public authentication key, and without verifying the authenticity of the first public authentication key and the second public authentication key by referring to a certification authority.

2. Method according to claim 1, comprising the steps of:- assigning to the second version (DB1 N+1 ) of the file information (VN) allowing it to be distinguished from the first version (DB1 N ) of the file, such as a version number, creation date or other identifying information, and- add information regarding the second version (DB1 N+1 ) from the file to the data block from which the authentication signature (SIGN N+1 ) of the second version (DB1N+1 ) of the file is calculated.

3. The method of claim 2, comprising the step of inserting markers into the data block (DB2 N+1 ) from which the authentication signature (SIGN N+1 ) of the second version (DB1 N+1 ) of the file is calculated, to distinguish the second version (DB1 N+1 ) of the second public authentication key (PK) file N+1 ) and distinguish the second public authentication key (PK N+1 ) information regarding the second version (DB1 N+1 ) of the file.

4. Method according to one of claims 1 to 3, comprising the steps of:- generating or obtaining a third version (DB1 N+2 ) of the file, - using the single source of authentication key pairs, generate a third authentication key pair (pK N+2 -PK N+2 ) including a third public authentication key (PKN+2 ) and a third private authentication key (pK N+2 ),- calculate an authentication signature (SIGN N+2 ) of the third version (DB1 N+2 ) of the file using the private authentication key (pK N+1 ) of the second pair of authentication keys (pK N+1 -PK N+1 ) and from a data block (DB2 N+2 ) including at least the third version (DB1 N+2 ) of the file and the third public authentication key (PK N+2 ), and- form a final version (DB3 N+2 ) of the third version (DB1 N+2 ) of the file, the final version including at least the third version (DB1 N+2 ) of the file, the third public authentication key (PK N+2 ) and the authentication signature (SIGN N+2 ) of the third version (DB1 N+2 ) of the file.

5. Method according to claim 4, comprising a step of verifying the authenticity of the final version (DB3 N+2 ) of the third version (DB1 N+2 ) of the file in reference to the final version (DB3 N+1 ) of the second version (DB1 N+1 ) of the file, the step of verifying the authenticity of the final version (DB3 N+2 ) of the third version (DB1 N+2 ) of the file including the step of verifying the validity of the authentication signature (SIGN N+2 ) of the third version (DB1 N+2 ) of the file using the second public authentication key (PK N+1 ) present in the final version (DB3 N+1 ) of the second version (DB1 N+1 ) of the file and from the data block including at least the third version (DB1 N+2 ) of the file and the third public authentication key (PK N+2 ).

6. Method according to claim 5, in which the step of verifying the authenticity of the final version (DB3 N+2 ) of the third version (DB1 N+2 ) of the file is conducted by a machine, processor or software entity not knowing any of the private authentication keys associated with the second public authentication key or the third public authentication key, and without verifying the authenticity of the second public authentication key and the third public authentication key by referring to a certification authority.

7. Method according to one of claims 4 to 6, comprising the steps of:- assigning to the third version (DB1 N+2 ) of the file information (VN) allowing it to be distinguished from the second (DB1 N+1) of the file, such as a version number, creation date or other identifying information, and- add the information (VN) to distinguish the third version (DB1 N+2 ) of the second version file (DB1 N+1 ) from the file to the data block from which the authentication signature (SIGN N+2 ) of the third version (DB1 N+2 ) of the file is calculated.

8. The method of claim 7, comprising the step of inserting markers into the data block (DB2 N+2 ) from which the authentication signature (SIGN N+2 ) of the third version (DB1 N+2 ) of the file is calculated, to distinguish the third version (DB1 N+2 ) of the third public authentication key (PK) file N+2 ) and distinguish the third public authentication key (PK N+2 ) information regarding the third version (DB1 N+2 ) of the file.

9. Method according to one of claims 1 to 8, in which each version of the file is a version of a document comprising text and / or images.

10. Method according to one of claims 1 to 9, in which each version of the file is a digital or digitized work of art and each version of the file corresponds to a version of the work at different stages of its creation or at different dates of the finalized work.

11. Method according to one of claims 1 to 8, in which each file is a firmware file installed or intended to be installed in a processor (HSMp).

12. The method of claim 11, wherein the authenticity verification step is conducted by a protection module (PM) of the processor, the protection module being configured to prevent the firmware file from being erased and to prevent a non-authentic version of an update of the firmware file from being installed in the processor.

13. Method according to one of claims 11 and 12, comprising the steps of:- concatenating the final version (DB3 N+1 ) of the second version (DB1 N+1 ) of the firmware file with an installation signature (ISIGN N+1 ) generated using an installation private key (IpK N+1 ) and from the final version (DB3 N+1 ) of the second version of the firmware file, and- provide a public installation key (IPK N+1 ) corresponding to the installation private key (IpK N+1 ) to the processor in which the second version (DB1N+1 ) of the firmware file must be installed.

14. Method according to one of claims 11 to 13, in which the final versions of the firmware file are provided to an operator of the processor who does not have access to any private key.

15. Method of manufacturing at least two versions (DB3 N , DB3 N+1 , DB3 N+2 ) of a computer file linked together by an authentication link, comprising the steps of:- providing a single source (HSM1a, APRV) of authentication key pairs (pK N -PK N , pK N+1 -PK N+1 , pK N+2 -PK N+2 ), each pair of authentication keys including a private authentication key (pK N , pK N+1 , pK N+2 ) and a public authentication key (PK N , PK N+1 , PK N+2),- using the single source of authentication key pairs, generate a first authentication key pair (pK N -PK N ) including a first public authentication key (PK N ) and a first private authentication key (pK N ),- generate or obtain a first version (DB1 N ) of the file, - form a final version (DB3 N ) of the first version (DB1 N ) of the file, the final version of the first version of the file including the first version (DB1 N ) of the file and at least the first public authentication key (PK N ),- save the final version (DB3 N ) of the first version (DB1 N ) of the file on a medium, - generate or obtain a second version (DB1 N+1 ) of the file,- using the single source of authentication key pairs, generate a second authentication key pair (pK N+1 -PK N+1) including a second public authentication key (PK N+1 ) and a second private authentication key (pK N+1 ),- calculate an authentication signature (SIGN N+1 ) of the second version (DB1 N+1 ) of the file using the private authentication key (pK N ) of the first authentication key pair (pK N -PK N ) and from a data block (DB2 N+1 ) including at least the second version (DB1 N+1 ) of the file and the second public authentication key (PK N+1 ),- form a final version (DB3 N+1 ) of the second version (DB1 N+1 ) of the file, the final version including at least the second version (DB1 N+1 ) of the file, the second public authentication key (PK N+1 ) and the authentication signature (SIGN N+1 ) of the second version (DB1 N+1 ) of the file, and- save the final version (DB3 N+1) of the second version (DB1 N+1 ) of the file on a medium.

16. Manufacturing method according to claim 15, comprising the steps of:- assigning to the second version (DB1 N+1 ) of the file at least one piece of information (VN) allowing it to be distinguished from the first version (DB1 N ) of the file, and- add the information (VN) concerning the second version (DB1 N+1 ) from the file to the data block from which the authentication signature (SIGN N+1 ) of the second version (DB1 N+1 ) of the file is calculated.

17. Manufacturing method according to one of claims 15 and 16, comprising the steps of:- generating or obtaining a third version (DB1 N+2 ) of the file, - using the single source of authentication key pairs, generate a third authentication key pair (pK N+2 -PK N+2) including a third public authentication key (PK N+2 ) and a third private authentication key (pK N+2 ),- calculate an authentication signature (SIGN N+2 ) of the third version (DB1 N+2 ) of the file using the private authentication key (pK N+1 ) of the second pair of authentication keys (pK N+1 -PK N+1 ) and from a data block (DB2 N+2 ) including at least the third version (DB1 N+2 ) of the file and the third public authentication key (PK N+2 ),- form a final version (DB3 N+2 ) of the third version (DB1 N+2 ) of the file, the final version including at least the third version (DB1 N+2 ) of the file, the third public authentication key (PK N+2 ) and the authentication signature (SIGN N+2 ) of the third version (DB1 N+2 ) of the file, and- save the final version (DB3N+2 ) of the third version (DB1 N+2 ) of the file on a medium.

Images