An industrial mainboard security booting method based on hardware root of trust

Abstract

The application relates to the technical field of mainboards, in particular to an industrial mainboard security starting method based on a hardware root of trust, which comprises the following steps: after the industrial mainboard is powered on and reset, a security control domain runs prior to a business processing domain, and a main processor is kept waiting for starting; the security control domain reads hardware root anchor credentials and an initial boot program, and sequentially performs integrity measurement and signature verification on the initial boot program and a later-stage boot program; after the verification passes, running key materials are derived based on a random seed, device private credentials and a later-stage boot program digest, a running private key is written into a restricted key area, and a running public key is written into a public storage area; when a boot update package exists, a firmware public key certificate, a boot image signature and a replacement identifier are verified, a boot image is loaded after the certificate is valid and the signature passes, starting proof information is generated, an access path is closed and the main processor is released; any verification failure enters a fault processing flow.

Description

Technical Field

[0001] This invention relates to the field of motherboard technology, and in particular to a secure boot method for industrial motherboards based on a hardware root of trust. Background Technology

[0002] Industrial motherboards typically serve as core control components in industrial control equipment, edge computing devices, and dedicated terminal devices. Their boot phase requires loading a bootloader, system firmware, and related control programs. Due to the characteristics of industrial field equipment—long operating cycles, infrequent updates and maintenance, dispersed deployment environments, and numerous external interfaces—if the bootloader or firmware is tampered with before loading, the main processor may execute abnormal code without the user's knowledge, affecting device control logic, data reliability, and subsequent communication security. Existing secure boot solutions largely rely on software-level verification or fixed public key verification. While these can verify firmware origins to some extent, they still have shortcomings in root credential isolation, pre-boot trust measurement, runtime key protection, and management of historical credential invalidation after certificate replacement. When signature credentials need to be reissued or firmware requires long-term maintenance, the lack of a boot control mechanism combined with a hardware root of trust can easily lead to problems such as the reuse of old credentials, bypassing of the boot chain, or sensitive keys being read by business-side programs. This makes it difficult to meet the requirements of secure boot and trusted updates for industrial motherboards in long-term service scenarios. Summary of the Invention

[0003] In view of the above technical problems, the present invention provides a secure boot method for industrial motherboards based on hardware root of trust, which solves the problems of unreliable verification of boot source, lack of hardware isolation protection for running key, and difficulty in timely invalidation of historical certificates after firmware certificate replacement during the power-on boot and boot update process of industrial motherboards.

[0004] Other features and advantages of the invention will become apparent from the following detailed description, or may be learned in part by practice of the invention.

[0005] According to one aspect of the present invention, a secure boot method for an industrial motherboard based on a hardware root of trust is proposed. The method is applied to an industrial motherboard, which includes a security control domain, a service processing domain, an immutable storage area, a restricted key area, a common storage area, a unidirectional incrementing counter area, a hardware random source, a key derivation unit, and a cryptographic execution unit. The service processing domain includes a main processor. The security control domain and the service processing domain are connected via a unidirectional master access relationship. This unidirectional master access relationship allows the security control domain to write boot data to the service processing domain and prevents the service processing domain from reading security data within the security control domain. The method includes: After the industrial motherboard is powered on and reset, the main processor is kept in a waiting startup state, and the security control domain runs before the business processing domain. The security control domain reads the hardware root anchor credentials and the initial bootloader from the immutable storage area. The hardware root anchor credentials include root verification material for verifying the trusted source of the boot and device private credentials for characterizing the identity of the industrial motherboard. The security control domain performs integrity measurement and signature verification on the initial bootloader based on the hardware root anchor credentials, and after the initial bootloader passes the verification, the initial bootloader performs integrity measurement and signature verification on the subsequent bootloader to be started. The security control domain calls the hardware random source to generate a random seed, and calls the key derivation unit to perform derivation processing on the random seed, the device private credentials, and the digest of the post-boot program that has passed the integrity measurement, to generate the running key material used for this startup. The running key material includes a running private key and a running public key. The security control domain writes the private key to the restricted key area, which is only accessible to the cryptographic execution unit, and writes the public key to the public storage area, which is readable by the business processing domain. When a boot update package exists, the security control domain parses the boot update package to obtain a firmware public key certificate, update descriptor metadata, boot image, and boot image signature. The firmware public key certificate is used to provide firmware verification materials for verifying the boot image signature, and the update descriptor metadata is used to limit the loading conditions and scope of application of the boot image. The security control domain performs chain verification on the firmware public key certificate based on the root verification material in the immutable storage area, and determines whether the firmware public key certificate is in a valid state based on the replacement identifier in the firmware public key certificate and the state of the unidirectional incrementing counter area. When the firmware public key certificate is in a valid state, the security control domain verifies the boot image signature based on the firmware verification material in the firmware public key certificate, and after the boot image signature verification is passed, loads the verified boot image into the startup storage area of ​​the business processing domain. The security control domain uses the running private key in the restricted key area to sign the metric value of the boot image, generate boot proof information corresponding to this boot, and write the boot proof information into the public storage area; The security control domain clears the temporary keys, intermediate metrics and execution stack data generated during the startup process, closes the access path of the business processing domain to the internal storage area and cryptographic peripherals of the security control domain, and releases the main processor, enabling the main processor to continue startup based on the boot image in the startup storage area. If any of the following verifications fails: the initial bootloader, the subsequent bootloader, the firmware public key certificate, or the boot image signature, the security control domain will stop releasing the main processor and enter the fault handling process.

[0006] Furthermore, the security control domain includes an isolation controller, which controls the pre-startup, verification scheduling, key writing, proof generation, and access path closure of the security control domain; the security data includes the hardware root anchor credential, the initial bootloader, the running private key in the restricted key area, the temporary key, and the intermediate metric.

