In-vehicle Network Traffic Protection Alternatives and Considerations

A demand to protect the messages inside a vehicle

The automotive industry regulatory requirements and cybersecurity threats demand addressing the protection of the messages inside vehicles. As part of the automotive industry shifts towards CASE (Connected, Automated, Shared and Electric) vehicles, the two dominant network types are CANbus and automotive Ethernet. Since the CANbus is being replaced by automotive Ethernet, this article will focus on the latter. Although not related, we shall also discuss the external communication between the vehicle and the cloud, appreciating that alternative and more suitable solutions might be appropriate for each case. We shall review the various cryptographic aspects of network protection, present the alternatives, analyze them, and propose the relevant courses of action to the various players in the industry.

The main audiences: OEMs and Tier 1s

This article’s main audience is OEMs (Original Equipment Manufacturer) since they manage and are responsible for the in-vehicle network. They are the ones who dictate the network architecture and instruct their Tier 1 suppliers on the required functionality.
This article is equally important to Tier 1s that develop ECU (Electronic Control Unit) hardware and software (with their supply chain and subcontractors), since they implement the OEMs’ network security requirements.
Testing companies should read this from their perspective as a preparation for the STD (System Test Document), and the STP (System Testing Procedure).
Analysts, consultants, industry experts and other parties will find great interest here as well.

The challenge and motivation in the automotive industry

To answer the industry needs for in-vehicle security, the following items need to be covered:

• Identification and authentication– both communicating parties (ECUs in this case) need to mutually authenticate their identities to ensure communication is with, and messages are produced by, the desired entity.
• Message integrity – assuring the message was not tampered with along the way with attack scenarios such as MitM (Man in the Middle), altering the contents of the message by a rogue ECU.
• Freshness – assuring the message is recent preventing replay attack scenario by a rouge ECU recording some traffic and transmitting it later.
• Non-repudiation – the sending ECU provides proof of authorship, preventing it from later denying it was the source of the message that was received by the receiving ECU.
• Confidentiality and Privacy – preventing a rouge ECU from tapping the network and eavesdropping on the flow of traffic.

All these principles apply equally to a vehicle-to-cloud interface, however this article will focus on the in-vehicle segment.

Alternative solutions

MACsec – MACsec is an ISO/OSI 7 layers model layer 2 (data link layer) protocol which works on the in-vehicle automotive Ethernet in a point-to-point operation mode. It protects the link between ECUs or between two Ethernet switches. The control plane is IEEE 802.1X that is also commonly used in other instances such as IEEE 802.11 (Wi-Fi) and other networks. MACsec is the wired equivalent of WPA2 in Wi-Fi networks.

• Control plane – allows the control of access to the network: only authenticated ECUs can gain connectivity.
• Data plane – IEEE 802.1AE and is a simple protocol based on Ethernet with AES-GCM (Advanced Encryption Standard (AES) key used with the Galois/Counter Mode (GCM) mode of operation) handling both the encryption and authenticity of the packets.

The network characteristics are:

• Only authenticated peers can connect to the network.
• All local attacks that “trick” switches and routers to redirect network traffic to attacker machines are not feasible.
• MACsec is transparent to the ISO (International Standard Organization) OSI (Open System Interconnect) 7 layers model – layer 3 (Network) and above. It handles and encrypts all traffic without the end point application being aware.

In the automotive world, a typical use case for MACsec would be to secure the connection between an TCM (Transmission Control Module) and a TGU (Telematics Gateway Unit) ensuring invalid payloads are discarded and ensuring that a receiving party can trust the source of the transferred message.

The in-vehicle Ethernet network is typically based on ECUs connected to other ECUs using a layer 2 switch. VMs (Virtual Machines) and/or containers are connected using a virtual bridge or a hypervisor. This means that all Ethernet network traffic routing is based solely on the layer 2 header parameters (Destination MAC address, Source MAC address, and VLAN tag). This allows encryption of the Ethernet frame payload without affecting the switching functionally of the network. The MACsec encapsulation is transparent to the switching functionality.

In theory, multiple ECUs can be allocated to groups with shared keys, thus enabling encryption of multicast and/or broadcast frames. There is no need to split the multi/broadcast to single point-to-point unicast. However, this does not look practical.

IPsec – IPsec is a layer 3 (network layer) protocol, providing a tunnel function. It works between any two hosts of an IP network – public internet or OEM/vehicle fleet network established for example over a cellular network using dedicated private APNs (Access Point Names). Regardless of how those peers are connected (in-vehicle or vehicle to cloud via many routers, several types of links, etc.) IPsec is used to create a VPN (Virtual Private Network) – peer to network i.e., ECU to ECU, ECU to cloud or vehicle to cloud.

• Control plane – IKE or IKEv2 (Internet Key Exchange).
• Data plane – using explicitly the IPsec protocol. IPSec VPN protocol communicates over IP protocol number 50 for ESP (Encapsulating Security Payload). It might also require UDP (User Data Protocol) – port 500 for IKE to manage encryption keys, and UDP port 4500 for IPSec NAT-T (Network Address Translation – Traversal). Sometimes, if the UDP ports are blocked, VPN devices try to use TCP (Transport Control Protocol) port 500 and TCP port 4500.

The IPsec setup and the protocol itself can be extremely complicated with multiple variants and options. IPsec is transparent to the application. It encrypts all traffic without the end point application being aware.
TLS – TLS (Transport Layer Security) and DTLS (Datagram Transport Layer Security) are application layer protocols between two endpoints (in general it means one application running on one host). They provide security directly between applications on the two devices. Most of the time, the parties do not need to know or trust each other in advance, since trust is usually handled through PKI (Public Key Infrastructure).
TLS is the replacement for SSL (Secure Sockets Layer), previous versions of SSL are deprecated and have known security issues. TLS requires a reliable transport protocol and typically runs over TCP.
DTLS (Datagram Transport Layer Security) is a version of TLS that does not require a reliable transport protocol over UDP unreliable transport.
These protocols contain several layers that deal with both the control plane and data plane.

• SSL/TLS is typically used for application-specific security e.g., using https://… From the ECU to a web server. The reason is that the credentials of the secure protocols can be bound to the application itself.
• DTLS would be used for encrypting real time data such as VoIP (Voice Over IP) traffic. The data is sent in real time and packet loss would not invalidate the entire connection. The DTLS protocol would keep the connection open and there would be a slight degradation in the call audio corresponding to the bad or missing data.

In terms of architecture and software implementation, these protocols do not require modification of the kernel to be implemented. However, they do require integration into user application(s) as these are not implemented at the system level.
An application running in an ECU can specify encryption and authentication parameters for each host it needs to contact.

Alternative comparison and considerations

Performance

• MACsec – this can be implemented in software and in fact, is part of operating systems such as in the Linux kernel. However, it is primarily a hardware implementation that can perform at wire speed with no latency on the network. Encryption/decryption and signing/authentication can be done by the NIC (Network Interface Card) hardware, thus offloading this functionality from the CPU. Virtual interfaces can also support hardware acceleration for MACsec.
• IPsec – this can be implemented as a software solution with optional hardware acceleration. Some delay is added due to the encryption, but it is not substantial with the acceleration.
• TLS – this is performed in software, but hardware acceleration is possible. TLS is not suitable for real time communication, but DTLS is, including multimedia multicasting. Both cases add load to the CPU and increase the latency. Both can be ameliorated by employing hardware cryptographic acceleration engines but still this is the heaviest alternative.

KMS (Key Management System)
In general, the KMS is the pitfall of the entire system. Key distribution is required by other mechanisms as well such as secure boot, OTA, diagnostics, and more. A dedicated HSM (Hardware Security Module) is present in the MCUs (Micro Controller Units) and CPUs (Central Processing Units) that facilitate the storage of the keys and acceleration of some cryptographic functions.

• MACsec – using MKA (MACsec Key Agreement) between the ECUs as described in 802.1X. Supporting multiple types of key exchange mechanisms and cryptographic suits such as TLSv1.3 using EAP-TLS (Extensive Authentication Protocol).
• IPsec – a mechanism such as PSK (Pre-Shared Key) using protocols such as IKE (Internet Key Exchange) needs to be put in place to enable the parties to engage in secured communication. More complex to achieve than MACsec mechanism, especially when the communication is vehicle to cloud.
• TLS – the common method is a heavier mechanism where certificates and CAs (Certificate Authorities) are used to govern the entire process. This makes life hard, especially for low computing power ECUs. Pre-shared secret is also possible for relevant applications.

Hardware

• MACsec – for optimal performance it requires an ECU with a NIC with MACsec support. There are software libraries but those do not scale for traffic intensive use cases. The switches along the path are not required to support MACsec and the process is transparent to them. An HSM with a large secure storage such as TEE (Trusted Execution Environment) is necessary,
• IPsec – this solution does not require any dedicated hardware but having acceleration comes in very handy.
• TLS – this solution does not require any dedicated hardware but having acceleration comes in very handy as well.

End to end vs. Hop by hop

