09/22/2021
HSM firmware: Functional safety starts in the hardware security module
Microcontrollers and microprocessors with hardware security modules (HSM) are the state of the art in many of today’s automotive ECUs. This applies in particular to safety-critical components such as airbags, battery management systems, and steering and braking systems. Connected to the host controller as a separate hardware component, the hardware security module includes its own HSM processor, cryptographic functions, and dedicated memory for the hardware security firmware and for secure data. The HSM firmware adds additional security functions to the HSM hardware, bundling these functions into complex IT security protocols to support dedicated OEM use cases.
An underlying pre-emptive real-time operating system ensures optimized, priority-driven resource utilization even in a multi-core context. All functions are made available to the host application via an API interface, thus ensuring that the HSM stack can be integrated easily into a bootloader or into any AUTOSAR stack. The HSM core and HSM software form the trust anchor for the vehicle systems. The hardware security module becomes a kind of benchmark for checking authenticity and integrity – for example to validate software updates or messages within the in-vehicle network (secure onboard communication, SecOC).
Functionally safe, interference-free co-existence
While most of today’s automotive microcontrollers and microprocessors are equipped with hardware security modules, very few of these HSMs are actually designed for functional safety. In most cases, hardware design is not performed on the basis of an ISO 26262-compliant quality management process that covers possible systematic failures. This is hardly surprising considering that there are usually no safety goals assigned directly to the HSM itself, but it means that a generic functional safety approach for the HSM firmware is not a valid solution. Instead, safety-relevant ECUs require case-specific implementations in the HSM for the application embedded within them and for its functions, including protection against manipulation, commissioning, software updates, diagnostics, onboard communication, and many other functions.
What’s more, the default intended use of the HSM is in an integrated environment where it co-exists with software solutions that perform safety-relevant functions with safety goals up to ASIL D. For this reason, it is important to achieve “freedom from interference” according to ISO 26262. Using the hardware functions available on the chip to ring-fence the host driver and the shared resources – for example by using dedicated protection mechanisms or memory protection units (MPUs) – is not really an option here due to the possible negative impact on performance. On top of that, such hardware mechanisms might not even be available on the selected low-cost devices.
The solution to this problem is provided by qualified HSM firmware CycurHSM that includes a host driver developed according to the ASIL requirements specified in ISO 26262. This allows easy integration of the HSM into the vehicle ECU with no partitioning or memory protection – and hence no impact on performance. The HSM firmware is designed as a safety element out of context (SEooC) and can be integrated in a manner that reliably prevents interference between the HSM and the host core with its safety-relevant functions.
Reducing risk with “Safe CMAC”
As a general rule, a thorough security analysis is required to identify threats and vulnerabilities in the system and design appropriate countermeasures. By incorporating cybersecurity aspects into the functional safety assessment, an informed risk assessment can then be carried out from the perspective of functional safety and a safety integrity level (SIL) determined accordingly.
In order to additionally prevent the safety-critical impact of onboard communication potentially being corrupted despite existing security mechanisms, AUTOSAR specifies end-to-end (E2E) protection for exchanging safety-relevant data. The E2E concept detects and handles faults in the communication network during runtime on both the hardware and software side and is generally adequate for safety-compliant communication up to ASIL D. At the same time, there are new, smarter ways of system design implementation that complement the E2E approach while managing to avoid the overhead it causes. One such novel, complementary approach is “Safe CMAC,” which secures safety-critical messages using a cipher-based message authentication code (CMAC).
In this approach, the MAC authentication of the messages in the vehicle’s internal network is used by the hardware security module to detect corrupted messages, thereby ensuring functional safety. This requires correspondingly high-performance HSM firmware that allows for the integration of additional CMAC-based functional safety of the vehicle systems as and when required. This firmware can also support safety-relevant MAC verification in different ways – whether by means of a “false MAC self-test” up to ASIL B, or by means of a cyclic redundancy check (CRC) up to ASIL D.
Instrumentalizing the HSM for safety goals
Smart cost- and performance-optimized safety concepts could delegate functional-safety goals to the hardware security module. Even if the hardware used in the latest generation of devices already features enhanced safety mechanisms and performance, there will still be demand for cost-optimized system designs that offer ever higher performance. A pioneering solution in this context would seem to be to instrumentalize the cybersecurity mechanisms of the hardware security module by using intelligent HSM firmware CycurHSM for the functional safety of critical in-vehicle systems.
