Anchoring Trust in the Increasingly Software-Based Car

Bill Boldt
Business Development Manager, Security 
Blackberry

Electronic Control Units (ECUs) started out in the 1970s as discrete modules with each one doing one particular thing, at that time mainly for emissions controls and mileage.  Then they became connected via in-car networks with the invention of the CAN bus in 1985.  In-car networking represented a big improvement in capability.  However, being networked means that ECUs became vulnerable to mischief and thus they, and what the connect to (such as domain and area controllers) need to be secured cryptographically to ensure that the signals being sent have not been tampered with or corrupted, and perhaps most importantly, that they are authentic.   There is also the emerging need for confidentiality (i.e. encryption/decryption).

The picture below shows the top attack points.  This range or targets indicates just how vulnerable cars have become: 

With a car having so many places to attack, how can trusted security be implemented and why is it so important?  Well, the main thing is that trust leads to safety, especially as cars become more connected and autonomous.  Hacked or corrupted signals can have dire consequences in a car, which is obvious.  In a car, safety is related to security and security comes to a  large extent from cryptography.  (Note that safety and security are not exactly the same thing, but there is tremendous overlap and interplay, and safety is becoming much more dependent on cryptographic security as cars become more connected and autonomous.  For more on functional safety look here.)

Trust
Trust is paramount in digital systems, and increasingly so in automotive. Trust comes from cryptographic solutions that:

• Securely store secret keys
• Securely issue, manage, renew and revoke security certificates
• Include a mix of software and security hardened hardware devices, and
• Are manufactured in highly secure facilities

What Creates Trust?
A major tenet of security is that each system and sub-system will have different types of threats and a range of options to provide countermeasures to those. This means that the automotive security equation has many variables and thus is difficult to solve.

However, two things are always common to trustable cryptographic security, and they form the basic foundation of modern security:

1. A proven algorithm (e.g. Elliptic Curve Cryptography (ECC)), and  
2. A secret cryptographic key  (to provide the required level of security for the selected algorithm). 

The challenge for the automaker is to choose the right algorithm and key length for the available processing resources and to securely issue, manage/store, renew, and revoke the security certificates. Cryptographic strength comes from the combination and application of these principles, processes, and techniques. 
 
Trust Anchor
On a CAN bus, which was designed without security in mind, ECUs are exposed.   So, connected cars should employ best practices for security, but cost, complexity (especially of the supply chain) and time get in the way. Having said that, best practices will eventually prevail and that will likely include a hardware trust anchor system to establish, maintain, and update cryptographic processes.

 
From the diagram you can see the four basic things that create a PKI-based hardware trust anchor:

1. A trusted hardware anchor that stores the key
2. That key, which becomes the root of trust
3. The certificate chain anchored by the root of trust, and
4. A signing mechanism that creates the anchored certificate chain

Multi-level Security

Because there are so many systems in the increasingly software-defined car, security has to be multi-layered and fit the specific application. In other words — it must be tailored. You have to figure out what you are securing, what threats that system will face, and what countermeasures should be employed. You have to pick what pillars of security to apply; namely, confidentiality, data integrity, authentication, and non-revocation. Making sure you are doing the right security things on each system is what Blackberry is positioned to help you with, from consulting, to design, testing, certificate management, securing the supply chain, making updates, and applying cryptography to the in-car and around-the-car networks.

To learn more about cryptography for automotive please contact Blackberry's Certicom
subsidiary, and for more information and/or help regarding reliable, secure, and trusted software for safety- and mission-critical applications such as automotive please contact QNX. 

The bottom line is that BlackBerry, Certicom, and QNX can help your system become not just secure, but BlackBerry secure. 

The Secret to a Successful Autonomous Vehicle Development Program: A Data-Centric Approach to Autonomous Car Design

Bob Leigh, Director of Market Development at RTI
Romain Saha, Strategic Alliances Manager at BlackBerry

The automotive industry is facing unprecedented changes in the coming decade. With the rise of autonomous and connected cars, software is a significant differentiator in the automotive market. As software takes a central role in the functions and features of the car the investment in software development is accelerating dramatically. Automotive companies must adopt novel software design methodologies to be competitive, as well as ensure safety, security, and a quality user experience. Fortunately, embedded system architecture is also evolving. Fueling this change is the proliferation of “system-of-systems” architectures, where connectivity and accessibility are baseline requirements. This requires interoperability! 

  
IIoT and Data-Centric Design

