Server firmware starting system based on distributed security module

Abstract

The invention provides a server firmware starting system based on a distributed security module. The server firmware starting system comprises a storage module, an entity storage medium and the distributed security module. The storage module comprises a basic input / output system and an initial encryption key database, and is responsible for executing an initial program and authenticating the validity of the initial program when the equipment is started; the entity storage medium comprises a user-defined database and contains a special secret key used for authenticating an additional module of the basic input / output system. A plurality of distributed security modules generate dynamic security tokens and mutually verify the dynamic security tokens, so that the integrity and security of the generation process are ensured. Before loading the basic input / output system additional module, the system confirms that the initial encryption key database does not contain the key for authenticating the additional module, and authenticates the additional module by using the special key and the dynamic security token. The distributed security module also monitors operation and data transmission in real time, records and analyzes information in the authentication process, detects abnormal behaviors and takes countermeasures to ensure system security.

Description

Technical Field

[0001] The invention relates to a server firmware startup system, in particular to a server firmware startup system based on a distributed security module. Background Art

[0002] With the rapid development of information technology, servers, as important infrastructure for information processing and storage, play a vital role in various application scenarios. The security and stability of the server system are directly related to the safe and reliable operation of the entire information system. Therefore, the secure boot of server firmware has become one of the research hotspots. However, the traditional server firmware boot system has many security risks, including but not limited to unauthorized firmware tampering, malware injection, etc. These problems seriously threaten the security and integrity of the server system.

[0003] The Basic Input / Output System is a key component in the computer boot process, which is responsible for initializing and testing system hardware components before the operating system is loaded. The security of the Basic Input / Output System directly affects the secure boot of the entire system. However, traditional Basic Input / Output Systems mainly rely on statically stored encryption keys to verify and authenticate the boot program, which has significant limitations.

[0004] In traditional BIOS, keys are stored statically, which means that once the keys are stored, they will not change. This static storage method has significant security risks. First, because the keys are stored statically, attackers can obtain key information in the storage medium through various means. Once the keys are cracked or leaked, attackers can use these keys to bypass the verification mechanism of the BIOS and load unauthorized malicious firmware or operating system. Second, once static keys are set, they usually do not change throughout the life cycle of the device. This lack of a dynamic update mechanism means that once the keys are leaked, the system will be at risk for a long time until the keys are manually updated.

[0005] In addition, the traditional basic input / output system authentication mechanism usually relies on only one or several static keys for authentication. This single authentication mechanism has significant shortcomings. With the diversification and complexity of attack methods, the single static key authentication mechanism seems to be unable to cope with the diverse security threats effectively. For example, a single authentication mechanism cannot provide sufficient protection against different types of attacks (such as man-in-the-middle attacks, replay attacks, etc.). In addition, the single authentication mechanism lacks flexibility and cannot be dynamically adjusted according to actual needs. This makes it difficult for the system to respond quickly and adjust the authentication strategy when facing new security threats, making it easy for attackers to exploit it.

[0006] More importantly, traditional BIOS lacks a dynamic security authentication mechanism, which makes it vulnerable to threats when facing a real-time changing security environment. Since traditional BIOS cannot generate and verify dynamic security tokens in real time, it is vulnerable to real-time attacks. Attackers can take advantage of this and launch attacks during the system startup process to bypass the static authentication mechanism. In addition, in the face of ever-changing security threats, traditional BIOS lacks dynamic response capabilities and cannot adjust security authentication strategies according to real-time situations. This static authentication method cannot meet the needs of modern server systems for high security and high flexibility.

[0007] In summary, the traditional basic input / output system has significant limitations and security risks in key management, authentication mechanism and dynamic security mechanism. Summary of the invention

[0008] In order to solve the above problems in the prior art, the present invention proposes a server firmware startup system based on a distributed security module, the firmware startup system comprising:

[0009] The storage module 101 includes a basic input / output system 103 and an initial encryption key database 104. The basic input / output system 103 executes an initial program when the device is started, and the initial encryption key database 104 includes an initial encryption key for authenticating the legitimacy of the initial program.

