CN120710691A

CN120710691A - A secure startup method for network equipment and network equipment

Info

Publication number: CN120710691A
Application number: CN202410362562.4A
Authority: CN
Inventors: 乔立忠; 张小虎; 章庆隆; 唐甜; 陈艳; 陈诗平
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2024-03-26
Filing date: 2024-03-26
Publication date: 2025-09-26

Abstract

A safe starting method of network equipment is applied to improving the safety of the safe starting process of the network equipment. In the method for safely starting the network equipment, the plaintext code of the starting firmware is encrypted by adopting a symmetric cryptographic algorithm in advance, and the length of a secret key used for encryption is not smaller than a certain threshold value, so that the ciphertext code of the starting firmware needs to be decrypted by adopting the same secret key in the process of safely starting the network equipment, and the plaintext code of the starting firmware can be obtained. The key of the symmetric cryptographic algorithm can have quantum computation resistance under the condition that the length reaches a certain threshold value, so that the process of decrypting the starting firmware by adopting the symmetric cryptographic algorithm is added in the safe starting process of the network equipment, the quantum computation resistance in the safe starting process of the network equipment can be ensured, and the safety of the network equipment is further improved.

Description

Safe starting method of network equipment and network equipment

Technical Field

The present application relates to the field of computer security technologies, and in particular, to a method for securely starting a network device and a network device.

Background

In the process of secure start-up of the network device, the secure boot code in the chip of the network device is usually executed, the code of the next stage is loaded and checked by the code of the previous stage, and after the check is successful, the execution of the code of the next stage is skipped until the system on the chip is started up successfully. In this way, during the start-up process of the network device, the code that is checked and executed in turn can form a trusted chain. Because the code of the next stage in the trusted chain is executed after the code of the previous stage is successfully checked, the starting mode based on the trusted chain can ensure the safety of the whole starting process of the network equipment.

Currently, in the secure start-up process of a network device, a preceding-stage code in a trusted chain usually adopts a digital signature verification mode to verify a following-stage code so as to ensure the integrity and authenticity of the following-stage code. The digital signature verification mode is realized based on a traditional public key cryptographic algorithm. With the rapid development of quantum computing technology, the traditional public key cryptographic algorithm cannot realize quantum computing resistance, so that the security of a digital signature verification mode based on the public key cryptographic algorithm is greatly threatened, and a large potential safety hazard exists in the starting process of network equipment.

However, the post quantum cryptography algorithm with quantum resistance calculation is still in the development stage at present, and has not been formally put into commercial use. Moreover, because the life cycle of the network device is long (usually 10 years to 20 years), most of the network devices produced in the early stage have no pre-buried post-quantum cryptography algorithm capability, so that most of the network devices already put into use cannot practically apply the post-quantum cryptography algorithm. Therefore, how to improve the security of network devices without the capability of post quantum cryptography algorithms is a problem to be solved.

Disclosure of Invention

The application provides a safe starting method of network equipment, which can ensure that the safe starting process of the network equipment has quantum computation resistance and improve the safety of the network equipment.

The first aspect of the present application provides a method for safely starting a network device, which is applied to improving the safety of a safe starting process of the network device. The method for safely starting the network equipment specifically comprises the following steps that firstly, a first starting firmware obtains a ciphertext code and a first secret key of a second starting firmware, the first starting firmware and the second starting firmware are both the firmware to be started in the safe starting process of the network equipment, and the first starting firmware is started before the second starting firmware. That is, the first boot firmware can be the first boot firmware in any stage of the secure boot process of the network device, and the second boot firmware is the second boot firmware. The first key is a key generated based on a symmetric cryptographic algorithm and can be used as a decryption key in the symmetric cryptographic algorithm. And the length of the first key is not less than a preset threshold.

Then, the first starting firmware adopts the first key to decrypt the ciphertext code to obtain a plaintext code of the second starting firmware. The ciphertext code of the second starting firmware is obtained by encrypting the plaintext code of the second starting firmware by adopting the same key as the first key. Therefore, the first starting firmware adopts the first key to decrypt the ciphertext code of the second starting firmware based on the symmetric cryptographic algorithm, and then the plaintext code of the second starting firmware can be obtained.

Finally, based on the decrypted plaintext code of the second boot firmware, the first boot firmware triggers the jump to execute the second boot firmware.

In the scheme, the plaintext code of the starting firmware is encrypted by adopting a symmetric cryptographic algorithm in advance, and the length of a key used for encryption is not smaller than a certain threshold, so that the ciphertext code of the starting firmware needs to be decrypted by adopting the same key in the safe starting process of the network equipment, and the plaintext code of the starting firmware can be obtained. The key of the symmetric cryptographic algorithm can have quantum computation resistance under the condition that the length reaches a certain threshold value, so that the process of decrypting the starting firmware by adopting the symmetric cryptographic algorithm is added in the safe starting process of the network equipment, the quantum computation resistance in the safe starting process of the network equipment can be ensured, and the safety of the network equipment is further improved.

In one possible implementation, before executing the second boot firmware, the first boot firmware further performs an integrity check on the ciphertext code of the second boot firmware or the plaintext code of the second boot firmware to ensure the integrity of the second boot firmware. By encrypting the second starting firmware by adopting a symmetric cryptographic algorithm and combining the integrity verification process of the second starting firmware, the authenticity and the integrity of the second starting firmware can be effectively ensured, and the security of the network security starting process is further improved.

In one possible implementation, the manner in which the first boot firmware performs the integrity check on the ciphertext code of the second boot firmware or the plaintext code of the second boot firmware includes a digital signature check manner or a hash value check manner.

In one possible implementation, when the first boot firmware performs the integrity check on the plaintext code of the second boot firmware, the first boot firmware obtains a first digital signature or a first hash value, and the first digital signature or the first hash value is stored in a storage medium of the network device. The first digital signature or the first hash value is obtained by calculating a plaintext code of the second starting firmware in advance. Typically, the first digital signature or first hash value is stored in the network device in combination with the ciphertext code of the second boot firmware.

After the first starting firmware decrypts to obtain the plaintext code of the second starting firmware, the first starting firmware executes the integrity check on the plaintext code of the second starting firmware by adopting the first digital signature or the first hash value, and triggers the execution of the second starting firmware when the plaintext code of the second starting firmware passes the integrity check.

In one possible implementation, when the first boot firmware performs the integrity check on the ciphertext code of the second boot firmware, the first boot firmware obtains a second digital signature or a second hash value, which is stored in a storage medium of the network device. The second digital signature or the second hash value is obtained by calculating a ciphertext code of the second starting firmware in advance. And the first digital signature or the first hash value is stored in the network device in combination with the ciphertext code of the second boot firmware.

After the first starting firmware obtains the ciphertext code of the second starting firmware, the first starting firmware executes integrity check on the ciphertext code of the second starting firmware by adopting a second digital signature or a second hash value, and triggers decryption on the ciphertext code of the second starting firmware when the ciphertext code of the second starting firmware passes the integrity check.

In one possible implementation, the symmetric cryptographic algorithm used to decrypt the ciphertext code of the second boot firmware comprises an advanced encryption standard (Advanced Encryption Standard, AES) algorithm. And, the preset threshold is 256, that is, the length of the first key is not less than 256.

In one possible implementation, the first key is derived from a root key that is stored in a one-time programmable memory (eFuse) of the network device. The security of the root key can be effectively ensured by storing the root key in the eFuses, and the first key is derived based on the root key, so that the security of the first key can be ensured, and meanwhile, the storage resource overhead caused by independently storing the first key is avoided.

In one possible implementation, a flag bit is stored in a chip of the network device, where the flag bit is used to indicate that the ciphertext code of the second boot firmware needs to be decrypted during the secure boot process. For example, eFuses are provided on a chip of the network device, and a 1-bit (bit) flag bit is provided in the eFuses, and when the value of the flag bit is 1, it represents that the ciphertext code of the second boot firmware needs to be decrypted. In this way, based on the flag bit stored in the chip of the network device, the first boot firmware determines that the second boot firmware needs to be decrypted during the secure boot process, thereby triggering a subsequent decryption process.

In one possible implementation, the first boot firmware is an on-chip secure boot code and the second boot firmware is an off-chip secure boot code. Or the first starting firmware is a first-level security boot code outside the chip, and the second starting firmware is a second-level security boot code outside the chip. Or, the first boot firmware is an external security boot code of the chip, and the second boot firmware is a basic input output system (Basic Input Output System, BIOS).

In one possible implementation, the first boot firmware and the second boot firmware are executed on different systems on Chip (SoC). After the first boot firmware is executed on one SoC and decryption and integrity verification of the second boot firmware are completed, the second boot firmware is executed on the other SoC.

The second aspect of the application provides a processing method of starting firmware, which comprises the steps of obtaining a plaintext code and a first key of a second starting firmware, wherein the second starting firmware is the firmware to be started in the safe starting process of network equipment, the first key is a key generated based on a symmetric cryptographic algorithm, the length of the first key is not smaller than a preset threshold value, encrypting the plaintext code by adopting the first key to obtain a ciphertext code of the second starting firmware, and the ciphertext code of the second starting firmware is configured to be stored in the network equipment.

In one possible implementation, the symmetric cryptographic algorithm comprises the AES algorithm. And, the preset threshold is 256, that is, the length of the first key is not less than 256.

The third aspect of the application provides a network device, which comprises an acquisition module, a processing module and a processing module, wherein the acquisition module is used for running first starting firmware to acquire ciphertext codes and first keys of second starting firmware, the first starting firmware and the second starting firmware are both the firmware to be started in the safety starting process of the network device, the first starting firmware is started before the second starting firmware, the first keys are keys generated based on a symmetric cryptographic algorithm, the length of the first keys is not smaller than a preset threshold, the processing module is used for running the first starting firmware to decrypt the ciphertext codes by adopting the first keys to acquire plaintext codes of the second starting firmware, and the processing module is further used for executing the second starting firmware based on the plaintext codes.

In one possible implementation, the processing module is further configured to run the first boot firmware to perform an integrity check on the ciphertext code or the plaintext code before executing the second boot firmware.

In one possible implementation, the manner in which the first boot firmware performs the integrity check on the ciphertext code or the plaintext code includes a digital signature check manner or a hash value check manner.

In one possible implementation manner, the acquisition module is further configured to execute the first boot firmware to acquire a first digital signature or a first hash value, where the first digital signature or the first hash value is stored in a storage medium of the network device, and after the first boot firmware decrypts to obtain the plaintext code, the processing module is further configured to execute the first boot firmware to perform integrity check on the plaintext code using the first digital signature or the first hash value, and trigger execution of the second boot firmware when the plaintext code passes the integrity check.

In one possible implementation, the obtaining module is further configured to execute the first boot firmware to obtain the second digital signature or the second hash value, where the second digital signature or the second hash value is stored in a storage medium of the network device, and after the first boot firmware obtains the ciphertext code, the processing module is further configured to execute the first boot firmware to perform integrity check on the ciphertext code using the second digital signature or the second hash value, and trigger decryption of the ciphertext code when the ciphertext code passes the integrity check.

In one possible implementation, the symmetric cryptographic algorithm includes an AES algorithm, with a preset threshold of 256.

In one possible implementation, the first key is derived from a root key that is stored in an eFuse of the network device.

In one possible implementation, a flag bit is stored in a chip of the network device, where the flag bit is used to indicate that the ciphertext code of the second boot firmware needs to be decrypted during the secure boot process.

In one possible implementation, the first boot firmware is a chip internal secure boot code and the second boot firmware is a chip external secure boot code;

or the first starting firmware is a first-level security boot code outside the chip, and the second starting firmware is a second-level security boot code outside the chip;

Or, the first starting firmware is a chip external safety boot code, and the second starting firmware is a basic input output system BIOS.

In one possible implementation, the first boot firmware and the second boot firmware are executed on different system-on-chip socs.

The fourth aspect of the present application provides a network device, including an acquisition module, configured to acquire a plaintext code and a first key of a second boot firmware, where the second boot firmware is a firmware to be booted in a secure boot process of the network device, the first key is a key generated based on a symmetric cryptographic algorithm, and a length of the first key is not less than a preset threshold, and an encryption module, configured to encrypt the plaintext code with the first key to obtain a ciphertext code of the second boot firmware, where the ciphertext code is configured to be stored in the network device.

A fifth aspect of the application provides a network device comprising a processor and a memory, wherein the memory is for storing program code, the processor being for performing the method as in any of the embodiments of the first or second aspects.

A sixth aspect of the application provides a computer readable storage medium storing instructions which, when run on a computer, cause the computer to perform a method as in any one of the embodiments of the first or second aspects.

A seventh aspect of the application provides a computer program product which, when run on a computer, causes the computer to perform a method as in any of the embodiments of the first or second aspects.

An eighth aspect of the application provides a chip comprising one or more processors. Some or all of the processor is configured to read and execute computer instructions stored in the memory to perform the method of any of the possible implementations of any of the aspects described above. Optionally, the chip further comprises a memory. Optionally, the chip further comprises a communication interface, and the processor is connected with the communication interface. The communication interface is used for receiving data and/or information to be processed, and the processor acquires the data and/or information from the communication interface, processes the data and/or information and outputs a processing result through the communication interface. Optionally, the communication interface is an input-output interface or a bus interface. The method provided by the application is realized by one chip or a plurality of chips in a cooperative manner.

The solutions provided in the second aspect to the eighth aspect are used to implement or cooperate to implement the method provided in the first aspect, so that the same or corresponding benefits as those of the first aspect can be achieved, and no further description is given here.

Drawings

Fig. 1 is a schematic flow chart of a secure start after a network device is powered on according to an embodiment of the present application;

Fig. 2 is a flow chart of a method for secure booting of a network device according to an embodiment of the present application;

FIG. 3 is a flowchart illustrating a process of decrypting and then performing integrity check on a second boot firmware according to an embodiment of the present application;

FIG. 4 is a flowchart illustrating a process of performing integrity check and then decryption on a second boot firmware according to an embodiment of the present application;

FIG. 5 is a flowchart illustrating a method for processing boot firmware according to an embodiment of the present application;

FIG. 6 is a schematic flow chart of generating a firmware file by a signature server and an encryptor according to an embodiment of the present application;

Fig. 7 is a schematic diagram of an architecture of an SoC according to an embodiment of the present application;

FIG. 8 is a flowchart illustrating a process of decrypting and verifying boot firmware according to an embodiment of the present application;

