Method and apparatus for testing a chip

Abstract

The application discloses a kind of test method and device of chip, wherein the method comprises: obtaining the original program package of secure boot system stored on chip;Determine the first byte that needs to be replaced in the binary encoding file of program package based on the trust chain of secure boot system in the process of secure boot, and the first byte in binary encoding file is replaced with second byte, to obtain target program package;Sign the target program package by target private key, to obtain signature data;Signature data and target public key are entered into chip, and the test result of secure boot test is obtained, wherein the test result is used to represent the running condition of secure boot system.The application solves the technical problem that the effectiveness of secure boot system cannot be tested.

Description

Technical Field

[0001] This invention relates to the field of automotive chip testing, and more specifically, to a chip testing method and apparatus. Background Technology

[0002] Currently, the common approach to ensuring the safe startup of vehicle controller chips is to monitor the safe operation of the system to determine the stability of the safety system's program package. However, there is still a technical problem that cannot test the effectiveness of the safe startup system.

[0003] There is currently no effective solution to the aforementioned technical problem of being unable to test the effectiveness of a secure boot system. Summary of the Invention

[0004] This invention provides a chip testing method and apparatus to at least solve the technical problem of being unable to test the effectiveness of a secure boot system.

[0005] According to one aspect of the present invention, a chip testing method is provided. The method may include: obtaining the original program package of a secure boot system stored on the chip; determining the first byte to be replaced in the binary encoded file of the original program package based on the trust chain of the secure boot system during the secure boot process, and replacing the first byte in the binary encoded file with a second byte to obtain a target program package; signing the target program package using a target private key to obtain signature data; recording the signature data and the target public key into the chip, and performing a secure boot test on the chip to obtain a test result, wherein the test result is used to characterize the operating status of the secure boot system.

[0006] Optionally, the encryption algorithm in the package is determined; based on the encryption algorithm, a target private key and a target public key are generated.

[0007] Optionally, based on an encryption algorithm, a target private key and a target public key are generated, including: determining the lengths of the original private key and the original public key pre-bound to the package; and generating a target private key with the same length as the original private key and a target public key with the same length as the original public key using an encryption algorithm.

[0008] Optionally, the first binary encoded file corresponding to the image computing engine, the second binary encoded file corresponding to the image bootloader, and the third binary encoded file corresponding to the image operating system in the trust chain are determined, wherein the binary encoded files include the first binary encoded file, the second binary encoded file, and the third binary encoded file.

[0009] Optionally, the first byte to be replaced in the binary encoded file of the original package is determined by at least one of the following: determining any byte of the first binary encoded file as the first byte; determining any byte of the second binary encoded file as the first byte; or determining any byte of the third binary encoded file as the first byte.

[0010] Optionally, the target package is signed using the target private key to obtain signature data, including: determining the hash value of the target package; signing the hash value using the target private key to obtain signature data, wherein a secure boot program is used to verify the legitimacy of the signature data.

[0011] Optionally, the signature data and the target public key are entered into the chip, and a secure boot test is performed on the chip to obtain the test result. This includes: entering the signature data and the target public key into the chip, and performing a secure boot test on the chip after entering the data; in response to the secure boot test, the secure boot system in the chip verifies the signature data and the target public key to obtain the test result.

[0012] Optionally, in response to the chip performing a secure boot test, the secure boot system in the chip verifies the signature data and the target public key, and obtains a test result, including: in response to the secure boot system failing to verify the signature data and the target public key, obtaining a test result indicating that the secure boot system is in a normal operating state.

[0013] According to another aspect of the present invention, a chip testing apparatus is also provided. The apparatus may include: an acquisition unit for acquiring the original program package of a secure boot system stored on the chip; a determination unit for determining, based on the trust chain of the secure boot system during the secure boot process, the first byte to be replaced in the binary encoded file of the program package, and replacing the first byte in the binary encoded file with a second byte to obtain the target program package; a signature unit for signing the target program package using a target private key to obtain signature data; and a testing unit for inputting the signature data and the target public key into the chip, and performing a secure boot test on the chip to obtain a test result, wherein the test result is used to characterize the operating status of the secure boot system.

[0014] In this embodiment of the invention, the original program package of the secure boot system stored on the chip is obtained; based on the trust chain of the secure boot system during the secure boot process, the first byte that needs to be replaced in the binary encoded file of the program package is determined, and the first byte in the binary encoded file is replaced with the second byte to obtain the target program package; the target program package is signed with the target private key to obtain signature data; the signature data and the target public key are entered into the chip, and the chip is subjected to a secure boot test to obtain the test result, wherein the test result is used to characterize the operating status of the secure boot system. In other words, this invention obtains the original program package of the secure boot system stored on the chip, determines the first byte that needs to be replaced in the binary encoding file of the original program package, replaces the first byte with the second byte to obtain the target program package, signs the target program package using the target private key to obtain signature data, stores the signature data and the target public key in the chip, and performs a secure boot test on the chip. Since the program package in the signature data has been modified, it cannot be successfully matched with the chip. Therefore, a secure boot test can be performed on the chip with the entered signature data of the target program package and the target private key. The validity of the secure boot program can be determined based on the test result of whether the chip can boot securely. This achieves the technical effect of being able to test the validity of the secure boot system and solves the technical problem of not being able to test the validity of the secure boot system. Attached Figure Description

