Firmware secure boot method

Abstract

The application relates to a firmware security starting method, which comprises the following steps: obtaining a boot program image and corresponding metadata, performing a same-time national secret SM3 operation to obtain an integrity digest; performing national secret SM2 signature verification on a first signature and a second signature by using a first trust domain public key and a second trust domain public key respectively, and passing the boot program image to perform after verification; extending the integrity digest to an image measurement register of a trusted password module as a measurement value; generating a signature verification strategy state vector according to a signature verification threshold judgment result, extending a national secret SM3 digest of the signature verification strategy state vector to a strategy measurement register; and in response to a challenge random number of a remote verifier, signing values of the two measurement registers and the challenge random number by a trusted password module with a proof private key to generate an integrity proof and report the integrity proof. The application makes the passed boot program image and the reported image be the same object, and enables a remote end to distinguish a strategy state of signature verification and passing.

Description

Technical Field

[0001] This application relates to the field of trusted computing technology, and in particular to a firmware secure boot method. Background Technology

[0002] Embedded devices and industrial control equipment are widely used in critical sectors such as power, transportation, and energy. The firmware of these devices carries the boot process and core control logic, and its integrity directly affects device operational security and data trustworthiness. If malicious code is injected into or tampered with in the bootloader or operating system kernel during the boot process, attackers can gain control at the lowest level of device operation, and such tampering is difficult to detect in upper-layer applications. Therefore, ensuring that the device is in a trustworthy state at every stage from power-on to business operation, and enabling the device's true boot state to be verified by a remote management platform, has become an urgent requirement for security protection of devices in critical sectors. In domestically developed scenarios, this also needs to be achieved based on national cryptographic algorithms.

[0003] Existing trusted protection typically includes two types of mechanisms. One is secure boot, which uses a hardware root of trust as the starting point of the trust chain and performs digital signature verification step by step on the firmware, bootloader, and operating system from the bottom up. Only after successful verification is the next step allowed to proceed. Some schemes further introduce dual signatures or multiple key pairs to enhance the trustworthiness of the image source. The other type is trusted measurement and remote verification, which calculates a measurement value for the firmware during boot or operation and stores it in a trusted module. Then, the measurement value is signed and sent to a remote verification server for comparison with a benchmark value to determine whether the firmware has been tampered with.

[0004] However, these two mechanisms are fragmented and fail to meet the remote end's need to verify the actual boot status of the device. Because the signature verification for secure boot is only used for local release decisions and the results are usually not presented to the remote end, the remote end cannot confirm whether the release was achieved through complete multi-party authorized signature verification or under conditions of missing signatures from one party or a downgraded situation where a recovery key is enabled. Furthermore, measurement and remote proof only report firmware measurement values, which the remote end can only use to determine if the measurement value matches the baseline value, without knowing the status of the signature verification policy on which the release was based. Also, because signature verification and measurement target different objects, the image may be replaced after signature verification and release but before measurement reporting, meaning the measurement results received by the remote end may not correspond to the actually released image. Therefore, the remote end cannot simultaneously confirm in a single proof that the released image and the image reported by measurement are the same object, and also confirm the status of the signature verification policy on which the release was based. Summary of the Invention

[0005] To enable remote authenticators to confirm in a single verification that the image allowed for execution is the same object as the image reported by the measurement, and to confirm the status of the verification and signature policy on which the release is based, this application provides a firmware secure boot method.

[0006] Firstly, this application provides a firmware secure boot method, which adopts the following technical solution: A firmware secure boot method includes the following steps: S1. Obtain the bootloader image and corresponding metadata, and perform the same SM3 operation on the bootloader image and metadata to obtain the integrity digest; S2. Based on the integrity digest, the first signature is verified using the first trust domain public key and the second signature is verified using the second trust domain public key respectively using the national cryptographic SM2 signature verification. In response to the successful verification of both the first and second signatures, the bootstrap image is allowed to be executed. S3. Extend the integrity digest as a metric of the bootstrap image to the image metric register of the trusted cryptographic module; S4. Generate a signature verification policy state vector based on the signature verification threshold determination result, and extend the national cryptographic SM3 digest of the signature verification policy state vector to the policy measurement register of the trusted cryptographic module; S5. In response to the challenge random number issued by the remote verifier, use the proof private key residing in the trusted cryptographic module to perform SM2 signature on the proof message containing the value of the mirror metric register, the value of the policy metric register and the challenge random number, generate an integrity proof and report it.

[0007] By adopting the above technical solution, the same integrity digest is used both for SM2 signature verification and release, and as the measurement value of the mirror measurement register, so that the released mirror and the measured and reported mirror are constrained to be the same object; the double signature threshold judgment result is constructed as a signature verification policy state vector and extended to the policy measurement register, and then the trusted cryptographic module uses the proof private key to sign the values ​​of the two measurement registers together with the challenge random number to generate an integrity proof, so that the remote verifier can confirm the measured mirror in one proof, and can distinguish whether the release has passed both signatures or whether it has been downgraded or the key has been recovered based on the signature verification policy state vector.

