Method and device for executing firmware file

Abstract

The present invention relates to the field of communication technology, and provides a method and device for executing a firmware file, wherein the method includes: the firmware file includes at least firmware information, first information, the first public key in a first key pair, and second information, and verifies whether the firmware file has been tampered with, specifically including: the host uses the second public key to decrypt the second information to obtain information related to the first public key, matches the information related to the first public key with the first public key, and if the two are consistent, the first round of verification passes; after the first round of verification passes, uses the first public key to decrypt the first information to obtain information related to the firmware information, and matches the information related to the firmware information with the firmware information, and if the two are consistent, the firmware file has not been tampered with, and the firmware file is executed. The present invention carries two layers of authentication information in the firmware file, so that when the firmware file is executed, the firmware file is double-authenticated to verify whether the firmware file has been tampered with, thereby ensuring the normal operation of the communication network.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a method and device for executing a firmware file. Background Art

[0002] In optical transmission rack systems, with the development of data centers, more and more pluggable modules (such as pluggable optical modules using SFP, QSFP, QSFP-DD, OSFP, etc. packages) are used. Due to the pluggable nature of the module, the module may be unplugged and replaced or its firmware may be upgraded. After the module is unplugged, the firmware file therein may be maliciously tampered with to have the function of stealing confidential equipment or destroying communication functions. In the existing technology, the firmware file is usually loaded and executed by the boot program after only a simple CRC integrity check. Under this existing technology, if the firmware file is illegally upgraded or tampered with, the system cannot recognize it and is directly executed by the boot program, which may cause serious security problems in the entire communication network.

[0003] In view of this, overcoming the defects of the prior art is an urgent problem to be solved in this technical field. Summary of the Invention

[0004] The technical problem to be solved by the present invention is that in the prior art, firmware files may be tampered with, and the system directly executing the firmware leads to security problems.

[0005] In a first aspect, the present invention provides a method for executing a firmware file, the execution method comprising: when a boot program detects an external device, reading a firmware file in the external device, and verifying whether the firmware file has been tampered with, wherein the firmware file includes at least firmware information, first information signed by a first private key in a first key pair to the firmware information, a first public key in the first key pair, and second information signed by a second private key in a second key pair to the first public key in the first key pair, and verifying whether the firmware file has been tampered with specifically comprises:

[0006] The host uses the second public key in the second key pair to decrypt the second information to obtain information related to the first public key, and matches the information related to the first public key with the first public key directly carried in the firmware file. If the two are consistent, the first round of verification is passed;

[0007] After the first round of verification is passed, the first public key in the first key pair is used to decrypt the first information to obtain firmware information related information, and the firmware information related information is matched with the firmware information directly carried in the firmware file. If the two are consistent, it is verified that the firmware file has not been tampered with, and the corresponding firmware file is executed.

[0008] Preferably, the first public key related information in the first key is specifically the result of processing the first public key in the first key by a digest algorithm;

[0009] The firmware information related information is specifically the result of processing the firmware information through a digest algorithm.

[0010] Preferably, matching the first public key related information with the first public key directly carried in the firmware file specifically comprises calculating a first public key digest result from the first public key directly carried in the firmware file, and matching the first public key digest result with the first public key related information;

[0011] The matching of the firmware information related information with the firmware information directly carried in the firmware file specifically includes calculating a firmware information summary result for the firmware information directly carried in the firmware file, and matching the firmware information related information with the firmware information summary result.

[0012] Preferably, the external device includes at least one of a pluggable optical module device, an on-chip storage space of a chip, and other pluggable devices suitable for a blade server; wherein the pluggable optical module device also includes at least one of an optical module with SFP package, QSFP package, QSFP-DD package, and OSFP package.

[0013] In a second aspect, the present invention further provides a method for executing a firmware file. Based on the method for executing a firmware file in the first aspect, the method further includes:

[0014] The host authenticates the device certificate and device private key of the external device according to the user certificate to authenticate the external device; wherein the external device is produced by the device manufacturer;

[0015] The storage area of ​​the external device stores a device certificate and a device private key in a device key pair. The generation process of the device certificate is specifically as follows: the device manufacturer obtains a device vendor certificate issued by a consumer user; the device vendor certificate is jointly generated by a first certificate subject and a first certificate signature, the first certificate subject being composed of a device vendor identifier and a device vendor public key in the device vendor key pair, and the first certificate signature being obtained by signing the first certificate subject with the consumer user's user certificate;

[0016] The device manufacturer also obtains the device identification of the external device, and uses the device vendor certificate, the device identification of the external device and the device public key in the device key pair to form a second certificate body, and uses the device vendor private key in the device vendor key pair to issue the second certificate body to obtain a second certificate signature. The device certificate is jointly generated by the second certificate body and the second certificate signature.

[0017] Preferably, the host authenticates the device certificate and device private key of the external device according to the user certificate, specifically including:

[0018] The host obtains the device vendor certificate from the device certificate, obtains the first certificate signature from the device vendor certificate, and verifies the validity of the first certificate signature using the user certificate;

[0019] After verifying the validity of the first certificate signature, obtaining the device manufacturer's public key in the device manufacturer key pair from the device manufacturer certificate, obtaining the second certificate signature from the device certificate, and verifying the validity of the second certificate signature using the device manufacturer's public key;

[0020] After verifying the validity of the signature of the second certificate, the device public key in the device key is obtained from the device certificate, and it is verified whether the device public key matches the device private key in the storage area of ​​the external device. If it is verified that the device public key matches the device private key, the authentication process of the external device is completed.

[0021] Preferably, the verifying whether the device public key matches the device private key in the storage area of ​​the external device specifically includes:

[0022] The host sends the generated random number to the external device, and obtains an encryption result obtained by the external device encrypting the random number according to the device private key;

[0023] The host decrypts the encryption result using the device public key to obtain a decryption result, and determines whether the decryption result is consistent with the random number;

[0024] If the decryption result is consistent with the random number, it is verified that the device public key matches the device private key.

[0025] Preferably, the using the user certificate to verify the validity of the first certificate signature specifically includes:

[0026] The host obtains the first certificate subject in the device vendor certificate, and uses the user certificate to issue the first certificate subject to obtain an issuance result;

[0027] Determine whether the issuance result is consistent with the first certificate signature; if the issuance result is consistent with the first certificate signature, verify that the validity of the first certificate signature is passed.

[0028] In a third aspect, the present invention further provides a method for executing a firmware file. Based on the method for executing a firmware file in the first aspect, the method further includes:

[0029] The host authenticates the device certificate and device private key of the external device according to the user certificate and the device manufacturer certificate to authenticate the external device, wherein the external device is produced by the device manufacturer; wherein the external device is produced by the device manufacturer;

[0030] The device manufacturer's device vendor certificate is issued by the consumer user. Specifically, the device vendor certificate is jointly generated by a first certificate subject and a first certificate signature. The first certificate subject is composed of the device vendor identifier and the device vendor public key in the device vendor key pair. The first certificate signature is issued to the first certificate subject by the consumer user's user certificate.