[0015] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0016] Figure 1 This is a flowchart of a chip testing method according to an embodiment of the present invention;

[0017] Figure 2 This is a schematic diagram of an automatic safety startup test system according to an embodiment of the present invention;

[0018] Figure 3 This is a flowchart illustrating an application security boot automatic test system performing a test according to an embodiment of the present invention;

[0019] Figure 4 This is a flowchart illustrating an application-based automated boot test system performing automated testing according to an embodiment of the present invention.

[0020] Figure 5 This is a schematic diagram illustrating the verification of the legality of an image signature according to an embodiment of the present invention;

[0021] Figure 6 This is a schematic diagram of a secure startup trust chain according to an embodiment of the present invention;

[0022] Figure 7 This is a schematic diagram of a chip testing apparatus according to an embodiment of the present invention. Detailed Implementation

[0023] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0024] It should be noted that the terms "first," "second," etc., in the specification and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0025] Example 1

[0026] According to an embodiment of the present invention, an embodiment of a chip testing method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0027] Figure 1 This is a flowchart of a chip testing method according to an embodiment of the present invention, such as... Figure 1 As shown, the testing method for this chip includes the following steps:

[0028] Step S101: Obtain the original program package of the secure boot system stored on the chip.

[0029] In the technical solution provided by step S101 of the present invention, the original program package of the secure boot system stored on the chip can be obtained. The secure boot system can be a system that includes firmware trusted loading technology through step-by-step verification of the boot image, and can be used to ensure the secure boot of the device software. The original program package can be the original secure boot program package.

[0030] For example, the original package of the secure boot system uploaded by the tester can be obtained to achieve the purpose of obtaining the original package of the secure boot system stored on the chip.

[0031] Step S102: Based on the trust chain of the secure boot system during the secure boot process, determine the first byte that needs to be replaced in the binary encoded file of the original program package, and replace the first byte in the binary encoded file with the second byte to obtain the target program package.

[0032] In the technical solution provided by step S102 of the present invention, the original program package of the secure boot system stored on the chip is obtained, the trust chain of the secure boot system in the secure boot process is determined, and based on the trust chain of the secure boot system in the secure boot process, the first byte that needs to be replaced in the binary encoded file of the program package is determined, and the first byte of the binary encoded file is replaced with the second byte to obtain the target program package. The first byte can be a byte in the binary encoded file, for example, a byte in binary encoded file 100100. The trust chain in the secure boot process can be used to ensure the secure boot of the secure boot system, and can include the verification process in the secure boot process. For example, it can include the process of remote boot service (boot read-only memory, abbreviated as bootrom) verifying the second-stage program loader (spl) image, the boot loader (uboot) image verifying the spl image, and the operating system (linux) image verifying the uboot image. The entire secure boot process can be connected to obtain the trust chain of the secure boot process. The binary encoded file of the original program package can be an encoded file composed of 0 and 1 numbers. For example, the binary encoded file can be a file of 01010. It should be noted that this is only an example and no specific restrictions are placed on the content and form of the binary encoded file.

[0033] Optionally, the first byte or the second byte can be a unit of measurement used in computer information technology to measure storage capacity, or it can be used to represent data types and language characters in computer programming languages.

[0034] Optionally, the Secure Boot system needs to establish a trust chain during the secure boot process. In the boot process, each level image can be validated by its preceding image. If the first level image is valid, the validity of the second level image can be guaranteed by the first level image, the validity of the third level image by the second level image, and so on, thus connecting the trust chain throughout the entire secure boot process and ultimately ensuring the validity of the entire Secure Boot system. This is merely an illustrative example and does not specifically limit the implementation method of the Secure Boot system during the secure boot process.

[0035] For example, the original package of the Secure Boot system stored on the chip can be obtained, and the original package can be converted into a binary file. Based on the trust chain in the Secure Boot process, the corresponding position of the binary encoded file of the original package and the image in the trust chain can be identified. Then, the last byte of the image is incremented by 1 to replace the first byte with the second byte in the binary encoded file, thereby obtaining the target package. The aforementioned image can include the second-stage program loader image, the U-Boot image, and the Linux image. This is only an example of the method for obtaining the target package based on the trust chain in the Secure Boot process, and no specific limitations are made on the method.

[0036] Step S103: Sign the target package using the target private key to obtain signature data.

[0037] In the technical solution of step S103 of the present invention, based on the trust chain in step S102, the first byte to be replaced in the binary encoded file of the original program package of the secure boot system stored on the chip is determined, and the first byte is replaced with the second byte to obtain the target program package. The obtained target program package is then signed using the target private key to determine the signature data. The signature can be a digital signature, a mirror signature, etc. The target private key, also known as the new private key, can be used for signature overwriting. The signature data can be the signature value sig (hash), which is only an example and does not specifically limit the type of signature.

[0038] Optionally, the target package can be signed using the target private key of the image publisher to generate a signature value, which is also the signature data.

[0039] For example, a hash value (hash(image)) can be generated using a hash function. Then, using the image publisher's private key, an asymmetric algorithm is used to sign the image's hash value, generating a signature value (sig(hash)). It should be noted that this is merely a preferred implementation method for signing a target package using a target private key to obtain signature data. The method for signing a target package using a target private key to obtain signature data is not specifically limited. Any method or process for signing a target package using a target private key to obtain signature data is within the protection scope of this invention, and will not be elaborated upon here.