[0007] Furthermore, the hardware root anchor credential includes a manufacturing root public key, an issuing authority certificate, and a device private credential written into the immutable storage area. The manufacturing root private key is not stored in the industrial motherboard. The security control domain verifies the signature of the initial boot program using the manufacturing root public key, verifies the issuing source of the firmware public key certificate using the issuing authority certificate, and signs the running public key using the device private credential to form a device boot certificate corresponding to the industrial motherboard.

[0008] Furthermore, the hardware random source completes random sampling, entropy aggregation, and state reset within the security control domain. The key derivation unit uses the random seed, the device private credentials, and the digest of the subsequent boot program that has passed the integrity measurement as derivation inputs to generate the running key material, so that the same boot program forms different running key materials on different industrial motherboards, and the same industrial motherboard forms running key materials that change with the boot state during different boot processes.

[0009] Furthermore, the restricted key area is a storage area that is written in one direction and cannot be read by the general instructions of the business processing domain and the security control domain. When signing the startup proof information, the cryptographic execution unit calls the running private key in the restricted key area in a handle manner.

[0010] Furthermore, the replacement identifier is a certificate version identifier that increments unidirectionally with certificate reissue. The security control domain accepts the firmware public key certificate when the firmware public key certificate is verified and the replacement identifier is not lower than the recorded state of the unidirectionally incrementing count area, and updates the unidirectionally incrementing count area when the replacement identifier is higher than the recorded state, so that historical public key certificates that are lower than the updated state become invalid in subsequent startups.

[0011] Furthermore, the boot update package includes several boot segments, a segment signature corresponding to the boot segment, the firmware public key certificate, and the update description meta information. The update description meta information records the loading location, dependencies, allowed version range, and signing entity identifier of the boot segment. The security control domain verifies the boot segment segment by segment according to the update description meta information, and determines the boot image to be loaded after all the boot segments to be started have passed the verification.

[0012] Furthermore, the firmware public key certificate carries a cryptographic algorithm identifier and a purpose identifier. The security control domain selects the corresponding cryptographic execution unit to complete the signature verification based on the cryptographic algorithm identifier, and limits the firmware public key certificate to be used for the corresponding objects in the bootloader, system firmware, and application firmware based on the purpose identifier.

[0013] Furthermore, the fault handling process includes recording the cause of failure, keeping the main processor waiting, rolling back to the most recently verified boot image, and refusing to restart using the historical public key certificate that has been marked as invalid by the one-way incrementing counter area.

[0014] The technical solution of the present invention has the following beneficial effects: This invention establishes a trusted boot foundation for the industrial motherboard before business operation by running the security control domain prior to the business processing domain and verifying the bootloader, firmware public key certificate, and boot image signature before the main processor is released. This reduces the risk of direct execution by tampered firmware. It improves the isolation between the root credential and the boot verification process by storing the hardware root anchor credential in an immutable storage area and restricting the business processing domain from reading back security data from the security control domain using a one-way master control access relationship. It derives the running key material used for this boot from the hardware random source, device private credentials, and verified boot content, and restricts the running private key to a limited key area for use by the cryptographic execution unit. This allows the boot proof information to be associated with the specific industrial motherboard and the current boot state, reducing the risk of the running private key being read or reused by the software side. Finally, through chain verification of the firmware public key certificate, replacement identifier judgment, and one-way incrementing counter management, it ensures that historical public key certificates after certificate renewal become invalid in subsequent boots, enhancing the security of credential replacement during long-term firmware maintenance and boot update processes. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating a secure boot method for an industrial motherboard based on a hardware root of trust, as described in the embodiments of this specification. Detailed Implementation

[0016] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make the invention more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a full understanding of embodiments of the invention. However, those skilled in the art will recognize that the technical solutions of the invention may be practiced with one or more of these specific details omitted, or other methods, components, apparatus, steps, etc., may be employed. In other instances, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of the invention.

[0017] Furthermore, the accompanying drawings are merely illustrative of the invention. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0018] This invention provides a secure boot method for an industrial motherboard based on a hardware root of trust. The method is applied to an industrial motherboard, which includes a security control domain, a business processing domain, an immutable storage area, a restricted key area, a common storage area, a one-way incrementing counter area, a hardware random source, a key derivation unit, and a cryptographic execution unit. The business processing domain includes a main processor. The security control domain and the business processing domain are connected via a one-way master access relationship. This one-way master access relationship allows the security control domain to write boot data to the business processing domain and prevents the business processing domain from reading secure data within the security control domain. Specifically, the security control domain includes an isolation controller, which controls the pre-boot, verification scheduling, key writing, proof generation, and access path closure of the security control domain. Secure data includes hardware root anchor credentials, an initial bootloader, phased verification data in the restricted key area, and temporary derived data.

[0019] An industrial motherboard can be a main control board used in industrial control equipment, edge computing devices, dedicated communication equipment, or other industrial terminal equipment. After power-on, it needs to complete the trusted loading of the boot program and system firmware before the service processing side can enter normal operation. To prevent the service processing side from directly executing unverified boot content before the boot verification is completed, this embodiment divides the industrial motherboard into a security control domain and a service processing domain. The service processing domain includes a main processor for running the boot program, system firmware, and service programs, while the security control domain is used to perform boot control, trusted verification, key generation, and access isolation processing before the main processor starts.

