Trusted boot system and trusted boot method

Abstract

The application discloses a trusted starting system and method, and relates to the technical field of computers, and comprises an access switching module, a starting control module and at least two authentication modules; the authentication modules are connected with each other, each authentication module is connected with a starting device through the access switching module, and each authentication module, the access switching module and the starting device are connected with the starting control module; the access switching module switches the connection state of each authentication module and the starting device; the authentication module generates to-be-verified information according to device information of the starting device, and obtains to-be-verified information of other authentication modules; according to the to-be-verified information and the to-be-verified information of other authentication modules, a preset verification rule is adopted to obtain and output a verification result; and the starting control module generates starting control information according to the verification result, and sends the starting control information to the starting device. The problem that the trusted starting process is time-consuming is solved, the security is ensured, and the starting speed is accelerated.

Description

Technical Field

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

[0002] Trusted booting of a computer system is typically achieved using a Trusted Platform Module (TPM). After power-on, the firmware (such as the Basic Input / Output System) analyzes its own code and key components such as the bootloader and operating system kernel to be loaded later. The hash value obtained from the analysis is then written into the platform configuration register inside the Trusted Platform Module. During this process, the processor needs to interact with the TPM multiple times via the bus to exchange instructions and transmit data. It needs to report and store the analysis results, as well as cooperate with key decapsulation and policy verification operations.

[0003] Due to these interaction steps between the processor and the TPM, the overall process introduces a significant amount of waiting and processing time from power-on to processor release and entry into the operating system, resulting in a longer startup time for the trusted boot process. Summary of the Invention

[0004] This application provides a trusted boot system and a trusted boot method to at least solve the problem of long trusted boot process time in related technologies.

[0005] This application also provides a trusted boot system, including: an access switching module, a boot control module, and at least two authentication modules; wherein, the at least two authentication modules are interconnected, each authentication module is connected to the device to be booted through the access switching module, and each authentication module, access switching module, and device to be booted are connected to the boot control module;

[0006] The access switching module is used to switch the connection status between each authentication module and the device to be started according to the access switching command;

[0007] The authentication module is used to obtain device information of the device to be started, generate verification information based on the device information, and obtain verification information generated by at least one other authentication module.

[0008] The authentication module is also used to obtain and output the verification result based on the verification information generated by itself and the verification information generated by at least one other authentication module, using preset verification rules.

[0009] The startup control module is used to receive verification results, generate startup control information based on multiple verification results, and send the startup control information to the device to be started.

[0010] This application provides a trusted boot method, including:

[0011] Obtain device information of the device to be started, generate verification information based on the device information, and obtain verification information generated by at least one other authentication module;

[0012] Based on the verification information generated by itself and at least one other authentication module, the system uses preset verification rules to obtain and output the verification results.

[0013] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the trusted boot methods described above when executing the computer program.

[0014] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the trusted startup methods described above.

[0015] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the trusted startup methods described above.

[0016] This application achieves a unique mechanism: by sequentially or in turn switching the connection status between each authentication module and the device to be started according to access switching instructions, different authentication modules can physically acquire device information independently. After exchanging or acquiring verification information generated by each other, each authentication module verifies its own results and the results of other authentication modules according to preset verification rules, and outputs the verification results without relying on the conclusions of any single module, thus improving the protection against firmware tampering, single point of failure, and unreasonable replacement. The startup control module makes a comprehensive decision based on the verification results output by multiple authentication modules, generates startup control information according to preset strategies, and controls the device to be started accordingly. This ensures that the device starts only when the authentication results from multiple parties meet the conditions, improving the overall reliability and fault tolerance of the startup process. By implementing device information collection, cross-authentication, and startup control in a layered manner, and by using the access switching module to plan the access sequence of each authentication module, this application, while ensuring reliable firmware verification during startup, changes the long waiting time caused by serial, single-channel verification in traditional schemes, solves the problem of long reliable startup time, and achieves the technical effect of accelerating system power-on startup speed and improving system availability while ensuring security. Attached Figure Description

[0017] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the structure of the trusted boot system provided in the embodiments of this application;

[0019] Figure 2 A schematic diagram of the structure of a trusted boot system based on a dual authentication module provided in an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of the structure implemented using combinational logic circuits, provided in an embodiment of this application.

[0021] Figure 4 This is a schematic diagram of the structure implemented using a start-up control programmable logic controller, as provided in an embodiment of this application.

[0022] Figure 5 A flowchart illustrating the trusted startup method provided in this application embodiment;

[0023] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0025] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0026] To address the technical problem in related technologies where the processor needs to frequently interact with the trusted platform module via the bus and repeatedly wait for responses during multiple rounds of measurement and policy judgment, resulting in a long startup phase from power-on to processor release, the inventive concept of this application is to separate trusted verification from the round-trip interaction link between the processor and the trusted platform module, and construct an independent trusted startup system consisting of an access switching module, a startup control module, and at least two authentication modules. Specifically, at least two interconnected authentication modules no longer rely on the processor to initiate instructions. Instead, after power-on, the access switching module directly establishes an access channel with the device to be started, actively obtains device information, and locally generates information to be verified. At the same time, the authentication modules obtain the information to be verified generated by each other, and then calculate the verification result internally according to preset verification rules. Thus, the measurement, comparison, and policy judgment process, which originally required multiple interactions between the processor and the bus, is moved forward to be completed in parallel or sequentially by multiple independent authentication modules. The startup control module only needs to summarize the verification results output by each authentication module, generate startup control information according to a preset strategy, and directly control the processor reset state and startup path selection.

[0027] This hierarchical structure, consisting of multiple authentication modules, access switching modules, and boot control modules, simplifies the multi-round command interaction between the traditional trusted platform module and the processor into a process of spontaneous verification within the authentication module and processing decisions by the boot control module. This reduces the repeated occupation of the system bus and processor clock cycles from an architectural perspective, solving the problem of long trusted boot time. While ensuring the trustworthiness of the boot firmware, it shortens the overall boot time from power-on to entering the operating system.

[0028] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0029] Figure 1 This is a schematic diagram of the trusted boot system provided in an embodiment of this application. The trusted boot system performs multi-module cross-validation of the device information of the device to be booted before the boot program is loaded, and allows the device to enter the boot process if the validation passes. Figure 1As shown, the trusted boot system includes an access switching module 102, a boot control module 104, and at least two authentication modules 101. A complete trusted boot chain is achieved through the collaboration between these modules. The device to be booted 103 can be any electronic device with a processor and boot firmware storage device, such as a server motherboard, industrial control host, or network device motherboard. Device information may include the boot firmware, configuration parameters, hardware identification information, etc., stored in the device to be booted 103. By setting up at least two authentication modules 101, the same device information can be processed in parallel or sequentially, and mutual verification of results can be achieved through interaction between the authentication modules 101, thus reducing the problems caused by the tampering of a single authentication module 101.

[0030] Each authentication module 101 is connected to the device to be started 103 through an access switching module 102. The access switching module 102 is used to switch the connection status between each authentication module 101 and the device to be started 103 according to the access switching command. The access switching module 102 provides a unified access path between the authentication module 101 and the device to be started 103. It can dynamically adjust which authentication module 101 is currently establishing a data interaction channel with the device to be started 103 according to the access switching command, thereby reducing the number of authentication modules 101 directly occupying the access resources of the device to be started 103 at the same time.

