Intelligence board embedded SDK end-to-end encryption method and system based on national secret double certificates

Abstract

The application discloses an intelligence board embedded SDK end-to-end encryption method and system based on a national secret double certificate, and relates to the technical field of Internet of Things safe communication. The system comprises a center end, a sub-center end and a device end, the center end comprises a control end, a center side encryption gateway cluster, the sub-center end comprises an Internet emergency agent, and the control end comprises an intelligence board; the control end serves as an initiator of intelligence board control instructions and communicates with each intelligence board through the center side encryption gateway; the center side encryption gateway cluster comprises a hardware encryption gateway and a software encryption gateway; the Internet emergency agent is arranged on a management sub-center node and forwards received encrypted data to an intranet target intelligence board; a national secret SDK is integrated in the controller of each intelligence board in a way of embedding or upgrading, and the national secret algorithm is realized in the functions of TLCP handshake, session key negotiation, data encryption and decryption and certificate management. The application can realize safe and efficient encryption communication from the control end to the intelligence board.

Description

Technical Field

[0001] This invention relates to the field of IoT secure communication technology, and in particular to an end-to-end encryption method and system for an information board embedded SDK based on national cryptographic dual certificates. Background Technology

[0002] The existing intelligence board encryption scheme uses a link from the control end to the central encryption gateway, then to the terminal encryption gateway, and finally back to the intelligence board. This link setup, due to the large number of terminal encryption gateways (one per intelligence board), means that a failure of any gateway will cause the corresponding intelligence board to lose control, while a failure of the central encryption gateway will paralyze the entire system. Although node failures can be avoided through hardware bypass, this will convert the entire communication link to plaintext, losing its encrypted communication capability. Furthermore, each intelligence board requires an external hardware encryption gateway, resulting in significant equipment costs, installation space requirements, power supply costs, and maintenance expenses, and retrofitting older intelligence boards is difficult. In terms of security, certificates are stored as files on the gateway's disk, making them vulnerable to copying and misuse; multi-hop encryption exposes intermediate nodes (terminal gateways) to the risk of decrypting plaintext, and if compromised, all intelligence board control commands will be leaked. Control cannot be restored via the internet when the monitoring network is interrupted. Summary of the Invention

[0003] In view of the shortcomings of the existing technology, the purpose of this invention is to provide an end-to-end encryption method and system for an information board embedded SDK based on national cryptographic dual certificates, which can realize secure and efficient encrypted communication from the control end to the information board.

[0004] To achieve the above objectives, the present invention is implemented through the following technical solution: The first aspect of this invention provides an end-to-end encryption system for intelligence boards based on dual national cryptographic certificates and embedded SDKs, comprising a central terminal, branch center terminals, and device terminals. The central terminal includes a control terminal and a central-side encryption gateway cluster. The branch center terminals include an internet emergency agent, and the control terminal includes intelligence boards. The control terminal is located in the management center and acts as the initiator of intelligence board control commands, communicating with each intelligence board through the central-side encryption gateway. The central-side encryption gateway cluster includes hardware encryption gateways and software encryption gateways. The hardware encryption gateway is based on a dedicated server, providing high-performance national cryptographic computing capabilities and serving as the main device to handle daily business traffic. The software encryption gateway is deployed on a general-purpose server, implementing pure software national cryptographic proxy functionality, equivalent to the hardware encryption gateway, and serves as a backup device. The internet emergency agent is deployed at the management branch center node to monitor non-standard ports on the internet side and accept national cryptographic connection requests from the central-side gateway. Simultaneously, the internet emergency agent maintains a connection with the monitoring intranet and forwards the received encrypted data to the target intelligence board on the intranet. The controller of each intelligence board integrates the national cryptographic SDK through embedding or upgrading, realizing TLCP handshake, session key negotiation, data encryption / decryption, and certificate management functions for national cryptographic algorithms.

[0005] Furthermore, the national cryptographic SDK is provided to information board manufacturers in the form of a static library or a dynamic library, which the manufacturers then integrate into the control program firmware of the information board. For new information board models, the manufacturers compile the SDK and the information board control program together during the development stage to generate a complete firmware image containing national cryptographic functions, which is then directly burned into the Flash memory of the information board controller at the factory.

[0006] Furthermore, during the production or upgrade of the information board, a unique national cryptographic dual certificate is issued by an internal trusted CA and transmitted and burned into the trusted storage area of ​​the information board controller through a secure channel.