[0020] The industrial motherboard also includes an immutable storage area, a restricted key area, a common storage area, a one-way incrementing counter area, a hardware random source, a key derivation unit, and a cryptographic execution unit. The immutable storage area stores basic startup data that cannot be modified by the business processing domain during the power-on startup phase. This basic startup data includes the hardware root anchor credentials and the initial bootloader. The restricted key area stores key data that can only be accessed by the cryptographic execution unit. The common storage area stores startup data, the runtime public key, and startup proof information that are allowed to be read by the business processing domain. The one-way incrementing counter area records the replacement status of the firmware public key certificate, ensuring that historical certificates with statuses lower than the recorded status cannot continue to be valid credentials in subsequent startups. The hardware random source generates a random seed for key derivation in this startup process. The key derivation unit combines the random seed, device identity-related credentials, and verified boot content to generate runtime key material. The cryptographic execution unit performs digest calculations, signature verification, certificate verification, and startup proof signing.

[0021] The security control domain and the business processing domain are connected via a one-way master access relationship. This one-way master access relationship means that during the startup control process, the security control domain can write verified startup data to the business processing domain and can write the runtime public key, startup proof information, or verified boot image to a readable location within the business processing domain. Conversely, the business processing domain cannot read back security data from within the security control domain, nor can it directly read root trust data in the immutable storage area, key data in the restricted key area, or the internal execution state of the cryptographic execution unit. Therefore, after the business processing domain is released from operation, sensitive content within the security control domain cannot be obtained through ordinary memory access, peripheral access, or software commands.

[0022] The security control domain specifically includes an isolation controller, which controls the pre-boot, verification scheduling, key writing, proof generation, and access path closure of the security control domain. Specifically, after the industrial motherboard powers on and resets, the isolation controller enters the working state before the main processor and keeps the main processor in a waiting-to-boot state. During the boot verification process, the isolation controller schedules the immutable storage area, hardware random source, key derivation unit, and cryptographic execution unit to complete root credential reading, bootloader measurement, signature verification, runtime key generation, certificate status judgment, and boot proof generation. After the verified boot image is written to the business processing domain, the isolation controller closes the business processing domain's access paths to the internal storage area and cryptographic peripherals of the security control domain and releases the main processor to continue booting.

[0023] Security data includes hardware root anchor credentials, the initial bootloader, the runtime private key written to the restricted key area, phased verification data, and temporary derived data. The hardware root anchor credentials establish the root trust foundation for the industrial motherboard boot process. The initial bootloader initiates subsequent boot verifications within the security control domain. The runtime private key is used to sign the boot image metric for this boot. Phased verification data may include digest results, signature verification results, and status judgment results generated during bootloader metric, certificate chain verification, and boot image signature verification. Temporary derived data may include data generated from the hardware random source, device private credentials, and bootloader digest but not stored as long-term credentials. This security data is managed by the security control domain during the boot process; the business processing domain cannot read or modify this security data.

[0024] Reference Figure 1 The diagram shown is a flowchart illustrating a secure boot method for an industrial motherboard based on a hardware root of trust, according to an embodiment of the present invention. Specifically, the method may include the following steps S101-S111.

[0025] In step S101, after the industrial motherboard is powered on and reset, the main processor is kept in the waiting startup state, and the security control domain runs before the business processing domain.

[0026] After the industrial motherboard is powered on and reset, the security control domain first acquires boot control. The main processor in the business processing domain does not immediately execute the boot content in the boot memory area, but remains in a waiting boot state. The waiting boot state can be achieved through one or more of the following methods: reset hold, boot permission bit locking, clock enable control, and instruction fetch path blocking. This prevents the main processor from actively reading the boot image or executing program code from external storage or the boot memory area before the security control domain completes subsequent boot verification.

[0027] The security control domain operates prior to the business processing domain. This means that when the industrial motherboard resets, the isolation controller enters the working state before the main processor and takes over the control flow during the startup phase. During this phase, the isolation controller establishes the basic operating environment within the security control domain, ensuring that the immutable memory area, hardware random source, key derivation unit, cryptographic execution unit, restricted key area, public memory area, and unidirectional incrementing counter area are in a callable state, while maintaining the business processing domain's access blockade to secure data within the security control domain. This process ensures that subsequent hardware root anchor credential reading, initial bootloader verification, runtime key material generation, and boot image loading are all initiated by the security control domain, rather than by ordinary programs in the business processing domain.

[0028] While the main processor remains in the waiting-to-start state, the service processing domain can be in a low-privilege standby state, only receiving start release signals or start data write results from the security control domain, and cannot initiate access requests to read security data from the security control domain. A one-way master access relationship between the security control domain and the service processing domain is established at this stage, enabling the security control domain to write verified start data to the service processing domain in subsequent steps, while restricting the service processing domain from reverse reading of hardware root anchor credentials, phased verification data, temporary derived data, and the runtime private key in the restricted key area.

[0029] Through the above processing, the industrial motherboard establishes a boot sequence dominated by the security control domain at the boot start point, preventing the main processor from executing unconfirmed boot content before the trusted verification is completed, and providing a controlled boot environment for subsequent integrity measurement, signature verification, runtime key derivation and boot proof generation based on hardware root anchor credentials.

[0030] In step S102, the security control domain reads the hardware root anchor credentials and the initial bootloader from the immutable storage area. The hardware root anchor credentials include root verification material for verifying the trusted source of the boot and device private credentials for characterizing the identity of the industrial motherboard.

[0031] The hardware root anchor credentials include the manufacturing root public key, the issuing authority certificate, and the device private credentials written in the immutable storage area. The manufacturing root private key is not stored in the industrial motherboard. The security control domain verifies the signature of the initial boot program through the manufacturing root public key, verifies the issuing source of the firmware public key certificate through the issuing authority certificate, and signs the running public key through the device private credentials to form a device boot certificate corresponding to the industrial motherboard.

[0032] After gaining boot control, the security control domain reads the hardware root anchor credentials and initial boot program from the immutable storage area. The immutable storage area can be implemented using read-only storage, write-once storage, or hardware-protected non-volatile storage. It is used to store basic trusted data that cannot be modified by the business processing domain during the boot phase, ensuring that the industrial motherboard enters the secure boot process with a fixed and verifiable root basis each time it is powered on.

