A data transmission method, apparatus, electronic device, and storage medium

Abstract

This application relates to the field of data transmission technology, and provides a data transmission method, apparatus, electronic device, and storage medium. The method involves acquiring raw data sent by a transmitting device and parsing it to identify target data; performing a digital signature operation on the target data using the private key of a locally configured hardware trusted module to obtain a digital signature; and generating a target message based on the target data and the digital signature; obtaining a multi-dimensional security verification result for the target data; and sending the target message if the multi-dimensional security verification result of the target data passes. Alternatively, a proxy gateway performs digital signature processing on the target data and obtains the corresponding multi-dimensional security verification result, sending the target message only when the verification passes. This places the security processing of the target data at the proxy gateway on the transmission path, without modifying the original underlying processing logic of the transmitting device, thus achieving enhanced security before data transmission.

Description

Technical Field

[0001] This application relates to the field of data transmission technology, and in particular to a data transmission method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the development of industrial internet and Internet of Things technologies, more and more traditional industrial control equipment, such as programmable logic controllers (PLCs), distributed control systems (DCS) and data acquisition and monitoring control systems (SCADA), are being connected to the network environment to realize data interaction and collaborative control between devices.

[0003] However, in industrial control scenarios, many underlying devices still use traditional industrial communication protocols for data transmission, such as Modbus TCP. These protocols were designed primarily for real-time and reliable communication, typically lacking security mechanisms such as authentication, data encryption, tamper protection, and replay protection. Therefore, in networked application scenarios, the data transmission process is susceptible to security risks such as malicious command injection, data forgery, and replay attacks.

[0004] Especially in critical infrastructure sectors such as nuclear power and electricity, control commands or business data issued by devices such as SCADA, RTU, operator stations, and engineer stations often directly affect the operating status and control safety of field equipment. For such scenarios, existing security measures typically focus on boundary isolation, link encryption, user authentication, or device access authentication. While these can improve system security to some extent, they often lack fine-grained identification, verification, and signature protection mechanisms before sending the specific data content, especially the target data that requires key protection. Therefore, they are insufficient to meet the requirements for data authenticity, integrity, compliance, and traceability in high-security scenarios.

[0005] Furthermore, industrial control systems typically contain a large number of existing devices, and significant modifications to the original software and communication programs are generally not advisable. Modifying the internal logic of the transmitting device through intrusive methods is not only costly but may also disrupt the stable operation of existing business systems. Therefore, how to enhance the security of target data in the transmitted data while minimizing changes to the original business logic of the transmitting device has become a pressing issue in current technology. Summary of the Invention

[0006] In view of this, embodiments of this application provide a data transmission method, apparatus, electronic device, and storage medium to solve the problem in the prior art that industrial control equipment is unable to provide security protection for transmitted data without modifying the original underlying equipment when facing malicious command issuance, data forgery, and replay attacks.

[0007] A first aspect of this application provides a data transmission method, the method comprising: acquiring raw data sent by a transmitting device and parsing the raw data to identify target data from the raw data; performing a digital signature operation on the target data using the private key of a locally configured hardware trusted module to obtain a digital signature, and generating a target message based on the target data and the digital signature; acquiring a multi-dimensional security verification result for the target data, and if the multi-dimensional security verification result of the target data is a successful verification, then sending the target message. A second aspect of this application provides a data transmission apparatus, comprising: an acquisition module for acquiring raw data sent by a transmission device and parsing the raw data to identify target data from the raw data; a signature module for performing a digital signature operation on the target data using the private key of a locally configured hardware trusted module to obtain a digital signature, and generating a target message based on the target data and the digital signature; and a transmission module for acquiring a multi-dimensional security verification result for the target data, and if the multi-dimensional security verification result of the target data is successful, transmitting the target message.

[0008] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0009] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0010] The beneficial effects of this application embodiment compared with the prior art are as follows: The method in this application embodiment obtains the original data sent by the sending device and parses the original data to identify the target data from the original data; performs digital signature operation on the target data using the private key of the locally set hardware trusted module to obtain a digital signature, and generates a target message based on the target data and the digital signature; obtains the multi-dimensional security verification result for the target data, and if the multi-dimensional security verification result of the target data passes the verification, the target message is sent. By obtaining the original data sent by the sending device from the proxy gateway side corresponding to the sending device and identifying the target data from it, the proxy gateway performs digital signature processing on the target data and obtains the corresponding multi-dimensional security verification result, and sends the target message only when the verification passes, thereby placing the security processing of the target data on the proxy gateway side of the sending path without modifying the original underlying processing logic of the sending device, thus achieving security enhancement before sending the data. Furthermore, digitally signing the target data improves the verifiability of its source and the integrity of its content. By determining whether to send the target message based on multi-dimensional security verification results before transmission, it facilitates the interception of abnormal data, illegal commands, or data that does not meet preset security conditions. This enhances the security of data transmission in industrial control scenarios and reduces the risks associated with malicious command issuance, data forgery, and replay attacks. This avoids the problem in existing technologies where industrial control equipment struggles to securely protect transmitted data from malicious command issuance, data forgery, and replay attacks without modifying the underlying equipment. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, 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.

[0012] Figure 1 This is a flowchart illustrating a data transmission method provided in an embodiment of this application; Figure 2 This is a timing diagram of a data transmission method provided in an embodiment of this application; Figure 3 This is a timing diagram of yet another data transmission method provided in an embodiment of this application; Figure 4 This is a flowchart illustrating another data transmission method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a data transmission device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] A data transmission method and apparatus according to an embodiment of this application will now be described in detail with reference to the accompanying drawings.

[0015] Figure 1 This is a flowchart illustrating a data transmission method provided in an embodiment of this application, as shown below. Figure 1 As shown, the method includes: S101. Obtain the raw data sent by the transmitting device and parse the raw data to identify the target data from the raw data; Understandably, this method can be applied to proxy gateways deployed in conjunction with the transmitting devices. In a typical industrial control scenario, the transmitting device can be an engineering workstation, operator workstation, or SCADA (Supervisory Control and Data Acquisition) system, while the receiving device can be a PLC (Programmable Logic Controller), DCS (Distributed Control System), or RTU (Remote Terminal Unit). The proxy gateway can be deployed in series using transparent bridging mode or bypassed using proxy forwarding mode, thereby achieving non-intrusive interception and processing of network traffic from the transmitting device without altering the original internal application of the transmitting device.

