This part shows different Connectivity attacks on the car.

Domain Improvement
Connectivity-Abstract-1 Improve abstract.

Acronyms and Abbreviations

The following table lists the terms utilized within this part of the document.

Acronyms or Abbreviations Description
ARP Address Resolution Protocol
BLE Bluetooth Low Energy
CAN Car Area Network
CCMP Counter-Mode/CBC-Mac Protocol
EDGE Enhanced Data Rates for GSM Evolution - Evolution of GPRS
GEA GPRS Encryption Algorithm
GPRS General Packet Radio Service (2,5G, 2G+)
GSM Global System for Mobile Communications (2G)
HSPA High Speed Packet Access (3G+)
IMEI International Mobile Equipment Identity
LIN Local Interconnect Network
MOST Media Oriented System Transport
NFC Near Field Communication
OBD On-Board Diagnostics
PATS Passive Anti-Theft System
PKE Passive Keyless Entry
PSK Phase-Shift Keying
RDS Radio Data System
RFID Radio Frequency Identification
RKE Remote Keyless Entry
SDR Software Defined Radio
SSP Secure Simple Pairing
TKIP Temporal Key Integrity Protocol
TPMS Tire Pressure Monitoring System
UMTS Universal Mobile Telecommunications System (3G)
USB Universal Serial Bus
WEP Wired Equivalent Privacy
WPA Wifi Protected Access


We only speak about the CAN bus to take an example, because the different attacks on bus like FlewRay, ByteFlight, Most and Lin use retro engineering and the main argument to improve their security is to encrypt data packets. We just describe them a bit:

On just about every vehicle, ECUs (Electronic Control Units) communicate over a CAN bus, which is a two-wire bus using hardware arbitration for messages sent on the shared medium. This is essentially a trusted network where all traffic is visible to all controllers and any controller can send any message.

A malicious ECU on the CAN bus can easily inject messages destined for any other device, including things like the instrument cluster and the head unit. There are common ways for hardware to do USB to CAN and open source software to send and receive messages. For example, there is a driver included in the Linux kernel that can be used to send/receive CAN signals. A malicious device on the CAN bus can cause a great number of harmful things to happen to the system, including: sending bogus information to other devices, sending unintended commands to ECUs, causing DOS (Denial Of Service) on the CAN bus, etc.

Domain Tech name Recommendations
Connectivity-BusAndConnector-Bus-1 CAN Implement hardware solution in order to prohibit sending unwanted signals.

See Security in Automotive Bus Systems for more information.


For the connectors, we supposed that they were disabled by default. For example, the USB must be disabled to avoid attacks like BadUSB. If not, configure the Kernel to only enable the minimum require USB devices. The connectors used to diagnose the car like OBD-II must be disabled outside garages.

Domain Tech name Recommendations
Connectivity-BusAndConnector-Connectors-1 USB Must be disabled. If not, only enable the minimum require USB devices.
Connectivity-BusAndConnector-Connectors-2 USB Confidential data exchanged with the ECU over USB must be secure.
Connectivity-BusAndConnector-Connectors-3 USB USB Boot on a ECU must be disable.
Connectivity-BusAndConnector-Connectors-4 OBD-II Must be disabled outside garages.


In this part, we talk about possible remote attacks on a car, according to the different areas of possible attacks. For each communication channels, we describe attacks and how to prevent them with some recommendations. The main recommendation is to always follow the latest updates of these remote communication channels.

Domain Object Recommendations
Connectivity-Wireless-1 Update Always follow the latest updates of remote communication channels.

We will see the following parts:

Domain Improvement
Connectivity-Wireless-1 Add communication channels (RFID, ZigBee?).

For existing automotive-specific means, we take examples of existing system attacks from the IOActive document (A Survey of Remote Automotive Attack Surfaces) and from the ETH document (Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars).



We can differentiate existing attacks on wifi in two categories: Those on WEP and those on WPA.


Domain Tech name or object Recommendations
Connectivity-Wireless-Wifi-1 WEP, PSK, TKIP Disabled
Connectivity-Wireless-Wifi-2 WPA2 and AES-CCMP Used
Connectivity-Wireless-Wifi-3 WPA2 Should protect data sniffing.
Connectivity-Wireless-Wifi-4 PSK Changing regularly the password.
Connectivity-Wireless-Wifi-5 Device Upgraded easily in software or firmware to have the last security update.

See Wifi attacks WEP WPA and Breaking wep and wpa (Beck and Tews) for more information.




Domain Tech name Recommendations
Connectivity-Wireless-Bluetooth-1 BLE Use with caution.
Connectivity-Wireless-Bluetooth-2 Bluetooth Monitoring
Connectivity-Wireless-Bluetooth-3 SSP Avoid using the "Just Works" association model.
Connectivity-Wireless-Bluetooth-4 Visibility Configured by default as undiscoverable. Except when needed.
Connectivity-Wireless-Bluetooth-5 Anti-scanning Used, inter alia, to slow down brute force attacks.

See Low energy and the automotive transformation, Gattacking Bluetooth Smart Devices, Comprehensive Experimental Analyses of Automotive Attack Surfaces and With Low Energy comes Low Security for more information.




Domain Tech name Recommendations
Connectivity-Wireless-Cellular-1 GPRS/EDGE Avoid
Connectivity-Wireless-Cellular-2 UMTS/HSPA Protected against Jamming.

See A practical attack against GPRS/EDGE/UMTS/HSPA mobile data communications for more information.




Domain Tech name Recommendations
Connectivity-Wireless-Radio-1 RDS Only audio output and meta concerning radio.




Domain Tech name Recommendations
Connectivity-Wireless-NFC-1 NFC Protected against relay and replay attacks.
Connectivity-Wireless-NFC-2 Device Disable unneeded and unapproved services and profiles.



Domain Object Recommendations
Application-Cloud-Download-1 authentication Must implement authentication process.
Application-Cloud-Download-2 Authorization Must implement Authorization process.


Domain Object Recommendations
Application-Cloud-Infrastructure-1 Packet Should implement a DPI.
Application-Cloud-Infrastructure-2 DoS Must implement a DoS protection.
Application-Cloud-Infrastructure-3 Test Should implement scanning tools like SATS and DAST.
Application-Cloud-Infrastructure-4 Log Should implement security tools (IDS and IPS).
Application-Cloud-Infrastructure-5 App integrity Applications must be signed by the code signing authority.


For data transport, it is necessary to encrypt data end-to-end. To prevent MITM attacks, no third party should be able to interpret transported data. Another aspect is the data anonymization in order to protect the leakage of private information on the user or any other third party.

The use of standards such as IPSec provides "private and secure communications over IP networks, through the use of cryptographic security services, is a set of protocols using algorithms to transport secure data over an IP network.". In addition, IPSec operates at the network layer of the OSI model, contrary to previous standards that operate at the application layer. This makes its application independent and means that users do not need to configure each application to IPSec standards.

IPSec provides the services below :

An additional means of protection would be to do the monitoring between users and the cloud as a CASB will provide.

Domain Object Recommendations
Application-Cloud-Transport-1 Integrity, confidentiality and legitimacy Should implement IPSec standards.