Blog: Automotive Security
Vehicle Telematics Security; getting it right
We spend a LOT of time looking at vehicle telematics security, sometimes on client projects but mostly doing vanilla research on telematics components that we’ve bought ourselves, or investigating our own vehicles.
We have a pile of vehicle TCUs here that’s several feet high, plus a couple of research vehicles here that… don’t quite work like they used to!
You’re probably most familiar with telematics in the shape of the mobile app that you use to check the status of your smart car, or the insurance telematics dongle that checks you’re being a good driver.
There are several components to a telematics system:
- A telematics control unit (TCU) or standalone OBD-II dongle
- A cellular modem and SIM (or eSIM)
- The cellular data carrier
- A telematics service platform (TSP), though some IoT connectivity platforms are used as telematics platforms
- An API, which can be hosted by the TSP or someone else
- A mobile app, often a web app too
Clearly, given the complexity of a telematics environment, there is plenty of opportunity to get security wrong. Defence in depth is the best approach, so let’s look at some of the common fails and how to put them right:
Let’s start with the TCU
A TCU is a hardware device, so it requires solid hardware security. We’ve written extensively about hardware security and firmware extraction.
However, at a minimum we would expect to see:
- A trusted execution environment
- An area of secure storage for keys for example
- A good random source of entropy to seed cryptographic operations
- A locked bootloader
- Restricted network, USB and other connections
- Physically and logically fused programming interfaces (e.g. JTAG / SPI etc)
- Chipsets that resist code readout protection bypass
- Signed firmware, signing checks and a secure OTA update mechanism
- A method to securely identify individual devices. No, not VIN or MAC!
Get these wrong and researchers or hackers will be finding secrets in your TCU
TCU-vehicle interfaces
It is often the interfaces with other devices on the vehicle that create security problems:
For example, the connection from TCU to IVI is often via a USB Ethernet adapter or plain Ethernet. There is often also a CANbus connection; we have rarely seen any security on the CAN interface of a TCU – we can usually just connect.
Several TCUs we’ve looked at have had SSH open via the network connection. Just sometimes we find serial is open as well.
The TCU sometimes has a dedicated CAN gateway between it and the rest of the vehicle. This is a great idea as it adds a layer of defence, though obviously that gateway design needs careful consideration for security
Firmware update processes for TCUs are really varied. Some TCUs update themselves, others are updated via the IVI. Our experience indicates that most TCU firmware updates are signed, though we have on occasion circumvented the code signing and pushed rogue firmware. It’s important to remember that firmware updates are required both for the core TCU and the CAN controller.
Interactions between TCU and TSP
Connectivity out from the TCU to TSP is very varied. There are huge variances between different TSPs as to how they interact with the TCU.
We’ve seen a VPN using per-vehicle certificates with HTTP connections keyed by VIN. This is the way Tesla used to do it, though this has now changed.
We’ve seen a common VPN certificate between vehicles, but with an HTTPS interface that uses per-client certificates.
We’ve seen the TSP connection made using MQTT using per-client certs.
We’ve seen MQTT using VIN only (with no password!)Then we’ve found a TSP available only via private APN, whose private key we’ve cracked (see below).
And even found a TSP accessible over the public internet
Quite a variety and lots of different security issues!
The TSP
Outside of API and endpoint security, the telematics service provider often hosts or manages server infrastructure.
Classic infrastructure security is required here, fortunately it’s rare that major flaws are found.
However, we recently discovered a TSP MQTT endpoint accidentally published on the public internet.
Whilst searching for MQTT on shodan, we stumbled on a testing endpoint from a TSP, though it was carrying some live data.
Fortunately, we had a contact at the OEM and it was quickly taken down.
Now the modem and SIM
There are several known security issues in cellular modems, for example: CVE-2018-11976.
It’s critical that the TCU allows for the baseband modem to be securely updated in light of new vulnerability discoveries.
Physical removal of the SIM can be an issue for fraud also. If the SIM isn’t locked, then it may be possible to access the telematics platform by removing the SIM from a vehicle TCU and using it in your own Mi-Fi device.
eSIMs are increasingly popular, as remote provisioning is easier and arguably much cheaper than handling a physical SIM
An eSIM presents more of a challenge for the hacker, though it’s still perfectly possible to ‘break out’ of the eSIM and present a physical SIM in its place, with a little careful soldering:
The carrier
Probably the most common security defence for the cellular data connection is to implement a private APN.
This is a layer of authentication that restricts which SIMs can access certain devices. It’s based on PPP CHAP, described in RFC1994.
We wrote a blog about cracking private APN keys though in summary if the APN key is <12 characters then it’s trivial to crack and join the private APN.
Long, complex private APN keys are therefore essential. However, it’s also important to consider what would happen in the event that even strong APN keys were compromised, perhaps direct from the firmware, memory or storage on the TCU and/or its cellular modem
How would you recover? Are your APN keys unique per client, or shared and generic?
Carrier segregation
Another common defence is to implement client-client segregation. This is something of a no brainer, although it was missing client segregation that facilitated the Jeep hack by Charlie Miller and Chris Valasek.
Essentially, from any point on the Sprint cellular data network, they could see other Jeep vehicle SIMs and then access the TCUs. Segregation helps defeats that attack.
Segregation can be implemented by the carrier and also by the TSP. An oversight by either of these can expose clients on the platform.
However, it’s very easy to rely too heavily on segregation – there were many issues in the chain that led to the compromise of the Jeep. Segregation was just one of them.
Mobile app and API
As you may have seen from our work on aftermarket vehicle alarms API security flaws are surprisingly common.
By far the most common issue with automotive mobile app APIs is that of the insecure direct object reference (IDOR) – essentially the API fails to check that the request is being carried out by the correct authenticated user.
This allowed us to take over mobile app accounts and then take control of the vehicle alarm, immobiliser and door locks.
API flaws in our experience are less common in TSP APIs, though we have discovered these on occasion. Once you have control of the user account, you have control over the vehicle.
Geo-locate the car, go find it, unlock it, steal it. That’s why TSP API security is so important!
There’s no point dwelling on mobile app security here; it’s been covered many times before. If you need security guidance for your dev team, or need standards to check 3rd party coding, go visit www.owasp.org!
Many developers love to trust the network, especially when it’s perceived to be a private network. Remind everyone about defence in depth.
Disclosure
Vulnerability disclosure is a persistent problem, though can be more of an issue in automotive.
Historically, intellectual property has been fiercely protected by automotive OEMs and their Tier 1&2 suppliers. You can see why: developing the millions of lines of code that sit in a vehicle ECU is expensive. You wouldn’t want it to be stolen!
Hence, it’s common to see ‘closed source’ approaches and minimum viable information disclosed between Tier 1 and OEM. This does not lend itself well to security.
Of late, security-savvy OEMs have negotiated source code access and audit rights with suppliers, in the pursuit of security. This is a good move.
When we find vulnerabilities in automotive components and vehicles, often the biggest obstacle is finding who to report them to. The largest OEMs have disclosure programs, though that’s less common in smaller OEMs, in Tier 1’s and related technology and service suppliers.
In many cases, security vulnerability disclosure is a new thing!
Working out which one of say >100,000 employees to disclose a vulnerability to makes for a real challenge. Which department looks after security? How does one contact them? What if we don’t get a reply?
Where we’ve struggled to disclose an auto vulnerability in the past, we’ve been helped by the Automotive ISAC.
These were created as a result of US Presidential Decision Directive 63 (PDD-63) during the Clinton administration to encourage security information sharing between public and private sectors.
The ISAC has helped broker confidential contact with right people in the right OEM/Tier1 etc. Serious automotive vulnerabilities have been fixed as a result. WIN!
Conclusion
Telematics security is hugely varied, with few standards that appear to define how it should be done securely.
As a result, we see a range of security issues, perhaps a result of the complex supply and development chains.
Fortunately, many forward thinking OEMs, Tier 1s and TSPs have addressed these issues. Ask questions, check, check and check again that the good security processes you have put in place for your internal dev teams and external suppliers have been followed.
I would particularly like to highlight BMW who are presenting at BlackHat USA this year, presenting alongside Keen Security researchers who pwned BMW vehicles last year. That is surely a great example of embracing the research community!