[0007] Furthermore, the Internet emergency agent is located at the boundary between the monitoring intranet and the Internet, and is configured with dual network cards for both the intranet and the Internet. The intranet network card is connected to the monitoring intranet, and the external network card is connected to the Internet.

[0008] Furthermore, the Internet emergency proxy software simultaneously establishes TCP connections with the central encrypted gateway and the intelligence board, and performs pure byte stream pass-through between the two, forwarding the encrypted data of both parties to each other. The central encrypted gateway and the intelligence board perform encryption and decryption operations. The Internet emergency proxy software itself does not participate in any encryption and decryption operations and does not need to rely on certificates and encryption / decryption components.

[0009] Furthermore, the internet emergency proxy software needs to have a public IP address on the internet side or be reachable through NAT mapping to ensure that a TCP connection with the gateway can be established. An intrusion detection / prevention system (IDS / IPS) needs to be deployed to perform in-depth inspection of incoming traffic, identify and block attack behaviors.

[0010] Furthermore, three communication links are defined and arranged in descending order of priority: the main link is from the control terminal to the central hardware encryption gateway and then to the intelligence board; the backup link is from the control terminal to the central software encryption gateway and then to the intelligence board; and the emergency link is from the control terminal to the central side gateway, then to the emergency agent and then to the intelligence board.

[0011] Furthermore, it also includes a large monitoring network, which is physically isolated from the Internet. When the monitoring network experiences a communication interruption due to fiber optic cable failure or equipment malfunction, both the main link and the backup link between the control terminal and the information board become unavailable. In this case, the Internet emergency link is activated.

[0012] Furthermore, the intelligence board uses the lightweight key negotiation mechanism of the national cryptographic TLCP to negotiate session keys. It achieves decoupling of national cryptographic encryption and decryption with specific intelligence board vendor protocols through the intelligence board SDK adaptive protocol adaptation layer. Based on the behavior baseline, the pre-anomaly detection and autonomous defense mechanism enable the intelligence board to have autonomous security perception capabilities independent of the central side.

[0013] The second aspect of this invention provides an encryption method for an end-to-end encryption system based on a national cryptographic dual-certificate information board embedded SDK, comprising the following steps: The control terminal initiates a national cryptographic TLCP connection to the IP address of the information board through the central gateway; The central gateway and the intelligence board exchange signature certificates and encryption certificates to verify the trust chain and device fingerprints. The session key is negotiated using the public key of the encryption certificate. The session key is only known to the control terminal and the information board. After the control terminal commands are encrypted and forwarded to the information board through the central gateway, they are decrypted and executed using the national cryptographic SDK.

[0014] The above one or more technical solutions have the following beneficial effects: This invention discloses an end-to-end encryption method and system for intelligence boards based on dual national cryptographic certificates and embedded SDKs. Addressing the architectural flaws of existing multi-hop hardware encryption gateway-based serial encryption schemes, this invention eliminates single-point-of-failure risks by removing the physical gateway on the terminal side and employing a central-side hardware and software backup mechanism. Fault switching requires no bypass, ensuring uninterrupted encrypted communication. Furthermore, the use of lightweight SDK software integration replaces external hardware, significantly reducing upgrade costs and supporting remote upgrades of older intelligence boards. At the security level, end-to-end encryption and pre-configured certificate device binding eliminate risks of intermediate node decryption and certificate impersonation. Combined with anomaly detection and autonomous defense based on intelligence board behavior baselines, proactive protection is achieved. In addition, a new internet emergency link ensures reliable control during large-scale network outages. Lightweight key negotiation and an adaptive protocol adaptation layer effectively reduce resource consumption and ensure compatibility with multiple vendor protocols, comprehensively improving the system's reliability, economy, and security.

[0015] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

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

[0017] Figure 1 This is the architecture and communication link diagram of the end-to-end encryption system based on the national cryptographic dual certificate embedded SDK of the information board in Embodiment 1 of the present invention; Figure 2 This is a flowchart of the internal modules and certificate binding verification process of the information board SDK in Embodiment 1 of the present invention; Figure 3 This is a timing diagram of end-to-end encryption and emergency forwarding between the control terminal and the information board SDK in Embodiment 1 of the present invention; Figure 4 This is a flowchart of the lightweight key negotiation mechanism for the intelligence board based on the national cryptographic TLCP in Embodiment 1 of the present invention. Detailed Implementation