[0016] Specifically, the proxy gateway can obtain the raw data sent by the sending device by monitoring the network traffic of the sending device, receiving the data stream sent by the sending device to a predetermined communication port, or taking over the outgoing communication link of the sending device. The raw data can be a message, message segment, command data stream, or other data content to be sent, and this embodiment does not limit this.

[0017] After obtaining the raw data, the proxy gateway parses it. Parsing may include identifying and extracting data format, protocol fields, function codes, parameter fields, address fields, payload content, or other business fields of the raw data to determine whether the raw data contains target data that needs to be processed for security.

[0018] The target data can be any data content in the original data that requires signature protection and security verification. For example, the target data can be control command data, configuration modification data, write operation data, or other preset data types. It should be noted that the specific type of target data can be flexibly set according to the actual application scenario, and this application does not limit it in this regard.

[0019] S102. Use the private key of the locally configured hardware trusted module to perform digital signature operation on the target data to obtain a digital signature, and generate a target message based on the target data and the digital signature. After identifying the target data, the proxy gateway invokes a locally configured trusted hardware module to perform digital signature operations on the target data. The trusted hardware module can be a TPM module, a TPCM module, or other trusted hardware modules with secure key storage and hardware cryptographic operation capabilities; this embodiment does not limit this.

[0020] Specifically, the hardware trusted module internally stores the private key used for digital signature calculations. This private key is kept within the hardware trusted module and is not exported in plaintext to external storage or business processes. After identifying the target data, the proxy gateway submits the target data to the hardware trusted module, which then uses its internal private key to perform digital signature calculations on the target data to generate a digital signature corresponding to the target data.

[0021] After obtaining the digital signature, the proxy gateway generates a target message based on the target data and the digital signature. The target message can be a message to be sent formed by appending the digital signature to the target data, or it can be a message re-encapsulated based on the target data and the digital signature. This embodiment does not limit this.

[0022] By using the above methods, subsequent target messages can be equipped with signature protection corresponding to the target data, thereby improving the reliability and integrity protection capabilities of the target messages during the transmission process.

[0023] S103. Obtain the multi-dimensional security verification result for the target data. If the multi-dimensional security verification result of the target data is successful, send the target message.

[0024] In this embodiment, the proxy gateway further obtains multi-dimensional security verification results for the target data. These multi-dimensional security verification results can be output by a security verification module locally configured on the proxy gateway, or by other processing modules used to assess the security of the target data; this embodiment does not limit the specifics.

[0025] Specifically, the multi-dimensional security verification results are used to characterize whether the target data meets the preset transmission security conditions. After obtaining the multi-dimensional security verification results corresponding to the target data, the proxy gateway makes a judgment on the multi-dimensional security verification results.

[0026] If the multi-dimensional security verification result indicates that the verification is successful, the proxy gateway sends the target message so that it reaches the corresponding receiving device for further processing. If the multi-dimensional security verification result indicates that the verification is unsuccessful, the proxy gateway does not send the target message, thereby preventing the continued transmission of target data that does not meet the transmission security conditions.

[0027] Through the above method, this embodiment realizes signature protection and pre-send security verification of target data on the proxy gateway side corresponding to the sending device, and decides whether to send the target message based on the verification result, thereby improving the security and reliability of the data sending process.

[0028] According to the technical solution provided in this application, the target data is identified by acquiring the original data sent by the sending device and parsing it. A digital signature operation is performed on the target data using the private key of a locally configured hardware trusted module to obtain a digital signature. A target message is then generated based on the target data and the digital signature. A multi-dimensional security verification result for the target data is obtained. If the multi-dimensional security verification result of the target data passes, the target message is sent. By acquiring the original data sent by the sending device from the proxy gateway side corresponding to the sending device and identifying the target data, the proxy gateway performs digital signature processing on the target data and obtains the corresponding multi-dimensional security verification result. The target message is sent only when the verification passes. This places the security processing of the target data on the proxy gateway side of the sending path without modifying the original underlying processing logic of the sending device, thus achieving enhanced security before the data is sent. Furthermore, digitally signing the target data improves the verifiability of its source and the integrity of its content. By determining whether to send the target message based on multi-dimensional security verification results before transmission, it facilitates the interception of abnormal data, illegal commands, or data that does not meet preset security conditions. This enhances the security of data transmission in industrial control scenarios and reduces the risks associated with malicious command issuance, data forgery, and replay attacks. This avoids the problem in existing technologies where industrial control equipment struggles to securely protect transmitted data from malicious command issuance, data forgery, and replay attacks without modifying the underlying equipment.

[0029] In some embodiments, the step S103 of "obtaining the multi-dimensional security verification result for the target data" can be performed simultaneously with the process of performing digital signature calculation on the target data in step S102, or it can be performed before or after step S102. This application does not limit this. That is to say, the order between the security verification process for the target data and the digital signature calculation process is not limited, as long as the multi-dimensional security verification result corresponding to the target data can be obtained before sending the target message.

[0030] Specifically, the multi-dimensional security verification results can be obtained by verifying the target data based on a dynamic filtering engine.

[0031] In some embodiments, obtaining multi-dimensional security verification results for target data may include the following process: the proxy gateway calls the locally configured dynamic filtering engine and queries whether there is a filtering rule program corresponding to the target data in the dynamic filtering engine; if there is no filtering rule program corresponding to the target data in the dynamic filtering engine, the proxy gateway sends a request to the security management platform to obtain the filtering rule program and dynamically loads the filtering rule program into the dynamic filtering engine; then, the dynamic filtering engine runs the filtering rule program to verify the target data to obtain multi-dimensional security verification results.

[0032] Specifically, after identifying the target data, the proxy gateway can determine the filter rule program identifier that matches the target data based on the data type, protocol characteristics, service category, source identifier, sending direction, or other preset matching conditions. It then queries the dynamic filtering engine to see if a corresponding filter rule program already exists. The filter rule program is used to perform security verification processing on the target data to generate multi-dimensional security verification results for the target data.

