Hey, Charlie Miller! Let’s Talk About Securing Autonomous Vehicles Reply


A recent Wired article on Charlie Miller (infamously known for remotely hacking and controlling a Jeep) claims that “open conversation and cooperation among companies” are necessary prerequisites to building secure autonomous vehicles. This seems rather far-fetched when so many companies are racing to dominate the future of the once-nearly-dead-but-newly-revived (remember the Big Three bailouts?) automotive industry. As naive as that part of the article sounds, what really blew my mind was the implication that the answer to re-designing security lies solely within the autonomous-vehicle industry.

IIC_LogoThe concept of security is not isolated to autonomous vehicles so there is no benefit in pretending that’s the case. Every IIoT industry is trying to solve similar problems and are surprisingly open to sharing their findings. I’m not saying that Miller needs to go on a journey of enlightenment through all other industries to create the ideal solution for security. I’m saying this has already been done for us, compliments of the Industrial Internet Consortium (IIC).

The IIC consists of 250+ companies across several industries – including automotive suppliers like Bosch, Denso, and TTTech – with the same fundamental problem of balancing security, safety, performance, and of course costs for their connected systems. If Wired and Miller are looking for an open conversation – it’s happening at the IIC. The IIC published the Industrial Internet Reference Architecture, which is available to everyone for free – as in “free beer,” especially if the car is doing the driving for you! The extensions to this document are the Industrial Internet Connectivity Framework (IICF) and Industrial Internet Security Framework (IISF). These documents provide guidance from a business perspective down to implementation, and the IISF is particularly applicable as it addresses Wired’s brief mentions to securing the connectivity endpoints and the data that passes between them.

Take a ride with me and see how we might modify the connected car’s architecture to protect against potential adversaries. Since we do not have any known malicious attacks on cars, we can start with Miller’s Jeep hack. Thanks to a backdoor “feature” in the Harmon Kardon head unit, Miller was able to execute unprotected remote commands quite easily. Through this initial exploit, he was able to reprogram a chip connected to the CAN Bus. From there, he had nearly full control of the car. You’re thinking, “just remove that unprotected interface,” right?

Miller would not have stopped there, so neither shall we. Assuming we could still find an exploit that granted us access to reprogram the ARM chip, then Wired’s article rightly suggests establishing an authenticated application – perhaps starting with secure boot for the underlying kernel, leverage ARM Trust Zone for the next stage of critical-only software, and implement some sort of authentication for higher level OS and application processes. Your device endpoint might start to look like a trusted application stack (Figure 1 below). I can only guess how much this head unit costs now, but to be fair, these are valid considerations to run a trusted application. The problem now is that we haven’t actually connected to anything, let alone securely. Don’t worry, I won’t leave you by the roadside.

Screen Shot 2017-05-03 at 2.40.51 PM

Figure 1. Trusted Application Stack

Many of these trusted applications connect up directly to the CAN Bus, which arguably expands the attack surface to the vehicle control. The data passed between these applications are not protected from unauthorized data writers and readers. In the case of autonomous taxis, as Wired points out, potential hackers now have physical access to their target, increasing their chance of taking over an application or introducing an imposter. Now the question becomes: can applications trust each other and the data on the CAN bus? How does the instrument cluster trust the external temperature data? Does it really need to? Maybe not and that’s ok. However, I am pretty sure that the vehicle control needs to trust LIDAR, Radar, cameras, and so on. The last thing anyone wants to worry about is a hacker remotely taking the car for a joyride.

We are really talking about data authenticity and access control: two provisions that would have further mitigated risk against Miller’s hack. Securing the legacy applications is a good step, but let’s consider the scenario where an unauthorized producer of data is introduced to the system. This trespasser can inject commands on the CAN Bus – messages that control steering and braking. The CAN Bus does not prevent unauthorized publishers of data nor does it ensure that the data comes from the authenticated producer. I’m not suggesting that replacing the CAN Bus is the way forward – although I’m not opposed to the idea of replacing it with a more data-centric solution. Realistically, with a framework like Data Distribution Services (DDS), we can create a layered architecture as guided by the IISF (Figure 2 below). The CAN Bus and critical drive components are effectively legacy systems for which security risk can be mitigated by creating a DDS databus barrier. New components can then be securely integrated using DDS without further compromising your vehicle control. So what is DDS? And how does it help secure my vehicle? Glad you asked.