[0008] Optionally, the first trust domain is the firmware supplier, and the first signature is used to characterize the authenticity of the bootloader image source; the second trust domain is the deployment operator, and the second signature is used to characterize the deployment authorization of the bootloader image; the public keys of the first trust domain and the second trust domain are respectively anchored by hardware trust roots; the signature threshold defaults to requiring both the first and second signatures to pass verification, and can be configured to require at least two of the first, second, and third signatures to pass verification, with the third signature issued by an offline recovery key.

[0009] By adopting the above technical solution, the authenticity of the source and the authorization of deployment are placed in two independent trust domains, so that the leakage of the private key of either trust domain is insufficient to pass the signature verification alone, and a controlled degradation channel is provided for anomalies such as key loss with a configurable recovery key threshold.

[0010] Optionally, the metadata includes the policy identifier of the bootloader image, and the integrity digest is the digest value obtained by performing a national cryptographic SM3 operation on the bootloader image and metadata in sequence; the integrity digest used for national cryptographic SM2 verification and the measurement value extended to the image measurement register are the same digest value, so that the byte sequence on which national cryptographic SM2 verification is based and the byte sequence extended to the image measurement register are the same sequence.

[0011] By adopting the above technical solution, the verification object and the measurement object are forcibly bound at the digest level, eliminating the risk that the bootloader image may be replaced after verification and before measurement and reporting, but still pass the measurement comparison.

[0012] Optionally, the hardware trust root stores the national cryptographic SM3 digest of the root public key in a one-time programmable storage area, and uses the hardware trust root as the starting point of the trust chain. Starting from the hardware trust root, the trust chain sequentially performs prior verification and allows the firmware, boot program image and operating system kernel, and sequentially extends the national cryptographic SM3 digests of the firmware, boot program image and operating system kernel to the image measurement register.

[0013] By adopting the above technical solution, trust is passed from the hardware root of trust to the kernel step by step, so that the execution of each step is based on the verification and signature of the previous step, and the measurement values ​​of each step are accumulated in the image measurement register for integrity proof overlay.

[0014] Optionally, the signature verification policy state vector includes the presence and pass status of the first and second signatures, whether the signature threshold is met, and the flags indicating whether the recovery key is enabled, as well as the policy version number; the integrity proof is obtained by performing a national cryptographic SM2 signature on the proof message obtained by sequentially concatenating the value of the mirror metric register, the value of the policy metric register, and the challenge random number using the proof private key; the metric log records the order in which the metric values ​​at each level are extended to the mirror metric register and the signature verification policy state vector.

[0015] By adopting the above technical solution, the signature verification strategy state vector can represent the presence and pass status of each signature and the activation status of the recovery key in a fine-grained manner, and provide a basis for remote verifiers to replay and verify the measurement values ​​at all levels through the measurement log.

[0016] Optionally, the signature verification policy state vector is generated by the trusted cryptographic module during the execution of the national cryptographic SM2 signature verification, rather than being calculated by firmware outside the trusted cryptographic module and written into the policy metric register.

[0017] By adopting the above technical solution, the signature verification strategy state vector becomes an inseparable byproduct of the signature verification process, thus avoiding firmware forgery of signature verification strategy state vectors that do not match the actual signature verification results.

[0018] Optionally, the extension of the national cryptographic SM2 signature verification and signature verification policy state vector to the policy metric register is completed by the trusted cryptographic module within a single uninterruptible command; firmware other than the trusted cryptographic module only provides the bootloader image, first signature, second signature, first trust domain public key and second trust domain public key to the trusted cryptographic module and receives the signature verification result, and does not have the authority to extend to the policy metric register.

[0019] By adopting the above technical solution, signature verification and policy state extension are bound to the same atomic command, making it impossible for the firmware to intervene and tamper between signature verification and extension, and further ensuring that the contents of the policy measurement register are consistent with the actual signature verification result.

[0020] Optionally, the metadata includes a monotonic version number and a rollback prevention lower limit value for the trusted cryptographic module; the rollback prevention lower limit value is updated to the monotonic version number only when the judgment result generated by the trusted cryptographic module in this round of signature verification is that all signatures have passed, and the monotonic version number is higher than the current value of the rollback prevention lower limit value; in response to the monotonic version number being lower than the current value of the rollback prevention lower limit value, the bootloader image is rejected.

[0021] By adopting the above technical solution, the anti-rollback counter step is placed in a clean state where both signatures have passed, so that the startup after downgrading or restoration will not endorse the old version image, thus blocking the attack path of implementing version rollback through the downgrading channel.

[0022] Optionally, a proof session can be maintained between multiple rounds of integrity proof reporting; within the proof session, only the increment of the signature verification policy state vector relative to the previous round and the metrics that have changed relative to the previous round in the mirror metric register are reported, instead of reporting all metric values ​​in each round.

[0023] By adopting the above technical solution, the amount of data reported for multiple rounds of proof can be reduced while maintaining remote verifiability, thereby reducing the transmission and processing overhead of the proof channel.

[0024] Optionally, within the rotation window of the second trust domain public key, the signature verification strategy state vector records a time-bounded transition state. The transition state indicates that the bootstrap image has passed the joint verification by the second trust domain public key before rotation and the rotation authority public key. The signature verification strategy state vector recording the transition state is included in the integrity proof and reported.

[0025] By adopting the above technical solution, a time-bounded and remotely verifiable transition trust file is provided for the key rotation of the deployment operator, so that the release during the rotation period can be identified by the remote end as a transitional state, and will not be mistakenly judged as a downgraded release.

[0026] Optionally, after the signature integrity verification is passed, the remote verification party replays the verification mirror measurement register value based on the measurement log to verify that it is consistent with the baseline value, and distinguishes three trust states based on the signature verification policy state vector: clean double signature passed, downgraded access granted, and recovery key access granted, and makes access control and service authorization decisions accordingly.

[0027] By adopting the above technical solution, the trusted state of the device startup is used as the basis for remote access and authorization determination, enabling authorization decisions to distinguish devices with different trust levels.

[0028] Optionally, after the bootloader image is released, the national cryptographic SM3 measurement is periodically re-executed on key runtime components, and the updated verification policy state vector is included in the integrity proof report.

[0029] By adopting the above technical solution, the proof of trusted state is extended from the startup phase to the runtime phase, so that tampering that occurs during the runtime can also be detected remotely in a timely manner.

[0030] Optionally, in response to downgraded release via the offline recovery key, the bootloader image is placed in an isolated environment and powered on again after alarms and repairs.

[0031] By adopting the above technical solutions, a controlled, isolated operation and repair path is provided for degraded release, avoiding direct access of devices in a degraded state to normal services.

[0032] Optionally, it can be proven that the private key is generated in real time through key derivation based on the response of a physically unclonable function within the trusted cryptographic module for each signature, and is not stored for a long period of time.

[0033] By adopting the above technical solution, the proof private key is not stored in a fixed form for a long period of time, reducing the risk of forging integrity proof after the private key is extracted.

[0034] Optionally, the private keys of the first trust domain key and the second trust domain key are kept separately by the firmware supplier and the deployment operator, and the confidentiality level of the first trust domain private key is higher than that of the second trust domain private key.

[0035] By adopting the above technical solution, the private keys of the two trust domains are stored by different entities, reducing the impact of a single entity's private key leakage on the overall trust chain.

[0036] In summary, this application includes at least one of the following beneficial technical effects: 1. By using the same integrity digest of the bootloader image for both dual-signature verification and release and the measurement value expansion of the image measurement register, and by incorporating the verification policy state vector and the image measurement value into the integrity proof for the remote verifier, the remote verifier can confirm in one proof that the image to be released for execution and the image reported by the measurement are the same object, and distinguish the verification policy state in which the image is released.

[0037] 2. By constraining the signature verification policy state vector to an indivisible byproduct produced by the trusted cryptographic module during the signature verification process, and extending and binding it to the same atomic command as the signature verification, firmware outside the trusted cryptographic module cannot forge a signature verification policy state that does not match the actual signature verification result, thus ensuring the credibility of the policy state obtained by the remote verifier.

[0038] 3. By setting the step of the monotonic counter to a clean state where both signatures have passed, and providing a time-bound credible transition period for key rotation, the startup that has been downgraded or restored does not endorse the old version image, and the release during key rotation can be identified remotely without being misjudged as downgrade, thus covering the credibility requirements in operation and maintenance scenarios such as key anomalies and version rollback. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of the overall process of the firmware secure boot method in one embodiment of this application.

[0040] Figure 2 This is a schematic diagram of the trusted boot and remote verification system structure involved in the firmware secure boot method in one embodiment of this application.

[0041] Figure 3 This is a schematic diagram of the remote verification interaction timing of the firmware secure boot method in one embodiment of this application. Detailed Implementation

[0042] The present application will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the application and are not intended to limit the scope of the application.

[0043] This application discloses a firmware secure boot method. This method is applied to the security control of devices equipped with a trusted cryptographic module during the firmware boot phase and supports the device in proving its boot status to a remote authenticator. Taking a power terminal as an example, its firmware is signed by the firmware supplier and the deployment operator respectively during factory manufacturing and deployment. After power-on, the device reports its boot status to a remote management platform to accept access control. The bootloader image is the program image to be loaded and executed in the firmware boot chain; the trusted cryptographic module is a secure component within the device, independent of the main processor, providing national cryptographic operations and measurement registers; the image measurement register is used to accumulate and record the measurement values ​​of the loaded object in an extended manner; the policy measurement register is used to record the execution status of the signature verification policy in an extended manner; and the signature verification policy state vector is a data structure representing the execution result of this signature verification policy.