[0033] The security management platform can pre-store multiple filtering rule programs, each corresponding to different data types, device types, business scenarios, or security policies. When the proxy gateway has a filtering rule program corresponding to the target data locally, it can directly run the filtering rule program using the dynamic filtering engine to verify the target data and obtain multi-dimensional security verification results. When the proxy gateway does not have a filtering rule program corresponding to the target data locally, it sends a request to the security management platform to obtain it. The request can carry identification information to characterize the target data, so that the security management platform can return a filtering rule program that matches the target data. After receiving the filtering rule program, the proxy gateway dynamically loads it into the dynamic filtering engine, enabling the dynamic filtering engine to perform security verification on the current target data.

[0034] Dynamic loading allows newly acquired filtering rules to be loaded into the runtime environment of the dynamic filtering engine without interrupting the current business processing flow of the proxy gateway, thereby improving the flexibility of security policy updates and business continuity.

[0035] The dynamic filtering engine receives target data as input and calls the filtering rule program to process the target data, outputting a multi-dimensional security verification result corresponding to the target data. The multi-dimensional security verification result can be information indicating whether the target data meets the preset transmission security conditions, such as verification passed, verification failed, or other information that can reflect the verification status. This embodiment does not limit this.

[0036] In this way, the proxy gateway can dynamically obtain and load the corresponding filtering rules program according to the actual type and security requirements of the target data, and complete the security verification of the target data based on the filtering rules program. This is conducive to achieving flexible configuration and dynamic updates of security policies without modifying the original business logic of the sending device, thereby improving the adaptability and security of the data sending process.

[0037] In some examples, the filtering rule program includes at least two of the following verification subroutines: instruction format compliance check program, operation permission verification program, timing rationality analysis program, and business logic legality verification program; the filtering rule program is run using a dynamic filtering engine to verify the target data and obtain multi-dimensional security verification results, including: running each verification subroutine contained in the filtering rule program using the dynamic filtering engine to obtain the single-dimensional verification result corresponding to the verification subroutine; and combining at least two single-dimensional verification results to obtain a multi-dimensional security verification result.

[0038] It is understandable that using the dynamic filtering engine to run the various verification subroutines included in the filtering rule program, and obtaining the single-dimensional verification results corresponding to each verification subroutine, includes, but is not limited to: using the dynamic filtering engine to run the instruction format compliance check program, performing instruction format compliance checks on the target data, and obtaining instruction format compliance check results. Instruction format compliance checks can be used to determine whether the data structure, protocol fields, function codes, parameter formats, or message organization of the target data conform to preset requirements. Using the dynamic filtering engine to run the operation permission verification program, performing operation permission verification on the target data, and obtaining operation permission verification results. Operation permission verification can be used to determine whether the sending entity corresponding to the target data has the permission to perform the corresponding operation. Using the dynamic filtering engine to run the timing rationality analysis program, performing timing rationality analysis on the target data, and obtaining timing rationality analysis results. Timing rationality analysis can be used to determine whether the target data has duplicate transmissions, abnormal retransmissions, abnormal transmission order, or other situations that do not conform to preset timing requirements, and can be used to identify replay attack risks. Using the dynamic filtering engine to run the business logic legality verification program, performing business logic legality verification on the target data, and obtaining business logic legality verification results. Business logic validity verification can be used to determine whether target data conforms to preset business rules, control process rules, process constraints, or operational relationships.

[0039] It should be noted that, in different embodiments, the filtering rule program may selectively include at least two of the above-mentioned verification subroutines based on the business scenario and security requirements corresponding to the target data. This application does not limit the types and combinations of verification subroutines included in the filtering rule program.

[0040] The synthesis of at least two single-dimensional verification results can be achieved by summarizing and judging multiple single-dimensional verification results according to preset synthesis judgment rules to determine whether the target data meets the transmission security conditions. For example, when all single-dimensional verification results involved in the synthesis indicate that the corresponding verification has passed, the multi-dimensional security verification result can be determined as verification passed; when at least one single-dimensional verification result involved in the synthesis indicates that the corresponding verification has failed, the multi-dimensional security verification result can be determined as verification failed. Alternatively, the synthesis can also be based on preset priority, weight relationship, or combined judgment strategy to jointly analyze multiple single-dimensional verification results to generate the final multi-dimensional security verification result, which is not limited in this application.

[0041] Through the above methods, the dynamic filtering engine can perform joint verification of target data based on multiple security dimensions, and form corresponding multi-dimensional security verification results. This helps to improve the comprehensiveness and accuracy of the judgment of the security status of target data, thereby enhancing the security protection capabilities during data transmission.

[0042] In some examples, the target data is digitally signed using the private key of the locally configured hardware trusted module to obtain a digital signature. This process includes: obtaining the security context information of the proxy gateway, which includes at least a timestamp and a device identifier; associating the security context information with the target data to obtain the data to be signed; and using the private key inside the hardware trusted module chip to perform a digital signature operation on the data to be signed to generate a digital signature.

[0043] The security context information is used to characterize the sending environment and source attributes of the current target data. The timestamp can be used to characterize the processing time or sending time of the target data, and the device identifier can be used to characterize the identity information of the sending device or proxy gateway. The device identifier can be a device number, terminal identification code, IP address, MAC address, or other information that can identify the device; this application does not limit this.

[0044] The proxy gateway can combine security context information with target data according to preset rules to obtain data to be signed. It should be noted that the association method can be concatenation, encapsulation, mapping, or other processing methods that establish a correspondence between security context information and target data; this application does not limit this. By associating security context information with target data, the subsequent signing result can not only correspond to the target data itself but also reflect time information and device origin information related to the target data.

[0045] Then, the proxy gateway submits the data to be signed to the hardware trusted module. The hardware trusted module then uses the private key stored internally in the chip to perform a digital signature operation on the data to be signed, thereby generating the corresponding digital signature. The private key is stored internally in the hardware trusted module chip and is not exported to the external environment in plaintext during the digital signature operation, thus improving the security of the signing process.