FIG. 9 is a flowchart of another method for decrypting and verifying boot firmware according to an embodiment of the present application;

fig. 10 is a schematic diagram of a secure start-up procedure of a network device according to an embodiment of the present application;

fig. 11 is a schematic diagram of another secure start-up procedure of a network device according to an embodiment of the present application;

fig. 12 is a schematic diagram of a secure boot process performed on a different SoC according to an embodiment of the present application;

Fig. 13 is a schematic diagram of another implementation of a secure boot process at a different SoC according to an embodiment of the present application;

Fig. 14 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 15 is a schematic structural diagram of another network device according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, embodiments of the present application will be described below with reference to the accompanying drawings, and it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. As a person skilled in the art can know, with the appearance of a new application scenario, the technical scheme provided by the embodiment of the application is also applicable to similar technical problems.

The terms first, second and the like in the description and in the claims and in the above-described figures, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order.

In order to facilitate understanding, some technical terms related to the embodiments of the present application are described below.

(1) Symmetric cryptographic algorithm

Symmetric cryptographic algorithms refer to encryption algorithms that encrypt and decrypt data using the same key. In the symmetric cryptographic algorithm, the data encryptor processes the plaintext data and the encryption key together by a special encryption algorithm, thereby obtaining complex ciphertext data. After the data decryption party obtains the ciphertext data, if the original text is to be interpreted, the ciphertext data is required to be decrypted by using a secret key used in encryption and an inverse algorithm of the same encryption algorithm, so that plaintext data is obtained. In the symmetric cryptographic algorithm, only one key is used, so that both the encryption and decryption parties encrypt and decrypt data by using the key, which requires that the decryption party must know the encryption key in advance.

(2) Digital signature

A digital signature (also called public key digital signature) is a digital string that cannot be forged by others only the signer of the information, and is also a valid proof of the authenticity of the information sent by the signer of the information. Digital signatures are a common physical signature written on paper-like, essentially implemented using techniques in the field of public key cryptography, and are used to authenticate digital information.

When generating a digital signature, a signer processes text by using a hash function to generate a text digest, then encrypts the text digest by using a private key of the signer, and the encrypted digest is used as the digital signature of the text.

In general, digital signatures have two functions, namely, determining that text is indeed signed and sent out by a signer, because others cannot impersonate the signer's signature, and determining the integrity of the text. Because the digital signature is characterized in that it represents a feature of text, if the text changes, the value of the digital signature will also change. That is, different text will get different digital signatures.

(3) Digital signature verification mode

The digital signature verification method is a method for determining the integrity of a text by verifying a digital signature of the text.

Specifically, when verifying the digital signature of the text, the signer first calculates a text digest from the acquired text using the same hash function as the signer, and then decrypts the digital signature transmitted by the signer using the public key to obtain the text digest. If the text abstract calculated by the signer through the hash function is the same as the text abstract obtained by decryption, the signer can confirm that the obtained text is truly complete.

(4) Hash value checking mode

The hash value verification method is a method for determining text integrity by verifying a hash value of text.

Specifically, for a text, the signer uses a hash function to calculate a text hash value, and the text hash value is given to the signer along with the text. Then, when checking the hash value of the text, the signer calculates the text sent by the signer by using the hash function same as that of the signer to obtain the text hash value, and then compares the text hash value obtained by the signer with the text hash value sent by the signer. If the text hash value calculated by the signer through the hash function is the same as the text hash value sent by the signer, the signer can confirm that the acquired text is truly complete.

In the process of safe starting of the network equipment, a former-stage code in a trusted chain usually adopts a digital signature verification mode to verify a latter-stage code so as to ensure the integrity and authenticity of the latter-stage code.

Referring to fig. 1, fig. 1 is a schematic flow chart of a secure start after a network device is powered on according to an embodiment of the present application. As shown in fig. 1, after the network device is powered on, the internal chip security boot code is loaded from the read-only memory inside the chip, and the external chip security boot code (i.e., the security boot code located outside the chip) performs digital signature verification by executing the internal chip security boot code. In the case that the chip external secure boot code passes the verification, the chip external secure boot code is executed, thereby performing digital signature verification on the basic input output system (Basic Input Output System, BIOS). In the event that the BIOS check passes, the BIOS loads the operating system, thereby performing a security check on the operating system. Under the condition that the verification of the operating system is passed, the operating system can execute digital signature verification on an Application program (APP) which needs to be started by a user according to a user instruction, and execute the APP under the condition that the verification of the APP is passed. In FIG. 1, the on-chip secure boot code, the off-chip secure boot code, the BIOS, the operating system, and the APP form a trusted chain. That is, the trusted chain is formed by multiple levels of nodes, and the code corresponding to the previous level of node is responsible for executing digital signature verification on the code corresponding to the next level of node, and executing the code corresponding to the next level of node when the code corresponding to the next level of node passes the verification.

The digital signature verification mode is realized based on a traditional public key cryptographic algorithm. With the rapid development of quantum computing technology, the traditional public key cryptographic algorithm cannot realize quantum computing resistance, so that the security of a digital signature verification mode based on the public key cryptographic algorithm is greatly threatened, and a large potential safety hazard exists in the starting process of network equipment. For example, if an attacker breaks the private key used by the signer through quantum computing techniques, a corresponding digital signature can be generated for the falsified code based on the private key, thereby enabling the falsified code of the attacker to be verified by the digital signature.

In view of this, the embodiment of the present application provides a secure boot method for a network device, in which a plaintext code of a boot firmware is encrypted by a symmetric cryptographic algorithm in advance, and a length of a key used for encryption is not less than a certain threshold, so that in a secure boot process of the network device, the ciphertext code of the boot firmware needs to be decrypted by using the same key, so that the plaintext code of the boot firmware can be obtained. The key of the symmetric cryptographic algorithm can have quantum computation resistance under the condition that the length reaches a certain threshold value, so that the process of decrypting the starting firmware by adopting the symmetric cryptographic algorithm is added in the safe starting process of the network equipment, the quantum computation resistance in the safe starting process of the network equipment can be ensured, and the safety of the network equipment is further improved.

Referring to fig. 2, fig. 2 is a flowchart of a method for secure startup of a network device according to an embodiment of the present application. As shown in fig. 2, the method provided by the embodiment of the application is applied to a network device, and the network device includes a first start firmware and a second start firmware. The first starting firmware and the second starting firmware are the firmware to be started in the safe starting process of the network equipment. The network device is, for example, a physical device such as a router, a switch, a gateway, a firewall, a hub, a server, etc., and the specific form of the network device is not limited in this embodiment.

Specifically, the method for securely starting up the network device provided by the embodiment of the present application includes the following steps 201 to 203.

In step 201, the first boot firmware obtains the ciphertext code and the first key of the second boot firmware.

In this embodiment, the secure boot process of the network device includes multiple stages, where each stage is to verify the next stage boot firmware by the previous stage boot firmware in the trusted chain of the secure boot process. Therefore, the first boot firmware in this embodiment can be the previous boot firmware in any stage of the secure boot process, and the second boot firmware is the next boot firmware of the first boot firmware. That is, the first boot firmware precedes the second boot firmware, and the security of the second boot firmware needs to be checked after the first boot firmware is started.

