A server firmware starting system based on a distributed security module

Abstract

The application provides a server firmware starting system based on distributed security modules, which comprises a storage module, a physical storage medium and distributed security modules. The storage module contains a basic input / output system and an initial encryption key database, which is responsible for executing the initial program and authenticating its legality when the device starts. The physical storage medium contains a custom database, which contains a special key for authenticating the basic input / output system additional module. Multiple distributed security modules generate dynamic security tokens and verify each other to ensure the integrity and security of the generation process. The system confirms that the initial encryption key database does not contain the key for authenticating the additional module before loading the basic input / output system additional module, and uses the special key and the dynamic security token to authenticate the additional module. The distributed security module also monitors the operation and data transmission in real time, records and analyzes the information in the authentication process, detects abnormal behavior and takes measures to ensure the security of the system.

Description

Technical Field

[0001] This invention relates to a server firmware boot system, and more particularly to a server firmware boot system based on a distributed security module. Background Technology

[0002] With the rapid development of information technology, servers, as a crucial infrastructure for information processing and storage, play a vital role in various application scenarios. The security and stability of server systems are directly related to the secure and reliable operation of the entire information system; therefore, the secure booting of server firmware has become a research hotspot. However, traditional server firmware booting systems have many security vulnerabilities, including but not limited to unauthorized firmware tampering and malware injection, which seriously threaten the security and integrity of server systems.

[0003] The Basic Input / Output System (BIOS) is a critical component in the computer boot process, responsible for initializing and testing system hardware components before the operating system loads. The security of the BIOS directly impacts the secure boot of the entire system. However, traditional BIOS primarily rely on statically stored encryption keys for verifying and authenticating the boot program, a method with significant limitations.

[0004] In traditional basic input / output (BII) systems, keys are stored statically, meaning they remain unchanged once stored. This static storage method presents significant security risks. First, because keys are statically stored, attackers can obtain the key information from the storage medium through various means. Once the keys are cracked or leaked, attackers can use them to bypass the BPI's authentication mechanism, thereby loading unauthorized malicious firmware or operating systems. Second, once a static key is set, it typically remains unchanged throughout the device's entire lifespan. This lack of dynamic update mechanisms means that once a key is leaked, the system will be at risk for a long time until the key is manually updated.

[0005] Furthermore, traditional basic input / output system authentication mechanisms typically rely on only one or a few static keys for authentication, which presents significant shortcomings. As attack methods become more diverse and complex, a single static key authentication mechanism proves inadequate and cannot effectively address the diverse security threats. For example, a single authentication mechanism cannot provide sufficient protection against different types of attacks (such as man-in-the-middle attacks and replay attacks). Moreover, a single authentication mechanism lacks flexibility and cannot be dynamically adjusted according to actual needs. This makes it difficult for the system to quickly respond to and adjust its authentication strategy when facing new security threats, making it vulnerable to exploitation by attackers.

[0006] More importantly, traditional basic input / output (BIO) systems lack dynamic security authentication mechanisms, making them vulnerable to threats in the face of real-time changing security environments. Because BIO systems cannot generate and verify dynamic security tokens in real time, they are susceptible to real-time attacks. Attackers can exploit this to launch attacks during system startup, bypassing static authentication mechanisms. Furthermore, facing constantly evolving security threats, BIO systems lack dynamic response capabilities and cannot adjust their security authentication policies according to real-time conditions. This static authentication method cannot meet the high security and high flexibility requirements of modern server systems.

[0007] In summary, traditional basic input / output systems have significant limitations and security vulnerabilities in terms of key management, authentication mechanisms, and dynamic security mechanisms. Summary of the Invention

[0008] To address the aforementioned problems in the prior art, this invention proposes a server firmware boot system based on a distributed security module, the firmware boot system comprising:

[0009] 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 contains initial encryption keys used to authenticate the legitimacy of the initial program.

[0010] The physical storage medium 102 contains a custom database 105, and the secondary encryption key within the custom database 105 includes a private key for authenticating the basic input / output system add-on module 106;