[0033] The hardware root anchor credential serves as the starting point for ensuring the trustworthiness of the industrial motherboard's boot process. It includes root verification materials and device private credentials. The root verification materials determine the trustworthiness of the initial bootloader, firmware public key certificate, and subsequent boot credentials. The device private credentials characterize the industrial motherboard, enabling subsequent generated runtime public keys, device boot certificates, or boot proof information to be bound to this industrial motherboard. By storing the root verification materials and device private credentials in immutable storage, it is possible to prevent the business processing domain from replacing the root foundation data via software during runtime.

[0034] In one implementation, the hardware root anchor credentials include a manufacturing root public key, an issuing authority certificate, and a device private credential. The manufacturing root public key is written to the immutable storage area of ​​the industrial motherboard and used to verify the signature of the initial bootloader. The manufacturing root private key is stored by the manufacturing or issuing side and is not stored within the industrial motherboard itself, thus preventing leakage of the manufacturing root private key if the industrial motherboard is disassembled or the business-side program is compromised. The issuing authority certificate is used to subsequently verify the issuing source of the firmware public key certificate, enabling the firmware public key certificate to form a traceable trust path along the root verification materials. The device private credential represents the device identity of the industrial motherboard and can participate in the signing of the runtime public key to form a device boot certificate corresponding to that industrial motherboard.

[0035] After the security control domain reads the initial bootloader, it does not immediately execute it in the business processing domain. Instead, it uses it as the object for subsequent integrity measurements and signature verification. The initial bootloader is the program closest to the root trust foundation in the boot chain, and its trustworthiness directly affects the verification results of subsequent bootloaders and boot images. Therefore, the purpose of reading the initial bootloader in this step is to provide the object to be verified in subsequent steps, rather than to release the main processor to run the program.

[0036] In step S103, the security control domain performs integrity measurement and signature verification on the initial bootloader based on the hardware root anchor credentials, and after the initial bootloader passes the verification, the initial bootloader performs integrity measurement and signature verification on the subsequent bootloader to be started.

[0037] Among them, integrity measurement can be understood as performing a digest calculation on the program content of the initial bootloader to obtain an initial bootloader digest that can characterize whether the program content has been changed; signature verification can be understood as using the root verification material in the hardware root anchor credential to verify the signature data accompanying the initial bootloader to confirm that the source of the initial bootloader is credible and that the content has not been tampered with.

[0038] In practice, the security control domain can use the isolation controller to schedule the cryptographic execution unit to read the program content of the initial bootloader and perform a digest operation on the program content to obtain the initial bootloader digest. This initial bootloader digest, along with the initial bootloader's signature data, participates in signature verification. If the signature verification passes, it indicates that a trusted connection has been established between the initial bootloader and the hardware root anchor credential, and the security control domain allows the initial bootloader to proceed to subsequent verification processes. If the signature verification fails, it indicates that the initial bootloader may have an abnormal source or its content may have been altered; the security control domain will not release the main processor and will proceed to the fault handling process.

[0039] After the initial bootloader passes verification, it performs integrity measurements and signature verification on the subsequent bootloaders to be loaded. The subsequent bootloaders can be the next stage bootloader used to load the boot image, system firmware, or boot manager. The initial bootloader performs a digest calculation on the subsequent bootloader to obtain its digest, and verifies the signature data of the subsequent bootloader based on the established trusted boot relationship. Through this process, the boot process is initiated from the hardware root anchor credentials to the initial bootloader, and then from the initial bootloader to the subsequent bootloaders, forming a hierarchical boot trust chain.

[0040] In this embodiment, the post-boot program digest is not only used to determine whether the post-boot program has been tampered with, but can also serve as one of the inputs for deriving subsequent runtime key materials. Since the post-boot program digest changes with the program content, its digest result will change when the post-boot program is replaced, damaged, or maliciously modified, and the subsequently generated runtime key materials will also change accordingly. This prevents the tampered post-boot program from using the runtime key materials from normal startup.

[0041] In step S104, the security control domain calls the hardware random source to generate a random seed, and calls the key derivation unit to derive the random seed, device private credentials, and digest of the post-boot program that has passed the integrity measurement, to generate the running key material used for this startup. The running key material includes the running private key and the running public key.

[0042] The hardware random source completes random sampling, entropy aggregation, and state reset within the security control domain. The key derivation unit uses a random seed, device private credentials, and a digest of the subsequent boot program that has passed integrity measurement as derivation inputs to generate runtime key material. This allows the same boot program to generate different runtime key material on different industrial motherboards, and also allows the same industrial motherboard to generate runtime key material that changes with the boot state during different boot processes.

[0043] After the subsequent bootloader has passed integrity measurement and signature verification, the security control domain calls the hardware random source to generate a random seed and calls the key derivation unit to generate the runtime key material used for this boot. The runtime key material includes a runtime private key and a runtime public key. The runtime private key is used for signing subsequent boot verification information, and the runtime public key is used for subsequent verification of boot verification information or for generating a device boot certificate.

[0044] The random seed is only used in the generation of the runtime key material during this startup process and is not stored as a fixed, long-term credential. The hardware random source performs a state reset after the random seed is output, so that the current random sampling state is not used in subsequent startup processes, thereby avoiding the use of the same random basis to generate the same runtime key material in different startup processes.

[0045] The random seed is used to introduce uncertainty into the startup process, the device private credentials are used to introduce the device identity attributes of the industrial motherboard, and the post-boot program digest is used to introduce the integrity status of the verified startup content. The post-boot program digest is the digest result obtained by performing integrity measurement on the post-boot program in step S103. Therefore, when the content of the post-boot program changes, the derived input changes accordingly, and the generated runtime key material also changes accordingly.

