Author: Todd Slack- Business development | Strategic and product marketing | Automotive and Commercial Safety CI | Microchip Technology
When I tell people that I work in the semiconductor business and that I do automotive security, they often assume it is car alarms and key fobs. Although car theft remains a legitimate concern, there are far greater security threats associated with internal electronic control units (ECUs) and their communications within the vehicle and with the outside world. Approximately 50% of all new vehicles sold this year will be connected vehicles and many estimate that 95% will be by 2030. These connections via Bluetooth®, USB, LTE, 5G, Wi-Fi®, etc. , bring a lot of convenience to the consumer, but hackers are also excited about the growing attack area. A quick Google search on the topic of vehicle hacking will turn up a myriad of real-world security flaws that have led to costly recalls, lawsuits, and a damaged brand reputation. It's a fact: software can be prone to bugs, and bugs are targeted by hackers. There are many things that can be done to minimize errors and take corrective action once detected; however, as humans write new code, new bugs may be introduced.
Gaining access to the vehicle's control area network (CAN bus) is a common target for hackers. Attacks have been made that allowed hackers to exploit a bug in Bluetooth that allowed them to find a bug in the vehicle's operating system that then 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 bus. The CAN bus has several advantages. It uses a simple protocol that is cheap, extremely robust, and relatively immune to electrical disturbances, making it a reliable option for safety-critical nodes to communicate with each other. The downside is that, for decades, the security of the protocol has been zero, meaning that once a hacker gains access, they can send bogus messages that can wreak havoc with in-vehicle communications. Some examples are turning the windshield wipers on or off, turning off the headlights, distracting the driver by manipulating the audio, creating false alarms in the instrument cluster, displaying incorrect speed, moving the seats or even leaving the car off the road. The good news is that with the advent of CAN FD there are additional bytes available in the message payload to add security by including a Message Authentication Code (MAC) to cryptographically verify the authenticity of the message, thus filtering out any forged messages. . There are two types of MAC to choose from: a hash-based HMAC or an AES symmetric key-based CMAC. The CMAC is implemented in the vast majority of the time.
OEMs have been very busy updating their cybersecurity specifications in response to all the hacks that have taken place. Almost all OEMs are requiring safety-critical ECUs to be upgraded to implement their new cybersecurity requirements and some OEMs are requiring 100% of connected ECUs to be upgraded. The fundamental security building block is the implementation of Secure Boot, which involves cryptographic verification that boot and application code running on a host controller has not been modified and is in a trusted state at power on, reboot and often repeat in a prescribed cadence once ripped. Second is the requirement to support secure firmware updates. Remember that all software can be subject to errors; therefore, it is often necessary to create firmware bug patches that can be applied in the field. These firmware updates also require cryptographic security implementations that typically require incoming firmware payloads to be encrypted with a symmetric key (AES) and signed with an asymmetric private key, most often elliptic curve cryptography (ECC). Thus, when an update image is presented to the host controller, no action is taken until the payload signature is verified by the ECC public key embedded in the controller. Once the signature is verified, the image can be decrypted and the controller firmware updated with the bug patch or feature enhancement. The third addition to the evolution of security is message authentication, as described above.
The need to authenticate batteries is unique in the electric vehicle industry. Most battery packs are designed with replaceable battery modules within the larger pack so that when one module fails it can be replaced without having to replace the entire pack or deal with an underperforming pack. Poorly designed modules can pose a safety risk and cause a vehicle fire; Therefore, it is important that OEMs apply ecosystem management, which means that each module must be cryptographically authenticated to verify that the module's manufacturing has been vetted and approved by the manufacturer before it is allowed to function within the pack. . A module that doesn't start fires, but rather underperforms, can damage the reputation of the OEM brand, which can lead to negative press sentiment and lost revenue. Yet another reason to cryptographically verify the provenance of the module manufacturer.
What does it mean to cryptographically verify a module? This is achieved by configuring customer-specific signing keys that are used to provision devices with customer-specific x.509 certificate chains and a unique device-level certificate based on a unique ECC key pair. 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 back to a root of confidence. After verification of the signature, the module is presented with a challenge to sign it with the associated private key, proving knowledge of a secret without transmitting it on the bus, in some cases transmitted by RF. The module-level use case stops there. Within the BMS, OEMs often require a more complex use case. Since the BMS/Gateway is the communication point with the outside world that provides routine battery status reports to the cloud, the security use case is extended to include secure boot, secure firmware upgrade, and Transport Layer Security (TLS) to establish a secure communication channel with the cloud.
All security implementations discussed require secure key storage, which can only be achieved with true hardware-based security. It can be easy to extract the keys from standard microcontrollers and even many that claim to be "secure microcontrollers" by performing some standard attacks via microprobing, fault injection, electromagnetic side channel attacks, temperature/power/ supply jamming and timing attacks, to name a few. It is important to select the right device to perform the cryptographic work and protect the keys against these types of attacks. Specialized security devices come in a variety of architectures and are referred to by different terms, such as hardware security modules (HSMs), both onboard and external, secure elements, secure storage subsystems, key vaults, smart cards , etc. These devices must include protections against the aforementioned attacks to protect the keys in their secure memory.
But how can a Tier XNUMX vendor or OEM verify that the security in place is good enough? The best way for a secure element provider to demonstrate that its security is sufficient is to submit the device to a third party for vulnerability assessment. The third party must be accredited by a trusted source, such as NIST (National Institute for Technology Standards), recognized in North America, BSI (Federal Office for Information Security) in Germany, or SOGIS (Senior Security Officers Group). of Information Systems), recognized worldwide. SOGIS accredited labs use a globally recognized vulnerability assessment scoring system by the JIL (Joint Interpretation Library) which requires a “white box” assessment, which means that the IC vendor must provide the lab with documentation on device layout (data flow, subsystem, memory map definition), hardware and firmware boot sequence, description of security protection mechanisms, full data sheet, guidance documentation on security and bootloader, all available code (RTL and C level, crypto library, FW), algorithm implementations, programming scripts, communication protocol, chip design and source code. The lab then reviews all documentation and maps out its plan of attack against the submitted sample devices. The scoring system assigns points based on the time it takes to extract a secret key, the level of experience required (from a recent university graduate to multiple experts), knowledge of the objective of the assessment (TOE), access to the TOE (how many sample devices to perform a successful attack), the complexity and cost of the hacking team, and the ease of access to the samples.
The resulting JIL scores start with no rating, then Basic, Enhanced Basic, Moderate, and High, which is the best possible score. Anything below JIL High means that the lab was able to extract the private key(s) from the device. Devices such as Microchip's CryptoAutomotive™ TrustAnchor100 (TA100) external HSM that have received a JIL High score, are capable of withstanding attacks for more than 3 months of attack, at which time the lab declares the device "Not Practical" for attack.
The question is whether it is an "on-die" or "off-die" device. On-die solutions, such as 32-bit dual-core MCUs, can be an expensive upgrade from a previous generation ECU that could have been well served by a standard MCU before true security was mandated by an OEM. They can also introduce significant time-to-market delays due to the need to completely redesign application code. It can be very risky to undertake security code development in-house and the cost of paying a third party can be prohibitive. It is also difficult for a Tier 100 vendor to proliferate the solution across multiple types of ECUs, given the different performance and peripheral requirements of each type. This is where external HMS or add-on secure elements can significantly reduce the security update burden for Tier XNUMX vendors. They can be added alongside a standard MCU in an existing design or bolted to all new designs with different host MCU requirements. External HSMs, like the TAXNUMX, come pre-provisioned with all security codes, keys, and certificates, dramatically reducing time to market. It is easily portable to any MCU given the associated cryptolibrary that is MCU agnostic. Risk, time to market and overall cost are reduced, giving Tier XNUMX providers an agile path to business before their competition, which is following a completely redesigned path.
With today's connected cars and intense in-vehicle network communications traffic, the need for in-car security clearly expands beyond car alarms. With security and brand reputation at stake, it is more important than ever to select truly secure devices that have been third-party vetted when updating ECUs to meet the multitude of new OEM cybersecurity specifications, SAE and ISO standards and the security mandates of regional governments.
