Automotive & IoT Testing

Cars are likely the most complex connected devices we see. The attack surface is immense – The Internet, mobile, Bluetooth, custom RF protocols, DAB, media files imported over USB, remote diagnostics, telematics, mobile apps… the list goes on:

What can you do to secure such a system?

Mobile application and API

By far the most common source of remotely exploitable vulnerabilities is the mobile application. After all, the mobile application is designed to interact with the car, and often from anywhere in the world. Can we abuse this interface?

Many mobile applications interact with an API server. Sniffing traffic between a device and the API server, or decompiling the mobile application will allow the workings of the API to be discovered and probed.

What are the most common issues in these areas?

• Use of plaintext communications, allowing traffic to be intercepted and tampered with. Transport encryption is vital, especially on mobile devices that often use untrusted Wi-Fi connections.
• Insecure storage of data on the device, allowing an attacker to obtain secrets such as stored passwords, Wi-Fi PSKs, and other keys. Device capture or a malicious app can make this possible.
• Insecure direct object reference – the API uses something like a VIN number or sequential ID without authorization checks to access data.
• Weak device pairing – it’s important that it isn’t possible to pair a new mobile device with an already paired car!
• Debug or hidden functionality – frequently the mobile application contains references to functionality that should never end up in a customer’s hands.
• Outsourced application development, leading to loss of control and oversight of application and API security.

OWASP and others publish guidelines to help secure mobile applications and web APIs. Following these will place you in a stronger position than most.

Bridging CAN buses

Most cars have multiple CAN buses, with one connecting the critical systems such as the engine, brakes and steering, and others connecting less important devices like the door locks, climate control and mirrors.

It’s vital that attackers are kept off the CAN bus controlling the engine itself. But there are points where the buses are connected, either with gateways to allow select commands through, or where a device needs access to multiple buses.

Many cars now have an infotainment unit, offering media playback, mapping and routing, climate control, and so on. In recent years, control of the vehicle itself has been added, with automatic parking, cruise control, sports mode and more being available from the same unit that you control the radio on. This range of functionality means that the infotainment unit can bridge multiple CAN buses.

They are often also the unit that handles Wi-Fi, Bluetooth, and media upload. They are prime targets for attack, and must be strongly secured to avoid serious issues.

Securing embedded Linux systems in a car isn’t particularly different to securing any other Linux system, except you have already put the device into the hands of an attacker. They can obtain firmware and analyse the system at their leisure.

Hardware

Security will rarely be the primary driver behind hardware choice, but there are a number of important considerations to make.

Microcontrollers with embedded flash memory make recovering firmware harder, but offer limited capacity compared to microprocessors with external flash and RAM.

Debug ports such as serial consoles and JTAG are rarely used in production devices, but frequently left in place. Consider physically removing them from devices, blowing fuses to prevent their use, and disabling them within software.

BGA (ball grid array) packages, combined with careful PCB design, can make tapping into signals much more difficult.

Consider using a secure authentication device such as a SAM module, Atmel CryptoAuthentiction device, or Maxim DeepCover device. These devices store keys securely in an authentication scheme.

Automotive devices present particular challenges; not every device is available with the appropriate ratings and approvals for use in vehicles, and supply chain considerations can limit choice.

Firmware

Encrypt and sign your firmware – if an attacker can simply download and unpack your firmware to reverse engineer it, you have missed a useful layer of security. Signing your firmware protects against malicious updates.

Disabled unused functionality – frequently our route into embedded devices is via functionality that a user will never use, such as a serial port, JTAG, telnet, or hidden debug functionality. Remove everything that will not be used from production devices.

Updates

Every system will contain vulnerabilities and bugs. Because of this, it is vital that you can update the firmware in devices in a seamless and secure manner.

In the past, embedded, IoT and automotive systems have not dealt with this well. Frequently firmware updates need to be performed manually, or worse still, by a garage as part of a service.

Firmware update mechanisms in vehicles must be reliable. With upwards of over 100 ECUs in some modern vehicles, bricking any one of these would likely result in an undrivable car.

It’s also important the update mechanism is secure. Frequently firmware updates are a source of vulnerability in themselves – what happens if an attacker can upload their own firmware, or downgrade a system to a version with a previous vulnerability?