The ciphertext code of the second boot firmware is stored in a storage medium of the network device, for example, a Flash Memory (Flash) of the network device. After the first starting firmware is started, the ciphertext code of the second starting firmware can be obtained from a storage medium of the network equipment.

Optionally, the first key is derived from a root key, which is stored in a one-time programmable memory (eFuse) of the network device to ensure security of the root key. After the first boot firmware obtains the ciphertext code of the second boot firmware, the first boot firmware triggers the derivation of the key, so that the first key derived from the root key can be obtained.

Optionally, a flag bit is stored in a chip of the network device, where the flag bit is used to indicate that the ciphertext code of the second boot firmware needs to be decrypted during the secure boot process. For example, eFuses are provided on a chip of the network device, and a 1-bit (bit) flag bit is provided in the eFuses, and when the value of the flag bit is 1, it represents that the ciphertext code of the second boot firmware needs to be decrypted. In this way, based on the flag bit stored in the chip of the network device, the first boot firmware determines that the second boot firmware needs to be decrypted during the secure boot process, thereby triggering a subsequent decryption process.

Step 202, the first boot firmware decrypts the ciphertext code of the second boot firmware with the first key to obtain the plaintext code of the second boot firmware.

In this embodiment, the first key is a key generated based on a symmetric cryptographic algorithm, and the length of the first key is not less than a preset threshold. Wherein the first key is generated based on a symmetric cryptographic algorithm and does not refer to the generation of the first key using the symmetric cryptographic algorithm, but rather refers to the generation of the first key based on a criterion of the symmetric cryptographic algorithm, thereby enabling the first key to be used as an encryption key or a decryption key in the symmetric cryptographic algorithm. The key of the symmetric cryptographic algorithm can have quantum computation resistance under the condition that the length reaches a certain threshold value, so that the encryption and decryption of the second starting firmware are realized by adopting the first key generated by the symmetric cryptographic algorithm, the security of the verification process of the second starting firmware can be ensured, and the secure starting process of the network equipment is further ensured to have quantum computation resistance.

The ciphertext code of the second starting firmware is obtained by encrypting the plaintext code of the second starting firmware by adopting the same key as the first key. Therefore, the first starting firmware adopts the first key to decrypt the ciphertext code of the second starting firmware based on the symmetric cryptographic algorithm, and then the plaintext code of the second starting firmware can be obtained.

Optionally, the symmetric cryptographic algorithm used to generate the first key comprises an advanced encryption standard (Advanced Encryption Standard, AES) algorithm, and the length of the first key is not less than 256 (i.e., the above-mentioned preset threshold is 256). The symmetric key algorithm can be other types of algorithms besides the AES described above, as long as the anti-quantum computation can be realized, and the present embodiment is not particularly limited thereto.

Step 203, the first boot firmware triggers the jump to execute the second boot firmware based on the plaintext code of the second boot firmware.

After the plaintext code of the second starting firmware is obtained through decryption, the first starting firmware can trigger to jump to a storage address where the plaintext code of the second starting firmware is located, so that the second starting firmware is executed, and starting of the second starting firmware is achieved.

It should be noted that the above describes the process that the first boot firmware decrypts the ciphertext code of the second boot firmware and triggers the execution of the second boot firmware. In the actual application process, if the first boot firmware further has the previous boot firmware in the trusted chain, the previous boot firmware of the first boot firmware may also decrypt the ciphertext code of the first boot firmware and trigger the execution of the first boot firmware by referring to the above steps 201-203. Or if the second boot firmware also has the next level of boot firmware in the trusted chain, the second boot firmware may also decrypt the ciphertext code of the next level of boot firmware and trigger execution of the next level of boot firmware in the manner described above with reference to steps 201-203.

The above describes the process that the first boot firmware decrypts to obtain the plaintext code of the second boot firmware in the process of secure booting of the network device, so as to realize the verification of the security of the second boot firmware. Optionally, before the first boot firmware triggers the second boot firmware to boot, the first boot firmware can also check the integrity of the second boot firmware to ensure the integrity of the second boot firmware.

There are various ways in which the first boot firmware verifies the integrity of the second boot firmware.

In one possible implementation, the first boot firmware performs an integrity check on the plaintext code of the second boot firmware.

In the case that the first boot firmware performs the integrity check on the plaintext code of the second boot firmware, the first boot firmware needs to perform the integrity check on the plaintext code of the second boot firmware after decrypting the ciphertext code of the second boot firmware and obtaining the plaintext code of the second boot firmware.

In another possible implementation, the first boot firmware performs an integrity check on the ciphertext code of the second boot firmware.

Since the ciphertext code of the second boot firmware is encrypted based on the plaintext code of the second boot firmware, the ciphertext code of the second boot firmware has a strong correlation with the plaintext code of the second boot firmware. If the ciphertext code of the second boot firmware is able to pass the integrity check, the plaintext code representing the second boot firmware is also complete and authentic, i.e. the plaintext code of the second boot firmware is also able to pass the integrity check.

In addition, the first starting firmware performs integrity check on the ciphertext code of the second starting firmware, and then decrypts the ciphertext code of the second starting firmware.

That is, under different implementations, the order in which the first boot firmware decrypts the second boot firmware and performs the integrity check on the second boot firmware is not the same. When the integrity check is performed on the ciphertext code of the second starting firmware, the first starting firmware firstly decrypts the second starting firmware and then performs the integrity check on the second starting firmware, and when the integrity check is performed on the ciphertext code of the second starting firmware, the first starting firmware firstly performs the integrity check on the second starting firmware and then decrypts the second starting firmware.

Optionally, whether the first boot firmware performs integrity checking on the plaintext code or the ciphertext code of the second boot firmware, the integrity checking mode adopted by the first boot firmware can be a digital signature checking mode or a hash value checking mode.

Referring to fig. 3, fig. 3 is a flowchart illustrating a process of decrypting and then performing integrity check on the second boot firmware according to an embodiment of the present application. As shown in fig. 3, the process of decrypting and then performing the integrity check on the second boot firmware by the first boot firmware includes the following steps 301-304.

In step 301, the first boot firmware obtains a ciphertext code and a first key of the second boot firmware, and obtains a first digital signature or a first hash value.

The first digital signature or the first hash value may be stored in the same storage medium as the ciphertext code of the second boot firmware, for example, both stored in Flash of the network device.

When the integrity checking mode of the second starting firmware is a digital signature checking mode, the first starting firmware acquires a first digital signature; when the integrity check mode of the second starting firmware is a hash value check mode, the first starting firmware acquires a first hash value.

In step 302, the first boot firmware decrypts the ciphertext code of the second boot firmware using the first key to obtain the plaintext code of the second boot firmware.

In this embodiment, step 302 is similar to step 202 described above, and reference is specifically made to step 202 described above, which is not repeated here.

In step 303, the first boot firmware performs an integrity check on the plaintext code of the second boot firmware using the first digital signature or the first hash value.

The method for executing the integrity check on the plaintext code of the second starting firmware by the first starting firmware by adopting the first digital signature is a digital signature check method, and the method for executing the integrity check on the plaintext code of the second starting firmware by adopting the first hash value by the first starting firmware is a hash value check method. The specific verification process of the digital signature verification method and the hash value verification method is explained with reference to the above terms, and will not be repeated here.

Step 304, when the plaintext code of the second boot firmware passes the integrity check, the first boot firmware triggers the jump to execute the second boot firmware.

