+++ /dev/null
----
-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.
-
Code Review / AGL / documentation.git / blobdiff