WO2021103431A1 - Method for realizing dds domain participant security authentication - Google Patents

Abstract

The present invention provides a method for realizing DDS domain participant security authentication. The present invention comprises: designing an authentication file assembly which is deployed on each DDS node, and configuring an IP, a port number, an SFTP user name and a password of an authentication file microservice on each DDS node; after the DDS node is powered on, synchronizing latest encryption and decryption certificate file information from the authentication file microservice at regular time; and moreover, supporting directly copying the corresponding encryption and decryption certificate file to the local. By means of the authentication file microservice, the management of encryption and decryption certificates is standardized in a unified manner, and the maintenance difficulty and costs of the encryption and decryption certificates are reduced. A leaked secret key file is only required to be deleted in the authentication file microservice, and each DDS node may automatically delete the leaked secret key file during synchronization. For the situation of secret key leakage, the present invention provides an authentication data rule. Even if a secret key is leaked, if an authentication rule of the data is unknown, the security authentication cannot be passed, and addition into the domain of the current DDS is not allowed.

Description

A Method for Realizing DDS Domain Participant Security Authentication Technical field

The invention belongs to the field of distributed communication technology, and in particular relates to a method for realizing DDS domain participant safety authentication.

Background technique

With the development of informatization, it is necessary to face the ever-changing massive data information, and real-time, efficient, and high-speed data interaction is of vital importance. Therefore, it is urgent to establish information transmission middleware with strong real-time, high reliability and good security, improve system interconnection capabilities, meet various information exchange and sharing needs in the system, and solve data sharing and integration problems between application software. solved problem.

The data distribution service DDS (Data Distribution Service) is a distributed real-time communication middleware standard formulated by the object management organization. The publish-subscribe mode it supports provides flexible decoupling capabilities for applications, and it has a wealth of QoS (Quality of Service, Service quality), DDS can well meet the functional and performance requirements of the Internet of Things system. At present, DDS has been widely used in a variety of industrial IoT fields, including energy, medical, robotics, etc.

DDS specifications include domain participants, publishers, subscribers, data types, data writers, data readers, topics, built-in topics, and QoS. In the specific product implementation, DDS is above the operating system and below the user application, which can well shield the details of the underlying system and bus heterogeneity, and provide a unified API interface for application data, as shown in Figure 1. .

As DDS is used more and more, it is widely used in various wireless smart devices. While making full use of the function of DDS to automatically join the domain, it also brings about security issues. How to confirm that the node joining the current domain is legal has become a problem that needs to be solved at present. At present, it is proposed that the domain participants joined by each node have passed the certification of the third-party certification service center. This method has a fatal problem, there is a risk of single point of failure, and violates the dynamic concept of DDS; and it is proposed to adopt X-based .509 and other authentication methods, domain participants communicate and authenticate by negotiating dynamic secret keys. In actual business scenarios, DDS communicates through multicast (the UDP protocol used at the bottom of the multicast) to discover Domain participants, and this X.509-based authentication method generally requires the use of the TCP protocol and communication between two points; a new link needs to be established for the communication of authentication messages, and there is now a DDS automatic discovery mechanism There is no way to directly implement this method, and there is no way to implement intercommunication between different vendors. In view of the current status quo, it is urgent to provide a new method that is simple and can support the DDS products of different manufacturers to mutually realize the security authentication of domain participants under the existing DDS standard protocol conditions.

Summary of the invention

Purpose of the invention: The technical problem to be solved by the present invention is to provide a method for realizing DDS (Dat a Distribution Service, data distribution service) domain participant security authentication in view of the deficiencies of the prior art, including the following steps:

Step 1. All powered-on DDS nodes will automatically read the current system configuration, and according to the system configuration item information, automatically apply to the certificate file microservice to synchronize the current latest certificate file to the specified directory of the current DDS node;

Step 2. The DDS node newly added to the domain will determine whether the domain participant security authentication is required according to the system configuration of the current node. If necessary, select the current encrypted file, use the selected encrypted file to encrypt the authentication data, and then execute Step 3; if not needed, go directly to step 4;

Step 3. For the newly added DDS node of the domain, fill in the name of the encryption certificate in the 0-31 digits of the UserDataQosPolicy (User Data Entity Policy) parameter of the DomainParticipantQoS (Domain Participant Quality of Service) in the DDS protocol specification, 32-36 Fill in the length of the encrypted data in bits; fill in the encrypted data after 37;

Step 4. The DDS node that newly joins the domain sends an SPDP message;