[0040] In this embodiment of the invention, the first byte that needs to be replaced in the binary encoded file of the original program package of the secure boot system stored on the chip is determined by using the trust chain of the secure boot system during the secure boot process. The first byte is then replaced with the second byte to obtain the target program package. Based on the target program package and the target private key, the signature data is determined. The chip can be tested for secure boot using the signature data and the target public key, thereby achieving the technical effect of testing the effectiveness of the secure boot system.

[0041] Step S104: Input the signature data and target public key into the chip, and perform a secure boot test on the chip to obtain the test results.

[0042] In the technical solution of step S104 of the present invention, the target public key and the signature data obtained according to step S103 can be recorded into the chip, and a secure boot test can be performed on the chip to determine the test result. The target public key can be a new public key, which can be programmed onto the chip. The test result can be used to characterize the operating status of the secure boot system, specifically its normal and abnormal operating states. For example, if the secure boot system fails to verify the signature data and the target public key, the test result for the operating status of the secure boot system can be considered as a normal state.

[0043] For example, the target program package can be signed using the target's private key to obtain signature data. The signature data sig (hash) and the target's public key (P2) are then entered into the chip, and a secure boot test is performed on the chip to obtain the test results. This is only an example and is not a specific limitation.

[0044] Optionally, since the program package in the signature data has been modified, it cannot be successfully matched with the chip. Therefore, a secure boot test can be performed on the chip containing the signature data of the target program package and the target private key. The validity of the secure boot program can be determined based on the test results of whether the chip can be securely booted.

[0045] Optionally, the test result can be the result of comparing and analyzing the target public key with the original public key during the secure boot process. Specifically, this can be achieved by using a matching new private key to overwrite the signature and burning it into the chip, thus ensuring the secure boot process can proceed smoothly. This is merely an example and does not specifically limit the implementation method for obtaining the test result after performing a secure boot test on the chip.

[0046] In steps S101 to S104 of the present invention, the original program package of the secure boot system stored on the chip is obtained; based on the trust chain of the secure boot system during the secure boot process, the first byte that needs to be replaced in the binary encoded file of the program package is determined, and the first byte in the binary encoded file is replaced with the second byte to obtain the target program package; the target program package is signed with the target private key to obtain signature data; the signature data and the target public key are entered into the chip, and a secure boot test is performed on the chip to obtain the test result, wherein the test result is used to characterize the operating status of the secure boot system. In other words, this invention obtains the original program package of the secure boot system stored on the chip, determines the first byte that needs to be replaced in the binary encoding file of the original program package, replaces the first byte with the second byte to obtain the target program package, signs the target program package using the target private key to obtain signature data, stores the signature data and the target public key in the chip, and performs a secure boot test on the chip. Since the program package in the signature data has been modified, it cannot be successfully matched with the chip. Therefore, a secure boot test can be performed on the chip with the entered signature data of the target program package and the target private key. The validity of the secure boot program can be determined based on the test result of whether the chip can boot securely. This achieves the technical effect of being able to test the validity of the secure boot system and solves the technical problem of not being able to test the validity of the secure boot system.

[0047] The method described in this embodiment will be further described below.

[0048] As an optional embodiment, the method may further include: determining the encryption algorithm in the package; and generating a target private key and a target public key based on the encryption algorithm.

[0049] In this embodiment, the encryption algorithm in the package can be determined, and a target private key and a target public key can be generated based on the encryption algorithm. The target private key and the target public key can be a key pair obtained by an algorithm, that is, a private key and a public key. The target public key is the public part of the key pair, and the target private key is the non-public part of the key pair.

[0050] Optionally, during chip testing, information such as the length and content of the public and private keys in the secure boot package can be read to select and analyze the encryption algorithms that may be used in the secure boot package. Based on the obtained encryption algorithms, new public and private keys can be generated. This is only an example and is not specifically limited.

[0051] As an optional implementation method, generating a target private key and a target public key based on an encryption algorithm includes: determining the lengths of the original private key and the original public key pre-bound to the package; and generating a target private key with the same length as the original private key and a target public key with the same length as the original public key using an encryption algorithm.

[0052] In this embodiment, the lengths of the original private key and the original public key pre-bound to the package are determined, and a target private key and a target public key with the same length as the original private key and the original public key are generated through an encryption algorithm.

[0053] Optionally, based on a determined encryption algorithm, after determining the lengths of the original private and public keys pre-bound to the program package, a public and private key can be generated using random numbers. A target public and private key of the same length as those in the secure boot program package can then be selected as a backup. It should be noted that this is merely an example of how to generate target private and public keys based on an encryption algorithm; it does not specifically limit the methods or processes for generating target private and public keys based on an encryption algorithm. Any method or process for generating target private and public keys based on an encryption algorithm is within the protection scope of this invention, and will not be listed here.

[0054] For example, the original private key and original public key can be analyzed through the original key analysis module to read information such as the length and content of the public and private keys in the program package, analyze the encryption algorithms that may be used in the secure boot program package, determine the length of the original private key and original public key pre-bound to the program package, and generate a target private key with the same length as the original private key and a target public key with the same length as the original public key through the encryption algorithm.