[0031] Among them, the storage area of ​​the external device stores the device certificate and the device private key in the device key pair. The specific process of generating the device certificate is: the device manufacturer also obtains the device identification of the external device, and uses the device identification of the external device and the device public key in the device key pair to form a second certificate body, and uses the device vendor private key in the device vendor key pair to issue the second certificate body to obtain a second certificate signature, and the second certificate body and the second certificate signature jointly generate a device certificate.

[0032] Preferably, the host authenticates the device certificate and device private key of the external device according to the user certificate and the device vendor certificate, specifically including:

[0033] The host obtains the first certificate signature from the device vendor certificate and verifies the validity of the first certificate signature using the user certificate;

[0034] After verifying the validity of the first certificate signature, obtaining the device manufacturer's public key in the device manufacturer key pair from the device manufacturer certificate, obtaining the second certificate signature from the device certificate, and verifying the validity of the second certificate signature using the device manufacturer's public key;

[0035] After verifying the validity of the signature of the second certificate, the device public key in the device key is obtained from the device certificate, and it is verified whether the device public key matches the device private key in the storage area of ​​the external device. If it is verified that the device public key matches the device private key, the authentication process of the external device is completed.

[0036] Preferably, the verifying whether the device public key matches the device private key in the storage area of ​​the external device specifically includes:

[0037] The host sends the generated random number to the external device, and obtains an encryption result obtained by the external device encrypting the random number according to the device private key;

[0038] The host decrypts the encryption result using the device public key to obtain a decryption result, and determines whether the decryption result is consistent with the random number;

[0039] If the decryption result is consistent with the random number, it is verified that the device public key matches the device private key.

[0040] Preferably, the using the user certificate to verify the validity of the first certificate signature specifically includes:

[0041] The host obtains the first certificate subject in the device vendor certificate, and uses the user certificate to issue the first certificate subject to obtain an issuance result;

[0042] Determine whether the issuance result is consistent with the first certificate signature; if the issuance result is consistent with the first certificate signature, verify that the validity of the first certificate signature is passed.

[0043] In a fourth aspect, the present invention further provides a firmware file execution device, for implementing the firmware file execution method described in any one of the first aspect, the second aspect, or the third aspect, the execution device comprising:

[0044] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the processor to execute the firmware file execution method described in any one of the first aspect, the second aspect, or the third aspect.

[0045] In a fifth aspect, the present invention further provides a non-volatile computer storage medium, wherein the computer storage medium stores computer-executable instructions, which are executed by one or more processors to complete the firmware file execution method described in any one of the first aspect, the second aspect or the third aspect.

[0046] The present invention signs the firmware information and the first public key, so that the firmware file carries two layers of authentication information. Therefore, when the firmware file is executed, the firmware file can be double-authenticated to verify whether the firmware file has been tampered with, thereby ensuring the security of the firmware file finally loaded into the communication network and ensuring the normal operation of the communication network. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. Those skilled in the art can also derive other drawings based on these drawings without inventive effort.

[0048] Figure 1 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0049] Figure 2 This is a schematic diagram of the structure of a firmware file provided by an embodiment of the present invention;

[0050] Figure 3 is a schematic diagram of a method for executing a firmware file provided by an embodiment of the present invention;

[0051] Figure 4 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0052] Figure 5 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0053] Figure 6 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0054] Figure 7 This is a schematic diagram of the structure of a device vendor certificate provided by an embodiment of the present invention;

[0055] Figure 8 This is a schematic diagram of the structure of a device certificate provided by an embodiment of the present invention;

[0056] Figure 9 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0057] Figure 10 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0058] Figure 11 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0059] Figure 12 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0060] Figure 13 This is a schematic diagram of the structure of a firmware certificate provided by an embodiment of the present invention;

[0061] Figure 14 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0062] Figure 15 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0063] Figure 16 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0064] Figure 17 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0065] Figure 18 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0066] Figure 19 This is a flowchart of a method for executing a firmware file provided by an embodiment of the present invention;

[0067] Figure 20 It is a schematic diagram of the architecture of a firmware file execution device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0068] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0069] In the description of the present invention, the terms "inside", "outside", "longitudinal", "lateral", "upper", "lower", "top", "bottom", etc. indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings. They are only for the convenience of describing the present invention and do not require that the present invention must be constructed and operated in a specific orientation. Therefore, they should not be understood as limitations on the present invention.

[0070] In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0071] Embodiment 1:

[0072] Embodiment 1 of the present invention provides a method for executing a firmware file. When a boot program detects an external device, the boot program reads the firmware file in the external device to verify whether the firmware file has been tampered with. The firmware file includes at least firmware information, first information signed by the first private key in the first key pair, the first public key in the first key pair, and second information signed by the second private key in the second key pair. Figure 1 As shown in the figure, verifying whether the firmware file has been tampered with specifically includes:

[0073] In step 201, the host uses the second public key in the second key pair to decrypt the second information to obtain the first public key related information, and matches the first public key related information with the first public key directly carried in the firmware file. If the two are consistent, the first round of verification is passed.

[0074] In step 202, after the first round of verification is passed, the first information is decrypted using the first public key in the first key pair to obtain firmware information related information, and the firmware information related information is matched with the firmware information directly carried in the firmware file. If the two are consistent, it is verified that the firmware file has not been tampered with, and the corresponding firmware file is executed.

[0075] If the first round of verification fails or the firmware information obtained after the first round of verification passes does not match the firmware information directly carried in the firmware file, the firmware file is considered to have been tampered with and the firmware file is suspended without being executed.

[0076] The external device includes at least one of a pluggable optical module device, an on-chip storage space of a chip, and a pluggable device suitable for a blade server; the pluggable optical module device includes at least one of an optical module with SFP package, QSFP package, QSFP-DD package, and OSFP package.

[0077] According to different security requirements for firmware by those skilled in the art, the firmware and the second key pair may have the following three relationships:

[0078] Relationship 1: All firmware share a second key pair.

[0079] Relationship 2: Each version of the firmware shares a second key pair.

[0080] Relationship 3: Generate a unique second key pair for each firmware file.

[0081] The above three relationships are also applicable to the first key pair. In order to ensure the security of the firmware file, there is also a preferred implementation method: the second key pair and the firmware file adopt relationship one or relationship two, and the first key pair and the firmware file adopt relationship three.

[0082] The first public key is directly included in the firmware file, and the second public key is not written into the firmware file. Therefore, before executing the above step 201, the host needs to obtain the second public key. To solve this problem, three optional implementation methods are provided, including:

[0083] Method 1: Write the second public key in the second key pair directly into the host's boot program. This allows the host to perform the first round of verification based on the second public key in the boot program without having to obtain the second public key from elsewhere.

[0084] Method 1 is relatively simple to implement and, since it doesn't involve network transmission, offers higher security. However, since the second public key is directly embedded in the bootloader, replacing it requires updating the host's bootloader, which results in a cumbersome update process. Furthermore, when the firmware files and the second key pair exhibit the relationship described in Relationship 3 above, the number of firmware files directly determines the number of second public keys stored in the host. Consequently, when a large number of firmware files are present, the host's storage resources are significantly occupied by the second public keys.

