A secure data transmission method suitable for open-source honeycomb terminal devices

Abstract

A kind of security data transmission method suitable for open source Hongmeng terminal equipment between, this method deeply integrates the distributed architecture of open source Hongmeng.1, by HMAC-SM3 two-way authentication to build "super terminal" trust domain, and the authentication system is integrated into the distributed identity authentication of Hongmeng.2, the data to be transmitted is encapsulated as Hongmeng atomization service, which is uniformly distributed by the distributed task scheduling center, and the encryption and authentication are completed in the distributed security sandbox using SM4-CCM block cipher mode.3, the present application utilizes the trusted device group mechanism and distributed database / file system to perform security hierarchical management on the keys and data throughout their life cycle. Finally, based on the device capability perception, the transmission strategy is dynamically adjusted, and the seamless networking of heterogeneous network devices is realized through the distributed soft bus. This scheme forms a native security transmission system deeply coupled with the underlying capabilities of Hongmeng system, effectively solving the security and efficiency problems of cross-device data flow.

Description

Technical Field

[0001] This invention belongs to the field of industrial communication security, specifically relating to a secure data transmission method applicable to open-source HarmonyOS terminal devices. Background Technology

[0002] With the rapid development of the Industrial Internet of Things (IIoT), the open-source HarmonyOS is increasingly being used in distributed device communication. However, in industrial scenarios such as natural gas transmission and distribution systems, terminal devices are often deployed in open environments where physical security is difficult to guarantee. Monitoring data transmitted via wireless networks faces security threats such as eavesdropping and tampering. Existing technologies have the following shortcomings: traditional encryption schemes (such as AES-CBC) are not deeply integrated with the HarmonyOS distributed architecture, resulting in performance degradation; key negotiation mechanisms (such as RSA key exchange) lack forward security; the device authentication process is susceptible to man-in-the-middle attacks, and channel conflicts are easily triggered when multiple devices respond concurrently. In addition, it is difficult to achieve unified security policy management in heterogeneous network environments, which restricts the efficiency of secure transmission of industrial data. Therefore, there is an urgent need for a secure transmission solution that is deeply adapted to open-source HarmonyOS, supports dynamic key management, and facilitates cross-device collaboration. Summary of the Invention

[0003] To address the aforementioned shortcomings, this invention provides a secure data transmission method applicable to open-source HarmonyOS terminal devices. Through two-way authentication, hybrid encryption, key update mechanisms, and secure transmission protocols such as TLS, it ensures the security, integrity, and authenticity of data transmission, possesses independent controllability, and effectively prevents data from being stolen or tampered with by third parties during transmission. It is suitable for industrial data acquisition scenarios involving long-distance transmission where the physical security of the link cannot be guaranteed.

[0004] To achieve the above objectives, the present invention adopts the following technical solution:

[0005] A secure data transmission method applicable to open-source HarmonyOS terminal devices includes:

[0006] Device discovery and authentication: In the device discovery and authentication steps, based on the open-source HarmonyOS distributed soft bus, a group of super terminal virtualized devices is built by broadcasting discovery requests through the CoAP protocol. The receiving end returns unicast messages and exchanges public keys. The HMAC-SM3 algorithm, which integrates role ID, user ID and management key ID, is used for two-way authentication. Authentication-passed devices form a trust domain based on the HarmonyOS distributed identity authentication system.

[0007] Identity authentication is implemented based on the HMAC-SM3 algorithm. Each device generates a public key and a private key pair. Two-way authentication is achieved by encrypting a random number and an identity identifier using the other device's public key. The identity identifier includes fields such as role ID, user ID, and management key ID. Only authenticated devices can participate in communication, ensuring the reliability of identity authentication and the security of data transmission.

[0008] Key Negotiation: Leveraging the distributed device virtualization capabilities of HarmonyOS, the Diffie-Hellman (DH) key exchange mechanism within the SuperTerminal trust domain allows both communicating parties to securely generate and transmit SM4 symmetric keys. This method enables both parties to jointly generate a shared symmetric key without directly transmitting the key, thereby reducing the risk of key interception or tampering during transmission. This symmetric key is used for subsequent data encryption. This mechanism significantly enhances the system's defense against man-in-the-middle attacks and improves data transmission security.

[0009] Data transmission: Data encryption and authentication are implemented based on the SM4-CCM block cipher mode. The CTR portion of the SM4-CCM mode uses the generated symmetric key to perform SM4 symmetric encryption on the data, while the CBC-MAC portion generates a message authentication code (MAC) to ensure the integrity of data transmission and prevent data tampering.

[0010] Key Update: The system supports multiple key update mechanisms, including updating keys by time, updating keys by communication volume, and updating keys for each communication, to adapt to terminal devices with different communication conditions and computing resources, balancing system load and security. Simultaneously, by introducing a random number factor and forward and backward security mechanisms, the security of key updates and the continuity of data transmission are guaranteed. Encrypted data can be transmitted using various communication methods, employing different transmission strategies for different types of terminal devices. In scenarios with limited computing power on terminal devices, the HarmonyOS soft bus message transmission mechanism can be used for ordered transmission in queues; in scenarios with sufficient computing power or higher security requirements, TLS / SSL protocols can be further used to encrypt the data transmission layer on top of encryption, providing a higher level of security.

[0011] Data storage: HarmonyOS introduces a distributed caching strategy, differentiating data security levels and storing it in partitions with varying security capabilities to implement security protection. This strategy supports seamless cross-device flow of keys throughout their entire lifecycle and cross-device key access control, promoting distributed identity authentication and data sharing.

[0012] Network communication: Distributed soft bus technology supports networking of heterogeneous networks with different protocols, solving the problem of data communication between devices with different protocols. This enables multiple HarmonyOS devices to automatically build a logically fully connected network, so users or business developers do not need to worry about the networking method and physical protocol.

[0013] Atomic service transmission: Through the HarmonyOS distributed task scheduling center, data is encapsulated into atomic services with cross-device transfer capabilities. The SM4-CCM block cipher mode is used for encryption and authentication. The CTR part uses the SM4 key for efficient encryption, and the CBC-MAC part generates a message authentication code to ensure integrity. The entire process is executed in isolation by the HarmonyOS distributed security sandbox.

[0014] On the other hand, the present invention provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, enable the processor to implement the aforementioned secure data transmission method applicable to open-source HarmonyOS terminal devices.

[0015] The advantages of this invention compared to the prior art are:

[0016] (1) System-level native security architecture to build a super terminal trust domain: This invention abandons the traditional approach of adding security patches to the upper layer of the operating system and deeply integrates security authentication with the distributed identity authentication system of HarmonyOS. Authentication devices are no longer isolated nodes, but together form a logical "super terminal" trust domain. This trust relationship native to the system architecture has security, stability and collaborative efficiency far exceeding the simple point-to-point authentication in existing technologies, fundamentally improving the overall credibility of the device group.

[0017] (2) Innovative Data Transfer Model Based on Atomized Services: Existing technologies typically only encrypt the data packets themselves during transmission. This invention creatively encapsulates the data to be transmitted into HarmonyOS atomic services, which are then uniformly managed and transferred by a distributed task scheduling center. This transforms data transmission from a simple information transfer into a cross-device migration of service capabilities. This model not only inherently possesses context awareness and state synchronization capabilities, but also executes the entire process in isolation within a distributed security sandbox, achieving the integration of business logic and security protection. This is an architectural advantage that Android, iOS, and other systems cannot replicate at the application layer.

