In the future, V2I (vehicle to infrastructure) and V2V (vehicle to vehicle) communication will be combined with V2X (vehicle to everything) – a billion dollar market that is also is capturing the attention of customers. One goal of V2X communication is to reduce the number of accidents by exchanging information. Based on an analysis of traffic accidents between 2004 and 2008, the US Department of Transportation (USDOT) found that V2X systems can prevent 4,5 million accidents, or 81% of the total. total.
Threat
V2X has not enjoyed much popularity so far. One reason for this is that there is a negative perception around the security of V2X communication. The greatest possible threat is found in cyberattacks. If the vehicle's computer system or mobile phone is hacked, it can cause damage to the vehicle and even put human lives at risk if it is driving at the time. In 2015, two security researchers remotely hacked into the CAN bus of a Jeep Cherokee, thus gaining control of the car; they used a "weak spot" in the Linux-based infotainment system. A year later, these two professionals were once again able to drive a Jeep Cherokee through a portable computer (laptop) connected to the vehicle's OBD port. When the CAN protocol was developed several decades ago, security was not an issue. Therefore, CAN does not guarantee the confidentiality of the data and the signals are transferred in broadcast mode.
Today's vehicles exchange messages via the CAN bus to, for example, open the doors and start the engine. These messages are produced between a control unit (ECU) inside the car and an electronic key. If this system is violated, a thief could easily steal the car. In addition, wireless communication standards such as Bluetooth, GPRS, or UMTS for mobile internet functions, including email, SMS, video streaming, and video calls, offer hackers a greater number of "targets." Here they could not only take control of the vehicle, but also install malicious software with the intention of stealing data such as car location and most frequent routes, as well as complete calls remotely. Since the so-called T-BOX (Telematics Control Unit – Telematics Control Unit) is now responsible for all the aforementioned communication functions, the focus is on security.
Solution
What features should a hardware architecture have to ensure that the ECU meets the highest security requirements and is protected from sabotage, unauthorized installation, malware downloads, Trojans and fake updates? Data encryption is an effective way to ensure the integrity, availability and confidentiality of data on the internal vehicle network communication bus. Thus, cryptographic methods can prevent cyberattacks. In recent years, various lobby groups have been created to propose guidelines for designing and testing systems that can withstand hacker attacks and tampering attempts. A good example is the EVITA research project, funded by the European Union (EU), in which companies such as BMW, Continental, Fujitsu, Infineon and Bosch have been involved. EVITA came up with numerous guidelines that describe in detail the design, verification and prototyping of various security architectures for control units – ECUs – on board the car. Furthermore, it stipulates that all critical ECUs be equipped with a chip that contains not only a hardware security module (HSM), but also the CPU, where three different requirement profiles have been defined for the HSM: full, medium and Light.
These modules encrypt and decrypt all information exchange between the ECUs. Based on the EVITA standard, a growing number of semiconductor manufacturers are implementing what is known as a “safe zone” (also referred to as a “trust anchor”) in their microcontrollers / microprocessors. For example, STMicroelectronics has integrated HSMs into both its SPC5 family of microcontrollers (MCUs) based on a power supply architecture and ARM core processors, such as the STA1385 Telematics Control Unit (TCU). These integrated circuits with HSM offer complete protection against cyber attacks. The HSM is an isolated subsystem with its own secured processor core, RAM, and Flash memory (code and data). Additionally, HSMs contain hardware accelerators for cryptography. In ST, this is the C3 cryptographic accelerator, which also has a true random number generator (TRNG).
Data requests and interrupts are exchanged between the HSM and the application processor via a hardware interface. The HSM not only assumes access control, but also generates real random numbers for encryption keys and performs all other encryption functions thanks to the built-in TRNG. As mentioned above, the CAN bus does not provide a high level of security and therefore cannot guarantee the confidentiality and integrity of the data transmitted. However, with the data encrypted, it can be used in a secure transfer. Symmetric and asymmetric encryption algorithms with HASH, MAC (message authentication code) or CMAC functions enable confidentiality, integrity and availability, as well as digital signature and authentication of data. All encoding and decoding functions are implemented in hardware to ensure that the host CPU is not overloaded.
typical application
Secure boot
The secure boot function validates the integrity of the boot loader. To do this, the MCU's HSM first loads the Flash boot loader via the master bus. Using an agreed secret key, the HSM can calculate a MAC (message authentication code) for the received message; if the calculated MAC matches the stored boot MAC, data integrity is ensured and the MCU can use the boot loader.
secure communication
The HSM also supports secure communication. The following example shows how this occurs: a central ECU communicates with a sensor ECU. As already explained, each HSM has a TRNG and a hardware encryption engine. The central ECU generates a random number and sends it to the sensor ECU. The sensor receives that number, measures its data in parallel, and activates its own HSM to encrypt the measured data with the ECU's random number. The sensor ECU returns the encrypted data to the central ECU, which decrypts the data using its own random number. The transferred random number is then compared with the received one to verify the integrity and authenticity of the data. The TRNG protects against replay attacks (reproduction) and performs encryption against possible eavesdropping.
Flash memory protection
Since firmware and security settings such as passwords and keys are stored in the controller's Flash memory, protecting them is also essential. ST SPC5 MCUs, for example, have two modules that are solely responsible for saving memory: TDM forces software to write a set of data to a specific Flash area before one or more blocks can be deleted in a TDR (tamper detection region – sabotage detection region). The PASS module, on the other hand, performs a password match before the Flash can be written or erased.
System security settings
To ensure that the system boot proceeds safely after a reboot, all stored Device Configuration Formats (DFCs) are checked for integrity prior to rebooting, and accordingly prevent unauthorized interventions and changes. In addition, it is possible to check various security functions. Thus, any attempt to modify content in specific places can be stopped using different attack methods or loading malicious firmware during reboot.
Conclusion
In-vehicle Information Technology (IT) security measures are essential, and therefore the use of state-of-the-art innovative semiconductors with integrated HSM helps improve security and increase efficiency in implementation.
