On August 22nd, 2018, Principal Software Engineer, Adam Mitz, delivered an educational webinar on “Revolutionizing Data Distribution with an Open and Secure DDS.” He discussed:
- DDS and OpenDDS Overview
- Security Use Cases
- Features in the DDS Security Specification
- OpenDDS Security in Action
We received a number of questions during the webinar. Below is a list of those questions along with their corresponding answers.
1) Is DDS Security backwards compatible? If so, how does that work?
Yes, as long as the domain has been configured to allow unauthenticated participants, unsecure DDS participants (or those without valid authentication credentials) will be allowed to match with secure DDS participants and to publish and subscribe to domain topics that don’t require secure discovery or encryption/signing.
2) What happens when two applications have two valid governance documents that differ?
The local participant will always use its own local governance file to dictate domain behavior. In some instances, two different governance files might allow for smooth interoperation (e.g. when two participants with valid identity certs disagree about allowing unauthenticated participants, it won’t matter since they will both authenticate). In other instances, two different governance files might prevent interoperability altogether (e.g. when the governance files disagree about whether discovery is encrypted, the appropriate data exchanges will not take place).
3) When participants match, how does one participant know and/or trust the permissions of the other?
During the authentication handshake, both the identity certificate and permissions document are exchanged. Both are verified according to their appropriate certificate authorities and then the permissions file is checked to make sure it is valid according to the current time and to make sure it matches the identity certificate provided.
4) Can a participant update their permissions after they match?
The permissions are set as a QoS policy for the participant that is not changeable during run-time for the participant. Applications are always allowed to delete an old participant and create a new participant with new permissions, which will then initiate a new authentication handshake and access control checks in order to verify the new permissions.
5) What other domain configuration options are there? Other topic configuration options?
The configuration options for the domain and topics are generally found in the governance file. The domain level options are: allowing unauthenticated participants, enabling domain access controls, and setting protection kinds for discovery, liveliness, and RTPS messages (whole-message level). The per-topic options are: enabling discovery protection, enabling liveliness protection, enabling read / write access controls, and protection kinds for metadata (sub-message level) and data (payload level) messages. Consult the DDS Security specification for more details.
6) What is the discovery overhead from security?
Potential Security-related discovery overhead can come from a few different sources.
- Participant announcements increase in size because they now contain parameters for identity and permissions tokens.
- DDS Security adds additional built-in endpoints and so there is additional traffic for initializing those readers and writers.
- Each pair of participants must authenticate each other using the 3-way Diffie-Hellman handshake. During the handshake, the full x.509 identity certificate (~4Kb in size) for each participant is sent along with the corresponding permissions document (size varies greatly, but generally more than 3k) and various byte sequences required by DDS Security Built-In Authentication.
- Depending on the discovery and liveliness protection kinds, additional cryptographic key material may need to be sent in order to complete initialization of built-in topic endpoints.
7) Is there a hit on CPU resources due to encryption of user data samples?
In short: of course. However, the majority of the cryptographic “heavy lifting” will be performed by the OpenSSL crypto library, which is designed for both security and speed and has many optimizations to take advantage of hardware acceleration. We have plans for extensive characterization of the OpenDDS security performance profile, but as this is considered a beta implementation we don’t have these numbers yet.
Have more questions? Request a consultation.
