A DDS secure communication method

Abstract

The present application discloses a DDS secure communication method, wherein a DDS entity loads a local configuration file to determine the QoS state and security parameters, and creates a pre-selected security domain for the local end; the pre-selected security domains all include a zero security domain; the DDS publisher and the DDS subscriber send notification messages to each other to establish a communication connection; if the DDS entity determines that the current security domain of the local end is a zero security domain, the notification message includes the current QoS state of the local end and a globally unique identifier; if the DDS entity determines that the current security domain of the opposite end is a zero security domain based on the current QoS state of the opposite end, the zero security domain session key of the local end is generated using a preset secret key derivation algorithm based on the security parameters corresponding to the zero security domain of the local end and the globally unique identifier of the opposite end; the DDS entity communicates securely with the opposite end based on the zero security domain session keys of each end. The present application can take into account the secure communication needs of DDS for resource-constrained devices.

Description

Technical Field

[0001] The present application belongs to the field of data communication technology, and specifically relates to a DDS secure communication method. Background Art

[0002] DDS (Data Distribution Service) is a communication middleware protocol released by OMG (Object Management Group). DDS provides users with high-performance, high-reliability, scalable, and loosely coupled solutions through a data-centric publish-subscribe model.

[0003] With the development of automobile networking, the demand for communication security is also increasing. When using DDS in the automotive field, the problem of how to solve communication security is faced. OMG proposed a distributed data service (DDS) security mechanism (DDS Security) based on public key infrastructure (PKI), which realizes communication security based on DDS through scalable authentication, access control and encryption service plug-ins. This solution can effectively solve the data transmission security problem in DDS communication. However, due to the limited computing and storage resources of some resource-constrained devices such as MCU (Microcontroller Unit), even if the hardware acceleration modules such as Crypto Service Module (encryption service module) and KeyM (key management) on the Control Processor (control processor) are used, it is difficult to meet the needs of certificate storage and private key calculation operations during the authentication process.

[0004] Therefore, providing a DDS secure communication method that can take into account resource-constrained devices is a technical problem that needs to be solved in the art. Summary of the invention

[0005] The technical purpose of this application is to provide a DDS security communication method that can take into account resource-constrained devices to meet the requirements of the current distributed data service (DDS) security mechanism (DDS Security).

[0006] To achieve the above objectives, this application adopts the following technical solutions.

[0007] The present application provides a DDS secure communication method, including:

[0008] The DDS entity loads a local configuration file, determines the QoS state and security parameters corresponding to the pre-selected security domain according to the configuration file, and creates the pre-selected security domain corresponding to the local end according to the QoS state and the security parameters; the DDS entity includes a DDS publisher and a DDS subscriber; the pre-selected security domains of the DDS publisher and the DDS subscriber both include a zero security domain;

[0009] The DDS publisher and the DDS subscriber send notification messages to each other to establish a communication connection; if the DDS publisher or the DDS subscriber determines that the security domain to which the terminal currently belongs is the zero security domain, the notification message includes the current QoS state and the globally unique identifier corresponding to the security domain to which the terminal currently belongs;

[0010] If the DDS publisher or the DDS subscriber determines that the security domain to which the other party currently belongs is the null security domain according to the current QoS state of the other party, the null security domain session key of the local end is generated by using a preset secret key derivation algorithm according to the security parameters corresponding to the local null security domain and the global unique identifier of the other party;

[0011] The DDS publishing end and the DDS subscribing end respectively communicate securely with the other end based on the zero security domain session key of each end.

[0012] Furthermore, the security parameters corresponding to the null security domain of the DDS publisher are the same as the security parameters corresponding to the null security domain of the DDS subscriber.

[0013] Furthermore, the security parameter corresponding to the zero security domain is a key identifier of the root key;

[0014] Based on the security parameters corresponding to the local zero-safe domain and the peer's globally unique identifier, the preset key derivation algorithm is used to generate the local zero-safe domain session key, including:

[0015] The root key is determined according to the key identifier, and the zero security domain session key of the opposite end is generated using a preset key derivation algorithm according to the root key and the globally unique identifier of the opposite end.

[0016] Furthermore, the method also includes: presetting the root key and securely storing the root key.

[0017] Further, the DDS publishing end or the DDS subscribing end respectively communicates securely with the other end based on the zero security domain session key of each end, including:

[0018] The DDS publisher encrypts the plaintext data using a preselected encryption algorithm based on the zero-safe domain session key of the local end to obtain encrypted data, generates a message authentication code corresponding to the plaintext data based on the zero-safe domain session key of the local end, generates a DDS encrypted message according to the encrypted data and the message authentication code, and sends the DDS encrypted message to the DDS subscriber;

[0019] The DDS subscriber decrypts the encrypted data in the DDS encrypted message based on the zero security domain session key of the local end to obtain the plaintext data, generates a message authentication code corresponding to the plaintext data based on the zero security domain session key of the local end, and performs a legitimacy check based on the message authentication code.

[0020] Furthermore, the pre-selected security domain further includes a security domain, and the security parameters corresponding to the security domain include a digital certificate, a private key and an authority file of a PKI security mechanism;

[0021] The method further includes: if the DDS publisher or the DDS subscriber determines that the security domain to which the terminal currently belongs is the first security domain, the notification message includes the current QoS state corresponding to the security domain to which the terminal currently belongs, the digital certificate, private key and authority file of the PKI security mechanism;

[0022] If the DDS publisher or the DDS subscriber determines that the security domain to which the other party currently belongs is the first security domain according to the current QoS status of the other party, the DDS publisher or the DDS subscriber performs access control and identity authentication as well as security domain session key exchange with the other party according to the digital certificate, private key and authority file of the PKI security mechanism;

[0023] The DDS publishing end and the DDS subscribing end respectively communicate securely with the other end based on the security domain session key of each end.

[0024] Furthermore, the DDS publisher and / or the DDS subscriber may be arranged in a microcontroller.

[0025] Compared with the prior art, the DDS secure communication method provided by the present application has the following beneficial technical effects: during the secure communication process, the zero security domain can be applicable to scenarios of resource-constrained devices, and the session key is determined by specific security parameters and a globally unique identifier. It does not require complex encryption algorithms and a large number of resource-occupying operations, and has low device resource consumption. Therefore, it can take into account the secure communication needs of DDS for resource-constrained devices. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 A schematic diagram of the DDS secure communication method flow provided in an embodiment of the present application;

[0027] Figure 2A schematic diagram of a process for secure communication between a DDS publisher and a DDS subscriber in a DDS secure communication method provided in an embodiment of the present application;

[0028] Figure 3 This is a schematic diagram of the DDS message verification process received by the DDS subscriber in the embodiment of the present application;

[0029] Figure 4 Schematic diagram of EEA topology in the embodiment. DETAILED DESCRIPTION

[0030] In order to enable those skilled in the art to better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this application.

[0031] DDS (Data Distribution Service) is a middleware standard for data publishing and subscription in distributed systems. It provides a data-centric communication mechanism that enables different nodes (such as software components, devices, etc.) to efficiently transmit and share data in a distributed environment. PKI is a system that uses public and private key technologies to ensure information security. It mainly includes digital certificates, certificate authorities (CA), key management, etc. In the DDS data distribution service, the purpose of the PKI security mechanism is to ensure the confidentiality, integrity and authentication of data transmitted between the publisher and the subscriber. However, the PKI security mechanism usually has high requirements for resources in terms of computing resources, storage resources, and communication resources. Therefore, it is necessary to provide a DDS secure communication method that can take into account resource-constrained devices. Example

[0032] This embodiment provides a DDS secure communication method, such as Figure 1 As shown, including:

[0033] Step S1: The DDS entity loads the local configuration file, determines the QoS state and security parameters corresponding to the pre-selected security domain according to the configuration file, and creates the pre-selected security domain corresponding to the local end according to the QoS state and security parameters; the DDS entity includes the DDS publisher and the DDS subscriber; the pre-selected security domains of the DDS publisher and the DDS subscriber both include the zero security domain;

[0034] Step S2: The DDS publisher and the DDS subscriber send notification messages to each other to establish a communication connection; if the DDS publisher or the DDS subscriber determines that the security domain to which the terminal currently belongs is the zero security domain, the notification message includes the current QoS state and the globally unique identifier corresponding to the security domain to which the terminal currently belongs;

[0035] Step S3: If the DDS publisher or subscriber determines that the security domain to which the other party currently belongs is the null security domain according to the current QoS status of the other party, the null security domain session key of the local end is generated using a preset secret key derivation algorithm according to the security parameters corresponding to the local null security domain and the global unique identifier of the other party;

[0036] Step S4: The DDS publisher and the DDS subscriber communicate securely with each other based on the zero security domain session key of each end.

[0037] In the embodiment, the notification message may adopt the RTPS (Real Time Publish Subscribe) protocol. The RTPS protocol is a protocol for real-time communication, which defines a data transmission mechanism for implementing real-time data transmission of a publish-subscribe model in a DDS system.

