Security in Automotive Applications

11.14.2012 // Murray Slovick // New Technology

Security in Automotive Applications

With over 30,000 lives lost each year due to vehicle crashes, the U.S. Department of Transportation (DOT) is studying whether all future cars should have some form of embedded connectivity for safety reasons. Automotive connectivity using vehicle-to-vehicle and vehicle-to-infrastructure (V2X) communications has been identified as a means for decreasing the number of fatal traffic accidents in the future (as well as for implementing intelligent traffic management programs).

Autonomous, or self-driving, cars also are closer to reality than you may realize. In June 2011 the state of Nevada was the first jurisdiction in the United States to pass a law allowing the operation of autonomous cars and last fall California followed suit. To date Google’s fleet of fully autonomous Toyota Prius hybrids have logged over 300,000 miles.

Examples of semi-autonomous safety applications include local danger warnings and electronically activated brakes and emergency brakes. While these capabilities may spur a new era of traffic safety, new security requirements need to be considered in order to prevent attacks on these systems. Examples of such threats are forced malfunctioning of safety-critical components or interference with traffic flow by means of false messages.

Consequently, as in-car networks begin to connect with access points outside the vehicle, sensitive in-vehicle data must be kept trustworthy and protected from modification. As such, security measures become essential and automakers are working to develop platforms that can withstand and negate malicious attacks on embedded automotive systems, including encroachment on messages sent between vehicles and infrastructure.

Not a Broadway Show

Europe has taken the lead in developing automotive security platforms. In November 2011 a European-based project called EVITA (for E-safety vehicle intrusion protected applications) presented the results of its work on security architecture for in-vehicle automotive networks. The objective of the EVITA project is to design, verify, and prototype architecture for automotive on-board networks where security-relevant components are protected against tampering and sensitive data is protected against compromise when transferred inside a vehicle.

Particular attention has been paid to electronic components within the vehicle, such as sensors or engine control units (ECUs), including the certification and verification of applications, remote management and virus or malware control. Among the ECUS that need cryptographic protection are:

  • Body Computer Modules
  • Climate Control
  • Brake ECU
  • Instrument Cluster
  • Night Vision
  • Battery Management System
  • Charger (where applicable)
  • Safety Computer
  • Adaptive Cruise Control
  • Engine Control
  • Gear Box
  • Electronic Steering
  • Hybrid Power Electronics

The central element of the EVITA vehicular security solution is a hardware security module (HSM). The EVITA specification targets both HW and SW and comes in three flavors:

Full EVITA HSM: This HSM focuses on protecting the in-vehicle domain against the extra-vehicular vulnerabilities of V2X communications. It supports strong authentication (e.g., RSA) as well as complex block ciphers at very high data throughputs. This requires creating and verifying electronic signatures. Here, an efficient asymmetric cryptographic engine is needed. The full HSM aims to provide a security lifetime of at least 20 years.

Medium EVITA HSM: This HSM focuses on securing on-board communication. It also supports complex block ciphers at high data throughput; the medium HSM resembles the full HSM except for the asymmetric cryptographic building block and a slightly lower performing CPU (25 MHz vs. 100 MHz). The medium HSM is able to perform some non-time-critical asymmetric cryptographic operations in software, such as for the establishment of shared secrets.

Small EVITA HSM: This HSM focuses on securing the interaction between secured ECUs and sensors and actuators. It supports simple block ciphers and low cost modules. It is only required to contain a symmetric cryptographic engine and the corresponding shortened hardware interface. The small HSM is able to meet cost and efficiency requirements with regard to message size, protocol limitations or processor consumption that are typical for sensors and actuators.

SHE Who Must be Obeyed

Similarly, EC-developd SHE (Secure Hardware Extension) is an on-chip extension within an MCU that provides a set of cryptographic services to the applications layer and isolates secret security keys from the rest of the MCU’s resources. SHE is endorsed by the German OEM group Hersteller Initiative (HIS), members of which include Audi, BMW, Daimler, Porsche and Volkswagen. SHE is more than European-centric; it is required by or referenced by automotive OEMS worldwide. The main cryptographic operations supported by SHE are secure encoding and decoding of messages and authentication of messages and data of the various communication nodes. Based on AES-128 encryption/decryption it also provides random number generation, a boot loader verfification and a unique device identifier.

SHE integrates a secure key store that cannot be read without access authorization, and it encrypts access codes with up to 128 bits. The secret keys and certificates are stored in a dedicated non-volatile memory not accessible by the automotive application.

A secure boot feature ensures that only the original software is loaded during the boot process. Every time the microcontroller is booted SHE checks the authenticity of the internal flash memory contents by means of a digital fingerprint. The cryptographic individual key of an ECU has to match all the cryptographic keys within the ECU network of a vehicle, and that key is stored safely in SHE, so even if an ECU were to be fitted in another identical vehicle, its engine performance characteristics could not be changed.

While explicitly designed for application in an automotive security context the SHE module is mainly built for securing cryptographic key material against software attack, but is not considered useable to protect vehicle-to-infrastructure (V2X) communications.

Expect the next generation of automotive devices to integrate a range of security peripherals to support these protocols in order to meet the auto industry’s growing security requirements.

Share this:

Statements of fact and or opinions expressed in MarketEYE by its contributors are the responsibility of the authors alone and do not imply an opinion of the officers or the representatives of TTI, Inc.

Featured Contributor:
Murray Slovick

Murray Slovick

Murray Slovick is Editorial Director of Intelligent TechContent, an editorial services company that produces technical articles, white papers and social media posts for clients in the semiconductor/electronic design industry. Trained as an engineer, he has more than 20 years of experience as chief editor of award-winning publications covering various aspects of consumer electronics and semiconductor technology. He previously was Editorial Director at Hearst Business Media where he was responsible for the online and print content of Electronic Products, among other properties in the U.S. and China. He has also served as Executive Editor at CMP’s eeProductCenter and spent a decade as editor-in-chief of the IEEE flagship publication Spectrum.

Click on a raw material to see a chart of its cost trend.
Enter your email address below to receive email updates whenever we publish new content.Subscribe
TwitterFacebookLinkedINGoogle +PinterestYoutubeRSSSubscribe