Exploring Security in Connected Vehicles: Hardware Protection in Embedded Systems

As the automotive industry continues to develop, the ability to provide more convenience and personalized driving experiences becomes prominent. On one hand, consumers wish to enjoy more convenient and personalized services through connectivity, prompting manufacturers to integrate vehicles with personal devices like smartphones; on the other hand, manufacturers recognize the immense value of connected vehicles in remote vehicle management, leading them to continually add new functionalities such as remote vehicle control, remote diagnostics, OTA software upgrades, and security rescue capabilities.

As connected vehicles evolve, in-vehicle networks are gradually developing towards an automotive Ethernet architecture. Therefore, the possibility of hackers remotely attacking vehicles through vulnerabilities in the connected vehicle network is no longer just a theoretical concern. Even Tesla, known for its innovative vehicle intelligence, has experienced multiple incidents where hackers remotely attacked and took control of various models.

Consequently, the security design of connected vehicles has garnered more attention from stakeholders. The security design of connected vehicles must first rely on the reliable authentication of trusted devices and the cloud, establishing secure communication channels based on trusted authentication to encrypt communication data. A trusted identity system is based on a strong identification system related to keys, which is usually a centralized hierarchical security system, such as a multi-layer discrete system based on symmetric keys and an asymmetric PKI system.

In such a security system, a reliable trust anchor for securely storing device identities and identity keys becomes the foundation of the entire trust chain.

However, in the embedded systems of vehicle devices, if there are no reliable hardware means, the secure storage of keys and device identities becomes the weakest link. Considering the inability to effectively control attackers’ physical access and analysis of vehicle devices, such risks inevitably become foundational vulnerabilities in the connected vehicle system, posing systemic risks to the entire connected vehicle system.

On this basis, a hardware-based trust anchor (HTA) becomes necessary. HTA is based on hardware to store and process sensitive data, especially keys and identity data, ensuring that this data is not susceptible to malware attacks and sniffing.

Depending on the computational and data protection capabilities required by different devices, HTA comes in various types:

• Secure Hardware Extension (SHE)

• Hardware Security Module (HSM)

• Trusted Platform Module (TPM)

For vehicle ECU embedded systems, HSM is the most commonly used HTA. The definition of HSM originates from the EU-funded EVITA project, and the main objectives of HSM include:

• Enhancing the anti-attack capability of ECU devices: including software attacks and specific hardware attack methods.

• Providing hardware-accelerated encryption capabilities: reducing the computational burden on MCU processors.

• Supporting communication protection between ECUs: used to implement sensitive information transmission protection and device identity authentication.

According to EVITA’s definition, HSM has three types:

• HSM FULL: Features an independent encryption processing chip, supports strong authentication mechanisms (e.g., based on RSA, ECC), supports complex symmetric encryption operations, and provides high-performance encryption and decryption operations based on hardware acceleration. Typically used to protect authentication and communication between vehicle ECUs and external devices or software. The secure element (SE) is a typical example of HSM FULL.

• HSM Medium: A hardware security module specially designed within the main processor, dedicated to storing keys and protecting computational processes. Applications encrypt data protection through internal encryption interfaces, typically used to protect secure communication between ECUs.

• HSM Small: Low-cost security modules that perform simple block encryption operations to protect critical sensors, similar to SHE.

Taking the TLS protocol stack as an example, the following is the OPENSSL software architecture diagram:

The default OPENSSL is based on a software encryption engine to complete the storage and operation of keys and identities. For embedded devices, software-based key protection cannot form a reliable TRUST Anchor. The encryption engine mechanism of OPENSSL allows developers to smoothly upgrade software-based encryption and decryption operations to hardware HSM-based security mechanisms through custom engines.

In AutoSAR 4.3, the embedded security model defined based on HSM FULL maps appropriately to OPENSSL, as shown in the following diagram:

In this model, the crypto driver (CRYDRV) is the specific implementation part of encryption and decryption functions, fully corresponding to the concept of OPENSSL’s engine. By configuring OPENSSL’s engine, we can easily implement security capabilities based on HTA, establishing a secure and feasible anchor for the device’s identity authentication system.

The hardware-based encryption package typically includes three parts:

1. HSM interface driver running on the MCU

2. Encryption and decryption interface driver running on the MCU

3. Encryption program running inside HSM

However, the security of HTA is not just about the software itself; the secure production and secure updates of HTA itself are also key considerations for overall hardware security. For this reason, traditional security chip manufacturers like Gemalto not only provide high-standard security products but also offer trusted secure production and over-the-air update management capabilities, establishing a trusted security anchor in the trust chain of the entire connected vehicle security system.

As stated at the beginning of this article, the era of connected vehicles has begun. The potential demands for enhanced security, improved customer experience through new services, and operational and maintenance advantages that boost manufacturer profits make Connected Cars a win-win proposition for the industry and its customers. Successfully managing this revolutionary change requires that design-time security and lifecycle security become critical components of the product development cycle and the manufacturer’s IT infrastructure.

Therefore, it is crucial to view security design as a key part of ECU system design rather than an additional component of the existing system architecture.

The challenge facing the automotive industry in designing the security architecture for Connected Cars is determining the security technology requirements for different automotive systems and how ECUs interact with each other. The optimal solution is to use different HTA security hardware for different devices in the vehicle, which requires architectural decisions to be established early in the vehicle design process.