[0046] In one implementation, the key derivation unit can concatenate or combine a random seed, device private credentials, and a post-bootstrap digest in a preset order and input them into the cryptographic execution unit. The cryptographic execution unit then performs digest operations or curve key generation operations to obtain the running private key and the running public key. This process can be represented as follows: Krun=KDF Rseed,Dpriv,Hboot Here, Krun represents the runtime key material, Rseed represents the random seed, Dpriv represents the device private credentials, Hboot represents the post-boot digest, and KDF represents key derivation processing. Krun includes the runtime private key and the runtime public key.

[0047] Through the above processing, even if different industrial motherboards load the same back-end bootloader, the generated runtime key materials will be different due to the different device private credentials. Similarly, even if the same industrial motherboard loads the same back-end bootloader multiple times, the generated runtime key materials will change with the boot state because the hardware random source generates different random seeds during different boot processes. The runtime key materials are generated by the security control domain; the business processing domain cannot participate in this derivation process, nor can it read the runtime private key during the key generation stage. This provides a key basis for the subsequent generation of boot proof information, associated with the device identity, boot content, and the current boot state.

[0048] In step S105, the security control domain writes the private key to a restricted key area that can only be accessed by the cryptographic execution unit, and writes the public key to a public storage area that can be read by the business processing domain.

[0049] The restricted key area is a one-way write storage area that cannot be read by general instructions from the business processing domain and the security control domain. When signing the startup proof information, the cryptographic execution unit calls the running private key in the restricted key area in the form of a handle.

[0050] Specifically, the private key is written to the restricted key area, and the public key is written to the public storage area. This process is used to ensure that the private and public keys are managed separately during the startup phase. The private key is only used as an internal calling object of the cryptographic execution unit, while the public key serves as verification material or certificate formation material that can be read by the business processing domain.

[0051] The restricted key area is used to store key data that cannot be directly read by ordinary programs. After the runtime private key is written to the restricted key area, the business processing domain cannot read the runtime private key through memory access instructions, peripheral access, or debugging interfaces, and the general instructions in the security control domain cannot directly read the plaintext of the runtime private key. This restricted key area can be implemented using a one-way write method, that is, the security control domain can write the runtime private key to the restricted key area, but after writing, it can only be used by the cryptographic execution unit according to preset calling rules and cannot be read out as ordinary data.

[0052] When generating startup proof information, the cryptographic execution unit does not directly output the running private key. Instead, it invokes the running private key in the restricted key area using a handle. The handle method means that the cryptographic execution unit locates the running private key through a key index, key identifier, or internal call number, and performs the signing operation internally; the outside only obtains the signing result. Therefore, the running private key does not leave the restricted key area during startup proof generation, nor is it exposed to the business processing domain.

[0053] Once the public key is written to the public storage area, it can be read by the business processing domain. The data stored in the public storage area does not contain the plaintext of the private key; its purpose is to provide the business processing domain with public verification materials corresponding to this boot. The business processing domain can subsequently read the public key, device boot certificate, or boot proof information to verify the correspondence between the boot image loaded during this boot, the identity of the industrial motherboard, and the boot status.

[0054] Through the above processing, the private key and public key are isolated in terms of storage and access permissions. The private key is kept in the restricted key area of ​​the security control domain and can only be called by the cryptographic execution unit, while the public key is put into the public storage area for the business processing domain to read. This ensures that subsequent startup proofs can be verified while preventing the private key from being read or reused by business-side programs.

[0055] In step S106, when a boot update package exists, the security control domain parses the boot update package to obtain the firmware public key certificate, update descriptor metadata, boot image, and boot image signature. The firmware public key certificate is used to provide firmware verification materials for verifying the boot image signature, and the update descriptor metadata is used to limit the loading conditions and scope of application of the boot image.

[0056] The boot update package includes several boot segments, segment signatures corresponding to the boot segments, firmware public key certificates, and update description metadata. The update description metadata records the loading location, dependencies, allowed version range, and signer identifier of the boot segments. The security control domain verifies the boot segments segment by segment according to the update description metadata, and determines the boot image to be loaded after all boot segments to be started have passed the verification.

[0057] When the security control domain detects the existence of a boot update package, it parses the package to obtain the firmware public key certificate, update descriptor metadata, boot image, and boot image signature. The boot update package carries the boot content to be updated or loaded, along with its verification materials. The firmware public key certificate carries firmware verification materials used to verify the boot image signature; the update descriptor metadata defines the loading conditions, scope of application, and fragment organization of the boot image; and the boot image signature proves the source and integrity of the boot image.

[0058] The boot update package may include several boot segments, segment signatures corresponding to each boot segment, firmware public key certificates, and update descriptor metadata. Boot segments are the building blocks of the boot image and can correspond to different boot function segments, configuration segments, or program segments. Segment signatures are used to independently verify the corresponding boot segments, enabling the security control domain to detect replaced or corrupted segments before loading the complete boot image. Update descriptor metadata records the loading location, dependencies, allowed version range, and signing entity identifier of each boot segment, allowing the security control domain to determine whether the boot segments can be assembled into the boot image to be loaded in a predetermined order and position.

[0059] After parsing the boot update package, the security control domain determines the verification order and loading relationship of each boot segment according to the update description metadata, and calls the cryptographic execution unit to perform digest calculation and segment signature verification on each boot segment. If the segment signature verification passes, it means that the content of the corresponding boot segment matches the signing result; if the segment signature verification fails, it means that the corresponding boot segment has abnormal content or an abnormal source, and the security control domain will no longer use that boot segment in subsequent boot image formation. This segment-by-segment verification method can avoid the problems of missing local segment replacements, incorrect segment order, or dependency mismatches that occur when only verifying at the overall image level.