[0046] In some examples, the hardware trusted module can directly perform digital signature operations on the data to be signed; in other examples, the proxy gateway can first perform a digest calculation on the data to be signed, and then submit the digest value to the hardware trusted module, which uses the private key inside the chip to perform a digital signature operation on the digest value to generate a digital signature. This application does not limit this.

[0047] By using the above methods, target data can be associated with time information and device source information before signing, thereby enhancing the ability of digital signatures to protect the authenticity of the target data source, the integrity of the content, and the timeliness.

[0048] In some examples, the proxy gateway deploys a main gateway business process and a hardware security microservice process independent of the main gateway business process. It uses the private key of a locally configured hardware trusted module to perform digital signature calculations on the target data, obtaining a digital signature. This includes: sending a signature request to the hardware security microservice process via an inter-process communication channel through the main gateway business process. The signature request triggers the hardware security microservice process to call the corresponding hardware driver interface, enabling the hardware trusted module to perform digital signature calculations on the target data within the chip; and receiving the digital signature returned by the hardware security microservice process via the inter-process communication channel.

[0049] Specifically, the gateway's main business process can be used to perform business processing functions such as data reception, raw data parsing, target data identification, target packet generation, and transmission control of the proxy gateway; the hardware security microservice process can be used to perform security operation processing functions related to the hardware trusted module, such as signature request reception, signature task scheduling, hardware driver invocation, and signature result return. This application deploys business processing functions and hardware security processing functions in different processes, making the data plane processing and hardware security processing of the proxy gateway independent of each other.

[0050] In some examples, after the gateway's main business process identifies the target data, it can generate a signature request corresponding to the target data and send the signature request to the hardware security microservice process via an inter-process communication channel. The signature request may carry the data to be signed, a request identifier, a session identifier, time information, or other information used to characterize the signing task; this application does not limit this.

[0051] The inter-process communication channel can be a local socket, shared memory, message queue, pipe, remote procedure call channel based on a local loopback interface, or other inter-process communication mechanism suitable for transmitting data between the gateway main business process and the hardware security microservice process. This application does not limit this.

[0052] Upon receiving a signature request, the hardware security microservice process can parse the request and call the hardware driver interface corresponding to the hardware trusted module. This allows the hardware trusted module to perform digital signature operations on the target data or the corresponding data to be signed within the chip, generating a digital signature. Because the signature operation is completed within the hardware trusted module chip, the private key used for signing can always be stored within the hardware trusted module and is not exposed to the gateway's main business process.

[0053] After generating the digital signature, the hardware security microservice process returns the digital signature to the gateway main service process via an inter-process communication channel. Upon receiving the digital signature, the gateway main service process can generate a target message based on the target data and the digital signature, and decide whether to send the target message based on the corresponding multi-dimensional security verification results.

[0054] It should be noted that, in different embodiments, the gateway main business process and the hardware security microservice process can use synchronous or asynchronous call methods, and this application does not limit this. For example, after sending a signature request, the gateway main business process can block and wait for the signature result to return; or, after sending a signature request, the gateway main business process can continue to execute other processing flows and subsequently obtain the digital signature through callback, polling, or message notification.

[0055] By encapsulating the signature processing capabilities related to the hardware trusted module in an independent hardware security microservice process and interacting with the gateway's main business process through a cross-process communication channel, the coupling between the proxy gateway's main business process and the underlying hardware driver is reduced, thereby improving the flexibility of system deployment, the stability of business processing, and the independent maintenance capability of the security module.

[0056] In some examples, the data transmission method provided in this application further includes: obtaining the processing result of the target data and generating an audit record based on the processing result, wherein the audit record includes at least: device information of the sending device, processing timestamp, multi-dimensional security verification result and fingerprint information corresponding to the digital signature; calling the private key inside the hardware trusted module to perform digital signature operation on the audit record to obtain the audit record signature; and sending the audit record with the audit record signature to the audit management center.

[0057] Specifically, after completing the signature processing and security verification of the target data, the proxy gateway can obtain the processing result corresponding to the target data. The processing result can be used to characterize the processing status of the target data on the proxy gateway side, such as whether the target data has passed multi-dimensional security verification, whether a target message has been generated, whether it has been allowed to be sent, or other information that can reflect the processing process and processing conclusion. This application does not limit this.

[0058] After obtaining the processing results, the proxy gateway generates corresponding audit logs based on those results. These audit logs record key information about the target data during processing, facilitating subsequent security audits, accountability, and incident analysis.

[0059] The audit log should include at least: device information of the sending device, processing timestamp, multi-dimensional security verification results, and fingerprint information corresponding to the digital signature. The device information of the sending device can be used to identify the source device of the target data, specifically including device number, terminal identification code, IP address, MAC address, or other information that can identify the sending device; the processing timestamp can be used to characterize the time when the target data was processed, verified, or sent; the multi-dimensional security verification results can be used to characterize whether the target data meets the preset sending security conditions; and the fingerprint information corresponding to the digital signature can be used to characterize the identification information of the digital signature corresponding to the target data, for subsequent signature association verification and audit tracing.

[0060] Furthermore, the proxy gateway invokes the private key stored within the hardware trusted module to perform a digital signature operation on the audit record, thereby generating an audit record signature. Specifically, the proxy gateway can submit the audit record or its corresponding digest value to the hardware trusted module, which then invokes the private key stored internally in the chip to perform a digital signature operation on the audit record or the digest value, thereby generating an audit record signature. This application does not limit the specifics of this method. Since the audit record signature is generated by the private key stored within the hardware trusted module, the authenticity and tamper-proof capability of the audit record are improved.

[0061] After obtaining the audit record signature, the proxy gateway sends the audit record with the signature to the audit management center. Specifically, the proxy gateway can upload the audit record and its corresponding signature to the audit management center through a preset communication link, enabling the audit management center to uniformly store, centrally manage, and subsequently analyze the audit records.

[0062] It should be noted that, in different embodiments, the audit record can be generated immediately after the target data processing is completed, or it can be generated uniformly after summarizing the processing results of multiple target data within a preset time window. This application does not limit this. Correspondingly, the audit record can be sent to the audit management center in real time, at regular intervals, or triggered by a specific timeframe. This application does not limit this either.