Screen Shot 2017-05-03 at 2.41.07 PM

Figure 2. Industrial Internet Security Framework Protecting Legacy Endpoints

Imagine a network of automotive sensors, controllers, and other “participants” that communicate peer-to-peer. Every participant receives only the data it needs from another participant and vice versa. With peer-to-peer, participants in that network can mutually authenticate and if our trusted applications hold up, so does our trusted connectivity. How do we secure those peer-to-peer connections? TLS, right? Possibly, but with the complexity of securing our vehicle we want the flexibility to trade off between performance and security and apply access control mechanisms.

Let’s back up a little and re-visit our conversation about the IICF, which provides guidance on connectivity for industrial control systems. The IICF identifies existing open standards and succinctly attributes them to precise functions of an Industrial IoT system. At its core, an autonomous vehicle, as cool as it sounds, is just an Industrial IoT system in a sleek aerodynamic body with optional leather seats. So what does the IICF suggest for integrating software for an Industrial IoT system, or more specifically, autonomous systems? You guessed it! DDS: an open set of standards designed and documented through open conversations by the Object Management Group (OMG). An ideal automotive solution leveraging DDS allows system applications to publish and subscribe to only messages that they need (see Figure 3 below for our view of an autonomous architecture). With this data-centric approach, we can architecturally break down messages based on criticality for safety or need for data integrity.

Screen Shot 2017-05-03 at 2.41.17 PM

Figure 3. Autonomous Vehicle Data-Centric Architecture

And now that we’ve established a connectivity solution for our autonomous vehicle, we can get back to talking about security and our TLS-alternative: a data-centric security solution for a data-centric messaging framework. With DDS Security, Industrial IoT system architects can use security plugins to fine-tune security and performance trade-offs, a necessary capability not offered by TLS (Figure 4 below). Authenticate only select data topics but no more? Check. Encrypt only sensitive information but no more? Check. Actually, there is more. Casting aside centralized brokers, DDS Security offers distributed access control mechanisms dictating what participants can publish or subscribe to certain topics without single points of vulnerability. This means that Miller’s unauthorized application would be denied permission to publish commands to control braking or steering. Or if Miller compromised the data in motion, the data subscriber could cryptographically authenticate the message and discard anything that doesn’t match established policies. Can we say our autonomous vehicle is now completely secure? No, because as Miller made it perfectly clear, we still need more conversations. However, we can certainly say that DDS and DDS Security provide the forward-looking flexibility needed to help connect and secure autonomous systems.

Screen Shot 2017-05-03 at 2.41.31 PM

Figure 4. Connext DDS Secure Pluggable Architecture

So, to Mr. Charlie Miller (and of course Mr. Chris Valasek), your work is amazing and vision inspiring, but I think you need to look across industries if you want to talk openly about redesigning automotive architecture. When you and all the other Charlie Millers in the world want to have that open conversation, come knock on our door. At RTI, we are ready to talk to you about autonomy, Industrial IoT, safety and security, and everything you else you believe should define cars of tomorrow.

Mission: ace the initial screening call and get asked back for in-depth interviews Reply


Congratulations! Hopefully the tips from Mission: score an interview with a Silicon Valley company were helpful, and you have been contacted to talk to the hiring manager. Here are a few tips on how to ace the initial call.

Before the interview

  • Test your system. We often use a video call to interview candidates: Skype or Google Hangouts. Make sure your camera and microphone work. Do not use a phone for video conferencing. Sometimes we do hands-on exercises. Have a working IDE, editor and compiler installed. Lastly, take a few moments to clean up your computer background and desktop files.
  • Be professional. Dress appropriately in a shirt or blouse. A suit or tie is overkill. Also, pay attention to your environment and background. Clean up the room. Coordinate with your family or roommates that you will be in an important interview call.
  • Prepare by exploring the company website. Read about the products, download the evaluation software, check out the videos, or forums. Learn as much as you can about the company. Look up the interviewer on LinkedIn. You have to learn about a common passion.