[0011] Distributed security module 107 is used to generate dynamic security tokens;

[0012] Before loading the Basic Input / Output System 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 uses a private key and a dynamic security token to authenticate the Basic Input / Output System Add-on Module 106.

[0013] The dynamic security token is generated by multiple distributed security modules 107, each of which is responsible for generating a portion of the token, and each of the distributed security modules 107 verifies each other.

[0014] The firmware boot system includes multiple distributed security modules 107. Each distributed security module 107 is responsible for generating a part of the token and verifying each other. After all distributed security modules 107 successfully verify each other, they combine to generate a complete dynamic security token. The generated dynamic security token and a private key are used to authenticate the basic input / output system add-on module 106. After successful authentication, the basic input / output system add-on module 106 is loaded and executed.

[0015] Each distributed security module 107 collects current system status information, including but not limited to timestamps, hardware status, operating system version, and random numbers. Based on a hash algorithm, each distributed security module 107 uses the collected system status information, timestamps, and random numbers to generate the security token portion it is responsible for, using the following formula:

[0016] Token section i =Hash(state information) i +timestamp i +random number i ).

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

[0018] Verification results j =Verify(token part) i Status information i random numbers i )

[0019] The Verify function is used to verify whether the generated token portion matches the expectation.

[0020] After all modules have completed independent verification, the verification results are fed back to the original sending module; when all modules pass the verification, the token generation and transmission process is considered complete and secure.

[0021] Each of the distributed security modules combines the verified token portions to form a complete dynamic security token, using the following combination formula:

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

[0023] The Combine function is used to combine individual tokens into a complete dynamic security token according to a predetermined order and rules.

[0024] The basic input / output system add-on module 106 generates its digital signature, which includes a hash value of the add-on module code. The basic input / output system 103 uses a private key and the generated full dynamic security token to decrypt and verify the digital signature of the basic input / output system add-on module 106. If the verification result is true, the firmware boot system loads and executes the basic input / output system add-on module 106.

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

[0026] The device in question is a server device.

[0027] This invention provides a server firmware boot system based on a distributed security module, which has the following advantages: The distributed security module generates and verifies dynamic security tokens, improving system security and attack resistance; the distributed log recording and storage mechanism ensures the transparency and traceability of the authentication process, preventing log data tampering; real-time monitoring and anomaly detection functions promptly detect and handle potential security threats, ensuring stable system operation; and strict access control and regular security audits further enhance the overall security level of the system, ensuring the reliability and security of the server device's firmware boot process. Attached Figure Description

[0028] The accompanying drawings, which are provided to further illustrate the invention and form part of this application, are not intended to unduly limit the invention. In the drawings:

[0029] Figure 1 This is a schematic diagram of the server firmware boot system based on a distributed security module according to the present invention. Detailed Implementation

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

[0031] Example 1: Firmware boot control system for servers

[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, while the physical storage medium 102 includes a custom database 105.

[0033] The basic input / output system 103 in storage module 101 is responsible for initializing and testing the hardware components and executing the initial program during server startup. The initial encryption key database 104 contains one or more sets of initial encryption keys used to authenticate the legitimacy of the initial program by verifying one or more initial encryption identifiers associated with it. However, these initial encryption keys do not contain keys used to authenticate the basic input / output system add-on module 106.

[0034] Before the Elementary Input / Output System Add-on 106 is loaded into the Elementary Input / Output System 103, the system first determines that the first set or more initial encryption keys in the initial encryption key database 104 do not contain a key for authenticating the add-on. Subsequently, the system verifies that the second set or more secondary encryption keys stored in the custom database 105 in the physical storage medium 102 include a dedicated key that can be used to authenticate the add-on 106.

[0035] Next, the system uses a dedicated key and a dynamically generated security token to authenticate the add-on module 106. The dynamically generated security token is generated by multiple distributed security modules 107, each responsible for generating a portion 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 of 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 comprises multiple distributed security modules 107, each responsible for generating a portion of the security tokens. The process includes the following steps:

[0038] a. Partial generation of dynamic security tokens

[0039] Upon system startup, each module in the distributed security module 107 generates a portion of the security token based on a predetermined algorithm and the current system state. The specific steps are as follows:

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

[0041] 2. Pre-defined algorithm application: Based on a pre-defined algorithm (such as the SHA-256 hash algorithm), each module generates its assigned security token portion using the collected system status information, timestamps, and random numbers. The specific formula is as follows:

[0042] Token section i =Hash(state information) i +timestamp i +random number i )