If the plaintext code of the second boot firmware passes the integrity check, the ciphertext code representing the second boot firmware is not tampered with, and therefore represents the second boot firmware to be secure, thereby triggering the jump to execute the second boot firmware.

In addition, if the plaintext code of the second boot firmware fails the integrity check, the ciphertext code representing the second boot firmware may be tampered with, thereby causing an error in the decrypted plaintext code and failing to pass the integrity check, thus terminating the boot process of the network device and reporting the boot error information.

Referring to fig. 4, fig. 4 is a flowchart illustrating a process of performing integrity check and then decrypting the second boot firmware according to an embodiment of the present application. As shown in fig. 4, the process of the first boot firmware performing the integrity check on the second boot firmware before decrypting includes the following steps 401-404.

In step 401, the first boot firmware obtains the ciphertext code and the first key of the second boot firmware, and obtains the second digital signature or the second hash value.

In step 402, the first boot firmware performs an integrity check on the ciphertext code of the second boot firmware using the second digital signature or the second hash value.

And step 403, when the ciphertext code of the second starting firmware passes the integrity check, the first starting firmware adopts the first key to decrypt the ciphertext code of the second starting firmware, and the plaintext code of the second starting firmware is obtained.

When the ciphertext code of the second boot firmware passes the integrity check, the ciphertext code representing the second boot firmware is complete (i.e., has not been tampered with), so that the first boot firmware decrypts the ciphertext code of the second boot firmware using the first key, thereby obtaining the correct plaintext code of the second boot firmware.

In addition, if the ciphertext code of the second boot firmware fails the integrity check, the ciphertext code representing the second boot firmware is tampered, thus terminating the boot process of the network device and reporting a boot error message.

In step 404, the first boot firmware triggers the jump to execute the second boot firmware.

After the integrity check is completed and the plaintext code of the second starting firmware is obtained, the first starting firmware triggers the jump to execute the second starting firmware, so that the second starting firmware is started.

The above describes the process of decrypting the second boot firmware by the first boot firmware during the secure boot process of the network device. In order to obtain the ciphertext code of the second boot firmware, the embodiment of the application also provides a processing method of the boot firmware, so as to obtain the ciphertext code of the second boot firmware which can be stored in the network device. Specifically, the processing method of the boot firmware provided in the embodiment is applied to an encryption machine, and is used for executing encryption operation on the boot firmware.

Referring to the drawings, fig. 5 is a flowchart illustrating a processing method for starting firmware according to an embodiment of the application. As shown in fig. 5, the process of the boot firmware includes the following steps 501-503.

In step 501, the client sends a plaintext code for the second boot firmware to the encryptor.

In this embodiment, the client may be specifically a client used by the publisher of the second boot firmware, for interacting with the encryption machine. And under the condition that the manufacturer or the publisher of the second starting firmware needs to encrypt the second starting firmware and store the second starting firmware in the network equipment, the publisher of the second starting firmware sends the plaintext code of the second starting firmware to the encryptor through the client and informs the encryptor of encrypting the plaintext code of the second starting firmware.

Alternatively, the encryptor may obtain the plaintext code of the second boot firmware from the client, or may obtain the plaintext code of the second boot firmware by other manners, which is not limited in this embodiment. For example, the plaintext code of the second boot firmware is stored in a removable storage medium (such as a usb disk), and the removable storage medium is connected to an encryptor, and the encryptor obtains the plaintext code of the second boot firmware by reading the removable storage medium.

Step 502, the encryptor obtains a first key, and encrypts a plaintext code of the second boot firmware by using the first key to obtain a ciphertext code of the second boot firmware.

Specifically, the encryptor may derive a first key based on the root key, and encrypt a plaintext code of the second boot firmware using the derived first key, thereby obtaining a ciphertext code of the second boot firmware. The first key used by the encryptor is the same as the first key used by the first boot firmware to decrypt the ciphertext code of the second boot firmware in the above embodiment. And the encryption machine adopts a symmetric cryptographic algorithm to encrypt the plaintext code of the second boot firmware. Thus, in a subsequent decryption process, the first boot firmware is able to decrypt the ciphertext code of the second boot firmware based on the same key (i.e., the first key).

In step 503, the encryptor sends the ciphertext code of the second boot firmware to the client.

After the encryption of the second starting firmware is realized, the encryption machine returns the ciphertext code of the second starting firmware to the client so that the publisher of the second starting firmware can acquire the ciphertext code of the second starting firmware. In this way, the publisher of the second starting firmware can burn the acquired ciphertext code of the second starting firmware into the storage medium of the network device in a burning way, or the publisher of the second starting firmware publishes the ciphertext code of the second starting firmware to a designated website, and the network device downloads the ciphertext code of the second starting firmware on the website to realize the updating of the starting firmware.

Optionally, after obtaining the ciphertext code of the second starting firmware, the publisher of the second starting firmware may also make a digital signature corresponding to the ciphertext code of the second starting firmware through the signature server, so that the publisher of the second starting firmware may publish the ciphertext code of the second starting firmware and the corresponding digital signature together. Of course, the issuer of the second boot firmware may generate a digital signature corresponding to the plaintext code of the second boot firmware by the signature server, and issue the ciphertext code of the second boot firmware together with the digital signature corresponding to the plaintext code of the second boot firmware.

For ease of understanding, the encryption process of the boot firmware, and the secure boot process of the network device will be described in detail below in connection with a specific application scenario. For convenience of description, the following description will be given by taking the case of performing digital signature verification on a plaintext code of the boot firmware, and in practical application, the digital signature verification may be performed on a ciphertext code of the boot firmware, or other integrity verification methods may be adopted, which is not particularly limited herein.

Referring to fig. 6, fig. 6 is a schematic flow chart of generating a firmware file by a signature server and an encryptor according to an embodiment of the present application. In the embodiment shown in fig. 6, the firmware file generated by the signature server and the encryptor may be deployed on the network device in the embodiment described in fig. 2-4, so that the first boot firmware in the network device can obtain the ciphertext code of the second boot firmware and the digital signature of the second boot firmware.

As shown in fig. 6, for the plaintext code of the second boot firmware, the client used by the user may generate a digital signature of the second boot firmware based on the signature server, and generate the ciphertext code of the second boot firmware based on the encryptor to obtain a firmware file including the ciphertext code of the second boot firmware and the digital signature of the second boot firmware.

The client sends the hash value of the plaintext code of the second starting firmware to the signature server, and the signature server encrypts the hash value of the plaintext code by adopting a private key, so that the digital signature of the second starting firmware is obtained.

In addition, when the plaintext code of the second boot firmware is encrypted by the encryptor, the encryptor first obtains a first key derived based on the root key, and then encrypts the plaintext code of the second boot firmware by a symmetric cryptographic algorithm (such as an AES algorithm) based on the first key, thereby obtaining the ciphertext code of the second boot firmware.