[0018] (3) Distributed Full-Lifecycle Security Management: This invention utilizes the HarmonyOS Trusted Device Cluster mechanism to securely store keys in a hardware TEE and store business data in a distributed database or file system according to the security level. This breaks through the limitations of traditional data "security only upon landing," realizing secure and seamless flow and state synchronization of data and keys within the "super terminal." Compared to existing technologies that limit security strategies to a single device, this invention provides distributed security management capabilities covering the entire lifecycle of storage, access, and transmission, greatly enhancing the availability and security of data in multi-device scenarios.

[0019] (4) Dynamic Adaptive Security and Performance Balancing Strategy: This invention combines the HarmonyOS system's perception of device capabilities to achieve a highly intelligent transmission strategy. It can dynamically switch transmission modes (such as HarmonyOS soft bus queue transmission and TLS / SSL dual encryption) based on device computing power, network status, and security threats, and intelligently select the key update timing. This refined adaptive capability ensures the optimal balance between security and performance even on resource-constrained IoT devices, far superior to traditional fixed security strategies. Attached Figure Description

[0020] Figure 1 This is a structural diagram of a secure data transmission method applicable to open-source HarmonyOS terminal devices according to the present invention. Detailed Implementation

[0021] The present invention will now be described in further detail with reference to the accompanying drawings.

[0022] This invention relates to a secure data transmission method applicable to open-source HarmonyOS terminal devices, aiming to ensure the security, integrity and authenticity of data transmission, and to provide a secure, efficient and reliable data transmission method for industrial data acquisition scenarios with long-distance transmission and inability to guarantee the physical security of the link.

[0023] The overall method structure diagram of the present invention is as follows: Figure 1 As shown, the specific implementation method is as follows:

[0024] Step 1: Device discovery and authentication;

[0025] In the open-source HarmonyOS environment, device discovery is based on distributed soft bus technology, using the Constrained Application Protocol (CoAP) to send broadcast messages within the local area network. CoAP is an application-layer protocol specifically designed for constrained nodes and networks, suitable for use in resource-constrained IoT devices. The broadcast message contains basic information about the discovering device, such as device type and device ID, encapsulated in a specific format within the CoAP message. The message also includes a device type identifier (using the HarmonyOS device UUID), a role ID (assigned by the HarmonyOS distributed role management system), and a public key certificate (issued in the HarmonyOS TEE security environment). Upon startup, the receiving device uses the PublishService interface to publish its service, including service name and description. The published service information is then propagated within the local area network, awaiting discovery requests from discovering devices. When the receiving device receives a broadcast message from the discovering device, it parses it, extracts key information, verifies the request's legitimacy through the HarmonyOS device management service, and returns a unicast response containing its identity identifier (user ID + device ID + management key ID). Subsequently, both parties exchange SM2 public keys and perform two-way authentication using the HarmonyOS enhanced HMAC-SM3 algorithm. Upon successful authentication, a "super terminal" device group is formed, sending a CoAP unicast message containing device public keys and supported communication protocols as a reply to the discovering device. After receiving the reply unicast message from the receiving device, the discovering device parses the message and updates its local device information list. The updated information includes the receiving device's IP address, device status, etc., to facilitate subsequent communication with the receiving device.

[0026] Each communication device uses an asymmetric encryption algorithm such as RSA or ECC to generate a public-private key pair. The private key is kept secure by the device itself, while the public key is made public. Upon device discovery, the discovering and receiving ends exchange public keys, encrypt a random number and identity identifier using the other party's public key, and then send them to each other. The receiving end decrypts and compares the encrypted data using its private key. If the results match, two-way authentication is complete. To ensure the trustworthiness of the public key, the device requests a public key credential from the Huawei Cloud server. The device submits its public key and relevant device information. The cloud server verifies the device's legitimacy and the validity of the public key before signing it. The device subsequently uses this credential to prove its identity. The HarmonyOS distributed key management service is launched within the super terminal to obtain the computing power information of the group's devices through the HarmonyOS device virtualization layer.

