Of all new cars sold this year, approximately 50% support connectivity, and many estimate that this figure will reach around 95% by 2030. These connections, via Bluetooth®, USB, LTE, 5G, and Wi-Fi®, offer consumers numerous conveniences, but hackers are equally excited due to the significantly increased attack surface. A quick Google search for "hacking cars" reveals countless real-world security vulnerabilities that lead to costly recalls, lawsuits, and damage to brand reputation. Indeed, software is prone to vulnerabilities, which hackers can exploit. While vulnerabilities can be minimized and corrected after detection, new vulnerabilities are introduced every time new code is written.
Hacking into a car's Controller Area Network (CAN bus) is a common target for hackers. In previous attacks, hackers have been able to exploit vulnerabilities in Bluetooth and the car's operating system to remotely tamper with messages via the CAN bus. Modern cars may have up to 100 ECUs, many of which are safety-critical and communicate via the bus. The CAN bus has many advantages. It uses a low-cost, extremely robust, and relatively resistant to electronic interference, making it a reliable choice for communication between safety-critical nodes. The downside is that for decades, this protocol has lacked any security measures, meaning that once hackers successfully infiltrate it, they can send forged messages, severely disrupting in-vehicle communications. Examples include turning windshield wipers on/off, turning off headlights, distracting the driver by manipulating audio, generating false dashboard warnings, displaying incorrect speeds, moving seats, or even driving the car off the road. The good news is that with the advent of CAN FD, extra bytes are reserved in the message payload to store a Message Authentication Code (MAC), which can be used to cryptographically verify the authenticity of messages, filtering out all forged messages and thus improving security. There are two MAC options available: HMAC based on a hash algorithm or CMAC based on the AES symmetric key block cipher. In most cases, CMAC is implemented.
OEMs are constantly updating their cybersecurity specifications to address any potential hacking attacks. Almost all OEMs need to upgrade safety-critical ECUs to meet their new cybersecurity requirements, with some requiring upgrades to all networked ECUs. A basic security module is used to implement secure booting involving cryptographic verification: the boot and application code running on the host controller remains unchanged, is in a trusted state upon power-on and reset, and typically repeats execution at a prescribed frequency after boot. A next requirement is support for secure firmware updates. Recall that all software is susceptible to vulnerabilities; therefore, it is often necessary to create field-applicable firmware patches. Furthermore, these firmware updates require cryptographic security implementations, which typically involve encrypting the incoming firmware payload using a symmetric (AES) key and signing it with an asymmetric private key, most commonly elliptic curve cryptography (ECC). This way, when an upgrade image is provided to the host controller, no action is taken until the signature of the payload is verified using the ECC public key embedded in the controller. Once signature verification is complete, the image is decrypted, and the controller firmware is upgraded with the patch or feature enhancement. A third measure added to this security evolution is the aforementioned message verification.
What's unique about the electric vehicle sector is the ever-increasing demand for battery verification. Most battery packs incorporate replaceable modules within a larger assembly, so when one module fails, only the faulty module needs to be replaced, rather than the entire battery pack or the poorly performing module. Poorly designed modules can pose a safety hazard, potentially causing vehicle fires; therefore, OEMs must strengthen ecosystem management, meaning each module must be cryptographically verified to ensure its manufacturing process is vetted and approved by the OEM before it can function properly in the battery pack. A substandard module, even if it doesn't cause a fire, can damage an OEM's brand reputation, leading to negative publicity and lost revenue. This is another reason for cryptographically verifying the origin of module manufacturers.
What does cryptographic verification of a module mean? Cryptographic verification is implemented using a customer-specific x.509 certificate chain and a unique device-level certificate set based on a unique ECC key pair to configure the device with a customer-specific signing key. The configured device is installed on each battery module. When a battery module is replaced in the battery pack, the Battery Management System (BMS) (also known as the battery gateway) queries the module for its unique X.509 certificate and verifies the signature chain all the way to the root of trust. After signature verification is complete, the module that signed with the associated private key faces the challenge of proving that it has access to confidential information without transmitting it over the bus (in some cases, via RF). This concludes the module-level use case. Within the BMS, OEMs typically require more complex use cases. Since the BMS/gateway is the communication point connecting to the outside world and providing routine battery health reports to the cloud, security use cases extend to include secure boot, secure firmware updates, and Transport Layer Security (TLS) to establish secure communication channels with the cloud.
All the security implementations discussed here require secure key storage, which can only be achieved through true hardware security. Keys can be easily extracted from standard microcontrollers, and even many so-called "secure microcontrollers," by performing standard attacks such as microprobing, fault injection, electromagnetic side-channel attacks, temperature/cycle power-on/power glitches, and timing attacks. Therefore, selecting appropriate devices to perform the encryption task and prevent keys from being subjected to such attacks is crucial. Dedicated security devices offer various architectures and are referred to by different terms, such as on-chip and external hardware security modules (HSMs), secure elements, secure storage subsystems, keystores, and smart cards. These devices must include tamper-proof features against the aforementioned attacks to protect the keys in their secure memory.
However, how can Tier 1 suppliers or OEMs verify that the implemented security is sufficiently robust? The best way for secure element suppliers to demonstrate their security value is to submit their devices to a third party for vulnerability assessment. The third party should be certified by a trusted organization such as the National Institute of Standards and Technology (NIST) in North America, the Federal Office for Information Security (BSI) in Germany, or the globally recognized Organization for Advanced Official Cooperation on Information Systems Security (SOGIS). SOGIS-accredited labs use the globally recognized Joint Interpreter Library (JIL) vulnerability scoring system. This system requires a "white-box" assessment, meaning that the supplier submitting the IC must provide lab documentation regarding the device design (dataflow, subsystem, and memory mapping definitions), hardware and firmware boot sequences, security protection mechanism descriptions, a complete datasheet, security and bootstrapping guide documentation, all available code (RTL and C-level, cryptographic libraries and firmware), algorithm implementations, programming scripts, communication protocols, chip layout, and source code. The lab will then review all documentation and develop an attack plan against the submitted sample. The scoring system assigns scores based on the time taken to extract the confidential information key, the required level of expertise (from recent graduates to experts), understanding of the Test Object (TOE), access to the TOE (number of samples required for a successful attack), the complexity and cost of hacking the device, and the ease of accessing the samples. The resulting JIL scores are ranked as follows: No rating, "Basic," "Enhanced Basic," "Medium," and "High," with "High" being the highest achievable score. A JIL "High" rating indicates that the lab can extract the private key from the device. Devices such as the Microchip CryptoAutomotive™ TrustAnchor100 (TA100) external HSM that receive a JIL "High" rating can withstand attacks for more than 3 months; after this period, the lab will declare the attack on the device "invalid."
On-chip or off-chip, that is the question. Upgrading previous-generation ECUs with on-chip solutions like 32-bit dual-core MCUs is costly, while standard MCUs can fully meet the requirements of previous-generation ECUs until OEMs demand true security. These on-chip solutions also significantly delay time-to-market if a complete rebuild of the application code is required. Developing security code internally carries extremely high risks, while outsourcing to third parties is expensive. Furthermore, Tier 1 vendors struggle to scale such solutions across multiple ECU types, each with different performance and peripheral requirements. In this context, external HSMs or complementary security elements can significantly reduce the burden of security upgrades for Tier 1 vendors. They can be added alongside standard MCUs in existing designs or integrated into all new designs with different host MCU requirements. External HSMs like the TA100 come pre-configured with all security code, keys, and certificates, significantly shortening time-to-market. With a relevant cryptographic library independent of the MCU, they can be easily ported to any MCU. External HSMs reduce risk, shorten time-to-market, and lower overall costs, providing Tier 1 vendors with a shortcut to commercial success that puts them ahead of competitors offering completely refactored solutions.
With many modern vehicles supporting connectivity and experiencing high volumes of in-vehicle network communication, the demand for vehicle security far exceeds that for vehicle alarms. Because safety and brand reputation are paramount, when upgrading your ECU, always choose genuinely safe components that have undergone third-party review to meet numerous new OEM cybersecurity specifications, SAE, ISO standards, and local government security requirements.
