Hardware security modules help thwart hackers bent on getting control of EVs.

Todd Slack • Microchip Technology
Roughly half of all new vehicles sold this year will be connected vehicles, and estimates are that figure will rise to around 95% by 2030. Those connections via Bluetooth, USB, LTE, 5G, Wi-Fi, and so forth have dramatically increased the attack surface that must be secured against hackers.

The vehicle Controller Area Network (CAN bus) is a common target for hackers. Demonstrations have shown that hackers can exploit a bug in the Bluetooth protocol to gain access to the vehicle operating system. This attack vector, in turn, provided remote access to manipulate messages on the CAN bus.

Modern vehicles can have up to 100 ECUs with many safety critical ECUs communicating on the CAN bus. The CAN bus uses a simple protocol that is inexpensive, extremely robust, and relatively immune to electric disturbance which makes for reliable communication among safety critical nodes. The downside is that for decades, there has been zero security in the protocol. Hackers who gain access can send spoofed messages and wreak havoc on in-vehicle communications. Some examples include engaging or disengaging windshield wipers, turning off headlights, distracting the driver by manipulating audio, creating false instrument cluster alarms, incorrectly displaying speed, moving seats, or even driving the car off the road.

The good news is that with the advent of CAN FD (FD stands for flexible data rate, specified in ISO 11898-1) there are additional bytes available in the message payload to add security. CAN FD includes a Message Authentication Code (MAC) to cryptographically verify the authenticity of the message, thereby filtering out any spoofed messages. There are two types of MACs to choose from: A hash-based HMAC or an AES symmetric key block cypher based CMAC. CMAC is implemented the overwhelming majority of the time.

OEMs have been busy updating their cybersecurity specifications in response to the numerous hacks. Almost all OEMs now require safety critical ECUs to implement new cybersecurity requirements, and some OEMs require that 100% of connected ECUs be upgraded.

The foundational security block is to implement secure boot. Secure boot involves cryptographic verification that the boot and application code is unchanged and is in a trusted state at power-on. And verification is often repeated at a prescribed cadence once booted.

A close second in security procedures is the requirement to support secure firmware updates. Of course, all software can be subject to bugs; so firmware bug patches that can be applied in the field are often a necessity. These firmware updates also require cryptographic security. Typically incoming firmware payloads encrypted with a symmetric (AES) key and signed with an asymmetric private key, most often Elliptic Curve Cryptography (ECC). (As a brief review, with a symmetric key, the same key is used to encrypt and decrypt the message. With asymmetric keys, two different keys, called the public and private keys, are used. ECC is based on the algebraic structure of elliptic curves over finite fields and allows use of smaller keys compared to non-EC cryptography.)

The third addition in security evolution is message authentication. When an encrypted image is presented to the host controller, no action is taken until the signature of the payload is verified by the public ECC key embedded in the controller. Once the signature is verified, the image can be decrypted and the controller firmware upgraded with the bug patch or feature enhancement.

AES basics

The Advanced Encryption Standard is a symmetric block cipher. A block cipher is a deterministic algorithm operating on fixed-length groups of bits called blocks. AES actually includes three block ciphers: AES-128, AES-192 and AES-256. The numbers denote the number of bits in the key used to encrypt and decrypt a block of messages. Thus each cipher encrypts and decrypts data in blocks of 128 bits using cryptographic keys of 128, 192 and 256 bits, respectively.

The first step of AES encryption is to put the data into an array. Then the cipher transformations are repeated over multiple encryption rounds. A round consists of several processing steps that include substitution, transposition and mixing of the input plaintext to transform it into the final output of ciphertext. There are 10 rounds for 128-bit keys, 12 rounds for 192-bit keys and 14 rounds for 256-bit keys.

The first transformation in the AES encryption cipher is substitution of data using a substitution table; the second transformation shifts data rows, and the third mixes columns. The last transformation takes place on each column using a different part of the encryption key. Longer keys need more rounds to complete.

EV security

Unique to the electric vehicle space is the growing need for battery authentication. Most battery packs are comprised of replaceable battery modules so a module that fails can be replaced without replacing the entire pack. Poorly designed modules can be safety hazards that cause vehicle fires. Thus ecosystem management is important; each module must be cryptographically authenticated. Authentication verifies each module manufacturer has been vetted and approved by the OEM. Similarly, a module that does not cause fires but instead under-performs is equally bad. Poor performance can damage brand reputations, yet another reason to cryptographically verify who manufactured the module.

