Method and device for verifying starting mirror image by system-on-chip, chip and equipment

Abstract

The embodiment of the invention provides a method and device for verifying a startup mirror image by a system-on-chip, a chip and equipment, and the method comprises the steps: burning a root of trust in the chip, and enabling the root of trust to comprise a plurality of root public keys; the method comprises the following steps: loading a starting mirror image and a verification data mirror image signed by using a root private key corresponding to a predetermined administrator, wherein the verification data mirror image comprises a verification head; calculating a hash value of each starting mirror image, and performing matching operation on the obtained hash value of each starting mirror image and the hash value of each starting mirror image stored in the verification data mirror image; calculating a hash value of the verification data mirror image, and performing signature verification operation on the hash value of the verification data mirror image by using the user public key in the verification head; performing signature verification operation on the user public key verification data in the verification head by using a root public key corresponding to a trust root in the verification head; matching the root of trust in the check head with the root of trust burnt in the system-on-chip; and when all the results are in a verification passing state, determining that the starting mirror image verification of the system-on-chip is passed.

Description

Technical Field

[0001] The present application relates to the field of chips, and in particular to a method, device, chip and equipment for verifying a startup image of a system-level chip. Background Art

[0002] When verifying a system-level chip, the verification process is either complicated and time-consuming, or the verification process is high-risk and the absolute security and legality of the system-level chip cannot be guaranteed. Summary of the invention

[0003] In view of this, the embodiments of the present application propose a method, device, chip and equipment for verifying the boot image of a system-level chip, so as to solve the following problems in the prior art: when verifying the system-level chip, either the verification process is complicated and time-consuming, or the verification process has high risks and the absolute security and legality of the system-level chip cannot be guaranteed.

[0004] On the one hand, an embodiment of the present application proposes a method for verifying a startup image of a system-level chip, wherein a trusted root is burned into a one-time editable memory of the system-level chip, wherein the trusted root includes each root public key of a plurality of root keys, and each of the root public keys is arranged in a predetermined order; the verification method includes: in response to a startup operation of the system-level chip, loading a startup image and a verification data image signed by a predetermined administrator corresponding to a root private key, wherein the verification data image includes a verification header, and the verification header includes: current image verification data, user public key verification data, user public key, and trusted root; calculating hash values ​​of each startup image, and matching the obtained hash values ​​of each startup image with the hash values ​​of each startup image stored in the verification data image to obtain a first result; The method comprises the steps of: calculating a hash value of the verification data image, and using the user public key in the verification header to perform a signature verification operation on the hash value of the verification data image to obtain a second result value; using the root public key corresponding to the trust root in the verification header to perform a signature verification operation on the user public key verification data in the verification header to obtain a third result value; matching the trust root in the verification header with the trust root burned in the system-level chip to obtain a fourth result value; detecting whether all result values ​​are in a verification pass state, wherein all result values ​​include: a first result value, a second result value, a third result value, and a fourth result value, and the verification pass state includes: a complete match state and a signature verification success state; when all results are in a verification pass state, determining that the startup image of the system-level chip has passed the verification.

[0005] In some embodiments, the use of the root public key corresponding to the trust root in the verification header to perform a signature verification operation on the user public key verification data in the verification header to obtain a third result value includes: parsing the trust root in the verification header to obtain multiple root public keys; using each root public key in turn to perform a signature verification operation on the user public key verification data in the verification header to obtain multiple signature verification states; determining the third result value based on the multiple signature verification states, wherein the signature verification states include: signature verification failure state and signature verification success state.

[0006] In some embodiments, a revocation table is also burned into the system-level chip, and the revocation table indicates the revocation status through bits; the use of each root public key in turn to verify the user public key in the check header to obtain multiple verification statuses includes: reading the revocation table in the system-level chip to determine the expired root public key; and using other non-expired root public keys in turn to verify the user public key in the check header.

[0007] In some embodiments, the method also includes: determining the current image verification data based on the hash value of each of the startup images and the user private key; using the root private key corresponding to the predetermined administrator to sign the hash value of the user public key to obtain the user public key verification data; storing the current image verification data, the user public key verification data, the user public key corresponding to the user private key, and the trust root in the verification header of the verification data image, and adding the stored verification data image to the image package.

[0008] In some embodiments, determining the current image verification data based on the hash value of each of the startup images and the user private key includes: obtaining the hash value of each of the startup images, and aggregating all of the hash values ​​into the verification data image; calculating the aggregated verification data image to obtain a first hash value of the verification data image; using the user private key to perform a signing operation on the first hash value; and generating the current image verification data according to the first hash value and the signature corresponding to the signing operation.

[0009] In some embodiments, the verification data image further includes: a serial number of the root key to be invalidated;

[0010] After determining that the startup image verification of the system-level chip has passed, it also includes: obtaining the serial number of the root key to be invalidated from the verification data image; determining whether the root key to be invalidated is in an invalid state in the invalidation table burned in the system-level chip; if it is in a non-invalidated state, modifying the bit of the serial number of the root key to be invalidated in the invalidation table.

[0011] In some embodiments, determining whether the root key to be invalidated is already in an invalid state in the invalidation table burned in the system-level chip includes: determining whether the serial number of the root key to be invalidated is the same as the serial number of the root key used by the mirror package that has currently passed the verification; if the serial numbers are different, determining whether the root key to be invalidated is already in an invalid state in the invalidation table burned in the system-level chip.

[0012] On the other hand, an embodiment of the present application proposes a system-level chip verification device for a startup image, wherein a trusted root is burned into a one-time editable memory of the system-level chip, wherein the trusted root includes each root public key of a plurality of root keys, and each of the root public keys is arranged in a predetermined order; the verification device includes: a loading module, which is used to load a startup image and a verification data image signed by a predetermined administrator's corresponding root private key in response to a startup operation of the system-level chip, wherein the verification data image includes a verification header, and the verification header includes: current image verification data, user public key verification data, user public key, and trusted root; a first result determination module, which is used to calculate the hash value of each startup image, and match the obtained hash value of each startup image with the hash value of each startup image stored in the verification data image to obtain a first result value; a second result determination module, which is used to calculate a third result determination module, configured to use the root public key corresponding to the trusted root in the verification header to perform a signature verification operation on the user public key verification data in the verification header to obtain a third result value; a fourth result determination module, configured to match the trusted root in the verification header with the trusted root burned in the system-level chip to obtain a fourth result value; a detection module, configured to detect whether all result values ​​are in a verification pass state, wherein all result values ​​include: a first result value, a second result value, a third result value, and a fourth result value, and the verification pass state includes: a complete match state and a successful signature verification state; a result output module, configured to determine that the startup image of the system-level chip has passed the verification when all results are in a verification pass state.

[0013] On the other hand, an embodiment of the present application provides a chip storing a computer program, wherein the computer program implements the steps of the above method when executed by a processor.

[0014] On the other hand, an embodiment of the present application proposes a computer device, which includes at least a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps of the above method when executing the computer program in the memory.

[0015] In the embodiment of the present application, the verification data image is burned into the memory of the system-level chip together with other boot images. The verification data image includes a set of hash values ​​of other boot images and a verification header. The verification header stores the current image verification data, user public key verification data, user public key, and trust root for verification. During the image package verification process, the integrity of each boot image is verified by verifying the hash values ​​of other boot images stored in the verification data image, and then the integrity of the verification data image is verified by the current image verification data and the user public key in the verification header. Then, the user public key data and the trust root in the verification header and the trust root stored in the one-time editable memory of the system-level chip are verified, thereby ensuring the legitimacy of the verification header data, and then ensuring the absolute security and legitimacy of the entire verification process of the system-level chip for the boot image package. The entire verification process is simple and easy to operate. Any administrator can sign the boot image to allow the boot image to pass the security verification of the chip. Once the key of an administrator is leaked, other administrators can be replaced to sign to implement the verification process, thereby solving the risk problem in the chip verification process. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0017] Figure 1 A schematic diagram of a root of trust in a system-on-chip provided in the first embodiment of the present application;

[0018] Figure 2 A flowchart of a method for verifying a startup image by a system-on-chip provided in the first embodiment of the present application;

[0019] Figure 3 A schematic diagram of a system-on-chip with a failure table burned into it provided in the first embodiment of the present application;

[0020] Figure 4 A schematic diagram of the composition of the verification data mirror provided in the first embodiment of the present application;

[0021] Figure 5 A schematic diagram of a process for generating an image package containing a verification data image and burning it into a SOC provided in the first embodiment of the present application;

[0022] Figure 6 A schematic diagram of the verification process provided for the first embodiment of the present application;

[0023] Figure 7A schematic diagram of the structure of a system-on-chip startup image verification device provided in the second embodiment of the present application;

[0024] Figure 8 A schematic diagram of the structure of an electronic device provided in the fourth embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to make the purpose, technical solution and advantages of the embodiment of the present application clearer, the technical solution of the embodiment of the present application will be clearly and completely described in conjunction with the drawings of the embodiment of the present application. Obviously, the described embodiment is a part of the embodiment of the present application, not all of the embodiments. Based on the described embodiment of the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0026] Unless otherwise defined, the technical terms or scientific terms used in this application should be understood by people with ordinary skills in the field to which this application belongs. "First", "second" and similar words used in this application do not indicate any order, quantity or importance, but are only used to distinguish different components. "Include" or "comprise" and similar words mean that the elements or objects appearing before the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0027] In order to keep the following description of the embodiments of the present application clear and concise, the present application omits detailed descriptions of known functions and known components.

[0028] The first embodiment of the present application provides a method for verifying a boot image in a system-level chip, wherein an unchangeable root of trust is burned into a one-time editable memory of the system-level chip, wherein the root of trust includes each root public key of a plurality of root keys, such as Figure 1 As shown, each root public key is arranged in a predetermined order, and the arrangement can be as follows Figure 1 The root public key 1, root public key 2, root public key 3, and root public key 4 shown may also be root public key 3, root public key 2, root public key 1, and root public key 4, as long as they are arranged in a predetermined order; the process of the verification method is as follows Figure 2 As shown, steps S101 to S107 are included:

[0029] S101, in response to a startup operation of the system-level chip, load a startup image and a verification data image signed by a predetermined administrator's corresponding root private key, wherein the verification data image includes a verification header, and the verification header includes: current image verification data, user public key verification data, user public key, and a trusted root.

[0030] The user public key is a user public key customized by any administrator among multiple administrators, and the user public key of any administrator can be implemented.

[0031] The embodiment of the present application is a verification process of a system-level chip for a startup image (i.e., a signature verification process). Correspondingly, the verification data image needs to be stored in the chip's image package (i.e., a collection of images) (i.e., a signature process) for verification when the chip is started. The signature process of the embodiment of the present application includes the following steps S201 to S203:

[0032] S201, determining current image verification data according to the hash value of each startup image and the user private key.

[0033] In the specific implementation, the hash values ​​of each startup image are first obtained, and all hash values ​​are summarized into the verification data image; then the summarized verification data image is calculated to obtain the first hash value of the verification data image; then the user's private key is used to sign the first hash value; finally, the current image verification data is generated according to the first hash value and the signature corresponding to the signature operation.

[0034] S202, using the root private key corresponding to the predetermined administrator to sign the hash value of the user's public key to obtain user public key verification data.

[0035] S203, store the current image verification data, the user public key verification data, the user public key corresponding to the user private key and the trust root in the verification header of the verification data image, and add the stored verification data image to the image package.

[0036] The above process from S201 to S203 completes the signature operation, and the startup image package with the verification data image added will be burned into the memory of the chip.

