Abstracting the HSM: portable security for the bootloader

Cyber-security demands on automotive software keep rising. Software-defined vehicles and over-the-air updates to electronic control units (ECUs) mean more code, delivered more often, to more places — and every update has to be proven authentic and intact before it is allowed to run. That raises the demands on the hardware underneath the software.

At Diadrom we work extensively with the bootloaders that carry those software updates. Much of the effort goes into verifying both the authenticity and the integrity of the data to be loaded, and those checks are computationally heavy. Run synchronously on a single-core microcontroller (MCU), they can block other tasks for a long time.

To make encryption, decryption, authentication and key handling both faster and safer, that work is increasingly offloaded to a Hardware Security Module (HSM) — a dedicated unit isolated from the rest of the execution. For performance and security it is the right answer. But it introduces a portability problem.

The way software talks to an HSM can be implemented in several ways, and the exact interface is hard to plan for in advance: the specifications come from the MCU vendor and are typically protected by non-disclosure agreements. For some HSMs you start asynchronous cryptographic jobs and poll for the result; others are interrupt-driven. Build a bootloader directly against one vendor's quirks and you have tied yourself to that silicon.

The established way to handle a hardware dependency whose interface may change is to separate the functionality from the hardware behind a hardware abstraction layer (HAL). With a HAL in place, the implementation of the functionality does not have to change when the underlying hardware does — and the same discipline applies cleanly to the HSM interface.

Behind a generic interface to the HSM, the higher layers of the application no longer need to know any single vendor's specifics. Whether a given HSM polls an asynchronous job or fires an interrupt, the result is returned in a common form — so the developers writing the security logic above it are insulated from the hardware underneath.

Three things follow. The implementation becomes easier to unit test, because it is written against a generic interface rather than a specific chip. It becomes more portable, because switching HSM — or silicon vendor — no longer means rewriting the security logic. And it becomes more resilient: in years when semiconductor availability has forced platforms to change chips at short notice, separating the HSM interface from the implementation makes that move far less costly.

At Diadrom we have implemented exactly this strategy — a HAL towards the HSM in our bootloader. It cuts the time it takes us to adapt the bootloader to a new customer and hardware platform, and it keeps code quality high through re-use. For hardware-accelerated cyber-security in the software-defined vehicle, it is the approach we would recommend going forward.