While auto theft remains a legitimate concern, the security threat associated with internal electronic control units (ECUs) and their communications inside and outside the vehicle is significantly greater. About 50 percent of all new cars sold this year will be connected, and many estimate that number will be around 95 percent by 2030. These connections, implemented via Bluetooth, USB, LTE, 5G, and Wi-Fi, offer many consumer benefits, but hackers are equally excited by the dramatic increase in the number of attack surfaces. A quick Google search on the subject of hacked cars will yield countless actual security flaws that lead to costly recalls, lawsuits and brand damage. In fact, software is prone to vulnerabilities that can be exploited by hackers. There are many things you can do to minimize vulnerabilities and take corrective action when they are detected; But whenever people write new code, they introduce new vulnerabilities.
Hacking into the car controller LAN (CAN bus) is a common target of hackers. In previous attacks, hackers were able to remotely tamper with messages via the CAN bus by exploiting vulnerabilities in Bluetooth and then in the car's operating system. Modern cars may have as many as 100 ECUs, many of which are safety-critical and communicate over a bus. The CAN bus has many advantages. It uses a simple protocol that is low cost, extremely robust and relatively immune to electronic interference, so it is a reliable choice for security critical nodes to communicate with each other. The downside is that, for decades, the protocol has been without any security measures, meaning that if hackers succeed, they can send fake messages that can wreak havoc on onboard communications.
For example, turning wipers on and off, turning headlights off, distracting drivers by manipulating audio, generating false dashboard alarms, displaying the wrong speed, moving seats and even pulling the car off the road. The good news is that with the advent of CAN FD, additional bytes are reserved in the packet payload to store the packet validation code (MAC), which can be used to encrypt the authenticity of the packet and filter out all forged packets, thus improving security. There are two MACS to choose from: HMACs based on hash algorithms or CMACs based on AES symmetric key block ciphers. In most cases, the implementation is CMAC.
Oems have been busy updating their network security specifications to deal with all the hacks that occur. Almost all Oems need to upgrade safety-critical ECUs to meet their new network security requirements, and some of them need to upgrade all networked ECUs. The underlying security module is used to implement secure booting involving cryptographic validation: the boot and application code running on the host controller remains unchanged, is in a trusted state when powered on and reset, and is usually repeated at a specified frequency after booting. A close second requirement was support for security firmware updates. To review, all software creates bugs; Therefore, it is often necessary to create firmware vulnerability patches that can be applied in the field. In addition, these firmware updates also require cryptographic security implementations, which typically require encrypting the incoming firmware payload with a symmetric (AES) key and signing it with an asymmetric private key, the most common of which is elliptic curve encryption (ECC). This way, when the upgrade image is provided to the host controller, nothing is done until the signature of the payload is verified by the ECC public key embedded in the controller. After signature verification is complete, the image can be decrypted and the controller firmware upgraded with a vulnerability patch or feature enhancement. The third addition to the security evolution is the message validation described above.
What is unique in the EV space is the increasing demand for battery verification. Most battery strings have a replaceable battery module inside the larger battery string. Therefore, if one of the battery strings fails, you only need to replace the faulty module. You do not need to replace the entire battery string or deal with the battery string with poor performance. Poorly designed modules can become safety hazards and cause vehicle fires; As a result, Oems must strengthen ecosystem management, which means that each module must be validated in an encrypted manner to ensure that the module manufacturing is reviewed for OEM certification before the module can function properly in the battery pack. Modules that do not cause fires but do not perform well can damage the OEM brand reputation, resulting in bad press and lost revenue. This is another reason to encrypt the source of the module manufacturer.
What does it mean to encrypt a module? Encryption verification is implemented by using customer-specific x.509 certificate chains and a unique device-level certificate based on a unique ECC key pair to set the customer-specific signature key used to configure the device. 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, asks the module for its unique X.509 certificate and validates the signature chain all the way to the trusted root. Once signature verification is complete, a module signing with the relevant private key faces the challenge of proving knowledge of confidential information without sending it over the bus (in some cases via RF). So much for the module-level use cases. Within BMS, Oems often require more complex use cases. Because the BMS/ gateway is the communication point to the outside world to provide routine battery health reports to the cloud, the security use case expands to include secure booting, secure firmware updates, and Transport layer security (TLS) to establish a secure communication channel with the cloud.
All of the security implementations discussed here require a secure key store, and such storage can only be implemented with true hardware security. By performing standard attacks such as microprobes, fault injection, electromagnetic side channel attacks, temperature/cycle power-on/power burr, and timing attacks, it is easy to extract keys from standard microchips and even many so-called "secure microchips". Therefore, it is very important to choose the right device to perform the encryption task and prevent the key from being subjected to such attacks. Dedicated security devices offer a variety of architectures and are referred to in different terms, such as on-chip and external hardware security modules (HSM), security components, secure storage subsystems, key stores, and smart cards. These devices must contain tamper-proof features against such attacks to protect the keys in their secure memory.
But how does a tier 1 vendor or OEM verify that the security implemented is good enough? The best way for a security component supplier to prove its security value is to submit the device to a third party for vulnerability assessment. The third party should be certified by a credible organization such as the National Institute of Standards and Technology (NIST) in North America, the Federal Information Security Agency (BSI) in Germany, or the High Official Cooperation Organization for Information System Security (SOGIS) in the world. SOGIS accredited laboratories use the globally recognized Joint Analytic Library (JIL) vulnerability scoring system, which requires a "white box" assessment, That is, the supplier submitting the IC must provide relevant device design (data flow, subsystem and memory map definition), hardware and firmware boot sequence, security protection mechanism description, complete data manual, security and bootloader guidance documentation, all available code (RTL and level C, encryption library and firmware), algorithm implementation, programming scripts, communication protocols, chip layout, and source generation Code for laboratory documentation. The lab will then review all the documentation to develop a plan of attack against the submitted samples. The scoring system assigns points based on how long it takes to extract the secret information key, the level of expertise required (from recent graduates to specialists), knowledge of the subject of the assessment (TOE), access to the TOE (the number of samples needed to execute a successful attack), the sophistication and cost of the hacking device, and the ease of accessing the samples. The resulting JIL score is in order of no rating, Basic, Enhanced Basic, Medium, and High, with High being the highest score that can be achieved. A JIL "high" rating below indicates that the laboratory is able to extract the private key from the device. Devices such as Microchip CryptoAutomotive™ TrustAnchor100 (TA100) external HSM, which received a "high" rating from JIL, can withstand attacks for more than three months, after which the lab will declare the device "invalid."
On - or off-camera, that's the question. It was costly to upgrade the previous generation of ECUs with on-chip solutions such as 32-bit dual-core MCUS, which were fully met by standard MCUS before Oems required true security. These on-chip solutions can also significantly delay time to market if the application code is required to be completely rebuilt. Developing secure code in-house is extremely risky and handing it over to a third party is expensive. It is also difficult for tier 1 vendors to apply such solutions in large numbers to multiple types of ECUs, as each type has different performance and peripheral requirements. In this context, external HMS or accompanying security components can help tier 1 vendors greatly reduce the burden of security upgrades. They can be added next to a standard MCU in an existing design or integrated into all new designs with different host MCU requirements. External HSMS such as TA100 are pre-configured with full security codes, keys, and certificates to significantly reduce time to market. Given a related encryption library independent of the MCU, it can be easily ported to any MCU. External HSMS reduce risk, shorten time to market, and reduce total costs, providing tier 1 vendors with a shortcut to commercial success ahead of their complete refactoring competitors.
Nowadays, many vehicles support networking functions and vehicle network traffic is large, so the demand for vehicle security is obviously far more than vehicle alarm. Because security and brand reputation are not compromised, when upgrading ECUs, be sure to select authentic security devices that have been reviewed by third parties to meet the many new OEM network security specifications, SAE, ISO standards, and local government security requirements.