[0063] The above methods can record the processing process, processing conclusions, and corresponding signature information of the target data. After the audit record is signed and protected by a hardware trusted module, it is sent to the audit management center. This helps to improve the authenticity, completeness, and traceability of the audit record, thereby enhancing the audit support capabilities and security management capabilities of the data transmission process.

[0064] In some examples, before performing a digital signature operation on the target data using the private key of a locally configured hardware trusted module to obtain the digital signature, the method further includes: triggering the hardware trusted module to generate an authentication key pair inside the chip, and sending a certificate request containing the public key in the authentication key pair to a private certification authority, so that the private certification authority, after confirming the authenticity of the hardware trusted module based on the endorsement key of the hardware trusted module, returns an authentication key certificate for the public key; sending the authentication key certificate to the receiving device, so that the receiving device, after receiving the target message, verifies the legality of the digital signature based on the public key in the authentication key certificate.

[0065] Specifically, the proxy gateway can trigger the hardware trusted module to generate an authentication key pair within the chip during the initialization phase, registration phase, or when initially establishing a trusted communication relationship with the receiving device. The authentication key pair includes a public key and a private key. The private key is stored internally within the hardware trusted module chip and is not exported to the external environment in plaintext. The public key is used for subsequent applications for authentication key certificates.

[0066] After generating the authentication key pair, the proxy gateway generates a certificate request and sends it to the private certification authority. The certificate request may include the public key from the authentication key pair, as well as relevant information characterizing the identity of the trusted hardware module or device; this application does not impose any limitations on this.

[0067] Upon receiving a certificate request, the private certification authority can verify the authenticity of the trusted hardware module based on its endorsement key. Specifically, the endorsement key represents the trusted identity of the hardware module itself. After confirming that the hardware module is a trusted hardware module, the private certification authority generates a corresponding authentication key certificate based on the public key carried in the certificate request and returns the authentication key certificate to the proxy gateway.

[0068] After obtaining the authentication key certificate, the proxy gateway can send the authentication key certificate to the receiving device. Specifically, the authentication key certificate can be sent to the receiving device when establishing a communication connection, or it can be sent in conjunction with a subsequent target message; this application does not limit this. The authentication key certificate contains the public key corresponding to the private key in the authentication key pair, thereby providing a trusted basis for the receiving device to subsequently verify the digital signature.

[0069] In some examples, after the proxy gateway performs a digital signature operation on the target data using the private key inside the hardware trusted module chip and generates the target message, the receiving device, upon receiving the target message, can obtain the authentication key certificate corresponding to the target message and verify the digital signature corresponding to the target message based on the public key in the authentication key certificate. If the verification passes, it indicates that the digital signature matches the private key corresponding to the authentication key certificate, thus indicating that the source of the target message is trustworthy and the signature has not been tampered with; if the verification fails, the receiving device can refuse to receive or refuse to process the target message.

[0070] It should be noted that, in different embodiments, the timing of applying for the authentication key certificate can be when the device first comes online, during a preset periodic update, or when the original certificate expires; this application does not limit this. Correspondingly, the method by which the authentication key certificate is sent to the receiving device can also be pre-sent, sent per session, sent with a message, or sent on demand; this application does not limit this.

[0071] By using the above method, an authentication key certificate issued by a private certification authority can be established for the authentication key pair generated inside the hardware trusted module before the target data is signed. This enables the receiving device to verify the legitimacy of the digital signature based on the public key in the authentication key certificate, thereby improving the credibility of the target message source authentication and the reliability of signature verification, and further enhancing the security of the data transmission process.

[0072] In some examples, to enable both communicating parties to reliably verify each other's identities, the proxy gateway and the peer device can also perform a bidirectional exchange of authentication keys and certificates. The peer device can be a receiving device or any other device that needs to establish a trusted communication relationship with the proxy gateway; this application does not limit this.

[0073] Specifically, the proxy gateway can send its own authentication key certificate to the peer device; correspondingly, the proxy gateway can also receive peer authentication key certificates sent by the peer device. Upon receiving the peer authentication key certificate, the proxy gateway can verify its validity. This validity verification may include: verifying whether the issuer of the peer authentication key certificate is a pre-defined private certification authority, verifying whether the peer authentication key certificate is valid, and verifying whether the peer authentication key certificate matches the identity information of the current peer device; this application does not limit the scope of this verification.

[0074] Correspondingly, after receiving the authentication key certificate sent by the proxy gateway, the peer device can also verify the legitimacy of the proxy gateway's authentication key certificate. In this way, both communicating parties can obtain and verify the other party's corresponding authentication key certificate and confirm the trustworthiness of the public key held by the other party.

[0075] In some examples, after the proxy gateway and the peer device have verified each other's authentication key certificates, they can save the verified peer's public key as a trusted public key. In subsequent communications, they can use this trusted public key to perform digital signature verification, identity confirmation, or other secure communication processes. Specifically, when sending a target message, the proxy gateway can generate a digital signature using the private key corresponding to its own authentication key. Upon receiving the target message, the peer device can verify the digital signature using the public key in the proxy gateway's authentication key certificate. Correspondingly, when the peer device sends data to the proxy gateway, the proxy gateway can also verify the digital signature corresponding to the data sent by the peer using the public key in the peer's authentication key certificate.

[0076] In this way, both parties can not only prove the credibility of their own identities, but also establish a two-way trusted authentication relationship by receiving and verifying the authentication key certificates sent by each other. This provides a trusted foundation for subsequent signature verification, identity confirmation and secure communication of target messages, thereby improving the credibility of identities and data security during the communication process.

[0077] To better understand this application, this embodiment provides a more specific example for illustration.

[0078] This example illustrates secure communication between terminal device A and terminal device B. Both terminal device A and terminal device B can be devices used in industrial control scenarios, such as PLCs, DCS devices, RTU devices, SCADA station devices, engineer workstations, operator workstations, or other devices with hardware trusted modules; this application does not limit their use. It should be noted that this example uses terminal device A as the transmitting device and terminal device B as the receiving device. The roles of terminal device A and terminal device B can be interchanged in different scenarios; this example is merely for illustrative purposes.