[0031] Specifically, the access switching module 102 adjusts the connection status between each authentication module 101 and the device to be started 103 according to the access switching command sent by the startup control module 104. For example, the access switching command may carry control information such as the target authentication module 101 identifier, access stage identifier, or connection switching conditions, indicating which authentication module 101 should establish communication with the device to be started 103 at the current moment, or under what conditions to switch to another authentication module 101. The access switching module 102 can switch the connection status through multiplexing or bus arbitration. By implementing connection management between the authentication module 101 and the device to be started 103 in the access switching module 102, on the one hand, bus conflicts or resource contention caused by multiple authentication modules 101 simultaneously initiating access requests to the device to be started 103 are reduced; on the other hand, according to the preset timing or strategy of the authentication process, each authentication module 101 can obtain device information in an orderly manner at different stages, thereby ensuring the controllability and traceability of the authentication process.

[0032] At least two authentication modules 101 are interconnected. Authentication module 101 is used to obtain device information of the device 103 to be started, generate verification information based on the device information, and obtain verification information generated by at least one other authentication module 101. Therefore, any authentication module 101 can interact with at least one other authentication module 101 through a preset communication method, so that after generating verification information, it can send its own generated verification information to other authentication modules 101 and receive verification information from other authentication modules 101. Simultaneously, authentication module 101 is also used to obtain and output verification results based on its own generated verification information and the verification information generated by at least one other authentication module 101, using preset verification rules.

[0033] In this embodiment, the authentication module 101 first establishes a connection with the device to be started 103 through the access switching module 102, and reads device information from the device to be started 103 according to preset information acquisition rules. The device information may be boot firmware code, boot configuration files, or register values ​​used to identify hardware status stored in non-volatile memory, and the specific content can be configured according to the type and requirements of the device to be started 103. After obtaining the device information, the authentication module 101 generates verification information based on the device information. By generating the verification information, the original device information is converted into a format suitable for authentication comparison and interactive transmission. By completing device information acquisition and verification information generation within the authentication module 101, the extraction and characterization of boot data from the device to be started 103 are realized, providing a data foundation for subsequent multi-module cross-authentication.

[0034] After generating its own verification information, the authentication module 101 also obtains verification information generated by at least one other authentication module 101 through its connection with other authentication modules 101. This acquisition can include actively requesting verification information from other authentication modules 101, or passively receiving verification information pushed by other authentication modules 101 during preset authentication rounds. After simultaneously holding its own generated verification information and verification information generated by at least one other authentication module 101, the authentication module 101 compares and analyzes this verification information using preset verification rules. These preset verification rules can be rules for determining whether verification data is consistent, rules for comprehensively judging data integrity and rationality, or rules for correlation verification combined with additional information such as timestamps and device identifiers. Through these preset verification rules, the authentication module 101 can determine whether the device information it obtains is consistent with the device information obtained by other authentication modules 101 in content, and whether it has been tampered with or partially missing. By cross-referencing the verification information from multiple authentication modules 101, consistency verification and multi-point verification of the device information of the device to be started 103 are achieved, improving the robustness and anti-attack capability of the authentication process.

[0035] After completing the calculations corresponding to the preset verification rules, the authentication module 101 generates a verification result based on the comparison results and outputs the verification result to the startup control module 104. The verification result may include a pass or fail flag for a certain type of device information, or it may include more detailed status information, such as the verification status of different types of device information, and suspected anomaly indicators. By outputting the verification result, the authentication module 101 reports its local consistency and reasonableness judgments of device information to the startup control module 104 in a unified result format. By outputting structured verification results on the authentication module 101 side, the authentication process and the startup control process are decoupled, so that the startup control module 104 does not need to directly participate in the details of device information collection and verification, simplifying the implementation complexity of startup control.

[0036] Next, each authentication module 101, access switching module 102, and device to be started 103 are connected to the startup control module 104. The startup control module 104 is used to receive verification results, generate startup control information based on multiple verification results, and send the startup control information to the device to be started 103.

[0037] In this embodiment, the startup control module 104 can comprehensively analyze the verification results output by different authentication modules 101. For example, it can determine whether the verification results of all authentication modules 101 for the same type of device information are consistent, or determine the final credibility conclusion according to preset majority voting rules and priority rules. In some embodiments, the startup control module 104 can distinguish different types of verification results and map them to different startup modes or processing strategies. For example, when all authentication modules 101 pass the verification, startup control information allowing normal startup is generated; when some authentication modules 101 pass the verification while others fail, startup control information starting from a backup information source is generated; when all authentication modules 101 fail the verification, startup control information not starting or entering a security fault handling process is generated. In this way, the startup control module 104 converts multiple verification results into startup control information that the device 103 to be started can directly execute.

[0038] After generating startup control information, the startup control module 104 sends the startup control information to the device to be started 103. The device to be started 103 determines whether to enter the startup process and which specific startup path to use based on the startup control information. The startup control information can be sent to the device to be started 103 in the form of control signals, level states, register configurations, or command messages, and is used to control the processor's reset state, the selection of the startup source, and the setting of the startup level. For example, the startup control information can instruct the device to be started 103 to release the processor reset and load the startup program from a specified information source, or it can instruct to keep the processor in a reset state and report security events in the management channel. By uniformly converting the verification results generated by the authentication module 101 into startup control information in the startup control module 104, and having the device to be started 103 execute subsequent actions accordingly, control that links the authentication results with the startup behavior is achieved.

[0039] In one embodiment, the authentication module is further described. The authentication module includes a programmable controller, which may be a programmable logic device. Internally, it includes logic units for implementing authentication logic, storage units for storing configuration data and intermediate calculation results, and interface units for signal interaction with the access switching module and a preset communication interface. Through the programmable controller, authentication-related data acquisition and verification information generation are all completed at the hardware logic level, enabling pre-authentication processing of the device to be started with low latency and high determinism without relying on a general-purpose processor.

[0040] The editable controller connects to the device to be started via an access switching module. After the access switching module establishes a connection based on the access switching command, the editable controller retrieves device information from the device to be started according to a preset information reading process. By utilizing the editable controller within the authentication module to complete the orderly collection of device information, an accurate and traceable data foundation is provided for the subsequent generation of verification information.

[0041] The programmable controller connects to at least one other programmable controller via a pre-defined communication interface. This pre-defined communication interface can be a serial communication interface, a parallel communication interface, or a differential high-speed interface, specifically employing a bus or point-to-point link suitable for board-level communication. Through this pre-defined communication interface, the programmable controller can establish a bidirectional data channel with at least one other programmable controller for exchanging their respective generated verification information during the authentication process. The pre-defined communication interface can be configured with handshake mechanisms, frame formats, error detection codes, and other control information at the physical and link layers, enabling reliable sending and receiving of verification information between programmable controllers at specified stages of the authentication process. By providing a dedicated pre-defined communication interface between programmable controllers, direct communication between authentication modules is achieved, reducing the risk of authentication data being tampered with or intercepted during transmission.