[0038] In an embodiment, the QoS state and security parameters corresponding to the pre-selected security domain may be set in the configuration file, which is equivalent to pre-setting the attributes of the pre-selected security domain, and these attributes are the basis for creating the corresponding pre-selected security domain.

[0039] In order to distinguish different pre-selected security domains, some structures can be defined to save and operate the QoS state and security parameters of each security domain. The QoS state corresponding to the possible security domain options can be listed in the form of labels or enumeration types. For example, when setting the QoS state, if the QoS state is lightweight security QoS (corresponding to zero security domain), it is set to 0. If there are other QoS states (such as PKI QoS state, corresponding to one security domain), the QoS state is set to other values. Optionally, each QoS state can have a simple description to explain its applicable scenarios and characteristics.

[0040] For the zero security domain, the corresponding security parameter can be the key identifier of the root key; the DDS publisher and the DDS subscriber generate the zero security domain session key of the local end using the preset key derivation algorithm based on the security parameters corresponding to the zero security domain of the local end and the globally unique identifier of the other end.

[0041] When DDS entities (publishers and subscribers) load the configuration file, they create corresponding preselected security domains based on these QoS states and security parameters in the file. This process ensures that each DDS entity can communicate in an environment that meets security and quality of service requirements. For example, if the QoS state of a certain preselected security domain in the configuration file is set to high reliability and low latency, along with corresponding security encryption parameters, after creating this preselected security domain, the DDS entity will handle event notifications within this security domain according to these requirements, such as using a more reliable network protocol and encryption method to send and receive messages.

[0042] In an embodiment, the security parameters corresponding to the zero security domain of the DDS subscriber and publisher can be the same key identifier, which is used to point to a common root key resource. The DDS subscriber and publisher find the root key using the common key identifier, and then generate the same zero security domain session key using a preset key derivation algorithm.

[0043] In an embodiment, step S4 includes: The DDS publisher encrypts the plaintext data using a preselected encryption algorithm based on the zero security domain session key of its own end to obtain encrypted data, generates a message authentication code corresponding to the plaintext data based on the zero security domain session key of its own end, generates a DDS encrypted message according to the encrypted data and the message authentication code, and sends the DDS encrypted message to the DDS subscriber.

[0044] The DDS subscriber decrypts the encrypted data in the DDS encrypted message based on the zero security domain session key of its own end to obtain the plaintext data, generates a message authentication code corresponding to the plaintext data based on the zero security domain session key of its own end, and performs a legality check according to the message authentication code.

[0045] Specifically, the legality check process according to the message authentication code may include: The DDS subscriber compares whether the message authentication code generated by its own end is the same as the message authentication code of the peer end. If they are the same, the plaintext data is sent for service processing; otherwise, the publisher announcement message is discarded.

[0046] In some other embodiments, in some complex security architectures or dynamic security configuration scenarios, there may also be a situation where the security parameters (key identifiers) corresponding to the zero security domain of the subscriber and publisher are different. For example, the subscriber and publisher may be assigned different key identifiers according to their own locations, permissions, or other factors, and these identifiers finally point to the same root key after a series of conversion or mapping operations.

[0047] In the embodiment, the root key can be stored in the software and can also be offloaded to the hardware security module (HSM) for secure storage. After the hardware is offloaded, the encryption and decryption performance is greatly improved while ensuring security. The hardware security module (HSM) has an anti-tampering design that can prevent physical attacks and illegal access. The storage resource requirement is only a symmetric key (which can be offloaded to hardware), and the computing resources also only require a symmetric algorithm (which can be offloaded to hardware), which meets the needs of MCU deployment of DDS Security.

[0048] In some embodiments, the pre-selected security domain also includes a security domain, and the security parameters corresponding to the security domain include a digital certificate, a private key and an authority file of a PKI security mechanism; the DDS secure communication method also includes: if the DDS publisher or the DDS subscriber determines that the security domain to which the local end currently belongs is a security domain, then the notification message includes the current QoS status corresponding to the security domain to which the local end currently belongs, the digital certificate, the private key and the authority file of the PKI security mechanism; if the DDS publisher or the DDS subscriber determines that the security domain to which the other end currently belongs is a security domain based on the current QoS status of the other end, then the DDS publisher or the DDS subscriber performs access permission control and identity authentication with the other end based on the digital certificate, the private key and the authority file of the PKI security mechanism, and determines the session key of the security domain of the local end; the DDS publisher and the DDS subscriber respectively communicate securely with the other end based on the session key of the security domain of each end.

