Telematics Control Unit Cybersecurity: A Battle on Two Fronts

The Telematics Control Unit (TCU) is now the frontline of the automotive cybersecurity battle. New use cases, driven by ubiquitous connectivity, will see it play a larger role in modern vehicles. As cybersecurity attack vectors emerge, the automotive industry will need to think fast if it is to keep ahead of the threat. Gilad Bandel, VP of Product and Marketing at Israeli firm Arilou Automotive Cybersecurity explains more. 

Fighting on Two Fronts 

On March 21^st, 1801, the 28^th (North Gloucestershire) regiment of the British Army fought a fierce battle outside of Alexandria, Egypt. During this battle, French cavalry broke through the British lines, formed up behind the regiment, and began to charge both sides of the line simultaneously. Still heavily engaged to their front, the order came; “Rear rank, 28th! Right about face!”, and then, in two ranks back-to-back, the regiment successfully defended itself. 

The telematics control unit is in a similar situation in terms of cyber-threats and possible attack vectors, because the TCU serves as a gateway between the external world and the IVN. Vulnerable on two fronts, it can be attacked via both the external cellular network and the in-vehicle network. A full transition to the use of automotive Ethernet, using IP (internet protocol), increases the risk of a remote attack being launched against an electronic control unit (ECU). 

A Mobile Enemy 

Remote attacks are regarded as the most severe threat to the vehicle since they can be performed from anywhere and leave very few traces: 

• External cellular: Most current, high probability cases feature a cellular modem integrated within the TCU. This interface is used by Original Equipment Manufacturers (OEMs), or fleet owners, to interact with the vehicle (via the cellular network) for functions such as telemetry – using diagnostics protocols – or the upload of new firmware to ECUs using Firmware Over-the-Air (FOTA). We can split threat analysis for this interface as follows:
  • Incoming traffic from the cellular network: This traffic originates from the cloud and reaches the TCU via cellular. It poses the most severe threat since it is the preferred attack vector into the vehicle. A malicious actor can reach the IVN and easily launch an attack on the vehicle via a compromised TCU – targeting other ECUs or the TCU itself. Note that even if communication channels are secured, and the peer is authenticated using cryptography, this still does not rule out compromised cloud servers being used to attack an individual vehicle or an entire fleet. In some cases, adding end-to-end encryption can even harm the greater cause as it denies inspection mechanisms access to network traffic. This risk is similar to that of vehicle-to-everything (V2X) traffic reaching an on-board unit (OBU), which share similarities with TCUs in terms of communication and threats.
  • Outgoing traffic to the cellular network: Traffic originating from the TCU, sent to the cloud over the cellular network. In this attack scenario, the attacker uses the vehicle to send rogue data with the purpose of harming the cloud. The same authentication and cryptographic considerations mentioned above apply, however, this is not the most likely scenario. In some cases, the vehicle owner could be the actual attacker, or an innocent bystander unknowingly aiding in the attack, making the attack much simpler and significantly more dangerous.

In the Trenches

As physical attacks are also possible, the basic assumption is that the enemy is among us and able to inject traffic into the IVN.

• IVN: The interface for vehicle ECUs, the backbone of the internal network. In the most probable cases, attacks originating from outside the vehicle would target the IVN in an attempt to gain access to specific ECUs, but other scenarios are possible as well. In cases where the TCU has no cellular modem, the central gateway is used to interface with the cellular network, so in this case this is yet another type of outgoing traffic. The threat analysis for this interface is divided as following:
  • Incoming traffic from the IVN: There are three cases depending on the target:
    • The target of the attack is the TCU itself, with the intention of influencing TCU functionality by causing it to malfunction and provide erroneous information. This is a high probability scenario. Traffic can originate from any ECU, and in cases where the cellular modem is located in the central gateway, it can also originate from the cloud, making this a dangerous scenario.
    • This type of attack can also be used as a step in the kill chain, with the actual target not necessarily related to the TCU. This is a medium-probability scenario due to its complexity, but if successful it could have severe impact.
    • Using the TCU as a relay to jump from one network to another e.g. from the CAN-bus to the cellular network, or even back to the CAN-bus. This is an unlikely scenario.
  • Outgoing traffic to the IVN: Once traffic leaves the TCU for the IVN it can reach other ECUs and cause harm. Relevant cases are:
    • Destination is another ECU: The result of such attack scenarios depends on the victim ECU, its protection mechanism, and any other security on the path between TCU and ECU. This includes mechanisms such as network segregation (assuming the TCU is located in the connected low-security network zone, while safety critical ECUs are on a separated high-security network).