[0085] Method 2: The second public key is stored in the corresponding remote server, and each firmware corresponds to a first key pair. When the host performs the first round of verification, it reads the version information in the firmware information and obtains the corresponding second key pair from the remote server based on the version information, thereby performing the first round of verification.

[0086] Method 2, because it involves network transmission, poses certain security risks. However, because the second public key is stored on a remote server, it is easier to manage and change. Thus, if the second key pair is cracked by malicious actors, the second public key can be quickly modified to ensure that firmware files signed with the second private key cannot be executed. This prevents the execution of some firmware files and avoids irreparable errors in the entire communication system. If Method 2 is combined with Relationship 2 described above, since each version of firmware shares a second key pair, firmware versions can be managed using the second public key on the server. For example, if the communication system is continuously updated and becomes incompatible with older versions of firmware, the second public key corresponding to the older versions can be deleted from the server to eliminate the older versions of firmware from the market.

[0087] Method 3: The second public key is manually obtained by the user of the external device and imported into the host.

[0088] This method usually involves directly handing over the second public key to the user when selling firmware files or external devices, and the user imports it into the host. Since this method relies on manual labor, it has certain security risks, but it can be combined with the above-mentioned three relationships to increase its security, so that the second public key can be obtained more conveniently.

[0089] The first key pair and the second key pair are generated by an asymmetric encryption algorithm, and the asymmetric encryption algorithm includes one or more of RSA, ECDSA, ECC, AES and SM2.

[0090] This embodiment signs the firmware information and the first public key, so that the firmware file carries two layers of authentication information. Therefore, when the firmware file is executed, the firmware file can be double-authenticated to verify whether the firmware file has been tampered with, thereby ensuring the security of the firmware file ultimately loaded into the communication network and ensuring the normal operation of the communication network.

[0091] In actual use, if the firmware information itself is directly encrypted, the first information may be too large, resulting in a larger firmware file, which requires an external device with a larger storage space, ultimately increasing the manufacturing cost of the external device. On the other hand, it also increases the time required to verify the firmware file. To address this problem, there are also the following preferred implementations, specifically, Figure 2 As shown:

[0092] The first public key related information in the first key is specifically the result of processing the first public key in the first key through a digest algorithm.

[0093] The firmware information related information is specifically the result of processing the firmware information through a digest algorithm.

[0094] Corresponding to the preferred embodiment, when performing firmware file verification, as shown in FIG. Figure 3 As shown, the matching of the first public key related information with the first public key directly carried in the firmware file is specifically as follows: calculating the first public key directly carried in the firmware file to obtain a first public key summary result, and matching the first public key summary result with the first public key related information.

[0095] The matching of the firmware information related information with the firmware information directly carried in the firmware file specifically includes calculating a firmware information summary result for the firmware information directly carried in the firmware file, and matching the firmware information related information with the firmware information summary result.

[0096] The digest algorithm used when matching the first public key related information with the first public key directly carried in the firmware file is the same as the digest algorithm used when generating the first public key related information. The digest algorithm used when matching the firmware information related information with the firmware information directly carried in the firmware file is the same as the digest algorithm used when generating the firmware information related information.

[0097] The digest algorithm includes one or more of the HASH algorithm, MD5 algorithm and SHA-1 algorithm.

[0098] Example 2:

[0099] The present invention is based on the method described in Example 1, combined with specific application scenarios, and uses technical descriptions in related scenarios to illustrate the implementation process of the present invention in characteristic scenarios.

[0100] If there is a pluggable optical module for plugging into the corresponding OLT device, the firmware file in the pluggable optical module includes firmware information, first information, a first public key and second information, specifically, Figure 4 As shown:

[0101] In step 301, when generating the firmware file, two key pairs are pre-generated: key pair A (equivalent to the first key pair in Example 1) and key pair B (equivalent to the second key pair in Example 1). Key pair A is used to sign the firmware information, and key pair B is used to sign the public key in key pair A (equivalent to the first public key in Example 1). Both key pair A and key pair B are generated based on the RSA or ECDSA asymmetric encryption algorithm. The length of the key pair can be 1024, 2048, or longer. The general OpenSSL tool can be used to generate the key pair, with or without encryption.

[0102] In step 302, the firmware information is first hashed using SHA256 to obtain firmware information-related information. The firmware information-related information is then signed using the private key of key pair A to generate the first information. The firmware file now contains two parts: the firmware information and the signature information of the firmware information (equivalent to the first information in Example 1).

[0103] In step 303, further signature is performed, the HASH summary of the public key of key pair A is calculated to obtain the first public key related information, and the first public key related information is signed using the private key of key pair B to obtain the signature file of the public key of key pair A, such as Figure 5 As shown; the firmware file information at this time consists of 4 parts, the signature information of the public key of key pair A (equivalent to the second information in Example 1), the public key of key pair A (equivalent to the first public key in Example 1), the firmware information and the signature information of the firmware information (equivalent to the first information in Example 1).

[0104] When the system loads the firmware file in the pluggable optical module, it will perform signature authentication on the firmware information to verify whether the firmware file has been tampered with. The following is an example of the specific process of verifying the firmware file when the system is powered on. Figure 5 As shown, specifically including:

[0105] In step 401, the boot reads the firmware file in the Flash storage area of ​​the pluggable optical module, obtains the second information therefrom, and then reads the public key of the key pair B (equivalent to the second public key in Example 1) from the boot code, authenticates the second information, that is, uses the public key in the key pair B to decrypt, thereby obtaining the first public key related information S1.

[0106] In step 402, the boot reads the first public key in the Flash, and then uses a digest algorithm to calculate a digest of the first public key to obtain a first public key digest result S2.

[0107] In step 403, the boot compares the values ​​of S1 and S2 to see if they are consistent. If they are inconsistent, it means that the second information has been tampered with, the file is untrustworthy, and the program is suspended without executing subsequent operations. If the values ​​of S1 and S2 are consistent, it means that the second information has not been tampered with, the program completes the first layer of authentication, and the program continues to execute.

[0108] In step 404, the boot reads the first information in the Flash and uses the first public key to authenticate the first information, that is, uses the first public key in the first key pair to decrypt the first information, thereby obtaining firmware information related information S3.

[0109] In step 405, the boot reads the firmware information in the Flash, and then uses a digest algorithm to calculate a digest of the firmware information to obtain a firmware information digest result S4.

[0110] In step 406, the boot process compares the values ​​of S3 and S4 to see if they are consistent. If they are inconsistent, the firmware information has been tampered with and the firmware file is untrustworthy. The program suspends and does not execute subsequent operations. If the comparison results in the values ​​of S3 and S4 being consistent, the firmware file is authentic, the program completes the second layer of authentication, and the program continues to execute subsequent processes, such as loading the firmware information to load the firmware.