[0010] A physical storage medium 102, which contains a custom database 105, wherein the secondary encryption key in the custom database 105 includes a dedicated key for authenticating a basic input / output system add-on module 106;

[0011] A distributed security module 107, for generating a dynamic security token;

[0012] Before loading the BIOS add-on module 106 , the firmware boot system confirms that the initial encryption key database 104 does not contain a key for authenticating the add-on module, and authenticates the BIOS add-on module 106 using a dedicated key and a dynamic security token.

[0013] The dynamic security token is generated by a plurality of the distributed security modules 107 , each of the distributed security modules 107 is responsible for generating a part of the token, and each of the distributed security modules 107 performs mutual authentication.

[0014] The firmware startup system includes multiple distributed security modules 107, each of which is responsible for generating a part of the token and performing mutual verification. After all distributed security modules 107 are successfully verified, they are combined to generate a complete dynamic security token, and the generated dynamic security token and private key are used to authenticate the basic input / output system additional module 106. After the authentication is successful, the basic input / output system additional module 106 is loaded and executed.

[0015] Each distributed security module 107 collects current system status information, including but not limited to timestamp, hardware status, operating system version, and random number; according to the hash algorithm, each distributed security module 107 uses the collected system status information, timestamp, and random number to generate the security token part it is responsible for. The specific formula is as follows:

[0016] Token part i =Hash(status information i +Timestamp i +Random Numbers i ).

[0017] Each distributed security module 107 sends the generated token part, state information and random number to other modules. After receiving the information sent by other modules, each module independently calculates whether the received token part is correct. The specific verification steps are as follows:

[0018] Verify the results j =Verify(token part i , status information i , random number i )

[0019] Among them, the Verify function is used to verify whether the generated token part is consistent with the expectation;

[0020] After all modules have been independently verified, the verification results will be fed back to the original sending module; when all modules have passed the verification, the token generation and transmission process is deemed complete and secure.

[0021] Each of the distributed security modules combines the verified token parts to form a complete dynamic security token. The combination formula is as follows:

[0022] Complete token = Combine(token part 1, token part 2, ..., token part n )

[0023] Among them, the Combine function is used to combine the various parts of the token into a complete dynamic security token according to a predetermined order and rules.

[0024] The basic input / output system additional module 106 generates its digital signature, which includes the hash value of the additional module code. The basic input / output system 103 uses the dedicated key and the generated complete dynamic security token to decrypt and verify the digital signature of the basic input / output system additional module 106. If the verification result is true, the firmware startup system loads and executes the basic input / output system additional module 106.

[0025] The distributed security module 107 monitors operations and data transmission in real time, records operations and data transmission information during the authentication process, and detects abnormal behavior; records and synchronizes operations and data transmission information, and verifies log integrity; uses distributed storage and encryption technology to store log data, and strictly controls access rights; regularly checks and analyzes security logs, verifies log integrity and consistency, analyzes log data to identify security threats, and takes countermeasures.

[0026] The device is a server device.

[0027] The present invention provides a server firmware startup system based on a distributed security module, which has the following beneficial effects: the distributed security module generates and verifies dynamic security tokens, thereby improving the security and anti-attack capability of the system; the distributed log recording and storage mechanism ensures the transparency and traceability of the authentication process, and prevents log data from being tampered with; the real-time monitoring and anomaly detection functions timely discover and handle potential security threats, and ensure the stable operation of the system; through strict access control and regular security audits, the overall security protection level of the system is further improved, ensuring that the firmware startup process of the server device is reliable and safe. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of the present application, but do not constitute an improper limitation of the present invention. In the drawings:

[0029] Figure 1 It is a structural schematic diagram of a server firmware startup system based on a distributed security module of the present invention. DETAILED DESCRIPTION

