External safety communication system of electric power trusted computing platform

Abstract

The invention discloses an external secure communication system of an electric power trusted computing platform, which is characterized in that the system reads a TPM (Trusted Platform Module) metric value, a start chain log and a trusted state report of the platform, performs secondary signature verification in combination with a lightweight hash verification model, ensures the trusted state of the platform, realizes physical and logic isolation by adopting optoelectronic isolation and an FPGA (Field Programmable Gate Array) logic firewall, and ensures the reliability of the platform. A dynamic session key is generated based on a national secret SM2 / SM4 algorithm and is bound with a platform TPM (Trusted Platform Module), the security of the key is ensured, an independent RTC (Real Time Clock) and a time signature chip are integrated, a non-tampering auditing log is generated, link packet loss supplementary transmission and signing verification are supported, and when an abnormal behavior is detected, a hardware relay is immediately triggered to disconnect a communication link, so that the safety of the communication link is ensured. And manual switching to an emergency local control mode is supported. The system provides multi-level security protection for the power trusted computing platform, and ensures the security, credibility and auditing performance of communication between the platform and external nodes.

Description

Technical Field

[0001] This invention relates to the field of power information security and trusted computing technology, and in particular to an external secure communication system suitable for power trusted computing platforms, which can realize high-level security protection for power business data throughout the entire process of transmission, verification, isolation, encryption and decryption, and trusted authentication. Background Technology

[0002] Existing power dispatching, monitoring, and management systems are rapidly transforming towards cloudification and platformization. The Trusted Computing Platform for Power Systems (TCPPS) can guarantee the trustworthiness of computing nodes within the platform. However:

[0003] 1. Trust Boundary Issues: The security and trust boundary of a power trusted computing platform typically only covers the internal workings of the platform. External communication links (such as those between the dispatch center and distributed power plants, energy storage stations, and distribution automation terminals) are easily targeted by attacks, making it difficult to guarantee end-to-end trust.

[0004] 2. External security access deficiencies: Existing technologies often rely on built-in gateways or software security modules for authentication and encryption. However, such solutions are susceptible to platform security vulnerabilities and cannot cope with "side-channel attacks" or "man-in-the-middle attacks".

[0005] 3. Insufficient Trustworthiness of Hardware-Software Hybrid Security: Current external security modules often only focus on encrypted transmission, lacking functions such as binding platform trust status, auditing communication behavior, and dynamic key management at the hardware level.

[0006] Therefore, there is a need for an external, secure communication device and system that can work with a trusted power computing platform. This device and system can achieve secure authentication and trusted negotiation independently through hardware, and automatically isolate external communication when the platform's security attributes are compromised, thereby improving the overall anti-attack capability. Summary of the Invention

[0007] The purpose of this section is to outline some aspects of embodiments of the present invention and to briefly describe some preferred embodiments. Simplifications or omissions may be made in this section, as well as in the abstract and title of this application, to avoid obscuring the purpose of these documents; however, such simplifications or omissions should not be construed as limiting the scope of the invention.

[0008] In view of the problems existing in the current trusted power computing platform, the present invention is proposed.

[0009] Therefore, the present invention aims to provide an external secure communication system for a power trusted computing platform, which is deployed in hardware outside the platform and achieves secure, controllable and auditable communication between the platform and external nodes through multi-layer trusted verification, isolated transmission channels and dynamic encryption strategies.

[0010] To address the aforementioned technical problems, this invention provides the following technical solution: an external secure communication system for a power trusted computing platform, comprising the following components: a trusted state awareness module, which periodically reads the platform's TPM metric value, startup chain log, and trusted state report through a secure interface, and synchronously uses a lightweight hash verification model built into the link to perform secondary signature verification of the platform state; a bidirectional isolation communication unit, which employs opto-isolation and FPGA logic firewall to achieve physical and logical isolation between the external wide area network side and the platform's internal network side; synchronously performs packet-level whitelist policy matching before data forwarding and performs anomaly detection based on a benchmark communication model; a dynamic key negotiation and management unit, which is based on the national cryptographic SM2 / SM4 algorithm and bound to the key derivation function of the platform's TPM to achieve session-level dynamic key generation; a trusted timestamp and security audit unit, which integrates an independent RTC and time signature chip to ensure the accuracy and immutability of the audit log time; and an abnormal behavior isolation response module, which immediately triggers a hardware relay to disconnect the communication link when the L-HV model or BTM detects abnormal data packets, abnormal key negotiation requests, or an untrusted platform state.

[0011] As a preferred embodiment of the external secure communication system of the power trusted computing platform described in this invention, the dynamic key negotiation and management unit immediately replaces the session key when it detects a change in the platform's trusted state or when the timer expires.

[0012] As a preferred embodiment of the external secure communication system of the power trusted computing platform described in this invention, the trusted timestamp and security audit unit includes: audit logs synchronized to an external security audit server, supporting packet loss retransmission and signature verification.

[0013] As a preferred embodiment of the external secure communication system of the power trusted computing platform described in this invention, the abnormal behavior isolation response module supports manual switching to emergency local control mode.

[0014] As a preferred embodiment of the external secure communication system of the power trusted computing platform described in this invention, the external secure communication system forms the following system architecture: platform trusted computing core → TSSM → DDICU → DKNMU → secure communication network; the platform's trusted state serves as a prerequisite for key negotiation, and communication will be terminated if any state is not met; audit logs form an immutable chain and are stored in TTSAU.

[0015] This invention provides an external secure communication system for a power trusted computing platform, which has the following advantages:

[0016] 1. External communication hardware driven by the platform's trusted state: The communication device is deployed entirely outside the platform and only allows data to pass when the platform is detected to be in a trusted state; unlike traditional software or built-in encryption modules;

[0017] 2. Physical-Logical Dual Isolation Path: The combination of FPGA logic firewall and opto-isolation prevents any cross-domain instruction injection attacks;

[0018] 3. Dynamic key binding to TPM status: The key update policy is bound to the platform's TPM metric in real time. When the platform status is changed by an attack, the key becomes invalid immediately.

[0019] 4. Model-based anomaly detection: Introducing L-HV and BTM models to provide packet-level and state-level detection capabilities, improving the recognition rate of unknown attacks;

[0020] 5. Immutable audit chain: All communication audit records are stored through hardware timestamps and a Merkle chain structure. Detailed Implementation

[0021] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the specification. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0022] To address the existing technical problems raised in this solution, this invention aims to provide an external secure communication system for a power trusted computing platform. This system is deployed in hardware outside the platform and achieves secure, controllable, and auditable communication between the platform and external nodes through multi-layer trusted verification, isolated transmission channels, and dynamic encryption strategies.

[0023] Specifically, the technical solution of the present invention includes:

[0024] An external secure communication device, comprising:

[0025] ① Trusted State Sensing Module (TSSM)

[0026] The platform's TPM (Trusted Platform Module) metrics, startup chain logs, and trusted state reports are periodically read through secure interfaces (such as SPI or I2C secure channels).