[0043] This formula describes the process by which each distributed security module 107 generates the security token it is responsible for. The following is a detailed explanation of each part of the formula:

[0044] 1. Status Information i This refers to the current operating status of the system, including various hardware and software information such as CPU load, memory usage, network status, and operating system version. This status information reflects the specific circumstances under which the system generated the token, making the generated token closely related to the system's actual operating state, thereby increasing security.

[0045] 2. Timestamp i The timestamp refers to the specific time when the token portion was generated, accurate to milliseconds or higher. The timestamp ensures that each generated token portion is unique, preventing replay attacks (i.e., attackers repeatedly using the same data packets to launch attacks).

[0046] 3. Random Numbers i This refers to a random value generated by the distributed security module, which should be different each time a token portion is generated. Random numbers increase unpredictability, ensuring that even with the same system state and timestamp, the generated token portion will differ, thus further enhancing security.

[0047] 4. Hash: A hash function (such as SHA-256) is an algorithm that transforms input data (a combination of state information, timestamps, and random numbers) into a fixed-length output data (hash value). Hash functions ensure that the input data generates a unique hash value after complex calculations. This hash value is highly irreversible (i.e., the original input cannot be deduced from the hash value), thus guaranteeing the security and integrity of the token portion.

[0048] The formula calculation process is as follows:

[0049] 1. Data Combination:

[0050] status information i timestamp i and random numbers iCombine the data to form a comprehensive input. This step can be achieved through string concatenation, array combination, or other methods.

[0051] 2. Hash calculation:

[0052] A hash function is applied to the combined input data to generate a fixed-length hash value. The hash function performs complex mathematical operations on the input data, ensuring that the output hash value is unique and irreversible.

[0053] 3. Token generation section:

[0054] The hash value serves as the token portion generated by this distributed security module. Due to variations in state information, timestamps, and random numbers, the token portion generated by each module is unique.

[0055] For example

[0056] Assuming 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 section 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 could be:

[0063] Token section i =e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

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

[0065] b. Mutual verification of the token portion

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

[0067] The specific steps are as follows:

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

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

[0070] Verification results j =Verify(token part) i Status information i random numbers i )

[0071] The Verify function is used to verify whether the generated token portion matches the expectation.

[0072] The formula describes the specific logic of the token verification mechanism in a distributed security module system. The distributed security modules verify the token's validity through mutual information exchange and independent computation. The following is a detailed explanation of the formula.

[0073] Detailed explanation:

[0074] "Verification Results" j =Verify("token portion") i "Status Information" i "random number" i )

[0075] The formula means that module j independently verifies the information received from module i (including the token part, status information, and random number) through the verification function Verify, and obtains the verification result.

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

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

[0078] "Token Section" i :

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

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

[0081] Status Information i :

[0082] This refers to the relevant context information of module i when generating the token.

[0083] This may include the module's current internal state, generation rules, timestamps, etc., to aid in verification.

[0084] "Random number" i :

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

[0086] Random numbers are often used to increase the unpredictability of token generation, preventing attackers from launching attacks through pattern recognition or forgery.

[0087] Verify:

[0088] This is the verification function, which receives the "token portion". i "Status Information" i "Random number" i As input, determine whether this information conforms to the expected rules or generation logic.

[0089] Verification criteria may include checking the hash value of the token portion, the cryptographic signature, or other constraints.

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

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

[0092] The successful verification means that module j is convinced that the token portion of module i is trustworthy.

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

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