[0030] The present invention will be described in detail below in conjunction with the accompanying drawings and specific embodiments, wherein the illustrative embodiments and descriptions are only used to explain the present invention but are not intended to limit the present invention.

[0031] Example 1: Server firmware startup control system

[0032] like Figure 1As shown, this embodiment provides a server firmware boot system based on a distributed security module. The system includes a storage module 101 and a physical storage medium 102, wherein the storage module 101 includes a basic input / output system 103 and an initial encryption key database 104, and the physical storage medium 102 includes a custom database 105.

[0033] The basic input / output system 103 in the storage module 101 is responsible for initializing and testing hardware components and executing the initial program when the server is started. The initial encryption key database 104 contains one or more groups of initial encryption keys, which are used to authenticate the legitimacy of the initial program by verifying one or more first encryption identifiers associated with the initial program. However, these initial encryption keys do not contain the key for authenticating the basic input / output system additional module 106.

[0034] Before the BIOS add-on module 106 is loaded into the BIOS 103, the system first determines that the first set or sets of initial encryption keys in the initial encryption key database 104 do not contain a key for authenticating the add-on module. Subsequently, the system confirms that the second set or sets of secondary encryption keys in the custom database 105 stored in the physical storage medium 102 include a dedicated key that can be used to authenticate the add-on module 106.

[0035] Next, the system uses the private key and a dynamically generated security token to authenticate the additional module 106. The dynamically generated security token is generated by multiple distributed security modules 107, each of which is responsible for generating a part of the token, and these modules can mutually verify the integrity and security of the generation process. These distributed security modules 107 also have the function of real-time monitoring and recording the authentication process to ensure the overall security and stability of the system.

[0036] Example 2: Generation and verification of dynamic security tokens

[0037] The system includes multiple distributed security modules 107, each of which is responsible for generating a portion of the security token. The process includes the following steps:

[0038] a. Partial Generation of Dynamic Security Tokens

[0039] When the system starts, each module in the distributed security module 107 generates a portion of the security token according to a predetermined algorithm and the current system status. The specific steps are as follows:

[0040] 1. System status collection: Each distributed security module 107 collects current system status information, including but not limited to timestamp, hardware status, operating system version, random numbers, etc.

[0041] 2. Application of a predetermined algorithm: According to a predetermined algorithm (such as the hash algorithm SHA-256), each module uses the collected system status information, timestamps, and random numbers to generate the security token part it is responsible for. The specific formula is as follows:

[0042] Token part i =Hash(status information i +Timestamp i +Random Numbers i )

[0043] This formula is used to describe the process of each distributed security module 107 generating the security token part it is responsible for. The following is a detailed description of each part in the formula:

[0044] 1. Status Information i : refers to the current operating status of the system, including various types of information about hardware and software, such as CPU load, memory usage, network status, operating system version, etc. The status information reflects the specific situation of the system when generating the token, so that the generated token is closely related to the actual operating status of the system, thereby increasing security.

[0045] 2. Timestamp i : Refers to the specific time when the token part is generated, which can be accurate to milliseconds or higher. The timestamp ensures that each generated token part is unique, preventing replay attacks (that is, attackers repeatedly use the same data packet to attack).

[0046] 3. Random Numbers i : Refers to a random value generated by the distributed security module, which should be different each time the token part is generated. The random number increases unpredictability so that even if the system state and timestamp are the same, the generated token part will be different, further improving security.

[0047] 4. Hash: A hash function (such as SHA-256) is an algorithm that converts input data (a combination of state information, timestamp, and random number) into output data (hash value) of fixed length. The hash function ensures that the input data generates a unique hash value after complex calculations, and the hash value is highly irreversible (i.e., the original input cannot be reversed from the hash value), thereby ensuring the security and integrity of the token part.

[0048] The calculation process of the formula is as follows:

[0049] 1. Data combination:

[0050] Status information i , Timestamp i and random numbers iCombine to form a comprehensive data input. This step can be achieved through string concatenation, array combination, etc.

[0051] 2. Hash calculation:

[0052] The combined data input is calculated by applying a hash function to generate a fixed-length hash value. The hash function performs complex mathematical operations on the input data, making the output hash value unique and irreversible.

[0053] 3. Generate token part:

[0054] The hash value is used as the token part generated by the distributed security module. Due to the changes in state information, timestamp and random number, the token part generated by each module is unique.

[0055] Example

[0056] Assuming that the state information of a distributed security module is "SystemState123", the timestamp is "2024-07-30T12:34:56.789Z", and the random number is "RandomValue456", the process of generating the token is as follows:

[0057] 1. Data combination:

[0058] Combined data = SystemState123 + 2024-07-30T12:34:56.789Z + RandomValue456

[0059] 2. Hash calculation:

[0060] Token part i =Hash(SystemState1232024-07-30T12:34:56.789ZRandomValue456)

[0061] 3. Generate hash value:

[0062] Assuming the hash function is SHA-256, the output hash value may be:

[0063] Token part i =e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

[0064] Through the above formula and process, the token part generated by each distributed security module is based on a unique combination of the current system state, timestamp and random number, ensuring the security and uniqueness of the generated token.

[0065] b. Mutual authentication of tokens

[0066] Each distributed security module 107 sends the generated token portion to other modules for mutual authentication.

[0067] The specific steps are as follows:

[0068] 1. Information exchange: Each distributed security module sends the generated token part and related status information, random numbers, etc. to other modules.

[0069] 2. Verification calculation: After receiving the information sent by other modules, each module independently calculates whether the received token part is correct. The specific verification steps are as follows:

[0070] Verify the results j =Verify(token part i , status information i , random number i )

[0071] Among them, the Verify function is used to verify whether the generated token part is consistent with the expectation;

[0072] The formula describes the specific logic of the token verification mechanism in a distributed security module system. The distributed security module verifies the correctness of the token through mutual information exchange and independent calculation. The following is the details of the formula

[0073] Detailed explanation:

[0074] "Verification Results" j =Verify("Token part" i ,"Status Information" i ,"Random Number" i )

[0075] The meaning of the formula is: module j uses the verification function Verify to independently verify the information received from module i (including the token part, state information, and random number) and obtain the verification result;

[0076] Where i: represents the module number (sender) of the sending token part. Each distributed security module has an independent number i to identify its identity in the system;

[0077] j: indicates the module number (receiver) that receives and verifies the token part. Similarly, j also indicates the identity of the verified module in the system.

[0078] "Token Section" i :

[0079] is a portion of the token data generated by module i.

[0080] The token part may be a fragment of the entire token, which is used to verify the integrity and security of the overall token.

[0081] "Status Information" i :

[0082] It is the relevant context information of module i when generating the token part.

[0083] It may include the module’s current internal state, generation rules, timestamps, etc., to assist in verification.

[0084] "Random Numbers" i :

[0085] is a random value generated by module i during the token generation process.

[0086] Random numbers are often used to add unpredictability to token generation, preventing attackers from performing attacks through pattern recognition or forgery.

[0087] Verify:

[0088] Is the verification function, receiving the "token part" i , "Status information" i , "Random Number" i As input, determine whether this information conforms to the expected rules or generation logic.

[0089] Validation criteria may include checking hash values ​​of token portions, cryptographic signatures, or other constraints.

[0090] Verification results ("Verification results" j ):

[0091] It is the Boolean result obtained after verification by module j, usually "passed" (True) or "failed" (False).

[0092] Verification success means that module j is confident that the token portion of module i is authentic.

[0093] Module i generates its own token part, state information and random number, and sends this data to other modules.

[0094] After receiving these data, module j verifies the received information through the Verify function.

[0095] The core of verification is to ensure that some data of the token is consistent, authentic and unforgeable, so as to achieve mutual trust and security verification between distributed modules.

[0096] 3.Consistency check: After all modules have been independently verified, the verification results will be fed back to the original sending module. Only when all modules have passed the verification, the token generation and transmission process is considered complete and secure.