[0042] Based on the above embodiments, the authentication module is specifically used to: obtain device information of the device to be started through the editable controller, generate verification information based on the device information, and obtain verification information of at least one other editable controller through the editable controller.

[0043] In this embodiment, during the generation of verification information, the editable controller can segment the device information, calculate verification values, or add identification fields related to the source of the device information. This ensures that the verification information not only contains the content features of the device information but also includes tags used to distinguish different information sources or different collection times. By generating the verification information internally within the editable controller, the conversion from raw device information to authentication feature data is achieved. This allows the authentication process to complete consistency judgment without directly exposing the original device information, improving the security and flexibility of the authentication process.

[0044] After generating its own verification information, the authentication module also obtains verification information from at least one other editable controller via a preset communication interface through the editable controller. The editable controller can proactively send requests to other editable controllers, or listen for verification information data frames from other editable controllers within a specified time window, and associate the received data with the corresponding other editable controller based on the identifier field. In this way, the authentication module can simultaneously hold its own generated verification information and verification information generated by at least one other authentication module locally, providing a data foundation for subsequent cross-verification.

[0045] Based on the above embodiments, the authentication module is further specifically used to: obtain and output the verification result by using a preset verification rule based on the corresponding verification information of the editable controller and the verification information corresponding to at least one other editable controller.

[0046] In this embodiment, the authentication module, through an editable controller, processes the information to be verified using preset verification rules based on the information source and content to obtain and output verification results. The preset verification rules may include comparison rules for whether the content of the information to be verified is completely consistent, or approximate matching rules within a preset tolerance range. The editable controller can compare or combine the information to be verified from different authentication modules according to the preset verification rules. When all the information to be verified meets the preset consistency conditions, the verification result is set as passed; when inconsistencies or abnormal features are detected among the information to be verified, the verification result is set as failed or abnormal. Subsequently, the editable controller outputs the verification results to the startup control module in the form of a status signal or encoding. By using preset verification rules within the editable controller to uniformly judge the information to be verified from multiple sources, local determination of the reliability of device information is achieved, which helps to improve the fault identification capability of the authentication process without increasing the complexity of the startup control module.

[0047] Furthermore, in one specific embodiment, the authentication module further includes a power supply circuit and a clock signal generation circuit, both of which are connected to the editable controller to provide basic operating conditions for its operation. For example, the power supply circuit may include a voltage conversion unit, a voltage regulation unit, and a filtering unit to convert the input voltage from the system power backplane into a stable DC power supply that conforms to the rated operating voltage of the editable controller, and to suppress the effects of power ripple, transient overshoot, and electromagnetic interference on the operation of the editable controller through filtering and protection measures. The clock signal generation circuit may include a clock source, a level shaping unit, and a frequency multiplier or divider unit to provide a stable operating clock signal for the internal logic operations and timing control of the editable controller. Each authentication module has its own independent power supply circuit and clock signal generation circuit, making the power-on timing and operating clock independent of each other, which helps reduce the impact of a single point of power supply or clock anomaly on multiple authentication modules simultaneously. It should be noted that the power supply circuit and clock signal generation circuit are not specifically limited, as long as they can provide basic operating conditions for the editable controller.

[0048] Based on the above embodiments, the authentication module is further configured to: provide operating power to the editable controller through the power supply circuit, and provide a running clock signal to the editable controller through the clock signal generation circuit; after the editable controller is powered on and started according to the operating power supply and the running clock signal, the editable controller performs an internal self-test according to the built-in self-test program, and after the self-test is passed, obtains and stores a temporary session key corresponding to the editable controller in at least one other authentication module through a preset communication interface according to the key exchange protocol.

[0049] In this embodiment, the built-in self-test program may include steps such as configuration data verification, register initial value checking, internal memory read / write testing, communication interface loopback testing, and integrity checks of key storage-related areas. These steps are used to confirm that the programmable controller is currently in a logical configuration state and that its internal resources are free of significant faults. During the self-test, if corrupted configuration data, abnormal critical registers, or a malfunctioning communication interface are detected, the programmable controller can record the corresponding self-test failure status in its internal status register and reflect this status as abnormal or failed when subsequently outputting authentication results. By executing the built-in self-test program after the programmable controller is powered on, autonomous detection and screening of the internal working state of the authentication module are achieved. This ensures basic hardware reliability for the authentication modules participating in the authentication process and reduces the distortion of authentication results caused by module failures.

[0050] Provided the built-in self-test passes, the programmable controller establishes a secure session channel with other authentication modules via the communication interface. The key exchange protocol can be a key negotiation protocol supporting two-way authentication and session key negotiation, used to generate temporary session keys for use within the current session period between participating authentication modules without transmitting long-term keys in plaintext over the link. During key exchange, the programmable controller can use its stored long-term key materials or identity identifiers to handshake, exchange parameters, and perform protocol calculations with other authentication modules, and calculate a temporary session key valid only for the current session after the protocol ends. After obtaining the temporary session key, at least one temporary session key corresponding to another authentication module is stored in a secure storage area within the programmable controller for subsequent encryption and decryption of the information to be verified. By executing the key exchange protocol after the self-test passes, a secure communication foundation based on temporary session keys is established between authentication modules before participating in authentication data interaction, reducing the direct exposure of long-term keys over the link and ensuring the confidentiality and integrity of subsequent information to be verified.

[0051] In one embodiment, the startup control module is further described below. The startup control module includes a first control device and a second control device. The first control device is connected to the access switching module and is used to control the timing and connection path; each authentication module and the device to be started is connected to the second control device and is used to control the aggregation of verification results and startup decisions.

[0052] Based on the above embodiments, the startup control module is specifically used to: receive the verification results output by each authentication module through the second control device, generate startup control information based on multiple verification results, and send the startup control information to the device to be started.

[0053] In this embodiment, after each authentication module completes the acquisition of device information, the generation of information to be verified, and the consistency judgment under preset verification rules, it outputs the verification results to the second control device in the form of a predefined signal. The second control device can internally allocate independent result input channels for different authentication modules, collect and store the verification results of each module, and uniformly read and process these verification results. By centrally receiving the verification results through the second control device, a complete decision-making basis is provided for the subsequent generation of startup control information.

[0054] Next, the process by which the second control device generates startup control information based on multiple verification results may include identifying authentication failures of different authentication modules and selecting strategies for whether startup is allowed and in what mode. The second control device can have a pre-set set of decision rules. For example, when all authentication modules pass verification, it generates startup control information indicating normal startup; when there are authentication failures, it generates startup control information indicating restricted startup or triggering a security processing flow. The generated startup control information is maintained in the form of logical signals or status indicators and sent to the device to be started via the second control device, allowing the device to adjust its processor reset state, startup path, or startup process accordingly.

[0055] Based on the above embodiments, the start control module is also specifically used to send an access switching instruction carrying the module switching conditions to the access switching module through the first control device.

[0056] In this embodiment, the module switching conditions can be related to the stage of the authentication process, preset time parameters, or the current state of the device to be started. The first control device sets the authentication order, access order, and switching timing according to the preset startup process, and controls the access switching module through an access switching command at an appropriate time to switch the authentication module currently connected to the device to be started to another authentication module, or to switch the access path of the device to be started to the processor after the authentication stage ends. The module switching conditions carried in the access switching command can be used to instruct the access switching module to perform connection switching when it detects a timing condition, an authentication stage completion signal, or other triggering conditions. By uniformly issuing access switching commands to the access switching module by the first control device, the connection switching between the authentication module and the device to be started has clear timing control and logical basis, ensuring that each authentication module has access opportunities and reducing access conflicts and authentication stage errors.

[0057] In one embodiment, the access switching module is further described. The access switching module includes a delay line and a multiplexing unit, used for unified management and controlled switching of the connection relationships between each authentication module and the device to be started at the physical connection layer. The delay line can be understood as a control circuit that performs time-domain processing on the access switching command output by the first control device. By delaying, timing, and triggering the access switching command, the switching timing of the multiplexing unit is controlled. The multiplexing unit acts as a signal channel selection element, responsible for selecting the currently connected side between different authentication modules and the device to be started. By changing the selection signal of the multiplexing unit, the data interaction path between the authentication module and the device to be started is dynamically changed. By combining the delay line and the multiplexing unit, the access switching module possesses both time control capability and channel selection capability.

[0058] The first control device is connected to the multiplexing unit via a delay line; each authentication module is connected to the device to be started via the multiplexing unit. Based on this, the access switching module is specifically used to: receive access switching commands sent by the first control device via the delay line and perform real-time switching timing; according to the connection switching conditions carried in the access switching command, when the real-time switching timing meets the connection switching conditions, switch the connection status of each authentication module and the device to be started via the multiplexing unit.

[0059] In this embodiment, the first control device sends an access switching command to the delay line through a corresponding output port. Upon receiving the access switching command, the delay line starts a real-time switching timer based on the connection switching conditions in the command. For example, the connection switching conditions may include a time constraint of "switching after completing a certain access cycle," or a control requirement of "maintaining the connection state between the current authentication module and the device to be started within a preset time window." Internally, the delay line accumulates and records the running time from the receipt of the access switching command through a timer, trigger logic, or timing control unit. Only after the real-time switching timer reaches the connection switching conditions required in the access switching command does it output a control trigger to the multiplexing unit to update the strobe signal. By setting a real-time switching timer mechanism in the delay line, it ensures that the current authentication module has sufficient access time within a preset time to complete the reading and processing of relevant device information of the device to be started, improving the integrity and stability of the authentication process.

[0060] After receiving the control signal from the delayed line, the multiplexing unit switches the authentication module currently connected to the device to be started to another authentication module, or maintains the current connection state, according to the target channel indicated by the control signal. Specifically, when the real-time switching timer does not meet the connection switching conditions, the multiplexing unit maintains the existing channel selection relationship, allowing the current authentication module to continuously occupy the access path with the device to be started. When the real-time switching timer meets the connection switching conditions carried in the access switching command, the multiplexing unit updates its internal selection signal according to the target authentication module identifier set in the access switching command, switching the access channel of the device to be started to another authentication module. The multiplexing unit enables flexible control over the access order and access duration of each authentication module.

[0061] Furthermore, in one specific embodiment, the access switching module includes a first delay line, a second delay line, a first multiplexing unit, and a second multiplexing unit. The first control device is connected to the first multiplexing unit via the first delay line, and the first control device is connected to the second multiplexing unit via the second delay line. The authentication module is sequentially connected to the primary information source device and the backup information source device of the device to be started via the first multiplexing unit and the second multiplexing unit, respectively. The processor of the device to be started is connected to the primary information source device and the backup information source device via the second multiplexing unit.

[0062] Specifically, the two-level multiplexing structure within the access switching module can perform phased switching at different times based on their respective access switching instructions. During the authentication phase, the authentication module occupies the access channels to the primary information source device and the backup information source device; after the authentication phase ends, the processor of the device to be started takes over the access to the primary information source device and the backup information source device through the second multiplexing unit, completing the path conversion from authentication access to startup access.

[0063] Based on the above embodiments, the access switching module is specifically used to: receive a first access switching instruction sent by the first control device through a first delay line, and perform real-time switching timing to obtain a first cumulative duration; when the first cumulative duration is greater than or equal to the first time threshold carried in the first access switching instruction, switch the authentication module currently connected to the main information source device and the backup information source device to another authentication module through a first multiplexing unit.

[0064] In this embodiment, the first delay line is used to process the first access switching command sent by the first control device. Upon receiving the first access switching command, the first delay line starts a real-time switching timer for the command and accumulates it to form a first cumulative duration. During the real-time switching timer, the first multiplexing unit maintains its current selection state, enabling the authentication module currently connected to the primary and backup information source devices to read device information for authentication, such as firmware code segments or other startup data, from the primary and backup information source devices within a continuous access window. When the first cumulative duration has not yet reached the first time threshold carried in the first access switching command, the first multiplexing unit will not perform a switching operation, ensuring that the current authentication module has complete access time to complete data acquisition and related processing.

[0065] When the first cumulative duration is greater than or equal to the first time threshold carried in the first access switching command, the first delay line outputs a control signal to the first multiplexing unit to trigger the switching. The first multiplexing unit then switches the authentication module currently connected to the primary and backup information source devices to another authentication module. In one embodiment, two authentication modules can be configured. Before the first time threshold is reached, the first multiplexing unit selects the first authentication module to connect to the primary and backup information source devices. After the first time threshold is reached, it switches and selects the second authentication module to connect to the primary and backup information source devices. In this way, the access switching module allocates sequentially independent access windows to different authentication modules during the authentication phase, enabling each authentication module to obtain device information from the same source without interference. By utilizing the cooperation of the first delay line and the first multiplexing unit, automatic management of the access order and access duration between authentication modules is achieved, which helps ensure that each authentication module can complete the access to the primary and backup information source devices and the generation of verification information within a preset time.

[0066] Furthermore, the access switching module is specifically used to: receive a second access switching command sent by the first control device via a second delay line, and perform a switching timer to obtain a second cumulative duration. When the second cumulative duration is greater than or equal to the second time threshold carried in the second access switching command, the authentication module currently connected to the main information source device and the backup information source device is switched to the processor of the device to be started via a second multiplexing unit.

[0067] In this embodiment, the second delay line is used to process the second access switching command sent by the first control device, controlling the transition from the authentication phase to the startup phase. Upon receiving the second access switching command, the second delay line initiates a corresponding switching timing process and accumulates a second cumulative duration. Before the second cumulative duration reaches the second time threshold carried in the second access switching command, the second multiplexing unit remains in the authentication path state, meaning its output is still connected to the authentication module. When the second cumulative duration is greater than or equal to the second time threshold carried in the second access switching command, the second delay line outputs a switching control signal to the second multiplexing unit. The second multiplexing unit disconnects the authentication module currently connected to the primary and backup information source devices and switches the connection between the primary and backup information source devices to the processor of the device to be started. This allows the processor to read the startup program from the primary or backup information source device based on the startup control information from the startup control module after the authentication process is completed. Through the cooperation of the second delay line and the second multiplexing unit, the access rights of the information source device are transferred from the authentication module to the processor, ensuring the temporal order of the authentication and startup phases.

[0068] Regarding time parameter configuration, to ensure that each authentication module has sufficient time to complete device information reading, verification information generation, and verification information interaction with other authentication modules, in one implementation, the first time threshold is preferably set to be greater than the maximum access time for each authentication module to read firmware code segments from the primary and backup information source devices and complete necessary processing. For example, the first time threshold can be denoted as t1. During configuration, parameters that ensure firmware code segment reading and verification information generation are completed within time t1 are selected based on factors such as the access speed of the primary and backup information source devices and the processing capacity of the authentication modules. To ensure that at least two authentication modules have completed their respective authentication operations before switching to the processor, the second time threshold can be set to t2. If there are two authentication modules, t2 is set to be greater than twice the first time threshold. Through this constraint, a complete access window can be provided to both authentication modules sequentially before the second cumulative time reaches the second time threshold, allowing each authentication module to complete access to the primary and backup information source devices and output authentication results.

[0069] In one embodiment, Figure 2 This is a schematic diagram of the structure of a trusted boot system based on a dual authentication module provided in an embodiment of this application. Figure 2As shown, in this embodiment, the device to be booted is a processor (CPU) on a server motherboard, along with its corresponding main BIOS Flash and backup BIOS Flash. The main BIOS Flash and backup BIOS Flash serve as the main information source device and backup information source device, respectively. The CPU is powered by the CPU power supply. The trusted boot system includes two authentication modules, a boot control module, and an access switching module. Specifically, the two authentication modules are authentication CPLD-1 and authentication CPLD-2, which are connected via a dedicated data interface, such as a Serial Peripheral Interface (SPI) interface or a Low Voltage Differential Signaling (LVDS) interface, and are powered by independent power supplies -1 and -2, respectively, forming two authentication parts with completely independent power supplies and clocks. The second control device is a boot control CPLD or a hardware control logic circuit (combinational logic circuit), which is connected to the CPU to output the processor reset control signal (SYSTEM_RESET_N) and the boot information source selection signal (CPU_BOOT_SEL), and is also connected to the two authentication CPLDs to send and receive verification results.

[0070] The first multiplexing unit includes multiplexers MUX_1 and MUX_2; the second multiplexing unit includes multiplexers MUX_3 and MUX_4. The outputs of the first delay line (delay line-1) and the second delay line (delay line-2) are VERIFY_DELAY_1 and VERIFY_DELAY_2 control signals, respectively connected to the strobe signal terminals of MUX_1 to MUX_4, used to switch the connection state of each multiplexing unit at different time stages. The authentication CPLD-1 is connected to one set of input terminals of MUX_1 and MUX_2 via two Serial Peripheral Interfaces (SPI) SPI_1_1 and SPI_1_2, respectively; the authentication CPLD-2 is connected to another set of input terminals of MUX_1 and MUX_2 via SPI_2_1 and SPI_2_2, respectively. The output of the first multiplexing unit is connected to the input of the second multiplexing unit. That is, the output of MUX_1 is used as a set of inputs to MUX_3, and the output of MUX_2 is used as a set of inputs to MUX_4. This is used to select the path to access the main BIOS Flash and the backup BIOS Flash for different authentication CPLDs during the authentication phase.

[0071] To control the CPU's boot selection between the primary BIOS Flash and the backup BIOS Flash, this embodiment uses a multiplexer MUX_5 as the CPU-side boot source selector. The CPU's SPI interface is split into two paths via MUX_5: one path connects to the primary BIOS Flash via MUX_3, and the other path connects to the backup BIOS Flash via MUX_4. The CPU_BOOT_SEL signal output by the boot control CPLD or hardware control logic circuit serves as the strobe signal for MUX_5, indicating whether the CPU ultimately obtains the boot firmware from the primary BIOS Flash or the backup BIOS Flash. Simultaneously, the boot control CPLD also outputs a SYSTEM_RESET_N signal to the CPU to set the CPU's reset state. Upon meeting the boot requirements, the reset is released, allowing the CPU to enter the boot process. In this way, the boot control module can comprehensively control the CPU's reset state and the selection of the boot information source device based on the verification results of the two authentication modules.

[0072] The overall process is explained below. After power-on, power supply-1 and power supply-2 provide operating power to authentication CPLD-1 and authentication CPLD-2 respectively. Their respective internal clock signal generation circuits output a running clock signal to the authentication CPLD, enabling the two authentication modules to power on and start independently. Upon power-on, the authentication CPLD first completes an internal self-test according to its built-in self-test program, confirming that internal resources such as configuration data, logic units, key storage areas, and communication interfaces are in normal condition. After passing the self-test, the two authentication CPLDs execute a key exchange protocol through their dedicated communication interface, negotiating and generating a temporary session key for the current session without disclosing the long-term key, and storing it in their respective local secure storage areas. At this time, the outputs of the first and second delay lines are in their initial state, putting MUX_1 to MUX_4 in authentication access configuration.

[0073] During the authentication phase, the first control device sends a first access switching command to the access switching module via a first delay line. The first delay line begins real-time switching timing to obtain a first cumulative duration. Before the first cumulative duration reaches a preset first time threshold, MUX_1 and MUX_2 select the authentication CPLD-1, and the corresponding SPI_1_1 and SPI_1_2 are connected to the main BIOS Flash and the backup BIOS Flash, respectively. The authentication CPLD-1 reads firmware code segments (e.g., addresses 0x0000 to 0xFFFF) from the two BIOSes and performs hash operations on the read data to obtain the hash data H1_1 and H1_2 corresponding to the main BIOS Flash and the backup BIOS Flash, respectively. When the first accumulated time reaches the first time threshold, the first delay line triggers a switch between MUX_1 and MUX_2, changing the access path from authentication CPLD-1 to authentication CPLD-2. At this time, SPI_2_1 and SPI_2_2 are connected to the main BIOS Flash and the backup BIOS Flash, respectively. Authentication CPLD-2 completes the reading and hash calculation of firmware code segments within the same address range within its own access window, obtaining hash data H2_1 and H2_2. In this embodiment, the first time threshold is set to be greater than the maximum access time required for either authentication CPLD to complete the firmware code segment reading and hash calculation.

[0074] Simultaneously, the first control device sends a second access switching command through the second delay line, and the second delay line begins timing for the second cumulative duration. Before the second cumulative duration reaches the second time threshold, both MUX_3 and MUX_4 maintain access to the authentication paths from MUX_1 and MUX_2. When the second cumulative duration reaches the second time threshold, the second delay line triggers a switch between MUX_3 and MUX_4, changing the access path of the primary BIOS Flash and the backup BIOS Flash from the authentication CPLD side to the CPU side, enabling the CPU to directly access the corresponding BIOS Flash through the path selected by MUX_5. In this embodiment, the second time threshold is preferably set to be greater than twice the first time threshold.

