--- title: Connectivity --- 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_ | **A**ddress **R**esolution **P**rotocol _BLE_ | **B**luetooth **L**ow **E**nergy _CAN_ | **C**ar **A**rea **N**etwork _CCMP_ | **C**ounter-Mode/**C**BC-**M**ac **P**rotocol _EDGE_ | **E**nhanced **D**ata **R**ates for **GSM** **E**volution - Evolution of **GPRS** _GEA_ | **G**PRS **E**ncryption **A**lgorithm _GPRS_ | **G**eneral **P**acket **R**adio **S**ervice (2,5G, 2G+) _GSM_ | **G**lobal **S**ystem for **M**obile Communications (2G) _HSPA_ | **H**igh **S**peed **P**acket **A**ccess (3G+) _IMEI_ | **I**nternational **M**obile **E**quipment **I**dentity _LIN_ | **L**ocal **I**nterconnect **N**etwork _MOST_ | **M**edia **O**riented **S**ystem **T**ransport _NFC_ | **N**ear **F**ield **C**ommunication _OBD_ | **O**n-**B**oard **D**iagnostics _PATS_ | **P**assive **A**nti-**T**heft **S**ystem _PKE_ | **P**assive **K**eyless **E**ntry _PSK_ | **P**hase-**S**hift **K**eying _RDS_ | **R**adio **D**ata **S**ystem _RFID_ | **R**adio **F**requency **I**dentification _RKE_ | **R**emote **K**eyless **E**ntry _SDR_ | **S**oftware **D**efined **R**adio _SSP_ | **S**ecure **S**imple **P**airing _TKIP_ | **T**emporal **K**ey **I**ntegrity **P**rotocol _TPMS_ | **T**ire **P**ressure **M**onitoring **S**ystem _UMTS_ | **U**niversal **M**obile **T**elecommunications **S**ystem (3G) _USB_ | **U**niversal **S**erial **B**us _WEP_ | **W**ired **E**quivalent **P**rivacy _WPA_ | **W**ifi **P**rotected **A**ccess # Bus 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: - **CAN**: Controller Area Network, developed in the early 1980s, is an event-triggered controller network for serial communication with data rates up to one MBit/s. **CAN** messages are classified over their respective identifier. **CAN** controller broadcast their messages to all connected nodes and all receiving nodes decide independently if they process the message. - **FlewRay**: Is a deterministic and error-tolerant high-speed bus. With a data rate up to 10 MBit/s. - **ByteFlight**: Is used for safety-critical applications in motor vehicles like air-bags. Byteflight runs at 10Mbps over 2 or 3 wires plastic optical fibers. - **Most**: Media Oriented System Transport, is used for transmitting audio, video, voice, and control data via fiber optic cables. The speed is, for the synchronous way, up to 24 MBit/s and asynchronous way up to 14 MBit/s. **MOST** messages include always a clear sender and receiver address. - **LIN**: Local Interconnect Network, is a single-wire subnet work for low-cost, serial communication between smart sensors and actuators with typical data rates up to 20 kBit/s. It is intended to be used from the year 2001 on everywhere in a car, where the bandwidth and versatility of a **CAN** network is not required. On just about every vehicle, **ECU**s (**E**lectronic **C**ontrol **U**nits) 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](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf) for more information. # Connectors 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. # Wireless 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: - [Wifi](#wifi) - [Bluetooth](#bluetooth) - [Cellular](#cellular) - [Radio](#radio) - [NFC](#nfc) 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](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf)) and from the ETH document ([Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars](https://eprint.iacr.org/2010/332.pdf)). - [Telematics](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A40%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) - [Passive Anti-Theft System (PATS)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A11%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C574%2C0%5D) - [Tire Pressure Monitoring System (TPMS)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A17%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) - [Remote Keyless Entry/Start (RKE)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A26%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D) - [Passive Keyless Entry (PKE)](https://eprint.iacr.org/2010/332.pdf) -------------------------------------------------------------------------------- ## Wifi ### Attacks We can differentiate existing attacks on wifi in two categories: Those on **WEP** and those on **WPA**. - **WEP** attacks: - **FMS**: (**F**luhrer, **M**antin and **S**hamir attack) is a "Stream cipher attack on the widely used RC4 stream cipher. The attack allows an attacker to recover the key in an RC4 encrypted stream from a large number of messages in that stream." - **KoreK**: "Allows the attacker to reduce the key space". - **PTW**: (**P**yshkin **T**ews **W**einmann attack). - **Chopchop**: Found by KoreK, "Weakness of the CRC32 checksum and the lack of replay protection." - **Fragmentation** - **WPA** attacks: - **Beck and Tews**: Exploit weakness in **TKIP**. "Allow the attacker to decrypt **ARP** packets and to inject traffic into a network, even allowing him to perform a **DoS** or an **ARP** poisoning". - [KRACK](https://github.com/kristate/krackinfo): (K)ey (R)einstallation (A)tta(ck) ([jira AGL SPEC-1017](https://jira.automotivelinux.org/browse/SPEC-1017)). ### Recommendations - Do not use **WEP**, **PSK** and **TKIP**. - Use **WPA2** with **CCMP**. - Should protect data sniffing. 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](https://matthieu.io/dl/wifi-attacks-wep-wpa.pdf) and [Breaking wep and wpa (Beck and Tews)](https://dl.aircrack-ng.org/breakingwepandwpa.pdf) for more information. -------------------------------------------------------------------------------- ## Bluetooth ### Attacks - **Bluesnarfing** attacks involve an attacker covertly gaining access to your Bluetooth-enabled device for the purpose of retrieving information, including addresses, calendar information or even the device's **I**nternational **M**obile **E**quipment **I**dentity. With the **IMEI**, an attacker could route your incoming calls to his cell phone. - **Bluebugging** is a form of Bluetooth attack often caused by a lack of awareness. Similar to bluesnarfing, bluebugging accesses and uses all phone features but is limited by the transmitting power of class 2 Bluetooth radios, normally capping its range at 10-15 meters. - **Bluejacking** is the sending of unsolicited messages. - **BLE**: **B**luetooth **L**ow **E**nergy [attacks](https://www.usenix.org/system/files/conference/woot13/woot13-ryan.pdf). - **DoS**: Drain a device's battery or temporarily paralyze the phone. ### Recommendations - Not allowing Bluetooth pairing attempts without the driver's first manually placing the vehicle in pairing mode. - Monitoring. - Use **BLE** with caution. - For v2.1 and later devices using **S**ecure **S**imple **P**airing (**SSP**), avoid using the "Just Works" association model. The device must verify that an authenticated link key was generated during pairing. 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](http://www.ti.com/lit/wp/sway008/sway008.pdf), [Gattacking Bluetooth Smart Devices](http://gattack.io/whitepaper.pdf), [Comprehensive Experimental Analyses of Automotive Attack Surfaces](http://www.autosec.org/pubs/cars-usenixsec2011.pdf) and [With Low Energy comes Low Security](https://www.usenix.org/system/files/conference/woot13/woot13-ryan.pdf) for more information. -------------------------------------------------------------------------------- ## Cellular ### Attacks - **IMSI-Catcher**: Is a telephone eavesdropping device used for intercepting mobile phone traffic and tracking location data of mobile phone users. Essentially a "fake" mobile tower acting between the target mobile phone and the service provider's real towers, it is considered a man-in-the-middle (**MITM**) attack. - Lack of mutual authentication (**GPRS**/**EDGE**) and encryption with **GEA0**. - **Fall back** from **UMTS**/**HSPA** to **GPRS**/**EDGE** (Jamming against **UMTS**/**HSPA**). - 4G **DoS** attack. ### Recommendations - Check antenna legitimacy. 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](https://media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf) for more information. -------------------------------------------------------------------------------- ## Radio ### Attacks - Interception of data with low cost material (**SDR** with hijacked DVB-T/DAB for example). ### Recommendations - Use the **R**adio **D**ata **S**ystem (**RDS**) only to send signals for audio output and meta concerning radio. Domain | Tech name | Recommendations ----------------------------- | --------- | -------------------------------------------- Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concerning radio. -------------------------------------------------------------------------------- ## NFC ### Attacks - **MITM**: Relay and replay attack. ### Recommendations - Should implements protection against relay and replay attacks (Tokens, etc...). - Disable unneeded and unapproved services and profiles. - NFC should be use encrypted link (secure channel). A standard key agreement protocol like Diffie-Hellmann based on RSA or Elliptic Curves could be applied to establish a shared secret between two devices. - Automotive NFC device should be certified by NFC forum entity: The NFC Forum Certification Mark shows that products meet global interoperability standards. - NFC Modified Miller coding is preferred over NFC Manchester coding. 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. # Cloud ## Download - **authentication**: Authentication is the security process that validates the claimed identity of a device, entity or person, relying on one or more characteristics bound to that device, entity or person. - **Authorization**: Parses the network to allow access to some or all network functionality by providing rules and allowing access or denying access based on a subscriber's profile and services purchased. Domain | Object | Recommendations ---------------------------- | -------------- | -------------------------------------- Application-Cloud-Download-1 | authentication | Must implement authentication process. Application-Cloud-Download-2 | Authorization | Must implement Authorization process. -------------------------------------------------------------------------------- ## Infrastructure - **Deep Packet Inspection**: **DPI** provides techniques to analyze the payload of each packet, adding an extra layer of security. **DPI** can detect and neutralize attacks that would be missed by other security mechanisms. - A **DoS** protection in order to avoid that the Infrastructure is no more accessible for a period of time. - **Scanning tools** such as **SATS** and **DAST** assessments perform vulnerability scans on the source code and data flows on web applications. Many of these scanning tools run different security tests that stress applications under certain attack scenarios to discover security issues. - **IDS & IPS**: **IDS** detect and log inappropriate, incorrect, or anomalous activity. **IDS** can be located in the telecommunications networks and/or within the host server or computer. Telecommunications carriers build intrusion detection capability in all network connections to routers and servers, as well as offering it as a service to enterprise customers. Once **IDS** systems have identified an attack, **IPS** ensures that malicious packets are blocked before they cause any harm to backend systems and networks. **IDS** typically functions via one or more of three systems: 1. Pattern matching. 2. Anomaly detection. 3. Protocol behavior. 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. -------------------------------------------------------------------------------- ## Transport 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 : - Confidentiality: A service that makes it impossible to interpret data if it is not the recipient. It is the encryption function that provides this service by transforming intelligible (unencrypted) data into unintelligible (encrypted) data. - Authentication: A service that ensures that a piece of data comes from where it is supposed to come from. - Integrity: A service that consists in ensuring that data has not been tampered with accidentally or fraudulently. - Replay Protection: A service that prevents attacks by re-sending a valid intercepted packet to the network for the same authorization. This service is provided by the presence of a sequence number. - Key management: Mechanism for negotiating the length of encryption keys between two **IPSec** elements and exchange of these keys. 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.