Protecting proprietary data on DDS

2 posts / 0 new
Last post
Offline
Last seen: 4 years 4 months ago
Joined: 07/01/2014
Posts: 9
Protecting proprietary data on DDS

Hello, 

I have an existing RTI DDS implementation and I'm trying to assess how visible our data would be if we open up our DDS bus to another vendor.  I've looked at best practices and I understand that domains isolate data. But I'm not clear on how discovery works (particularly in tools like DDS Monitor) if you simply join multiple vendors' domains. 

If I run DDS Monitor with our software, I see the domain participants and their associated service names, but I don't see any topic names. I am assuming that I have to define an explicit QoS policy for each topic that I want to be visible ?  Is it reasonable to assume that a vendor can only interpret the data for which they have definitions (or maybe QoS policies -- I'm not sure how the definitions are defined and if they actually limit data discovery and visibility)?  

I do see that you distribute the RTI Security Plugins with the download, but I'm trying to understand best practices at the domain partitioning and QoS configuration level for right now. We'll move into more formal security protocol as we progress. 

Thanks, 

Myca

rip
rip's picture
Offline
Last seen: 1 day 9 hours ago
Joined: 04/06/2012
Posts: 324

Types and topics are absolutely visible on the wire, even if you don't supply your IDL to the other vendor -- consider things like the spy, or other monitoring applications.  They have no idea what your types/topics are, and yet as soon as you create your datawriter or datareader, it appears in spy.  That is the nature and power of the discovery protocol, your tools don't need to know what's out there, or what's going to be out there, a tool can simply attach to the bus and start gathering everything it needs to read your mail, including the type description of what the serialized data should be martialed into.

The default DDS specification has zero confidentiality, integrity, authenticity, etc built in to it.  That is what Secure DDS plugins are designed to address.

If you are not using Secure DDS and want to provide your own data assurance, you have to implement it at the application layer, before it hits the middleware.  Even before you start writing code -- ie, at the IDL definition.  

Different ways to do that.  Helps if you build it into the IDL before you start coding.  Bolting it on afterwards isn't really an option without creating more IDL (extending your existing types to provide an opaque byte buffer that is large enough to hold your encrypted/signed data).  But that means having to touch each and every application that uses the original IDL.

But, loop back up to the above -- the tools that make your life easy will pretty much stop working if you start shoving your data into an opaque, encrypted byte buffer. 

If your application is already live, then the Secure DDS plugins will encrypt the data for you, and allow you to identify which tools will be allowed to decrypt the data, without having to change your application itself.  The other vendor's peers won't be part of the same CA, and so won't be able to read your mail.

(also, yes, the specification has ways for your participant to ignore unexpected peers, but that doesn't stop wireshark from harvesting your data.)