Finally, a firmware file may be generated based on the ciphertext code of the second boot firmware and the digital signature of the second boot firmware. The firmware file comprises a boot firmware header, a ciphertext code of the second boot firmware and a digital signature of the second boot firmware. The boot firmware header is used to indicate the length of the ciphertext code of the second boot firmware and the location in the firmware file, and to indicate the length of the digital signature of the second boot firmware and the location in the firmware file, so that the ciphertext code of the second boot firmware and the digital signature of the second boot firmware can be located quickly in the firmware file. Optionally, the boot firmware header may further be provided with a flag bit, where the flag bit is used to indicate that the ciphertext code of the second boot firmware is required to be decrypted, so that the first boot firmware can learn that the ciphertext code of the second boot firmware needs to be decrypted when loading the ciphertext code of the second boot firmware.

In the process of security start of the network device, after the network device is powered on, a System on Chip (SoC) in the network device will start each stage of start firmware on the trusted chain in sequence, so the process of security start of the network device can be specifically understood as a process of loading and executing each stage of start firmware by the SoC. The flow executed by the SoC during the secure boot process of the network device will be described in detail below in conjunction with the structure of the SoC.

Referring to fig. 7, fig. 7 is a schematic diagram of an architecture of an SoC according to an embodiment of the present application. As shown in fig. 7, the SoC includes a Read Only Memory (ROM), a Flash controller, a processing core, a public key algorithm engine (Public Key Algorithm Engine, PKE), a symmetric algorithm engine (SYMMETRIC ALGORITHM ENGINE, SAE), efuses, and a Static Random-Access Memory (SRAM). And moreover, a Flash is arranged outside the SoC, and a Flash controller in the SoC is connected with the Flash through a communication bus so as to conveniently read data in the Flash. The Flash stores the firmware file shown in fig. 6, namely the plaintext code of the second boot firmware and the digital signature of the second boot firmware.

Specifically, the ROM is a nonvolatile storage medium inside the SoC for storing an unalterable on-chip secure boot code.

The Flash controller interacts with Flash outside the SoC through a communication bus and is used for reading, writing and erasing data in the Flash.

The processing core in the SoC is an operation and control module inside the SoC, and can initiate access to and execute operation on each component in the SoC.

The PKE is responsible for calculating the hash value of the data and performing digital signature verification.

The SAE is responsible for key derivation and decrypting ciphertext codes that initiate the firmware.

EFuses in the SoC are non-volatile storage media inside the SoC for storing sensitive data such as root keys. Wherein the root key is only accessible by SAE and not by software.

The SRAM is used for storing ciphertext codes and plaintext codes of the starting firmware, and is a running space of the starting firmware.

Referring to fig. 8, fig. 8 is a flowchart illustrating a process of decrypting and verifying boot firmware according to an embodiment of the application. As shown in fig. 8, the process of decrypting and verifying the second boot firmware in the SoC includes the following steps 1-4. In the embodiment shown in fig. 8, the SoC is deployed on the network device in the embodiment described in fig. 2-4, and the first boot firmware is specifically executed on the SoC of the network device.

Step 1, a first starting firmware running in the SoC loads a ciphertext code of a second starting firmware and a digital signature of the second starting firmware from Flash to an SRAM in the SoC.

Specifically, a firmware file is stored in Flash outside the SoC, and the firmware file includes a boot firmware header, a ciphertext code of the second boot firmware, and a digital signature of the second boot firmware. The boot firmware header can indicate where the ciphertext code of the second boot firmware and the digital signature of the second boot firmware are located, so that the first boot firmware running in the SoC loads the ciphertext code of the second boot firmware and the digital signature of the second boot firmware from the Flash to the SRAM in the SoC.

The first starting firmware running in the SoC specifically reads data in Flash through a Flash controller connected with the Flash in the SoC.

And step 2, the first starting firmware instructs SAE to derive a first key and adopts the first key to decrypt the ciphertext code of the second starting firmware to obtain the plaintext code of the second starting firmware.

Optionally, a first flag bit is provided in an eFuse of the SoC to indicate whether to decrypt the second boot firmware. In addition, the boot firmware header in Flash may be provided with a second flag bit that is also used to indicate whether the second boot firmware is to be decrypted. If any one of the first flag bit and the second flag bit indicates that the second boot firmware needs to be decrypted, the first boot firmware triggers a process of decrypting the ciphertext code of the second boot firmware.

When the first boot firmware determines that decryption of the ciphertext code of the second boot firmware is required, the first boot firmware instructs the SAE to decrypt the ciphertext code of the second boot firmware. And, the boot firmware header may carry the derivation parameters (e.g., color value and number of iterations) required for key derivation. The first boot firmware passes the derived parameters in the boot firmware header to the SAE when instructing the SAE to decrypt the ciphertext code of the second boot firmware.

Wherein the eFuses of the SoC have root keys stored therein. The SAE performs a key derivation algorithm on the root key based on the derived parameters, thereby obtaining a first key, which has a length of, for example, 256 bits. Then, SAE decrypts the ciphertext code of the second boot firmware using the derived first key, thereby obtaining the plaintext code of the second boot firmware.

And 3, based on the plaintext code of the second boot firmware, the first boot firmware instructs the PKE to verify the digital signature of the second boot firmware.

Among other things, PKE supports hash algorithms and digital signature verification algorithms. After obtaining the plaintext code of the second boot firmware, the first boot firmware notifies the PKE to verify the digital signature of the second boot firmware. The PKE firstly decrypts the digital signature loaded in the SRAM based on the public key stored in the eFuse to obtain a hash value, and the PKE calculates the hash value of the plaintext code of the second starting firmware obtained through decryption by adopting a hash algorithm to obtain the hash value, so that the PKE can complete verification of the digital signature of the second starting firmware by comparing the hash value obtained through decryption of the digital signature with the hash value obtained through calculation of the plaintext code. If PKE comparison finds that the two hash values are the same, the digital signature verification representing the second boot firmware passes, and if PKE comparison finds that the two hash values are the same, the digital signature verification representing the second boot firmware does not pass.

And 4, triggering the second starting firmware to start by the first starting firmware under the condition that the digital signature of the second starting firmware passes the verification.

Specifically, since the plaintext code of the second boot firmware has been decrypted and stored in the SRAM, the first boot firmware may trigger a jump to the address where the plaintext code of the second boot firmware is stored, thereby booting the second boot firmware.

The example shown in fig. 8 above describes the use of digital signature verification to perform integrity verification, and in some embodiments, hash value verification may be used to perform integrity verification.

Referring to fig. 9, fig. 9 is a schematic flow chart of decrypting and verifying boot firmware according to another embodiment of the present application. As shown in fig. 9, in contrast to the embodiment shown in fig. 8, the firmware file in fig. 9 includes only the boot firmware header and the ciphertext code of the second boot firmware, and no longer includes the digital signature of the second boot firmware. In addition, a firmware hash value obtained by performing hash value calculation on a plaintext code of the second boot firmware is stored in the eFuse of the SoC in advance.

Thus, after the plaintext code of the second boot firmware is decrypted, the first boot firmware instructs the PKE to calculate the plaintext code of the second boot firmware using a hash algorithm, and the calculated hash value is compared with the firmware hash value stored in the eFuse. If the calculated hash value is the same as the firmware hash value stored in the eFuse, the second boot firmware is represented as passing the hash value verification, and if the calculated hash value is not the same as the firmware hash value stored in the eFuse, the second boot firmware is represented as not passing the hash value verification.

It should be noted that the process of decrypting the second boot firmware and verifying the integrity by the first boot firmware described above may be any stage in the secure boot process of the network device, which is not specifically limited in this embodiment.