[0027] Each IoT device maintains its own semaphore mechanism. A semaphore can be viewed as a counter used to control access to shared resources. During device discovery and authentication, semaphores control the order in which devices reply with unicast response messages. When a master device broadcasts a connection request, multiple IoT devices may receive the broadcast message simultaneously. Upon receiving the broadcast message, each IoT device first checks the state of its maintained semaphore. If the semaphore allows, the device queues according to certain rules (such as the order of device IDs) to reply with a unicast response message. Only when it is its turn will the device send a unicast response message, thus avoiding channel conflicts caused by multiple devices replying simultaneously. After sending the unicast response message, the device updates its maintained semaphore state, releases resources, and allows the next device to reply. Simultaneously, after completing communication with the discoverer, the device also updates its semaphore to prepare for subsequent participation in the device discovery and authentication process.

[0028] Before communication begins, two-way authentication is performed based on the HMAC-SM3 algorithm. Only authenticated devices can participate in the communication, ensuring the reliability of authentication and the security of data transmission. The specific steps are as follows:

[0029] Step 1.1: During device initialization, a unique identity identifier is configured, including role ID, user ID, and management key ID. Subsequently, device A and device B each generate a public key and a private key pair. Device A and device B generate a shared key through the DH key exchange mechanism, which is used to perform hash operations on authentication data packets to generate the Message Authentication Code (HMAC).

[0030] Step 1.2: When device A is ready to communicate with device B, device A generates a random number and combines it with the identity identifier to form an authentication data packet. Device A uses the shared key to perform a hash operation on the authentication data packet to generate a message authentication code (HMAC). The authentication data packet and the HMAC are combined and encrypted using device B's public key to generate an encrypted authentication request message MsgA, which is then sent to device B.

[0031] Step 1.3: After receiving the authentication request message MsgA, device B decrypts the message using its private key B, extracts the authentication data packet and HMAC, and uses the HMAC-SM3 algorithm to calculate the message authentication code of the decrypted authentication data packet using the shared key. It then compares the result with the received HMAC. If the two match, the authentication is successful.

[0032] Step 1.4: Device B generates a random number and combines it with the identity identifier to form the authentication data packet of Device B. Using the shared key and reverse hash operation, a message authentication code is generated, which is combined with the authentication data packet, encrypted with the public key of Device A, and an encrypted authentication request message MsgB is generated and sent to Device A.

[0033] Step 1.5: After receiving the authentication request message MsgB, device A decrypts the message using its private key A to extract the authentication data packet and message authentication code. Device A uses the HMAC-SM3 algorithm to calculate the message authentication code of the decrypted authentication data packet using the shared key, and compares it with the received HMAC. If they match, the authentication is successful, and the authenticated devices together form a logical super terminal.

[0034] Step 1.6: Device A combines the random number from Device B with its own identifier, encrypts the data packet using public key B to generate a final confirmation message MsgConfirmA, and sends it to Device B.

[0035] Step 1.7: After receiving MsgConfirmA, device B decrypts it with its private key B and extracts the random number and A's identity identifier. Device B verifies whether the random number is consistent with the one it generated. If they are consistent, the two-way authentication is successful, and device A and device B can communicate securely.

[0036] Step 2, Key Negotiation;

[0037] Based on the distributed device virtualization features of HarmonyOS, SM4 symmetric keys are generated and transmitted through the Diffie-Hellman (DH) key exchange mechanism for data encryption and authentication. The specific implementation is as follows:

[0038] Step 2.1: Device A and Device B negotiate to select a large prime number p and a generator g. These two parameters are shared and can be preset or negotiated at the beginning of the communication session.

[0039] Step 2.2: Device A randomly generates a private value 'a', and uses 'a' to calculate the public key A; Device B randomly generates a private value 'b', and uses 'b' to calculate the public key B.