[0044] This method allows the same integrity digest to be used for both dual-trust domain signature verification and image measurement, and it solidifies the signature verification threshold judgment result into a policy state that can be remotely proven. This enables the remote verifier to confirm the same-source binding between the allowed image and the measured image, as well as the execution status of the signature verification policy, in a single proof. First, the same integrity digest is calculated for the bootstrap image and its metadata, and then verified and released using the public keys of both trust domains. Next, this integrity digest is extended to the image measurement register. Then, a signature verification policy state vector is generated based on the signature verification threshold judgment result, and its digest is extended to the policy measurement register. Finally, in response to the challenge from the remote verifier, the values ​​of the two measurement registers, along with the challenge random number, are signed to generate an integrity proof and reported. The main process described above is as follows: Figure 1 As shown. Therefore, compared to the situation where the remote verifier can only determine whether the metric value of the loaded image matches the baseline based on the image metric proof, but cannot determine whether the image was released after both parties' signatures were approved or after being downgraded and released via offline recovery key, this method allows the remote verifier to directly distinguish the above release types based on the signature verification policy state vector. The following sections provide a detailed explanation of the terminology conventions, main method flow, generation of the signature verification policy state vector and the specific implementation of remote proof, as well as several optional extensions.

[0045] The terms "first" and "second" in the specification and claims of this application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence; the terms "comprising" and "having" are intended to cover non-exclusive inclusion.

[0046] During the firmware boot process, step S1 is executed to obtain the bootloader image and its corresponding metadata. The same SM3 cryptographic operation is then performed on the bootloader image and metadata to obtain the integrity digest. Let the bootloader image be denoted as... Metadata is Then the complete summary satisfy ,in This indicates byte concatenation in a predetermined order. The objects involved in the operation include the bootloader image itself and relevant fields from the metadata. These are concatenated into a single byte sequence, input into the national standard SM3 algorithm, and iteratively compressed to output a 256-bit digest value. Only a single integrity digest is obtained per operation. This summary also serves as a common input for subsequent dual-trust domain signature verification and mirroring measurement.

[0047] Specifically, the aforementioned metadata includes a policy identifier for the bootloader image. This policy identifier may include fields such as image version information, applicable platform identifier, and policy category. The integrity digest is the digest value obtained by performing a single SM3 operation on the bootloader image and the metadata containing the policy identifier in sequence. In some implementations, the bootloader image and metadata are concatenated into a single byte sequence and then a single SM3 operation is performed. Compared to performing SM3 operations on the bootloader image and metadata separately and then merging them, this allows the policy identifier in the metadata and the image itself to be bound to the same digest value, so that any change to either one is reflected in the change of this digest value.

[0048] After obtaining the integrity digest, step S2 is executed. Based on the integrity digest, the first signature is verified using the first trust domain public key, and the second signature is verified using the second trust domain public key using the national cryptographic standard SM2. If both the first and second signatures pass verification, the bootloader image execution is allowed. Let the first trust domain public key and the second trust domain public key be denoted as follows: , The first signature and the second signature are respectively , Then the verification result , If and only if Allow the bootloader image to execute at that time. and If any of the values ​​is not 1, the signature verification is deemed unsuccessful, and the loading and execution of the bootloader image is aborted.

[0049] In one optional implementation, the first trust domain is the firmware supplier, and the first signature is used to characterize the authenticity of the bootloader image's origin; the second trust domain is the deployment operator, and the second signature is used to characterize the deployment authorization of the bootloader image; the public keys of the first and second trust domains are respectively anchored through hardware trust roots, and the trusted cryptographic module verifies the certificate chain or public key digest of the first and second trust domain public keys submitted by the firmware based on the root public key digest embedded in the one-time programmable storage area, and only performs SM2 signature verification with the public key after the verification is passed; in other implementations, the trusted cryptographic module only accepts trusted public key handles that have been registered internally, and the firmware cannot replace the trusted public key with any public key it submits. The signature threshold defaults to requiring both the first and second signatures to pass verification, and can be configured to require at least two of the first, second, and third signatures to pass verification, with the third signature issued by an offline recovery key. For example, under the default threshold, both the first and second signatures must pass verification; when configured with a threshold of at least two of the three signatures passing, if one of the online signatures from both parties is missing, the third signature issued by the offline recovery key can make up the threshold.

[0050] Metadata can also include a monotonic version number, which increments unidirectionally after each legitimate firmware update. If the monotonic version number in the metadata of the bootloader image to be loaded is lower than the current value of the monotonic counter maintained by the trusted cryptographic module, the bootloader image is rejected. Thus, even if an older version image still has a valid signature, it will be rejected because its version number is lower than the current counter value, thereby preventing the device from being rolled back to a known defective older version.

[0051] In other embodiments, in response to downgraded release via the offline recovery key, the bootloader image is placed in an isolated environment for execution, and then powered on again after alarms and repairs. The isolated environment can be implemented through restricted network access, sandbox operation, etc., so that the downgraded released image cannot obtain full running permissions until the repair is complete.