[0049] In the embodiment, a PKI security mechanism is implemented by setting a security domain, so that the system can flexibly adapt to scenarios with different security requirements. For some applications with extremely high security requirements, the high-intensity identity authentication and encryption functions provided by the PKI security mechanism can meet the needs. For scenarios with relatively low security requirements, other security methods such as zero security domain can be used. By including the digital certificate of the PKI security mechanism in the notification message, the publisher and subscriber can use the public key infrastructure for strict identity authentication.

[0050] The digital certificate and private key of the PKI security mechanism are used to determine the session key of the security domain, which increases the security of the key. Through a complex key negotiation process, such as the use of a certificate-based key exchange protocol, the session key is more difficult to be stolen or tampered with during the exchange and generation process.

[0051] When the system needs to be expanded and new publishers or subscribers are added, the digital certificates and authority files of the PKI security mechanism can be easily configured and managed.

[0052] In a specific embodiment, the DDS secure communication method provided by the present application is used to implement DDS secure communication, and the process steps of secure communication between the DDS publisher and the DDS subscriber are as follows: Figure 1 Combination Figure 2As shown, it includes: during the initialization phase, the DDS publisher and the DDS subscriber read the configuration files of each end respectively, determine the QoS parameters according to the configuration files, including the QoS state and security parameters; and create the local pre-selected security domain of the local end according to the QoS parameters.

[0053] As an example, if the QoS state includes public key infrastructure quality of service (PKI QoS), a security domain is created and information such as user certificates / authority files is filled into the DDS discovery notification message. If the QoS state includes lightweight quality of service (lightweight security QoS), a zero security domain is created and the key identifier (KeyID) is read.

[0054] The DDS publisher and the DDS subscriber send discovery notification messages to each other.

[0055] The DDS publisher and DDS subscriber receive the discovery notification message sent by the other party, obtain the QoS status corresponding to the current domain of the other party, and determine whether the other party is a zero security domain or a one security domain. If it is determined that the current domain of the other party is a one security domain, the PKI identity card authentication and the one security domain session key exchange are completed. If the current domain of the other party is a zero security domain, the zero security domain session key of this end is generated based on the security parameters corresponding to the zero security domain of this end and the globally unique identifier (guid) of the DDS entity of the other end through the preset root key derivation algorithm.

[0056] The DDS publisher encrypts the ciphertext data according to the one-security domain session key exchange or the zero-security domain session key exchange, generates a message authentication code corresponding to the plaintext data, generates a DDS encrypted message, and sends the DDS encrypted message to the DDS subscriber;

[0057] The DDS subscriber receives the DDS encrypted message sent by the other end, decrypts the encrypted data in the DDS encrypted message based on the local zero security domain session key to obtain the plain text data, generates a message authentication code corresponding to the plain text data based on the local zero security domain session key, and performs a legitimacy check based on the message authentication code; or performs access permission control and identity authentication and one security domain session key exchange with the other end based on the digital certificate, private key and authority file of the PKI security mechanism; and performs message authentication on the received DDS encrypted message.

[0058] The message receiver receives the DDS encrypted message verification process as follows Figure 3 As shown, including:

[0059] First, determine the QoS status of the local end of the message. If it is a security domain (Security mechanism of the PKI system):

[0060] 1. Decrypt the DDS encrypted data into plain text data using the local security domain session key;

[0061] 2. Generate a local message authentication code based on the plaintext data;

[0062] 3. Compare the received message authentication code with the local message authentication code to see if they are consistent; if they are consistent, the message is sent to the service for processing; otherwise, the message is discarded;

[0063] If it is a zero security domain (corresponding to a lightweight Security mechanism):

[0064] 1. Send the security parameters (KeyID) corresponding to the local zero security domain, the received DDS encrypted data and the message authentication code to the security module for legitimacy verification.

[0065] 2. If the verification result message is legal, the message is sent to the service for processing; otherwise, the message is discarded.

[0066] In some embodiments, the DDS publisher and / or the DDS subscriber may be provided on a microcontroller. In other embodiments, the DDS publisher and / or the DDS subscriber may be provided on a SoC (System-on-Chip); or one of the DDS publisher and the DDS subscriber may be provided on an MCU and the other on a SoC.