[0095] The core of verification lies in ensuring that some data in the token is consistent, authentic, and unforgeable, thereby achieving mutual trust and secure verification between distributed modules.

[0096] 3. Consistency Check: After all modules have completed independent verification, the verification results are fed back to the original sending module. Only when all modules pass verification is the token generation and transmission process considered complete and secure.

[0097] c. Generation of dynamic security tokens

[0098] After all modules have been successfully verified, a complete dynamic security token is generated by combining them. The specific steps are as follows:

[0099] 1. Token Combination: Each distributed security module combines the verified token components 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] The Combine function is used to combine individual tokens into a complete dynamic security token according to a predetermined order and rules.

[0102] d. Authentication of the Basic Input / Output System Add-on Module

[0103] The basic input / output system add-on module 106 is authenticated using the generated dynamic security token and private key. The specific steps are as follows:

[0104] 1. Add-on module signature: The Basic Input / Output System Add-on 106 generates its digital signature, which contains a hash of the add-on module code.

[0105] 2. Token and Key Verification: The Basic Input / Output System 103 uses a dedicated key and the generated full dynamic security token to decrypt and verify the digital signature of the add-on module. The specific verification steps are as follows:

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

[0107] Decrypt hash = Decrypt(additional module signature, private key, dynamic token)

[0108] Verification result = (Additional module hash == Decryption hash)

[0109] The Decrypt function is used to decrypt the digital signature to obtain the hash value of the add-on module, and the Hash function is used to calculate the current hash value of the add-on module code.

[0110] 3. Authentication passed: If the verification result is true, the authentication is passed, and the system loads and executes the basic input / output system add-on module 106.

[0111] e. Real-time monitoring and recording

[0112] After successful authentication, during the loading and execution of the Basic Input / Output System add-on module 106, the distributed security module 107 also monitors and records the entire authentication process in real time to ensure that any anomalies are detected and handled promptly. 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. Encrypted Log Storage: To prevent log data from being tampered with and unauthorized access, all monitoring log data is stored using encryption technology. Specific encryption algorithms can employ advanced encryption standards such as AES-256.

[0115] 3. Anomaly Detection: By analyzing monitoring log data in real time, the distributed security module can promptly detect potential security threats and abnormal behaviors. For example, if an unauthorized access attempt or data inconsistency is detected during the authentication process, the system will immediately trigger a security alert and record detailed anomaly information.

[0116] 4. Security Audit: Regularly audit monitoring log data to analyze and review all operations during the authentication process, ensuring the effectiveness and consistency of the system security policy. If any potential security vulnerabilities are discovered, take remedial measures promptly.

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

[0118] Example 3: Security Monitoring and Recording Mechanism

[0119] This embodiment describes the security monitoring and recording functions of the distributed security module 107. 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 of operations and data transmission

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

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

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

[0124] 3. Anomaly Detection: Utilizing predefined rules and machine learning algorithms, the system analyzes operation and data transmission logs in real time to detect abnormal behavior, such as unauthorized operations, duplicate or lost data packets, and abnormal data packet content. Once an anomaly is detected, an alarm is immediately triggered and detailed information is recorded.

[0125] b. Distributed logging mechanism

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

[0127] 1. Logging: Each distributed security module records the operations and data transmission information it monitors to its local log. The log format is uniform, including timestamps, operation types, operation results, and data packet information.

[0128] 2. Log Synchronization: Local logs are periodically synchronized to other distributed security modules to ensure distributed storage of log data. The synchronization process is conducted through an encrypted communication channel to prevent data leakage and tampering during transmission.

[0129] 3. Log Integrity Verification: After synchronization is complete, each module verifies the integrity of the logs. Specific steps include:

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

[0131] Exchange and verify log hash values ​​sent by other modules.

[0132] If log inconsistencies are found, record the anomaly and trigger an alert.

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

[0134] The security log is stored and managed in a distributed manner by multiple modules to ensure the integrity and immutability of the log data. Specific implementation steps include:

[0135] 1. Distributed Storage: Each distributed security module stores a portion of the log data, with copies stored in other modules, forming a redundant storage mechanism. Specific storage solutions can employ distributed file systems (such as HDFS) or blockchain technology.

[0136] 2. Data Encryption: Stored log data is encrypted using advanced encryption algorithms (such as AES-256) to prevent unauthorized access. Each module's copy of the logs is also encrypted.

[0137] 3. Access Control: Access permissions for 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 system operation, the distributed security module 107 periodically checks and analyzes security logs to promptly identify potential security threats and anomalies, and takes corresponding countermeasures. Specific implementation steps include:

[0140] 1. Log Inspection: Regularly perform integrity checks and consistency verifications on the stored log data. The inspection steps include:

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

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

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

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

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

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

[0147] Anomaly detection: Based on machine learning models, it identifies unexpected and anomalous behaviors.

[0148] 3. Response Measures: Upon detecting potential security threats and anomalies, the system will immediately take corresponding response measures, including but not limited to:

[0149] Trigger a security alert: Notify the system administrator and relevant security modules.

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

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

[0152] Through the detailed implementation scheme described above, the security monitoring and recording mechanism of this invention can comprehensively improve the security and stability of the system. The system, through the collaborative work of distributed security modules, monitors all operations and data transmissions during the authentication process in real time, and utilizes advanced logging and analysis technologies to ensure that any anomalies are detected and handled promptly, thereby guaranteeing the overall security and reliability of the system.

[0153] Through the above embodiments, the present invention provides a server firmware boot system based on a distributed security module, which effectively improves the boot security and overall stability of the server system by utilizing dynamically generated security tokens and multi-layered encryption authentication mechanisms.

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

Claims

1. A firmware booting system based on a distributed security module, characterized by: The firmware boot system includes: 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) contains initial encryption keys used to authenticate the legitimacy of the initial program. The physical storage medium (102) contains a custom database (105), and the secondary encryption key within the custom database (105) includes a private key for authenticating the basic input / output system add-on module (106); The distributed security module (107) is used to generate dynamic security tokens; Before loading the Basic Input / Output System 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 uses a private key and a dynamic security token to authenticate the Basic Input / Output System Add-on Module (106). The firmware boot system includes multiple distributed security modules (107). Each distributed security module (107) is responsible for generating a part of the token and verifying each other. After all distributed security modules (107) successfully verify, they combine to generate a complete dynamic security token. The generated dynamic security token and a private key are used to authenticate the basic input / output system add-on module (106). After successful authentication, the basic input / output system add-on module (106) is loaded and executed. Each distributed security module (107) collects current system status information, including but not limited to timestamps, hardware status, operating system version, and random numbers. Based on a hash algorithm, each distributed security module (107) generates its assigned security token using the collected system status information, timestamps, and random numbers, with the specific formula as follows: 。 2. The firmware booting system based on the distributed security module according to claim 1, wherein: Each distributed security module (107) sends the generated token portion, status information, and random number to other modules. After receiving the information from other modules, each module independently calculates whether the received token portion is correct. The specific verification steps are as follows: wherein, The function serves to verify that the generated token part is consistent with the expected one; After all modules have completed independent verification, the verification results are fed back to the original sending module; when all modules pass the verification, the token generation and transmission process is considered complete and secure.

3. The firmware booting system based on the distributed security module according to claim 2, wherein: Each of the distributed security modules combines the verified token portions to form a complete dynamic security token, using the following combination formula: wherein, The function is used to combine the individual tokens into a complete dynamic security token in a predetermined order and rules.

4. The firmware booting system based on the distributed security module according to claim 3, wherein: The basic input / output system add-on module (106) generates its digital signature, which contains a hash value of the add-on module code. The basic input / output system (103) uses a private key and the generated full dynamic security token to decrypt and verify the digital signature of the basic input / output system add-on module (106). If the verification result is true, the firmware boot system loads and executes the basic input / output system add-on module (106).

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

6. The firmware boot system based on a distributed security module as described in claim 1, characterized in that: The device in question is a server device.

Images