[0018] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0019] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof. The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0020] Example 1: Embodiment 1 of this invention provides an end-to-end encryption system for an information board embedded with an SDK based on dual national cryptographic certificates, such as... Figures 1 to 4As shown, the system includes a central terminal, branch terminals, and device terminals. The central terminal includes a control terminal and a central-side encrypted gateway cluster. The branch terminals include an internet emergency agent, and the control terminal includes intelligence boards. The control terminal is located in the management center and acts as the initiator of control commands for the intelligence boards, communicating with each intelligence board through the central-side encrypted gateway. The central-side encrypted gateway cluster includes hardware and software encryption gateways. The hardware encryption gateway is based on a dedicated server, providing high-performance national cryptographic computing capabilities and serving as the main device to handle daily business traffic. The software encryption gateway is deployed on a general-purpose server, implementing pure software national cryptographic proxy functionality, equivalent to the hardware encryption gateway, and serving as a backup device. The internet emergency agent is deployed at the management branch terminal node to listen to non-standard ports on the internet side and accept national cryptographic connection requests from the central-side gateway. At the same time, the internet emergency agent maintains a connection with the monitoring intranet and forwards the received encrypted data to the target intelligence board on the intranet. The controller of each intelligence board integrates the national cryptographic SDK through embedding or upgrading, realizing TLCP (Transport Layer Cryptography Protocol) handshake, session key negotiation, data encryption and decryption, and certificate management functions for national cryptographic algorithms.

[0021] In one specific implementation, the national cryptographic SDK is provided to the information board manufacturer in the form of a static library (.a) or a dynamic library (.so). The manufacturer then integrates it into the information board's control program firmware. For new information board models, the manufacturer compiles the SDK and the information board control program together during the development phase to generate a complete firmware image containing national cryptographic functions, which is then directly burned into the information board controller's Flash memory at the factory. For already deployed information boards, integration is completed via remote firmware upgrades.

[0022] It should be noted that the full name of the Chinese Cryptography SDK in this embodiment is "Chinese Cryptography Algorithm Software Development Kit". Here, "Chinese Cryptography" refers to the national commercial cryptography (abbreviated as Chinese Cryptography), and "SDK" stands for Software Development Kit, which is a collection of library files, API interfaces, and development tools for developers to use. The "Chinese Cryptography SDK" is a development kit that encapsulates Chinese cryptographic algorithms and security protocols (such as Chinese cryptographic SSL / TLCP).

[0023] During the production or upgrade of the information board, a unique dual certificate with national cryptographic algorithms is issued by an internal trusted CA and transmitted and burned into the trusted storage area of ​​the information board controller through a secure channel. The trusted storage area can be an independent security chip (such as an SE security chip supporting national cryptographic algorithms), a TEE (Trusted Execution Environment), or a one-time programmable memory (eFuse). The certificate is stored in encrypted form, and its encryption key is derived internally from the security chip or TEE, making the plaintext certificate unreadable externally.

[0024] The certificate extension embeds the hardware fingerprint of the information board. This hardware fingerprint is generated by combining multiple hardware features, including the CPU serial number, network card MAC address (primary network card), storage device serial number (such as eMMC CID), and a unique identifier for the TPM or SE chip. During certificate issuance, these feature values ​​are collected from the information board, concatenated, and hashed using SM3 to obtain a 32-byte fingerprint value. This fingerprint is then written to the certificate as a custom extension (OID 1.2.156.10197.6.X, marked as a critical extension). Once written, this fingerprint cannot be changed.

[0025] The SDK automatically performs device fingerprint verification every time it starts. First, it collects the hardware characteristics of the current device and calculates the fingerprint using the same algorithm. Then, it verifies the validity of the certificate chain using a pre-installed root certificate and extracts the fingerprint extension from the certificate. Finally, it compares the current fingerprint with the fingerprint in the certificate. If they match, the certificate is loaded and the national cryptographic service is started; if they do not match, the certificate loading is refused, the security event is recorded, and an alarm is triggered. This mechanism ensures a strong bond between the certificate and the information board hardware, preventing its use on other devices even if the certificate file is exported.

[0026] The current steps in this embodiment have the following advantages: They eliminate the terminal-side encryption gateway, preventing the control-side encryption / decryption node from failing. Integration is easy and the modification cost is low. Software SDK integration only requires modifying the intelligence board firmware, without altering the hardware circuitry. Security is further enhanced: the control end and intelligence board are directly encrypted, eliminating the need for a terminal-side gateway and thus eliminating the risk of decryption at intermediate nodes. Certificates are bound to the device and pre-stored in trusted storage, preventing export or misuse.

[0027] In one specific implementation, a hardware encryption gateway and a software encryption gateway are deployed simultaneously on the central side. The hardware encryption gateway, based on a dedicated server, provides high-performance national cryptographic computing capabilities and serves as the primary device handling daily business traffic. The software encryption gateway, deployed on a general-purpose server, implements pure software national cryptographic proxying, and is functionally equivalent to the hardware encryption gateway, serving as a backup device.

[0028] The two gateways share a single virtual IP address via Virtual Router Redundancy Protocol (VRRP) or Keepalived. During normal operation, the virtual IP is bound to the network interface card (NIC) of the hardware-encrypted gateway, and all traffic is processed through this gateway. A health check module detects the gateway's liveness status at fixed intervals (e.g., 1 second) from two directions: firstly, the management platform sends heartbeat probes to both gateways; secondly, the two gateways send heartbeats to each other. Detection metrics include process liveness, network connectivity, and the response time of the national cryptographic handshake.

[0029] Specifically, the health monitoring module in this embodiment continuously monitors the status of each link. The monitoring method is as follows: the management platform periodically sends heartbeat probe messages to the intelligence board through each link, and the intelligence board replies with confirmation upon receiving them. If the main link fails to respond to three consecutive probes, it is determined that the main link has failed, and the system automatically switches traffic to the backup link. The backup gateway immediately seizes the virtual IP and takes over all business traffic. The encrypted connections already established during the switchover are not affected (the session key is synchronized between the main and backup links). If the backup link also fails to respond to three consecutive probes, it is determined that the entire monitoring network is interrupted, the system activates the emergency link, and the central gateway connects to the emergency agent through the Internet. The emergency agent then forwards the data to the target intelligence board on the internal network.

[0030] It should be noted that heartbeat detection messages are a common term in this field, and are a common technical means for detecting link liveness and connectivity in centralized monitoring systems, so they will not be elaborated on here.

[0031] In one specific implementation, the Internet emergency agent is located at the boundary between the monitoring intranet and the Internet, and is configured with dual network cards for both the intranet and the Internet. The intranet network card is connected to the monitoring intranet, and the external network card is connected to the Internet.

[0032] The Internet Emergency Proxy is in the form of Internet Emergency Proxy software. The Internet Emergency Proxy software establishes TCP connections with the central encrypted gateway and the intelligence board, and performs pure byte stream pass-through between the two, forwarding the encrypted data of both parties to each other. The central encrypted gateway and the intelligence board perform encryption and decryption operations. The Internet Emergency Proxy software itself does not participate in any encryption and decryption operations and does not rely on certificates or encryption and decryption components.

[0033] Internet emergency proxy software needs to have a public IP address on the internet side or be reachable through NAT mapping to ensure that a TCP connection with the gateway can be established. An intrusion detection / prevention system (IDS / IPS) needs to be deployed to perform in-depth inspection of incoming traffic, identify and block attack behaviors.

[0034] The internet emergency proxy software must have a public IP address on its internet side, or be reachable via NAT mapping, to ensure a TCP connection with the gateway can be established. An intrusion detection / prevention system (IDS / IPS) must be deployed to perform deep inspection of incoming traffic, identifying and blocking attacks. The proxy should be configured with an IP whitelist, allowing only connections from the central gateway's outgoing IP addresses, rejecting all other sources. When activating a connection, the operator must insert a UKey to complete authentication; only after successful authentication will the proxy establish a data forwarding channel. All operations forwarded through the emergency proxy are logged in their entirety, including connection time, source IP, destination IP, data traffic volume, and operator identity. These logs are encrypted, tamper-proof, and available for post-event auditing and traceability.

[0035] In this embodiment, the dual hardware and software backup of the central encrypted gateway eliminates the risk of a complete system failure due to a single hardware device malfunction. Even when the monitoring network is completely interrupted, the Internet emergency agent can still issue emergency information board display instructions through the Internet channel, enhancing the availability of the system. It is lightweight and only requires port mapping configuration. The forwarding latency is low and the protocol is transparent, with no encryption / decryption overhead or security risks.

[0036] In one specific implementation, three communication links are defined and arranged in descending order of priority: the main link is from the control terminal to the central hardware encryption gateway and then to the intelligence board; the backup link is from the control terminal to the central software encryption gateway and then to the intelligence board; and the emergency link is from the control terminal to the central side gateway, then to the emergency agent and then to the intelligence board.