[0052] The private keys of the first trust domain key and the second trust domain key can optionally be kept separately by the firmware supplier and the deployment operator. The first trust domain private key is kept in an offline hardware security module or an offline environment, while the second trust domain private key is kept in an online hardware security module, so that the first trust domain private key is distinguished from the second trust domain private key representing deployment authorization in terms of storage environment.

[0053] After the signature verification is successful and the request is granted, step S3 is executed. The integrity digest is used as the measurement value of the bootstrap image and extended to the image measurement register of the trusted cryptographic module. The extension operation of the image measurement register involves reading the current value of the register, concatenating the current value with the current measurement value in sequence, performing a national cryptographic SM3 operation, and writing the result back to the register. ,in This is the value of the mirror metric register. The mirror metric register has a defined initial value when the device starts up, and each expansion accumulates in the order of loading, so that the final value of the register reflects the loaded objects and their loading order.

[0054] In some implementations, the integrity digest used for SM2 signature verification and the metric value extended to the mirror metric register are the same digest value, ensuring that the byte sequence used for SM2 signature verification and the byte sequence extended to the mirror metric register are the same sequence. That is, the digest H used by the signature verification stage to determine whether to allow access and the metric value extended to the mirror metric register by the metric stage are both derived from the same SM3 operation; they are not calculated separately. If the signature verification and metric are based on their respective calculated digests, they may point to different objects due to their different values; that is, the digest used for signature verification and the digest extended by the metric are obtained from different operations and lack mandatory consistency constraints. However, under the same-origin constraint, the digest used for signature verification and the metric value extended to the mirror metric register are both derived from the same SM3 operation, and they will not point to different objects due to separate calculations. It should be noted that the same-origin constraint guarantees that the signature verification and metric are derived from the same byte sequence; for the case where the image is replaced in the execution buffer after signature verification but before image loading and execution, the object-level atomic binding described below provides further constraints. Compared to calculating the signature digest and metric digest separately for the bootstrap image and then associating them by reference, the same-origin constraint uses a single digest value to simultaneously carry both the signature and metric, eliminating the need for additional consistency checks and removing inconsistency windows caused by separate values ​​for the signature and metric. As an alternative implementation, some methods may calculate the signature digest and metric digest separately for the bootstrap image and record their correspondence in the metadata using pointers; however, this implementation requires additional maintenance and verification of this correspondence, and its resistance to substitution depends on the integrity of the correspondence itself.

[0055] As an optional implementation, the bootstrap image's SM3 measurement, SM2 signature verification, and loading execution are bound to operations targeting the same immutable buffer or the same protected object handle. That is, after the buffer is locked to be immutable, the SM3 measurement and SM2 signature verification are performed on it before loading and execution, ensuring that the measured, verified, and loaded objects are the same locked object. Compared to merely constraining the signature and measurement to be taken from the same digest, this object-level binding further eliminates the window of replacing the image in the execution buffer after signature verification but before loading and execution.

[0056] As an optional implementation, the hardware root of trust stores the SM3 hash of the root public key in a one-time programmable storage area, and uses the hardware root of trust as the starting point of the trust chain. Starting from the hardware root of trust, the trust chain sequentially performs verification and signing on the firmware, bootloader image, and operating system kernel before allowing them to proceed, and sequentially extends the SM3 hashes of the firmware, bootloader image, and operating system kernel to the image metric register. Because the root public key hash is stored in a one-time programmable storage area and cannot be rewritten, each level of the trust chain loads the next level only after verification and signing is successful. The metric values ​​of each level accumulate in the image metric register in the loading order, ensuring that the integrity of each level of the boot chain is reflected in the final value of the image metric register.

[0057] After the bootloader image is released, the national cryptographic SM3 measurement can be periodically re-executed on key runtime components. The measurement values ​​of the runtime components are extended to independent runtime measurement registers or image measurement registers, and the corresponding measurement events are recorded in the measurement log. The verification policy state vector is only updated when the verification policy actually changes. Compared to measuring only during the startup phase, periodic runtime measurement can include the state changes of key components during operation after release in the scope of proof, so that the state information obtained by the remote verifier is not limited to the state at the startup time.