[0060] The load location in the update description metadata is used to determine the target location when the boot fragment is written to the boot storage area or assembled into a boot image. Dependencies are used to determine the sequence and calling relationships between boot fragments. The allowed version range is used to determine whether the boot fragment matches the current industrial motherboard's boot environment. The signing entity identifier is used to determine whether the boot fragment was signed by an authorized signing entity. The security control domain only determines a boot fragment as valid if its fragment signature, load location, dependencies, allowed version range, and signing entity identifier all meet the limitations of the update description metadata.

[0061] After all boot segments awaiting startup have passed verification, the security control domain determines the boot image to be loaded based on the updated descriptor metadata. At this point, determining the boot image to be loaded only indicates that the verification and combination conditions at the boot segment level have been met. Further steps require combining the validity of the firmware public key certificate and the boot image signature verification result to determine whether the boot image can be written to the startup storage area of ​​the business processing domain. This process establishes a consistent verification relationship between the certificate materials, descriptor information, segment content, and the overall image in the boot update package, providing a foundation for subsequent certificate status judgment and boot image signature verification.

[0062] In step S107, the security control domain performs chain verification on the firmware public key certificate based on the root verification material in the immutable storage area, and determines whether the firmware public key certificate is in a valid state based on the replacement identifier in the firmware public key certificate and the state of the unidirectional incrementing counter area.

[0063] The replacement identifier is a certificate version identifier that increments unidirectionally with the certificate renewal. The security control domain accepts the firmware public key certificate when the firmware public key certificate is verified and the replacement identifier is not lower than the recorded state of the unidirectionally incrementing count area. When the replacement identifier is higher than the recorded state, the unidirectionally incrementing count area is updated, so that historical public key certificates that are lower than the updated state become invalid in subsequent startups.

[0064] The firmware public key certificate carries a cryptographic algorithm identifier and a purpose identifier. The security control domain selects the corresponding cryptographic execution unit to complete the signature verification based on the cryptographic algorithm identifier, and limits the firmware public key certificate to the corresponding objects in the bootloader, system firmware, and application firmware based on the purpose identifier.

[0065] The security control domain performs chain-like verification of the firmware public key certificate's issuance source and integrity based on the root verification material in the immutable storage area. It also reads the replacement identifier from the firmware public key certificate and compares it with the recorded state in the one-way incrementing counter to determine if the firmware public key certificate is still valid as a verification credential for this boot. The replacement identifier indicates the order in which the firmware public key certificate was issued. If the firmware public key certificate verification passes and the replacement identifier is not lower than the recorded state in the one-way incrementing counter, the security control domain accepts the firmware public key certificate. If the replacement identifier is higher than the recorded state, the security control domain updates the one-way incrementing counter, invalidating historical public key certificates with a lower state in subsequent boots, preventing replaced certificates from being reused for verifying older boot content. The firmware public key certificate can also carry a cryptographic algorithm identifier and a purpose identifier. The security control domain calls the matching cryptographic execution unit to complete the signature verification based on the cryptographic algorithm identifier and restricts the firmware public key certificate to be used only for the corresponding boot program, system firmware, or application firmware verification based on the purpose identifier, thereby preventing certificates for different purposes from being used interchangeably.

[0066] In step S108, when the firmware public key certificate is in a valid state, the security control domain verifies the boot image signature based on the firmware verification material in the firmware public key certificate, and loads the verified boot image into the startup storage area of ​​the business processing domain after the boot image signature verification passes.

[0067] After the firmware public key certificate has passed chain verification and been deemed valid, the security control domain retrieves the firmware verification material from the firmware public key certificate and uses this material to verify the boot image signature. The firmware verification material can be public key data or verification parameters corresponding to the public key. Its purpose is to confirm whether the boot image has been signed by a trusted signing entity and to confirm that the boot image has not been replaced or modified after signing. The security control domain can invoke a cryptographic execution unit that matches the cryptographic algorithm identifier in the firmware public key certificate to perform a digest calculation on the boot image and complete the signature verification process by combining the boot image signature and the firmware verification material. If the signature verification passes, it indicates that the boot image's source and integrity meet the startup requirements; if the signature verification fails, it indicates that the boot image has an abnormal source or content, and the security control domain will not load the boot image into the startup storage area of ​​the business processing domain.

[0068] After the boot image signature verification is successful, the security control domain writes the verified boot image to the boot storage area of ​​the business processing domain. The boot storage area is used for instruction fetching and loading boot content after the main processor is released. This loading process is executed by the security control domain. The business processing domain cannot write to or replace the boot image before the loading is complete, thus ensuring that the boot content executed by the main processor subsequently is consistent with the boot image verified by the security control domain.

[0069] In step S109, the security control domain uses the running private key in the restricted key area to sign the measurement value of the boot image, generate boot proof information corresponding to this boot, and write the boot proof information into the public storage area.

[0070] After the boot image signature verification is successful, the security control domain performs an integrity measurement on the boot image to obtain a boot image metric value. The boot image metric value is used to characterize the state of the boot image content loaded into the boot storage area. When the program content, configuration content, or fragment combination relationship of the boot image changes, the corresponding metric value also changes.

[0071] The security control domain invokes the cryptographic execution unit and uses the runtime private key in the restricted key area as a handle to sign the boot image metric, generating boot proof information corresponding to this boot. The runtime private key is not read from the restricted key area during the signing process; the invocation and signing operations are only completed internally by the cryptographic execution unit. Therefore, the business processing domain cannot obtain the plaintext of the runtime private key.

[0072] The boot verification information is used to record the status of the boot image that has passed verification during this boot, and to establish a verification relationship with the public key corresponding to the private key. Since the private key is derived from the random seed, the device's private credentials, and the digest of the subsequent boot program, the boot verification information can simultaneously associate the industrial motherboard identity, the current boot status, and the content of the loaded boot image.