[0037] S102, calculating the hash value of each boot image, and matching the obtained hash value of each boot image with the hash value of each boot image stored in the verification data image to obtain a first result value.

[0038] S103, calculating a hash value of the verification data image, and performing a signature verification operation on the hash value of the verification data image using the user public key in the verification header to obtain a second result value.

[0039] S104: Use the root public key corresponding to the trusted root in the verification header to perform a signature verification operation on the user public key verification data in the verification header to obtain a third result value.

[0040] Since it is uncertain which administrator's root public key is used for the signature, the trust root in the verification header is first parsed to obtain multiple root public keys; then each root public key is used in turn to verify the user public key verification data in the verification header to obtain multiple verification statuses; finally, the third result value is determined based on the multiple verification statuses, where the verification status includes: verification failure status and verification success status.

[0041] When implemented, Figure 3 As shown, a revocation table can also be burned into the one-time editable memory in the system-level chip. The revocation table indicates the revocation status through bits. Only the revoked bits can be added, and the revoked bits cannot be revoked. Since the revocation table is burned in the SOC, the revocation table in the system-level chip can be read to determine the revoked root public key, and then the user public key verification data in the verification header is verified by using other non-revoked root public keys in turn to determine the root public key corresponding to the signature. The revocation table can avoid using the mirror package signed by the revoked root public key, thereby ensuring the security of the chip.

[0042] S105, matching the root of trust in the verification header with the root of trust programmed in the system-on-chip to obtain a fourth result value.

[0043] S106, detecting whether all result values ​​are in the verification pass status, wherein all result values ​​include: a first result value, a second result value, a third result value, and a fourth result value, and the verification pass status includes: a complete match status and a signature verification success status.

[0044] The chip verification process requires that all verifications are passed to ensure the security of the chip. Therefore, the four result values ​​obtained by the above verification need to all be in the verification pass state.

[0045] S107 , when all the results are in the verification pass state, it is determined that the boot image of the system-level chip has passed the verification.

[0046] In the embodiment of the present application, the verification data image is burned into the memory of the system-level chip together with other boot images. The verification data image includes a set of hash values ​​of other boot images and a verification header. The verification header stores the current image verification data, user public key verification data, user public key, and trust root for verification. During the image package verification process, the integrity of each boot image is verified by verifying the hash values ​​of other boot images stored in the verification data image, and then the integrity of the verification data image is verified by the current image verification data and the user public key in the verification header. Then, the user public key data and the trust root in the verification header and the trust root stored in the one-time editable memory of the system-level chip are verified, thereby ensuring the legitimacy of the verification header data, and then ensuring the absolute security and legitimacy of the entire verification process of the system-level chip for the boot image package. The entire verification process is simple and easy to operate. Any administrator can sign the boot image to allow the boot image to pass the security verification of the chip. Once the key of an administrator is leaked, other administrators can be replaced to sign to implement the verification process, thereby solving the risk problem in the chip verification process.

[0047] If the root key of an administrator is leaked, the root public key burned into the chip's root of trust needs to be invalidated to prevent the subsequent leaked root key from performing any illegal operations on the chip and ensure chip security. Figure 4 As shown, in the case of including the current image verification data, the user public key verification data, the user public key corresponding to the user private key and the trusted root, the serial number of the root key to be invalidated is also included, for example, root key 3.

[0048] After determining that the boot image verification of the system-level chip has passed, the serial number of the root key to be invalidated is obtained from the verification data image, and it is determined whether the root key to be invalidated is in an invalid state in the invalidation table burned in the system-level chip; if it is in a non-invalidated state, the bit of the serial number of the root key to be invalidated in the invalidation table is modified to adjust the root key to be invalidated to an invalid state in the invalidation table, so that when the boot image is loaded again, the invalidation table in the system-level chip can be read to determine the invalidated root public key.

[0049] In the process of determining whether the root key to be invalidated is already in an invalid state in the invalidation table burned in the system-level chip, in order to avoid the current image package being signed using the root key to be invalidated, it is necessary to first determine whether the serial number of the root key to be invalidated is the same as the serial number of the root key used by the current image package that has passed the verification; if the serial numbers are different, then determine whether the root key to be invalidated is already in an invalid state in the invalidation table burned in the system-level chip. If it is not invalid, modify the bit of the serial number of the root key to be invalidated in the invalidation table at the corresponding position to perform invalidation processing; if it is already invalid, no further processing is performed.

[0050] The above process is exemplarily described below with reference to the accompanying drawings.

[0051] Two types of keys are used during the chip startup process, the root key and the user key; an asymmetric encryption algorithm is used, so each key is a pair, with a private key and a public key.

[0052] The verification method of the embodiment of the present application configures 4 groups of root keys. Those skilled in the art can configure multiple groups according to actual conditions, such as 3 groups, 5 groups, etc. The 4 groups in this embodiment are only an example. These 4 groups of root public keys will form a public trust root in a fixed order; then they will be burned into the one-time programmable memory of the SOC and cannot be changed. It is the ultimate basis for the entire startup verification process.

[0053] These four sets of root private keys correspond to four administrators who keep one of the root private keys separately. The root private keys cannot be changed or leaked and are required to sign the boot image. The four administrators each hold a set of root private keys and clearly indicate their serial numbers. The user key is user-defined and a new user key can be used each time the image package is signed. The user private key still needs to be kept specially and the user public key is public.

[0054] Each administrator has a set of root private keys, root public key sets (i.e., trust roots), customized user private keys, and user public keys. Based on the above preparations, the image package can be signed; the signed image package can be correctly verified when it is started on a chip with the trust root burned in it.

[0055] When it is suspected that an administrator's root key has been leaked, each administrator can specify the serial numbers of other root keys that need to be invalidated when signing the image package; after the chip is started, when the verification process is completed and passed, it will enter the process corresponding to the invalidated key.

[0056] The embodiment of the present application includes a signing process, a verification process and an invalidation key process, and each process is described below.