[0055] In this embodiment of the invention, the lengths of the original private key and the original public key pre-bound to the program package can be determined first, the encryption algorithm used in the secure boot program package can be analyzed, and a target private key with the same length as the original private key and a target public key with the same length as the original public key can be generated through the encryption algorithm. This achieves the technical effect of being able to test the effectiveness of the secure boot system and solves the technical problem of not being able to test the effectiveness of the secure boot system.

[0056] As an optional implementation method, a first binary encoded file corresponding to the image computing engine, a second binary encoded file corresponding to the image bootloader, and a third binary encoded file corresponding to the image operating system are determined in the trust chain, wherein the binary encoded file includes the first binary encoded file, the second binary encoded file, and the third binary encoded file.

[0057] In this embodiment, the binary encoded file can be identified as follows: a first binary encoded file corresponding to the image computing engine, a second binary encoded file corresponding to the image bootloader, and a third binary encoded file corresponding to the image operating system in the trust chain during the secure boot process. Specifically, the first binary encoded file corresponding to the image computing engine can be a binary encoded file of the SP1 image, the second binary encoded file corresponding to the image bootloader can be a binary encoded file of the U-Boot image, and the third binary encoded file corresponding to the image operating system can be a binary encoded file of the Linux image. This example only illustrates the image type of the binary encoded file and does not specifically limit the image type of the binary encoded file.

[0058] Optionally, the original program package of the secure boot system stored on the chip is obtained; based on the trust chain of the secure boot system during the secure boot process, the first binary encoded file corresponding to the computing engine, the second binary encoded file corresponding to the image bootloader, and the third binary encoded file corresponding to the image operating system are determined in the binary encoded file of the original program package.

[0059] As an optional implementation method, determining the first byte to be replaced in the binary encoded file of the original program package includes at least one of the following: determining any byte of the first binary encoded file as the first byte; determining any byte of the second binary encoded file as the first byte; determining any byte of the third binary encoded file as the first byte.

[0060] In this embodiment, any byte of the first binary file, or any byte of the second binary file, or any byte of the third binary file can be determined as the first byte, where any byte can be the last byte. For example, the last byte of the spl image, the last byte of the uboot image, and the last byte of the linux image can be determined as the first byte. This is merely an example of how to determine the first byte to be replaced in the binary encoded file of the original program package, and does not specifically limit the method for determining the first byte to be replaced in the binary encoded file of the original program package.

[0061] Optionally, after determining that any byte of the first binary file is the first byte, or determining that any byte of the second binary file is the first byte, or determining that any byte of the third binary file is the first byte, the first byte of the first binary file can be replaced with the second byte, or the first byte of the second binary file can be replaced with the second byte, or the first byte of the third binary file can be replaced with the second byte to obtain the target package.

[0062] For example, after determining that the last byte of the spl image is the first byte, the last byte of the spl image is incremented by 1; or after determining that the last byte of the uboot image is the first byte, the last byte of the uboot image is incremented by 1; or after determining that the last byte of the linux image is the first byte, the last byte of the linux image is incremented by 1, so as to replace the first byte of the binary encoded file with the second byte, thereby obtaining the target program package.

[0063] For another example, after determining the last byte of the spl image and the first byte of the uboot image, the last byte of the spl image and the last byte of the uboot image can be replaced with the result of the last byte plus one, thus obtaining the target program package.

[0064] As an optional implementation, the target package is signed using the target private key to obtain signature data, including: determining the hash value of the target package; signing the hash value using the target private key to obtain signature data, wherein a secure boot program is used to verify the legitimacy of the signature data.

[0065] In this embodiment, signing the target package using the target private key involves first determining the hash value of the target package, then using the target private key to sign the hash value to obtain signature data. For example, if the hash value of the target package is determined to be hash(image), then the target private key is used to sign the hash value hash(image) to obtain the signature data sig(hash). This example only illustrates the implementation method of signing the target package using the target private key to obtain signature data; it does not specifically limit the implementation method of signing the target package using the target private key to obtain signature data.

[0066] Optionally, the Secure Boot Package Modification Module can be used to increment the last byte of the SPL image, the last byte of the U-Boot image, or the last byte of the Linux image to obtain a modified Secure Boot Package. The hash value in the modified Secure Boot Package is calculated and signed with a new private key, overwriting the hash value signature in the original image file. This is then written to the chip via the chip programming module and a Secure Boot is performed. At this point, the original image, after being signed, contains the new private key and the original public key.

[0067] As an optional implementation, the signature data and the target public key are entered into the chip, and a secure boot test is performed on the chip to obtain the test result. This includes: entering the signature data and the target public key into the chip, and performing a secure boot test on the chip after entering the data; in response to the secure boot test, the secure boot system in the chip verifies the signature data and the target public key to obtain the test result.

[0068] In this embodiment, after the signature data and target public key are entered into the chip, a secure boot test is performed. The secure boot system in the chip verifies the signature data and target public key to obtain the test result. For example, the public key and signature value of an asymmetric algorithm can be used to verify the hash value of the image to obtain the test result. This example only illustrates the implementation method of entering the signature data and target public key into the chip and performing a secure boot test; it does not specifically limit the implementation method of entering the signature data and target public key into the chip and performing a secure boot test.