[0111] Example 3:

[0112] In actual usage, the firmware file is usually used in conjunction with an external device. If the firmware file is tampered with or the external device is not a valid device, the firmware file may not be executed as expected. In order to solve this problem, the external device is also authenticated. Combined with Example 1, this embodiment also proposes an optimal method for executing the firmware file.

[0113] The method for executing the firmware file is implemented based on the method for executing the firmware file described in Example 1 or Example 2, and before reading the firmware file in the external device, the method further includes:

[0114] The host authenticates the device certificate and the device private key of the external device according to the user certificate to authenticate the external device, wherein the external device is produced by the device manufacturer.

[0115] Wherein, the user certificate is transmitted to the host by the consumer user. And depending on the different external devices, the authentication of the external device can be before the execution of the firmware file, or after the execution of the firmware file. When the reading of the device certificate and the device private key in the external device depends on the firmware, that is, the device certificate and the device private key can be read through the firmware program only after the firmware program is loaded, the firmware file is authenticated first. If it is authenticated that the firmware file has not been tampered with, then after loading the firmware, the external device is authenticated. If it is authenticated that the firmware file has been tampered with, the firmware is not loaded, and the external device is not authenticated. If the authentication shows that the external device is valid, the external device is loaded. Otherwise, if the authentication shows that the external device is invalid, the external device is not loaded.

[0116] When the access to the device certificate and device private key in the external device is independent of the firmware, the authentication of the external device can be performed before or after the firmware file is executed. For example, when the external device is authenticated before the firmware file is executed, if the authentication result indicates that the external device is valid, the firmware file in the external device is read and verified; if the authentication result indicates that the external device is invalid, the firmware file in the external device is not read.

[0117] The storage area of ​​the external device stores a device certificate and a device private key in a device key pair. The generation process of the device certificate is specifically as follows:

[0118] The external device at least involves a device manufacturer, a consumer user and an external device, wherein the external device is produced by the device manufacturer, such as Figure 6 As shown, specifically:

[0119] In step 501, the device manufacturer obtains a device vendor certificate issued by a consumer user; wherein, the device vendor certificate is generated by a first certificate subject and a first certificate signature, wherein the first certificate subject is composed of a device vendor identifier and a device vendor public key in a device vendor key pair, and the first certificate signature is obtained by signing the first certificate subject with the user certificate of the consumer user; the generated device vendor certificate is as follows: Figure 7 shown.

[0120] Among them, the device manufacturer may be one or more, and the device manufacturer identifier may be the manufacturer information of the device manufacturer. The external device may be one or more. The authentication generation process of this embodiment mainly involves three parties, including consumer users, device manufacturers and external devices. One consumer user corresponds to one or more user certificates, and one device manufacturer corresponds to one or more device manufacturer key pairs. The device manufacturer key pair is pre-generated by the device manufacturer using an asymmetric encryption algorithm. There are many asymmetric encryption algorithms, including RSA, ECDSA, ECC, AES and SM2.

[0121] The consumer user generates a user certificate that does not need to be issued or is issued by himself. There are many ways to generate the user certificate, for example:

[0122] The first method uses any custom string as the user certificate.

[0123] In the second method, the consumer user generates a user key pair, uses the user identifier and the user public key in the user key pair to form the certificate body of the user certificate, and uses the user private key in the user key pair to sign the certificate body of the user certificate to obtain a certificate signature. The certificate body and certificate signature of the user certificate together constitute the user certificate.

[0124] The user certificate is the most fundamental basis for verifying the validity of all vendor certificates and device certificates.

[0125] Each device manufacturer is associated with one or more device vendor certificates. The device manufacturer sends its own device vendor identifier and public key (i.e., the first certificate subject) to the consumer user and requests a device vendor certificate from the consumer user. The consumer user verifies the device manufacturer as legitimate based on the device vendor identifier and generates a device vendor certificate. If the device manufacturer is not legitimate, no device vendor certificate is generated.

[0126] The first certificate signature is obtained by signing the first certificate subject using the consumer's user certificate. An optional implementation includes calculating a digest of the first certificate subject and encrypting the calculated digest using the user's private key to obtain the first certificate signature. There are various methods for calculating digests, including MD4, MD5, SHA-1, SHA-256, SHA-384, and SHA-512.

[0127] In step 502, the device manufacturer also obtains the device identification of the external device, and uses the device manufacturer certificate, the device identification of the external device, and the device public key in the device key pair to form a second certificate body, and uses the device manufacturer private key in the device manufacturer key pair to issue the second certificate body to obtain a second certificate signature, and the second certificate body and the second certificate signature jointly generate a device certificate; the generated device certificate is as follows: Figure 8 shown.

[0128] Each external device has a corresponding device certificate, generated by the device manufacturer that manufactures the device. Each external device also has a corresponding device key pair, pre-generated by the device manufacturer. Each device has a unique device identifier, which is obtained by the device manufacturer from the device.

[0129] After the device manufacturer obtains the device identification of the external device, the device manufacturer further verifies whether the external device is a legitimate external device based on the device identification. If it is legitimate, a device certificate is generated; otherwise, no device certificate is generated.

[0130] In step 503, the device certificate and the device private key in the device key pair are burned into the storage area of ​​the external device; the user certificate is transmitted to the host by the consumer user so that the host that installs the external device can complete the authentication process of the external device.

[0131] In this embodiment, the consumer user can be understood as the manager of the device production authentication process, and has absolute authority to manage whether the external device is legal and whether the device manufacturer is legal. For example, the consumer user can be the user, seller or manufacturer of the host, and the consumer user also acts as a principal to entrust the device manufacturer to manufacture external devices that can be used by the host. The device manufacturer's authority to manufacture external devices is controlled by the consumer user. If the consumer user does not provide the device manufacturer with a valid device manufacturer certificate, the device manufacturer cannot generate a valid device certificate, and thus cannot generate a valid device. Or if the consumer user does not transmit a valid user certificate to the host, the external device cannot be effectively authenticated, and the device cannot be installed on the host.

[0132] This embodiment generates a corresponding device certificate for the external device through interaction between the consumer user, the device manufacturer, and the external device. When the external device is inserted into the host, the device certificate can be used to authenticate the external device and identify tampered or illegal external devices, thereby ensuring the legitimacy and security of the external device and the overall security of the communication network.

[0133] Based on the external device in the above embodiment, this embodiment also provides a specific implementation method for how to authenticate the external device, that is, the host computer that installs the external device completes the authentication process of the external device, such as Figure 9 As shown, specifically including:

[0134] In step 601, the host obtains the device vendor certificate from the device certificate, obtains the first certificate signature from the device vendor certificate, and verifies the validity of the first certificate signature using the user certificate.

[0135] In step 602, after verifying the validity of the first certificate signature, the device manufacturer public key in the device manufacturer key pair is obtained from the device manufacturer certificate, and the second certificate signature is obtained from the device certificate, and the validity of the second certificate signature is verified using the device manufacturer public key.