[0057] (A) Signature process

[0058] The signing process includes the following steps (11) to (14):

[0059] (11) The hash values ​​of each boot image will be aggregated into a unified verification data image.

[0060] If a key sequence number is specified to be invalidated, its value will also be added to the verification data image.

[0061] (12) The aggregated verification data image can calculate a hash value, which is signed with the user's private key. The hash value and the signature cost image verification data (i.e., the current image verification data) are saved at the beginning of the image (i.e., in the verification header);

[0062] (13) Any of the four administrators uses his or her root private key to sign the user public key hash value to obtain the user public key verification data, which is stored in the verification header of the verification data mirror together with the user public key and the trust root.

[0063] (14) Attach the final generated verification data image to the entire image package, burn it to the SOC, and complete the signature.

[0064] like Figure 5 As shown, any administrator participates in the signature and generates an image package containing the verification data image and burns it into the SOC.

[0065] (B) Verification process

[0066] There is also an expiration table in the one-time programmable memory of the SOC, which is used to record the serial numbers of expired root keys and confirm that they cannot be restored after expiration. As long as each administrator's root key has not been expired, the image package independently signed by him can be correctly verified on the chip.

[0067] The verification process is as follows Figure 6 As shown, it includes the following steps (21) to (27):

[0068] (21) After the chip is started, the startup image is loaded, and the verification data image is also loaded and parsed.

[0069] (22) Calculate the hash value for each boot image and compare it with the value stored in the verification data image to ensure the integrity of each boot image. If they are consistent, execute (23), otherwise execute (27).

[0070] (23) Calculate the hash value of the verification data image and use it to verify the user public key in the verification header to ensure the integrity of the verification data image. If the signature verification passes, execute (24), otherwise execute (27).

[0071] (24) Read the invalidation table in the SOC, parse the trust root in the check header into 4 groups of root public keys, and try to use the non-expired root public keys to verify the user public key verification data in the check header in turn to ensure the integrity and legitimacy of the user public key. If the signature verification passes, execute (25), otherwise execute (27).

[0072] (25) Finally, the root of trust in the verification header is compared with the root of trust burned into the chip. If they are the same, they are legal and execute (26). Otherwise, execute (27).

[0073] (26) The verification is successful, confirming that the boot image is legal and complete. Finally, the legality of the entire verification process is also guaranteed.

[0074] (27) Verification failed.

[0075] There is no order of precedence for steps (22) to (25) above, and all of them must be successfully verified for the verification to pass.

[0076] (3) Key expiration process.

[0077] According to the above description, when you have any set of root private keys and obtain the public root of trust, you can customize the user key to correctly sign the image package so that it can be correctly verified during the chip startup process. When any set of root private keys is at risk of being leaked, it needs to be invalidated. After that, the image package signed by this set of root keys can no longer be correctly verified during the chip startup process.

[0078] After confirming the root key serial number that needs to be invalidated, any other administrator sets the corresponding serial number in the key to be invalidated field of the verification data image when signing a new image package; after that, the user does not need to operate on the client, and when the chip starts using the new image package, the key invalidation process will be executed normally.

[0079] The failure process includes the following steps (31) to (35):

[0080] (31) The new image package passes the verification when it is started, and the serial number of the root key to be invalidated is obtained.

[0081] (32) Determine whether the serial number is the same as the root key used to sign the current boot image package. If they are different, execute (33); if they are the same, there is a fault and an alarm needs to be processed.

[0082] (33) Determine whether the root key corresponding to the serial number has expired. If it has expired, the invalidation operation will not be repeated; if it has not expired, execute (34).

[0083] (34) Determine whether the current image package has been successfully and correctly started. If it has not been started, do not perform the key invalidation operation. If it has been started, perform (35).

[0084] This flag is generally determined by the partition table attributes. This method is not fixed and is not necessary. It is mainly used to prevent the current new image package from failing to start correctly.

[0085] (35) Automatically modify the failure table in the SOC to complete the failure operation.

[0086] The above-mentioned invalid root key can be, for example, the following scenario: the chip with the trusted root burned in has been using the root key 1 held by administrator 1 to sign the image package. The root key 1 held by administrator 1 is at risk. The root key 2 held by administrator 2 is started to sign the image package, and the key to be invalidated field is set to 1. After the new image package is burned onto the chip, the chip can verify the new image package and confirm that the new image package can be started normally. Then, the invalidation table of the burned chip will invalidate the root key 1. After that, all image packages signed by the root key 1 cannot be started normally on the chip. Root keys 2, 3 and 4 are all normal.

[0087] The one-time programmable memory in the chip of the embodiment of the present application contains a plurality of root public keys combined in a fixed order to form a trust root, and also contains a root key expiration table; the bits of the expiration table correspond to the root keys with the same serial number, and when the bit is set to 1, the corresponding key is invalid, and once set, it cannot be restored.

[0088] Each administrator has his own independent root private key with a specific serial number. When the administrator believes that a root private key has a risk of being leaked, he can set one or more serial numbers of the key to be invalidated when signing the image package on the client. The serial numbers of the key to be invalidated will eventually be stored in the verification data image generated by the signature.

[0089] After the chip is started, when verifying the image package, it will parse the verification data image; in this process, you can get the set key serial number to be invalidated, and you can also get which serial number of the root key that the currently verified image package was issued by;

[0090] Since the burning of the one-time programmable memory cannot be restored, during the startup process, only the program running on the security domain has the authority to operate it; when starting the program running on the security domain, after completing the verification of the image package and confirming that the verification data image in the image package is complete and legal, it is determined that the key serial number to be invalidated in the verification data image is also legal. When the serial number value is not empty, the key expiration process is entered.

[0091] In the key expiration process, if the conditions are met, the bit corresponding to the key number to be invalidated in the expiration table of the one-time programmable memory in the chip will be rewritten and set to 1; after the setting is successful, all image packages signed by the invalidated key will not be able to start normally on the chip with the trusted root burned.

[0092] The embodiment of the present application pre-sets a trust root of multiple key combinations. At the same time, these core keys are independent of each other and can each complete the chip startup image signature. Any set of repairs can perform corresponding key invalidation operations on the chip with the trust root solidified, thereby solving security risks. At the same time, the embodiment of the present application ensures the security of the secure boot solution based on the trust root of multiple key combinations through a complete signing, verification and invalidation process.

[0093] The second embodiment of the present application provides a system-level chip verification device for a boot image, wherein a trusted root is burned into a one-time editable memory of the system-level chip, wherein the trusted root includes each root public key of a plurality of root keys, and each root public key is arranged in a predetermined order; the structure of the device is shown in FIG. Figure 7 As shown, including:

[0094] The loading module 10 is used to load the startup image and the verification data image signed by the corresponding root private key of the predetermined administrator in response to the startup operation of the system-level chip, wherein the verification data image includes a verification header, and the verification header includes: current image verification data, user public key verification data, user public key, and trust root;

[0095] A first result determination module 20, coupled to the loading module 10, is used to calculate the hash value of each boot image, and match the obtained hash value of each boot image with the hash value of each boot image stored in the verification data image to obtain a first result value;

[0096] The second result determination module 30 is coupled to the loading module 10 and is used to calculate the hash value of the verification data image and perform a signature verification operation on the hash value of the verification data image using the user public key in the verification header to obtain a second result value;

[0097] A third result determination module 40, coupled to the loading module 10, is used to perform a signature verification operation on the user public key verification data in the verification header using the root public key corresponding to the trusted root in the verification header to obtain a third result value;

[0098] A fourth result determination module 50, coupled to the loading module 10, is used to match the trust root in the check header with the trust root burned into the system-level chip to obtain a fourth result value;

[0099] The detection module 60 is coupled with the first result determination module 20, the second result determination module 30, the third result determination module 40, and the fourth result determination module 50, and is used to detect whether all result values ​​are in the verification pass state, wherein all result values ​​include: the first result value, the second result value, the third result value, and the fourth result value, and the verification pass state includes: the complete match state and the signature verification success state;

[0100] The result output module 70 is coupled to the detection module 60 and is used to determine that the boot image of the system-level chip has passed the verification when all the results are in the verification-passed state.

[0101] The third result determination module 40 is specifically used to: parse the trust root in the verification header to obtain multiple root public keys; use each root public key in turn to verify the user public key verification data in the verification header to obtain multiple verification states; determine the third result value according to the multiple verification states, wherein the verification state includes: verification failure state, verification success state.

[0102] The above-mentioned system-level chip is also burned with a revocation table, which indicates the revocation status through bits; when the third result determination module 40 uses each root public key in turn to verify the user public key in the check header to obtain multiple verification statuses, it is specifically used to: read the revocation table in the system-level chip to determine the expired root public key; use other non-expired root public keys in turn to verify the user public key in the check header.

[0103] The above-mentioned device also includes a signature module, which is used to: determine the current image verification data according to the hash value of each startup image and the user's private key; use the root private key corresponding to the predetermined administrator to sign the hash value of the user's public key to obtain the user's public key verification data; store the current image verification data, the user's public key verification data, the user's public key corresponding to the user's private key, and the trust root in the verification header of the verification data image, and add the stored verification data image to the image package. Wherein, when determining the current image verification data according to the hash value of each startup image and the user's private key, first obtain the hash value of each startup image, and summarize all the hash values ​​into the verification data image, and then calculate the summarized verification data image to obtain the first hash value of the verification data image; then use the user's private key to sign the first hash value; finally, generate the current image verification data according to the first hash value and the signature corresponding to the signature operation.

[0104] The verification data mirror of the embodiment of the present application also includes: the serial number of the root key to be invalidated. After determining that the boot mirror verification of the system-level chip has passed, the invalidation module is used to: obtain the serial number of the root key to be invalidated from the verification data mirror; determine whether the root key to be invalidated is in an invalid state in the invalidation table burned in the system-level chip; if it is in a non-invalidated state, modify the bit of the serial number of the root key to be invalidated in the invalidation table.

[0105] Among them, when determining whether the root key to be invalidated is already in an invalid state in the invalidation table burned in the system-level chip, first determine whether the serial number of the root key to be invalidated is the same as the serial number of the root key used by the mirror package that has currently passed the verification, and then, if the serial numbers are different, determine whether the root key to be invalidated is already in an invalid state in the invalidation table burned in the system-level chip.

[0106] In the embodiment of the present application, the verification data image is burned into the memory of the system-level chip together with other boot images. The verification data image includes a set of hash values ​​of other boot images and a verification header. The verification header stores the current image verification data, user public key verification data, user public key, and trust root for verification. During the image package verification process, the integrity of each boot image is verified by verifying the hash values ​​of other boot images stored in the verification data image, and then the integrity of the verification data image is verified by the current image verification data and the user public key in the verification header. Then, the user public key data and the trust root in the verification header and the trust root stored in the one-time editable memory of the system-level chip are verified, thereby ensuring the legitimacy of the verification header data, and then ensuring the absolute security and legitimacy of the entire verification process of the system-level chip for the boot image package. The entire verification process is simple and easy to operate. Any administrator can sign the boot image to allow the boot image to pass the security verification of the chip. Once the key of an administrator is leaked, other administrators can be replaced to sign to implement the verification process, thereby solving the risk problem in the chip verification process.

[0107] A third embodiment of the present application provides a chip, which is a system-level chip storing a computer program, and a trusted root is burned into a one-time editable memory of the system-level chip, wherein the trusted root includes each root public key in a plurality of root keys, and each root public key is arranged in a predetermined order; when the computer program is executed by a processor, the method provided by any embodiment of the present application is implemented, including the following steps S11 to S17:

[0108] S11, in response to a startup operation of the system-level chip, loading a startup image and a verification data image signed by a predetermined administrator corresponding to a root private key, wherein the verification data image includes a verification header, and the verification header includes: current image verification data, user public key verification data, user public key, and a trusted root;

[0109] S12, calculating the hash value of each boot image, and matching the obtained hash value of each boot image with the hash value of each boot image stored in the verification data image to obtain a first result value;

[0110] S13, calculating the hash value of the verification data image, and using the user public key in the verification header to perform a signature verification operation on the hash value of the verification data image to obtain a second result value;

[0111] S14, using the root public key corresponding to the trusted root in the verification header to perform a signature verification operation on the user public key verification data in the verification header to obtain a third result value;

[0112] S15, matching the root of trust in the check header with the root of trust programmed in the system-on-chip to obtain a fourth result value;

[0113] S16, detecting whether all result values ​​are in the verification pass state, wherein all result values ​​include: a first result value, a second result value, a third result value, and a fourth result value, and the verification pass state includes: a complete match state and a signature verification success state;

[0114] S17, when all the results are in the verification pass state, it is determined that the boot image of the system-level chip has passed the verification.

[0115] When the computer program is executed by the processor to use the root public key corresponding to the trust root in the verification header to perform a signature verification operation on the user public key verification data in the verification header to obtain a third result value, the processor specifically performs the following steps: parsing the trust root in the verification header to obtain multiple root public keys; using each root public key in turn to perform a signature verification operation on the user public key verification data in the verification header to obtain multiple signature verification states; determining the third result value based on the multiple signature verification states, wherein the signature verification states include: signature verification failure state and signature verification success state.

[0116] The above-mentioned system-level chip is also burned with a revocation table, which indicates the revocation status through bits; when the computer program is executed by the processor and uses each root public key in turn to verify the user public key in the check header to obtain multiple verification statuses, the processor specifically executes the following steps: read the revocation table in the system-level chip to determine the expired root public key; use other non-expired root public keys in turn to verify the user public key in the check header.

[0117] The computer program is specifically further executed by the processor as follows: determining the current image verification data according to the hash value of each startup image and the user private key; using the root private key corresponding to the predetermined administrator to sign the hash value of the user public key to obtain the user public key verification data; storing the current image verification data, the user public key verification data, the user public key corresponding to the user private key and the trust root in the verification header of the verification data image, and adding the stored verification data image to the image package.

[0118] When the computer program is executed by the processor to determine the current image verification data according to the hash value of each startup image and the user private key, the processor specifically executes the following steps: obtaining the hash value of each startup image, and summarizing all the hash values ​​into the verification data image; calculating the summarized verification data image to obtain the first hash value of the verification data image; using the user private key to perform a signing operation on the first hash value; generating the current image verification data according to the first hash value and the signature corresponding to the signing operation.

[0119] The above-mentioned verification data image also includes: the serial number of the root key to be invalidated; after the computer program is executed by the processor to determine that the startup image verification of the system-level chip has passed, the processor also executes the following steps: obtaining the serial number of the root key to be invalidated from the verification data image; determining whether the root key to be invalidated is in an invalid state in the invalidation table burned in the system-level chip; if it is in a non-invalidated state, modifying the bit of the serial number of the root key to be invalidated in the invalidation table at the corresponding position.

[0120] When the computer program is executed by the processor to determine whether the root key to be invalidated is already in an invalid state in the invalidation table burned in the system-level chip, the processor specifically executes the following steps: determining whether the serial number of the root key to be invalidated is the same as the serial number of the root key used by the mirror package that has currently passed the verification; if the serial numbers are different, determining whether the root key to be invalidated is already in an invalid state in the invalidation table burned in the system-level chip.

[0121] In the embodiment of the present application, the verification data image is burned into the memory of the system-level chip together with other boot images. The verification data image includes a set of hash values ​​of other boot images and a verification header. The verification header stores the current image verification data, user public key verification data, user public key, and trust root for verification. During the image package verification process, the integrity of each boot image is verified by verifying the hash values ​​of other boot images stored in the verification data image, and then the integrity of the verification data image is verified by the current image verification data and the user public key in the verification header. Then, the user public key data and the trust root in the verification header and the trust root stored in the one-time editable memory of the system-level chip are verified, thereby ensuring the legitimacy of the verification header data, and then ensuring the absolute security and legitimacy of the entire verification process of the system-level chip for the boot image package. The entire verification process is simple and easy to operate. Any administrator can sign the boot image to allow the boot image to pass the security verification of the chip. Once the key of an administrator is leaked, other administrators can be replaced to sign to implement the verification process, thereby solving the risk problem in the chip verification process.

[0122] Optionally, in this embodiment, the above-mentioned computer program product may include, but is not limited to, various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk. Optionally, in this embodiment, the processor executes the method steps recorded in the above-mentioned embodiment according to the program code stored in the computer program product. Optionally, the specific examples in this embodiment can refer to the examples described in the above-mentioned embodiment and the optional implementation mode, and this embodiment is not repeated here. Obviously, it should be understood by those skilled in the art that the above-mentioned modules or steps of the present application can be implemented with a general computing device, which can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices. Optionally, they can be implemented with executable program codes of computing devices, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that here, or they can be made into individual integrated circuit modules respectively, or multiple modules or steps therein can be made into a single integrated circuit module to implement. In this way, the present application is not limited to any specific combination of hardware and software.

[0123] A fourth embodiment of the present application provides an electronic device. The structural diagram of the electronic device can be as follows: Figure 8 As shown, at least a memory 901 and a processor 902 are included, the memory 901 stores a computer program, and the processor 902 implements the verification method of the system-level chip provided by any embodiment of the present application when executing the computer program on the memory 901. Exemplarily, a root of trust is burned into a one-time editable memory of the system-level chip, wherein the root of trust includes each root public key of a plurality of root keys, and each root public key is arranged in a predetermined order; the computer program steps of the computer device are as follows S21 to S27:

[0124] S21, in response to a startup operation of the system-level chip, loading a startup image and a verification data image signed by a predetermined administrator corresponding to a root private key, wherein the verification data image includes a verification header, and the verification header includes: current image verification data, user public key verification data, user public key, and a trusted root;

[0125] S22, calculating the hash value of each boot image, and matching the obtained hash value of each boot image with the hash value of each boot image stored in the verification data image to obtain a first result value;

[0126] S23, calculating the hash value of the verification data image, and using the user public key in the verification header to perform a signature verification operation on the hash value of the verification data image to obtain a second result value;

[0127] S24, using the root public key corresponding to the trusted root in the verification header to perform a signature verification operation on the user public key verification data in the verification header to obtain a third result value;

[0128] S25, matching the root of trust in the check header with the root of trust programmed in the system-on-chip to obtain a fourth result value;

[0129] S26, detecting whether all result values ​​are in the verification pass state, wherein all result values ​​include: a first result value, a second result value, a third result value, and a fourth result value, and the verification pass state includes: a complete match state and a signature verification success state;

[0130] S27, when all the results are in the verification pass state, it is determined that the boot image of the system-level chip has passed the verification.

[0131] When the processor executes a computer program stored in the memory and uses the root public key corresponding to the trust root in the check header to perform a signature verification operation on the user public key verification data in the check header to obtain a third result value, the processor specifically executes the following computer program: parsing the trust root in the check header to obtain multiple root public keys; using each root public key in turn to perform a signature verification operation on the user public key verification data in the check header to obtain multiple signature verification states; determining the third result value according to the multiple signature verification states, wherein the signature verification states include: a signature verification failure state and a signature verification success state.

[0132] The above-mentioned system-level chip is also burned with a revocation table, which indicates the revocation status through bits; when the processor executes a computer program stored in the memory that uses each root public key in turn to verify the user public key in the check header to obtain multiple verification statuses, the processor specifically executes the following computer program: read the revocation table in the system-level chip to determine the expired root public key; use other non-expired root public keys in turn to verify the user public key in the check header.

[0133] The processor also specifically executes the following computer program: determining the current image verification data according to the hash value of each startup image and the user private key; using the root private key corresponding to the predetermined administrator to sign the hash value of the user public key to obtain the user public key verification data; storing the current image verification data, the user public key verification data, the user public key corresponding to the user private key and the trust root in the verification header of the verification data image, and adding the stored verification data image to the image package.

[0134] When the processor executes a computer program stored in the memory and determines the current image verification data according to the hash values ​​of each startup image and the user private key, the processor specifically executes the following computer program: obtaining the hash values ​​of each startup image, and summarizing all the hash values ​​into the verification data image; calculating the summarized verification data image to obtain a first hash value of the verification data image; using the user private key to perform a signing operation on the first hash value; and generating the current image verification data according to the first hash value and the signature corresponding to the signing operation.

[0135] The above-mentioned verification data image also includes: the serial number of the root key to be invalidated; after the processor executes the computer program stored in the memory to determine that the startup image verification of the system-level chip has passed, it also executes the following computer program: obtaining the serial number of the root key to be invalidated from the verification data image; determining whether the root key to be invalidated is in an invalid state in the invalidation table burned in the system-level chip; if it is in a non-invalidated state, modifying the bit of the serial number of the root key to be invalidated in the invalidation table at the corresponding position.

[0136] When the processor executes a computer program stored in the memory for determining whether the root key to be invalidated is already in an invalid state in the invalidation table burned in the system-level chip, the processor specifically executes the following computer program: determining whether the serial number of the root key to be invalidated is the same as the serial number of the root key used by the mirror package that has currently passed the verification; if the serial numbers are different, determining whether the root key to be invalidated is already in an invalid state in the invalidation table burned in the system-level chip.

[0137] In the embodiment of the present application, the verification data image is burned into the memory of the system-level chip together with other boot images. The verification data image includes a set of hash values ​​of other boot images and a verification header. The verification header stores the current image verification data, user public key verification data, user public key, and trust root for verification. During the image package verification process, the integrity of each boot image is verified by verifying the hash values ​​of other boot images stored in the verification data image, and then the integrity of the verification data image is verified by the current image verification data and the user public key in the verification header. Then, the user public key data and the trust root in the verification header and the trust root stored in the one-time editable memory of the system-level chip are verified, thereby ensuring the legitimacy of the verification header data, and then ensuring the absolute security and legitimacy of the entire verification process of the system-level chip for the boot image package. The entire verification process is simple and easy to operate. Any administrator can sign the boot image to allow the boot image to pass the security verification of the chip. Once the key of an administrator is leaked, other administrators can be replaced to sign to implement the verification process, thereby solving the risk problem in the chip verification process.

[0138] In addition, although exemplary embodiments have been described herein, the scope includes any and all embodiments based on the present application with equivalent elements, modifications, omissions, combinations (e.g., various embodiments intersecting schemes), adaptations or changes. The elements in the claims will be interpreted broadly based on the language adopted in the claims, and are not limited to the examples described in this specification or during the implementation of the application, and the examples will be interpreted as non-exclusive. Therefore, this specification and examples are intended to be considered as examples only, and the true scope and spirit are indicated by the following claims and the full scope of their equivalents.

[0139] The above description is intended to be illustrative rather than restrictive. For example, the above examples (or one or more of them) can be used in combination with each other. For example, those of ordinary skill in the art can use other embodiments when reading the above description. In addition, in the above-mentioned specific embodiments, various features can be grouped together to simplify the application. This should not be interpreted as an intention that a disclosed feature that does not require protection is necessary for any claim. On the contrary, the subject matter of the present application may be less than all the features of a specific disclosed embodiment. Thus, the following claims are incorporated into the specific embodiments as examples or embodiments, wherein each claim is independently used as a separate embodiment, and it is considered that these embodiments can be combined with each other in various combinations or arrangements. The scope of the present application should be determined with reference to the attached claims and the full scope of equivalent forms granted by these claims.

[0140] Multiple embodiments of the present application are described in detail above, but the present application is not limited to these specific embodiments. Those skilled in the art can make various variations and modifications to the embodiments based on the concept of the present application, and these variations and modifications should all fall within the scope of protection required by the present application.

Claims

1. A method for verifying a startup image of a system-level chip, characterized in that: A root of trust is burned into a one-time editable memory of the system-level chip, wherein the root of trust includes each root public key of a plurality of root keys, and each of the root public keys is arranged in a predetermined order; The verification method comprises: In response to the boot operation of the system-level chip, a boot image and a verification data image signed by a predetermined administrator corresponding to a root private key are loaded, wherein the verification data image includes a verification header, and the verification header includes: current image verification data, user public key verification data, user public key, and a trusted root; Calculating hash values ​​of each boot image, and matching the obtained hash values ​​of each boot image with the hash values ​​of each boot image stored in the verification data image to obtain a first result value; Calculate the hash value of the verification data image, and use the user public key in the verification header to perform a signature verification operation on the hash value of the verification data image to obtain a second result value; Using the root public key corresponding to the trusted root in the verification header, a signature verification operation is performed on the user public key verification data in the verification header to obtain a third result value; Matching the root of trust in the verification header with the root of trust burned into the system-on-chip to obtain a fourth result value; Detect whether all result values ​​are in the verification pass state, wherein all result values ​​include: the first result value, the second result value, the third result value, and the fourth result value, and the verification pass state includes: the complete match state and the signature verification success state; When all the results are in the verification pass state, it is determined that the startup image of the system-level chip has passed the verification.

2. The method according to claim 1, characterized in that The using the root public key corresponding to the trusted root in the verification header to perform a signature verification operation on the user public key verification data in the verification header to obtain a third result value includes: Parsing the trust root in the verification header to obtain multiple root public keys; Using each root public key in turn to perform a signature verification operation on the user public key verification data in the verification header to obtain multiple signature verification states; A third result value is determined according to the multiple signature verification states, wherein the signature verification states include: a signature verification failure state and a signature verification success state.

3. The method according to claim 2, characterized in that A failure table is also burned into the system-level chip, and the failure table indicates the failure status through bits; The user public key in the verification header is verified by using each root public key in turn to obtain multiple verification states, including: Reading the revocation table in the system-on-chip to determine the revoked root public key; The user public key in the verification header is verified by using other root public keys that have not expired in turn.

4. The method according to claim 1, characterized in that The method further comprises: Determine the current image verification data according to the hash value of each of the startup images and the user private key; Use the root private key corresponding to the predetermined administrator to sign the hash value of the user public key to obtain the user public key verification data; The current image verification data, the user public key verification data, the user public key corresponding to the user private key and the trust root are stored in the verification header of the verification data image, and the stored verification data image is added to the image package.

5. The method according to claim 4, characterized in that The determining the current image verification data according to the hash value of each of the startup images and the user private key includes: Obtaining hash values ​​of each of the boot images, and aggregating all of the hash values ​​into the verification data image; Calculating the aggregated verification data image to obtain a first hash value of the verification data image; Use the user private key to sign the first hash value; The current image verification data is generated according to the first hash value and the signature corresponding to the signature operation.

6. The method according to any one of claims 1 to 5, characterized in that The verification data mirror also includes: the serial number of the root key to be invalidated; After determining that the boot image verification of the system-level chip passes, the method further includes: Obtaining the serial number of the root key to be invalidated from the verification data image; Determine whether the root key to be invalidated is in an invalid state in the invalidation table burned in the system-level chip; In the case of not being in expired state, modify the bit of the serial number of the to-be-expired root key at the corresponding position in the expiration table.

7. The method according to claim 6, characterized in that The step of determining whether the root key to be invalidated is already in an invalid state in the invalidation table burned in the system-level chip includes: Determine whether the serial number of the root key to be invalidated is the same as the serial number of the root key used by the mirror package that has currently passed the verification; In the case where the serial numbers are different, it is determined whether the root key to be invalidated is already in an invalid state in the invalidation table burned in the system-on-chip.

8. A system-on-chip verification device for a startup image, characterized in that: A root of trust is burned into a one-time editable memory of the system-level chip, wherein the root of trust includes each root public key of a plurality of root keys, and each of the root public keys is arranged in a predetermined order; The verification device comprises: A loading module, configured to load a startup image and a verification data image signed by a predetermined administrator's corresponding root private key in response to a startup operation of the system-level chip, wherein the verification data image includes a verification header, and the verification header includes: current image verification data, user public key verification data, user public key, and a trusted root; A first result determination module, configured to calculate a hash value of each boot image, and match the obtained hash value of each boot image with the hash value of each boot image stored in the verification data image to obtain a first result value; A second result determination module is used to calculate the hash value of the verification data image, and use the user public key in the verification header to perform a signature verification operation on the hash value of the verification data image to obtain a second result value; A third result determination module is used to perform a signature verification operation on the user public key verification data in the verification header using the root public key corresponding to the trusted root in the verification header to obtain a third result value; A fourth result determination module, used for matching the trust root in the verification header with the trust root burned into the system-level chip, to obtain a fourth result value; A detection module, used to detect whether all result values ​​are in a verification pass state, wherein all result values ​​include: a first result value, a second result value, a third result value, and a fourth result value, and the verification pass state includes: a complete match state and a signature verification success state; The result output module is used to determine that the startup image verification of the system-level chip has passed when all the results are in the verification pass state.

9. A chip storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

10. An electronic device, comprising at least a memory and a processor, wherein a computer program is stored in the memory, wherein: The processor implements the steps of the method of any one of claims 1 to 7 when executing the computer program on the memory.

Images