[0027] The platform status is verified by a secondary signature using the built-in Lightweight Hash Verification Model (L-HV).

[0028] It should be noted that the Trusted State Awareness Module (TSSM) is responsible for monitoring and verifying the trust status of the platform in real time, ensuring that external communication is only allowed when the platform is in a trust status.

[0029] 1. Functions and roles of TSSM

[0030] The primary function of TSSM is to perform secondary signature verification of the platform state by reading the platform's TPM metric, startup chain logs, and trusted state reports, combined with a lightweight hash verification model (L-HV). Its functions include:

[0031] Platform Trust Status Monitoring: Real-time reading of the platform's TPM metrics and startup chain logs to ensure that the platform has not been tampered with or infected.

[0032] Secondary signature verification: The platform status is verified a second time using the L-HV model to prevent the initial verification from being bypassed or tampered with.

[0033] Status transmission: The verification result is passed to subsequent modules (such as the bidirectional isolated communication unit DDICU) as a condition for communication to be allowed.

[0034] 2. Components of TSSM

[0035] (1) Security Interface

[0036] Function: To interact with the platform's TPM module via secure communication protocols (such as SPI or I2C) to ensure the security of data transmission.

[0037] Technical details:

[0038] SPI (Serial Peripheral Interface): A high-speed synchronous serial interface suitable for short-distance, high-bandwidth data transmission.

[0039] I2C (Integrated Circuit Interconnect Bus): A low-speed, short-distance communication protocol suitable for data transmission between simple devices.

[0040] Security features: An encrypted transmission mechanism is used to prevent data from being eavesdropped on or tampered with during transmission.

[0041] (2) TPM measurement reading module

[0042] Function: Reads metrics from the platform's TPM module, including PCR (Platform Configuration Register) values.

[0043] Technical details:

[0044] PCR (Platform Configuration Registers): Records a summary of key events during the system startup process, reflecting the system's trusted state.

[0045] Measurement value reading: Obtain PCR values ​​and signatures through the TPM GetQuote command to ensure data integrity and authenticity.

[0046] (3) Start the chain log analysis module

[0047] Function: Analyze the platform's startup chain logs to ensure that every step of the startup process is trustworthy.

[0048] Technical details:

[0049] Boot chain log: Records every step of the system's operation from startup to running, including BIOS loading, operating system initialization, etc.

[0050] Log verification: Verify the integrity of the startup chain log through a hash chain to ensure that the log has not been tampered with.

[0051] (4) Trusted State Report Parsing Module

[0052] Function: Parse the platform's trusted state report to obtain the current trusted state of the system.

[0053] Technical details:

[0054] Trusted State Report: A summary report containing TPM metrics, startup chain logs, and other relevant security information.

[0055] Report Verification: Verify the digital signature of the report to ensure its integrity and authenticity.

[0056] (5) Lightweight Hash Verification Model (L-HV)

[0057] Function: Perform secondary signature verification on the platform status to ensure the platform status is authentic and trustworthy.

[0058] Technical details:

[0059] Input data: TPM metric (PCR value), startup chain log.

[0060] Hash operation: The SM3 hash algorithm is used to perform a digest operation on the input data.

[0061] Benchmark comparison: The generated digest is compared with the initial benchmark value stored in secure Flash.

[0062] Output: Generate trusted / untrusted flags and pass them to subsequent modules.

[0063] 3. The computational process of the Lightweight Hash Verification Model (L-HV)

[0064] (1) Data Acquisition

[0065] Read PCR values ​​and starter chain logs from the TPM module.

[0066] Ensure the integrity and authenticity of the data to prevent it from being tampered with.

[0067] (2) Data preprocessing

[0068] The collected data is formatted to ensure that the input data meets the requirements of the L-HV model.

[0069] For example, PCR values ​​and startup chain logs can be concatenated into a single data block.

[0070] (3) Hash operation

[0071] The SM3 hash algorithm is used to perform a digest operation on the preprocessed data block to generate a fixed-length hash value.

[0072] Calculation process:

[0073] Initialize the hash context.

[0074] Input data blocks are entered one by one and compressed.

[0075] Generate the final hash value.

[0076] (4) Benchmark value comparison

[0077] The generated hash value is compared with the initial baseline value stored in secure Flash.

[0078] Initial baseline value: The hash value generated by the L-HV model when the platform is shipped or in an initial trusted state, which serves as a reference for subsequent verification.

[0079] Comparison results:

[0080] Matching: If the platform status is trustworthy, output the trustworthy flag.

[0081] Mismatch: The platform status is untrusted; output the untrusted flag.

[0082] (5) Result Transmission

[0083] The verification result (trusted / untrusted flag) is passed to the Two-Way Isolated Communication Unit (DDICU) as a condition for communication to be allowed.

[0084] 4. TSSM's collaboration with other modules

[0085] The role of TSSM in the system is not limited to verifying the platform's trusted status; it also needs to work in conjunction with other modules to ensure the overall security of the system.

[0086] (1) Coordination with the Two-Way Isolated Communication Unit (DDICU)

[0087] Data transmission: TSSM transmits the verification result to DDICU as a condition for communication to be allowed.

[0088] Communication control: DDICU allows data to pass after receiving the trusted flag bit; otherwise, it disconnects the communication link.

[0089] (2) Collaboration with the Dynamic Key Negotiation and Management Unit (DKNMU)

[0090] Key generation conditions: After receiving the trusted flag, DKNMU triggers the key negotiation process to generate a dynamic session key.

[0091] Key Update: When TSSM detects a change in the platform's trusted state, it immediately notifies DKNMU to change the session key.

[0092] (3) Collaboration with Trusted Timestamps and Security Audit Unit (TTSAU)

[0093] Audit Log Recording: The verification results of TSSM are recorded in the TTSAU audit log to ensure the integrity of the audit records.

[0094] Timestamp synchronization: TTSAU provides accurate timestamps for TSSM's verification operations, ensuring the time accuracy of audit logs.

[0095] (4) Collaboration with the Abnormal Behavior Isolation Response Module (AIRM)

[0096] Anomaly Detection: When TSSM detects that the platform status is untrusted, it triggers AIRM's anomaly isolation response mechanism to disconnect the communication link.

[0097] Emergency Control: AIRM supports manual switching to emergency local control mode to ensure system safety.

[0098] 5. Technological advantages of TSSM

[0099] Security: The platform's status is ensured to be authentic and trustworthy through secondary signature verification, preventing the initial verification from being bypassed or tampered with.

[0100] High efficiency: It adopts a lightweight hash verification model (L-HV) to reduce the consumption of computing resources while ensuring security.

[0101] Reliability: By working in collaboration with multiple modules, the overall system's resistance to attacks and security are ensured.

[0102] The Trusted State Awareness Module (TSSM) reads the platform's TPM metric values, startup chain logs, and trusted state reports, and uses a lightweight hash verification model (L-HV) to perform secondary signature verification of the platform's state, ensuring that communication is only allowed when the platform is in a trusted state. Its collaborative work with other modules provides multi-layered security protection for the power trusted computing platform, ensuring the security, trustworthiness, and auditability of communication between the platform and external nodes.

[0103] ② Dual-Domain Isolation Communication Unit (DDICU)

[0104] The system employs opto-isolation combined with an FPGA logic firewall to achieve physical and logical isolation between the external WAN side and the platform's internal network side.

[0105] Before data forwarding, packet-level whitelist policy matching is performed, and anomaly detection is performed based on the Baseline Traffic Model (BTM).

[0106] It should be noted that the Dual-Domain Isolation Communication Unit (DDICU) is responsible for achieving physical and logical isolation between the external wide area network and the platform's internal network, ensuring the security and reliability of communication.

[0107] 1. Functions and roles of DDICU

[0108] DDICU's main function is to achieve physical and logical isolation through opto-isolation and FPGA logical firewalls, while performing packet-level whitelist policy matching and anomaly detection based on the Baseline Communication Model (BTM) before data forwarding. Its functions include:

[0109] Physical isolation: Prevents external networks from directly attacking internal networks via electrical current.

[0110] Logical isolation: Controlling the transmission of data packets through an FPGA firewall to ensure that only data packets that conform to the rules can pass through.

[0111] Anomaly detection: Based on the BTM model, detects abnormal traffic and prevents unknown attacks.

[0112] 2. Components of DDICU

[0113] (1) Opto-isolation module

[0114] Function: To achieve physical isolation between the external WAN side and the platform's internal network side, preventing cross-domain attacks.

[0115] Technical details:

[0116] Optocoupler: Uses LEDs and photosensitive elements to convert electrical signals into optical signals, and then back into electrical signals, thus cutting off direct electrical connections.

[0117] Transmission delay: typically less than 50 nanoseconds, ensuring real-time communication.

[0118] Bandwidth: Supports high-speed data transmission to meet the needs of power services.

[0119] (2) FPGA logic firewall

[0120] Function: Controls data packet transmission through customized logic circuits to achieve logical isolation.

[0121] Technical details:

[0122] Logical structure: FPGA-based programmable logic to implement data packet parsing, rule matching, and forwarding control.

[0123] Rule matching algorithm: Supports multiple rule matching, such as 5-tuple (source address, destination address, source port, destination port, protocol type) matching.

[0124] Processing speed: Supports high-speed data packet processing to ensure efficient communication.

[0125] (3) Package-level whitelist policy matching module

[0126] Function: Before data forwarding, each data packet is matched against a whitelist policy to ensure that the data packet conforms to predefined rules.

[0127] Technical details:

[0128] Whitelist generation: Generate whitelist rules based on the platform's normal communication needs.

[0129] Policy update mechanism: Supports dynamic updates to whitelist rules to adapt to changes in business needs.

[0130] Policy effective time: Configure the effective time of the policy to ensure the security and flexibility of communication.

[0131] (4) Baseline Communication Model (BTM)

[0132] Function: By analyzing the traffic characteristics of normal communication, a benchmark model is established to detect abnormal traffic.

[0133] Technical details:

[0134] Data acquisition: Acquiring the normal communication traffic of the platform, including characteristics such as packet length, protocol type, and time interval.

[0135] Model training: Model normal traffic using machine learning algorithms (such as clustering algorithms) to generate a baseline model.

[0136] Model update frequency: The baseline model is updated regularly to adapt to changes in communication patterns.

[0137] (5) Anomaly Detection and Response Module

[0138] Function: When real-time traffic differs significantly from the BTM model, an anomaly detection mechanism is triggered, and corresponding response measures are taken.

[0139] Technical details:

[0140] Anomaly detection algorithms: These use statistical methods or machine learning algorithms to detect abnormal traffic behavior.

[0141] Response measures include logging the anomaly and triggering a hardware relay to disconnect the communication link.

[0142] 3. DDICU Workflow

[0143] (1) Physical isolation

[0144] Data from the external WAN side enters DDICU through an opto-isolation module, severing the direct electrical connection and preventing cross-domain attacks.

[0145] (2) Logical isolation

[0146] Data packets enter the FPGA logic firewall for rule matching and logic control.

[0147] Only packets that conform to the whitelist policy can pass through the firewall; other packets are dropped or marked as abnormal.

[0148] (3) Package-level whitelist policy matching

[0149] Each data packet is matched against a whitelist policy to ensure that the data packet conforms to the predefined rules.

[0150] Whitelist rules can be configured and updated according to actual needs.

[0151] (4) Anomaly detection based on BTM

[0152] Real-time traffic is compared with the BTM model to detect abnormal behavior.

[0153] When abnormal traffic is detected, the anomaly detection and response module is triggered to take appropriate measures.

[0154] (5) Data forwarding

[0155] Data packets that meet the rules are forwarded through DDICU to the platform's intranet or external WAN.

[0156] 4. DDICU's technological advantages

[0157] Physical isolation: Opto-isolation modules are used to prevent external networks from directly attacking the internal network via electrical current.

[0158] Logical isolation: Through the FPGA firewall, the transmission of data packets is controlled to ensure that only data packets that conform to the rules can pass through.

[0159] Packet-level whitelist strategy: Enables fine-grained traffic control and improves communication security.

[0160] Model-based anomaly detection: Detects abnormal traffic and prevents unknown attacks using the BTM model.

[0161] High efficiency: Supports high-speed data packet processing, ensuring real-time and high-efficiency communication.

[0162] The Two-Way Isolated Communication Unit (DDICU) achieves physical and logical isolation through opto-isolation and an FPGA logic firewall. Simultaneously, it performs packet-level whitelist policy matching and anomaly detection based on the Baseline Communication Model (BTM) before data forwarding, ensuring the security and trustworthiness of communication between the platform and external nodes. Its collaborative work with other system modules provides multi-layered security protection for the power trusted computing platform, ensuring the security, trustworthiness, and auditability of communication between the platform and external nodes.

[0163] ③ Dynamic Key Negotiation and Management Unit (DKNMU)

[0164] Based on the national cryptographic SM2 / SM4 algorithm and bound to the key derivation function of TPM within the platform, session-level dynamic key generation is realized.

[0165] The session key is replaced immediately upon detecting a change in the platform's trusted state or when the timeout expires.

[0166] It should be noted that the Dynamic Key Negotiation and Management Unit (DKNMU) is responsible for generating and managing dynamic session keys to ensure the security and trustworthiness of communication.

[0167] 1. The main functions of DKNMU include:

[0168] Dynamic key generation: Based on the national cryptographic SM2 / SM4 algorithm, session-level dynamic keys are generated.

[0169] Key binding with TPM: Bind the key generation to the key derivation function of the TPM within the platform to ensure key security.

[0170] Key update mechanism: The session key is immediately replaced when a change in the platform's trusted state is detected or the timeout expires.

[0171] 2. DKNMU consists of the following key components:

[0172] (1) SM2 / SM4 encryption engine

[0173] Function: Implements SM2 elliptic curve key exchange and SM4 block cipher algorithm.

[0174] Technical details:

[0175] SM2 algorithm: Based on elliptic curve cryptography, it provides efficient key exchange capabilities.

[0176] SM4 algorithm: Block cipher algorithm used for data encryption and decryption to ensure the confidentiality of communication content.

[0177] Hardware acceleration: Improve the efficiency of encryption operations through dedicated hardware accelerators.

[0178] (2) TPM Interface Module

[0179] Function: Communicates with the TPM module within the platform to obtain key derivation functions.

[0180] Technical details:

[0181] TPM command interface: Interact with TPM modules through standard TPM commands (such as GetQuote, Sign, etc.).

[0182] Key derivation function: Combines the PCR value of TPM, random number and timestamp to generate a dynamic session key.

[0183] (3) Key Management Module

[0184] Function: Responsible for the generation, storage, and updating of keys.

[0185] Technical details:

[0186] Key generation strategy: Generate session keys based on platform trust status, random numbers, and timestamps.

[0187] Key storage: Use secure storage media (such as secure Flash) to store keys to prevent them from being tampered with or leaked.

[0188] Key update mechanism: Supports updates triggered by changes in the platform's trusted state and updates triggered by timeout expiration.

[0189] (4) Status monitoring module

[0190] Function: Monitors the platform's trust status and key validity period, and triggers key updates.

[0191] Technical details:

[0192] Platform Trust Status Monitoring: Receives the verification results from TSSM to determine whether the platform is in a trusted state.

[0193] Key validity period management: Set the validity period of the session key, usually 5 minutes, which can be adjusted according to needs.

[0194] 3. Technical Details

[0195] (1) SM2 algorithm

[0196] Elliptic curve key exchange:

[0197] Parameter selection: Select the elliptic curve parameters recommended by the State Cryptography Administration.

[0198] Key generation: A shared key is generated based on the multiplication of elliptic curve points.

[0199] Security: It has the ability to resist quantum attacks, ensuring the security of key exchange.

[0200] (2) SM4 algorithm

[0201] Block encryption:

[0202] Encryption modes: Supports multiple encryption modes, such as ECB (Electronic Codebook) and CBC (Cryptographic Block Chain).

[0203] Key length: Supports 128-bit keys to ensure encryption strength.

[0204] Hardware acceleration: Improve the efficiency of encryption operations through dedicated hardware accelerators.

[0205] (3) Key derivation function

[0206] Key generation formula:

[0207] Key = KDF(TPM_PCR, Session_Random, Timestamp)

[0208] TPM_PCR: PCR value of the platform's trustworthiness status.

[0209] Session_Random: Session random number, increases the randomness of the key.

[0210] Timestamp: A timestamp that ensures the validity of the key.

[0211] KDF (Key Derivation Function): Uses the SM3 hash algorithm to perform a digest operation on the above parameters and generate the final session key.

[0212] (4) Key update strategy

[0213] Triggering conditions:

[0214] Platform Trust Status Change: When TSSM detects that the platform status is untrusted, it immediately changes the session key.

[0215] Session key validity period: The session key is valid for 5 minutes by default and will be replaced immediately after expiration.

[0216] Update process:

[0217] Key generation: Generate a new session key based on the new TPM_PCR, Session_Random, and Timestamp.

[0218] Key distribution: Distribute the new session key to both communicating parties to ensure the correctness of data encryption and decryption.

[0219] Old key destruction: Immediately destroy old session keys to prevent them from being exploited.

[0220] 4. Work Process

[0221] The DKNMU workflow can be divided into the following steps:

[0222] (1) Key generation

[0223] When the platform is in a trusted state, the key negotiation process is triggered.

[0224] Elliptic curve key exchange is performed using the SM2 algorithm to generate a shared key.

[0225] The shared key is encrypted using the SM4 algorithm to generate a session key.

[0226] (2) Key update

[0227] The key update process is triggered when the platform's trusted status changes or the key expires.

[0228] Generate a new session key and distribute it to both communicating parties.

[0229] Destroy old session keys to ensure security.

[0230] (3) Key distribution

[0231] Distribute the session key to both communicating parties to ensure the correctness of data encryption and decryption.

[0232] Use secure communication protocols (such as SPI or I2C) for key distribution to prevent eavesdropping or tampering.

[0233] 5. DKNMU works in conjunction with other modules in the system to ensure the overall system security:

[0234] (1) Synergy with TSSM

[0235] Platform Trust Status Monitoring: Receives the verification result of TSSM as a prerequisite for key generation.

[0236] Key update trigger: The session key is immediately replaced when the platform's trusted state changes.

[0237] (2) Collaboration with DDICU

[0238] Key provision after communication is granted: After the communication link is granted, a session key is provided to ensure encrypted data transmission.

[0239] Anomaly Detection Response: When an anomaly is detected, a key replacement is triggered to prevent key leakage.

[0240] (3) Synergy with TTSAU

[0241] Key generation and update logging: Records operation logs for key generation and updates to ensure the integrity of the audit.

[0242] Timestamp synchronization: Uses precise timestamps provided by TTSAU to ensure the timeliness of keys.

[0243] (4) Synergy with AIRM

[0244] Anomaly Detection Response: When an anomaly is detected, a key replacement is triggered to prevent key leakage.

[0245] Emergency control support: Ensures key security in emergency local control mode.

[0246] 6. Technological Advantages

[0247] Dynamic key generation: Ensures that a different key is used for each session, improving security.

[0248] Key binding to TPM: Key updates are bound to platform status to prevent keys from being bypassed or tampered with.

[0249] Efficiency: The use of national cryptographic algorithms and hardware acceleration ensures the high efficiency of key generation and updates.

[0250] The Dynamic Key Negotiation and Management Unit (DKNMU) provides a high level of security for the power trusted computing platform by generating and managing dynamic keys based on the national cryptographic algorithms SM2 / SM4, combined with platform trusted status monitoring. Its collaborative work with other system modules ensures the security, trustworthiness, and auditability of communication between the platform and external nodes, effectively preventing the risks of unknown attacks and key leakage.

[0251] ④ Trusted Timestamp & Secure Audit Unit (TTSAU)

[0252] It integrates an independent RTC and time signature chip to ensure that the audit logs are accurate and tamper-proof in terms of time.

[0253] Audit logs are synchronized to an external security audit server, supporting packet loss retransmission and signature verification.

[0254] It should be noted that the Trusted Timestamp & SecureAudit Unit (TSAU) is responsible for generating and managing trusted timestamps to ensure the accuracy and immutability of audit logs, while also supporting the synchronization, packet loss retransmission, and verification of audit logs.

[0255] 1. The main functions of TTSAU include:

[0256] Trusted timestamp generation: Provides accurate timestamps through independent RTC to ensure the time accuracy of audit logs.

[0257] Audit log signing: Use a time signature chip to digitally sign audit logs to prevent tampering.