[0040] Step 2.3: Device A sends public key A to device B, and device B sends public key B to device A. After receiving public key B, device A uses 'a' to calculate the shared key K_AB. After receiving public key A, device B uses 'b' to calculate the shared key K_AB. Due to the symmetry of modular arithmetic, the shared key calculated by device A and device B is the same. This key is the SM4 symmetric encryption key, used for subsequent encryption and authentication.

[0041] Based on this mechanism, devices A and B do not directly transmit keys. Instead, they calculate a shared key using their respective private values ​​and the other's public key. Therefore, even if an attacker intercepts public keys A and B, they cannot calculate the shared key K_AB and thus cannot decipher the communication content. This ensures the security of key transmission and improves the overall security of data transmission.

[0042] Step 3: Data transmission; The data to be transmitted is encapsulated into HarmonyOS atomic services through the HarmonyOS distributed task scheduling center and transmitted, and the data in the atomic services is encrypted and authenticated using the SM4-CCM block cipher mode.

[0043] The data is encrypted and authenticated using the SM4-CCM block cipher mode. SM4-CCM is an encryption mode that combines the Counter Mode (CTR) and Cipher Block Linked Message Authentication Code (CBC-MAC). It provides data encryption and verifies data integrity by generating a Message Authentication Code (MAC). The raw data is preprocessed using the HarmonyOS Distributed Data Management Service to construct an atomic service package body (including service ID, version number, and dependencies) and add a HarmonyOS-exclusive FA model descriptor. The specific implementation is as follows:

[0044] Step 3.1: Before encryption begins, device A prepares plaintext P and, if necessary, additional authentication data AAD. This additional authentication data is typically used to authenticate message headers or control information, ensuring the data has not been tampered with. Device A generates a unique random number, Nonce.

[0045] Step 3.2: In SM4-CCM mode, the CTR portion uses the generated shared symmetric key K_AB and the generated Nonce as input to generate the counter stream CTR for encryption. Device A uses the SM4 symmetric key K_AB and the generated counter stream CTR to encrypt the plaintext P. Specifically, block cipher is used; the plaintext P is divided into multiple 128-bit blocks, each block is encrypted sequentially to generate the corresponding ciphertext block, and finally combined to form the ciphertext C.

[0046] Step 3.3: Device A uses CBC-MAC mode to perform SM4 encryption on the ciphertext, additional authentication data ADD, and the generated Nonce to generate the authentication code MAC. Device A transmits the ciphertext C and the authentication code MAC together to Device B, while using the Nonce as an auxiliary data transmission.

[0047] Step 3.4: After receiving the data packet, Device B extracts the Nonce, ciphertext C, and authentication code MAC. Device B uses the same shared key K_AB and Nonce as Device A to generate a counter stream CTR and decrypts the ciphertext C to recover the original plaintext P. Device B processes the received ciphertext C, additional authentication data AAD, and Nonce using CBC-MAC mode and K_AB to generate a new authentication code MAC. This new MAC is compared with the received MAC. If they match, the data has been tampered with, and the verification is successful. Otherwise, the data is considered tampered with, the data packet is discarded, and the corresponding error handling mechanism is triggered.

[0048] Step 4: Key update;

[0049] To adapt to different communication conditions and the computing resources of terminal devices, multiple key update mechanisms are provided, including time-based key updates, data volume-based key updates, and automatic key updates after each communication. This ensures that the system can effectively balance system load while maintaining security. The specific implementation is as follows: ① Time-based key updates allow the system to update keys periodically according to a set time interval. System administrators can set the key update interval according to security requirements. When the preset time interval is reached, the system automatically generates a new key using the DH key exchange mechanism. ② In high-data-volume transmission scenarios, to prevent keys from being cracked after prolonged use, the system can trigger key updates based on the cumulative data volume transmitted during communication. By setting a data threshold, when the cumulative data volume reaches the preset threshold, the system will trigger a key update, similar to the time-based update mechanism. ③ The system can be set to automatically update keys after each communication to meet scenarios with multiple communications in a short period and sufficient computing resources. The system triggers a key update after each communication (such as the end of a session or the completion of a batch of data transmission). The key used for each communication is independent; even if a key is leaked in one session, it will not affect the security of other sessions, providing the highest level of security.

[0050] To further enhance security during the key update process, this invention introduces a random number factor and forward and backward security mechanisms. Each time a new key is generated, a new random number is randomly generated to participate in the key generation, ensuring the unpredictability and uniqueness of the new key. The forward security mechanism ensures that even if the old key is leaked, the new key cannot be derived; the backward security mechanism ensures that even if the new key is leaked, the previously used old key cannot be derived.

[0051] Encrypted data can be flexibly transmitted using different communication methods based on the computing power and security requirements of the terminal device, achieving a balance between performance and security. Specifically: ① In scenarios with limited computing power, data transmission utilizes the HarmonyOS soft bus message transmission mechanism. Encrypted data is encapsulated into message units, each including encrypted data payload, message header information, and necessary metadata. Message units are transmitted in an orderly manner according to the message queue mechanism within the soft bus framework, ensuring data transmission order and consistency, making the data transmission process simple and efficient. Despite limited computing power, the data still undergoes SM4-CCM encryption and HMAC-SM3 authentication, ensuring basic data security and integrity, sufficient to meet the security requirements of general communication. ② In scenarios with sufficient computing power or higher security requirements, encrypted data transmission is further protected using the TLS / SSL protocol. The TLS / SSL protocol adds encryption and integrity protection to the data transmission layer on top of the original SM4-CCM encryption, preventing security threats such as man-in-the-middle attacks and data tampering. The TLS / SSL protocol workflow specifically includes: handshake to confirm the identities of both parties before communication begins; generating a session key to encrypt data transmission; and generating a message authentication code to ensure that data is not tampered with during transmission. This approach is particularly suitable for scenarios involving sensitive data, and can prevent potential cyberattacks and data breaches.

[0052] The dynamic policy switching mechanism includes: when the device starts up, it detects its own computing power level (such as CPU load and remaining memory) and selects the initial transmission policy through the decision engine. During runtime, it monitors network status (such as latency and packet loss rate) and security events (such as key update failure alarms) in real time and dynamically switches transmission modes: when insufficient computing power is detected (such as CPU utilization > 80%), it degrades to soft bus queue transmission; when the security threat level increases (such as frequent authentication failures), it forces the use of TLS / SSL dual encryption.

[0053] Step 5: Data storage; Using the Trusted Device Group mechanism of HarmonyOS, the session key and historical key are stored in the Hardware Secure Execution Environment (TEE), and the transmitted data is stored in the open-source HarmonyOS distributed database or distributed file system according to the security level, so as to realize seamless cross-device access and state synchronization.

[0054] Based on the sensitivity of the data, it is divided into three security levels: high, medium, and low, and stored in corresponding partitions. The high-security zone is used to store keys and identity information, employing strong encryption and strict access control; the medium-security zone is used for general data, employing moderate security measures; and the low-security zone stores non-sensitive data, with relatively lenient security measures. This partitioned storage strategy ensures the security of different types of data.

[0055] It enables full lifecycle management of keys, supporting seamless cross-device transfer. When a device requests access to a key from another device, it must provide authentication credentials, ensuring that only authorized devices can obtain the key. Simultaneously, it employs fine-grained access control policies to ensure that data in different security zones can only be accessed by devices with the appropriate permissions, thereby enhancing system security.

[0056] Distributed identity authentication, combining public-private key pairs and digital certificates, ensures the authenticity of device identities. When devices update data, an event notification mechanism promptly synchronizes relevant information, guaranteeing data consistency and real-time performance. This mechanism not only promotes data sharing but also enhances the security of communication between devices.

[0057] Step 6: Network communication;