[0037] In one specific implementation, a monitoring network is also included, which is physically isolated from the Internet. When the monitoring network is interrupted due to fiber optic cable failure or equipment malfunction, both the main link and the backup link between the control terminal and the information board are unavailable. At this time, the Internet emergency link is activated.

[0038] It should be noted that the highway system in this embodiment includes a monitoring network, a toll collection network, and a communication network. These are three physically independent dedicated networks for the highway, each with its own independent equipment and fiber optic lines, and all are independent of the public internet. The monitoring network carries the control of information boards and video transmission, the toll collection network ensures the security of billing and settlement, and the communication network provides the underlying transmission channel. These are all common networks in this field and will not be described in detail here. In this embodiment, information board control commands must be issued through the monitoring network.

[0039] In one specific implementation, the intelligence board performs session key negotiation based on the lightweight key negotiation mechanism of the national cryptographic TLCP, and decouples the national cryptographic encryption and decryption from the specific intelligence board manufacturer's protocol through the intelligence board SDK adaptive protocol adaptation layer. Based on the behavior baseline, the pre-anomaly detection and autonomous defense mechanism enable the intelligence board to have autonomous security perception capabilities independent of the central side.

[0040] (1) The information board uses the lightweight key negotiation mechanism of the national cryptographic TLCP to negotiate the session key.