[0136] In step 603, after verifying the validity of the signature of the second certificate, the device public key in the device key is obtained from the device certificate, and it is verified whether the device public key matches the device private key in the storage area of ​​the external device. If it is verified that the device public key matches the device private key, the authentication process of the external device is completed.

[0137] The verification of the validity of the first certificate signature is actually verification of whether the equipment vendor certificate is valid, and the verification of the validity of the second certificate signature is actually verification of whether the equipment certificate is valid.

[0138] The host and the external device match each other. For example, when the external device is a pluggable optical module, the host may be an OLT device.

[0139] Here, an optional implementation method of using a user certificate to verify the validity of the first certificate signature is also provided, such as Figure 10 As shown, specifically including:

[0140] In step 701, the host obtains the first certificate subject in the device vendor certificate, and uses the user certificate to sign the first certificate subject to obtain a signing result.

[0141] In step 702, it is determined whether the issuance result is consistent with the first certificate signature. If the issuance result is consistent with the first certificate signature, the validity of the first certificate signature is verified to be passed.

[0142] In the above-mentioned method 1 for generating the user certificate or the method 2 for generating the user certificate, this embodiment can be applied to the process of authenticating the validity of the signature of the first certificate.

[0143] Here, another optional implementation method is provided for the second method of generating the user certificate, which specifically includes:

[0144] The host obtains the first certificate signature in the device vendor certificate and the user public key in the user certificate, and uses the user public key to decrypt the first certificate signature to obtain a decryption result.

[0145] The host further obtains a first certificate subject in the device vendor certificate, and calculates a digest of the first certificate subject to obtain a digest result.

[0146] Determine whether the digest result is consistent with the decryption result; if so, verify that the validity of the first certificate signature is passed.

[0147] After verifying the validity of the first certificate signature and the second certificate signature, it is necessary to verify the validity of the device key pair. This embodiment provides an optional implementation method, such as Figure 11 As shown, the verification of whether the device public key matches the device private key in the storage area of ​​the external device specifically includes:

[0148] In step 801, the host sends a generated random number to an external device, and obtains an encryption result obtained by the external device encrypting the random number according to the device private key.

[0149] In step 802, the host uses the device public key to decrypt the encryption result to obtain a decryption result, and determines whether the decryption result is consistent with the random number.

[0150] In step 803, if the decryption result is consistent with the random number, it is verified that the device public key matches the device private key.

[0151] Among them, as an optional implementation, in step 801, the host may send the generated random number to the external device or send the hash value of the random number. Correspondingly, in step 802, it is determined whether the decryption result is consistent with the hash value of the random number; in step 803, if the decryption result is consistent with the hash value of the random number, it is verified that the device public key matches the device private key.

[0152] This embodiment ensures the security of the loaded firmware file and the external device through dual authentication of the device and the firmware.

[0153] The "first", "second" and "third" in this embodiment do not have any special limiting meanings. They are used for description only to facilitate the description of different individuals in a category of objects. They should not be interpreted as order or other aspects with special limiting meanings.

[0154] Embodiment 4:

[0155] Compared to the implementation method of directly placing the device vendor certificate into the device certificate in Example 3, this embodiment also provides another implementation method, that is, the device vendor certificate is not placed into the device certificate, but the consumer user transmits the device vendor certificate to the host.

[0156] The host authenticates the device certificate and the device private key of the external device according to the user certificate and the device manufacturer certificate to authenticate the external device, wherein the external device is produced by the device manufacturer.

[0157] The user certificate and the device vendor certificate are transmitted to the host by the consumer user.

[0158] The external device at least involves a device manufacturer, a consumer user and an external device, wherein the external device is produced by the device manufacturer, such as Figure 12 As shown, specifically including:

[0159] In step 901, the device manufacturer obtains a device vendor certificate issued by a consumer user; wherein, the device vendor certificate is jointly generated by a first certificate subject and a first certificate signature, the first certificate subject is composed of a device vendor identifier and a device vendor public key in a device vendor key pair, and the first certificate signature is obtained by issuing the first certificate subject with the user certificate of the consumer user.

[0160] In step 902, the device manufacturer also obtains the device identification of the external device, and uses the device identification of the external device and the device public key in the device key pair to form a second certificate subject, and uses the device manufacturer private key in the device manufacturer key pair to issue the second certificate subject to obtain a second certificate signature, and the second certificate subject and the second certificate signature jointly generate a device certificate; the generated device certificate is as follows: Figure 13 shown.

[0161] In step 903, the device private key in the device certificate and device key pair is burned into the storage area of ​​the external device; the user certificate and device vendor certificate are transmitted to the host by the consumer user so that the host that installs the external device can complete the authentication process of the external device.

[0162] The process of generating the device vendor certificate and the user certificate is based on the same concept as in Example 1 and will not be described in detail here.

[0163] However, what is different from Example 1 is that when generating a device certificate, this embodiment uses the device public key and device identification as the second certificate subject, and does not place the device vendor certificate in it. The device vendor's private key is then used to sign the second certificate subject to obtain a second certificate signature, thereby generating a device certificate.

[0164] At the same time, the device vendor certificate is transmitted from the consumer user to the host, which brings about a different authentication process.

[0165] The host computer that is installed with the external device completes the authentication process of the external device, such as Figure 14 As shown, specifically including:

[0166] In step 1001, the host obtains a first certificate signature from the device vendor certificate and uses a user certificate to verify the validity of the first certificate signature.

[0167] In step 1002, after verifying the validity of the first certificate signature, the device manufacturer public key in the device manufacturer key pair is obtained from the device manufacturer certificate, and the second certificate signature is obtained from the device certificate, and the validity of the second certificate signature is verified using the device manufacturer public key.

[0168] In step 1003, after verifying the validity of the signature of the second certificate, the device public key in the device key is obtained from the device certificate, and it is verified whether the device public key matches the device private key in the storage area of ​​the external device. If it is verified that the device public key matches the device private key, the authentication process of the external device is completed.

[0169] During authentication, since the device vendor certificate has been transmitted to the host by the consumer user in advance, the first certificate signature can be directly extracted from the device vendor certificate for subsequent authentication.

[0170] Verifying whether the device public key matches the device private key in the storage area of ​​the external device specifically includes:

[0171] The host sends the generated random number to the external device, and obtains an encryption result obtained by the external device encrypting the random number according to the device private key.

[0172] The host decrypts the encryption result using the device public key to obtain a decryption result, and determines whether the decryption result is consistent with the random number.

[0173] If the decryption result is consistent with the random number, it is verified that the device public key matches the device private key.

[0174] Among them, as an optional implementation, the host may send the generated random number to the external device or send the hash value of the random number. Correspondingly, when performing authentication, it is determined whether the decryption result is consistent with the hash value of the random number; if the decryption result is consistent with the hash value of the random number, it is verified that the device public key matches the device private key.

[0175] This embodiment provides an optional implementation method for verifying the validity of the first certificate signature, that is, using the user certificate to verify the validity of the first certificate signature, specifically including:

[0176] The host obtains the first certificate subject in the device vendor certificate, and uses the user certificate to sign the first certificate subject to obtain a signing result.

[0177] Determine whether the issuance result is consistent with the first certificate signature; if the issuance result is consistent with the first certificate signature, verify that the validity of the first certificate signature is passed.

[0178] Depending on the external device, the authentication of the external device can be performed before or after the execution of the firmware file. When the reading of the device certificate and the device private key in the external device depends on the firmware, that is, the device certificate and the device private key can be read through the firmware program only after the firmware program is loaded, the firmware file is first authenticated. If the firmware file is authenticated to be untampered with, the external device is authenticated after the firmware is loaded. If the firmware file is authenticated to be tampered with, the firmware is not loaded and the external device is not authenticated. If the external device is authenticated to be valid, the external device is loaded. Otherwise, if the external device is authenticated to be invalid, the external device is not loaded.

[0179] When the access to the device certificate and device private key in the external device is independent of the firmware, the authentication of the external device can be performed before or after the firmware file is executed. For example, when the external device is authenticated before the firmware file is executed, if the authentication indicates that the external device is valid, the firmware file is executed; if the authentication indicates that the external device is invalid, the firmware file is not executed. This ensures the security of the ultimately loaded firmware file and the external device through dual authentication of the device and the firmware. The method for executing the firmware file has been described in detail in Examples 1 and 2 and will not be repeated here.

[0180] In this embodiment, the device vendor certificate is not placed in the device certificate. Instead, the consumer user transmits the device vendor certificate to the host. Compared with Example 1, this embodiment is more suitable for scenarios where the transmission of the device vendor certificate between the consumer user and the host is completely secure. For example, when the consumer user is the manufacturer of the host, there is no need to place the device vendor certificate in the device certificate. Instead, the device vendor certificate is directly transmitted to the host. This simplifies the authentication generation process while ensuring the security of the authentication generation process.

[0181] Example 5:

[0182] The present invention is based on the methods described in Example 3 and Example 4, combined with specific application scenarios, and uses technical descriptions in related scenarios to illustrate the implementation process of the present invention in the characteristic scenarios.

[0183] Taking Example 3 as an example, if there is a pluggable optical module, this pluggable optical module is manufactured by equipment manufacturer V and is used to be inserted into the corresponding OLT device, and a firmware file is stored in the pluggable optical module, and the OLT device is manufactured by consumer user C, then in this scenario, the external device is the pluggable optical module and the host is the OLT device.

[0184] The authentication generation method in the pluggable optical module is as follows Figure 15 As shown, specifically including:

[0185] In step 1101, the device manufacturer V generates a device vendor key pair, including a device vendor public key V_Key_Pubic and a device vendor private key V_Key_Private.

[0186] In step 1102, the device manufacturer V sends the device manufacturer public key V_Key_Public and manufacturer information (equivalent to the device manufacturer identifier in Example 3) to the consumer user C to request a device manufacturer certificate.

[0187] In step 1103, the consumer user C generates an unissued device vendor certificate for the device manufacturer V, which includes the device vendor public key and manufacturer information, and uses the user certificate to issue the device vendor certificate Cert_V.

[0188] In step 1104 , the consumer user C sends the device vendor certificate Cert_V to the device manufacturer V.

[0189] In step 1105 , the device manufacturer V generates a device key pair for each pluggable optical module, including a device public key Dev_Key_Pubic and a device private key Dev_Key_Private.

[0190] In step 1106, the device manufacturer V generates an unsigned device certificate for each pluggable optical module, which includes the device's unique security identifier (equivalent to the device identifier in Example 3), the device public key Dev_Key_Public, and the generated device vendor certificate Cert_V; and uses the device vendor's private key to sign it to obtain the issued device certificate Cert_Dev.

[0191] In step 1107, the device manufacturer V writes the device private key Dev_Key_Private and the device certificate Cert_Dev into the device security storage area of ​​the external device, such as into the read-only memory ROM, and performs the authentication process of the pluggable optical module when the pluggable optical module is plugged in.

[0192] At the same time, consumer C transmits the user certificate to the OLT device for authentication of the pluggable optical module.

[0193] When the pluggable optical module is inserted into the OLT device, the OLT device reads the firmware file from the pluggable optical module and verifies whether the firmware file has been tampered with. The specific implementation of reading the firmware file and verifying whether the firmware file has been tampered with has been described in detail in Example 1 and Example 2 and will not be repeated here.

[0194] If the firmware file has not been tampered with, the firmware is loaded according to the firmware information, the firmware program is started, and the pluggable optical module is authenticated using the firmware program. If the firmware is tampered with, the firmware is not loaded and the pluggable optical module is refused to be loaded.

[0195] The pluggable optical module certification, such as Figure 16 As shown, specifically including:

[0196] In step 1201 , when a pluggable optical module is inserted into an OLT device, the OLT device obtains a device certificate Cert_Dev from the pluggable optical module.

[0197] In step 1202, the OLT device extracts the device vendor certificate from the device certificate Cert_Dev and uses the user certificate to verify the validity of the device vendor certificate; if the verification is valid, the device vendor public key in the device vendor certificate is used to verify the validity of the device certificate; if the device vendor certificate is invalid or the device certificate is invalid, the device is determined to be an illegal device, the process ends, and the OLT device does not load the pluggable optical module; if the device vendor certificate and the device certificate are both valid, the device public key Dev_Key_Public is extracted from the device certificate.

[0198] In step 1203, the OLT device generates a random number Rand and sends the random number Rand to the pluggable optical module.

[0199] In step 1204 , the pluggable optical module encrypts Rand using the device private key Dev_Key_Private, and sends the encryption result Rand_sign to the OLT device.

[0200] In step 1205, the OLT device decrypts Rand_sign with Dev_Key_Public to obtain Rand_a; and compares Rand and Rand_a to see if they are equal. If they are equal, the pluggable optical module is determined to be a legal device and the pluggable optical module is accepted for loading. Otherwise, the pluggable optical module is determined to be an illegal device and the pluggable optical module is refused to be loaded.

[0201] Based on Example 4, also taking the pluggable optical module as an example, Figure 17 As shown, the authentication production method in the pluggable optical module also executes the above steps 1101 to 1105 , then proceeds to step 1106 ′, and then executes step 1107 .

[0202] In step 1106', the device manufacturer V generates an unsigned device certificate for each pluggable optical module, which includes the device's unique security identifier (equivalent to the device identifier in Example 3) and the device public key Dev_Key_Public; and uses the device manufacturer's private key to sign it to obtain the signed device certificate Cert_Dev.

[0203] At the same time, consumer C transmits the user certificate and equipment vendor certificate to the OLT device for authentication of the pluggable optical module. Figure 18 As shown, execute the above step 1201, then execute step 1202', and then execute steps 1203-1205.