[0079] In some examples, the data transmission method may include the following stages.

[0080] Phase 1: such as Figure 2 As shown, both communicating parties register with a private certification authority, generate authentication key pairs, and obtain authentication key certificates.

[0081] In some examples, terminal device A first triggers its embedded hardware trusted module (TPCM_A) to generate an authentication key pair within the chip, which includes an authentication private key and an authentication public key. The authentication private key is stored internally within the hardware trusted module chip and is not exported to the external environment in plaintext. Correspondingly, terminal device B also triggers its embedded hardware trusted module (TPCM_B) to generate a corresponding authentication key pair within the chip.

[0082] After generating the authentication key pair, terminal device A sends a certificate request to a private certification authority (private CA) to apply for an authentication key certificate for its authentication public key. Specifically, the certificate request may include terminal device A's authentication public key and proof information generated based on the endorsement key of the trusted hardware module corresponding to terminal device A, used to prove that the authentication public key was generated by a genuine and trusted hardware module. Upon receiving the certificate request, the private certification authority can verify the authenticity of the trusted hardware module corresponding to terminal device A based on the root certificate corresponding to the endorsement key or the trusted information pre-stored in the data. After successful verification, the private certification authority issues the corresponding authentication key certificate for the authentication public key.

[0083] Correspondingly, terminal device B can also perform the same or similar processing procedure as terminal device A to apply for and obtain an authentication key certificate for its own authentication public key from a private certification authority.

[0084] In this way, both parties in the communication can obtain authentication key certificates corresponding to their own authentication key pairs, thus providing a foundation for establishing a trusted communication relationship in the future.

[0085] Phase Two: The two communicating parties exchange authentication key certificates and perform two-way device authentication.

[0086] In some examples, terminal device A sends its authentication key certificate to terminal device B, and terminal device B sends its authentication key certificate to terminal device A. Since the authentication key certificate mainly contains public key information and certificate issuance information, the certificate exchange process can be carried out through existing communication links.

[0087] In some examples, after receiving the authentication key certificate from terminal device A, terminal device B can verify the certificate using the public key of the private certification authority to confirm that it was issued by a trusted private certification authority. If the verification is successful, terminal device B can generate a random challenge value and send it to terminal device A. Upon receiving the challenge value, terminal device A invokes its hardware trusted module to sign the challenge value using the authentication private key stored internally in the chip, generating a response message, which is then returned to terminal device B. Terminal device B then verifies the response message using the authentication public key from terminal device A's authentication key certificate. If the verification passes, it indicates that terminal device A indeed possesses the authentication private key corresponding to its authentication key certificate, and that the authentication private key is protected by a genuine hardware trusted module. At this point, terminal device B can save the authentication public key corresponding to terminal device A as a trusted public key.

[0088] Correspondingly, terminal device A can also perform the same or similar challenge-response authentication process on terminal device B to verify the authenticity of terminal device B's identity.

[0089] In this way, the two communicating parties can receive and verify the authentication key certificate sent by the other party, and further confirm that the other party does indeed hold the authentication private key corresponding to the authentication key certificate through the challenge-response mechanism, thereby establishing a two-way trusted authentication relationship between the two communicating parties.

[0090] Phase 3: Target data signature and multi-dimensional security verification.

[0091] In some examples, after the two communicating parties complete the exchange of authentication key certificates and two-way device authentication, the private certification authority may no longer participate in the online data transmission process. That is, during the online operation phase of the system, the private certification authority can be offline, and terminal device A and terminal device B can perform subsequent secure communication processing based on the aforementioned established trusted relationship.

[0092] In some examples, the proxy gateway corresponding to terminal device A acquires the raw data sent by terminal device A in real time. For example, the raw data may be a Modbus TCP command stream or other industrial protocol data streams. This application does not limit this. The proxy gateway intercepts and parses the raw data to identify target data that requires security processing.

[0093] After identifying the target data, such as Figure 3 As shown, the proxy gateway invokes the locally configured dynamic filtering engine to perform security verification on the target data, thereby obtaining multi-dimensional security verification results for the target data. In some examples, if the dynamic filtering engine does not contain a filtering rule program corresponding to the target data, the proxy gateway can send a request to the security management platform to obtain the filtering rule program corresponding to the target data, dynamically load the filtering rule program into the dynamic filtering engine, and then perform the corresponding verification processing.

[0094] In some examples, the filtering rule program can be a WASM program, and the dynamic filtering engine can be a WASM dynamic filtering engine. Accordingly, after the dynamic filtering engine runs the filtering rule program, it can analyze the target data from multiple security dimensions. For example, such as... Figure 4 As shown, multi-dimensional security verification can include the following checks: instruction format compliance check, operation permission verification, timing rationality analysis (time window verification), and business logic legality verification (business rule verification). Through the above verifications, multi-dimensional security verification results corresponding to the target data can be generated.

[0095] In some examples, the multi-dimensional security verification process for the target data can be executed simultaneously with the digital signature operation process for the target data, or it can be executed before or after the digital signature operation process. This application does not limit this, as long as the multi-dimensional security verification result corresponding to the target data can be obtained before sending the target message.

[0096] In some examples, while performing security verification on the target data, the proxy gateway can also invoke a locally configured hardware trusted module to perform digital signature processing on the target data. Specifically, the proxy gateway can obtain security context information corresponding to the target data, which includes at least a timestamp and device identifier, and associate the security context information with the target data to obtain the data to be signed. Then, the proxy gateway submits the data to be signed, or its corresponding digest value, to the hardware trusted module, which uses the private key stored internally in the chip to perform digital signature calculations to generate a digital signature.

[0097] In some examples, the proxy gateway can deploy a main gateway process and a hardware security microservice process independent of the main gateway process. The main gateway process can send signature requests to the hardware security microservice process via an inter-process communication channel, such as a gRPC channel. Upon receiving the signature request, the hardware security microservice process can call the hardware driver interface corresponding to the hardware trusted module, enabling the hardware trusted module to perform digital signature operations on the data to be signed or the digest value within the chip, and return the generated digital signature to the main gateway process. Since the private key used for signing is always stored inside the hardware trusted module chip, there is no need to export the private key to external memory during the entire signing process, which improves the security of the signing process.