[0097] c. Combined generation of dynamic security tokens

[0098] After all modules are successfully verified, they are combined to generate a complete dynamic security token. The specific steps are as follows:

[0099] 1. Token part combination: Each distributed security module combines the verified token parts to form a complete dynamic security token. The combination formula is as follows:

[0100] Complete token = Combine(token part 1, token part 2, ..., token part n )

[0101] Among them, the Combine function is used to combine the various parts of the token into a complete dynamic security token according to a predetermined order and rules.

[0102] d. Certification of Basic Input / Output System Add-on Modules

[0103] Use the generated dynamic security token and private key to authenticate the basic input / output system additional module 106. The specific steps are as follows:

[0104] 1. Additional module signature: The basic input / output system additional module 106 generates its digital signature, which contains the hash value of the additional module code.

[0105] 2. Token and key verification: The basic input / output system 103 uses the private key and the generated complete dynamic security token to decrypt and verify the digital signature of the additional module. The specific verification steps are as follows:

[0106] Add-on module hash = Hash(Add-on module code)

[0107] DecryptedHash = Decrypt(AdditionalModuleSignature,PrivateKey,DynamicToken)

[0108] Verification result = (additional module hash == decrypted hash)

[0109] Among them, the Decrypt function is used to decrypt the digital signature to obtain the hash value of the additional module, and the Hash function is used to calculate the current hash value of the additional module code.

[0110] 3. Authentication passed: If the verification result is true, it means that the authentication is passed, and the system loads and executes the basic input / output system additional module 106.

[0111] e. Real-time monitoring and recording

[0112] After the authentication is successful, during the process of loading and executing the basic input / output system additional module 106, the distributed security module 107 also monitors and records the entire authentication process in real time to ensure that any abnormal situation can be detected and handled in time. The specific steps are as follows:

[0113] 1. Monitoring log generation: Each distributed security module records all key operations and events in the authentication process, including token generation, verification, combination, authentication, etc.

[0114] 2. Log encryption storage: In order to prevent log data from being tampered with and unauthorized access, all monitoring log data is stored using encryption technology. The specific encryption algorithm can adopt advanced encryption standards such as AES-256.

[0115] 3. Anomaly detection: By analyzing monitoring log data in real time, the distributed security module can detect potential security threats and abnormal behaviors in a timely manner. For example, if illegal access attempts or data inconsistencies are found during the authentication process, the system will immediately trigger a security alarm and record detailed abnormal information.

[0116] 4. Security Audit: Regularly conduct security audits on monitoring log data, analyze and review all operations during the authentication process, and ensure the effectiveness and consistency of the system security policy. If any potential security risks are found, take corrective measures in a timely manner.

[0117] Through the above detailed implementation scheme, the dynamic security token generation and verification mechanism of the present invention can effectively improve the startup security and overall stability of the server system. The system realizes a dynamic, secure and efficient authentication process through the collaborative work of distributed security modules, ensuring that each loaded and executed module is strictly verified to prevent unauthorized programs from affecting the normal operation of the system.

[0118] Example 3: Security monitoring and recording mechanism

[0119] This embodiment introduces the security monitoring and recording functions of the distributed security module 107. In order to ensure the overall security of the system, the distributed security module 107 is equipped with an advanced monitoring and recording mechanism, as follows:

[0120] a. Real-time monitoring operation and data transmission

[0121] Each distributed security module 107 monitors all operations and data transmissions during the authentication process in real time to detect any abnormal behavior. The specific implementation steps include:

[0122] 1. Operation monitoring: Each security module monitors every step of its execution in real time, including token generation, verification, data transmission, etc. Operation monitoring is achieved by recording operation instructions and execution results.

[0123] 2. Data transmission monitoring: Monitor the data transmission process between modules to ensure that the data is not tampered with or lost during the transmission process. Data transmission monitoring includes recording the sending and receiving time of the data packet, the size of the data packet, the hash value of the data packet, etc.

