Security in a vehicle is feasible

07/18/2019 Know-How

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 attracting increasing attention from consumers. One goal of V2X communication is to reduce the number of accidents by exchanging information. Based on an analysis of road accidents between 2004 and 2008, the US Department of Transportation (USDOT) discovered that V2X systems can prevent 4.5 million accidents, i.e. 81% of all accidents.


V2X has not proven so popular up to now. One reason for this is that there are a lot of negative perceptions surrounding the security of V2X communication. The possibly greatest threat lies in cyber attacks. If the vehicle’s computer system or cell phone system is hacked, it can lead to property damage and could even be life-threatening if the car is being driven at the time. In 2015, two security researchers succeeded in remotely hacking into the CAN bus of a Jeep Cherokee, allowing them to take control of the vehicle; they used a weak point in the Linux-based infotainment system. A year later, the two researchers were again able to steer a Jeep Cherokee via a laptop connected to the vehicle’s OBD port.

When CAN was developed decades ago, security was not an issue. Accordingly, CAN does not guarantee data confidentiality and signals are transferred in broadcast mode. Modern-day cars exchange messages via the CAN bus, for example to open doors and to start the engine. Messages are exchanged between an ECU inside the vehicle and an electronic key. If this system were to be compromised, a thief could easily steal the car.

In addition, wireless communication standards such as Bluetooth, GPRS or UMTS for mobile Internet functions like email, SMS, video streaming, video calls, etc. have provided hackers with greater “target areas”. This would allow them not only to take control of the vehicle but also to install malicious software in order to steal vehicle data such as the location of a vehicle, frequently used routes, and complete calls remotely. Since the so-called T-BOX (Telematics Control Unit) is now responsible for all the aforesaid communication functions, the focus is firmly on security.


Which features must a hardware architecture have to ensure that the ECUs meet the highest security requirements and are protected against illegal tampering, unauthorized installations, uploading of malicious software, Trojans, and fake upgrades? Data encryption is an effective way to ensure the integrity, availability, and confidentiality of data within the internal communication bus of the vehicle network. Cryptographic methods can thus prevent cyber attacks.

In recent years, various interest groups have been established to propose guidelines for the design and verification of systems that can withstand hacker attacks and manipulation attempts.

A prime example of this is the EU-funded EVITA research project, in which several companies such as BMW, Continental, Fujitsu, Infineon, and Bosch were involved. EVITA came up with a number of guidelines that describe in detail the design, verification, and prototyping of various security architectures for automotive ECUs. Moreover, EVITA stipulates that all critical ECUs are equipped with a chip that contains not only a dedicated hardware security module (HSM) but also the CPU, wherein three different requirement profiles have been defined for the HSM: Full, medium, and light. These modules encrypt and decrypt all the information exchanged between ECUs.

Based on the EVITA standard, an increasing number of semiconductor suppliers are implementing what is known as a “secure zone” (also referred to as a “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 offer comprehensive protection against cyber threats. The HSM is an isolated subsystem with its own secure processor core, RAM, and flash memory (code and data). In addition, 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 a hardware interface.

The HSM not only assumes access control but can also generate real random numbers for encryption keys and perform all other encryption functions thanks to the integrated TRNG. As already mentioned, the CAN bus does not deliver a high level of security and therefore cannot guarantee the confidentiality and integrity of the transferred data. However, with encrypted data, it can also be used for secure data transfer. Asymmetric and symmetric encryption algorithms with HASH functions, MACs (message authentication code) or CMACs enable data confidentiality, integrity, and availability, digital signature and data authentication. All coding and decoding functions are implemented in the hardware to ensure the host CPU is not overloaded.



Typical application


Secure boot

The secure boot function validates the integrity of the boot loader. To do so, 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 an MAC (message authentication code) for the received message; if the calculated MAC corresponds to the stored boot MAC, the integrity of the data is secured and the MCU can use the boot loader.


Secure 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. This decrypts the data using its own random number. The transferred random number is then compared with the received random number to verify data integrity and authenticity. The TRNG protects against replay attacks and encryption against “eavesdropping”.


Flash memory protection (optional)

Since firmware and security configurations such as passwords and keys are stored in the controller's flash memory, their protection is also critical. The ST SPC5 MCUs are, therefore, equipped with two modules that are exclusively responsible for protecting the memory: The TDM forces the software to write a data set in a specific flash area before one or more blocks can be deleted in a TDR (tamper detection region). The PASS module, on the other hand, performs a password comparison before the flash can be written or deleted.


System security configuration (optional)

To ensure a system startup is carried out securely after a reset, all the stored device configuration formats (DCFs) are checked for integrity before rebooting, thereby preventing unauthorized interventions and changes. In addition, several security features can be checked. This ensures any attempts to change content at specific locations using various attack methods or to load malicious firmware while booting can be stopped.



IT security measures in vehicles are essential. The use of state-of-the-art semiconductors with integrated HSM helps to improve security and make implementation more efficient.


Find components at <link _blank external-link-new-window "open internal link"></link>.

Subscribe to our <link _blank external-link-new-window "open internal link">newsletter</link> and stay updated.