[0069] As an optional embodiment, in response to the chip performing a secure boot test, the secure boot system in the chip verifies the signature data and the target public key to obtain a test result, including: in response to the secure boot system failing to verify the signature data and the target public key, obtaining a test result indicating that the secure boot system is in a normal operating state.

[0070] In this embodiment, when the chip performs a secure boot test, the secure boot system can verify the signature data and the target public key. If the verification fails, the test result of the secure boot system's operating status is considered normal. For example, the secure boot system uses the public key and signature value of an asymmetric algorithm to verify the hash value of the image. If the package in the signature value has been modified, it cannot be matched with the chip. Therefore, a secure boot test can be performed on the chip using the entered signature data of the target package and the target private key. Based on the test result of whether the chip can boot securely, if the test result shows that the secure boot system fails to verify the signature data and the target public key, it indicates that the secure boot system's operating status is normal. This is only an example and does not specifically limit the verification method for obtaining the operating status of the secure boot system.

[0071] This invention obtains the original program package of the secure boot system stored on the chip, determines the first byte that needs to be replaced in the binary encoded file of the original program package, and replaces the first byte with the second byte to obtain the target program package. The target program package is then signed using the target private key to obtain signature data. The signature data and the target public key are stored in the chip, and a secure boot test is performed on the chip. Since the program package in the signature data has been modified, it cannot be successfully matched with the chip. Therefore, a secure boot test can be performed on the chip containing the signature data of the target program package and the target private key. The validity of the secure boot program can be determined based on the test results of whether the chip can boot securely. This achieves the technical effect of testing the validity of the secure boot system and solves the technical problem of not being able to test the validity of the secure boot system.

[0072] Example 2

[0073] The technical solutions of the embodiments of the present invention will be illustrated below with reference to preferred embodiments.

[0074] In related technologies, existing secure boot systems are implementation schemes for secure boot itself, while secure boot testing methods mostly focus on whether the implementation of secure boot itself is effective. Currently, automated testing systems for verifying the integrity and legality of secure boot usually only monitor the secure operation of the system to determine the stability of the secure system's program package, but they have the technical problem of not being able to test the effectiveness of the secure boot system.

[0075] In one related technology, a system secure boot method is proposed, in which the boot program can be stored simultaneously in a bootrom chip and a flash memory chip (Flash EEPROM). The system logic in the logic chip maps the starting address of the central processing unit (CPU) to one of the aforementioned chips. When the system starts, it enters from the boot program in the chip. When the chip fails, the system logic remaps the CPU's starting address to another chip. When the system starts, it enters from the boot program in the chip with the remapped CPU starting address, thereby improving the system's reliability. However, there is still a technical problem that the effectiveness of the secure boot system cannot be tested.

[0076] In another related technology, a firmware packaging and secure boot method is proposed. This secure boot method includes: obtaining a firmware package of the firmware to be booted from a device, wherein the firmware package includes firmware data and multiple sets of verification information. Each set of verification information includes a public key or public key digest, and signature information obtained by signing the firmware based on the private key corresponding to the public key or public key digest; obtaining the public key or public key digest built into the device, and determining a set of verification information that matches the public key or public key digest built into the device from the multiple sets of verification information; verifying the firmware based on the matching set of verification information, and booting the firmware after successful verification. This solves the technical problem of compatibility between new and old devices with different secure boot keys in related technologies. However, it still has the technical problem of not being able to test the effectiveness of the secure boot system.

[0077] In another related technology, a key burning method and apparatus, a secure boot method and apparatus, a device, and a medium are proposed. This method can generate a key pair; burn the start address information and length information of the public key in the key pair into a memory; wherein the public key is used for the secure boot process; burn the public key into the memory according to the start address information and length information of the public key; and provide a secure boot method, which may include: reading the start address information and length information of the public key burned according to the above key burning method from the memory; reading the public key from the memory according to the read start address information and length information of the public key; and performing the secure boot process according to the read public key. A public key programming device is also provided, comprising: a generation module for generating a key pair; a first programming module for programming the start address information and length information of the public key in the key pair into a memory; wherein the public key is used for a secure boot process; and a second programming module for programming the public key into a memory according to the start address information and length information of the public key. This addresses the problems of poor compatibility and scalability of chips in secure boot functions of related technologies, their inability to be flexibly adjusted, and their limited applicability. However, the technical problem of not being able to test the effectiveness of the secure boot system still exists.

[0078] To address the aforementioned issues, this invention proposes a chip testing method. It constructs signature data and a target private key. Since the program package in the signature data has been altered, it cannot be successfully matched with the chip. Therefore, by testing the chip against the entered program package's signature data and target private key, a test result is obtained to determine whether the chip can be securely booted, thus validating the secure boot program. This achieves the technical effect of testing the effectiveness of the secure boot system.

[0079] The embodiments of the present invention will be further described below.

[0080] Figure 2This is a schematic diagram of an automatic safety startup test system according to an embodiment of the present invention, such as... Figure 2 As shown, the Secure Boot Automatic Test System 200 may include: original key analysis module 201, new key generation module 202, secure boot package identification module 203, secure boot package modification module 204, chip programming module 205, user interaction module 206, firmware flashing module 207, secure boot module 208, and test result generation module 209.