[0204] In step 1202', the OLT device uses the user certificate to verify the validity of the device vendor certificate based on the device vendor certificate stored in its own storage; if the verification is valid, the device vendor public key in the device vendor certificate is used to verify the validity of the device certificate; if the device vendor certificate is invalid or the device certificate is invalid, the device is determined to be an illegal device, the process ends, and the OLT device does not load the pluggable optical module; if the device vendor certificate and the device certificate are both valid, the device public key Dev_Key_Public is extracted from the device certificate, and subsequent authentication continues.

[0205] Example 6:

[0206] Based on Examples 1 to 5, this embodiment further integrates Example 1 with Example 3 or Example 4, that is, the device vendor key pair is reused and used as the second key pair of the firmware file. The execution method of the firmware file thus formed specifically includes:

[0207] When the boot program detects an external device, it reads the firmware file in the external device and verifies whether the firmware file has been tampered with. The firmware file at least includes firmware information, first information signed by the first private key in the first key pair, the first public key in the first key pair, and second information signed by the device vendor private key in the device vendor key pair. Figure 19 As shown in the figure, verifying whether the firmware file has been tampered with specifically includes:

[0208] Before verifying whether the firmware file has been tampered with, verify the validity of the external device. If the external device is verified to be legal, retrieve the device vendor public key from the device vendor certificate. When implemented based on Example 3, the device vendor certificate is included in the device certificate, and the device certificate is stored in the storage area of ​​the external device. The device vendor certificate is read from the device certificate when authenticating the external device.

[0209] When implemented based on Example 4, the device vendor certificate is transmitted to the host by the consumer user, so the device vendor certificate can be directly read by the host.

[0210] In step 1301, the host uses the device vendor's public key to decrypt the second information to obtain information related to the first public key, and matches the first public key related information with the first public key directly carried in the firmware file. If the two are consistent, the first round of verification is passed.

[0211] In step 1302, after the first round of verification is passed, the first public key in the first key pair is used to decrypt the first information to obtain firmware information related information, and the firmware information related information is matched with the firmware information directly carried in the firmware file. If the two are consistent, it is verified that the firmware file has not been tampered with, and the corresponding firmware file is executed.

[0212] This embodiment reuses the device vendor key pair to make the connection between the external device and the firmware file closer, so that the firmware file not placed in the external device cannot be effectively verified, thereby ensuring the security of firmware file reading.

[0213] In actual use, since the firmware file is placed in the external device, when in use, the host loads the firmware information as the software part, and uses the hardware part of the external device at the same time. The software part and the hardware part work together to implement the firmware function. However, with the iterative update of the external device and the firmware file, some versions of the firmware file may be incompatible with some old external devices. In order to solve this problem, as a further preferred implementation method, the relationship 2 in Example 1 is combined with this embodiment. The relationship 2 is that each version of the firmware shares a second key pair. In this embodiment, it is expressed as follows:

[0214] The equipment manufacturer generates multiple pairs of equipment manufacturer key pairs based on the firmware file versions required by the external devices to be produced. Each pair of equipment manufacturer key pairs corresponds to a version of the firmware file. The corresponding equipment manufacturer key pairs are used to request equipment manufacturer certificates, so that each version of the firmware file corresponds to a unique equipment manufacturer certificate.

[0215] After the device vendor certificate is generated, the authentication generation process of the external device is kept independent of the firmware file generation process. That is, the external device uses the device vendor private key in the corresponding device vendor key pair to issue the second certificate subject according to the required firmware file version to obtain the second certificate signature, and the second certificate subject and the second certificate signature jointly generate the device certificate.

[0216] The first public key in the first key pair is signed using the device vendor private key in the device vendor key pair corresponding to the version information of the firmware information to obtain the second information, generate the corresponding firmware file, and write the firmware file into the external device.

[0217] For example, there is an external device P, the required firmware version is v1, and the corresponding device vendor key pair is A. The external device is produced using the device vendor key pair A, that is, the device certificate in the external device is issued by the private key of the device vendor key pair A. When authenticating it, the public key of the device vendor key pair A is required.

[0218] There is a firmware information V with version v2, and the corresponding device vendor key pair is B. The firmware file is generated using the device vendor key pair B, that is, the second information in the firmware file is signed by the private key of the device vendor key pair B. When authenticating it, the public key of the device vendor key pair B is required.

[0219] If the firmware information V is mistakenly written into the external device P during the generation process, then if both the firmware information V and the external device P need to be authenticated, at least the public key of the device vendor key pair A and the public key of the device vendor key pair B are required. However, the same device vendor certificate is used when authenticating the firmware file and the external device. Therefore, there is only one device vendor public key, which cannot meet the authentication validity pass conditions of the firmware file and the external device at the same time. This can prevent the incorrect version of the firmware file from being executed and loaded, thereby ensuring the normal operation of network communication.

[0220] Example 7:

[0221] like Figure 20 FIG. 1 is a schematic diagram of the architecture of the execution device of the firmware file according to an embodiment of the present invention. The execution device of the firmware file according to this embodiment includes one or more processors 21 and a memory 22. Figure 20 A processor 21 is taken as an example.

[0222] The processor 21 and the memory 22 may be connected via a bus or other means. Figure 20 The bus connection is taken as an example.

[0223] The memory 22 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs and non-volatile computer executable programs, such as the firmware file execution method in Example 1. The processor 21 executes the firmware file execution method by running the non-volatile software programs and instructions stored in the memory 22.

[0224] The memory 22 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state memory device. In some embodiments, the memory 22 may optionally include a memory remotely located relative to the processor 21, and such remote memory may be connected to the processor 21 via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0225] The program instructions / modules are stored in the memory 22, and when executed by the one or more processors 21, the execution method of the firmware file in the above embodiment 1 is executed, for example, the execution method described above is executed. Figure 1 、 Figure 4-Figure 6 、 Figures 9-12 as well as Figures 14-19 The steps shown.

[0226] It is worth noting that the information interaction, execution process, etc. between the modules and units within the above-mentioned devices and systems are based on the same concept as the processing method embodiment of the present invention. The specific content can be found in the description of the method embodiment of the present invention and will not be repeated here.

[0227] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a disk or an optical disk, etc.

[0228] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for executing a firmware file, characterized in that: The execution method includes: When the boot program detects an external device, the boot program reads a firmware file in the external device to verify whether the firmware file has been tampered with, wherein the firmware file includes at least firmware information, first information signed by a first private key in a first key pair to the firmware information, a first public key in the first key pair, and second information signed by a second private key in a second key pair to the first public key in the first key pair. Verifying whether the firmware file has been tampered with specifically includes: The host uses the second public key in the second key pair to decrypt the second information to obtain information related to the first public key, and matches the information related to the first public key with the first public key directly carried in the firmware file. If the two are consistent, the first round of verification is passed; After the first round of verification passes, the first information is decrypted using the first public key in the first key pair to obtain firmware information related information, and the firmware information related information is matched with the firmware information directly carried in the firmware file. If the two are consistent, it is verified that the firmware file has not been tampered with, and the corresponding firmware file is executed; The execution method further includes: The host authenticates the device certificate and the device private key of the external device according to the user certificate to authenticate the external device, wherein the external device is manufactured by a device manufacturer; The storage area of ​​the external device stores a device certificate and a device private key in a device key pair. The generation process of the device certificate is specifically as follows: the device manufacturer obtains a device vendor certificate issued by a consumer user; the device vendor certificate is jointly generated by a first certificate subject and a first certificate signature, the first certificate subject being composed of a device vendor identifier and a device vendor public key in the device vendor key pair, and the first certificate signature being obtained by signing the first certificate subject with the consumer user's user certificate; The device manufacturer also obtains the device identification of the external device, and uses the device vendor certificate, the device identification of the external device and the device public key in the device key pair to form a second certificate body, and uses the device vendor private key in the device vendor key pair to issue the second certificate body to obtain a second certificate signature. The device certificate is jointly generated by the second certificate body and the second certificate signature.