Step 5: The DDS node that has joined the domain receives the SPDP message of the newly joined DDS node. It will determine whether domain participant security authentication is required according to the current system configuration. If necessary, it will parse the UserDataQosPolicy parameter content of DomainParticipantQoS and base it on The 0-31 bit information in the UserDataQosPolicy parameter obtains the local corresponding decrypted file, and obtains the information after 37 bits according to the length of the encrypted data from 32-36 to obtain the information after 37 bits, and then performs step 6; if not needed, receive the new addition After the SPDP message of the DDS node of the domain, directly add the DDS node of the newly joined domain to the local domain participant list, and send a confirmation message to the newly joined DDS node, and then perform step 7;

Step 6. Confirm the legality of the decrypted data in step 5. If it is legal and valid, the authentication is passed, the DDS node of the newly added domain is added to the local domain participant list, and the newly added domain DDS The node sends a confirmation message; otherwise, the authentication fails, and the SPDP message is directly ignored;

Step 7. The domain participant authentication process ends and continues to monitor DDS messages.

In step 1, the system configuration includes the following configuration items:

DDS_ENDPOINT_AUTH_SWITCH: When the value is true, it means that the node needs to be encrypted and decrypted, and when the value is false, it means that the node does not need to be encrypted or decrypted;

DDS_CERTIFICATE_PATH: the path of the encryption and decryption certificate of this node;

DDS_CERTIFICATE_SERVER_ADD: IP address and port of the certificate service center;

DDS_CERTIFICATE_SERVER_USER: User name and password of the certificate service center.

In step 1, the specified directory is obtained through the configuration item DDS_CERTIFICATE_PATH.

In step 1, if you apply to the certificate file microservice to synchronize the current latest certificate file to the specified directory of the current DDS node, the synchronization fails, then directly copy the latest certificate file to the specified directory of the current DDS node.

In step 2, if the configuration item DDS_ENDPOINT_AUTH_SWITCH is true in the system configuration of the current node, it is determined that the domain participant security authentication is required, select the current encrypted file, use the selected encrypted file to encrypt the authentication data, and then go to step 3. ; Otherwise, it is determined that the security authentication of the domain participant is not required, and proceed directly to step 4.

In step 3, the parameters of DomainParticipantQoS mainly include UserDataQosPolicy (user entity data policy) and EntityFactoryQosPolicy (entity factory policy):

In step 5, if the configuration item DDS_ENDPOINT_AUTH_SWITCH is true in the current system configuration, it is determined that the domain participant security authentication is required, otherwise it is determined that it is not required.

The present invention has the following beneficial effects:

(1) The security authentication of domain participants between different DDS products can be realized.

(2) Support both symmetric encryption and decryption and asymmetric encryption and decryption.

(2) It is proposed to improve the reliability of authentication through double authentication of authentication data encryption and data authentication rules.

(4) It is proposed that through the authentication file microservice, the unified management of all encryption and decryption certificates can be realized, which reduces the difficulty and cost of maintaining encryption and decryption certificates.

(5) Supporting SPDP multicast and unicast at the same time, domain participant discovery security authentication.

Description of the drawings

In the following, the present invention will be further described in detail with reference to the accompanying drawings and specific embodiments, and the above-mentioned and/or other advantages of the present invention will become clearer.

Figure 1 is a diagram of the DDS architecture.

Figure 2 is a diagram of the naming specification of encryption and decryption certificates.

Figure 3 is a schematic diagram of the overall message of the domain participants.

Figure 4 is a flowchart of a newly joined domain participant.

Figure 5 is a schematic diagram of authentication data rules.

Figure 6 is a diagram of the composition of the domain participant authentication message.

Figure 7 is a flowchart of authentication for newly joined domain participants.

Detailed ways

Discovery among DDS participants is realized through Simple Participant Discovery Protocol (SPDP). The RTPS protocol (Real-time Publish-Subscribe Wire Protocol) stipulates two methods for SPDP messages: multicast and unicast; in actual application scenarios, most SPDP messages are sent through multicast. The method can realize the automatic discovery of DDS, and each node can automatically join or exit the domain without any configuration or human intervention. The default value of the multicast IP is 239.255.0.1; the port is PB+DG*domainId (PB is 7400, DG is 250, and domainId is the domain ID value). Of course, in some business scenarios, it is necessary to use unicast to realize the process of domain participant discovery, that is, static discovery.

In the DDS standard protocol, all DDS nodes joining the current domain are required to actively send domain participant messages, and each domain participant has the domain participant quality of service DomainParticipantQoS QoS; the standard protocol stipulates that the QoS contains UserDataQosPolicy (user data entity Policy) and EntityFactoryQosPolicy (Entity Factory Policy); that is, the DomainParticipantQoS of all DDS products should contain these two parameter information. Of course, each DDS product can add its own defined parameter information on this basis; in the present invention, for Compatible with different existing DDS products, the present invention does not adopt the newly added QoS parameter mode, but directly reuses the existing UserDataQosPolicy parameters of DomainParticipantQoS.