[0041] Specifically, the following steps are included: 1. After the intelligence board is initially deployed and started, the central gateway, acting as a client, proactively initiates a connection to the intelligence board. Since no session cache has been established between the two parties at this point, a standard TLCP handshake process is executed first: the central gateway generates a client random number `random_c` and sends `ClientHello` to the intelligence board. Upon receiving this, the intelligence board generates a server random number `random_s`, returns `ServerHello` to the central gateway, and sends its own signing certificate `SignCert_board` and encryption certificate `EncCert_board` (the intelligence board's dual certificates), along with a `ServerKeyExchange` message. Upon receiving the intelligence board's certificates, the central gateway verifies the certificate chain and signature validity, confirming the intelligence board's legitimate identity. Subsequently, the central gateway requests the intelligence board to verify its identity via a `CertificateRequest` message. During the client certificate exchange, the central gateway sends its signing certificate `SignCert_gateway` and encryption certificate `EncCert_gateway` to the intelligence board. Upon receiving this, the intelligence board verifies the certificate chain, confirming the central gateway's legitimate identity. After both sides pass the verification, the central gateway generates a 48-byte pre-master key PMS, which is encrypted using the public key of the intelligence board's encryption certificate and then sent. The intelligence board decrypts the PMS using its own encryption certificate private key. Both parties use the PRF algorithm to derive the master key MK = PRF(PMS, "master secret", random_c || random_s, 48) and the working key KB = PRF(MK,"key expansion", random_s || random_c, 64), which gives the central gateway's SM4 encryption key C_K = KB[0:15] and the intelligence board's SM4 encryption key S_K = KB[16:31].

[0042] 2. After the initial handshake is completed: The information board caches the certificates of the central gateway (signature certificate SignCert_gateway and encryption certificate EncCert_gateway) and establishes hash indexes cert_cache[SignCert_gateway_hash] = SignCert_gateway and cert_cache[EncCert_gateway_hash] = EncCert_gateway for subsequent verification of the central gateway's identity. Both parties perform additional pre-computation operations: each generates a 32-byte pre-shared key PSK (PSK_local and PSK_remote) and a 32-byte pre-computed seed Seed (Seed_local and Seed_remote), which are encrypted using the master key MK and then exchanged. The combined key materials PSK_combined = PSK_local ⊕ PSK_remote and Seed_combined = Seed_local ⊕ Seed_remote are obtained by XOR mixing. Then, the encryption key K1 = PRF(PSK_combined, "precomputed key 1", Seed_combined, 16) and the initialization vector IV1 = PRF(PSK_combined, "precomputed iv 1", Seed_combined, 12) for the next round of communication are pre-computed. Both parties cache the pre-computed key group [K1, IV1], with the index number recorded as 1, for use in subsequent zero-round encrypted communication.

[0043] 3. When the central gateway needs to issue instructions to the same information board again to execute the lightweight handshake process, there is no need to perform a complete certificate exchange and key negotiation again: The central gateway carries an extended field in ClientHello, declaring the lightweight mode and attaching the hash value of its signing certificate. After receiving ClientHello, the information board uses this hash value to look up the central gateway certificate in its local cache. If it can find it, the verification is successful, confirming that the other end is a legitimate central gateway. After successful verification, both parties use the cached encryption key K_i for encrypted data transmission: Central gateway encryption instruction: ciphertext = E(K_i, plaintext, IV_i); Information board decryption instruction: plaintext = D(K_i,ciphertext, IV_i); Information board encryption response: ciphertext_resp = E(K_i, response, IV_i); Central gateway decryption response: response = D(K_i, ciphertext_resp, IV_i).

[0044] This embodiment uses lightweight key derivation to achieve zero-round encrypted communication for subsequent connections. After each communication, the usage count of the current key group is incremented. When the count reaches a preset limit (default 100 times) or the communication interval exceeds a preset time window, a key rolling update is automatically triggered, deriving the next key group and incrementing the index number: K_{i+1} = PRF(K_i,"rollover", IV_i || counter, 16); IV_{i+1} = PRF(K_i, "rollover iv", IV_i || counter, 12) If the pre-computed keys do not match due to reasons such as expired cache or device restart, a lightweight key negotiation is performed: the central gateway generates a temporary key pair, encrypts it with the public key of the intelligence board's encryption certificate, and sends it to the intelligence board; the intelligence board decrypts it with its own encryption certificate private key (1 SM2 decryption), and both parties derive a new key pair.

[0045] The above steps have the following advantages: simplified process and reduced communication time. Only the initial connection uses the full standard TCP procedure; subsequent connections use lightweight algorithms such as SM4 and SM3, reducing CPU usage. Using cached certificates and hash indexes avoids exchanging complete dual certificates and trust chains every time; subsequent handshakes only send hash values, reducing network traffic. (2) The information board achieves decoupling of national cryptographic encryption and decryption with the specific information board manufacturer's protocol through the information board SDK adaptive protocol adaptation layer.

[0046] The information board SDK's adaptive protocol adaptation layer adopts a three-layer separation architecture to decouple national cryptographic encryption / decryption from specific information board vendor protocols: The first layer is a unified encryption interface layer: providing standardized national cryptographic encryption / decryption APIs to upper-layer applications, including functions for encrypted sending, decrypted receiving, session management, and certificate loading. Upper-layer business logic calls this unified API to complete data sending and receiving, shielding the differences in underlying protocols. The second layer is a protocol adaptation layer: containing three sub-modules—a protocol identifier (selecting the corresponding protocol processor based on device ID or configuration), a data mapper (maintaining a bidirectional mapping between standard data models and vendor formats), and a serializer / deserializer (converting data objects and byte streams). The third layer is a vendor protocol plugin layer: each vendor corresponds to an independent protocol plugin (dynamic library .so), implementing the vendor's unique handshake protocol, message encapsulation format, field encoding / decoding rules, verification algorithms, and session keep-alive mechanism.

[0047] When the information board starts, the SDK scans the specified plugin directory and loads the protocol dynamic libraries of all information board manufacturers. The SDK supports two protocol selection modes: Configuration-specified mode: The corresponding plugin is loaded directly based on the pre-configured manufacturer identifier in the configuration file. This is the default mode and is suitable for deployment scenarios with known manufacturer models. Automatic detection mode: When the configuration file does not specify or specifies an incorrect protocol, the SDK attempts to call the unpacking function of each plugin in turn to process the received data until a plugin successfully parses it. After successful identification, the protocol type is recorded, and subsequent communication directly uses that plugin.

[0048] When a new vendor's information board needs to be integrated, developers write the vendor's protocol plugin according to the standardized plugin interface specification, implementing all interface functions. The compiled plugin dynamic library is placed in the plugin directory, and the vendor's identifier is added to the configuration file. The new plugin is automatically loaded when the SDK starts, without requiring modification to the SDK core code, recompiling the SDK, or affecting other information boards.

[0049] (3) The intelligence board has autonomous security perception capabilities independent of the central side by using a pre-anomaly detection and autonomous defense mechanism based on behavioral baselines.

[0050] This mechanism incorporates a behavior baseline detection module within the intelligence board SDK, enabling the intelligence board to possess autonomous security awareness capabilities independent of the central side.

[0051] During operation, the SDK continuously monitors the following behavioral metrics: Communication frequency metric, recording the number of commands received per unit time, calculating a dynamic threshold based on historical data from the same time period over the past 7 days, and exceeding this threshold indicates an abnormal frequency; Command sequence validity metric, maintaining a state machine (idle state → handshake state → authenticated state → command execution state → result reporting state), each command has a valid preceding state, if a command that does not conform to the current state is received, it is considered an abnormal sequence; Command type distribution metric, statistically analyzing the proportion of various types of commands per unit time, if the proportion of sensitive commands such as configuration modification or firmware upgrade exceeds a preset threshold, it is considered an abnormal type distribution; Heartbeat continuity metric, maintaining a heartbeat timer, if no command or heartbeat response is received within the timeout period, it is considered a communication interruption; Network connection anomaly metric, periodically checking the network connection status of the intelligence board, under normal conditions only there is a TLCP connection with the central gateway or Internet emergency agent, if a connection to other target IPs or ports (such as SSH, Telnet, unknown ports) is detected, it is immediately considered a network connection anomaly and triggers defense.

[0052] Upon detecting an anomaly, the SDK executes a tiered response. Level 1 Response (Low Security Risk): Single sequential anomaly, frequency exceeding threshold, single type anomaly. Actions: Record alarm logs and report to the management platform, force re-authentication, and continue executing current commands (without interrupting business). Level 2 Response (Medium Security Risk): 3 consecutive sequential anomalies involving sensitive commands, 10 consecutive frequency exceeding thresholds with a continuously increasing trend, 5 consecutive type anomalies, or any network connection anomaly. Actions: Disconnect the current encrypted connection, enter a security lock state (reject all commands, only respond to unlock commands and heartbeats signed by the management platform with the private key), clear the session key in memory, and send an emergency alarm through a backup channel. The lock state can only be unlocked by the management platform or by a physical reboot on-site. Level 3 Response (High Security Risk): Firmware integrity verification fails. Actions are the same as Level 2 response, and the lock state can only be unlocked by a physical reboot on-site. After reboot, the factory firmware is automatically loaded from the backup partition.

[0053] Firmware integrity self-check operates as an independent security mechanism: During the early morning hours each day, the information board calculates the SM3 hash value of its own executable file using the SDK and compares it with the factory default value. If they match, the self-check is recorded as passed; if they do not match, it is determined that the firmware has been tampered with, immediately triggering a level 3 response and reporting an emergency alarm.

[0054] This step offers the following advantages: it transforms the original post-event anomaly detection into pre-event anomaly behavior detection, identifying and blocking anomalies before the information board content is tampered with, resulting in higher detection efficiency. It does not rely on other devices or modules; the detection module is integrated only within the SDK, thus reducing costs.

[0055] Example 2: Embodiment 2 of the present invention provides an encryption method for the end-to-end encryption system of the information board embedded SDK based on national cryptographic dual certificates as described in Embodiment 1, comprising the following steps: The control terminal initiates a national cryptographic TLCP connection to the IP address of the information board through the central gateway; The central gateway and the intelligence board exchange signature certificates and encryption certificates to verify the trust chain and device fingerprints. The session key is negotiated using the public key of the encryption certificate. The session key is only known to the control terminal and the information board. After the control terminal commands are encrypted and forwarded to the information board through the central gateway, they are decrypted and executed using the national cryptographic SDK.

[0056] The steps involved in the above embodiment two correspond to those in embodiment one. For specific implementation details, please refer to the relevant description section of embodiment one.

[0057] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this application can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0058] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data processing device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, an optical medium, or a semiconductor medium, etc.