[0081] The original key analysis module 201 is used to read information such as the length and content of the public and private keys in the program package and analyze the encryption algorithms that may be used in the secure boot program package.

[0082] The new key generation module 202 is used to generate a public key and a private key using random numbers, select the public key and private key of the same length as those in the secure boot package, and use them as backup new public key and new private key.

[0083] The Secure Boot Package Identification Module 203 is used to convert Secure Boot packages into binary files and identify the corresponding binary files for spl, uboot, and linux images.

[0084] The Secure Boot Package Modification Module 204 is used to select whether to increment the last byte of the spl image, the last byte of the uboot image, or the last byte of the linux image by 1.

[0085] The chip programming module 205 is used to program the modified secure boot program package onto the chip.

[0086] User interaction module 206 is used to present a streamlined operation interface for the functional modules in the secure startup automatic test system.

[0087] Firmware flashing module 207 is used to flash the secure boot program information on the chip.

[0088] The secure boot module 208 is used to attempt to start a modified secure boot process on the chip, using a matching new private key to overwrite the signature, and ensuring that the boot process can proceed smoothly when the new key is burned onto the chip.

[0089] The test result generation module 209 is used to modify the SPL image: if the Secure Boot automatic test system fails, it can display an integrity and validity verification error, indicating that the test has passed; otherwise, the test has failed. It can also be used to modify the U-Boot image: if the Secure Boot automatic test system fails, it can display a validity verification error, indicating that the test has passed; otherwise, the test has failed. It can also be used to modify the Linux image: if the Secure Boot automatic test system fails, it can display an integrity and validity verification error, indicating that the test has passed; otherwise, the test has failed.

[0090] In this embodiment, the secure boot automatic testing system may include: an original key analysis module, a new key generation module, a secure boot package identification module, a secure boot package modification module, a chip programming module, a user interaction module, a firmware flashing module, a secure boot module, and a test result generation module. The above-mentioned functional modules in the secure boot automatic testing system can test whether the secure boot package can be booted securely, thereby solving the technical problem of not being able to test the effectiveness of the secure boot system and achieving the technical effect of being able to test the effectiveness of the secure boot system.

[0091] Figure 3 This is a flowchart illustrating an application secure boot automated testing system according to an embodiment of the present invention. The testing method involves testers calculating and obtaining a new public key and a new private key for testing using the original key analysis module and the new key generation module (wherein the public key cannot be replaced). Figure 3 As shown, the test method includes the following steps:

[0092] Step S301: The tester uploads the secure boot package.

[0093] Optionally, during the testing process using the Secure Boot automated testing system, testers can upload the Secure Boot package.

[0094] Step S302: Read the public key and private key length from the secure boot package, and obtain the encryption algorithm.

[0095] Optionally, the lengths of the public and private keys in the package can be read through the original key analysis module to analyze the encryption algorithms that may be used in the secure boot package.

[0096] Step S303: Based on the obtained encryption algorithm, generate a new public key and a new private key.

[0097] Optionally, based on the public key and private key length read from the secure boot package in step S302, and the obtained encryption algorithm, a new public key and a new private key are generated.

[0098] Step S304: Select a new public key and a new private key for backup.

[0099] Optionally, a public key and a private key are generated using random numbers, and the public key and private key of the same length as those in the Secure Boot Package are selected as backup new public key and new private key.

[0100] In this embodiment, the tester uploads a Secure Boot package, thereby activating the key analysis module. The module reads the lengths of the public and private keys in the package, analyzes the encryption algorithms that may be used in the Secure Boot package, generates new public and private keys, and generates public and private keys using random numbers. The public and private keys with the same length as those in the Secure Boot package are selected as backup new public and private keys. This solves the technical problem of not being able to test the effectiveness of the Secure Boot system and achieves the technical effect of being able to test the effectiveness of the Secure Boot system.

[0101] Figure 4 This is a flowchart illustrating an application-based automated testing system for secure boot according to an embodiment of the present invention, such as... Figure 4 As shown, this automated testing method includes the following steps:

[0102] Step S401: Convert the Secure Boot package into a binary file.

[0103] Optionally, the Secure Boot Package is converted into a binary file by the Secure Boot Package Identification Module, and the corresponding parts of the spl image, uboot image and linux image in the binary file are determined.

[0104] Step S402: Based on the obtained binary file, modify the last byte of the image to obtain the modified image.

[0105] Optionally, the Secure Boot Package modification module can be used to modify the last byte of the binary files obtained in step S401, based on the binary files. For example, the last byte of the spl image, uboot image, and linux image can be incremented by 1.

[0106] Step S403: Calculate and obtain the new private key and the original public key based on the modified image.

[0107] Optionally, based on the last byte of the image modified in step S402, the hash value of the modified secure boot package is calculated and signed with the new private key, overwriting the hash value signature in the original image file. The package is then written to the chip through the chip programming module to attempt secure boot. The new private key and the original public key are obtained after signing the original image.

[0108] Step S404: Based on the new private key and the original public key, obtain the test results using the new public key and the original public key.

[0109] Optionally, the obtained new private key and the original public key can be compared and analyzed to obtain the test results for secure boot. The matching new private key can be used to overwrite the signature, and the new public key can be burned onto the chip to ensure that the boot process can proceed smoothly.