[0075] After completing firmware data reading and hash calculation, the authentication CPLD-1 encrypts its calculated H1_1 and H1_2 using the aforementioned temporary session key, and carries the source device tags of the main BIOS Flash and backup BIOS Flash in the verification information. It then sends the verification information to the authentication CPLD-2 via a dedicated communication interface. Similarly, the authentication CPLD-2 encrypts its calculated H2_1 and H2_2 and sends them to the authentication CPLD-1. Each authentication CPLD, after decrypting the verification information sent by the peer, combines its own hash data with the peer's hash data according to the source device tags, and performs consistency checks on the hash data set {H1_1, H2_1} corresponding to the main BIOS Flash and the hash data set {H1_2, H2_2} corresponding to the backup BIOS Flash. When all hash data in the sets are identical and meet the preset consistency conditions, the corresponding source device is marked as verified; otherwise, it is marked as verified as failed. Each authentication CPLD outputs the verification pass / fail result for the main BIOS Flash and backup BIOS Flash to the boot control CPLD or hardware control logic circuit in the form of an enable signal.

[0076] In one embodiment, the second control device includes a combinational logic circuit or a programmable logic controller for startup control in the device to be started. Each authentication module is connected to the combinational logic circuit or the programmable logic controller for startup control, and the combinational logic circuit is connected to the device to be started.

[0077] The second control device is specifically used to: receive the verification results output by each authentication module, and output processor reset control information and information source device selection information according to the enable signals corresponding to multiple verification results through combinational logic circuits; or receive the verification results output by each authentication module through the start control programmable logic controller, and query and obtain the processor reset control information and information source device selection information according to multiple verification results through a preset control state correspondence table.

[0078] In this embodiment, when the second control device is implemented using combinational logic circuits, the verification results output by each authentication module can be converted into multiple corresponding enable signals. For example, enable signals indicating successful or unsuccessful verification are generated for the primary information source device and the backup information source device, respectively. The combinational logic circuit uses pre-set AND, OR, NOT gates, and other logic devices to perform logical combination operations on the enable signals from multiple authentication modules, internally forming a comprehensive judgment on the trustworthiness of each information source device. On one hand, the combinational logic circuit generates processor reset control information based on the comprehensive judgment result, instructing the processor of the device to be started to either maintain or release the reset. On the other hand, based on the comprehensive trustworthiness judgment of the primary and backup information source devices, it generates information source device selection information, instructing the device to be started to load startup information from the primary or backup information source device. By outputting processor reset control information and information source device selection information based on the enable signals corresponding to multiple verification results using the combinational logic circuit, a direct hardware mapping between the authentication result and the startup behavior is achieved, accelerating the startup process.

[0079] Specifically, Figure 3 This is a schematic diagram of the structure implemented using combinational logic circuits in an embodiment of this application. After verifying the main information source device and the backup information source device, authentication CPLD-1 and CPLD-2 output four enable signals: Main Flash Start EN_1, Backup Flash Start EN_1, Main Flash Start EN_2, and Backup Flash Start EN_2, respectively. A high level indicates that the corresponding information source device has passed verification, and a low level indicates that verification has failed. The input terminals of the combinational logic circuit receive the four enable signals and are configured with two AND gates: the two input terminals of the first AND gate are connected to Main Flash Start EN_1 and Main Flash Start EN_2, respectively, and its output serves as the comprehensive pass signal for the main information source device; the two input terminals of the second AND gate are connected to Backup Flash Start EN_1 and Backup Flash Start EN_2, respectively, and its output serves as the comprehensive pass signal for the backup information source device. Through these two AND gates, the corresponding information source device is considered passed only when both programmable controllers simultaneously consider a particular information source device to have passed.

[0080] To generate processor reset control information, an OR gate is included in the combinational logic circuit. Its two inputs are connected to the main information source device's synthesis pass signal and the backup information source device's synthesis pass signal, respectively. When at least one synthesis pass signal is high, the OR gate outputs a high level, and the startup control CPLD sets SYSTEM_RESET_N to the reset level, allowing the CPU to start. When both synthesis pass signals are low, its output is low, SYSTEM_RESET_N remains at the reset level, and the CPU does not start.

[0081] To achieve the selection control of the information source device, the combinational logic circuit also includes an inverter, an OR gate, and an AND gate. The input of the inverter is connected to the main information source device's pass signal, and its output represents the inverted signal. The standby information source device's pass signal is passed through an OR gate, and together with the inverted signal, serves as the two inputs of the AND gate. Only when both the main information source device's pass signal is low and the standby information source device's pass signal is high are simultaneously met will the AND gate output a high level. The CPLD then uses this output as the hardware source signal for the information source device selection information CPU_BOOT_SEL, causing the CPU to select the standby information source device for startup. Under other startup-enabled conditions, CPU_BOOT_SEL remains in the state of selecting the main information source device. Even if the combinational logic circuit can output a default CPU_BOOT_SEL state when neither the main nor standby information source device passes, since SYSTEM_RESET_N is always at the reset level, the CPU will not actually enter the startup process. This embodiment fully implements the comprehensive processing of the verification results output by the two programmable controllers at the hardware level, forming the processor reset control information SYSTEM_RESET_N and the information source device selection information CPU_BOOT_SEL.

[0082] In another embodiment, when the second control device employs a programmable startup control logic controller, the programmable startup control logic controller receives the verification results output by each authentication module and maps these verification results to internal status codes according to a preset format. Based on this, the programmable startup control logic controller pre-stores a control status mapping table. The programmable startup control logic controller queries the control status mapping table according to the current status code to directly obtain the corresponding processor reset control information and information source device selection information. By employing a table lookup method using a control status mapping table within the programmable startup control logic controller, it is convenient to flexibly adjust the startup strategy by updating table entries, thereby improving the scalability and maintainability of the trusted startup system in different application scenarios.

[0083] Specifically, Figure 4This is a schematic diagram illustrating the structure of a programmable logic controller (PLC) for startup control provided in this embodiment. In this embodiment, the second control device is implemented using a startup control CPLD, serving as the PLC for startup control in the device to be started. It is used to uniformly receive the main Flash startup EN_1, backup Flash startup EN_1, main Flash startup EN_2, and backup Flash startup EN_2 outputs from authentication CPLD-1 and authentication CPLD-2 after the authentication process is completed. A high level indicates that the corresponding information source device verification has passed, and a low level indicates that the verification has failed. The startup control CPLD internally stores a control state mapping table, mapping the level combinations of the four enable signals one-to-one with the processor reset control information SYSTEM_RESET_N and the information source device selection information CPU_BOOT_SEL. See the table below:

[0084]

[0085] When the CPLD receives four enable signals, it uses the current level combination as an index to look up the corresponding control state in the control state table and directly obtains the SYSTEM_RESET_N state and CPU_BOOT_SEL state to be output. For example, when both the main BIOS Flash and the standby BIOS Flash are determined to be successful, SYSTEM_RESET_N is set to the release reset level and CPU_BOOT_SEL selects the main information source device. When the main BIOS Flash fails but the standby BIOS Flash succeeds, SYSTEM_RESET_N is still released reset but CPU_BOOT_SEL selects the standby information source device.

[0086] In one embodiment, the first control device is used to receive the self-test result of the authentication module, and select two authentication modules that have passed the self-test as the first authentication module and the second authentication module in sequence according to a preset sorting list; receive the communication establishment result of the first authentication module and the second authentication module, and send an access switching command to the delayed line after receiving the communication establishment result.

