Fixing the index numbering

Fixing the index numbering for all documentation

Bug-AGL: [SPEC-4470]
Signed-off-by: Vinod Ahuja <vahuja@unomaha.edu>
Change-Id: I96b482a3ab598f0739c692e301de66c0553ba0e4
Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/28118
Reviewed-by: Walt Miner <wminer@linuxfoundation.org>
Reviewed-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Tested-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>

1 files changed, 487 insertions, 0 deletions

diff --git a/docs/3_Architecture_Guides/2_Security_Blueprint/8_Connectivity.md b/docs/3_Architecture_Guides/2_Security_Blueprint/8_Connectivity.md
new file mode 100644
index 0000000..076c0e0
--- /dev/null
+++ b/docs/3_Architecture_Guides/2_Security_Blueprint/8_Connectivity.md
@@ -0,0 +1,487 @@
+---
+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.
+