--- /dev/null
+---
+title: Overview
+---
+
+Modern cars have become a lot more technologically sophisticated and different
+than those of the past. We are seeing a wider range of new features and
+functionality, with a lot more complex software. It is fair to say that the cars
+being introduced to the market today have much more in common with computing
+devices like cell phones, than their predecessors did. Modern car manufacturers
+are also integrating support for a broad range of communication technologies for
+these “connected” cars. With the advent of such vehicles, Linux has become a
+natural choice for the software platform, with Automotive Grade Linux as a
+promising example.
+
+From a security point of view, the remote capabilities of a connected car
+results in a much larger attack surface. This opens a whole new world of
+security vulnerabilities that need to be considered during the architectural
+design. History shows that physical access to a device is sufficient for a
+hacker to gain root privileges. This makes the car a hostile environment.
+
+The Security Blueprint documents the security features that are included as part
+of Automotive Grade Linux (AGL) and identifies areas that need to be addressed
+from a security perspective as part of AGL. It also gives guidance around
+existing technologies and solutions.
+
+Security domains will allow us to create a set of tests verifying the security
+of Automotive Grade Linux.
+
+This document is firstly based on an existing AGL security-blueprint.
+
+**For security to be effective, the concepts must be simple. And by default,
+anything that is not allowed is forbidden.**
+
+We will cover topics starting from the lowest level (_Hardware_) up to the
+highest levels (_Connectivity_ and _Application_). We will move quickly on
+_Hardware_ and _Connectivity_ because this is not supported at our level.
+Solutions of connectivity problems concern updates and secured settings while
+hardware securing is related to the manufacturers.
+
+## Adversaries
+
+Adversaries and attackers within the Automotive space.
+
+- Enthusiast Attackers
+
+Enthusiast attackers have physical access to the Engine Control Units (ECUs) at
+the circuit board level. They can solder ‘mod chips’ onto the board and have
+access to probing tools. They also have information on ECUs that have been
+previously compromised and have access to softwares and instructions developed
+by other members of car modification forums. The goal of the enthusiast hacker
+could be, but is not limited to, adding extra horse power to the car or hacking
+it just for fun.
+
+- Corrupt Automotive Dealers
+
+Corrupt automotive dealers are attackers that have access to the same
+capabilities as enthusiasts, but also have access to the car manufacturer’s
+(OEM) dealer network. They may also have access to standard debugging tools
+provided by the car manufacturer. Their goal may be to support local car theft
+gangs or organized criminals.
+
+- Organized Criminals
+
+Organized criminals have access to all of the above tools but may also have some
+level of control over the internal network at many dealerships. They may have
+hacked and gained temporary control of the Over-The-Air (OTA) servers or the
+In-Vehicle Infotainment (IVI) systems. This is very much like the role of
+organized criminals in other industries such as paid media today. Their goal is
+to extort money from OEMs and/or governments by threatening to disable multiple
+vehicles.
+
+- Malware Developers
+
+Malware developers have developed malicious software to attack and compromise a
+large number of vehicles. The malicious software is usually designed to spread
+from one vehicle to another. Usually, the goal is to take control of multiple
+machines and then sell access to them for malicious purposes like
+denial-of-service (DoS) attacks or theft of private information and data.
+
+- Security Researchers
+
+Security researchers are ‘self-publicized’ security consultants trying to make a
+name for themselves. They have access to standard tools for software security
+analysis. They also have physical access to the vehicle and standard hardware
+debugging tools (Logic Analyzers, Oscilloscopes, etc). Their goal is to
+publicize attacks for personal gain or just to gain personal understanding with
+a sense of helping make things more secure.
+
+## Attack Goals
+
+In today’s connected vehicle, more and more functionality is moving to software
+control, meaning that the threat of attack becomes greater and greater. We see
+car features like navigation and summoning, car access/engine start, and
+motor/ECU upgrades all controlled through software and connections to the cloud.
+The risk of attack is high because there are high value targets in play.
+
+Here, we outline some of the major threats categories along with some sample
+attackers, example attacks, and a relative importance. These threat categories
+are intended to be general examples. There can be many nuances to threat types.
+Additionally, there can be many sub-attacks that eventually lead to these higher
+level attack goals.
+
+| Threat Category | Sample Attacker | Example Attacks | Relative Importance |
+|-------------------------------|-----------------------------------------|-------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------|
+| Vehicle theft | Individual, organized criminals | Send the car to an unplanned destination, get a key for the car, gain control of the unlock mechanism | Reduced likelihood of future vehicle purchases (Profit Later), bad press (Brand Integrity) |
+| Reduced vehicle functionality | Terrorist groups, disgruntled employees | Lock the driver out of the car, cause the car to crash, block access to infotainment system | Inability sell paid-for apps and content (Profit Now), bad press (Brand Integrity), possible loss of life (Physical Injury) |
+| Vehicle hacking | Vehicle owner, competitor | Get content without paying, modify DRM licenses, unlock of after-market features, theft of IP | Loss of sales for content and features (Profit Now), lawsuits from content owners (Profit Later), loss of competitive advantage (Profit Later) |
+| Sensitive asset theft | Organized criminals, blackmailers | Steal credit card numbers, health information, camera data, steal bandwidth | Bad press (Brand Integrity), lawsuits from vehicle owners (Profit Later) |
+
+The Automotive Grade Linux (AGL) initiative builds upon open-source software
+including Linux and Tizen to offer a flexible application framework. However,
+the security provisions of the app framework, Cynara, and the security manager
+only go so far in keeping the biggest threats at bay. As experience has shown,
+providing a constrained app (like that in the Android Open Source Platform) and
+store development flow, signature verification, DAC sandboxing, and MAC (SMACK)
+controls over the platform can have a certain amount of success with the
+security of the system. However, the openness of the system invites many
+researchers, hobbyists and hackers and financially motivated attackers to
+compromise the system for their own gains.
+
+As AGL arrives on modern automobiles, this is inevitably inviting many capable
+actors to modify, attack, and compromise these well thought-out systems and
+their applications. With concerns like safety and security, the auto industry
+cannot afford to go the way of consumer devices like phones and tablets where
+security problems are encountered on a frequent basis. It is imperative to use a
+layered approach and defense-in-depth to protect the system from inevitable
+attack.
+
+## Assets and Security Categorization
+
+This section outlines some of the assets that are likely to be found in the
+vehicle and their relative sensitivity from an attack point of view.
+Additionally, the final column on the right lists some of the recommended
+protection types that can be applied to these types of assets (Note that the
+empty cells refer to the cells above them). A good protection approach will give
+priority to the most sensitive assets, using a defense-in-depth approach to
+cover these assets. Less sensitive assets are treated at a lower priority,
+typically protected with fewer protection techniques. A more fine-grained
+prioritization of the the assets in a concrete vehicle network can be achieved
+with detailed threat analysis which considers the topology of the vehicle
+network and access-controls that are in-place. e.g. the EVITA framework for
+attack trees.
+
+| Asset Category | Examples | Sensitivity | Recommended Protection Types |
+|-------------------|--------------------------------------------------------------------------------|-------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Software | ECU software, infotainment software, OS images | Critical | Key Management, Mutual Asymmetric Authentication, HSM and WhiteBox Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms/ Obfuscation, Integrity Verification, Secure OS |
+| Car Access | Biometric data, car keys | | |
+| Payment Data | Credit cards, User profile critical data | | |
+| Recordings | Internal camera recording, internal audio recording, external camera recording | High | Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms / Obfuscation |
+| User Profile | Usernames and passwords, customization, calendar, contacts | | |
+| Location | GPS coordinates, vehicle usage data | | |
+| Purchased Content | Video, audio, licenses | | |
+| Teleconference | Chat, audio, video | Medium | SW Protection, Program Transforms / Obfuscation, Authenticated encryption for transmission |
+| Vehicle data | Vehicle info, sensor data | | |
+| Navigation data | Static and dynamic maps | | |
+| 3rd party data | Home automation commands, cloud game data | | |
+
+## Hardening term
+
+The term Hardening refers to the tools, techniques and processes required in
+order to reduce the attack surface on an embedded system, such as an embedded
+control unit (**ECU**) or other managed devices. The target for all hardening
+activities is to prevent the execution of invalid binaries on the device, and to
+prevent copying of security related data from the device.
+
+## AGL security overview
+
+AGL roots are based on security concepts. Those concepts are implemented by the
+security framework as shown in this picture:
+
+
+
+--------------------------------------------------------------------------------
+
+# Acronyms and Abbreviations
+
+The following table lists the strongest terms utilized within all this document.
+
+| Acronyms or Abbreviations | Description |
+|---------------------------|-------------------------------------|
+| _AGL_ | **A**utomotive **G**rade **L**inux |
+| _ECU_ | **E**lectronic **C**ontrol **U**nit |
+
+--------------------------------------------------------------------------------
+
+# References
+
+- [security-blueprint](http://docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html).
+ - _http://
+ docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html_
+- **[2017]** - [kernel
+ security](https://www.kernel.org/doc/Documentation/security/).
+ - _https:// www.kernel.org/doc/Documentation/security/_
+- **[2017]** - [Systemd integration and user
+ management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf).
+ - _http:// iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf_
+- **[2017]** - [AGL - Application Framework
+ Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf).
+ - _http:// iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf_
+- **[2017]** - [Improving Vehicle
+ Cybersecurity](https://access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf).
+ - _https://
+ access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf_
+- **[2016]** - [AGL framework
+ overview](http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html).
+ - _http://
+ docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html_
+- **[2016]** -
+ [SecureBoot-SecureSoftwareUpdates](http://iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf).
+ - _http://
+ iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf_
+- **[2016]** - [Linux Automotive
+ Security](http://iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf).
+ - _http://
+ iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf_
+- **[2016]** - [Automotive Security Best
+ Practices](https://www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf).
+ - _https://
+ www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf_
+- **[2016]** - [Gattacking Bluetooth Smart
+ Devices](http://gattack.io/whitepaper.pdf).
+ - _http:// gattack.io/whitepaper.pdf_
+- **[2015]** - [Comprehensive Experimental Analysis of Automotive Attack
+ Surfaces](http://www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf).
+ - _http://
+ www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf_
+- **[2015]** - [Security in Automotive Bus
+ Systems](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf).
+ - _http://
+ citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf_
+- **[2014]** - [IOActive Remote Attack
+ Surface](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf).
+ - _https:// www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf_
+- **[2011]** - [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).
+ - _https://
+ media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf_
+- **[2011]** - [Comprehensive Experimental Analyses of Automotive Attack
+ Surfaces](http://www.autosec.org/pubs/cars-usenixsec2011.pdf).
+ - _http:// www.autosec.org/pubs/cars-usenixsec2011.pdf_
+- **[2010]** - [Relay Attacks on Passive Keyless Entry and Start Systems in
+ Modern Cars](https://eprint.iacr.org/2010/332.pdf).
+ - _https:// eprint.iacr.org/2010/332.pdf_
+- **[2010]** - [Wifi attacks wep
+ wpa](https://matthieu.io/dl/wifi-attacks-wep-wpa.pdf).
+ - _https:// matthieu.io/dl/wifi-attacks-wep-wpa.pdf_
+- **[2008]** -
+ [SMACK](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf).
+ - _http://
+ schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf_
Code Review / AGL / documentation.git / blobdiff