[0073] The security control domain writes the boot verification information to the public storage area, enabling the business processing domain to read the boot verification information and the running public key during subsequent operation, and thereby confirm that the boot image in the boot storage area has been verified and signed by the security control domain. This process does not change the loading result of the boot image itself, but only provides verifiable proof data for this boot.

[0074] In step S110, the security control domain clears the temporary key, intermediate metric value and execution stack data generated during the startup process, closes the access path of the business processing domain to the internal storage area and cryptographic peripherals of the security control domain, and releases the main processor, so that the main processor can continue to start based on the boot image in the startup storage area.

[0075] After completing the boot image loading and writing of startup verification information, the security control domain invalidates the security intermediate data generated during the startup phase and disables the business processing domain's access to the security control domain's internal storage area and cryptographic peripherals. Security intermediate data may include temporary derived data not saved as the runtime private key, interim digest results, certificate verification status, fragment verification status, and signature verification status. Invalidation can be achieved through overwriting, zeroing, status revocation, or prohibiting further invocation to prevent the business processing domain from continuing to access sensitive data from the startup verification phase after it enters runtime.

[0076] Access path closure refers to the security control domain revoking the internal access permissions temporarily granted during the startup verification process, preventing the business processing domain from reading the root trust data in the immutable storage area, the running private key in the restricted key area, and the internal state of the cryptographic execution unit. At this stage, the cryptographic peripherals retain only the normal access capabilities required for business operation, and no longer allow the business processing domain to invoke security functions related to hardware root anchor credentials, running private keys, and startup proof signing.

[0077] After the above processing is completed, the security control domain sends a boot release signal to the main processor, releasing the main processor from its boot waiting state. Once released, the main processor reads the verified boot image from the boot storage area of ​​the service processing domain and continues the subsequent boot process based on this boot image. Thus, the boot content actually executed by the main processor is consistent with the boot image verified and loaded by the security control domain, while security data within the security control domain remains isolated during the service processing domain's runtime phase.

[0078] In step S111, if any of the verifications of the initial bootloader, the subsequent bootloader, the firmware public key certificate, or the boot image signature fails, the security control domain stops releasing the main processor and enters the fault handling process.

[0079] The fault handling process includes logging the cause of failure, keeping the main processor waiting, rolling back to the most recently verified boot image, and refusing to restart using a historical public key certificate that has been marked as invalid by a one-way incrementing counter.

[0080] If any of the verifications of the initial bootloader, subsequent bootloader, firmware public key certificate, boot fragment, or boot image signature fails, the security control domain will not send a boot release signal to the main processor, causing the main processor to remain in a waiting boot state and preventing the business processing domain from executing boot code with abnormal source or content.

[0081] The fault handling process may include recording the failed object, the failed stage, and the failed reason. The failed object can be the initial bootloader, subsequent bootloaders, firmware public key certificates, boot fragments, or boot image signatures. Failure reasons may include digest inconsistencies, signature mismatches, invalid certificate chains, replacement identifiers falling below the unidirectional incrementing counter state, usage identifier mismatches, or unsupported algorithm identifiers. The above failure information can be written to the state area allowed to be recorded in the security control domain for subsequent maintenance and troubleshooting, but it does not change the access restrictions on the running private key in the restricted key area.

[0082] When an industrial motherboard contains a recently verified boot image, the security control domain can roll back to that boot image and re-perform boot verification based on a valid firmware public key certificate. During the rollback process, historical public key certificates that have been marked as invalid by a one-way incrementing counter cannot be reused as verification credentials to avoid recovering replaced or revoked boot content using old certificates.

[0083] When a rollback boot image is unavailable, or a rollback boot image fails verification using the current valid credentials, the security control domain keeps the business processing domain inactive and outputs a boot failure status. This prevents the industrial motherboard from continuing to run when the trusted boot chain is interrupted, ensuring that the system enters a controlled state in the event of boot failure.

[0084] As described in the above embodiments, this invention enables the industrial motherboard to establish a trusted boot foundation before entering business operation by running the security control domain before the business processing domain and completing the verification of the boot program, firmware public key certificate, and boot image signature before the main processor is released. This reduces the risk of direct execution by tampered firmware. By storing the hardware root anchor credentials in an immutable storage area and restricting the business processing domain from reading back security data in the security control domain in combination with a one-way master control access relationship, the isolation between the root credentials and the boot verification process is improved. The running key material used for this boot is derived from the hardware random source, device private credentials, and verified boot content, and the running private key is restricted to the restricted key area for use by the cryptographic execution unit. This allows the boot proof information to be associated with the specific industrial motherboard and the current boot state, reducing the risk of the running private key being read or reused by the software side. Through chain verification, replacement identifier judgment, and one-way incrementing counter area management of the firmware public key certificate, the historical public key certificate after certificate renewal becomes invalid in subsequent boots, enhancing the security of credential replacement during long-term firmware maintenance and boot update processes.

[0085] The above figures are merely illustrative of the processes included in the method according to exemplary embodiments of the present invention and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Furthermore, it is also readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0086] It should be noted that although several modules or units of the system have been mentioned in the detailed description above, this division is not mandatory. In fact, according to exemplary embodiments of the present invention, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0087] Other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of the invention are indicated by the claims.