The rise of the Industrial Internet of Things (IIoT) is driving this need for new architectures to unify the standalone devices of the past. These changes are already happening in other market segments and are fully applicable to automotive. In ever more connected and autonomous cars, many subsystems operate in tandem, but without the benefit of a greater awareness. For example, braking systems have very little interaction with power steering.  As we connect these systems and add layers of automation, the car itself becomes a system-of-systems – where braking and steering coordinate with vision and sensor functions – and every car is then connected to a much larger system. 

These larger connected systems could support fleet management, traffic management, sharing services and other as yet undefined applications.

 

Such a new design model must provide:

• Time-sensitive reliable transport, safety and mission-critical rigor in software design;
• Interoperability between applications, domains, operating systems, and entire heterogeneous systems;
• Support for high volume communication across multiple domains or compute platforms (sensors, actuators, etc.); and 
• Code reuse and the evolution of the system as it moves from research to development, on to production and into maintenance lifecycles that span multiple model releases.

Data-centric architectures address all these requirements. A data-centric architecture offers reduced development and maintenance costs when compared to device or application-centric or object-oriented approaches. 

Data centric-architectures support interoperability between teams, application and entire network domains and foster innovation through better access to data. To be data-centric means to put data at the center of any system, which is then self-describing and accurately reflects the real-time state of the system. It abstracts the complexity of operating systems, hardware, and network programming to allow applications to focus on the core value they add to the system. It decouples applications so that they become actors that use or change the state of data but do not explicitly interact with each other. This approach supports the sharing of code and IP (since it does not depend on a specific platform) and has many advantages in scalability, interoperability and maintaining data/state integrity.

Complete Lifecycle Support Platform

 

The preeminent data-centric middleware standard for real-time systems is DDS (Data Distribution Service). DDS is an open standard maintained by the Object Management Group (OMG). This standard has been developed over decades in highly demanding applications and is in use today in multi-billion dollar product lines worldwide.

DDS offers many features that are critical to any ADAS or Autonomous Drive application. Core to DDS, Quality of Service allows developers to guarantee latency, control data flow and manage network bandwidth. All of these things are achieved within the middleware, so the application only needs to focus on the processing of data, not the delivery.

Interoperability between applications and domains creates a layer of abstraction that allows OEMs to combine systems from different Tier 1s in a way that minimizes complexity and risk. It supports multiple operating systems seamlessly to enable architectural evolution from statically to dynamically configured higher-level operating systems – moving from the idea of domain controllers to compute platforms. It provides a unified infrastructure to connect and control different domains, paving the path to sensor fusion. It supports the high volume of traffic that these architectures will demand.

With DDS, applications, teams of developers, and systems share data using a common data model defined for the entire system. Once defined, all interaction between system actors is understood through this common data model. Code development and application interactions are decoupled, which allows more efficient development and collaboration of large, geographically distributed teams. DDS can support many thousands of applications with hundreds of development teams worldwide. This is the power of data-centric middleware.

Certified Software Stack

For many years DDS has been used in air, land, and sea autonomous system projects. It provides the features needed to support time-critical, dynamic, high volume applications that are key to the next generation ADAS architectures and ultimately to autonomous drive. Using a safety certifiable middleware, such as RTI Connext® DDS Cert, with QNX ISO26262 certified RTOS and ADAS framework, you can begin development with a fully-integrated, certified software stack. The combination allows engineering teams to focus on their core value-add in application development while ensuring system performance, interoperability, security and safety certifiability.

RTI (Real-Time Innovations, Inc.) is the largest DDS vendor and is the only one with a safety certifiable version of its product. RTI Connext® DDS is used in many mission-critical and safety-critical applications and is an essential component of the future Autonomous Car.

Please contact RTI at  bobl@rti.com or QNX at rsaha@blackberry.com today to learn more about these powerful tools.

QNX Software Systems Limited, subsidiary of BlackBerry is a leading vendor of operating systems, development tools, and professional services for connected embedded systems. Global leaders such as Audi, Cisco, General Electric, Lockheed Martin, and Siemens depend on QNX technology for vehicle infotainment units, network routers, medical devices, industrial automation systems, security and defense systems, and other mission- or life-critical
applications. Founded in 1980, QNX Software Systems Limited is headquartered in Ottawa, Canada.


For more information on Connext DDS in Autonomous Vehicles, please download our whitepaper or register for this upcoming joint webinar with QNX and RTI.

---

On Clusters and Infotainment

Romain Saha

Strategic Alliances Manager
BlackBerry

I think I have IAD or internet addiction disorder. I don’t argue with people anymore. I just google until I get the answer. I can’t remember anything. Why should I? It’s all out there on the internet. I barely watch TV anymore. I’d rather just learn something using the internet. 

OK – this probably isn’t textbook IAD. Maybe it’s just the new reality. Pretty much everything anyone could possibly want to know is out there somewhere on the internet. Sometimes it’s easy to find. Sometimes it’s hard. But it almost always is out there if you look hard enough. 

You would think that in this brave new world that there’s no opportunity for confusion anymore. I thought so until I started trying to figure out how one could build a safety certified digital instrument cluster and a full-blown infotainment system using a single high powered embedded processor. I see a lot of silicon road maps in my role and those indicate that a lot of horsepower is coming online. So much horsepower that it’s starting to look like using separate processors to run disparate systems in a car doesn’t make sense anymore.

You’d think that combining a cluster and infotainment system on one SoC would be a no-brainer. Dual (or more) display support is getting pretty common and even today’s SoCs have the compute cycles, so why isn’t everybody already doing this?  It seems pretty easy until you consider that the cluster is a safety critical system. It’s not even the whole cluster, mind you. It’s just what they call telltales. Telltales are those icons that light up in your car to tell you you’re in drive and not reverse, that your traction control is offline, or that your engine is about to blow up. Small things maybe, but very useful information indeed. So, that means you have to address safety concerns for the cluster.

Why not just apply safety criteria to the whole system including the head unit then and be done with it? That is one approach certainly, but the problem is that an infotainment system is pretty much impossible to safety certify. Maybe impossible is too strong. You could probably do it, but why would you? It would probably cost way more than any savings resulting from collapsing two systems onto a single chip.  Plus it would take forever.

If that’s not the answer, then what is? Finding a way to isolate cluster safety criteria from the infotainment system can do job, as long as you can ensure complete isolation. This isn’t a new concept but still pretty rare in embedded.   This is called a hypervisor, and if it is done right, it does the trick. Well, almost. Not every hypervisor can do it right. In order to ensure isolation for this use case you need a type-1 hypervisor. Type-2 hypervisors don’t cut it.  

This is where the internet starts to fail me.  I see hypervisors described as type-1 but then see things about proprietary drivers. I see people say virtualization, but when you dig a bit deeper it’s hard to say whether it’s virtualization or para-virtualization. Type-1, type-2, para, hybrid… I’m at the point where I don’t really know what I see. 

It would be so much easier if people answered simple questions with simple answers.

• Can you share graphics and still achieve true safety isolation? 
•  Is the hypervisor built in a way that you can reasonably safety certify your system.
•  Is it real-time? 
• How much overhead does it add to the overall system? 
• What happens if a guest OS goes rogue? 

Maybe you could ask your hypervisor supplier how they address this kind of stuff. If you get an answer that makes sense, do the world a favor and spread the word.

The second thing you need is a foundation on which to build a safety certified system. QNX, as an example, has certified both its OS and tool chain to ISO 26262 ASIL D. You can find this certification on the internet. It’s  here . If you take the time to read it, it says we did the tools and the OS. The production OS used in millions of systems shipping worldwide.

  

Here’s where the internet fails me again. I have looked and looked and looked for another embedded OS company with anywhere near the same level of certification. It has to be out there. I see all kinds of anecdotal “marketing" evidence but I can’t find a certificate. The closest I have come so far is a certificate for an OS, without the tools, that was issued in 2007 for Common Criteria EAL 6+ on an old single-core PowerPC processor. I must be missing something.  Can you buy a PowerPC processor anymore? I guess you should ask to see certificates to be sure you know what you’re getting.

I’m having a hard time coming to grips with the internet letting me down. I’m certain I just don’t know where to look, so if anyone has the answers I’m looking for, I’d love to hear about it. Better yet, post it somewhere on the internet that’s easy to find.

The next thing I’m going to try to find is someone with a safety certified hypervisor because you’ll need one of those too…