You might wonder what it means to cryptographically verify a battery module. The process is accomplished by setting up customer-specific signing keys. The keys are used to provision devices with customer-specific x.509 certificate chains and a unique device-level certificate based upon a unique ECC key pair. (An X. 509 certificate is a digital certificate employing the international X. 509 public key infrastructure (PKI) standard to verify that a public key belongs to the entity contained within the certificate.)

The provisioned device is mounted on each battery module. When a battery module is replaced within the pack the battery management system (BMS), also known as the battery gateway, will query the module for its unique X.509 certificate and verify the signature chains up to a trusted root.

After signature verification, the module is challenged with the task of signing the associated private key. Successful completion proves knowledge of a secret without transmitting it on the bus or via RF. The use case at the module level stops there.

Within the BMS, OEMs often require a more complex use case. The BMS/gateway is the communication point to the outside world providing routine battery health status reports to the cloud. So security for communication channel with the cloud may be expanded to include secure boot, secure firmware update, and Transport Layer Security (TLS, a standard protocol providing authentication, privacy and data integrity between two communicating computer applications).

The security implementations discussed here require secure key storage which can only happen via true hardware-based security. It can be easy to extract keys from standard microcontrollers, and even from many claiming to be “secure microcontrollers,” via standard attacks through micro-probing (attaching microscopic needles on the internal wiring of a chip), fault injection (by creating voltage glitches, clock glitches, injecting a temporal fault during a cryptographic operation with a laser module, etc.), electromagnetic side channel attacks (performing signal analysis on the electromagnetic radiation the device emits) , temperature/power cycling/supply glitching, and timing attacks, to name a few.

It is important to select the right device for cryptographic heavy lifting and to protect the keys against these sorts of attacks. Specialized security devices come in a variety of architectures. They have varying terminology like Hardware Security Modules (HSM) both on-die and external, secure elements, secure storage subsystems, key vault, smartcards, etc. All these devices must include tamper protection against the aforementioned attacks to prevent access to the keys in their secure memory.

When is security good enough?

The best way to prove security worthiness is to submit the secure device to a third-party for a vulnerability assessment. The third-party should be accredited by a trustworthy source like the National Institute of Standards of Technology (NIST) recognized in North America, the Federal Office for Information Security (BSI) in Germany, or the globally recognized Senior Officials Group Information Systems Security (SOGIS).

SOGIS-accredited labs use a globally recognized Joint Interpretation Library (JIL) vulnerability assessment scoring system which requires a “white box” assessment. The submitting IC vendor must provide the lab documentation on the device design. The documentation includes data-flow, sub-system, memory map definition, hardware and firmware start-up sequence, description of security protection mechanisms, full datasheet, security and bootloader guidance documentation, all code available (RTL and C level, crypto library, FW), algorithm implementations, programming scripts, communication protocol, die layout, and source code. The lab reviews all documentation and maps out a plan of attack against the submitted sample devices.

The scoring system allots points based on how long it takes to extract a secret key, the level of expertise required (recent college grad up to multiple experts), knowledge of the target of evaluation (TOE), access to the TOE (how many sample devices to perform a successful attack), hacking equipment complexity and cost, and ease of access to samples. JIL scores begin with no rating and progress to Basic, Enhanced Basic, Moderate, and High being the best achievable score. Anything below JIL High means the lab was able to extract private key(s) from the device.

Devices like Microchip’s CryptoAutomotive TrustAnchor100 (TA100) external HSM which have received a score of JIL High, are able to withstand attacks for more than three months of attack, at which point the lab declares the device “not practical” to attack.

On die or off die, that is the question. On-die solutions like 32-bit dual-core MCUs can represent an expensive upgrade to previous-generation ECU tasks perfectly well served by a standard MCU before true security became mandatory. Dual-core MCUs can also introduce significant development delays given the requirement to completely rearchitect the application code. It can be extremely risky to take on the security code development in-house and cost prohibitive to pay a third-party. It can also be difficult for Tier 1 suppliers to deploy the solution across multiple types of ECUs given that each type can have varying performance and peripheral requirements.

This is where external HSMs or companion secure elements can significantly reduce the security upgrade burden. They can be added to a standard MCU in an existing design or be bolted onto all new designs with different host MCU requirements. External HSMs like the TA100 come pre-provisioned with all security code, keys and certificates. External HSMs are easily portable to any MCU given the associated crypto-library that is MCU agnostic.

With today’s connected cars and heavy in-vehicle network communications traffic, the need for automotive security clearly stretches far beyond car alarms. With safety and brand reputation at stake, it is as important as ever to select truly secure devices vetted by third parties when upgrading ECUs to satisfy the plethora of new OEM cybersecurity specifications.

References
Microchip Technology, “Optimizing Cybersecurity in Your Autonomous Vehicle Designs”