Things You Must Know For Vehicle Hacking: PART 4
IN-VEHICLE CYBERSECURITY SOLUTIONS: Key Management Systems and IDS/IPS
< Intruders Here, Everywhere! />
Let’s start with IDS/ IPS systems. Intrusion Detection Systems and Intrusion Prevention Systems are nearly everywhere and are now an indispensable part of the IT stack. Vehicle security is also one of the domains that which IDS and IPS are used.
Using Juniper Network’s definition, intrusion detection is the process of monitoring the events occurring in your network and analyzing them for signs of possible incidents, violations, or imminent threats to your security policies. Intrusion prevention is the process of performing intrusion detection and then stopping the detected incidents. These security measures are available as intrusion detection systems (IDS) and intrusion prevention systems (IPS), which become part of your network to detect and stop potential incidents.
In vehicular context, IDPS (IDS & IPS) are not only applicable to the ethernet but also to CAN protocol. Let’s compare what are the pros and cons of IDPS in both technologies.
As mentioned in previous posts, CanBus is a Bus topology which means when a message leaves an ECU, it is guaranteed to reach any neighbor ECU on the same bus. Meaning there is no way to stop an attack using software that resides in the gateway since it is just listening to the traffic. The gateway can only stop the propagation of the message from one bus to another but not on the same bus.
On the other hand, the automotive ethernet is a star topology meaning on each port there is exactly one device is connected any device that is sent by the device can be inspected by the gateway. Since ethernet is much more speedy compared to the Can, any IDS or IPS system needs lots of horsepowers to be able to undertake full or partial analysis. Let me remind you that the message length in Can-bus is only 8 bytes (60 for Can FD) compared to Ethernet which is 1500 bytes.
In terms of source identification, there is no source ID in Canbus there is only Message-ID. So you cannot tell who sent the message. This can be done using encapsulated protocols like J1939 but the standard does not have message origin identification. Can bus does not have any specific message destination as well, it only has message-id which is a multicast address that anyone can listen to. Automotive-ethernet, on the other hand, is a distinct unicast which means it has source and destination MAC addresses and ethernet supports both unicast and multicast hence, with ethernet it is much easier to detect the source of a message. Beware that automotive ethernet is not necessarily about ethernet, it is about all the networking. For example, on top of ethernet sits MAC, and then on top of that sits IP, on top of that sits TCP/IP or UDP/IP. At the application level, there is DoIP.
<CAN vs Ethernet Work Process/>
IDS/IPS is designed to counter an attacker manipulating network traffic via a malicious application, hacked ECU, or another controller.
It has 3 steps:
- It learns the normal.
- It monitors the network traffic and the Routing function of gateway rules.
- It detects anomalies based on deviation from normal. Prevents by discarding frames when possible.
Both of them require recordings to generate rules out of it. Rule generation is simple in CAN Bus(but can get complicated if J1939 is used because dynamic addressing comes into play) and is complex in ethernet due to network nature (MAC address, DHCP, DoIP, etc. protocols)
CAN is static, predictive and deterministic and uses whitelisting. But ethernet is more volatile, it uses both black and white lists simultaneously, and also implements signature-based detection which is not implemented by CanBus.
<CAN vs Ethernet IDPS Architecture />
IDS systems are essentially SDKs integrated into ECU. This ECU can be an existing ECU, like a gateway or a dedicated ECU attached to the CAN bus. The incoming message/frame is routed to IDS/IPS to be processed. the IDS/IPS inspects the message/frame and returns its findings with the associated information. In case of anomaly, an event is reported. When configured as IPS, when possible, the anomalous packet is discarded.
CAN message is determined to be passing or not based on message ID, if valid, it is passed else, it is discarded. There is a possibility that a compromised ECU can send a message with a valid ID and if it is not a periodic message, it is not possible to determine it was an attack. Ethernet Packet is filtered based on filtering rules initially. if it is not in white and blacklist, the default rule applies.
As for the message flow capture, in CAN, it is relatively easy to validate flow, with requests and responses, and order of messages. Impossible to determine ECU origin. Need to add a digital signature using 3rd party compression software or SecOC.
For ethernet, on the other hand, to capture a packet flow, you need to follow full OSI 7 layers individually and another problem is many fields are dynamically assigned per instance.
Are IDPS the most important security mechanism?
There is hype about IDS and IPS systems. But instead of going through IDS, you can start with creating the path to transport from vehicles to your backend and then incrementally add and look at your data.
IPS on the other hand has actively intervening mechanisms that can cause vehicles (especially autonomus cars) to go out of control, hence not desirable.
IDS is only a tool in your security toolbox, and you need to create a strategy that centers it.
< In-Vehicle Key Management Systems />
Why a strong key management system is important? In the next post, we will be talking about the 2015 Jeep Cherokee hack as a case study, but the following reasons should suffice anyhow.
- Do not forget that we have remote access to the vehicles.
- Also, you have customer data collected and maybe stored.
- Now we have internal networks which means easy internal attack traversal (lateral movement.)
- Access to ECU applications means theft of intellectual property.
- We have more software, meaning a wider attack surface.
Some ways to mitigate possible attacks are:
- Debug Access Protection. This may help to prevent gain access to car network. (especially JTAG and UART)
- Reverse Engineering Protection. (through encryption and/or obfuscation of Data-at-rest)
- Add Secure Boot for preventing malicious software from being flashed over ethernet. (checking signatures)
- use SecOC.
- The common approach should be Distributed Trust.
- Code Signing.
Distributed trust boils down to Vehicle Key Management Systems. This means secure generation, storage, distribution, and destruction of keys.
At its core, Vehicle Key Management Systems are creating, distributing, and storing cryptographic material.
Creating cryptographic material can be symmetric, asymmetric, password-protected, or certificate protected. It can be platform, product, or even ECU specific(most complex but most secure). And never forget that Good Enough Randomness is hard to achieve. (random bit generation).
Distributing cryptographic material entails that keys should be accessible to control units and stored in the control units in manufacturing.
ECUs are mostly manufactured on-premies at the supplier sites but they belong to OEMs so secure onboard comms is something OEMs have to make sure it works. In the final assembly of the card, all keys distributed MUST fit together
When Storing cryptographic material, access to locked control units must be possible after shipping the car, cryptographic material must be stored securely on-chip, and hardware security must be supported with software.
Also, all this process should observe the CIA triad principle.
<Key Management Systems Architecture />
The main Key Management Systems Architecture is divided into 3 layers with each and every one of them has its specific roles and responsibilities.
The first layer is Backend & Middleware layer.
The main component is the database which is used for creating and storing the cryptographic material. It is usually set with High Availability in mind(Remember CIA Triad?). Also, for better security, Hardware Security Modules (HSM) is used alongside databases. Databases are used because HSM are small in memory to keep all these data. HSM on the other hand is in charge of data-at-rest encryption and randomness generation.
Key Distribution and Management are taken care of by the attached services/applications. For this purpose, different interfaces are used and REST API, KMS-interfaces, OPENPGP for eMAil, proprietary interfaces etc. are few to name. Interfaces may implement server-side services like encryption and signing.
The second layer is the Frontend layer.
Frontend directly talks to the backend to undertake tasks like:
- Getting keys and flash them to ECUs in manufacturing.
- Caching OEM-keys for asynchronous supplier-side manufacturing.
- Retrieve unit-specific passwords for root-cause analysis.
The punchline for the security is that you want to store them in the backend but use it on the frontend for the key protection.
Depending on the use case, the frontend side application can be a manual GUI, another machine, or some library that is used by another software.
Sometimes even offline use-cases have to be supported by the VKMS like in-line flashing verification checks.
The third and the final layer is In-Vehicle(network and chip) layer:
This layer consists of Processor + Flash/Rom + HSM.
Every crypto material managed by the VKMS will eventually be distributed into an ECU for in-vehicle purposes like SecOC, SecureBoot, and IP-Protection. Certain modules will always be present on-chip for security and practical reasons. These are secure ways of storing (Secure Hardware Extension(SHE), Software-based HSM), A library/stack of hardware providing cryptographic services. (AUTOSAR Crypto Stack, Cryptoprocessor). HSM on the chip is required for the protection of the keys stored on the chip so they are not extracted or extracted easily. SHE is specifically designed for this purpose.
Like if not stored on-chip, how will it execute secure boot checks or signature checks.
Depending on the VKMS implementation, on-chip software might be in or out of scope. But in any case, you need to address it as a holistic problem.
Now after all these different implementations and solutions, the real question arises. Does every protocol need security built-in?
For example, DoIP(lives in OSI 5–7) reaches out of the vehicle so it makes sense to secure it. You can enforce security within or support it with TLS below it, or a combination of both.
But say, do we need to secure UDP Network Management(UDPnm) for network management by building security into the protocol? Unlikely.
Main idea is, that if two sides of the bridge are secure, you don’t need security for the bridge. Because if you implement MacSec, which protects everything sitting on top of it, an external attacker cannot modify antyhing.
For an internal attacker, who is controlling a compromised ECU, say Head Unit, you can use ACL or sort of firewalls. You don't put these countermeasures on the TCP layer, but below it to protect it. So, you DONT need built-in security for everything as long as you think security first and design things accordingly. Yet the punchline is ‘Make sure you have access control and filtering’.
Next up will be the case study for 2015 Jeep Cherokee hack. We will see the details and roam around what we have been going through in these 4 chapters.
Until next time...
PS: If you haven’t already, please take a look at the previous chapters: