Vehicle Networking Security: Hardware Protection for Embedded Systems

Author Introduction: Mr. Li Feng is a senior security consultant at Gemalto, a global leader in digital security. He has been with Gemalto for nearly 20 years, focusing on security services and solutions, and has dedicated around 5 years to IoT and automotive security, responsible for product security design and consulting.

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 more features between vehicles and personal devices, such as smartphones; on the other hand, automotive manufacturers recognize the immense value of vehicle networking for remote vehicle management, driving them to continuously add new functional applications to vehicle networking, such as remote vehicle control, remote diagnostics, OTA software upgrades, and security rescue capabilities.

With the evolution of vehicle networking, in-vehicle networks are gradually transitioning towards in-vehicle Ethernet architecture, making it increasingly plausible for hackers to remotely attack vehicles through vulnerabilities in vehicle networking and take control. Even Tesla, known for its intelligent vehicle innovations, has experienced multiple incidents where hackers remotely attacked and seized control of their vehicles.

Therefore, the security design of vehicle networking has attracted more attention from relevant parties. The security design of vehicle networking primarily relies on the reliable authentication of trusted devices and cloud interactions. Only on the basis of trusted authentication can secure communication channels be established between two or more parties, enabling the encryption of communication data. A trusted identity system is based on a strong identification system related to keys, which is typically 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. Additionally, considering the inability to effectively control an attacker’s physical access to and analysis of vehicle devices, such risks inevitably become the foundational vulnerabilities of vehicle networking systems, posing systemic risks to the entire vehicle networking system.

On this basis, hardware-based Trusted Anchor (HTA) becomes necessary. HTA is based on hardware to store and process sensitive data, especially keys and identity data, ensuring these data are not vulnerable 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 in-vehicle ECU embedded systems, HSM is the more commonly used HTA. The definition of HSM originated from the EU-funded EVITA project, and its main objectives include:

• Enhancing the attack resistance of ECU devices: including software attacks and specific hardware attack methods

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

• Supporting communication protection between ECUs: for the protection of sensitive information transmission and device identity authentication

According to EVITA’s definition, there are three types of HSM:

• HSM FULL: Equipped with an independent encryption processing chip, supporting strong authentication mechanisms (e.g., based on RSA, ECC), supporting complex symmetric encryption operations, providing high-performance encryption and decryption operations based on hardware acceleration. Typically used to protect vehicle ECU authentication and communication with 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 the operation process. Applications achieve data encryption protection through internal encryption and decryption interfaces, typically used to protect secure communication between ECUs.

• HSM Small: A low-cost security module that implements simple block encryption operations, used 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 relies 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 security mechanisms through custom engines.

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

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

Hardware-based encryption packages typically include 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 the HSM

However, the security of HTA is not solely about the software itself; the security production and updates of HTA are also critical considerations for overall hardware security. For this reason, traditional security chip manufacturers, such as Gemalto, not only provide high-standard security products but also offer trusted security production and over-the-air update management capabilities, establishing a trusted security anchor for the entire vehicle networking security system’s trust chain.

As mentioned at the beginning of this article, the era of connected vehicles has begun. The potential demands for enhanced security, improved customer experience, and operational and maintenance advantages that increase manufacturer profits make the Connected Car a win-win proposition for the industry and its customers. To successfully manage this revolutionary change, secure design and lifecycle security must be key components considered in the product development cycle and manufacturers’ IT infrastructure.

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

The automotive industry faces the task of determining the security technology requirements needed for different automotive systems and how ECUs interact with each other when designing Connected Car security architectures. The optimal solution is to use different HTA security hardware for different devices in the vehicle, a solution that needs to establish architectural decisions early in the vehicle design process.

Disclaimer: The content and images of this article are reprinted from BC-AUTO, sourced from Intelligent Networking and Artificial Intelligence, and authorized.