• Central gateway equipped with cellular modem while the TCU is not: Traffic here is equivalent to the outgoing cellular traffic mentioned above, except that it first travels over the IVN to the central gateway, which then conveys it to the cellular network.

• In cases where the TCU and the central gateway are combined as a Telematics Gateway Unit (TGU): We consider these as if they were two separate devices. Variations can include the TCU cellular modem being used by the gateway and other ECUs, or the central gateway modem being used by the TCU and other ECUs. In either case, this monolithic design maintains the same functionality and concept as the individual. Note that in this case, the risk is much higher since this device often has additional interfaces such as Bluetooth, Wi-Fi, GPS/GNSS (Global Positioning System/Global Navigation Satellite System) or USB. An attacker can jump from one network to another more easily since they are all packed in one place.

Communication Protocols

As above descriptions are generic, we should examine them in relation to the various protocols used.

• Cellular-Side
  • The physical and data link layers are cellular (3G/4G, and soon 5G) and have a high chance of residing in the central gateway. Using a public Access Point Name (APN) poses a considerable risk since the vehicle is accessible to anyone on the public internet, therefore private APNs are employed. This contrasts with in-vehicle infotainment systems (IVIs) that must have a public APN for internet access. As such, the IVI has some riskier characteristics compared to the TCU. 
  • The network layer is standard IP.
  • The higher layers include standard IP protocols such as IPsec or HTTPS for VPN creation, IT protocols such as Syslog, automotive standard and proprietary protocols for telemetry, diagnostics, FOTA, and so forth. 
• IVN
  • CAN-bus: This is a legacy bus (with new versions such as CAN-FD and CAN-XL) which all ECUs share and can communicate over freely. Gateways are used to mediate and segregate buses. The protocol does not have any inherent source identification or designated, specific, target ECU, as it uses a form of multicast addressing of the message type relevant to interested ECUs. CAN-bus has some extended capabilities such as Transport Protocol (TP), and authentication methods such as SecOC (Secured Onboard Communication). Riding protocols are the standard Unified Diagnostics Service (UDS). However, the implementations are OEM and model specific (but obscurity is not security). In general, the CAN-bus was well conceived, but in a time before there was any awareness of cybersecurity risk, and as such it has no real security.
  • SAE J1939: This protocol shares the CAN-bus infrastructure but has higher layer protocols and features such as extended addressing, source and destination identification, extended TP, dynamic addressing and more. This protocol is common among heavy-duty vehicles such as trucks, buses and agriculture machines. In terms of security it is not much different than the CAN-bus, but since it is far more standardized, many vehicles share the same message IDs and even the same ECUs. In principle this increases the threat risk since widespread common implementation implies opportunity for multiple attacks once a breach has been found.
  • Automotive Ethernet: An emerging technology that shares many characteristics with Information Technology (IT) and Operational Technology (OT) – except the physical layer. On top of Ethernet are some specific protocols such as Audio Video Bridging (AVB) and Audio Video Transport Protocol (AVTP). In addition, Ethernet standard TCP/IP is used with common IT protocols such as Address Resolution Protocol (ARP). It also makes use of more important automotive protocols such as Scalable service-Oriented middlewarE over IP (SOME/IP), Diagnostics over IP (DoIP), and others. Given that the protocol stack is new to the automotive industry, but also extremely mature from an IT/OT perspective, it is prone to vulnerabilities from recent adoption in addition to its well documented history of hacks, exploits, and scripts. As such it poses a major risk. Ethernet should be regarded an excellent opportunity for the automotive industry to evolve, but also for hackers to attack.
  • Other protocols such as Local Interconnect Network (LIN), FlexRay, Media Oriented System Transport (MOST), and others, are not regarded as a major cyber area due to their location/position or specific/limited functionality.

Embedded Positions

The TCU is just another embedded device, as such all the risks relevant to any embedded device are relevant here as well. Since this is a connected device that serves as a gateway for interfacing with a vehicle’s secure ECUs, the risks are much higher:

• Compromised boot sequence: In this attack the loaded flash image might be old and unsecured or have malware embedded. 
• Tampered storage: Modified software modules or data can be loaded and cause undesirable effects
• Firmware update from rogue source: Includes code that will cause malfunction of the TCU, allowing the ability to take remote control.
• Taking advantage of vulnerabilities and exposures such as a Buffer Over Flow (BOF) or an open port: Cause TCU misbehavior.

Defensive Maneuvers 

There are numerous reasons to secure TCUs:

• The TCU is one of the most common ECUs used as a means to attack a vehicle. Furthermore, if the IVN is CAN-bus then the attacker needs to switch protocols from the IP used over cellular to that of the CAN-bus. Even worse, in Automotive Ethernet, the IP is used end-to-end, facilitating direct traversal from the hacker’s computer to the victim ECU. Responsible professionals acknowledge this fact and act to protect and secure these devices.
• Worldwide regulation such as the UNECE (United Nations Economic Commission for Europe) WP.29 (Working Party – World Forum for Harmonization of Vehicle Regulations) and its equivalents in non-participating countries, list a set of risks and required mitigations to secure a vehicle. These lists must be adhered to in order to receive the legal certification necessary to enable the sale of the vehicle.
• Top management want to prevent deaths, damage to property, and the loss of reputation they could experience in cases where the TCU is found to be used as a means to cause harm to a vehicle.

A Suitable Arsenal

The following list examines relevant means to secure the TCU. Each case must be implemented following a designated process such as Threat Analysis and Risk Assessment (TARA), resulting in a list of prioritized risk minimization/mitigation methods. Tier-1 suppliers and OEMs need to work together to create an optimized plan for cost-effective security for the TCU and associated vehicle models. In any case, there is no silver bullet that solves all problems, therefore a multi-layer, defense-in-depth approach is required.

• Secure by design: From day zero a security plan and a Cyber Security Management System (CSMS) needs to be put in place, with a goal of managing and reducing cyber risk. Standards such as ISO/SAE 21434 should be followed. For example, network architecture with an Application Area Network (AAN) segregated by sensitivity level (connected, body, media, safety critical, etc.), usage of cryptographic means, trust chain, key distribution mechanisms, Ethernet Virtual Local Area Network (VLANs), IP Virtual Private Networks (VPNs) and similar.
• Development process: Should be designed with security in mind and employ the Secure Software Development Life Cycle (SSDLC), comply to standards such as ISO 26262 Automotive Safety Integrity Level (ASIL), Motor Industry Software Reliability Association (MISRA-C), etc. 
• Endpoint Detection and Response (EDR): Include a set of tools that secure the TCU internally such as:
  • Secure boot: Ensuring only a verified and authorized image is loaded at boot time.
  • Secure module loading: Ensure the persistent storage or volatile memory are secure and were not tampered with, thus only verified and authorized versions of each module and file are loaded and used by the software. In case a mismatch is found, the module or file will be denied, or loading and other measures can be taken, such as TCU reboot, restoring older verified versions, reporting the event, and other relevant actions.
  • Host Intrusion Detection System (HIDS): Will monitor the behavior of the software of the TCU (CPU usage, memory usage, running processes, data coherence, plausibility, sanity, etc.) to ensure the proper functionality of TCU firmware and report any detected misbehavior.
• Network Intrusion Detection System/Intrusion Prevention System (NIDS/NIPS): Also known as IDS/IPS, performs traffic inspection employing techniques such as Deep Frame Inspection (DFI), Deep Packet Inspection (DPI), Deep Content Inspection (DCI), and Stateful Packet Inspection (SPI) for anomaly detection, signature-based detection and other methods. Note that anomaly detection is well suited for the static, predictive, and deterministic nature of the in-vehicle network, and has an extremely low false positive ratio and immunity to zero-day attacks. From the other side, signature-based detection can detect complex attack scenarios but is, unfortunately, prone to more false positives alarms. A set of rules is applied on the analyzed traffic to detect anomalies and other indications of a cyber-attack, examples include:
  • Message format: consistency and compliance to standards
  • Field value range: For example, speed range within the vehicle physical boundaries (i.e. 0-250 Km/h is valid, but 1,000 Km/h is not).
  • Change rate of values: Such as accelerating from 20 Km/h to 23 Km/h in one second is possible but 10 Km/h to 150Km/s is one second is not possible.
  • Periodic messages: i.e. a message that has a 20ms frequency cannot appear after only 7ms.
  • Vehicle context: For example, a vehicle which is switched off and in parking mode cannot have torque on the engine.
  • Authentication failure: Such as the key does not match the expected value.
  • Media Access Control (MAC): Usage of a previously unknown MAC address, known MAC address originating from an unexpected physical port, unexpected MAC address/IP address combination.
  • Excessive message rate: Indicating a Denial Of Service (DOS) signature attack.

Decisive Tactics

It is crucial to emphasis that while all the other measures are important, the IDS/IPS is the only dedicated, devoted, independent and objective component in the vehicle concerned exclusively with cybersecurity protection.