2. The method for executing a firmware file according to claim 1, wherein: The first public key related information in the first key is specifically the result of processing the first public key in the first key with a digest algorithm; The firmware information related information is specifically the result of processing the firmware information through a digest algorithm.

3. The method for executing a firmware file according to claim 2, wherein: Matching the first public key related information with the first public key directly carried in the firmware file specifically includes calculating a first public key digest result from the first public key directly carried in the firmware file, and matching the first public key digest result with the first public key related information; The matching of the firmware information related information with the firmware information directly carried in the firmware file specifically includes calculating a firmware information summary result for the firmware information directly carried in the firmware file, and matching the firmware information related information with the firmware information summary result.

4. The method for executing a firmware file according to any one of claims 1 to 3, wherein: The external device includes at least one of a pluggable optical module device, an on-chip storage space of a chip, and other pluggable devices suitable for a blade server; wherein the pluggable optical module device also includes at least one of an optical module with SFP package, QSFP package, QSFP-DD package, and OSFP package.

5. The method for executing a firmware file according to claim 1, wherein: The host authenticates the device certificate and device private key of the external device according to the user certificate, specifically including: The host obtains the device vendor certificate from the device certificate, obtains the first certificate signature from the device vendor certificate, and verifies the validity of the first certificate signature using the user certificate; After verifying the validity of the first certificate signature, obtaining the device manufacturer's public key in the device manufacturer key pair from the device manufacturer certificate, obtaining the second certificate signature from the device certificate, and verifying the validity of the second certificate signature using the device manufacturer's public key; After verifying the validity of the signature of the second certificate, the device public key in the device key is obtained from the device certificate, and it is verified whether the device public key matches the device private key in the storage area of ​​the external device. If it is verified that the device public key matches the device private key, the authentication process of the external device is completed.

6. The method for executing a firmware file according to claim 5, wherein: Verifying whether the device public key matches the device private key in the storage area of ​​the external device specifically includes: The host sends the generated random number to the external device, and obtains an encryption result obtained by the external device encrypting the random number according to the device private key; The host uses the device public key to decrypt the encryption result to obtain a decryption result, and determines whether the decryption result is consistent with the random number; if the decryption result is consistent with the random number, it is verified that the device public key matches the device private key.

7. The method for executing a firmware file according to claim 5, wherein: The using the user certificate to verify the validity of the first certificate signature specifically includes: The host obtains the first certificate subject in the device vendor certificate, and uses the user certificate to issue the first certificate subject to obtain an issuance result; Determine whether the issuance result is consistent with the first certificate signature; if the issuance result is consistent with the first certificate signature, verify that the validity of the first certificate signature is passed.

8. A method for executing a firmware file, characterized in that: The execution method includes: When the boot program detects an external device, the boot program reads a firmware file in the external device to verify whether the firmware file has been tampered with, wherein the firmware file includes at least firmware information, first information signed by a first private key in a first key pair to the firmware information, a first public key in the first key pair, and second information signed by a second private key in a second key pair to the first public key in the first key pair. Verifying whether the firmware file has been tampered with specifically includes: The host uses the second public key in the second key pair to decrypt the second information to obtain information related to the first public key, and matches the information related to the first public key with the first public key directly carried in the firmware file. If the two are consistent, the first round of verification is passed; After the first round of verification passes, the first information is decrypted using the first public key in the first key pair to obtain firmware information related information, and the firmware information related information is matched with the firmware information directly carried in the firmware file. If the two are consistent, it is verified that the firmware file has not been tampered with, and the corresponding firmware file is executed; The execution method further includes: The host authenticates the device certificate and device private key of the external device according to the user certificate and the device manufacturer certificate to authenticate the external device, wherein the external device is produced by the device manufacturer; The device manufacturer's device vendor certificate is issued by the consumer user. Specifically, the device vendor certificate is jointly generated by a first certificate subject and a first certificate signature. The first certificate subject is composed of the device vendor identifier and the device vendor public key in the device vendor key pair. The first certificate signature is issued to the first certificate subject by the consumer user's user certificate. Among them, the storage area of ​​the external device stores the device certificate and the device private key in the device key pair. The specific process of generating the device certificate is: the device manufacturer also obtains the device identification of the external device, and uses the device identification of the external device and the device public key in the device key pair to form a second certificate body, and uses the device vendor private key in the device vendor key pair to issue the second certificate body to obtain a second certificate signature, and the second certificate body and the second certificate signature jointly generate a device certificate.

9. The method for executing a firmware file according to claim 8, wherein: The host authenticates the device certificate and device private key of the external device based on the user certificate and the device vendor certificate, specifically including: The host obtains the first certificate signature from the device vendor certificate and verifies the validity of the first certificate signature using the user certificate; After verifying the validity of the first certificate signature, obtaining the device manufacturer's public key in the device manufacturer key pair from the device manufacturer certificate, obtaining the second certificate signature from the device certificate, and verifying the validity of the second certificate signature using the device manufacturer's public key; After verifying the validity of the signature of the second certificate, the device public key in the device key is obtained from the device certificate, and it is verified whether the device public key matches the device private key in the storage area of ​​the external device. If it is verified that the device public key matches the device private key, the authentication process of the external device is completed.

10. The method for executing a firmware file according to claim 9, wherein: Verifying whether the device public key matches the device private key in the storage area of ​​the external device specifically includes: The host sends the generated random number to the external device, and obtains an encryption result obtained by the external device encrypting the random number according to the device private key; The host decrypts the encryption result using the device public key to obtain a decryption result, and determines whether the decryption result is consistent with the random number; If the decryption result is consistent with the random number, it is verified that the device public key matches the device private key.

11. The method for executing a firmware file according to claim 9, wherein: The using the user certificate to verify the validity of the first certificate signature specifically includes: The host obtains the first certificate subject in the device vendor certificate, and uses the user certificate to issue the first certificate subject to obtain an issuance result; Determine whether the issuance result is consistent with the first certificate signature; if the issuance result is consistent with the first certificate signature, verify that the validity of the first certificate signature is passed.

12. A device for executing a firmware file, characterized in that: The execution device includes: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor to execute the method for executing a firmware file according to any one of claims 1-11.

Images