Fig. 10 is a schematic diagram illustrating a secure start-up procedure of a network device according to an embodiment of the present application, and fig. 11 is a schematic diagram illustrating another secure start-up procedure of a network device according to an embodiment of the present application. As shown in fig. 10, in one possible secure boot process of the network device, three levels of boot firmware including an internal secure boot code, an external secure boot code and a BIOS are included, and after the previous level of boot firmware is started, the next level of boot firmware needs to be decrypted and checked for integrity, and then the next level of boot firmware is triggered to be executed.

For example, the first starting firmware is an internal chip secure boot code, the second starting firmware is an external chip secure boot code, and after the internal chip secure boot code needs to decrypt the ciphertext code of the external chip secure boot code, the external chip secure boot code is subjected to digital signature verification or hash value verification, and the external chip secure boot code is triggered to be executed under the condition that the external chip secure boot code passes the digital signature verification or the hash value verification.

For another example, the first starting firmware is a secure boot code outside the chip, and the second starting firmware is a BIOS, and after the secure boot code outside the chip needs to decrypt the ciphertext code of the BIOS, the digital signature verification is performed on the BIOS, and the BIOS is triggered to be performed if the BIOS passes the digital signature verification.

As shown in fig. 11, in some cases, the off-chip secure boot code may include multiple levels of secure boot code, such as an off-chip first level secure boot code and an off-chip second level secure boot code. In the case that the chip external secure boot code includes a multi-level secure boot code, the first boot firmware is, for example, the chip internal secure boot code, and the second boot firmware is the chip external first-level secure boot code, then the chip internal secure boot code needs to decrypt the ciphertext code of the chip external first-level secure boot code, and then perform digital signature verification or hash value verification on the chip external first-level secure boot code.

Or the first starting firmware is the first-stage security boot code outside the chip, and the second starting firmware is the second-stage security boot code outside the chip, so that the first-stage security boot code outside the chip needs to decrypt the ciphertext code of the second-stage security boot code outside the chip, and then digital signature verification is executed on the second-stage security boot code outside the chip.

Or the first starting firmware is a second-level security boot code outside the chip, and the second starting firmware is a BIOS, so that the second-level security boot code outside the chip needs to decrypt the ciphertext code of the BIOS, and then digital signature verification is performed on the BIOS.

In general, the process of decrypting the second boot firmware by the first boot firmware and verifying the integrity of the second boot firmware can be any stage in the secure boot process of the network device, and is specifically related to the stage division of the secure boot process of the network device, which is not specifically limited in this embodiment.

Alternatively, the secure boot process of the network device shown in fig. 10 and 11 may be performed in one SoC or may be performed in a plurality of different socs, for example, in two or more socs.

Fig. 12 is a schematic diagram illustrating a process of completing a secure boot process at a different SoC according to an embodiment of the present application, and fig. 13 is a schematic diagram illustrating another process of completing a secure boot process at a different SoC according to an embodiment of the present application. As shown in fig. 12, on-chip secure boot code is executed on SoC 1, and the on-chip secure boot code performs decryption and integrity check on the on-chip external secure boot code. After the on-chip external secure boot code completes decryption and integrity verification, soC2 begins power-up operations and the on-chip external secure boot code is executed on SoC 2. And, the on-chip external secure boot code executed on the SoC2 performs decryption and integrity check on the BIOS, and triggers execution of the BIOS if the BIOS passes the integrity check. Finally, the BIOS continues to perform integrity checking on the operating system, and triggers the operating system to be executed if the operating system passes the integrity checking.

As shown in fig. 13, on-chip secure boot code is executed on SoC 1, and the on-chip secure boot code performs decryption and integrity verification on the on-chip external first-level secure boot code. After the on-chip external first-level secure boot code completes decryption and integrity verification, soC 2 begins power-up operations and the on-chip external first-level secure boot code is executed on SoC 2. Then, the on-chip external first-level secure boot code executed on the SoC 2 performs decryption and integrity check on the on-chip external second-level secure boot code, and triggers execution of the on-chip external second-level secure boot code if the on-chip external second-level secure boot code passes the integrity check. Second, the second-level secure boot code outside the chip executed on the SoC 2 performs decryption and integrity check on the BIOS, which performs decryption and integrity check on the operating system after the BIOS is started.

That is, the first boot firmware and the second boot firmware described above can be executed on different socs. After the first boot firmware is executed on one SoC and decryption and integrity verification of the second boot firmware are completed, the second boot firmware is executed on the other SoC.

The method for starting up the network device safely provided by the embodiment of the application is introduced above, and the device for executing the method for starting up the network device safely is introduced below.

Referring to fig. 14, fig. 14 is a schematic structural diagram of a network device according to an embodiment of the present application. As shown in fig. 14, the network device provided by the embodiment of the application includes an obtaining module 1401, a processing module 1402, and a processing module 1402, wherein the obtaining module 1401 is configured to run a first boot firmware to obtain a ciphertext code of a second boot firmware and a first key, the first boot firmware and the second boot firmware are both firmware to be started in a secure boot process of the network device, the first boot firmware is started before the second boot firmware, the first key is a key generated based on a symmetric cryptographic algorithm, and a length of the first key is not less than a preset threshold, the processing module 1402 is configured to run the first boot firmware to decrypt the ciphertext code with the first key to obtain a plaintext code of the second boot firmware, and the processing module 1402 is further configured to execute the second boot firmware based on the plaintext code.

In one possible implementation, the processing module 1402 is further configured to execute the first boot firmware to perform an integrity check on the ciphertext code or the plaintext code before executing the second boot firmware.

In one possible implementation, the obtaining module 1401 is further configured to execute the first boot firmware to obtain a first digital signature or a first hash value, where the first digital signature or the first hash value is stored in a storage medium of the network device, and after the first boot firmware decrypts to obtain the plaintext code, the processing module 1402 is further configured to execute the first boot firmware to perform an integrity check on the plaintext code using the first digital signature or the first hash value, and trigger to execute the second boot firmware when the plaintext code passes the integrity check.

In one possible implementation, the obtaining module 1401 is further configured to execute the first boot firmware to obtain the second digital signature or the second hash value, where the second digital signature or the second hash value is stored in a storage medium of the network device, and after the first boot firmware obtains the ciphertext code, the processing module 1402 is further configured to execute the first boot firmware to perform integrity check on the ciphertext code using the second digital signature or the second hash value, and trigger decryption of the ciphertext code when the ciphertext code passes the integrity check.

Referring to fig. 15, fig. 15 is a schematic structural diagram of another network device according to an embodiment of the present application. As shown in fig. 15, another network device provided by the embodiment of the present application includes an obtaining module 1501 configured to obtain a plaintext code of a second boot firmware and a first key, where the second boot firmware is a firmware to be booted in a secure boot process of the network device, the first key is a key generated based on a symmetric cryptographic algorithm, and a length of the first key is not less than a preset threshold, and an encrypting module 1502 configured to encrypt the plaintext code with the first key to obtain a ciphertext code of the second boot firmware, where the ciphertext code is configured to be stored in the network device.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are referred to each other, and each embodiment is mainly described as a difference from other embodiments.

A refers to B, referring to a simple variation where A is the same as B or A is B.