[0258] Audit log synchronization: Synchronize audit logs to an external security audit server to ensure data integrity and availability.

[0259] Packet loss retransmission and verification: Supports retransmission of lost packets and performs signature verification on the retransmitted data to ensure the integrity and authenticity of the data.

[0260] 2. TTSAU consists of the following key components:

[0261] (1) Independent RTC module

[0262] Function: Provides high-precision timestamps to ensure the time accuracy of audit logs.

[0263] Technical details:

[0264] RTC chip: Uses a high-precision RTC chip (such as DS3231) that supports ±2ppm accuracy.

[0265] Power Management: Even in the event of a power outage, the RTC module can maintain time accuracy and ensure the continuity of timestamps.

[0266] Time synchronization: Supports periodic synchronization via Network Time Protocol (NTP) to ensure the accuracy of timestamps.

[0267] (2) Time signature chip

[0268] Function: Digitally sign audit logs to ensure their integrity and authenticity.

[0269] Technical details:

[0270] Encryption algorithm: The audit logs are signed using the SM2 / SM3 algorithm.

[0271] SM2: Elliptic Curve Cryptography, used to generate digital signatures.

[0272] SM3: A hash algorithm used to generate data digests.

[0273] Signature process:

[0274] Perform SM3 hashing on the audit logs to generate a data digest.

[0275] The SM2 algorithm is used to sign the data digest, generating a digital signature.

[0276] Attaching digital signatures to audit logs ensures the integrity and authenticity of the data.

[0277] (3) Audit log generation and storage module

[0278] Function: Generate audit logs and store them in secure storage media.

[0279] Technical details:

[0280] Audit log content includes timestamps, source / destination addresses, packet digests (such as SM3 hash values), and other information.

[0281] Storage format: Audit logs are stored in a structured format for easy subsequent analysis and processing.

[0282] Storage media: Secure flash storage media is used to prevent audit logs from being tampered with or leaked.

[0283] Storage encryption: Encrypt the stored audit logs to ensure data security.

[0284] (4) Audit log synchronization module

[0285] Function: Synchronize audit logs to an external security audit server.

[0286] Technical details:

[0287] Transport protocol: HTTPS protocol is used for data transmission to ensure data confidentiality and integrity.

[0288] Transmission frequency: Based on system configuration, audit logs are synchronized periodically to ensure data timeliness.

[0289] Data compression: Compress audit logs to reduce bandwidth usage.

[0290] Data packetization: The audit logs are transmitted in packets to prevent transmission failures caused by excessively large single packets.

[0291] (5) Packet Loss Retransmission and Verification Module

[0292] Function: When packet loss occurs during the transmission of audit logs, it supports retransmission and verifies the retransmitted data.

[0293] Technical details:

[0294] Packet loss detection: Detects packet loss by serial number and records the loss in the audit log.

[0295] Retransmission mechanism: Retransmit lost audit logs to ensure data integrity.

[0296] Signature verification: The retransmitted audit logs are signed to ensure the integrity and authenticity of the data.

[0297] Retransmission limit: Set an upper limit on the number of retransmissions to prevent system resources from being exhausted due to retransmission failures.

[0298] 3. Technical Details

[0299] (1) Credible timestamp generation

[0300] RTC chip: Uses a high-precision RTC chip (such as DS3231) that supports ±2ppm accuracy.

[0301] Time synchronization: Time is synchronized periodically via the NTP protocol to ensure the accuracy of timestamps.

[0302] Power failure protection: The RTC module uses battery backup to ensure continuity of time in the event of a power failure.

[0303] (2) Audit log signature

[0304] SM3 hash operation:

[0305] Perform an SM3 hash operation on the audit log content to generate a fixed-length data digest.

[0306] Ensure the uniqueness and collision resistance of the data summary.

[0307] SM2 digital signature:

[0308] The data digest is signed using the SM2 elliptic curve cryptography algorithm.

[0309] The signature result is appended to the audit log to ensure the integrity and authenticity of the data.

[0310] (3) Audit log storage

[0311] Storage format:

[0312] Audit logs are stored in JSON or XML format for easy parsing and analysis later.

[0313] Each audit log entry includes information such as timestamp, source / destination address, and packet summary.

[0314] Storage encryption:

[0315] The SM4 algorithm is used to encrypt the stored audit logs to prevent data leakage.

[0316] The encryption key is stored in a secure storage medium to prevent it from being tampered with or leaked.

[0317] (4) Audit log synchronization

[0318] Transmission protocol:

[0319] Using the HTTPS protocol for data transmission ensures the confidentiality and integrity of the data.

[0320] During transmission, the audit logs are encrypted to prevent eavesdropping or tampering.

[0321] Transmission frequency:

[0322] According to the system configuration, the audit logs are synchronized regularly to ensure the timeliness of the data.

[0323] The transmission frequency can be dynamically adjusted to adapt to changes in business needs.

[0324] Data compression:

[0325] Compress audit logs to reduce bandwidth usage.

[0326] Commonly used compression algorithms include GZIP and ZIP. Choose the appropriate algorithm based on your actual needs.

[0327] (5) Packet loss retransmission and verification

[0328] Packet loss detection:

[0329] Packet loss is detected by serial number, and the lost data is recorded in the audit log.

[0330] Serial numbers are generated based on timestamps and audit log content to ensure uniqueness.

[0331] Replacement pass mechanism:

[0332] Retransmit the lost audit logs to ensure data integrity.

[0333] During the retransmission process, the audit logs were re-signed to ensure the integrity and authenticity of the data.

[0334] Signature verification:

[0335] The retransmitted audit logs are signed and verified to ensure the integrity and authenticity of the data.

[0336] The verification process includes SM3 hash operation and SM2 signature verification.

[0337] Retransmission limit:

[0338] Set a maximum number of retransmissions (e.g., 3 times) to prevent system resources from being exhausted due to retransmission failures.

[0339] After exceeding the retransmission limit, record the packet loss event for subsequent analysis and processing.

[0340] 4. The TTSAU workflow can be divided into the following steps:

[0341] (1) Audit log generation

