green shield behind car

Into the future with hardware-based cybersecurity

More than a decade has passed since the European EVITA (E-safety Vehicle Intrusion proTected Applications) project added a new chapter to embedded automotive security. The project’s approach was unparalleled at the time: a dedicated, programmable on-chip hardware block physically encapsulates the data to be protected and the related cryptographic operations and isolates them from the actual application side of the chip, thereby creating a dedicated security domain. These days, the EVITA security principle is employed – chiefly in the form of a hardware security module (HSM) – in almost all of the microcontrollers from automotive chip manufacturers as well as in systems on a chip (SoCs).

Host-to-HSM bridge is becoming a bottleneck

However, as the need for secure onboard communication (SecOC) increases, HSMs designed according to the EVITA approach are at risk of reaching their limits. Modern vehicles use external interfaces to communicate with diagnostic systems, charging stations, occupants’ mobile devices, other vehicles, infrastructure, and the cloud. And internal communication is also increasing; for example, due to large volumes of sensor data for automated driving or new, service-oriented proxy skeleton architectures. This rapidly expanding volume of network traffic must be secured in its entirety. To this end, message authentication codes (MACs) are generated on the sender side to uniquely identify the encrypted messages before they are decrypted on the receiver side. For this, all data must pass through the bridge between the microcontroller’s operational host core and the physically separated HSM core – meaning the host-to-HSM bridge inevitably becomes a bottleneck. However, today’s high-end HSM firmware (CycurHSM) is in a position to assign the crypto hardware the greatest possible bandwidth while keeping interaction with the host CPU to a minimum (Figure 1).


Figure 1: In the EVITA architecture, the host and security domains are separated from one another on the hardware side.

Performance-enhanced chip architecture

The next generation of automotive MCU architectures will further alleviate this bottleneck problem. Performance-optimized SecOC accelerators implemented on-chip alongside the HSM increase throughput by using direct memory access (DMA) functions linked to multiple, parallel, first-in, first-out (FIFO) queues. Each channel applies symmetric cryptography such as AES-256 to the data. Meanwhile, the keys are derived from the classic HSM and injected into the SecOC accelerator unit. Additional hardware mechanisms secure the transfer via an interconnect bus. Typically, this new hardware block can be configured but not programmed. Expressed in EVITA terminology, this is equivalent to connecting an EVITA Full unit via a secure bus interface to an EVITA Light unit – then combining and integrating them on a single chip (Figure 2). As a side benefit, this makes it easier to implement safety requirements relating to communication. This is because safety-critical messages are processed in isolation from security processes (secure booting and logging, key exchange, etc.) and are secured with Safe CMACs (cipher-based message authentication codes).


Figure 2: Next-generation automotive ECU chip: a performance-enhanced SecOC accelerator encrypts message traffic on the basis of key material provided by the HSM.

Hypervisor virtualization

Meanwhile, cybersecurity requirements in vehicles continue to rise: for host-side applications that have been developed by a number of different suppliers working within an agile environment and independently of the hardware supplier, there needs to be a way of performing partial, dynamic, software-over-the-air (SOTA) updates without compromising other areas of the software. In addition, for platform concepts, it must be possible to secure one and the same software function – depending on the OEM – with different sets of keys and certificates. That way, if a single host application is compromised, other applications will continue to function securely. It is also important to isolate functions with different security levels from one another. Nonetheless, all applications must still be able to simultaneously access the same hardware security module so as to benefit from its protection.

All of these scenarios can be implemented with the help of virtualization concepts based on a hardware-supported hypervisor. These hardware blocks are established at the SoC level, and are currently finding their way in a leaner form into the next generation of automotive microcontrollers. Today’s high-end security software stacks for the HSM or the hardware trust anchor (HTA) already support multicore applications. Virtualization, however, involves the use of virtual machines that can run on either the same CPU core or different ones. The new microcontroller architectures therefore have mechanisms to tag and identify security applications such as SecOC or sensitive data, so that these can then be clearly assigned to a specific virtual machine. Conversely, other virtual machines have no access to this data, making it possible to create individual isolated security domains (Figure 3).


Figure 3: In the next generation of automotive microcontrollers, the use of virtual machines will make it possible to assign CPU resources to a number of securely isolated applications.

Security for the vehicle of the future

In response to the future cybersecurity challenges in highly connected and increasingly software-defined vehicles, the next generation of MCUs will boast enhanced hardware-security features in combination with appropriately powerful security software stacks. As a core element, the EVITA principle of hardware-based embedded cybersecurity is more valid than ever – and additional security hardware blocks and virtualization mechanisms make it future-proof against increasing real-time requirements and the need for greater bandwidth.

SHARE THIS

Language:
ISO 9001:2015