In order to implement the present invention, two system configurations are added to this solution, one of which is whether the domain participation security authentication operation is currently required, that is, encryption and decryption operations; the other is the path where the current DDS node stores the encryption and decryption certificates; There are four configuration items in the invention, and the specific configuration item information is shown in Table 1. The present invention also stipulates the naming rules of encryption and decryption certificates. The naming length of the encryption and decryption certificates is 32 bytes in total. Among them, the first 0-1 is to distinguish whether the current certificate is encrypted or decrypted; the second 2-4 are to identify the product type, and the first Bits 5-9 are reserved fields, and bits 10-26 are the time when the file is generated (year, month, day, hour, minute, second, millisecond); 27-29 are reserved fields, and 30-31 are random numbers; see Figure 2 for details. The first 2 bytes are used to identify the current certificate type. The current encryption methods are mainly symmetric encryption and asymmetric encryption. The file names of symmetric encryption and decryption are the same; asymmetric encryption and decryption are distinguished by public and private keys; see Table 2 for details . At present, the symmetric encryption algorithm of the present invention adopts MD5, and the asymmetric encryption algorithm adopts RSA; however, the present invention does not limit specific encryption algorithms, and does not perceive specific algorithms.

Table 1

Configuration item	Example	Description
DDS_ENDPOINT_AUTH_SWITCH	true/false	Does this node need to encrypt and decrypt
DDS_CERTIFICATE_PATH	/dds/certificate/	Encryption and decryption certificate path of this node
DDS_CERTIFICATE_SERVER_ADD	192.168.1.1:22	IP address and port of the certificate service center
DDS_CERTIFICATE_SERVER_USER	dds_radar:dds	Certificate Service Center username and password

Table 2

Certificate type field value	Description
00	Symmetric encryption
01	Asymmetric encryption (public key)
10	Asymmetric encryption (private key)

At the same time, in order to better maintain and update encrypted and decrypted files, the present invention proposes to maintain a certification file microservice, which stores the current encryption and decryption files of the entire company, and specifically stores them according to product categories; externally provides SFTP (Secret) File Transfer Protocol (secure file transfer protocol) message interface; according to different products, different user names are provided. In the present invention, the authentication file component is designed and implemented, which is deployed on each DDS node, and each DDS node is configured with the IP, port number, SFTP user name and password of the authentication file microservice; see Table 1 for specific parameters. After the DDS node is powered on, it will synchronize the latest encryption and decryption certificate file information from the authentication file microservice at regular intervals (the current synchronization interval is 2 hours); at the same time, it also supports the direct copy of the corresponding encryption and decryption certificate files to the local. Through the authentication file microservice, the management of encryption and decryption certificates is unified and standardized, and the maintenance difficulty and cost of the encryption and decryption certificates are reduced. For the leaked secret key files, only need to be deleted in the authentication file microservice, and each DDS node will automatically be synchronized during synchronization. Delete the leaked secret key file.

In addition, in view of the leakage of the secret key, the present invention considers corresponding countermeasures and proposes an authentication data rule. Even if the secret key is leaked, if it does not know the authentication rules of the data, it still cannot pass the security authentication and cannot join the current DDS. Domain.

The implementation method of the present invention for realizing the security authentication of DDS domain participants; combined with Figure 3, it mainly includes the following steps:

Step 1. All powered-on DDS nodes will automatically read the current system configuration. See Table 1 for the specific configuration. According to the system configuration item information, automatically apply to the certificate file microservice to synchronize the current latest certificate file to the specified directory of the current DDS node. For the specific directory, see the DDS_CERTIFICATE_PATH configuration item in Table 1.

Step 2. The DDS node newly added to the domain judges whether the domain participant security authentication is required according to the system configuration of the current node. If necessary, select the current encrypted file according to the corresponding algorithm (the present invention does not specifically specify the specific algorithm for selecting the encrypted file At present, the present invention adopts random selection, and the specific selection algorithm can be determined according to the needs of specific business scenarios). Use the selected encrypted file to encrypt the authentication data, the application itself does not need to perceive the current encrypted file, encryption method and other information.

Step 3. For the newly added DDS node of the domain, fill in the name of the selected encryption certificate in the UserDataQosPolicy parameter of DomainParticipantQoS in bits 0-31, and fill in the encrypted data length information in the 32-36 bits; fill in the encrypted data after 37; then send the SPDP message. The parameter information of DomainParticipantQoS is as follows:

Step 4. The DDS node that has joined the domain receives the SPDP message of the newly joined DDS node. It will determine whether the domain participant security authentication is required according to the current system configuration. If necessary, it will parse the UserDataQosPolicy parameter content of DomainParticipantQoS, and according to The 0-31 bit information in the UserDataQosPolicy parameter obtains the local corresponding decrypted file, and obtains the information after 37 bits according to the length of the encrypted data obtained by 32-36, and then decrypts it.

Step 5: Confirm the legality of the decrypted data. If it is legal and valid, the authentication is passed, and the DDS node of the newly joined domain is added to the local domain participant list; and a confirmation is sent to the newly joined DDS node Message; if authentication fails, ignore the message and go to step 7.

Step 6. If the current DDS node that has joined the domain does not need to perform domain participant security authentication, after receiving the SPDP message of the newly joined DDS node, directly add the newly joined DDS node of the domain to the local domain participant list. And send a confirmation message to the DDS node newly joining the domain.

Step 7. The domain participant authentication process ends and continues to monitor DDS messages.

Example

In view of the various deficiencies of the existing DDS domain participant security authentication schemes, the present invention makes full use of the UserDataQosPolicy parameter of DDS (Data Distribution Service) DomainParticipantQoS, and designs a universal domain that can be compatible with different DDS products. In addition, a data authentication rule is proposed, which can guarantee the validity and reliability of the security authentication to the greatest extent in the case of the leakage of the secret key.

Step 1. All powered-on DDS nodes will automatically read the current system configuration. See Table 1 for the specific configuration. According to the system configuration item information, automatically apply to the certificate file microservice to synchronize the current latest certificate file to the specified directory of the current DDS node. For the specific directory, see the DDS_CERTIFICATE_PATH configuration item in Table 1.

Step 2. If the synchronization of the latest certificate file fails in step 1, you can directly copy the latest certificate file to the specified directory of the current DDS node.

Step 3, as shown in Figure 4, a new DDS node trying to join the current domain will read the current system configuration item: DDS_ENDPOINT_AUTH_SWITCH. If the configuration item is true, proceed to the next step; otherwise, proceed to step 7.

Step 4. Randomly fetch an encrypted file from the directory configured by DDS_CERTIFICATE_PATH. (The present invention does not specifically specify the specific algorithm for selecting encrypted files, and the specific selection algorithm can be determined according to the needs of specific business scenarios).

Step 5. Use the selected encrypted file to encrypt the authentication data. This example uses a simple encryption rule. The specific rule is shown in Figure 5. A total of 48 bytes. The 0-13 bytes are the current system time, accurate to the second. ; The 14th-15th byte is to fill in the current domain ID, the 16th-31th byte is to fill in the IP address of this node in DDS communication (compatible with IPV6), the 32-35th byte is to fill in the SPDP (multicast/unicast) message The 36-41 bytes fill in the MAC address corresponding to the IP address of the node participating in DDS communication, the 42-44 bytes fill in the current product type, and the 45-47 bytes fill in the checksum. The specific encryption rules can be negotiated according to the requirements of each product. Encrypt 48 bytes of data information through the encrypted file in step 4.

Step 6. Write the data into the UserDataQosPolicy parameter. The 0-31 bytes of the UserDataQosPolicy parameter fill in the name of the encrypted file of this node, which is the information obtained in step 4; the 32-35 bytes fill in the length of the encrypted data in step 5 ; Fill in the encrypted data content in step 5 after the 36th byte (including the 36th byte). See Figure 6 for details.

Step 7. Send the SPDP message.

Step 8. The participant who has joined the domain receives the SPDP message sent by the participant who joins the domain. The main process is shown in Figure 7.

Step 9. The joined domain participant node reads the configuration item information of whether the current system performs domain participant authentication, the configuration item: DDS_ENDPOINT_AUTH_SWITCH.

Step 10. If the configuration item read in step 9 is true, execute the next step; otherwise, execute step 15.

Step 11: parse the UserDataQosPolicy parameter information of DomainParticipantQoS in the received SPDP message; parse out the encrypted certificate name, encrypted data length, and encrypted authentication data information.

Step 12: According to the name of the encryption certificate parsed in Step 11, the corresponding decrypted file is obtained locally; and the authentication data is encrypted for decryption.

In step 13, it is judged whether the decrypted data in step 12 meets the authentication data rule in FIG. 5, if it meets, the next step is executed, otherwise, step 17 is executed.