[0342] Receive audit events from various modules of the system (such as changes in the platform's trusted status, key negotiation process, anomaly detection, etc.).

[0343] Generate audit logs, including timestamps, source / destination addresses, packet summaries, and other information.

[0344] (2) Audit log signature

[0345] Perform SM3 hashing on the audit logs to generate a data digest.

[0346] The SM2 algorithm is used to sign the data digest, generating a digital signature.

[0347] Attaching digital signatures to audit logs ensures the integrity and authenticity of the data.

[0348] (3) Audit log storage

[0349] Signed audit logs are stored in secure Flash to ensure data security.

[0350] Audit logs are stored in encrypted form to prevent tampering or leakage.

[0351] (4) Audit log synchronization

[0352] Regularly synchronize the stored audit logs to an external security audit server.

[0353] Using the HTTPS protocol for data transmission ensures the confidentiality and integrity of the data.

[0354] (5) Packet loss retransmission and verification

[0355] When packet loss occurs during audit log transmission, the missing audit logs are detected.

[0356] The lost audit logs are retransmitted, and the retransmitted data is signed and verified.

[0357] Ensure the integrity and authenticity of data to prevent data loss or tampering due to packet loss.

[0358] 5. TTSAU works in conjunction with other modules in the system to ensure the overall system security:

[0359] (1) Synergy with TSSM

[0360] Audit event logging: Receive platform trusted status change events from TSSM and log them in the audit log.

[0361] Timestamp synchronization: Receives timestamps from TSSM to ensure the time accuracy of audit logs.

[0362] (2) Collaboration with DDICU

[0363] Audit event logging: Receive events such as communication release and anomaly detection from DDICU and record them in the audit log.

[0364] Timestamp synchronization: Receive timestamps from DDICU to ensure the time accuracy of audit logs.

[0365] (3) Synergy with DKNMU

[0366] Audit event logging: Receive key negotiation, key update and other events from DKNMU and record them in the audit log.

[0367] Timestamp synchronization: Receives timestamps from DKNMU to ensure the time accuracy of audit logs.

[0368] (4) Synergy with AIRM

[0369] Audit event logging: Receive AIRM events such as abnormal isolation and emergency control, and record them in the audit log.

[0370] Timestamp synchronization: Receives AIRM timestamps to ensure the time accuracy of audit logs.

[0371] 6. Technological Advantages

[0372] Trusted timestamps: The accuracy and continuity of timestamps are ensured through independent RTC and NTP synchronization.

[0373] Audit log signing: Audit logs are signed using SM3 and SM2 algorithms to ensure data integrity and authenticity.

[0374] Audit log synchronization: Supports regular synchronization of audit logs and packet loss retransmission to ensure data integrity and availability.

[0375] High security: Audit logs are stored and transmitted in encrypted form to prevent tampering or leakage.

[0376] The Trusted Timestamp and Security Audit Unit (TTSAU) ensures the time accuracy and immutability of audit logs by integrating an independent RTC and time signature chip. It also supports audit log synchronization, packet loss retransmission, and verification, providing a high level of security auditing capabilities for the power trusted computing platform. Its collaborative work with other system modules ensures the security, trustworthiness, and auditability of communication between the platform and external nodes, effectively preventing the risk of data tampering and loss.

[0377] ⑤ Anomaly Isolation Response Module (AIRM)

[0378] When the L-HV model or BTM detects abnormal data packets, abnormal key negotiation requests, or an untrusted platform state, it immediately triggers a hardware relay to disconnect the communication link.

[0379] It supports manual switching to emergency local control mode.

[0380] It should be noted that the Anomaly Isolation Response Module (AIRM) is responsible for immediately triggering a hardware relay to disconnect the communication link upon detecting abnormal behavior, preventing further propagation of the attack. Furthermore, it supports manual switching to an emergency local control mode to ensure basic system operation under abnormal circumstances.

[0381] 1. Module Functions and Roles

[0382] AIRM's main functions include:

[0383] Abnormal behavior detection: Receives abnormal detection signals from other modules (such as TSSM, DDICU, DKNMU).

[0384] Communication link isolation: Upon detecting abnormal behavior, a hardware relay is immediately triggered to disconnect the communication link, preventing the spread of attacks.

[0385] Emergency Local Control Mode Switching: Supports manual switching to emergency local control mode to ensure basic system operation in abnormal situations.

[0386] Log recording and alarms: Record abnormal events and response measures, trigger alarm mechanisms, and ensure timely response from administrators.

[0387] 2. AIRM consists of the following key components:

[0388] (1) Anomaly detection interface module

[0389] Function: Receives anomaly detection signals from other modules.

[0390] Technical details:

[0391] Signal source:

[0392] TSSM: Platform Trusted State Change Signal.

[0393] DDICU: Abnormal data packet detection signal.

[0394] DKNMU: Abnormal key negotiation request signal.

[0395] Signal transmission protocol: SPI or I2C protocol is used to ensure the reliability and timeliness of signal transmission.

[0396] Signal processing logic: Perform logical judgment on the received abnormal signals to determine whether an isolation response needs to be triggered.

[0397] (2) Hardware relay control module

[0398] Function: Based on the anomaly detection results, control the hardware relay to disconnect or close the communication link.

[0399] Technical details:

[0400] Hardware relay selection: Select suitable hardware relays to ensure fast and reliable opening and closing actions.

[0401] Control logic: When an abnormal signal is received, a relay is immediately triggered to disconnect the communication link to prevent the attack from spreading further.

[0402] Disconnection time: Ensure that the disconnection time of the relay is short enough to minimize the impact on normal operations.

[0403] (3) Emergency local control mode switching module

[0404] Function: Supports manual switching to emergency local control mode.

[0405] Technical details:

[0406] Emergency mode triggering mechanism: Administrators can manually trigger emergency mode via a physical button or a secure remote command.

[0407] Local control function: In emergency mode, the system only allows local operation and prohibits external communication to ensure system security.

[0408] Mode switching logic: Ensures the mode switching process is fast and reliable, and prevents system instability during the switching process.

[0409] (4) Log recording and alarm module

[0410] Function: Record abnormal events and response measures, and trigger alarm mechanisms.

[0411] Technical details:

[0412] Log entries include the time, type, triggering module, and response measures for the abnormal event.

[0413] Log storage medium: Use secure storage media to store logs to prevent them from being tampered with or leaked.

[0414] Alarm mechanism: Alarms are triggered through multiple methods (such as SMS, email, and audible and visual alarms) to ensure timely response from administrators.

[0415] 3. Technical Details

[0416] (1) Anomaly detection interface

[0417] Signal transmission protocol: SPI or I2C protocol is used to ensure the reliability and timeliness of signal transmission.

[0418] Signal processing logic: Perform logical judgment on the received abnormal signals to determine whether an isolation response needs to be triggered.

[0419] (2) Hardware relay control

[0420] Relay selection: Select suitable hardware relays to ensure fast and reliable disconnection and closing actions.

[0421] Control logic: When an abnormal signal is received, a relay is immediately triggered to disconnect the communication link to prevent the attack from spreading further.

[0422] Disconnection time: Ensure that the disconnection time of the relay is short enough to minimize the impact on normal operations.

[0423] (3) Emergency Local Control Mode

[0424] Triggering mechanism: Administrators can manually trigger the emergency mode via a physical button or a secure remote command.

[0425] Local control function: In emergency mode, the system only allows local operation and prohibits external communication to ensure system security.

[0426] Mode switching logic: Ensures the mode switching process is fast and reliable, and prevents system instability during the switching process.

[0427] (4) Log recording and alarms

[0428] Log entries include the time, type, triggering module, and response measures for the abnormal event.

[0429] Log storage medium: Use secure storage media to store logs to prevent them from being tampered with or leaked.

[0430] Alarm mechanism: Alarms are triggered through multiple methods (such as SMS, email, and audible and visual alarms) to ensure timely response from administrators.

[0431] 4. The AIRM workflow can be divided into the following steps:

[0432] (1) Anomaly detection

[0433] Receive anomaly detection signals from other modules, such as changes in the platform's trusted state, abnormal data packet detection, and abnormal key negotiation requests.

[0434] (2) Exception handling

[0435] Based on the detected anomaly type, trigger the corresponding response measures:

[0436] Trigger hardware relays: Disconnect the communication link to prevent the attack from spreading further.

[0437] Switch to emergency local control mode: The administrator manually triggers the emergency mode to ensure basic system operation in abnormal situations.

[0438] (3) Log recording and alarms

[0439] Record abnormal events and response measures to ensure that events are traceable.

[0440] The alarm mechanism is triggered, and the administrator is notified to take further action.

[0441] 5. AIRM works in conjunction with other modules in the system to ensure the overall system security:

[0442] (1) Synergy with TSSM

[0443] Platform Trusted State Change Detection: Receives the verification result from TSSM as a condition for triggering an isolation response.

[0444] Abnormal event logging: Records events that change the trusted state of the platform to ensure the completeness of the audit.

[0445] (2) Collaboration with DDICU

[0446] Abnormal data packet detection: Receives abnormal data packet detection signals from DDICU and triggers an isolation response.

[0447] Communication link disconnected: Based on the DDICU's detection results, the communication link is disconnected to prevent the spread of abnormal data packets.

[0448] (3) Synergy with DKNMU

[0449] Abnormal Key Negotiation Request Detection: Upon receiving an abnormal key negotiation request signal from DKNMU, an isolation response is triggered.

[0450] Key update response: Based on the key update events of DKNMU, record abnormal events and response measures.

[0451] (4) Synergy with TTSAU

[0452] Timestamp synchronization: Receives TTSAU timestamps to ensure the accuracy of abnormal event recording.

[0453] Audit log recording: Record abnormal events and response measures in the audit log to ensure the integrity of the audit.

[0454] 6. Technological Advantages

[0455] Rapid response: Upon detecting abnormal behavior, a hardware relay is immediately triggered to disconnect the communication link, preventing the attack from spreading further.

[0456] Emergency Local Control: Supports manual switching to emergency local control mode to ensure basic system operation in abnormal situations.

[0457] Comprehensive logging and alerting: Records abnormal events and response measures, triggers alert mechanisms, and ensures timely response from administrators.

[0458] The Anomaly Isolation Response Module (AIRM) receives anomaly detection signals from other modules, triggers a hardware relay to disconnect the communication link, supports manual switching to emergency local control mode, and records anomaly events and triggers alarm mechanisms, providing a high level of security protection for the power trusted computing platform. Its collaborative work with other system modules ensures the security, reliability, and auditability of communication between the platform and external nodes, effectively preventing the risk of unknown attacks and system crashes.

[0459] Specifically, the external secure communication device and the power trusted computing platform form the following system architecture:

[0460] Platform Trusted Computing Core → TSSM → DDICU → DKNMU → Secure Communication Network.

[0461] The platform's trustworthiness is a prerequisite for key negotiation; communication will be terminated if the platform's trustworthiness is not met.

[0462] The audit logs form an immutable chain (Blockchain-like Merkle Chain Log) stored in TTSAU.

[0463] It should be noted that:

[0464] 1. Device hardware composition:

[0465] Main control chip: Secure FPGA (with encrypted firmware);

[0466] Isolation medium: Three sets of opto-isolators, transmission delay <50ns;

[0467] Secure storage: Built-in secure Flash storage platform with initial metric hash;

[0468] RTC time module: supports ±2ppm accuracy and has signature capability;

[0469] Encryption engine: Hardware accelerator for Chinese national cryptographic standards SM2 / SM4 / SM3;

[0470] 2. Trusted State Awareness:

[0471] Send a GetQuote request to TPM via the security interface to obtain the PCR register value and signature.

[0472] L-HV model:

[0473] Input: PCR value + platform startup chain log;

[0474] Algorithm: SM3 digest → compared with the initial baseline value stored in secure Flash;

[0475] Output: Trusted / Untrusted flag;

[0476] The verification result is passed to DDICU as a condition for allowing communication.

[0477] 3. Dynamic key negotiation:

[0478] Once the platform is trusted and passes TSSM authentication, DKNMU will initiate key negotiation.

[0479] Both parties used SM2 to exchange session keys:

[0480] Key = KDF(TPM_PCR, Session_Random, Timestamp)

[0481] Session key validity period: 5 minutes by default, and will be immediately invalidated if any platform status changes.

[0482] 4. Baseline Communication Model (BTM):

[0483] Modeling method: The packet length sequence, protocol type, and periodicity of normal power business traffic are used as feature sets.

[0484] Detection method: When the difference between real-time traffic and model traffic is greater than 30%, anomaly isolation is triggered.

[0485] 5. Audit and Response

[0486] TTSAU hashes each communication record (timestamp, source / destination address, packet digest) using SM3 and merges it with the hash of the previous record to generate a Merkle chain node.

[0487] When the storage length threshold is 10MB, the data is automatically packaged and synchronized to an external audit server.

[0488] AIRM disconnects the WAN-side interface via a hardware relay, ensuring that attacks cannot continue to penetrate the network.

[0489] This invention provides an external secure communication system for a power trusted computing platform, which has the following advantages:

[0490] 1. External communication hardware driven by the platform's trusted state: The communication device is deployed entirely outside the platform and only allows data to pass when the platform is detected to be in a trusted state; unlike traditional software or built-in encryption modules;

[0491] 2. Physical-Logical Dual Isolation Path: The combination of FPGA logic firewall and opto-isolation prevents any cross-domain instruction injection attacks;

[0492] 3. Dynamic key binding to TPM status: The key update policy is bound to the platform's TPM metric in real time. When the platform status is changed by an attack, the key becomes invalid immediately.

[0493] 4. Model-based anomaly detection: Introducing L-HV and BTM models to provide packet-level and state-level detection capabilities, improving the recognition rate of unknown attacks;

[0494] 5. Immutable audit chain: All communication audit records are stored through hardware timestamps and a Merkle chain structure.

[0495] To verify the beneficial effects of the present invention, the following verifications are now conducted:

[0496] I. Purpose of Experimental Verification

[0497] This experiment aims to verify the superior technical effects of the external secure communication system of the power trusted computing platform of the present invention in the following aspects:

[0498] External communication control driven by platform trusted state: ensures that communication data is allowed to pass only when the platform is in a trusted state.

[0499] Physical-Logical Dual Isolation Effect: Verifying the physical and logical isolation capabilities of opto-isolation + FPGA firewall.

[0500] Dynamic key negotiation and security: Verify the speed and security strength of dynamic key generation and update based on the national cryptographic algorithm and TPM binding.

[0501] Anomaly detection and isolation response time: Verify the accuracy and response latency of L-HV and BTM models for anomaly traffic detection.

[0502] Immutable audit chain integrity: Verify the log chain's resistance to tampering under timestamp, hash, and replay attacks.

[0503] Effectiveness of packet loss retransmission mechanism: Verify the success rate of retransmission and signature verification of audit logs in network packet loss environments.

[0504] II. Test Environment and Configuration

[0505] project Configuration / Conditions Platform under test Power Trusted Computing Platform with TPM 2.0 Module (Linux 5.10 Kernel) External secure communication device FPGA + opto-isolation module + secure Flash + RTC signature chip Communication interface WAN port (external network simulation) ↔ External device ↔ Internal network port (platform) Test Network Gigabit Ethernet, latency <2ms, locally configured with a controllable packet loss injector National cryptographic support SM2, SM3, SM4 hardware acceleration modules Attack Simulation TCP hijacking, man-in-the-middle attack, abnormal packet injection, forged status reports Log server HTTPS interface security audit server, latency ≤10ms

[0506] III. Test Items and Methods

[0507] Trusted status release verification: Simulate TPM PCR value tampering (forge startup chain log); observe whether the system terminates communication; and count the false release rate.

[0508] Isolation effectiveness verification: Simulate voltage injection and cross-domain command injection on the WAN side; verify whether it is blocked by physical isolation and rejected by logical rules.

[0509] Dynamic key negotiation performance: Initiate the first key negotiation in a trusted state; measure the generation / distribution time; simulate key replacement triggered by changes in trusted state; verify the total time and key distribution success rate.

[0510] Anomaly detection and isolation response: Inject abnormal traffic into the system (packet size and cycle abnormality 30%+); record the detection time and relay disconnection delay.

[0511] Log tamper protection verification: Attempt to modify the stored audit log record and verify the hash chain again; observe whether tampering is detected.

[0512] Packet loss retransmission verification: Set the link packet loss rate to 5% and observe the recovery rate of the audit log under the retransmission mechanism.

[0513] IV. Testing Process and Data Recording

[0514] 1. Platform Trusted State Driven

[0515] Test Scenario Platform TPM Status Communication release result Mis-release rate Normal PCR value Trustworthy Release 0% PCR value tampering Untrustworthy Block 0% Forged startup chain logs Untrustworthy Block 0%

[0516] Results: No abnormal states were allowed to pass, and the false release rate was 0%, verifying the effectiveness of the trusted state release mechanism.

[0517] 2. Isolation effect

[0518] Attack methods Opto-isolation blocking effect FPGA rule interception effect Access the platform's intranet? Voltage injection attack Block N / A no Cross-domain instruction injection (illegal Modbus packet) N / A Intercept no Forged legitimate IP attack packets N / A Intercept no

[0519] Result: No attack data entered the internal network, verifying the effectiveness of physical and logical isolation.

[0520] 3. Dynamic key negotiation performance

[0521] Test rounds Negotiation type Time elapsed (ms) Success rate 1 First Key Negotiation 47.8 100% 2 State change triggers update 52.3 100% 3 Scheduled update 50.1 100%

[0522] Results: Key generation and distribution were both completed in less than 60ms, with a success rate of 100%.

[0523] 4. Anomaly Detection and Isolation Response

[0524] Scene Anomaly detection time (ms) Relay disconnection time (ms) Total response time (ms) Traffic flow characteristics abnormal 30% 12.4 6.1 18.5 Abnormal key negotiation request 10.2 6.0 16.2 Platform status downgrade 9.8 5.9 15.7

[0525] Result: The total response time for all scenarios was <20ms.

[0526] 5. Log tamper-proof verification

[0527] Tampering methods Verification results Detection time (ms) Modify the content of a single log entry Tampering detected 8.3 Delete a node in the chain Tampering detected 8.1 Replay old logs Tampering detected 8.0

[0528] Result: Tampering detection success rate was 100%, time taken < 9ms.

[0529] 6. Packet Loss Retransmission Verification

[0530] Packet loss rate Total number of audit logs First synchronization success count Trigger supplementary data transmission Final success rate 5% 10,000 9,500 500 100% 10% 10,000 9,000 1,000 100%

[0531] Result: The final audit log recovery rate was 100% under packet loss conditions.

[0532] V. Results Analysis and Conclusions

[0533] The trusted state release mechanism has been verified to control the false release rate to 0%, achieving true platform-driven trusted communication.

[0534] The physical and logical dual isolation demonstrated a 100% interception rate in attack simulations, ensuring that external attacks could not penetrate the internal network.

[0535] Dynamic key negotiation takes no more than 60ms in all scenarios and has a 100% success rate, which can meet the real-time requirements of power services.

[0536] The anomaly detection and isolation response latency is less than 20ms, which can block risks in the early stages of an attack.

[0537] The tamper-proof audit chain completely prevents attacks such as tampering, deletion, and replay, ensuring the credibility of audit data.

[0538] The packet loss compensation mechanism ensures zero log loss even with a 10% packet loss, meeting the reliability requirements of power communication.

[0539] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. An external secure communication system for a power trusted computing platform, characterized in that, Includes the following components: The Trusted State Awareness Module reads the platform's TPM metric, startup chain logs, and trusted state reports periodically through a secure interface, and simultaneously uses the lightweight hash verification model built into the link to perform secondary signature verification on the platform's state. The bidirectional isolated communication unit employs opto-isolation and FPGA logic firewall to achieve physical and logical isolation between the external wide area network side and the platform intranet side; Synchronously perform packet-level whitelist policy matching before data forwarding and perform anomaly detection based on the benchmark communication model; The dynamic key negotiation and management unit is based on the national cryptographic SM2 / SM4 algorithm and is bound to the key derivation function of the TPM within the platform to realize session-level dynamic key generation; The trusted timestamp and security audit unit integrates an independent RTC and time signature chip to ensure the accuracy and immutability of audit log times. The abnormal behavior isolation response module immediately triggers a hardware relay to disconnect the communication link when the L-HV model or BTM detects abnormal data packets, abnormal key negotiation requests, or an untrusted platform state.

2. The external secure communication system of the power trusted computing platform according to claim 1, characterized in that: The dynamic key negotiation and management unit immediately replaces the session key when it detects a change in the platform's trusted state or when the timer expires.

3. The external secure communication system of the power trusted computing platform according to claim 2, characterized in that, In the trusted timestamp and security audit unit: audit logs are synchronized to an external security audit server, supporting packet loss retransmission and signature verification.

4. The external secure communication system of the power trusted computing platform according to claim 3, characterized in that: The abnormal behavior isolation response module supports manual switching to emergency local control mode.

5. The external secure communication system of the power trusted computing platform according to claim 4, characterized in that, The external secure communication system forms the following system architecture: Platform Trusted Computing Core → TSSM → DDICU → DKNMU → Secure Communication Network; The platform's trust status is a prerequisite for key negotiation; communication will be terminated if the status is not met. The audit logs form an immutable chain and are stored in TTSAU.