The terms first and second and the like in the description and in the claims of embodiments of the application, are used for distinguishing between different objects and not necessarily for describing a particular sequential or chronological order of the objects, and should not be interpreted to indicate or imply relative importance. For example, a first speed limiting channel and a second speed limiting channel are used to distinguish between different speed limiting channels, rather than to describe a particular order of speed limiting channels, nor should the first speed limiting channel be understood to be more important than the second speed limiting channel.

In the embodiments of the present application, unless otherwise indicated, the meaning of "at least one" means one or more, and the meaning of "a plurality" means two or more.

The above-described embodiments may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, for example, by wired (e.g., coaxial cable, optical fiber, digital Subscriber Line (DSL)), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk Solid STATE DISK (SSD)), etc.

The foregoing embodiments are merely for illustrating the technical solution of the present application, but not for limiting the same, and although the present application has been described in detail with reference to the foregoing embodiments, it will be understood by those skilled in the art that modifications may be made to the technical solution described in the foregoing embodiments or equivalents may be substituted for parts of the technical features thereof, and such modifications or substitutions do not depart from the spirit of the corresponding technical solution from the scope of the technical solution of the embodiments of the present application.

Claims

1. A method for secure initiation of a network device, comprising:

The method comprises the steps that a first starting firmware obtains a ciphertext code and a first key of a second starting firmware, the first starting firmware and the second starting firmware are both the firmware to be started in the safe starting process of the network equipment, the first starting firmware is started before the second starting firmware, the first key is a key generated based on a symmetric cryptographic algorithm, and the length of the first key is not smaller than a preset threshold;

The first starting firmware adopts the first key to decrypt the ciphertext code to obtain a plaintext code of the second starting firmware;

And executing the second starting firmware based on the plaintext code.

2. The method of claim 1, wherein prior to executing the second boot firmware, the method further comprises:

the first boot firmware performs an integrity check on the ciphertext code or the plaintext code.

3. The method of claim 2, wherein the manner in which the first boot firmware performs the integrity check on the ciphertext code or the plaintext code comprises a digital signature check manner or a hash value check manner.

4. A method according to claim 3, characterized in that the method further comprises:

The first starting firmware obtains a first digital signature or a first hash value, and the first digital signature or the first hash value is stored in a storage medium of the network equipment;

After the first starting firmware decrypts to obtain the plaintext code, the first starting firmware adopts the first digital signature or the first hash value to execute integrity check on the plaintext code, and triggers the execution of the second starting firmware when the plaintext code passes the integrity check.

5. A method according to claim 3, characterized in that the method further comprises:

the first starting firmware obtains a second digital signature or a second hash value, and the second digital signature or the second hash value is stored in a storage medium of the network equipment;

After the first starting firmware obtains the ciphertext code, the first starting firmware executes integrity check on the ciphertext code by adopting the second digital signature or the second hash value, and triggers decryption on the ciphertext code when the ciphertext code passes the integrity check.

6. The method according to any of claims 1-5, wherein the symmetric cryptographic algorithm comprises an advanced encryption standard AES algorithm, the preset threshold being 256.

7. The method of any of claims 1-6, wherein the first key is derived from a root key, the root key stored in a one-time programmable memory, eFuse, of the network device.

8. The method of any of claims 1-7, wherein a flag bit is stored in a chip of the network device, the flag bit being used to indicate that a ciphertext code of the second boot firmware needs to be decrypted during a secure boot process.

9. The method of any of claims 1-8, wherein the first boot firmware is an on-chip secure boot code and the second boot firmware is an off-chip secure boot code;

10. The method of any of claims 1-9, wherein the first boot firmware and the second boot firmware are executed on different system-on-a-chip socs.

11. A method of processing boot firmware, comprising:

Acquiring a plaintext code and a first key of a second starting firmware, wherein the second starting firmware is the firmware to be started in the safety starting process of network equipment, the first key is a key generated based on a symmetric cryptographic algorithm, and the length of the first key is not smaller than a preset threshold;

and encrypting the plaintext code by adopting a first key to obtain a ciphertext code of the second starting firmware, wherein the ciphertext code is configured to be stored in the network equipment.

12. A network device, comprising:

The system comprises an acquisition module, a first starting module and a second starting module, wherein the acquisition module is used for running a first starting firmware to acquire a ciphertext code of a second starting firmware and a first secret key, the first starting firmware and the second starting firmware are both the firmware to be started in the safety starting process of the network equipment, the first starting firmware is started before the second starting firmware, the first secret key is a secret key generated based on a symmetric cryptographic algorithm, and the length of the first secret key is not smaller than a preset threshold value;

the processing module is used for running the first starting firmware to decrypt the ciphertext code by adopting the first key to obtain a plaintext code of the second starting firmware;

the processing module is further configured to execute the second boot firmware based on the plaintext code.

13. The network device of claim 12, wherein prior to executing the second boot firmware, the processing module is further to:

the first boot firmware is run to perform an integrity check on the ciphertext code or the plaintext code.

14. The network device of claim 13, wherein the manner in which the first boot firmware performs the integrity check on the ciphertext code or the plaintext code comprises a digital signature check manner or a hash value check manner.

15. The network device of claim 14, wherein the network device,

The acquisition module is further used for running the first starting firmware to acquire a first digital signature or a first hash value, and the first digital signature or the first hash value is stored in a storage medium of the network equipment;

After the first boot firmware decrypts the plaintext code, the processing module is further configured to run the first boot firmware to perform integrity check on the plaintext code using the first digital signature or the first hash value, and trigger execution of the second boot firmware when the plaintext code passes the integrity check.

16. The network device of claim 14, wherein the network device,

The acquisition module is further used for running the first starting firmware to acquire a second digital signature or a second hash value, and the second digital signature or the second hash value is stored in a storage medium of the network equipment;

After the first boot firmware obtains the ciphertext code, the processing module is further configured to operate the first boot firmware to perform integrity check on the ciphertext code using the second digital signature or the second hash value, and trigger decryption of the ciphertext code when the ciphertext code passes the integrity check.

17. The network device according to any of claims 12-16, wherein the symmetric cryptographic algorithm comprises an AES algorithm, the preset threshold being 256.

18. The network device of any of claims 12-17, wherein the first key is derived from a root key, the root key stored in an eFuse of the network device.

19. The network device according to any of claims 12-18, wherein a flag bit is stored in a chip of the network device, the flag bit being used to indicate that a ciphertext code of the second boot firmware needs to be decrypted during a secure boot process.

20. The network device of any of claims 12-19, wherein the first boot firmware is an on-chip secure boot code and the second boot firmware is an off-chip secure boot code;

21. The network device of any of claims 12-20, wherein the first boot firmware and the second boot firmware are executed on different system-on-a-chip socs.

22. A network device, comprising:

the system comprises an acquisition module, a first judgment module and a second judgment module, wherein the acquisition module is used for acquiring a plaintext code of a second starting firmware and a first key, the second starting firmware is the firmware to be started in the safety starting process of the network equipment, the first key is a key generated based on a symmetric cryptographic algorithm, and the length of the first key is not smaller than a preset threshold;

And the encryption module is used for encrypting the plaintext code by adopting a first key to obtain the ciphertext code of the second starting firmware, and the ciphertext code is configured to be stored in the network equipment.

23. A network device comprising a processor and a memory, the memory for storing program code, the processor for invoking the program code in the memory to cause the network device to perform the method of any of claims 1-11.