Step 14. Check the legality and validity of the decrypted authentication data, such as whether the IP address and MAC match, whether they are correct, whether the time information is valid, whether the product types are consistent, whether the checksum is correct, and so on. If the authentication data is legal and valid, go to the next step, otherwise go to step 17.

Step 15. Add the newly joined domain participant to the local domain participant list.

Step 16. Send a confirmation message to the newly joined domain participant.

Step 17, the domain participant authentication process ends and continues to monitor DDS messages.

The present invention provides a method for realizing the security authentication of DDS domain participants. There are many specific methods and ways to realize this technical solution. The above are only the preferred embodiments of the present invention. It should be pointed out that for those of ordinary skill in the art In other words, without departing from the principle of the present invention, several improvements and modifications can be made, and these improvements and modifications should also be regarded as the protection scope of the present invention. All the components that are not clear in this embodiment can be implemented with the existing technology.

Claims (7)

1. A method for realizing security authentication of DDS domain participants, which is characterized in that it comprises the following steps:

   Step 1. All powered-on DDS nodes will automatically read the current system configuration, and according to the system configuration item information, automatically apply to the certificate file microservice to synchronize the current latest certificate file to the specified directory of the current DDS node;

   Step 2. The DDS node newly added to the domain will determine whether the domain participant security authentication is required according to the system configuration of the current node. If necessary, select the current encrypted file, use the selected encrypted file to encrypt the authentication data, and then execute Step 3; if not needed, go directly to step 4;

   Step 3. For the newly added DDS node of the domain, fill in the name of the selected encryption certificate in the 0-31 bits of the UserDataQosPolicy user data entity policy parameter of the DomainParticipantQoS domain participant service quality in the DDS protocol specification, and fill in the encrypted data in the 32-36 bits Length information; fill in the encrypted data after 37;

   Step 4. The DDS node that newly joins the domain sends an SPDP message;

   Step 5: The DDS node that has joined the domain receives the SPDP message of the newly joined DDS node. It will determine whether domain participant security authentication is required according to the current system configuration. If necessary, it will parse the UserDataQosPolicy parameter content of DomainParticipantQoS and base it on The 0-31 bit information in the UserDataQosPolicy parameter obtains the local corresponding decrypted file, and obtains the information after 37 bits according to the length of the encrypted data from 32-36 to obtain the information after 37 bits, and then performs step 6; if not needed, receive the new addition After the SPDP message of the DDS node of the domain, directly add the DDS node of the newly joined domain to the local domain participant list, and send a confirmation message to the newly joined DDS node, and then perform step 7;

   Step 6. Confirm the legality of the decrypted data in step 5. If it is legal and valid, the authentication is passed, the DDS node of the newly added domain is added to the local domain participant list, and the newly added domain DDS The node sends a confirmation message; otherwise, the authentication fails, and the SPDP message is directly ignored;

   Step 7. The domain participant authentication process ends and continues to monitor DDS messages.
2. The method according to claim 1, wherein in step 1, the system configuration includes the following configuration items:

   DDS_ENDPOINT_AUTH_SWITCH: When the value is true, it means that the node needs to be encrypted and decrypted, and when the value is false, it means that the node does not need to be encrypted or decrypted;

   DDS_CERTIFICATE_PATH: the path of the encryption and decryption certificate of this node;

   DDS_CERTIFICATE_SERVER_ADD: IP address and port of the certificate service center;

   DDS_CERTIFICATE_SERVER_USER: User name and password of the certificate service center.
3. The method according to claim 2, wherein in step 1, the designated directory is obtained through a configuration item DDS_CERTIFICATE_PATH.
4. The method according to claim 3, wherein, in step 1, if an application is made to the certificate file microservice to synchronize the current latest certificate file to the specified directory of the current DDS node, the synchronization fails, then the latest certificate file is directly transferred Copy to the specified directory of the current DDS node.
5. The method according to claim 4, wherein in step 2, if the configuration item DDS_ENDPOINT_AUTH_SWITCH is true in the system configuration of the current node, it is determined that the domain participant security authentication is required, the current encrypted file is selected, and the selected The encrypted file encrypts the authentication data, and then performs step 3; otherwise, it is determined that the domain participant security authentication is not required, and step 4 is directly performed.
6. The method according to claim 5, wherein in step 3, the parameter information of DomainParticipantQos includes UserDataQosPolicy user entity data policy and EntityFactoryQosPolicy entity factory policy.
7. The method according to claim 6, characterized in that, in step 5, if the configuration item DDS_ENDPOINT_AUTH_SWITCH is true in the current system configuration, it is determined that the domain participant security authentication is required, otherwise it is determined that it is not required.

Images