X-Git-Url: https://gerrit.automotivelinux.org/gerrit/gitweb?a=blobdiff_plain;ds=sidebyside;f=docs%2F2_Architecture_Guides%2F2_Security_Blueprint%2F0_Overview.md;fp=docs%2F2_Architecture_Guides%2F2_Security_Blueprint%2F0_Overview.md;h=0000000000000000000000000000000000000000;hb=8be9db6f309e1e1b547e187c5db6ceac15f85a50;hp=ee5e7f7e00252a30e6865d4b06ea2cb5ab3949ec;hpb=e660399f8b909146a699e44eb340b8c0b7e7f12f;p=AGL%2Fdocumentation.git diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/0_Overview.md b/docs/2_Architecture_Guides/2_Security_Blueprint/0_Overview.md deleted file mode 100644 index ee5e7f7..0000000 --- a/docs/2_Architecture_Guides/2_Security_Blueprint/0_Overview.md +++ /dev/null @@ -1,250 +0,0 @@ ---- -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: - -![AGL architecture](images/WhiteBoxArchi.png) - --------------------------------------------------------------------------------- - -# 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_