connected car How to ensure security in the Connected Car
Modern vehicles have many functions with external interfaces that make traveling more pleasant. But these interfaces are also a gateway for attacks on the vehicle. Hardware-based security functions provide a remedy.
In the future, V2I (Vehicle to Infrastructure) and V2V (Vehicle to Vehicle) communication - combined with V2X (Vehicle to Everything) - will be a billion-dollar market that is also attracting increasing attention from consumers. One goal of V2X communication is to reduce the number of accidents through the exchange of information. USDOT, the US Department of Transportation, has found that V2X systems can prevent 4.5 million accidents, or 81% of all accidents, based on an analysis of traffic accidents between 2004 and 2008.
Connected cars can be hacked
V2X is not popular yet. One of the reasons for this is that there are many negative messages regarding the security of V2X communication. One of the biggest threats is cyber attacks. If the computer system of the vehicle or the mobile phone system is hacked, this can lead to material damage, the car drives, the thing even becomes life-threatening. In 2015, two security researchers succeeded in remotely accessing the CAN bus of a Cherokee jeep, which enabled them to gain control of the vehicle; they used a vulnerability in the Linux-based infotainment system. A year later, the two researchers were again able to steer a Jeep Cherokee with a laptop connected to the OBD interface of the car.
When CAN was developed decades ago, security was not an issue. Accordingly, CAN does not guarantee the confidentiality of the data and the signals are transmitted in broadcast mode. Modern cars exchange messages via the CAN bus, for example, to open doors and start the engine. Messages are exchanged between an ECU in the vehicle and an electronic key. If this system were compromised, a thief could easily steal the car.
Also, wireless communication standards such as Bluetooth, GPRS or UMTS for mobile Internet functions such as e-mail, SMS, video streaming, video calls, etc. have increased the "target areas" for hackers. Not only could they take control of the vehicle, but they could also install malicious software to steal vehicle data such as the position of a vehicle, frequently used routes and full remote conversations. Since the so-called T-BOX (Telematics Control Unit) nowadays takes over all the above-mentioned communication functions, security takes center stage.
Hardware architectures for securing ECUs
What features does a hardware architecture need to provide to ensure that ECUs meet the highest security requirements and are protected from unauthorized tampering, unauthorized installation, uploading of malicious software, Trojans and fake upgrades? The encryption of the data is an effective way to ensure the integrity, availability, and confidentiality of the data within the internal communication bus of the vehicle network. Cryptographic procedures can thus prevent cyber attacks.
Zum Thema Security wurden in den letzten Jahren diverse Interessensverbände gegründet, um Richtlinien für das Design und die Überprüfung von Systemen vorzuschlagen, die Hacker-Angriffen und Manipulationsversuchen widerstehen können.
On the subject of security, various interest groups have been formed in recent years to propose guidelines for the design and verification of systems that can withstand hacker attacks and manipulation attempts.
The EU-funded research project EVITA, in which several companies such as BMW, Continental, Fujitsu, Infineon, and Bosch were involved, is an example of this. EVITA has developed a series of guidelines that describe in detail the design, verification, and prototyping of various security architectures for automotive ECUs. EVITA provides that all critical ECUs are equipped with a chip that contains a dedicated hardware security module (HSM) as well as the CPU, whereby three different requirement profiles for the HSM were defined: Full, Medium and Light. These modules encrypt and decrypt all information exchanged between ECUs.
Based on the EVITA standard, more and more semiconductor manufacturers are implementing a so-called "Secure Zone" (also known as "Trust Anchor") in their microcontrollers/microprocessors. For example, STMicroelectronics has integrated HSMs into both its Power Architecture-based SPC5 microcontroller family (MCUs) and its ARM core processors, e.g. STA1385 TCU (Telematics Control Unit).
These ICs with HSM provide comprehensive protection against cyber threats. The HSM is an isolated subsystem with its secure processor core, RAM and flash memory (code and data). Also, the HSMs feature hardware accelerators for cryptography. At ST, this is the C3 cryptography accelerator, which also contains a true random number generator (TRNG). Data and interrupt requests are exchanged between the HSM and the application processor via an HW interface.
The HSM not only takes over access control but thanks to the integrated TRNG it can also generate real random numbers for encryption keys and execute all other encryption functions. As already mentioned, the CAN bus does not have a high-security level and therefore cannot guarantee the confidentiality and integrity of the transmitted data. However, encrypted data can also be used for secure data transmission. Asymmetric and symmetric encryption algorithms with HASH functions, MACs (Message Authentication Code) or CMACs enable the confidentiality, integrity, and availability of the data, a digital signature, and authentication of the data. All coding and decoding functions are implemented in hardware so that the host CPU is not overloaded.
Secure Boot validates the integrity of the boot loader
The secure boot function validates the integrity of the boot loader. To do this, the HSM of the MCU first loads the boot loader from the flash via the bus master. 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, the integrity of the data is secured and the MCU can use the boot loader.
Secure Communication for safe communication
The HSM also enables secure communication. The following example shows how this works: A central ECU communicates with a sensor ECU. As already explained, each HSM has a TRNG and a hardware crypto engine. The central ECU generates a random number and sends it to the sensor ECU. The sensor receives the random number, measures its data in parallel and activates its own HSM to encrypt the measurement data with the ECU random number. The sensor ECU sends the encrypted data back to the central ECU. The ECU decodes the data using its random number. The transmitted random number is then compared with the received random number to verify data integrity and authenticity. The TRNG protects against replay attacks, the encryption against "eavesdropping attacks".
Security Configurations Protect Flash Memory
Since firmware and security configurations such as passwords and keys are stored in the controller's flash memory, its protection is also critical. For this reason, ST's SPC5 MCUs are equipped with two modules that are exclusively responsible for protecting the memory: The TDM forces the software to write a data set into a certain flash area before one or more blocks can be deleted into a TDR (Tamper Detection Region). The PASS module, in turn, performs a password comparison before the flash can be written or erased.
Safe system start after a reset
To ensure that a system startup runs safely after a reset, all stored initial configurations (Device Configuration Formats, DCFs) are checked for their integrity before restarting, so that unauthorized interventions and changes can be prevented. Besides, multiple security features can be verified. In this way, attempts to modify content in specific locations using different attack methods, or to stop loading malicious firmware while booting, can be stopped.
Semiconductors with integrated HSM
IT security measures in the vehicle are essential. The use of modern semiconductors with integrated HSM helps to improve security and make implementation more efficient.
This article was first published in German by Next Mobility.