[0058] Distributed soft bus technology supports networking of heterogeneous networks with different protocols, solving the problem of data communication between devices using different protocols. This allows multiple HarmonyOS devices to automatically build a logically fully connected network, without requiring users or business developers to worry about the networking method or physical protocol. The specific implementation method is as follows:

[0059] Step 6.1, Protocol Adaptation and Automatic Discovery: A protocol adaptation layer is designed to support access from multiple communication protocols (such as Wi-Fi, Bluetooth, Zigbee, etc.), and a distributed soft bus is used to automatically identify the device's network type. Through adapter mode, the system can convert data formats from different protocols into a universal format, achieving seamless data transmission. Simultaneously, devices automatically identify and connect to surrounding devices through broadcast or multicast discovery mechanisms, building a logically fully connected network.

[0060] Step 6.2, Intelligent Data Routing and Forwarding: Intelligent routing algorithms are employed to optimize data transmission paths, ensuring efficient data communication. Data transmission between devices utilizes a message queue mechanism, supporting asynchronous communication and retransmission mechanisms to guarantee data reliability and timeliness. This mechanism enhances network flexibility and response speed.

[0061] Step 6.3, User-Transparent Interface and Security Management: A unified API interface is provided, hiding underlying network and protocol details to simplify operations for users and developers. The system implements device authentication and data encryption to ensure communication security, while using Role-Based Access Control (RBAC) to manage device permissions and ensure the security of data sharing.

[0062] On the other hand, the present invention provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, enable the processor to implement the aforementioned secure data transmission method applicable to open-source HarmonyOS terminal devices.

[0063] In summary, this invention provides a secure data transmission method suitable for open-source HarmonyOS terminal devices. By combining a distributed soft bus mechanism, bidirectional authentication using the HMAC-SM3 algorithm, Diffie-Hellman key exchange to generate SM4 symmetric keys, SM4-CCM encryption and authentication, and multiple key update mechanisms, it achieves efficient and reliable data transmission protection. Specifically, the system supports heterogeneous network topology through a protocol adaptation layer, automatically discovering and authenticating devices to ensure the authenticity of identities and the integrity of data. Simultaneously, it flexibly selects either the HarmonyOS soft bus message transmission mechanism or the TLS / SSL protocol, optimizing data transmission performance and security based on the computing power and security requirements of the terminal devices. Furthermore, the distributed caching strategy strengthens data storage security by classifying data security levels, ensuring the security and access control of different types of data. This combination of technologies not only improves the security of communication between devices but also provides a convenient operating experience for users and developers. Content not described in detail in this specification belongs to prior art known to those skilled in the art.

[0064] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for secure data transmission between open-source HOMER terminal devices, characterized in that, The method comprises the following steps: Step 1, device discovery and authentication: based on the open source distributed bus of Hongmeng, a discovery request is broadcasted through the CoAP protocol, and a unicast message is returned by the receiving end and the public key is exchanged; Under the Hongmeng distributed identity authentication system, the HMAC-SM3 algorithm is used to perform bidirectional authentication by fusing the role ID, user ID and management key ID, and the devices that pass the authentication together form a logical super terminal; Step 2, session key negotiation: based on the distributed device virtualization feature of Hongmeng, an SM4 symmetric key is generated through the Diffie-Hellman key agreement protocol within the super terminal trust domain; Step 3, data transmission: through the Hongmeng distributed task scheduling center, the data to be transmitted is encapsulated as a Hongmeng atomized service with cross-device flow capability for transmission, and the data in the atomized service is encrypted and authenticated using the SM4-CCM block cipher mode, wherein the CTR part of the SM4-CCM block cipher mode uses the generated SM4 symmetric key for symmetric encryption, and the CBC-MAC part generates a message authentication code MAC to ensure the integrity of the data transmission process.