• MACsec – can be E2E (End to End) or hop-by-hop. For E2E the ECU can serve as the key server. For hop-by-hop the switch will serves as the key server and thus hold the keys to all MACsec channels (also called Secure Connections) that go through it.
• IPsec – this is an E2E tunnel from the ECU or from the vehicle connected gateway to the peer party (in-vehicle or in the cloud).
• TLS – this is also an E2E tunnel from the ECU or from the vehicle connected gateway to the peer party (in-vehicle or in the cloud).

NIDS (Network Intrusion Detection System)

It should be noted that no cryptographic mechanism replaces the NIDS. The NIDS is the only dedicated, devoted, objective, and independent cybersecurity protection component in the vehicle. It is quite easy to conceive a scenario in which one compromised ECU or cloud software is used to attack an ECU in the vehicle over those very secured communication channels that we created using cryptography. The cryptographic mechanism will ensure that the malware will travel untouched and make life harder on the NIDS detecting the attack due to functions such as encryption. Therefore, a defense-in-depth approach is required using multiple layers of security. Traffic protection is one of them. The NIDS is another one. Additional mechanisms are required such as network segregation, secure boot, etc.

• MACsec – cannot perform inspection of network traffic by being a silent listener. Need to include the NIDS in the KSM and listen to the MKA to enable inspection of the traffic in-line or from a mirror port.
• IPsec – in case only AH (Authentication Header) is used thus ESP (Encapsulating Security Payload) is not employed the network traffic is clear text and then inspection is possible. If ESP is used, then the NIDS cannot perform inspection of network traffic by being a silent listener. It needs to be included in the KSM and listen to the IKE to enable inspection of the traffic. Working in transport mode makes inspection easier since the end IP addresses of the peers are exposed. If tunnel mode is used, then additional work is required to extract the encapsulated IP addresses.
• TLS – this is more complex since many mechanisms are involved. It would require the NIDS to be part of the KSM, listen to key exchange, etc., which is not a simple task.

Vehicle-to-cloud communication

• MACsec – works only in the vehicle and does not provide a service externally to the cloud. There can be implementation beyond the vehicle using protocols such as L2TP (Layer 2 Tunnelling Protocol) implementing a VPN that can even achieve end to end security.
• IPsec – this solution is suitable both for in-vehicle and vehicle to cloud communications since it enables IP end to end connectivity suitable for the cloud, but it is also a relatively simple implementation suitable for the in-vehicle.
• TLS – this solution is best suited for vehicles to cloud communications. Since it is a heavy mechanism, it is more suitable for the in-vehicle communication but more suitable for application layer connectivity between the vehicle and the cloud.

Virtualization and containers

• MACsec – Supports communication between VMs. Supports communication between containers. The various VMs/containers are connected using a virtual bridge. As stated above, the MACsec encapsulation is transparent to the virtual bridge.
• IPsec – fully supported.
• TLS – fully supported.

OEM proposed course of action

OEMs should specify and implement secure and strong cryptographic mechanisms to protect the traffic on the vehicle network (internally and with the cloud) for the sake of vehicle safety, security, and privacy.
Out of the available mechanisms, the best suited for in-vehicle is MACsec. IPsec can serve as a viable option for the in-vehicle as well, for example in case it is already present in the ECU due to cloud connectivity. TLS is best suited for vehicles with cloud connectivity and less for in-vehicle.
OEMs need to implement security means that make use of the increase in the available computing power and hardware capabilities.

Tier 1 proposed course of action

Tier 1s should plan and design ECUs with readily available security mechanisms to accommodate the secure network traffic.
Tier 1s designing sensors with high traffic rate such as camera, lidar or radar, with an Ethernet network interface should support MACsec (IEEE 802.1AE) and MKA (802.1X) as part of their hardware and communication stack.
Use hardware available components that include HSM, support MACsec and other cryptographic acceleration mechanisms.
Use own implementations or cooperate with software companies to implement the required mechanisms.

Security and penetration testing companies proposed course of action

STDs (System Test Document) and STPs (System Testing Procedure) should include testing the functionality of security mechanisms. Those should be subject of harsh penetration testing using automated tools and techniques such as fuzzing.

Conclusions

The MACsec protocol provides a safe, trusted, and secret playground in which all vehicle ECUs can play. The MACsec protocol enables encrypted and authenticated communication regardless of the underlying protocol. It can be easily integrated into existing networks by diverting the traffic from the existing interface to the MACsec interface. The hard part is providing the key exchange mechanism.
IPsec can be used to a certain extent, but TLS is more suitable for communication with the cloud.
In any case, both the in-vehicle and vehicle to cloud communication should be secured and protected as part of a holistic vehicle cybersecurity protection.