[0058] Based on the aforementioned signature verification and release, step S4 is executed. A signature verification policy state vector is generated according to the threshold determination result of the signature verification, and the national cryptographic SM3 digest of the signature verification policy state vector is extended to the policy measurement register of the trusted cryptographic module. The signature verification policy state vector is mapped from the threshold determination result of this signature verification, recording the signature verification status and threshold satisfaction status of each signature in this verification. For example, in a clean release scenario where both parties' signatures pass, the signature verification policy state vector records that both the first and second signatures are present and pass, the threshold is satisfied, and the recovery key is not enabled. However, in a recovery release scenario where one of the two online signatures is missing and the threshold is supplemented by an offline recovery key, the signature verification policy state vector records that the recovery key is enabled, and the presence and pass status of the corresponding signature are different from those in a clean release. Extending the digest of the signature verification policy state vector to a policy measurement register independent of the mirror measurement register allows the execution status of the signature verification policy and the measurement of the loaded object to be placed in different registers, thus enabling them to be retrieved and judged separately in remote proof. As an alternative implementation, the status of the signature verification policy can also be incorporated into the mirror measurement register for expansion; however, this implementation mixes the policy status and the mirror measurement in the same register value, making it difficult for the remote verification party to separate and determine the two. Therefore, in scenarios where it is necessary to separately confirm the mirror origin and the signature verification policy status, it is easier for the remote end to distinguish between them by setting separate policy measurement registers.

[0059] In some implementations, the signature verification policy state vector includes the presence and pass status of the first and second signatures, whether the signature threshold is met, and a flag indicating whether the recovery key is enabled, as well as a policy version number. When configured with a threshold of at least two of the three signatures passing, the signature verification policy state vector also includes the presence and pass status of the third signature, as well as the key identifier and key version of the offline recovery key used, and provides corresponding state vector values ​​according to different threshold modes. Specifically, the presence status indicates whether the corresponding signature is submitted with the bootloader image; the pass status indicates whether the corresponding signature has passed the SM2 verification; the threshold meeting indicates whether the current signature verification has reached the configured signature threshold; the flag indicating whether the recovery key is enabled indicates whether the current release is participated in by the offline recovery key; and the policy version number indicates the version of the policy configuration applicable to this signature verification.

[0060] The signature verification policy state vector can be encoded as a fixed-length bit string. For example, in a clean double-signature release, the presence and pass bits of the first signature are both set to 1, the presence and pass bits of the second signature are both set to 1, the threshold fulfillment bit is set to 1, the recovery key activation bit is set to 0, and several bits carry the policy version number. Combinations of these fields can represent different trust states: both signatures are present and pass, the threshold is met, and the recovery key is not activated, indicating a clean double-signature release; the recovery key is activated and the threshold is filled by it, indicating a restored release; the threshold not being met indicates that the release does not meet the policy requirements. As an alternative implementation, a single flag bit can be used to record whether the entire signature verification passed; however, this coarse-grained recording cannot distinguish the specific path taken for the release to the remote verifier, for example, it cannot distinguish between a clean double-signature release and a recovery key release. Therefore, the signature verification policy state vector containing the above fields has stronger discriminative power at the remote end.

[0061] As an implementation to prevent firmware forgery of the signature verification policy state vector, the signature verification policy state vector is generated by the trusted cryptographic module during the execution of the national cryptographic standard SM2 signature verification, rather than being calculated by firmware outside the trusted cryptographic module and written to the policy measurement register. In a normal signature verification process, the trusted cryptographic module generates a signature verification policy state vector reflecting the verification result while completing the national cryptographic standard SM2 signature verification. Both originate from the same execution process, therefore the signature verification policy state vector is consistent with the actual signature verification result. If firmware outside the trusted cryptographic module attempts to construct a signature verification policy state vector that does not match the actual signature verification result, since this vector is not generated by the trusted cryptographic module during the signature verification process, the firmware cannot use it to make the policy measurement register display a corresponding value. Therefore, this forgery cannot be accepted as a valid signature verification policy state by the remote end in remote authentication. As an alternative implementation, the firmware can also calculate the signature verification policy state vector and write it to the policy measurement register after obtaining the signature result; however, in this implementation, the generation of the signature verification policy state vector is separated from the trusted cryptographic module, making it difficult to rule out the possibility of firmware tampering between the signature verification result and the written value.

[0062] Based on the signature verification policy state vector generated by the trusted cryptographic module, the extension of the SM2 signature verification and signature verification policy state vector to the policy measurement register is, in some embodiments, completed by the trusted cryptographic module within a single, uninterruptible command. Firmware outside the trusted cryptographic module only provides the bootloader image, first signature, second signature, first trust domain public key, and second trust domain public key to the trusted cryptographic module and receives the signature verification result; it does not have the authority to extend the policy measurement register. The interface between the firmware and the trusted cryptographic module is limited to submitting the image and signature to be verified, submitting the public keys of the two trust domains, and receiving the signature verification result. The firmware cannot directly perform extensions or writes to the policy measurement register. Because signature verification and extension are completed within a single, uninterruptible command, the firmware cannot intervene and change the value to be extended after signature verification is completed but before extension occurs; if the firmware attempts to insert an operation between the two, it cannot do so because the command is uninterruptible. In contrast, if signature verification and extension are separated into two independently callable operations, a firmware intervention window exists between the two calls. The firmware might change the actual extension to the policy measurement register after successful signature verification. Binding both to a single, uninterruptible command eliminates this window. The structure and data flow between the trusted cryptographic module, firmware, mirror measurement register, and policy measurement register are described above. Figure 2 .

[0063] In addition, there is a lower limit value for preventing rollback in the trusted cryptographic module. The lower limit value is recorded as follows: The version number of the image to be loaded is Only if the judgment result generated by the trusted cryptographic module in this round of signature verification is that the signature verification result meets the preset signature threshold, and Higher than When, execute …Repeatedly launching the same legitimate version will not cause the lower limit to exceed the version number, thus preventing rollback to the old version while also preventing the legitimate version from being mistakenly rejected due to the accumulation of launch counts.

[0064] After completing the mirror measurement and signature verification policy measurement, step S5 is executed. In response to the challenge random number issued by the remote verifier, the proof private key residing in the trusted cryptographic module is used to perform a national cryptographic SM2 signature on the proof message containing the value of the mirror measurement register, the value of the policy measurement register, and the challenge random number, generating an integrity proof and reporting it. The value of the mirror measurement register is recorded as... The value of the policy metric register is The challenge random number is Prove that the private key is The integrity proof is then adopted. For proof message Obtained by executing the SM2 cryptographic standard. In one round of proof, the remote verifier first issues a new challenge random number. The equipment is based on this The integrity proof, along with the values ​​of the two measurement registers, is composed of a proof message, signed, and then reported. The remote verifier then verifies the integrity proof using the corresponding proof public key. Since the challenge random number used in each round of proof is issued in real-time by the remote verifier and is different for each round, replaying an integrity proof from a previous round will be rejected by the remote verifier because the challenge random number in that round does not match the current round. In contrast, if the integrity proof only includes the value of the mirror measurement register and not the value of the policy measurement register, the remote verifier can only confirm the integrity of the measured mirror image, but cannot confirm the verification policy status applicable to this approval. Including the value of the policy measurement register in the proof message allows the remote verifier to obtain both mirror measurement and verification policy status information in the same proof.

[0065] Specifically, the integrity proof is obtained by performing a national cryptographic standard SM2 signature on the proof message obtained by sequentially concatenating the values ​​of the mirror metric register, the policy metric register, and the challenge random number using the proof private key. A metric log is maintained to record the order in which each level of metric value is extended to the mirror metric register, as well as the signature verification policy state vector. After verifying the integrity proof, the remote verifier can recalculate each level of metric value according to the recorded extension order in the metric log, verify the value of the mirror metric register, and determine the policy state for this release based on the signature verification policy state vector recorded in the metric log.

[0066] Between multiple rounds of integrity proof reporting, a proof session can be maintained. Within a proof session, only the increment of the signature verification policy state vector relative to the previous round, and the metrics that have changed relative to the previous round in the mirror metric register, are reported, rather than reporting all metric values ​​in each round. For example, in a multi-round proof where the device state is relatively stable, if the signature verification policy state vector and each metric have not changed relative to the previous round, then only a small amount of incremental information needs to be reported in that round instead of all metric values, thereby reducing the cumulative amount of reported data and the processing load at the remote end across multiple rounds of proof.

[0067] Within the rotation window of the second trust domain public key, the signature verification policy state vector records time-bounded transition states. These transition states indicate that the bootstrap image has passed verification by both the pre-rotation second trust domain public key and the rotation authority public key. The signature verification policy state vector recording the transition states is included in the integrity proof and reported. For example, during the replacement of the second trust domain public key, if the device, in a transition state, requires the bootstrap image to pass verification by both the pre-rotation second trust domain public key and the rotation authority public key, the remote verification party, based on the transition state recorded in the signature verification policy state vector, can identify this release as a public key rotation transition rather than release after a recovery key supplementation threshold. Furthermore, this transition state has a time limit and is no longer applicable after the time limit expires.

[0068] After the signature integrity verification is successful, the remote authenticator, based on the reported measurement log, recalculates the measurement values ​​at each level according to the recorded expansion order and verifies that the values ​​of the mirror measurement registers are consistent with the baseline values. It also recalculates the SM3 digest of the signature verification policy state vector recorded in the measurement log, recalculates the value of the policy measurement register according to the expansion method of the policy measurement register, and compares it with the value of the signed policy measurement register in the integrity verification. If the values ​​of the mirror measurement register and the policy measurement register are consistent, the signature verification policy state vector is accepted, and it is used to distinguish between two trust states: clean double-signature verification and access granted after recovery key completion threshold. Based on this, access control and service authorization decisions are made. For example, the remote authenticator grants full access and service permissions to devices that have passed clean double-signature verification, while restricting the permissions of devices granted access after recovery key completion threshold completion or requiring prior repair. This differentiated access control is implemented based on the trust state distinguished by the signature verification policy state vector. The above proof interaction and remote judgment timing between the device and the remote authenticator are as follows: Figure 3 .

[0069] The proof private key can be optionally generated in real-time based on the response of the Physically Unclonable Function (PUF) within the Trusted Cryptographic Module (TCM) during each signing, instead of being stored long-term. Compared to storing the proof private key permanently in the device, the method of deriving the proof private key in real-time based on the response of the PUF each time makes it not persistent in a static form, thereby reducing the possibility of it being read and extracted.

[0070] The same or similar parts in the various embodiments of this application may be referred to each other; the technical features of each embodiment may be combined to form new embodiments without conflicting with each other.

[0071] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A firmware secure boot method, characterized in that, Includes the following steps: S1. Obtain the bootloader image and the metadata corresponding to the bootloader image, and perform the same SM3 operation on the bootloader image and the metadata to obtain the integrity digest; S2. Based on the integrity digest, the first signature is verified using the first trust domain public key and the second signature is verified using the second trust domain public key respectively using the national cryptographic SM2. In response to the verification results of the first signature and the second signature satisfying the preset signature threshold, the execution of the bootstrap image is allowed. S3. Extend the integrity digest as a metric of the bootstrap image to the image metric register of the trusted cryptographic module; S4. Generate a signature verification policy state vector based on the signature threshold determination result, and extend the national cryptographic SM3 digest of the signature verification policy state vector to the policy measurement register of the trusted cryptographic module; S5. In response to the challenge random number issued by the remote verifier, the verifier uses the proof private key securely held internally by the trusted cryptographic module or derived from the trusted cryptographic module to perform SM2 signature on the proof message containing the value of the mirror metric register, the value of the policy metric register and the challenge random number, generates an integrity proof and reports it. The metadata includes the policy identifier of the bootloader image, and the integrity digest is the digest value obtained by performing the national cryptographic SM3 operation once after sequentially concatenating the bootloader image and the metadata. The integrity digest used for the national cryptographic SM2 signature verification and the metric value extended to the mirror metric register are the same digest value, so that the byte sequence on which the national cryptographic SM2 signature verification is based and the byte sequence extended to the mirror metric register are the same sequence; The first trust domain is the firmware supplier, and the first signature is used to characterize the authenticity of the bootloader image's source; the second trust domain is the deployment operator, and the second signature is used to characterize the deployment authorization of the bootloader image; the public keys of the first and second trust domains are respectively anchored by hardware trust roots; the signature threshold defaults to requiring both the first and second signatures to pass verification, and can be configured to require at least two of the first, second, and third signatures to pass verification, with the third signature issued by an offline recovery key; the verification policy state vector includes the presence and pass status of the first and second signatures, whether the signature threshold is met, a flag indicating whether the recovery key is enabled, the recovery key version, and the policy version number; the integrity proof is obtained by performing a national cryptographic SM2 signature on the proof message obtained by sequentially concatenating the value of the image metric register, the value of the policy metric register, and the challenge random number using the proof private key; a metric log is maintained, which records the order in which metric values ​​at each level are extended to the image metric register and the verification policy state vector.

2. The firmware secure boot method according to claim 1, characterized in that, The signature verification policy state vector is generated by the trusted cryptographic module during the execution of the national cryptographic SM2 signature verification, rather than being calculated by firmware outside the trusted cryptographic module and written into the policy measurement register.

3. The firmware secure boot method according to claim 2, characterized in that, The SM2 signature verification and the extension of the signature verification policy state vector to the policy metric register are completed by the trusted cryptographic module within a single, uninterruptible command. Firmware other than the trusted cryptographic module only provides the bootloader image, the metadata, the first signature, the second signature, the first trust domain public key and the second trust domain public key to the trusted cryptographic module and receives the signature verification result, and does not have the permission to extend to the policy metric register.

4. The firmware secure boot method according to claim 1, characterized in that, The metadata includes a monotonic version number, and the trusted cryptographic module maintains a rollback prevention lower limit value. Only when the trusted cryptographic module's current signature verification result is that both the first signature and the second signature have passed verification, and the monotonic version number is higher than the current value of the rollback prevention lower limit value, is the rollback prevention lower limit value updated to the monotonic version number. In response to the monotonic version number being lower than the current value of the rollback prevention lower limit value, the bootloader image is denied release.

5. The firmware secure boot method according to claim 1, characterized in that, The proof session is maintained between multiple rounds of reporting of the integrity proof; within the proof session, only the increment of the signature verification policy state vector relative to the previous round and the newly added measurement events in the measurement log relative to the previous round are reported, instead of reporting all measurement values ​​in each round, and the national cryptographic SM2 signature is still performed on the current complete value of the mirror measurement register in each round.

6. The firmware secure boot method according to claim 1, characterized in that, Within the rotation window of the second trust domain public key, the signature verification policy state vector records time-bounded transition states. The transition state indicates that the bootstrap image has passed the signature verification of the second trust domain public key before rotation, and the rotation authorization signature has passed the signature verification of the rotation authority public key. The rotation authorization signature is issued by the private key corresponding to the rotation authority public key to a rotation authorization token containing the identifier of the second trust domain public key after rotation and the bootstrap image. The signature verification policy state vector recording the transition state is included as an independent trust file in the integrity proof and reported.

Images