[0088] It should be understood that the present invention is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A secure boot method for an industrial motherboard based on a hardware root of trust, characterized in that, The method is applied to an industrial motherboard, which includes a security control domain, a business processing domain, an immutable storage area, a restricted key area, a common storage area, a one-way incrementing counter area, a hardware random source, a key derivation unit, and a cryptographic execution unit. The business processing domain includes a main processor. The security control domain and the business processing domain are connected through a one-way master access relationship. This one-way master access relationship allows the security control domain to write startup data to the business processing domain and prevents the business processing domain from reading security data within the security control domain. The method includes: After the industrial motherboard is powered on and reset, the main processor is kept in a waiting startup state, and the security control domain runs before the business processing domain. The security control domain reads the hardware root anchor credentials and the initial bootloader from the immutable storage area. The hardware root anchor credentials include root verification material for verifying the trusted source of the boot and device private credentials for characterizing the identity of the industrial motherboard. The security control domain performs integrity measurement and signature verification on the initial bootloader based on the hardware root anchor credentials, and after the initial bootloader passes the verification, the initial bootloader performs integrity measurement and signature verification on the subsequent bootloader to be started. The security control domain calls the hardware random source to generate a random seed, and calls the key derivation unit to perform derivation processing on the random seed, the device private credentials, and the digest of the post-boot program that has passed the integrity measurement, to generate the running key material used for this startup. The running key material includes a running private key and a running public key. The security control domain writes the private key to the restricted key area, which is only accessible to the cryptographic execution unit, and writes the public key to the public storage area, which is readable by the business processing domain. When a boot update package exists, the security control domain parses the boot update package to obtain a firmware public key certificate, update descriptor metadata, boot image, and boot image signature. The firmware public key certificate is used to provide firmware verification materials for verifying the boot image signature, and the update descriptor metadata is used to limit the loading conditions and scope of application of the boot image. The security control domain performs chain verification on the firmware public key certificate based on the root verification material in the immutable storage area, and determines whether the firmware public key certificate is in a valid state based on the replacement identifier in the firmware public key certificate and the state of the unidirectional incrementing counter area. When the firmware public key certificate is in a valid state, the security control domain verifies the boot image signature based on the firmware verification material in the firmware public key certificate, and after the boot image signature verification is passed, loads the verified boot image into the startup storage area of ​​the business processing domain. The security control domain uses the running private key in the restricted key area to sign the metric value of the boot image, generate boot proof information corresponding to this boot, and write the boot proof information into the public storage area; The security control domain clears the temporary keys, intermediate metrics and execution stack data generated during the startup process, closes the access path of the business processing domain to the internal storage area and cryptographic peripherals of the security control domain, and releases the main processor, enabling the main processor to continue startup based on the boot image in the startup storage area. If any of the following verifications fails: the initial bootloader, the subsequent bootloader, the firmware public key certificate, or the boot image signature, the security control domain will stop releasing the main processor and enter the fault handling process.

2. The industrial motherboard secure boot method based on hardware root of trust according to claim 1, characterized in that, The security control domain includes an isolation controller, which controls the pre-launch, verification scheduling, key writing, proof generation, and access path closure of the security control domain; the security data includes the hardware root anchor credential, the initial bootloader, the running private key in the restricted key area, the temporary key, and the intermediate metric.

3. The industrial motherboard secure boot method based on hardware root of trust according to claim 1, characterized in that, The hardware root anchor credential includes a manufacturing root public key, an issuing authority certificate, and a device private credential written into the immutable storage area. The manufacturing root private key is not stored in the industrial motherboard. The security control domain verifies the signature of the initial boot program using the manufacturing root public key, verifies the issuing source of the firmware public key certificate using the issuing authority certificate, and signs the running public key using the device private credential to form a device boot certificate corresponding to the industrial motherboard.

4. The industrial motherboard secure boot method based on hardware root of trust according to claim 1, characterized in that, The hardware random source completes random sampling, entropy aggregation, and state reset within the security control domain. The key derivation unit uses the random seed, the device private credentials, and the digest of the subsequent boot program that has passed the integrity measurement as derivation input to generate the running key material, so that the same boot program forms different running key materials on different industrial motherboards, and the same industrial motherboard forms running key materials that change with the boot state during different boot processes.

5. The industrial motherboard secure boot method based on hardware root of trust according to claim 1, characterized in that, The restricted key area is a one-way write storage area that cannot be read by the general instructions of the business processing domain and the security control domain. When signing the startup proof information, the cryptographic execution unit calls the running private key in the restricted key area in a handle manner.

6. The industrial motherboard secure boot method based on hardware root of trust according to claim 1, characterized in that, The replacement identifier is a certificate version identifier that increments unidirectionally with certificate renewal. The security control domain accepts the firmware public key certificate when the firmware public key certificate is verified and the replacement identifier is not lower than the recorded state of the unidirectionally incrementing count area. When the replacement identifier is higher than the recorded state, the domain updates the unidirectionally incrementing count area, so that historical public key certificates that are lower than the updated state become invalid in subsequent startups.

7. The industrial motherboard secure boot method based on hardware root of trust according to claim 1, characterized in that, The boot update package includes several boot segments, segment signatures corresponding to the boot segments, the firmware public key certificate, and the update description meta information. The update description meta information records the loading location, dependencies, allowed version range, and signing entity identifier of the boot segments. The security control domain verifies the boot segments segment by segment according to the update description meta information, and determines the boot image to be loaded after all the boot segments to be started have passed the verification.

8. The industrial motherboard secure boot method based on hardware root of trust according to claim 1, characterized in that, The firmware public key certificate carries a cryptographic algorithm identifier and a purpose identifier. The security control domain selects the corresponding cryptographic execution unit to complete the signature verification based on the cryptographic algorithm identifier, and limits the firmware public key certificate to be used for the corresponding objects in the bootloader, system firmware, and application firmware based on the purpose identifier.

9. The industrial motherboard secure boot method based on hardware root of trust according to claim 1, characterized in that, The fault handling process includes recording the cause of failure, keeping the main processor waiting, rolling back to the most recently verified boot image, and refusing to restart using the historical public key certificate that has been marked as invalid by the one-way incrementing counter area.

Images