diff options
Diffstat (limited to 'security-blueprint/part-7')
| -rw-r--r-- | security-blueprint/part-7/0_Abstract.md | 52 | ||||
| -rw-r--r-- | security-blueprint/part-7/1-BusAndConnectors.md | 68 | ||||
| -rw-r--r-- | security-blueprint/part-7/2-Wireless.md | 244 | ||||
| -rw-r--r-- | security-blueprint/part-7/3-Cloud.md | 107 |
4 files changed, 0 insertions, 471 deletions
diff --git a/security-blueprint/part-7/0_Abstract.md b/security-blueprint/part-7/0_Abstract.md deleted file mode 100644 index f7acbe5..0000000 --- a/security-blueprint/part-7/0_Abstract.md +++ /dev/null @@ -1,52 +0,0 @@ -# Part 7 - Connectivity - -## Abstract - -This part shows different Connectivity attacks on the car. - -<!-- section-todo --> - -Domain | Improvement ------------------------ | ----------------- -Connectivity-Abstract-1 | Improve abstract. - -<!-- end-section-todo --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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 diff --git a/security-blueprint/part-7/1-BusAndConnectors.md b/security-blueprint/part-7/1-BusAndConnectors.md deleted file mode 100644 index 5ab9ab8..0000000 --- a/security-blueprint/part-7/1-BusAndConnectors.md +++ /dev/null @@ -1,68 +0,0 @@ -# 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. - -<!-- section-config --> - -Domain | Tech name | Recommendations ----------------------------------- | --------- | -------------------------------------------------------------------------- -Connectivity-BusAndConnector-Bus-1 | CAN | Implement hardware solution in order to prohibit sending unwanted signals. - -<!-- end-section-config --> - -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. - -<!-- section-config --> - -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. - -<!-- end-section-config --> diff --git a/security-blueprint/part-7/2-Wireless.md b/security-blueprint/part-7/2-Wireless.md deleted file mode 100644 index d3fda8b..0000000 --- a/security-blueprint/part-7/2-Wireless.md +++ /dev/null @@ -1,244 +0,0 @@ -# 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. - -<!-- section-config --> - -Domain | Object | Recommendations ------------------------ | ------ | ------------------------------------------------------------------ -Connectivity-Wireless-1 | Update | Always follow the latest updates of remote communication channels. - -<!-- end-section-config --> - -We will see the following parts: - -- [Wifi](#wifi) - -- [Bluetooth](#bluetooth) - -- [Cellular](#cellular) - -- [Radio](#radio) - -- [NFC](#nfc) - -<!-- section-todo --> - -Domain | Improvement ------------------------ | ------------------------------------------- -Connectivity-Wireless-1 | Add communication channels (RFID, ZigBee?). - -<!-- end-section-todo --> - --------------------------------------------------------------------------------- - -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) - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -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. - -<!-- end-section-config --> - -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. - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -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. - -<!-- end-section-config --> - -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. - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -Domain | Tech name | Recommendations --------------------------------- | --------- | -------------------------- -Connectivity-Wireless-Cellular-1 | GPRS/EDGE | Avoid -Connectivity-Wireless-Cellular-2 | UMTS/HSPA | Protected against Jamming. - -<!-- end-section-config --> - -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. - -<!-- section-config --> - -Domain | Tech name | Recommendations ------------------------------ | --------- | -------------------------------------------- -Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concerning radio. - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -<!-- pagebreak --> - -## 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. - -<!-- section-config --> - -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. - -<!-- end-section-config --> diff --git a/security-blueprint/part-7/3-Cloud.md b/security-blueprint/part-7/3-Cloud.md deleted file mode 100644 index ec7edea..0000000 --- a/security-blueprint/part-7/3-Cloud.md +++ /dev/null @@ -1,107 +0,0 @@ -# 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. - -<!-- section-config --> - -Domain | Object | Recommendations ----------------------------- | -------------- | -------------------------------------- -Application-Cloud-Download-1 | authentication | Must implement authentication process. -Application-Cloud-Download-2 | Authorization | Must implement Authorization process. - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- pagebreak --> - -<!-- section-config --> - -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. - -<!-- end-section-config --> - --------------------------------------------------------------------------------- - -## 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. - -<!-- section-config --> - -Domain | Object | Recommendations ------------------------------ | ----------------------------------------- | --------------------------------- -Application-Cloud-Transport-1 | Integrity, confidentiality and legitimacy | Should implement IPSec standards. - -<!-- end-section-config --> |