During the interview

  • Be friendly and personable. Smile. Show a spark.
  • Be confident, but don’t oversell. And no BS.
  • Ask clarifying questions, especially if your English is not that great.
  • Be sincere if you do not know something but try to answer anyway. For example, “I am not a Java expert, though if it works similar to C#, then …”
  • Don’t give up. Brainstorm. An interview is not a pass/fail test. One candidate felt he should have been asked back for an in-depth interview because he answered six of the ten questions correctly; in his eyes, he had passed the interview. Unfortunately, for the four questions he missed, he didn’t even try to answer them. Being able to figure out things you don’t know is one of the most important skills of an engineer.
  • Don’t play hard to get or show you are disinterested. Don’t act selectively.
  • Think of some questions to ask about the company, job, customers, etc.

Good luck getting to the in-depth interview mission. Apply now to start the process!

Why Would Anyone Use DDS Over ZeroMQ? Reply

zeroMQ vs AMQP vs DDS

Choices, choices, choices. We know you have many when it comes to your communications, messaging and integration platforms. A little over a year ago, someone asked a great question on StackOverflow: why would anyone use DDS over ZeroMQ?. In their words, “it seems that there is no benefit [to] using DDS instead of ZeroMQ.”

It’s an important question – one that we believe you should have the answer to, and so our CTO, Gerardo Pardo-Castellote, provided an answer on StackOverflow (a shorter version of his answer is provided below).


In my (admittedly, biased) experience as a DDS implementer/vendor, I have found that many developers of applications find significant benefits using DDS over other middleware technologies including ZeroMQ. In fact, I see many more “critical applications” using DDS than ZeroMQ.

First a couple of clarifications:

DDS, and the RTPS protocol it uses underneath, are standards, not specific products.

There are many implementations of these standards. To my knowledge, there are at least nine different companies that have independent products and codebases that implement these standards. It does not make sense to talk about the “performance” of DDS versus ZeroMQ, you can only talk about the performance of a specific implementation. I will address the issue of performance later but from that point of view alone the statement “the latency of ZeroMQ is better” is plainly wrong. The opposite statement would be just as wrong, of course.

When is it better to use DDS?

It is difficult to provide a short/objective answer to a question as broad as this. I am sure ZeroMQ is a good product and many people are happy using it. The same can be said about DDS. I think the best thing to do is point at some of the differences and let people decide what is important to them.

DDS and ZeroMQ are different in terms of the governance, ecosystem, capabilities, and even layer of abstraction. Some important differences:

Governance, Standards and Ecosystem

Both DDS and RTPS are open international standards from the Object Management Group (OMG). ZeroMQ is a “loose structure controlled by its contributors.” This means that with DDS there is open governance and clear OMG processes that control the specification and its evolution, as well as the IPR rules.

ZeroMQ IPR is less clear. On the web page (http://zeromq.org/docs:features), it is stated that “ZeroMQ’s libzmq core is owned by its contributors” and “The ZeroMQ organization is a loose confederation without a clear power structure, that mostly lives on GitHub. The organization’s Wiki page explains how anyone can join the Owners’ team simply by bringing in some interesting work.”

This “loose structure” may be more problematic to users that care about things like IPR pedigree, Warranty and indemnification.

Related to that, if I understood correctly, there is only one core ZeroMQ implementation (the one in GitHub), and only one company that stands behind it (iMatix). Besides that, it seems just four committers are doing most of the development work in the core (libzmq). If iMatix was to be acquired or decided to change its business model, or the main committers lost interest, the user’s only recourse would be supporting the codebase themselves.

Of course, there are many successful projects/technologies based on common ownership of the code. On the other hand, having an ecosystem of companies competing with independent products, codebases, and business models provides users with assurance regarding the future of the technology. It all depends on how big the communities and ecosystems are and how risk-averse the user is.

Features and Layer of Abstraction

Both DDS and ZeroMQ support patterns like publish-subscribe and Request-Reply (a new addition to DDS, the so-called DDS-RPC). But generally speaking, the layer of abstraction of DDS is higher. Meaning the middleware does more “automatically” for the application. Specifically:

DDS provides for automatic discovery

In DDS you just publish/subscribe to topic names. You never have to provide IP addresses, computer names or ports. It is all handled by the built-in discovery. And it does it automatically without additional services. This means that applications can be re-deployed and integrated without recompilation or reconfiguration. 

In comparison, ZeroMQ is lower level. You must specify ports, IP addresses, etc.

DDS pub-sub is data-centric

An application can publish to a Topic, but the associated data can represent updates to multiple data-objects, each identified by key-attributes. For example, when publishing airplane positions each update can identify the “airplane ID” and the middleware can provide history, enforce QoS, update rates, etc. for each airplane separately. The middleware understands and communicates when new airplanes appear or disappear from the system.

Also, DDS can keep a cache of relevant data for the application, which it can query (by key or content) as it sees fit, e.g., read the last 5 positions of an airplane. The application is notified of changes but it is not forced to consume them immediately. This also can help reduce the amount of code the application developer needs to write.

DDS provides more support for “application” QoS

DDS supports over 22 message and data-delivery QoS policies, such as Reliability, Endpoint Liveliness, Message Persistence and delivery to late-joiners, Message expiration, Failover, monitoring of periodic updates, time-based filtering and ordering. This is all configured via simple QoS-policy settings. The application uses the same read/write API and all the extra work is done underneath.

ZeroMQ approaches this problem by providing building blocks and patterns. It is quite flexible but the application has to program, assemble and orchestrate the different patterns to get the higher-level behavior. For example, to get reliable pub-sub requires combining multiple patterns as described in http://zguide.zeromq.org/page:all#toc119.

DDS supports additional capabilities like content-filtering, time-filtering, partitions, domains and more

These are not available in ZeroMQ. They would have to be built at the application layer.

DDS provides a type system and supports type extensibility and mutability

You have to combine ZeroMQ with other packages like Google protocol buffers to get similar functionality.


There is a DDS-Security specification that provides fine-grained (Topic-level) security including authentication, encryption, signing, key distribution and secure multicast.

How does the performance of DDS compare with ZeroMQ?

Note that you cannot use the benchmarks of Object Computing Inc.’s “OpenDDS” implementation for comparison. As far as I know, this is not known to be one of the fastest DDS implementations. I would recommend you take a look at some of the other implementations such as RTI Connext DDS (our implementation), PrismTech’s OpenSplice DDS or TwinOaks’ CoreDX DDS. Of course, results are highly dependable on the actual test, network and computers used, but typical latency performances for the faster DDS implementations using C++ are on the order of 50 microseconds, not 180 microseconds of OpenDDS. See https://www.rti.com/products/dds/benchmarks.html#CPPLATENCY

Middleware layers like DDS or ZeroMQ run on top of things like UDP or TCP, so I would expect they are bound by what the underlying network can do and for simple cases they are likely not too different, and they will, of course, be worse than the raw transport.

Differences also come from what services they provide. So you should compare what you can get for the same level of service, for example publishing reliably to scaling to many consumers, prioritizing information and sending multiple flows and large data over UDP (to avoid TCP’s head-of-line blocking).

Based on the relative performance of different DDS implementations  (http://www.dre.vanderbilt.edu/DDS/), I would expect that in an apples-to-apples test, the better-performing implementations of DDS would match or exceed ZeroMQ’s performance.

That said, people rarely select the middleware that gives them the “best performance.” Otherwise, no one would use Web Services or HTTP. The selection is based on many factors; performance just needs to be as good as required to meet the needs of the application. Robustness, scalability, support, risk, maintainability, the fitness of the programming model to the domain and total cost of ownership are typically more important to making the correct decision.

Which one is best?

If you’re still undecided, or simply want more information to help you in making a decision, you’re in luck! We have the perfect blog post for you: 6 Industrial IoT Communication Solutions – Which One’s for You? [Comparison].

If you think RTI Connext DDS may be what you need, head on over to our Getting Started homepage where you’ll find a virtual treasure trove of resources to get you up and running with Connext DDS.

getting started with connext dds