The IDS performs the function of detection and reporting (only) of events, normally to a Security Information and Event Management (SIEM) system at the Security Operation Center (SOC) where a Cyber Emergency Response Team (CERT) will perform forensic analysis and generate a response. An IPS, in addition to reporting, will stop the attack by taking intrusive actions – such as dropping offending frames or disabling offending components.

Inspecting the Cellular Interface:

• If the TCU is equipped with a cellular modem the IDS/IPS needs to reside on the TCU to enable it to inspect incoming cellular traffic for data that is regarded as a major threat. 
• It can also monitor outgoing cellular traffic but, as already mentioned, this is less of a priority since this attack scenario is less probable.

Inspecting the IVN:

Incoming traffic to the TCU needs to be inspected in case the attack target is the TCU. 

• For CAN-bus and SAE J1939
  • If only detection is needed, then the IDS can reside on the central gateway.
  • If prevention is needed the IPS need to be on the TCU itself since it can be attacked from any neighboring ECU. 

• For Ethernet it can be either on the TCU or on the central gateway with the same considerations as above. This becomes critical since the same IP is used all the way from the attacker to the ECU without any need to switch protocols along the way.

The outgoing traffic from the TCU to the IVN needs to be inspected in any case: 

• CAN-bus or SAE J1939 
  • In cases where only detection is needed, this can be done in the TCU or in the central gateway. 
  • If prevention is required, traffic needs to be inspected in the TCU as the bus topology will propagate the message to all ECUs on the bus without the possibility to further influence the traffic. 
  • One can claim that if the network is properly segregated then the TCU will be part of the less secured connected bus and the central secured gateway will be able to protect the safety critical bus from messages originating from the connected bus. 
• For Ethernet that employs a star topology the IDS/IPS function can be placed either on the TCU or on the central gateway. Placing it on the central gateway might have several benefits since this would be a common IDS/IPS for the entire network and specific rules relevant for the TCU port will be applied to it. 

• TCUs that are not equipped with a cellular modem use the central gateway for cellular communications, therefore there is a need for the outgoing traffic to be inspected. This can be done on the central gateway with the same considerations as above.

Debrief

Since the TCU is a connected device with interfaces both to the outside of the vehicle and to the IVN it is prone to cyber-attacks, and it should be well protected. Protection solutions include a variety of procedural and technological means as detailed in the article. The following table summarizes the various cases and considerations:

Interface	Protocol	Direction	Cellular Modem	Detection/ Prevention	Implementation	Importance
Cellular	IP/cellular	Incoming	Yes	Both	TCU	Very High
Cellular	IP/cellular	Outgoing	Yes	Both	TCU	Low
Cellular	IP/cellular	Incoming	No	Both	TCU/GW	Critical
Cellular	IP/cellular	Outgoing	No	Both	TCU/GW	Low
In-Vehicle	CAN-bus or J1939	Incoming	Both	Detection	TCU/GW	High
In-Vehicle	CAN-bus or J1939	Outgoing	Both	Detection	TCU/GW	Very High
In-Vehicle	CAN-bus or J1939	Incoming	Both	Prevention	TCU	High
In-Vehicle	CAN-bus or J1939	Outgoing	Both	Prevention	TCU	Very High
In-Vehicle	Ethernet	Incoming	Yes	Both	TCU/GW	High
In-Vehicle	Ethernet	Outgoing	Yes	Both	TCU/GW	Very High
In-Vehicle	Ethernet	Incoming	No	Both	TCU/GW	Critical
In-Vehicle	Ethernet	Outgoing	No	Both	TCU/GW	Very High

Table 1 – Summary of cases and considerations

Tier-1s and OEMs need to implement proper security measures if they are to protect the vehicle and the TCU from dangerous attacks. Arilou offers a variety of automotive cybersecurity products including:

• Arilou Sentinel-CAN IDS/IPS for CAN-bus
• Arilou Sentinel-TRK IDS/IPS for SAE J1939
• Arilou Sentinel-ETH IDS/IPS for automotive Ethernet
• Arilou Sentinel-CEL IDS/IPS for cellular interface

This is in addition to other products that provide a protection solution which answers the challenge of securing TCUs, gateways and the IVN in general.

Protected by patents US9881165, US9965636, US10002258, US10534922, EP2832070, US10140450, IL256106 and more pending.

Author

Gilad drives Arilou’s automotive cybersecurity product management and marketing. His focus is on delivering unique, innovative, and novel functionality. Creating ultramodern solutions for in-vehicle cybersecurity protection.

Gilad is an accomplished executive with over 30 years of experience in the cybersecurity and networking industries. Having covered markets in Europe, America and the APAC region, Gilad is a renowned expert in conceptualizing and developing go-to-market strategies.

Published in Telematics Wire