This introduction to DDS security looks at why we need a security standard in the Data Distribution Service (DDS)  and gives an overview of its use.

Introduction to DDS Security

What prompted the need for the DSS Security standard?

Many of Internet of Things systems are being built using DDS. These systems need to secure their data exchange, especially when data is sensitive. However, prior to the DDS Security standard, there was no multi-vendor interoperable mechanism for DDS applications to communicate securely.

Prior to the DDS Security

There are several existing approaches to secure communication between objects within the same network such as Transport Layer Security (TLS)  and Datagram Transport Layer Security (DTLS). These approaches have some limitations for Industrial Internet applications such as :

• They work only with unicast and not with multicast.
• They encrypt all data flowing through the network.
• As mentioned above, they are not interoperable.

DDS Security overcomes these limitations. Most importantly, it is standard and interoperable.

Threats

In order to understand some of the specific threats impacting applications that use DDS and DDS Interoperability Wire Protocol (RTPS), let introduce two imaginary friends, Alice and Bob.  They wish to communicate with each other and with other existing users in the network.

• Alice. An authorized publisher. Allowed to publish topic T
• Bob. An authorized subscriber. Allowed to subscribe to topic T
• Eve. An unauthorized subscriber (eavesdropper). Non-authorized eavesdropper
• Trudy. An unauthorized publisher (intruder).
• Trent. Trusted infrastructure service. However, he is not trusted to see the content of the information.
• Mallory. Malicious insider (an authorized subscriber and unauthorized publisher).

As shown in the following figure, there are several threats that can occur if there is no DDS security.

Unauthorized Subscription

• Eve is connected to the same network infrastructure and is able to observe the network packets.

• In situations where Alice and Bob are communicating over multicast, Eve could simply subscribe to the same multicast address.

Unauthorized Publication

• Trudy is connected to the same network infrastructure and is able to inject network packets with any data contents, headers and destination she wishes (e.g., Bob).

 Tampering and Replay

• Mallory can use the shared secret key to create messages on the network and pretend it came from Alice.
• She has the secret key used to compute the Hash-based Message Authentication Code (HMACs)  so she can also create a valid HMAC for the new message.

Unauthorized Access to Data by Infrastructure Services

•  Infrastructure services are allowed to store and forward the data, but not to read the content of data.

• Trent is an example of such a service, he can see the headers and sample information (writer global unique identifier (GUID), sequence numbers, key hash and such) but not the message contents.

Constraints of the DomainParticipant BuiltinTopicKey_t (GUID)

• In addition to these threats, there is an attack based on GUID. The DomainParticipant GUID is communicated as part of DDS Discovery.
• An attacker with legit Identity can authenticate using the GUID of another Participant.
• An accepted attacker will block legitimate Participant from using its GUID because its GUID would be detected as a duplicate of the already existing one.

Service Plugin Interface (SPI)

Based on the threats described above, the DDS security specification defines five Service Plugin Interfaces (SPIs) that when combined together provide Information Assurance to DDS systems:

• Authentication. Alice checks Bob’s identity.
• Access Control. Alice checks Bob’s permissions.
• Cryptography.  Implements all cryptographic operations including encryption, decryption, hashing, digital signatures, etc.
• Logging. Log all security-relevant events.
• Data Tagging. Add a tag for each data sample.

DDS Security specification models these plugins in the following architecture: