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


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.

Use MATLAB to Leverage Your Live IoT Data Reply

leverage live data MATLAB DDS

If you have ever done any data analysis from a sensor or other type of data source, you have most likely followed a process where you collect the data, you convert the data and then use MATLAB to process and analyze the data.  Using  MATLAB to analyze the data is a very well known tool to accomplish that task.  Collecting and converting the data, so that it is usable in  MATLAB, can take an enormous amount time.  Thanks to an integration that was completed by MathWorks, it is now possible to easily connect  MATLAB up with live data that is being published and subscribed to on DDS.  With  MATLAB being one of the top tools used to analyze data and DDS quickly becoming the data communications middleware of IIoT applications, this integration will enable some very rapid prototyping and test analysis for developers.  This blog post will walk through a few examples of how to publish DDS data and also how to subscribe to DDS data using  MATLAB.

Getting Started

To get started, you will need to make sure that both  MATLAB and RTI Connext DDS are installed on your computer.  For this set of examples, the following versions were used:

Once you have those installed, just follow the video at this link to complete and verify the installation:  Installation Video


Once you have everything installed and verified, then there are just a few steps to get DDS setup appropriately within  MATLAB.

  •  Import the datatype(s) that will be used in your project.
  •  Create a DDS Domain Participant
  •  Create a DDS DataWriter
  •  Create a DDS DataReader

Importing a datatype in  MATLAB is simple.  In DDS, datatypes are specified using IDL files.  The  MATLAB import statement can read an IDL file directly and will create the “.m” files required to work with that datatype within the  MATLAB interpreter.  The following  MATLAB call will import a datatype called “ShapeType” from the ShapeType.idl file located in the current working directory:

>> DDS.import('ShapeType.idl','matlab','f')

Now that datatype is available to use when creating your DataReaders and DataWriters of topics in DDS.  Also note, that once the import has been done, this step no longer has to be run in the future.  The type will be available in  MATLAB going forward.  The next thing to do to get DDS discovery going is to create a DDS Domain Participant.  That can be accomplished in this call:

>> dp = DDS.DomainParticipant;

Using this DomainParticipant (dp) object, you can then create both DataWriter and DataReader objects.  The following two commands will add a datawriter object and datareader object to the dp specifying its type to be the newly created “ShapeType” and their topics to be “Triangle” and “Square” respectively.

>> dp.addWriter('ShapeType','Triangle')
>> dp.addReader('ShapeType','Square')

Subscribing to Data in Shapes Demo

The ShapeType is used so that it will communicate with the standard RTI Shapes Demonstration application (Shapes) that is provided by RTI.  Shapes enables the creation of both DataWriters and DataReaders of “Square”, “Circle” and “Triangle” topics that are in turn based on the “ShapeType” datatype.  For more information on how to use the Shapes application, click here to view our video tutorial.

In Shapes, the next step is to create a subscriber of Triangle. In the next screen just leave all the other QoS options as default.


Publishing Data in  MATLAB

Now that we have the DataWriter setup in  MATLAB to send out ShapeType on the Triangle topic, and also we have the Shapes Demo setup to receive the publication, lets exercise the writer.  The following commands will populate the fields of the ShapeType and then publish out the data on the Triangle Topic:

%% create an instance of ShapeType
myData = ShapeType;
myData.x = int32(75);
myData.y = int32(100);
myData.shapesize = int32(50);
myData.color = 'GREEN';

%% write data to DDS

The result on the Triangle Topic within the Shapes Demo will be a single Green Triangle shown here:


Some more interesting use cases of publishing Triangle within  MATLAB are:

%% Publish out Green Triangles in a line at 1 Hz
for i=1:10
    myData.x = int32(20 + 10*i);
    myData.y = int32(40 + 10*i);

%%  Publish out Green Triangles in a Circle pattern at 20Hz
for i=1:1000
    angle = 10*pi * (i/200);
    myData.x = int32(100 + (50 * cos(angle)));
    myData.y = int32(100 + (50 * sin(angle)));
    myData.shapesize = int32(40);
    myData.color = 'GREEN';

The resulting output on the Shapes Demo are respectively:

multigreentirangle             greentirangleincircle

Publishing Data in Shapes Demo

In the Shapes demonstration, create a publisher of Square.  In the next screen just pick a color and leave all the other QoS options as default.  The following screenshot shows the Square Publish screen.  For my demonstration, I have chosen an Orange Square.  This will publish the X,Y Position on the screen every 30 msec.

createsubscriber                orangesquare

Subscribing to Data in  MATLAB

If you remember from before we added a Square Topic DataReader to the Domain Participant in  MATLAB.  We will use this DataReader to subscribe to data that we are now publishing from the Shapes Demonstration.  The following commands in  MATLAB will read 10 samples at 1 Hz.

%% read data
for i=1:10

The resulting output in  MATLAB will be 10 reports of the following:


Something More Interesting

Now that we have both directions going, lets do something that is more creative with the data.  First we will read in the Square data and modify it to switch the X and Y coordinates and then republish it out on to a RED Triangle.  Second, we will take the resulting Position data and plot it directly within  MATLAB.  These are the commands to use in  MATLAB to accomplish that.

%% allocate an array of 100 elements
xArray = zeros(1,100);

%%  run a loop to collect data and store it into the array
%%  also switch up the X and Y coordinates and then republish onto 
%%  the Triangle topic
for i=1:100
       [myData, status] = dp.read();
       if ~isempty(myData)
            x = myData(1).x;
            y = myData(1).y;
            xArray(i) = x;
            yArray(i) = y;
            myData(1).y = x;
            myData(1).x = y;
            myData(1).color = 'RED';

%%  Plot the X Position Data
t = 1:100;
xlabel('Time'), ylabel('Position');
title('X Postions');

The resulting output in Shapes Demo will be a Red Triangle moving the opposite of the Orange Square and also a Plot will be generated within  MATLAB showing the X Position data:

orangesquare_redtriangle       xposgraph

As you can see, the integration of DDS with  MATLAB is very simple to use and makes it very easy to collect data, inject data and analyze data.  For this demonstration, we used the simple Shapes Application, but the data used can just as easily be your own application data.  If you would like to find out more about the  MATLAB Integration with RTI Connext DDS, please visit this site on MathWorks site:  MATLAB DDS Integration. If you’d like to learn more about using Connext DDS, click here to gain access to our developer resources.

ISO 26262 Certification for Software Components Reply

Guest author: Joe Wlad, Vice President, Business Development, Verocel, Inc. 


The automotive industry has adopted ISO 26262 as its functional safety standard for electronic systems. The current version of ISO 26262 was published in 2011, with a second edition scheduled for release in 2018. The increased use of software in automotive systems such as driver assist, brake control and engine and systems management has placed a greater scrutiny on ensuring the software is safe. Modern vehicles now contain millions of lines of software and software quality is more important than ever. While automotive designers and suppliers have 5 years’ experience using ISO 26262, the bar for software compliance is now higher due to increased complexity, integration and automation. Moreover, one can expect regulatory oversight to increase in the future due to changing policies. In September 2016, the U.S. DOT issued a new federal policy for safe testing and deployment of automated vehicles. This new policy seeks to strike a fair balance between innovation and regulatory oversight but will require additional effort from vehicle makers and suppliers who wish to use forms of automation in their future designs.


Historically, all automotive companies and suppliers practiced a form of “self-certification” regarding their systems, hardware and software. To date, there is no pre-market approval process and no government regulator in the loop. Manufacturers do their own due diligence and any government oversight of safety design, development and production comes into play only after vehicles go into production. Even though a pre-market approval process for road vehicles would be impractical even for autonomous features, designers will have to place additional emphasis on software design and verification practices in the near future. Fortunately, ISO 26262 addresses the key requirements for software development and design and software suppliers like RTI are prepared to assist designers in ensuring compliance with ISO 26262 software requirements.

ISO 26262 covers functional safety at the system, hardware and software levels. To be considered fully compliant with ISO 26262, all areas must be addressed at once meaning that the software has to be integrated onto a given hardware platform and within a given system before it is approved. This poses a dilemma for suppliers who wish to use COTS software such as an operating system or communication layer because it places an additional certification burden on the supplier to represent software they may not have designed themselves. Companies like RTI and Verocel have addressed this problem by providing both certification evidence and a framework to use that evidence in any system design and achieve ISO 26262 compliance at ASIL-D. The details of this approach are documented in a whitepaper called ISO 26262 Compliance Using Approved Software Components for Road Vehicles which can be downloaded at both the RTI and Verocel websites.


The whitepaper provides a complete background on ISO 26262 processes and what parts of the standard would apply to COTS software components. It also provides a summary of key characteristics of COTS software that can be used in road vehicle designs as well as documentation and evidence to assist the integrator in achieving ISO 26262 compliance. RTI Connext DDS Cert supports the DDS (Data Distribution Service) family of standards and is a certifiable middleware available with a complete, commercially supported certification package to support ISO 26262 certification, including ASIL-D. Connext DDS Cert provides an architecture and hardware-independent layer of software that can be used on virtually any system design. It also comes with the certification evidence that supports ISO 26262, sections 2, 6 and 8 as well as additional guidance and information that helps designers integrate Connext DDS and retain certification credit in their system.

Automotive designers and suppliers need to prepare for a future where increased regulatory compliance for software will be a norm. The days of complete self-certification autonomy are coming to an end and suppliers will need to rely on an entire software ecosystem of suppliers who can meet the current and future ISO 26262 requirements head-on. RTI and Verocel have broad experience in delivering certified software to customers in many industries and we are prepared to assist you.