Back to Editors' Blog

First Formal DDS Security

by Bryon Moyer

August 11, 2014 at 10:10 AM

As noted in today’s article on some of the characteristics of the DDS data transport standard, it’s missing a rather important component: formalized security. Proprietary schemes have been layered on top of it, but the OMG has a beta standard that they’re now finalizing (a process that could take up to a year).

But that doesn’t stop early adoption. RTI has announced an implementation of the new OMG security standard for DDS – something likely made easier since, by their claim, they contributed much of the content of the standard.

There are a couple of particular challenges with respect to security on DDS. First, due to its decentralized nature, there are no brokers or single-points-of-security (which would be single points of failure). This means that each device or node has to handle its own security.

Second, DDS runs over many different transport protocols, some of which may or may not have their own security. Because of that, you can’t rely on the underlying transport security for protection. This means adding DDS-level security (which may complement security at a lower level).

We usually think of security as protecting the privacy of a message so that only the intended receiver can read it. While this is true, RTI points out that, in many cases, the content isn’t really secret – you just want to be sure that it’s authentic. They use as an example a weather data transmission: you may not care if anyone else sees it, but you want to be sure you’re getting the real thing and not some spoofed message that’s going to send your boats out into the heart of a hurricane. (I hear that competition amongst fishermen is fierce!)

So RTI’s Connext DDS Security includes authentication, access control, encryption (using encryption standards), data tagging (user-defined tags), and logging.


(Click to enlarge)

Image courtesy RTI

If all you’re interested in is authentication, you can improve performance by taking a hash of the message (much faster than encrypting) and then encrypting only the hash (much smaller – hence quicker – than the entire message). Full encryption (needed to obscure the entire payload) can be 100 times slower.

You can also customize your own encryption and authentication code if you wish.

They claim that this is the first “off the shelf” security package; the prior proprietary approaches ended up being written into the applications explicitly. Here it’s provided as a library for inclusion in the overall DDS infrastructure.

You can find more in their announcement.


IoT & MEMS. Embedded.

    submit to reddit  


You must be logged in to leave a reply. Login »

Related Articles

Data-Centric IoT Messaging

A Look at Key DDS Characteristics

by Bryon Moyer

The internet of things (IoT) is all about sensor data and communications. It involves some entity taking the data it receives, making some complex (or...

Lean Green Energy Harvesting Machine

PMICs and Biofuel Micro Trigeneration

by Amelia Dalton

In the venerable words of Kermit the Frog, "It's not that easy being green", but in this week's Fish Fry we're going to show you...

Where is the Value? Where is the ROI?

IoT Business Model Ruminations

by Bryon Moyer

When you think about it, the much-vaunted launch of the Internet of Things (IoT) represents an enormous investment in research, development, and rollout. Much is...

Who Controls the Power?

Open Power Foundation Aims to Make PowerPC More Plentiful

by Jim Turley

Once upon a time, there were many little RISC processors frolicking in the deep green microprocessor forest. There was the jaunty little ARM. The bright...

Login Required

In order to view this resource, you must log in to our site. Please sign in now.

If you don't already have an acount with us, registering is free and quick. Register now.

Sign In    Register