[0110] In this embodiment, the Secure Boot Package identification module converts the Secure Boot Package into a binary file, and the Secure Boot Package modification module modifies the last byte of the image to calculate the new private key and the original public key. The test results of using the new public key and the original public key during the Secure Boot process are then compared to obtain the test results. This solves the technical problem of not being able to test the effectiveness of the Secure Boot system and achieves the technical effect of being able to test the effectiveness of the Secure Boot system.

[0111] The basic process of mirror signing according to embodiments of the present invention will be further described below.

[0112] Figure 5 This is a schematic diagram illustrating the verification of the legality of an image signature according to an embodiment of the present invention, such as... Figure 5 As shown, the basic process for verifying the validity of an image signature is as follows.

[0113] In this embodiment, the obtained data (image) is first hashed using a hash algorithm to generate a hash value (hash(image)) of the image. Then, using the private key of the image publisher, an asymmetric algorithm is used to perform a signature process on the image's hash value and generate its signature value (sig(hash)). Finally, the image's hash value, signature value, and image are published together. When the chip starts up, the legitimacy of the image can be verified through the above process.

[0114] Optionally, the image's hash is signed using the private key and appended to the image file. When the system starts up, the source of the image can be confirmed simply by signing the image with the public key. Others cannot obtain the private key, which can only be obtained by the key owner.

[0115] In this embodiment, the public key and signature value of an asymmetric algorithm are first used to verify the hash value of the image. If the verification passes, the integrity of the image can be further verified. Otherwise, the program fails to start. If the verification passes, the hash value of the image, hash(image), is recalculated and compared with the original hash value, hash(image). If they are equal, it indicates that the integrity verification of the image has passed. Otherwise, the program fails to start.

[0116] Figure 6This is a schematic diagram of a secure boot trust chain according to an embodiment of the present invention, such as... Figure 6 As shown, the basic process of the trust chain for secure boot is as follows:

[0117] In this embodiment, the official image can be a remote boot service (bootrom) image, a second-stage program loader (spl) image, an operating system (linux) image, and other images. Unauthorized images can be a boot loader (uboot) image or an operating system (linux) image. The operating system may require multiple boot images during startup, and if any one of these images fails to execute the secureboot process, then all subsequent images are essentially untrusted.

[0118] Optionally, the remote boot service verifies the SPL image. If the SPL does not verify the U-Boot image, then once the U-Boot (universal boot loader) image is replaced, the attacker can control the entire subsequent boot process. For example, the replaced U-Boot can load an illegal Linux image from another location and arbitrarily implant backdoors in that Linux image.

[0119] Optionally, the Secure Boot process therefore needs to establish a trust chain for secure booting. During the boot process, each image is validated by its preceding image. This way, if the first-level image is valid, the validity of the second-level image is guaranteed by the first, and the validity of the third-level image is guaranteed by the second. This chain of trust connects the entire boot process, ultimately ensuring the trustworthiness of the entire system.

[0120] In this embodiment of the invention, the bootrom can be used to verify the SPL image. If the SPL does not verify the U-Boot image, the attacker can control all subsequent boot processes after the U-Boot image is replaced. Therefore, SecureBoot needs to establish a trust chain for secure boot. In the boot process, each level image is validated by its predecessor image. Thus, if the first level image is valid, the validity of the second level image can be guaranteed by the first level image, and the validity of the third level image can be guaranteed by the second level image, so as to ensure that the entire system is trustworthy. This solves the technical problem of not being able to test the effectiveness of the secure boot system and achieves the technical effect of being able to test the effectiveness of the secure boot system.

[0121] Example 3

[0122] According to an embodiment of the present invention, a chip testing apparatus is also provided. It should be noted that this chip testing apparatus can be used to perform the chip testing method described in Embodiment 1.

[0123] Figure 7 This is a schematic diagram of a chip testing apparatus according to an embodiment of the present invention. Figure 7 As shown, the testing device 700 for the chip may include: an acquisition unit 701, a determination unit 702, a signature unit 703, and a testing unit 704.

[0124] Acquisition unit 701 is used to acquire the original program package of the secure boot system stored on the chip.

[0125] The determining unit 702 is used to determine the first byte that needs to be replaced in the binary encoded file of the original program package based on the trust chain of the secure boot system during the secure boot process, and replace the first byte in the binary encoded file with the second byte to obtain the target program package.

[0126] The signature unit 703 is used to sign the target package using the target private key to obtain signature data.

[0127] Test unit 704 is used to input signature data and target public key into the chip and perform a secure boot test on the chip to obtain test results, which are used to characterize the operating status of the secure boot system.

[0128] Optionally, the apparatus may further include: a first determining unit for determining the encryption algorithm in the package; and a generating unit for generating a target private key and a target public key based on the encryption algorithm.

[0129] Optionally, the generation unit may include: a first determining module, used to determine the lengths of the original private key and the original public key pre-bound to the package; and a generation module, used to generate a target private key with the same length as the original private key and a target public key with the same length as the original public key using an encryption algorithm.

[0130] Optionally, the device may further include: a second determining unit, configured to determine a first binary encoded file corresponding to the image computing engine, a second binary encoded file corresponding to the image bootloader, and a third binary encoded file corresponding to the image operating system in the trust chain, wherein the binary encoded files include the first binary encoded file, the second binary encoded file, and the third binary encoded file.

[0131] Optionally, the determining unit 702 may include: a second determining module, used to determine any byte of the first binary encoded file as the first byte; a third determining module, used to determine any byte of the second binary encoded file as the first byte; and a fourth determining module, used to determine any byte of the third binary encoded file as the first byte.

[0132] Optionally, the signature unit 703 may include: a fifth determining module for determining the hash value of the target package; and an obtaining module for signing the hash value using the target private key to obtain signature data, wherein a secure boot program is used to verify the legality of the signature data.

[0133] Optionally, the test unit 704 may include: a test module for recording signature data and target public key into the chip and performing a secure boot test on the chip after recording; and a verification module for verifying the signature data and target public key in response to the secure boot test performed by the chip, and obtaining the test result.

[0134] Optionally, the verification module may include: an acquisition submodule, used to obtain a test result indicating that the secure boot system is in a normal operating state in response to the secure boot system's failure to verify the signature data and the target public key.

[0135] In this embodiment, the acquisition unit is used to acquire the original program package of the secure boot system stored on the chip; the determination unit is used to determine the first byte that needs to be replaced in the binary encoded file of the program package based on the trust chain of the secure boot system during the secure boot process, and replace the first byte in the binary encoded file with the second byte to obtain the target program package; the signing unit is used to sign the target program package with the target private key to obtain signature data; and the testing unit is used to input the signature data and the target public key into the chip and perform a secure boot test on the chip to obtain the test result. The test result is used to characterize the operating status of the secure boot system, thereby solving the technical problem of not being able to test the effectiveness of the secure boot system and achieving the technical effect of being able to test the effectiveness of the secure boot system.

[0136] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0137] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0138] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0139] The units designated as separate components may or may not be physically separate. Similarly, the components displayed as units may or may not be physical units; they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0140] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0141] If the integrated unit is implemented as a software functional unit and is sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0142] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for testing a chip, characterized in that, include: Obtain the original program package of the secure boot system stored on the chip; Based on the trust chain in the secure boot process of the secure boot system, the first byte that needs to be replaced in the binary encoded file of the original program package is determined, and the first byte in the binary encoded file is replaced with the second byte to obtain the target program package; The target package is signed using the target private key to obtain signature data; The signature data and the target public key are entered into the chip, and a secure boot test is performed on the chip to obtain the test results, wherein the test results are used to characterize the operating status of the secure boot system; The method further includes: determining the encryption algorithm in the target package; determining the lengths of the original private key and the original public key pre-bound to the target package; and generating the target private key and the target public key with the same length as the original private key using the encryption algorithm. The first binary encoded file corresponding to the image computing engine, the second binary encoded file corresponding to the image bootloader, and the third binary encoded file corresponding to the image operating system in the trust chain are determined, wherein the binary encoded file includes the first binary encoded file, the second binary encoded file, and the third binary encoded file.

2. The method according to claim 1, characterized in that, The determination of the first byte to be replaced in the binary encoded file of the original program package includes at least one of the following: Determine any byte of the first binary encoded file as the first byte; Any byte of the second binary encoded file is identified as the first byte; Any byte of the third binary encoded file is identified as the first byte.

3. The method according to claim 2, characterized in that, The target package is signed using the target private key to obtain the signature data, including: Determine the hash value of the target package; The hash value is signed using the target private key to obtain the signature data.

4. The method according to claim 3, characterized in that, The signature data and the target public key are entered into the chip, and a secure boot test is performed on the chip to obtain the test results, including: The signature data and the target public key are entered into the chip, and a secure boot test is performed on the chip after the data is entered. In response to the chip performing the secure boot test, the secure boot system in the chip verifies the signature data and the target public key to obtain the test result.

5. The method according to claim 4, characterized in that, In response to the chip performing the secure boot test, the secure boot system in the chip verifies the signature data and the target public key to obtain the test result, including: In response to the failure of the secure boot system to verify the signature data and the target public key, a test result is obtained indicating that the secure boot system is in a normal operating state.

6. A chip testing apparatus, characterized in that, include: The acquisition unit is used to acquire the original program package of the secure boot system stored on the chip. The determining unit is used to determine the first byte that needs to be replaced in the binary encoded file of the original program package based on the trust chain of the secure boot system during the secure boot process, and replace the first byte in the binary encoded file with the second byte to obtain the target program package; The signing unit is used to sign the target package using the target private key to obtain signature data; The testing unit is used to input the signature data and the target public key into the chip, and to perform a secure boot test on the chip to obtain test results, wherein the test results are used to characterize the operating status of the secure boot system; The testing device for the chip is also used to perform the following steps: determining the encryption algorithm in the target package; determining the lengths of the original private key and the original public key pre-bound to the target package; and generating the target private key and the target public key with the same length as the original private key using the encryption algorithm. The first binary encoded file corresponding to the image computing engine, the second binary encoded file corresponding to the image bootloader, and the third binary encoded file corresponding to the image operating system in the trust chain are determined, wherein the binary encoded file includes the first binary encoded file, the second binary encoded file, and the third binary encoded file.

Images