[0087] In this embodiment, the first control device first receives self-test result information generated by each authentication module according to its built-in self-test program, such as a simple signal output indicating whether the self-test passed. The first control device prioritizes all authentication modules that have passed the self-test according to a preset sorting list, for example, by hardware location, number order, or preset master / slave relationship. It then selects two authentication modules that have passed the self-test and are in normal status from the sorting list and marks them as the first authentication module and the second authentication module in the current startup cycle. These two authentication modules participate in the subsequent firmware reading and interactive authentication process.

[0088] Based on this, the first control device also receives indication information indicating whether the first authentication module and the second authentication module have established a secure communication session. When the communication establishment result between the two is detected as successful, the first control device determines that the current startup cycle meets the authentication startup conditions and outputs an access switching command to the connected delay line. In specific implementation, the first control device can be implemented using existing control devices or constructed from combinational logic circuits. Its output can be either a control signal for controlling the working state of the delay line or an enable signal for enabling the multiplexing unit inside the access switching module. Depending on different hardware implementation schemes, it flexibly completes the selection of authentication modules and the triggering control of the access switching timing, improving the adaptability and reliability of the trusted startup system in engineering implementation. Furthermore, it should be noted that the first control device can send an access switching command to the delay line upon power-up. In this case, the timing information carried in the switching command includes the self-test time of the two authentication modules and the time of connection establishment; or it can adopt the form of this implementation. Specific settings can be flexibly configured according to requirements.

[0089] Figure 5 This is a flowchart illustrating the trusted boot method provided in an embodiment of this application. Based on the above embodiments, as... Figure 5 As shown, it includes:

[0090] S51, obtain the device information of the device to be started, and generate the verification information based on the device information, and obtain the verification information generated by at least one other authentication module;

[0091] S52, based on the verification information generated by itself and the verification information generated by at least one other authentication module, adopts preset verification rules to obtain and output the verification result.

[0092] In this embodiment, the method is applied to the authentication module. Device information of the device to be started is obtained. This device information typically includes boot firmware data, configuration information, identification information, or other data reflecting the boot environment state stored in at least one information source device within the device. Verification information is a data structure obtained after processing the device information and used for authentication. It can retain the content characteristics of the device information or add identification fields related to the collection source, collection time, or information category to distinguish verification information from different sources in subsequent verification. Verification information generated by at least one other authentication module also needs to be obtained. Since different authentication modules typically differ in physical path, collection timing, or internal implementation, even when targeting the same device to be started and the same information source device, their processes for acquiring and processing device information are independent. Therefore, the verification information generated by each authentication module can be considered as multiple independent observations of the same device information.

[0093] Next, based on this information to be verified, the verification results are obtained and output using preset verification rules. These preset verification rules are a set of pre-defined judgment logics that describe under what conditions the information to be verified generated by different authentication modules is considered consistent or abnormal. Each authentication module compares its own generated information to be verified with information from other authentication modules item by item according to the preset verification rules, or combines judgments based on dimensions such as the information source device and data category. It should be noted that each authentication module executes the steps in this method according to the same process, thus forming an authentication mechanism at the method level that involves independent calculations and cross-verification.

[0094] In one embodiment, step S51 is further described. Based on the above embodiment, generating verification information includes:

[0095] S511, based on at least one information source device in the device to be started, read the firmware code segment in the information source device according to the preset information acquisition rules;

[0096] S512 calculates and obtains the hash data corresponding to each information source device through hash operation based on the firmware code segment;

[0097] S513: Obtain the stored temporary session key, encrypt the hash data corresponding to each information source device, and generate verification information carrying the information source device tag.

[0098] In this embodiment, the preset information acquisition rules are a unified convention for the access method of the information source device. These rules may include the start and end addresses of the firmware code segment, the reading step size by byte or by data block, the reading order, the error retry strategy, and the fault handling method in case of access anomalies. By pre-configuring the information acquisition rules in the authentication module, different authentication modules can consistently locate and read the same firmware code segment when accessing the same information source device, thus ensuring comparability when authenticating firmware data subsequently. Based on the firmware code segment, hash data corresponding to each information source device is calculated through hash operations. A hash operation is a one-way operation process that maps input data of arbitrary length to output data of fixed length. By converting the firmware code segment into hash data through hash operations, the overall feature extraction of the firmware content is achieved, allowing the authentication process to determine whether the firmware has been tampered with without directly exposing the complete firmware content.

[0099] Next, the stored temporary session key is obtained, and the hash data corresponding to each information source device is encrypted to generate verification information carrying the information source device tag. The temporary session key is obtained through negotiation between authentication modules according to the key exchange protocol after the authentication module passes its internal self-test and is stored in each authentication module. It is used to encrypt and protect authentication data during the current authentication session. The hash data is encrypted using a preset encryption algorithm (such as SHA-256), and the encrypted ciphertext data is output. Simultaneously, to distinguish encrypted data from different information source devices during subsequent cross-authentication module interactions, the authentication module attaches an information source device tag to each encrypted hash data when generating the verification information, providing a clear and reliable input data foundation for the cross-verification step. It should be noted that the key exchange protocol can adopt existing protocol forms, and no specific limitation is made here.

[0100] In one embodiment, step S52 described above is further explained below. Based on the above embodiment, obtaining the verification result includes:

[0101] S521, receive verification information sent by at least one other authentication module, and obtain a temporary session key corresponding to at least one other authentication module;

[0102] S522, based on the temporary session key, decrypt the verification information sent by at least one other authentication module to obtain the hash data corresponding to at least one other authentication module;

[0103] S523, based on the information source device label, combine its own corresponding hash data with the hash data corresponding to at least one other authentication module to obtain a set of hash data corresponding to each information source device;

[0104] S524, perform consistency verification on the hash data in each hash data set;

[0105] S525, when all hash data in the hash data set meets the preset consistency condition, obtain the verification result of the information source device corresponding to the hash data set;

[0106] S526, when at least one hash data in the hash data set does not meet the preset consistency condition, obtain the verification failure result of the information source device corresponding to the hash data set.

[0107] In this embodiment, after generating the local verification information, the authentication module also needs to perform joint verification of the verification information from other authentication modules. Specifically, it first receives the verification information sent by at least one other authentication module, and obtains the temporary session key corresponding to each other authentication module based on the temporary session key negotiated with these authentication modules in the early key exchange phase. On this basis, the authentication module uses the corresponding temporary session key to decrypt the verification information sent by each other authentication module to obtain the hash data carried in the verification information.

[0108] Subsequently, based on the information source device labels, the authentication module categorizes and combines the hash data it calculates for each information source device with the hash data calculated by other authentication modules for the same information source device, forming a hash data set corresponding to each information source device. It then executes preset consistency verification rules on multiple hash data within each hash data set, such as determining whether all hash data within the set are identical. When all hash data in the hash data set corresponding to a certain information source device meets the preset consistency conditions, the authentication module marks that information source device as verified and outputs the verification success result corresponding to that information source device. When at least one hash data in the hash data set corresponding to a certain information source device does not meet the preset consistency conditions, the information source device is marked as verified as failed, and the corresponding verification failure result is output. Through the above joint decryption and consistency verification process, multi-module cross-verification of the trustworthiness of each information source device is achieved.