[0124] 3. Anomaly detection: Using predetermined rules and machine learning algorithms, the operation and data transmission logs are analyzed in real time to detect abnormal behaviors, such as unauthorized operations, data packet duplication or loss, abnormal data packet content, etc. Once an anomaly is detected, an alarm is triggered immediately and detailed information is recorded.

[0125] b. Distributed logging mechanism

[0126] The system uses a distributed logging mechanism to record all key operations and status changes during the authentication process into the security log. The specific steps are as follows:

[0127] 1. Logging: Each distributed security module records the monitored operations and data transmission information in a local log. The log format is unified, including timestamp, operation type, operation result, data packet information, etc.

[0128] 2. Log synchronization: Regularly synchronize local logs to other distributed security modules to ensure distributed storage of log data. The synchronization process is carried out through an encrypted communication channel to prevent data leakage and tampering during transmission.

[0129] 3. Log integrity verification: After synchronization is completed, each module verifies the integrity of the log. The specific steps include:

[0130] Calculate the hash value of the local log.

[0131] Exchange and verify log hashes sent by other modules.

[0132] If log inconsistencies are found, the exception is recorded and an alert is triggered.

[0133] c. Distributed storage and management of log data

[0134] Security logs are distributed and managed by multiple modules to ensure the integrity and non-tamperability of log data. The specific implementation steps include:

[0135] 1. Distributed storage: Each distributed security module stores part of the log data and stores copies in other modules to form a redundant storage mechanism. The specific storage solution can use a distributed file system (such as HDFS) or blockchain technology.

[0136] 2. Data encryption: The stored log data is encrypted using advanced encryption algorithms (such as AES-256) to prevent unauthorized access. The log copies stored in each module are also encrypted.

[0137] 3. Access control: The access rights to log data are strictly controlled. Only authorized security modules and administrators can access and manage log data. Access control can be implemented through role-based access control (RBAC) policies.

[0138] d. Regularly check and analyze security logs

[0139] During the operation of the system, the distributed security module 107 regularly checks and analyzes security logs to promptly detect potential security threats and abnormal situations and take corresponding countermeasures. The specific implementation steps include:

[0140] 1. Log check: Regularly check the integrity and consistency of stored log data. The check steps include:

[0141] Verify the correctness of the log hash value.

[0142] Compare the consistency of local and replica log data.

[0143] Check for signs of loss or tampering in log data.

[0144] 2. Log analysis: Use data analysis tools and machine learning algorithms to regularly analyze log data to identify potential security threats and anomalies. The analysis steps include:

[0145] Cluster analysis: Identify unusual patterns and behaviors in logs.

[0146] Time series analysis: Detecting the temporal distribution of anomalous events in logs.

[0147] Anomaly detection: Identify unexpected abnormal behaviors based on machine learning models.

[0148] 3. Countermeasures: Once potential security threats and abnormal situations are discovered, the system will immediately take corresponding countermeasures, including but not limited to:

[0149] Trigger a security alert: Notify system administrators and related security modules.

[0150] Adjust security policies: Dynamically adjust the system's security policies and authentication mechanisms based on threats and abnormal situations.

[0151] Record detailed events: All discovered threats and anomalies are recorded in the security log for subsequent analysis and auditing.

[0152] Through the above detailed implementation scheme, the security monitoring and recording mechanism of the present invention can comprehensively improve the security and stability of the system. The system monitors all operations and data transmissions in the authentication process in real time through the coordinated work of distributed security modules, and uses advanced log recording and analysis technology to ensure that any abnormal situation can be detected and processed in time, thereby ensuring the overall security and reliability of the system.

[0153] Through the above embodiments, the present invention provides a server firmware startup system based on a distributed security module, which utilizes dynamically generated security tokens and a multi-level encryption authentication mechanism to effectively improve the startup security and overall stability of the server system.

