Smart cars can reduce traffic congestion, and more importantly, prevent fatal accidents. At the same time, however, more connectivity and internet-enabled services open further attack vectors in modern vehicles. So, while the integration of connected systems with vehicle controls has fundamentally changed the notion of vehicle safety and security, car OEMs and Tier 1 firms are still catching up with the relentless pace of innovations in the connected car realm.
In hindsight, the car hacking saga that forced Chrysler to recall 1.4 million vehicles served as a wake-up call for the automobile industry. In 2015, computer security researchers Charlie Miller and Chris Valasek were able to stop a Jeep Cherokee on Interstate 64 in Missouri, by hacking its internet-connected infotainment system.
Miller and Valasek were able to send commands to the engine and wheels through the CAN bus that carries information between the vehicle’s various electronic control units (ECUs) handling adaptive cruise control, electronic brakes, and control of the steering. The incident became a turning point for the automobile industry, which so far, had been reluctant to invest in security simply because consumers were not willing to pay for the security electronics.
Carmakers are now significantly more sensitive to a host of new security threats that are intertwined with data connections inside and outside of vehicles. That inevitably calls for a multi-pronged security approach to protect multiple networks both inside and outside of the car.
Let’s begin with securing a car’s communications with the outside world that is largely manifested in the vehicle-to-everything (V2X) technology that encompasses vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-pedestrians (V2P) communications.
1. Vulnerabilities Outside of the Vehicle
All V2X stations—on-board unit (OBU) in vehicles as well as roadside units (RSU)—rely on public key infrastructure (PKI) defined in the IEEE 1609.2 protocol based on dedicated short-range communications (DSRC) technology. The security architecture in the DSRC standard assigns and distributes certificates to authorize data exchange and safeguard data privacy.
But V2X communications is a work in progress, and we won’t see many V2X-equipped vehicles before 2020. So, while automotive designers are building security into V2X systems, there are two fundamental approaches currently used to incorporate security into the networked vehicle systems.
First, chipmakers like NXP and Infineon are adding security engines to their automotive MCUs to check the authenticity of over-the-air (OTA) software updates and prevent malware from infiltrating the vehicle. Second, MCU suppliers like Microchip are offering low-cost co-processors that assign certified and trusted identities to automotive subsystems for protection against threats such as spoofing and distributed denial-of-service (DDoS) attacks.
The specialize chips, like ATECC506A, offload security features from the main processor, and don’t require the hardware security module (HSM)-related authentication keys, distribution infrastructure, and logistics.
Then, at the junction of external communications and in-car networking, automotive MCUs are providing the gateway functionality for vehicle ECUs, while securing the OTA updates. Take, for instance, STMicro’s new Chorus microcontroller, SPC58NH92x, which incorporates HSM functionality to secure remote updates as well as in-vehicle networking. It features two Ethernet ports as well as 16 CAN-FD and 24 LINFlex interfaces.
And that brings us to the next frontier in the quest to secure connected cars: in-vehicle networking.
2. CAN Overhaul Inside the Vehicle
The Miller and Valasek hacking saga, which woke up the automobile industry from its security slumber, was more about CAN bus vulnerabilities than anything else. The truth is that the CAN bus, developed during the early 1990s, was never meant to provide security.
Later, CAN bus architects developed mechanisms like message authentication code (MAC), which employs encryption and complex key authentication process. However, it also increases compute load on the CAN bus, leading to message latency and delays, as well as more power draw. In short, The MAC-centric approach significantly raises the processing load on CAN controllers, and makes the CAN bus communications rather inefficient.
NXP Semiconductor claims to have found a solution around this design conundrum, without modifying the software in CAN controller for adding the MAC functionality. The Dutch chipmaker has unveiled a CAN transceiver that facilitates logging and reporting of security incidents on the bus, invalidating the message with an active error flag, while temporarily disconnecting the local node from the CAN bus.
If an ECU attempts to send a message which is not assigned to it, the secure CAN transceiver declines to transmit it on the bus. Likewise, on the receiver side, if a rogue ECU manages to send a message, the TJA115x CAN transceiver (Figure 3) can invalidate the message after comparing it with the CAN message ID originally assigned for transmission. Moreover, if no cyber incident is detected, it behaves like a standard CAN transceiver.
TJA115x employs a crypto engine that circumvents the processing load, bandwidth overhead, and communication delays. The transceiver chip also provides tamper protection and defense against efforts to flood the CAN bus by regulating the number of messages sent from an ECU at a given time.
3. Securing a Car’s Software Labyrinth
Today, a high-end car comprises more than 100 million lines of code, which surpasses the aggregate amount of software code in the space shuttle, Boeing 787 Dreamliner, and Microsoft Office. Software complexity will skyrocket with the automobile industry’s move toward self-driving cars.
The rise in the number of OTA software patches and updates is the first major challenge. Software solutions like secure bootloaders facilitate the authentication of updates via the air interface and the corresponding real-time diagnostics.
Then, there are embedded operating system (OS) solutions that partition safety-critical applications like collision warning from non-safety-critical services, such as real-time traffic updates. Hypervisors create virtual software containers that act as a traffic cop, for instance, making sure that infotainment and instrument cluster systems don’t interfere with each other.
Beyond the domain separation that secures the execution of sensitive code, automotive engineers are also carrying out the hardening of safety-critical applications running on OS and other embedded software platforms. Add to this the secure coding practices and solutions like firewalls that can thoroughly examine the software code.
BlackBerry, the supplier of QNX OS-based platforms for automotive designs, has recently launched a cloud-based tool that scans software in connected cars and identifies security flaws within minutes. Software tools, like Jarvis, allow automotive engineers to ensure that their code complies with the connected car’s security requirements.
Multi-Pronged Vehicle Security
Connected car security isn’t a single-track horse. It demands a multi-layered security approach encompassing both hardware and software components. The good news is that there are pre-configured design options that simplify the otherwise complex security implementations. For example, there are design kits that bypass the need for in-house security expertise.
Time is also on the automotive industry’s side. So far, most car hacking events have been demonstrated by IT security experts, not actual hackers with malicious intentions. So, it’s about time that automotive OEMs and Tier 1s get their act together in securing connected cars.