[0109] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0110] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes at least one processor 601 and a memory 602. Optionally, the electronic device 60 further includes a communication component 603. The processor 601, memory 602, and communication component 603 are connected via a bus 604.

[0111] In a specific implementation, at least one processor 601 executes computer execution instructions stored in memory 602, causing at least one processor 601 to execute the aforementioned trusted boot method embodiment.

[0112] The specific implementation process of processor 601 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0113] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0114] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0115] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0116] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described XX method embodiments when it is run.

[0117] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0118] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the trusted boot method embodiments described above.

[0119] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the trusted boot method embodiments described above.

[0120] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0121] The trusted boot system and trusted boot method provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A trusted boot system, characterized by The application relates to a device startup control system. The device startup control system comprises an access switching module, a startup control module and at least two authentication modules; the at least two authentication modules are connected to each other, each authentication module is connected to a to-be-started device through the access switching module, and each authentication module, the access switching module and the to-be-started device are connected to the startup control module; The access switching module is used for switching the connection state of each authentication module and the to-be-started device according to an access switching instruction; The authentication module is used for obtaining device information of the to-be-started device, generating to-be-verified information according to the device information, and obtaining to-be-verified information generated by at least one other authentication module; The authentication module is further used for obtaining and outputting a verification result according to the to-be-verified information generated by itself and the to-be-verified information generated by the at least one other authentication module by using a preset verification rule; The startup control module is used for receiving the verification result, generating startup control information according to multiple verification results, and sending the startup control information to the to-be-started device.

2. The trusted boot system of claim 1, wherein, The authentication module comprises an editable controller, the editable controller is connected to the to-be-started device through the access switching module, and the editable controller is connected to at least one other editable controller through a preset communication interface; The authentication module is specifically used for: obtaining the device information of the to-be-started device through the editable controller, generating to-be-verified information according to the device information, and obtaining to-be-verified information of at least one other editable controller through the editable controller; The authentication module is further specifically used for: obtaining and outputting a verification result according to the to-be-verified information corresponding to the editable controller and the to-be-verified information corresponding to the at least one other editable controller by using a preset verification rule through the editable controller.

3. The trusted boot system of claim 1, wherein, The startup control module comprises a first control device and a second control device; The first control device is connected to the access switching module, and each authentication module and the to-be-started device are connected to the second control device; The startup control module is specifically used for: receiving the verification result output by each authentication module through the second control device, generating startup control information according to multiple verification results, and sending the startup control information to the to-be-started device; The startup control module is further specifically used for: sending an access switching instruction carrying a module switching condition to the access switching module through the first control device.

4. The trusted boot system of claim 3, wherein, The access switching module comprises a delay line and a multiplexing unit; The first control device is connected to the multiplexing unit through the delay line, and each authentication module is connected to the to-be-started device through the multiplexing unit; The access switching module is specifically used for: receiving an access switching instruction sent by the first control device through the delay line and performing real-time switching timing; switching the connection state of each authentication module and the to-be-started device through the multiplexing unit when the real-time switching timing meets a connection switching condition carried in the access switching instruction.

5. The trusted boot system of claim 4, wherein, The access switching module comprises a first delay line, a second delay line, a first multiplexing unit and a second multiplexing unit; The first control device is connected with the first multiplexing unit through the first delay line, and is connected with the second multiplexing unit through the second delay line; The authentication modules are connected with the main information source device and the standby information source device of the to-be-started device through the first multiplexing unit and the second multiplexing unit respectively; The processor of the to-be-started device is connected with the main information source device and the standby information source device through the second multiplexing unit; The access switching module is specifically used for: receiving a first access switching instruction sent by the first control device through the first delay line, and performing real-time switching timing to obtain a first cumulative time length; receiving a second access switching instruction sent by the first control device through the second delay line, and performing switching timing to obtain a second cumulative time length; when the first cumulative time length is greater than or equal to a first time threshold carried in the first access switching instruction, switching, through the first multiplexing unit, the authentication module currently connected with the main information source device and the standby information source device to another authentication module; when the second cumulative time length is greater than or equal to a second time threshold carried in the second access switching instruction, switching, through the second multiplexing unit, the authentication module currently connected with the main information source device and the standby information source device to the processor of the to-be-started device.

6. The trusted boot system of claim 3, wherein, The second control device comprises a combinational logic circuit or a start control editable logic controller in the to-be-started device; Each authentication module is connected with the combinational logic circuit or the start control editable logic controller, and the combinational logic circuit is connected with the to-be-started device; Then the second control device is specifically used for: receiving the check results output by the authentication modules, and outputting processor reset control information and information source device selection information through the combinational logic circuit according to the enable signals corresponding to the check results; or receiving the check results output by the authentication modules through the start control editable logic controller, and querying and obtaining the processor reset control information and the information source device selection information through a preset control state corresponding table according to the check results.

7. The trusted boot system of claim 2, wherein, The authentication module further comprises a power supply circuit and a clock signal generation circuit, and the power supply circuit and the clock signal generation circuit are connected with the editable controller; Then the authentication module is further used for: providing working power to the editable controller through the power supply circuit, and providing a running clock signal to the editable controller through the clock signal generation circuit. After the editable controller completes power-on and starts according to the working power supply and the runtime clock signal, the editable controller performs internal self-checking according to a built-in self-checking program, and after the self-checking passes, the editable controller acquires and stores a temporary session key corresponding to the editable controller in at least one other authentication module according to a key exchange protocol through a preset communication interface.

8. A trusted boot method, comprising: Comprise: Obtain device information of a device to be started, and generate to-be-verified information according to the device information, and obtain to-be-verified information generated by at least one other authentication module; According to the to-be-verified information generated by itself and the to-be-verified information generated by the at least one other authentication module, a preset verification rule is used to obtain and output a verification result.

9. The trusted boot method of claim 8, wherein, The device information of the device to be started is obtained, and the to-be-verified information is generated according to the device information, comprising: According to at least one information source device in the device to be started, a preset information acquisition rule is used to read a firmware code segment in the information source device; According to the firmware code segment, the hash data corresponding to each information source device is calculated by hash operation; Obtain the stored temporary session key, and encrypt the hash data corresponding to each information source device to generate to-be-verified information carrying the information source device label.

10. The trusted boot method of claim 8, wherein, According to the to-be-verified information generated by itself and the to-be-verified information generated by the at least one other authentication module, a preset verification rule is used to obtain a verification result, comprising: Receive the to-be-verified information sent by the at least one other authentication module, and obtain the temporary session key corresponding to the at least one other authentication module; According to the temporary session key, the to-be-verified information sent by the at least one other authentication module is decrypted to obtain the hash data corresponding to the at least one other authentication module; According to the information source device label, the hash data corresponding to itself and the hash data corresponding to the at least one other authentication module are combined to obtain a hash data set corresponding to each information source device; Consistency verification is performed on the hash data in each hash data set; When all the hash data in the hash data set meets the preset consistency condition, the verification pass result of the information source device corresponding to the hash data set is obtained; And / or when at least one hash data in the hash data set does not meet the preset consistency condition, the verification fail result of the information source device corresponding to the hash data set is obtained.

Images