2. The method of claim 1, wherein the method is applied to secure data transmission between open-source HOMER terminal devices. The method further comprises: Step 4, key update: all keys are updated according to the device computing power, time, data volume or session round; Step 5, high-security key storage: using the trusted device group mechanism of the Hongmeng system, the SM4 symmetric key is stored in the hardware secure execution environment TEE, and the data to be transmitted is stored in the open source Hongmeng distributed database or distributed file system according to the security level, realizing cross-device non-invasive access and state synchronization; Step 6, networking communication: adapt to multiple protocol devices through the distributed soft bus to automatically build a logically fully connected network. 3.The method of claim 1, wherein, In step 1, all discovery and receiving end devices use independent semaphore maintenance schemes, and after broadcasting a discovery request through the CoAP protocol, the signal quantity is used to control the ordered response of multiple devices.

4. The method of claim 1, wherein the method is applied to secure data transmission between open source HOMER terminal devices. In step 1, the bidirectional authentication using the HMAC-SM3 algorithm includes that the discovery end and receiving end devices respectively generate an asymmetric key pair, encrypt a random number and an identity identifier with the public key of the opposite end device, generate a message authentication code through the HMAC-SM3 algorithm, and complete bidirectional authentication, wherein the identity identifier includes a role ID, a user ID and a management key ID.

5. The method of claim 1, wherein the method is applied to secure data transmission between open source HOMER terminal devices. Step 2 includes: Step 2.1, the receiving end device and the discovery end device negotiate to select a prime number and a generator as common parameters; Step 2.2, the receiving end device randomly generates a private value a and calculates a public key A using the private value a; the discovery end device randomly generates a private value b and calculates a public key B using the private value b; Step 2.3, the receiving end device and the discovery end device exchange the calculated public keys and respectively calculate a shared key using their own private values as the SM4 symmetric key.

6. The method of claim 1, wherein the method is applied to secure data transmission between open-source HOMER terminal devices. Step 3 includes: Step 3.1, before encryption starts, the sending end device prepares plaintext and additional authentication data, and generates a random number Nonce; Step 3.2, the CTR part of the SM4-CCM mode uses the generated SM4 symmetric key and the random number Nonce as input to generate a counter stream CTR for encryption; the SM4 symmetric key and the counter stream CTR are used to encrypt the plaintext; Step 3.3, the sending end device uses the CBC-MAC mode to perform SM4 encryption operation on the ciphertext, the additional authentication data and the random number Nonce to generate an authentication code MAC, and transmits the ciphertext and the authentication code MAC to the receiving end device, and simultaneously transmits the random number Nonce as auxiliary data; Step 3.4, after receiving the data packet, the receiving end device extracts the Nonce, the ciphertext and the authentication code MAC, generates a counter stream CTR using the SM4 symmetric key and the Nonce, and decrypts the ciphertext to recover the original plaintext.

7. The method of claim 2, wherein the method is applied to secure data transmission between open-source HOMER terminal devices. The step 4 further comprises a dynamic policy switching mechanism, which detects the computing power level of the device when starting, selects an initial transmission policy through a decision engine, and monitors network status and security events in real time during operation to dynamically switch the transmission mode: when insufficient computing power is detected, the soft bus queue transmission is downgraded; when the security threat level is increased, the TLS / SSL double encryption is forcibly enabled. 8.The method of claim 2, wherein, The step 5 comprises dividing the data into high, medium and low security levels according to the sensitivity of the data, and storing them in the corresponding partitions; the high security area is used to store keys and identity information, and strong encryption and strict access control are adopted; the medium security area is used for general data, and moderate security measures are adopted; the low security area stores non-sensitive data. 9.The method of claim 2, wherein, The step 6 comprises networking heterogeneous networks using different protocols based on the distributed soft bus to realize barrier-free data interaction of multi-protocol devices.

10. A computer readable storage medium characterized by, The executable instructions stored thereon enable the processor to implement the method for secure data transmission between open source Hongmeng terminal devices according to any one of claims 1-9 when executed by the processor.

Images