[0098] After obtaining the digital signature and acquiring the multi-dimensional security verification results, the proxy gateway generates the target message based on the target data and the digital signature. If the multi-dimensional security verification result indicates that the verification is successful, the proxy gateway sends the target message; if the multi-dimensional security verification result indicates that the verification is unsuccessful, the proxy gateway blocks the sending of the target message.

[0099] By using the above methods, target data identification, signature protection, and pre-send security verification can be achieved on the proxy gateway side without modifying the original underlying processing logic of the terminal device, thereby improving the authenticity, integrity, and security of the data transmission process.

[0100] Phase Four: Audit Record Generation and Audit Record Signing.

[0101] In some examples, after completing the signature processing and security verification of the target data, the proxy gateway can also obtain the processing result corresponding to the target data and generate an audit log based on the processing result. The audit log may include at least: device information of the terminal device, processing timestamp, multi-dimensional security verification results, and fingerprint information corresponding to the digital signature. In some examples, the audit log may further include the reason for verification failure, message processing status, or other information that can reflect the processing process; this application does not limit this.

[0102] In some examples, the proxy gateway uses the private key stored within the hardware trusted module to perform a digital signature operation on the audit record, thereby generating an audit record signature. Specifically, the proxy gateway can submit an audit record or its corresponding digest value to the hardware trusted module, which then uses the private key stored internally in the chip to perform a digital signature operation on either the audit record or the digest value, to generate the audit record signature.

[0103] After obtaining the audit log signature, the proxy gateway can send the audit log with the signature to the audit management center, or sign and save it. Upon receiving the audit log, the audit management center can verify the audit log signature based on the public key corresponding to the pre-saved authentication key certificate, thereby confirming the authenticity and integrity of the audit log.

[0104] The above methods can reliably record the processing process, processing conclusions, and signature information of the target data, and protect the audit records with signatures through a hardware trusted module, thereby improving the anti-tampering and traceability capabilities of audit information.

[0105] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0106] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0107] This embodiment also provides a data transmission device, such as... Figure 5 As shown, the data transmission device includes: The acquisition module 501 is used to acquire the raw data sent by the transmitting device and parse the raw data to identify the target data from the raw data. The signature module 502 is used to perform digital signature operations on the target data using the private key of the locally configured hardware trusted module, obtain a digital signature, and generate a target message based on the target data and the digital signature. The sending module 503 is used to obtain the multi-dimensional security verification result of the target data. If the multi-dimensional security verification result of the target data is successful, the target message is sent.

[0108] In some examples, obtaining multi-dimensional security verification results for target data includes: calling the dynamic filtering engine on the proxy gateway's local machine and querying whether the dynamic filtering engine has a filtering rule program corresponding to the target data; if the dynamic filtering engine does not have a filtering rule program, sending a request to the security management platform to pull the filtering rule program and dynamically loading the filtering rule program into the dynamic filtering engine; and using the dynamic filtering engine to run the filtering rule program to verify the target data in order to obtain multi-dimensional security verification results.

[0109] In some examples, the filtering rule program includes at least two of the following verification subroutines: instruction format compliance check program, operation permission verification program, timing rationality analysis program, and business logic legality verification program; the filtering rule program is run using a dynamic filtering engine to verify the target data and obtain multi-dimensional security verification results, including: running each verification subroutine contained in the filtering rule program using the dynamic filtering engine to obtain the single-dimensional verification result corresponding to the verification subroutine; and combining at least two single-dimensional verification results to obtain a multi-dimensional security verification result.

[0110] In some examples, the target data is digitally signed using the private key of the locally configured hardware trusted module to obtain a digital signature. This process includes: obtaining the security context information of the proxy gateway, which includes at least a timestamp and a device identifier; associating the security context information with the target data to obtain the data to be signed; and using the private key inside the hardware trusted module chip to perform a digital signature operation on the data to be signed to generate a digital signature.

[0111] In some examples, the proxy gateway deploys a main gateway business process and a hardware security microservice process independent of the main gateway business process. It uses the private key of a locally configured hardware trusted module to perform digital signature calculations on the target data, obtaining a digital signature. This includes: sending a signature request to the hardware security microservice process via an inter-process communication channel through the main gateway business process. The signature request triggers the hardware security microservice process to call the corresponding hardware driver interface, enabling the hardware trusted module to perform digital signature calculations on the target data within the chip; and receiving the digital signature returned by the hardware security microservice process via the inter-process communication channel.

[0112] In some examples, the device is also used to obtain the processing results of the target data and generate an audit record based on the processing results. The audit record includes at least: device information of the sending device, processing timestamp, multi-dimensional security verification results, and fingerprint information corresponding to the digital signature; the device calls the private key inside the hardware trusted module to perform digital signature operation on the audit record to obtain the audit record signature; and the audit record with the audit record signature is sent to the audit management center.

[0113] In some examples, before performing a digital signature operation on the target data using the private key of a locally configured hardware trusted module to obtain the digital signature, the method further includes: triggering the hardware trusted module to generate an authentication key pair inside the chip, and sending a certificate request containing the public key in the authentication key pair to a private certification authority, so that the private certification authority, after confirming the authenticity of the hardware trusted module based on the endorsement key of the hardware trusted module, returns an authentication key certificate for the public key; sending the authentication key certificate to the receiving device, so that the receiving device, after receiving the target message, verifies the legality of the digital signature based on the public key in the authentication key certificate.

[0114] According to the technical solution provided in this application, the target data is identified by acquiring the original data sent by the sending device and parsing it. A digital signature operation is performed on the target data using the private key of a locally configured hardware trusted module to obtain a digital signature. A target message is then generated based on the target data and the digital signature. A multi-dimensional security verification result for the target data is obtained. If the multi-dimensional security verification result of the target data passes, the target message is sent. By acquiring the original data sent by the sending device from the proxy gateway side corresponding to the sending device and identifying the target data, the proxy gateway performs digital signature processing on the target data and obtains the corresponding multi-dimensional security verification result. The target message is sent only when the verification passes. This places the security processing of the target data on the proxy gateway side of the sending path without modifying the original underlying processing logic of the sending device, thus achieving enhanced security before the data is sent. Furthermore, digitally signing the target data improves the verifiability of its source and the integrity of its content. By determining whether to send the target message based on multi-dimensional security verification results before transmission, it facilitates the interception of abnormal data, illegal commands, or data that does not meet preset security conditions. This enhances the security of data transmission in industrial control scenarios and reduces the risks associated with malicious command issuance, data forgery, and replay attacks. This avoids the problem in existing technologies where industrial control equipment struggles to securely protect transmitted data from malicious command issuance, data forgery, and replay attacks without modifying the underlying equipment.

[0115] Figure 6 This is a schematic diagram of the electronic device 6 provided in an embodiment of this application. Figure 6 As shown, the electronic device 6 of this embodiment includes a processor 601, a memory 602, and a computer program 603 stored in the memory 602 and executable on the processor 601. When the processor 601 executes the computer program 603, it implements the steps in the various method embodiments described above. Alternatively, when the processor 601 executes the computer program 603, it implements the functions of each module / unit in the various device embodiments described above.

[0116] Electronic device 6 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 6 may include, but is not limited to, processor 601 and memory 602. Those skilled in the art will understand that... Figure 6 This is merely an example of electronic device 6 and does not constitute a limitation on electronic device 6. It may include more or fewer components than shown, or different components.

[0117] The processor 601 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0118] The memory 602 can be an internal storage unit of the electronic device 6, such as a hard disk or RAM of the electronic device 6. The memory 602 can also be an external storage device of the electronic device 6, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the electronic device 6. The memory 602 can also include both internal and external storage units of the electronic device 6. The memory 602 is used to store computer programs and other programs and data required by the electronic device.

[0119] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0120] If an integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in a computer-readable medium can be appropriately added to or subtracted according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0121] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A data transmission method, characterized in that, The data transmission method is applied to a proxy gateway corresponding to the transmitting device, and the method includes: The raw data transmitted by the transmitting device is acquired and parsed to identify the target data from the raw data. The target data is digitally signed using the private key of the locally configured trusted hardware module to obtain a digital signature, and a target message is generated based on the target data and the digital signature. Obtain the multi-dimensional security verification result for the target data. If the multi-dimensional security verification result of the target data is successful, then send the target message.

2. The method according to claim 1, characterized in that, Obtain multi-dimensional security verification results for the target data, including: Invoke the local dynamic filtering engine of the proxy gateway and query whether the dynamic filtering engine has a filtering rule program corresponding to the target data; If the dynamic filtering engine does not have the filtering rule program, it sends a request to the security management platform to retrieve the filtering rule program and dynamically loads the filtering rule program into the dynamic filtering engine. The dynamic filtering engine is used to run the filtering rule program to verify the target data in order to obtain the multi-dimensional security verification results.

3. The method according to claim 2, characterized in that, The filtering rule program includes at least two of the following verification subroutines: instruction format compliance check program, operation permission verification program, timing rationality analysis program, and business logic legality verification program; The dynamic filtering engine is used to run the filtering rule program to verify the target data, thereby obtaining the multi-dimensional security verification results, including: The dynamic filtering engine is used to run each of the verification subroutines contained in the filtering rule program, and the single-dimensional verification results corresponding to the verification subroutines are obtained respectively. The multi-dimensional security verification result is obtained by combining at least two of the single-dimensional verification results.

4. The method according to claim 1, characterized in that, Using the private key of a locally configured hardware trusted module, a digital signature is obtained by performing a digital signature operation on the target data, including: Obtain the security context information of the proxy gateway, wherein the security context information includes at least a timestamp and a device identifier; The security context information is associated with the target data to obtain the data to be signed; The digital signature is generated by performing a digital signature operation on the data to be signed using the private key inside the hardware trusted module chip.

5. The method according to any one of claims 1-4, characterized in that, The proxy gateway deploys a main gateway business process and a hardware security microservice process independent of the main gateway business process; The step of performing a digital signature operation on the target data using the private key of a locally configured hardware trusted module to obtain a digital signature includes: The gateway main business process sends a signature request to the hardware security microservice process via the cross-process communication channel. The signature request is used to trigger the hardware security microservice process to call the corresponding hardware driver interface so that the hardware trusted module performs digital signature calculation on the target data inside the chip. The digital signature returned by the hardware security microservice process is received through the cross-process communication channel.

6. The method according to claim 1, characterized in that, The method further includes: Obtain the processing result for the target data, and generate an audit record based on the processing result, wherein the audit record includes at least: the device information of the sending device, the processing timestamp, the multi-dimensional security verification result, and the fingerprint information corresponding to the digital signature; The audit record is digitally signed by calling the private key inside the trusted hardware module to obtain the audit record signature; The audit record, bearing the signature of the audit record, is sent to the audit management center.

7. The method according to claim 1, characterized in that, Before obtaining the digital signature by performing a digital signature operation on the target data using the private key of a locally configured hardware trusted module, the method further includes: The hardware trusted module is triggered to generate an authentication key pair inside the chip and send a certificate request containing the public key in the authentication key pair to a private certification center, so that the private certification center, after confirming the authenticity of the hardware trusted module based on the endorsement key of the hardware trusted module, returns an authentication key certificate for the public key. The authentication key certificate is sent to the receiving device, so that after receiving the target message, the receiving device verifies the legality of the digital signature based on the public key in the authentication key certificate.

8. A data transmission device, characterized in that, The device includes: The acquisition module is used to acquire the raw data sent by the transmitting device and parse the raw data to identify the target data from the raw data; The signature module is used to perform digital signature operations on the target data using the private key of the locally configured hardware trusted module, to obtain a digital signature, and to generate a target message based on the target data and the digital signature. The sending module is used to obtain the multi-dimensional security verification result of the target data. If the multi-dimensional security verification result of the target data is successful, the target message is sent.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images