[0154] The above description is only a preferred embodiment of the present invention, so all equivalent changes or modifications made according to the structure, characteristics and principles described in the scope of the patent application of the present invention are included in the scope of the patent application of the present invention.

Claims

1. A firmware startup system based on a distributed security module, characterized in that: The firmware startup system includes: A storage module (101) comprising a basic input / output system (103) and an initial encryption key database (104), wherein the basic input / output system (103) executes an initial program when the device is started, and the initial encryption key database (104) comprises an initial encryption key used to authenticate the legitimacy of the initial program; A physical storage medium (102) containing a custom database (105), wherein the secondary encryption key in the custom database (105) includes a dedicated key for authenticating a basic input / output system add-on module (106); A distributed security module (107) for generating a dynamic security token; Before loading the basic input / output system additional module (106), the firmware startup system confirms that the initial encryption key database (104) does not contain a key for authenticating the additional module, and uses a dedicated key and a dynamic security token to authenticate the basic input / output system additional module (106).

2. A firmware startup system based on a distributed security module as claimed in claim 1, characterized in that: The dynamic security token is generated by a plurality of the distributed security modules (107), each of the distributed security modules (107) is responsible for generating a part of the token, and each of the distributed security modules (107) performs mutual authentication.

3. A firmware startup system based on a distributed security module as claimed in claim 1, characterized in that: The firmware boot system comprises a plurality of distributed security modules (107), each of which is responsible for generating a part of a token and performing mutual authentication. After all distributed security modules (107) are successfully authenticated, they are combined to generate a complete dynamic security token. The generated dynamic security token and a dedicated key are used to authenticate a basic input / output system additional module (106), and after successful authentication, the basic input / output system additional module (106) is loaded and executed.

4. A firmware boot system based on a distributed security module as claimed in any one of claims 1 to 3, characterized in that: Each distributed security module (107) collects current system status information, including but not limited to timestamp, hardware status, operating system version, and random number; according to the hash algorithm, each distributed security module (107) generates the security token part it is responsible for using the collected system status information, timestamp and random number, and the specific formula is as follows: Token part i =Hash(status information i +Timestamp i +Random Numbers i ).

5. A firmware startup system based on a distributed security module as claimed in claim 4, characterized in that: Each distributed security module (107) sends the generated token part, state information and random number to other modules. After receiving the information sent by other modules, each module independently calculates whether the received token part is correct. The specific verification steps are as follows: Verify the results j =Verify(token part i , status information i , random number i ) Among them, the Verify function is used to verify whether the generated token part is consistent with the expectation; After all modules have been independently verified, the verification results will be fed back to the original sending module; when all modules have passed the verification, the token generation and transmission process is deemed complete and secure.

6. A firmware startup system based on a distributed security module as claimed in claim 5, characterized in that: Each of the distributed security modules combines the verified token parts to form a complete dynamic security token. The combination formula is as follows: Complete token = Combine(token part 1, token part 2, ..., token part n ) Among them, the Combine function is used to combine the various parts of the token into a complete dynamic security token according to a predetermined order and rules.

7. A firmware startup system based on a distributed security module as claimed in claim 6, characterized in that: The basic input / output system additional module (106) generates its digital signature, which includes a hash value of the additional module code. The basic input / output system (103) uses a dedicated key and a generated complete dynamic security token to decrypt and verify the digital signature of the basic input / output system additional module (106). If the verification result is true, the firmware boot system loads and executes the basic input / output system additional module (106).

8. A firmware startup system based on a distributed security module as claimed in claim 1, 5 or 6, characterized in that: The distributed security module (107) monitors operations and data transmission in real time, records operations and data transmission information during the authentication process, and detects abnormal behavior; records and synchronizes operations and data transmission information, and verifies log integrity; uses distributed storage and encryption technology to store log data, and strictly controls access rights; regularly checks and analyzes security logs, verifies log integrity and consistency, analyzes log data to identify security threats, and takes countermeasures.

9. A firmware startup system based on a distributed security module as claimed in claim 1, characterized in that: The device is a server device.

Images