[0059] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An end-to-end encryption system for an information board with an embedded SDK based on dual national cryptographic certificates, characterized in that, The system comprises a central terminal, branch terminals, and device terminals. The central terminal includes a control terminal and a central-side encrypted gateway cluster. The branch terminals include an internet emergency agent, and the control terminal includes intelligence boards. The control terminal is located in the management center and acts as the initiator of control commands for the intelligence boards, communicating with each intelligence board through the central-side encrypted gateway. The central-side encrypted gateway cluster includes hardware and software encryption gateways. The hardware encryption gateway is based on a dedicated server, providing high-performance national cryptographic computing capabilities and serving as the main device to handle daily business traffic. The software encryption gateway is deployed on a general-purpose server, implementing pure software national cryptographic proxy functionality, equivalent to the hardware encryption gateway, and serves as a backup device. The internet emergency agent is deployed at the management branch terminal nodes to listen to non-standard ports on the internet side and accept national cryptographic connection requests from the central-side gateway. Simultaneously, the internet emergency agent maintains a connection with the monitoring intranet and forwards the received encrypted data to the target intelligence board on the intranet. The controller of each intelligence board integrates the national cryptographic SDK through embedding or upgrading, realizing TLCP handshake, session key negotiation, data encryption and decryption, and certificate management functions for national cryptographic algorithms.

2. The end-to-end encryption system for an information board embedded SDK based on dual national cryptographic certificates as described in claim 1, characterized in that, The national cryptographic SDK is provided to information board manufacturers in the form of a static library or a dynamic library. Manufacturers then integrate it into the control program firmware of the information board. For new information board models, manufacturers compile the SDK and the information board control program together during the development phase to generate a complete firmware image containing national cryptographic functions, which is then directly burned into the Flash memory of the information board controller at the factory.

3. The end-to-end encryption system for an information board embedded with an SDK based on dual national cryptographic certificates as described in claim 1, characterized in that, When the information board is produced or upgraded, a unique national cryptographic dual certificate is issued by an internal trusted CA and transmitted and burned into the trusted storage area of ​​the information board controller through a secure channel.

4. The end-to-end encryption system for an information board embedded SDK based on dual national cryptographic certificates as described in claim 1, characterized in that, The Internet emergency agent is located at the boundary between the monitoring intranet and the Internet. It is configured with dual network cards, one for the intranet and one for the Internet. The intranet card is connected to the monitoring intranet, and the extranet card is connected to the Internet.

5. The end-to-end encryption system for an information board embedded SDK based on dual national cryptographic certificates as described in claim 1, characterized in that, The Internet emergency proxy software establishes TCP connections with both the central encryption gateway and the intelligence board, and performs pure byte stream pass-through between them, forwarding encrypted data from both sides to each other. The central encryption gateway and intelligence board perform encryption and decryption operations. The Internet emergency proxy software itself does not participate in any encryption and decryption operations and does not rely on certificates or encryption and decryption components.

6. The end-to-end encryption system for an information board embedded with an SDK based on dual national cryptographic certificates as described in claim 1, characterized in that, Internet emergency proxy software needs to have a public IP address on the internet side or be reachable through NAT mapping to ensure that a TCP connection with the gateway can be established. It also needs to deploy an intrusion detection / prevention system to perform in-depth detection of incoming traffic, identify and block attack behaviors.

7. The end-to-end encryption system for an information board embedded with an SDK based on dual national cryptographic certificates as described in claim 1, characterized in that, Three communication links are defined and arranged in descending order of priority: the main link is from the control terminal to the central hardware encryption gateway and then to the intelligence board; the backup link is from the control terminal to the central software encryption gateway and then to the intelligence board; and the emergency link is from the control terminal to the central gateway, then to the emergency agent and then to the intelligence board.

8. The end-to-end encryption system for an information board embedded with an SDK based on dual national cryptographic certificates as described in claim 1, characterized in that, It also includes a large monitoring network, which is physically isolated from the Internet. When the monitoring network is interrupted due to fiber optic cable failure or equipment malfunction, both the main link and the backup link between the control terminal and the information board are unavailable. In this case, the Internet emergency link is activated.

9. The end-to-end encryption system for an information board embedded SDK based on dual national cryptographic certificates as described in claim 1, characterized in that, The intelligence board uses the lightweight key negotiation mechanism of the national cryptographic TLCP for session key negotiation. It achieves decoupling of national cryptographic encryption and decryption with specific intelligence board vendor protocols through the intelligence board SDK adaptive protocol adaptation layer. Based on the behavior baseline, the pre-anomaly detection and autonomous defense mechanism enable the intelligence board to have autonomous security awareness capabilities independent of the central side.

10. An encryption method for an end-to-end encryption system based on a national cryptographic dual certificate embedded SDK in an information board, as described in any one of claims 1-9, characterized in that, Includes the following steps: The control terminal initiates a national cryptographic TLCP connection to the IP address of the information board through the central gateway; The central gateway and the intelligence board exchange signature certificates and encryption certificates to verify the trust chain and device fingerprints. The session key is negotiated using the public key of the encryption certificate. The session key is only known to the control terminal and the information board. After the control terminal commands are encrypted and forwarded to the information board through the central gateway, they are decrypted and executed using the national cryptographic SDK.

Images