[0067] like Figure 4 As shown, a simplified EEA (Enterprise Ethernet Alliance) topology including MCU and SoC is used as an example, where the zero security domain is a lightweight DDS security domain and the one security domain is a security domain based on the PKI system. The pre-selected security domain of the SoC may include the zero security domain and the one security domain. The pre-selected security domain of the MCU may only include the zero security domain.

[0068] The DDS secure communication method provided in this application can be implemented in the form of a plug-in, and the user can flexibly configure whether to use the lightweight DDS security mechanism according to the scenario.

[0069] Through the pre-planned communication matrix, the lightweight DDS security mechanism can be deployed simultaneously with the PKI-based DDS security mechanism. The pre-planned communication matrix is ​​a communication relationship table that is predetermined during the communication system design phase. It specifies the communication links between different communication entities (such as devices, nodes, or users).

[0070] The above is a detailed introduction to a DDS secure communication method provided by the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the concept of the present application and should not be understood as limiting the scope of protection of the present application.

Claims

1. A DDS secure communication method, characterized in that: include: The DDS entity loads a local configuration file, determines the QoS state and security parameters corresponding to the pre-selected security domain according to the configuration file, and creates the pre-selected security domain corresponding to the local end according to the QoS state and the security parameters; The DDS entity includes a DDS publisher and a DDS subscriber; The pre-selected security domains of the DDS publisher and the DDS subscriber both include a zero security domain; The DDS publisher and the DDS subscriber send notification messages to each other to establish a communication connection; If the DDS publisher or the DDS subscriber determines that the security domain to which the terminal currently belongs is the zero security domain, the notification message includes the current QoS state and the globally unique identifier corresponding to the security domain to which the terminal currently belongs; If the DDS publisher or the DDS subscriber determines that the security domain to which the other party currently belongs is the zero security domain according to the current QoS state of the other party, the zero security domain session key of the local end is generated by using a preset key derivation algorithm according to the security parameters corresponding to the zero security domain of the local end and the globally unique identifier of the other party; The DDS publisher and the DDS subscriber respectively communicate securely with the other end based on the zero security domain session key of each end; The security parameter corresponding to the zero security domain is the key identifier of the root key; The zero-security domain session key of the local end is generated using a preset key derivation algorithm according to the security parameters corresponding to the zero-security domain of the local end and the globally unique identifier of the remote end, including: The root key is determined according to the key identifier, and the zero security domain session key of the current end is generated by using a preset key derivation algorithm according to the root key and the global unique identifier of the opposite end.

2. The DDS secure communication method according to claim 1, characterized in that: The security parameters corresponding to the null security domain of the DDS publisher are the same as the security parameters corresponding to the null security domain of the DDS subscriber.

3. The DDS secure communication method according to claim 1, characterized in that: The method further includes: presetting the root key and securely storing the root key.

4. The DDS secure communication method according to claim 1, characterized in that: The DDS publishing end or the DDS subscribing end respectively communicates securely with the other end based on the zero security domain session key of each end, including: The DDS publisher encrypts the plaintext data using a preselected encryption algorithm based on the zero-safe domain session key of the local end to obtain encrypted data, generates a message authentication code corresponding to the plaintext data based on the zero-safe domain session key of the local end, generates a DDS encrypted message according to the encrypted data and the message authentication code, and sends the DDS encrypted message to the DDS subscriber; The DDS subscriber decrypts the encrypted data in the DDS encrypted message based on the zero security domain session key of the local end to obtain the plaintext data, generates a message authentication code corresponding to the plaintext data based on the zero security domain session key of the local end, and performs a legitimacy check based on the message authentication code.

5. The DDS secure communication method according to claim 1, characterized in that: The pre-selected security domain also includes a security domain, and the security parameters corresponding to the security domain include a digital certificate, a private key and an authority file of a PKI security mechanism; The method further includes: if the DDS publisher or the DDS subscriber determines that the security domain to which the terminal currently belongs is the first security domain, the notification message includes the current QoS state corresponding to the security domain to which the terminal currently belongs, the digital certificate, private key and authority file of the PKI security mechanism; If the DDS publisher or the DDS subscriber determines that the security domain to which the other party currently belongs is the first security domain according to the current QoS status of the other party, the DDS publisher or the DDS subscriber performs access control and identity authentication and exchanges the first security domain session key with the other party according to the digital certificate, private key and authority file of the PKI security mechanism; The DDS publishing end and the DDS subscribing end respectively communicate securely with the other end based on the security domain session key of each end.

6. The DDS secure communication method according to claim 1, characterized in that: The DDS publishing end and / or the DDS subscriber end may be arranged in a microcontroller.

Images