diff options
| -rw-r--r-- | sec-blueprint/01-overview.md | 169 | ||||
| -rw-r--r-- | sec-blueprint/02-adversaries.md | 62 | ||||
| -rw-r--r-- | sec-blueprint/02-threat-analysis.md | 48 | ||||
| -rw-r--r-- | sec-blueprint/03-attack-surfaces.md | 36 | ||||
| -rw-r--r-- | sec-blueprint/03-threat-analysis.md | 347 | ||||
| -rw-r--r-- | sec-blueprint/04-adversaries.md | 49 | ||||
| -rw-r--r-- | sec-blueprint/04-security-concepts.md | 88 | ||||
| -rw-r--r-- | sec-blueprint/05-platform-security.md | 162 | ||||
| -rw-r--r-- | sec-blueprint/05-security-concepts.md | 466 | ||||
| -rw-r--r-- | sec-blueprint/06-application-security.md | 67 | ||||
| -rw-r--r-- | sec-blueprint/06-plateform-security.md | 143 | ||||
| -rw-r--r-- | sec-blueprint/07-application-security.md | 131 | ||||
| -rw-r--r-- | sec-blueprint/07-system-hardening.md (renamed from sec-blueprint/08-Hardening.md) | 258 | ||||
| -rw-r--r-- | sec-blueprint/App-flow.png | bin | 0 -> 73545 bytes | |||
| -rw-r--r-- | sec-blueprint/App_signing_flow.png | bin | 0 -> 154923 bytes | |||
| -rw-r--r-- | sec-blueprint/index.md | 14 |
16 files changed, 906 insertions, 1134 deletions
diff --git a/sec-blueprint/01-overview.md b/sec-blueprint/01-overview.md index d16b26c..7a71cee 100644 --- a/sec-blueprint/01-overview.md +++ b/sec-blueprint/01-overview.md @@ -1,7 +1,7 @@ --- title : Security BluePrint Overview -date : 2016-07-06 +date : 2017-07-07 category: security tags: security, architecture, automotive, linux layout: techdoc @@ -13,127 +13,46 @@ layout: techdoc 1. TOC {:toc} -## Introduction - -### Abstract - -This document describes how it is possible to create reasonably secured connected cars using already available Open Source components. -The complexity attached to such project is clearly exposed for each step and may seem a quite heavy reading. -Fortunately ready made solutions are coming on the market (Open Source and Proprietary), enabling short cuts for many of us. - -The documentation mostly focusses on the embedded side of the problem leaving the cloud components and manufacturing processes for further study. - -### The risk is real - -Connected cars, to be accepted by users and keeping under control liability of the Automotive Industry will have to solve many issues ranging from physical, direct, and remote and indirect cloud attacks. -A large section of unsolved technical security challenges, lies in car connectivity to user owned devices and well as to cloud. -The Automotive Industry, by opposition to those operating in cloud and mobiles businesses, has little experience of security issues and no long return of experience. -Proven solutions derived from the IT world are for most of them, inapplicable. - -For many people the Cyber Security risk for the Automotive industry is still at best not understood and unfortunately more often, simply ignored. -If the Fiat-Chrysler cyber car jacking has forced the industry to open their eyes, it is just a beginning. - -- 24 Jul 2015 Hacking a radio in a car: - *"… the computer systems built into Fiat Chrysler cars: the flaw can - be exploited by an attacker to wirelessly take control of the - engine, brakes and entertainment system ..." - "… the US National Highway Traffic Safety Administration has - recalled 1.4 million of the manufacturer's cars after a dangerous - software flaw was revealed just days ago..."* - <http://www.theregister.co.uk/2015/07/24/chrysler_recall_for_wireless_hacking_hole/> -- One day (likely not that far) we could see car blocked by - ramsomware, or cyber terrorism using cars as weapon if nothing is - done. - -As malicious hackers or terrorists are smart and well organised, we know -that if we let them enter a system, even by a side door, they will work -they way to the more juicy part of the system to monetise their work. - -As connected cars are going to interact with our phone and the cloud, -they will become a vector of attack not very dissimilar to the video -surveillance cameras in recent cyber attack with the added complexity -that tracking a mobile source will be more complex. - - <http://www.theregister.co.uk/2016/10/10/iot\_botnet/> - -## Scope - -Designing Connected cars without enabling a high level of security is -not acceptable and will be soon a key market requirement for any -respectable automotive company. -AGL is aimaing at providing a reasonable level of security by default. -The level of default security will evolve with the time and future releases to align with market expectations and needs. - -In order to converge on such an open question, we need to take -assumptions which are realistic for the targeted domain, in our case a -Connected Car. - -The assumptions selected are the following: - -- Secure boot with Hardware chain of trust. -- recent LTSI based kernel (4.1.x, 4.9.x, ...) -- kernel and middleware securely updated once in a while - in the future that rate will increase a lot. -- Middleware and Application compiled with up-to-date compiler - protections activated and checked through a static analysis process. -- Rootfs (/) in read-only, /home encrypted., integrity protected by - IMA/EVM -- Customisation reduced to Apps vetted by the manufacturer's store -- 24/7 connection to the outside world (sensor and internet). -- Developer mode not active by default. -- There is no administrator (only a user) for the product which mostly - run non attended. - -We can see that in such configuration, the base OS (kernel&middleware) -represents a well guarded entry point for a malicious hacker. -The combination of trusted boot, integrity enforcement and rootfs in ro, -creates a set a garded walls to anyone, who would try to modify valid -code on the product. - -The main risks will lie in the exploitation of Zero Days security holes -in the base OS (by definition correction and update is always an after -the fact event in that case) and the Apps store where vetting process -cannot afford to be that solid if real flexibility is required. - -We cannot completely avoid external activation of the base OS security -holes (publicly known or not) but we can limit the actions and reach of -any compromised code. - -We will start by reducing the surface of attack by designing a product -without open backdoors (e.g. cars drivers do not need a ssh connection -nor tcpdump), so why to install the such development code on the image, -and continue by reducing the capabilities which can be claimed by any -code to the minimum required. -This can be done by running the code with a non administrator’s user ID -(non root) and by removing the unrequired capabilities and file access -at code launch via Mandatory Access Control (MAC) and the Posix Capabilities. -In the case of Smack, the general concept is to associate different -label to specific code. -As the MAC label cannot be changed by theprocess itself, it enables the security rules set to enforce the respect -of the predefine code behaviour. -Code with connects to the outside world -by any mean, should first benefit of these special security -configurations. -The default policy should be good enough cover the security needs of most non connecting code. - -Once the surface of attack is reduced, you need to reduce possible -damage when a malicious user will have found his way in. -*Please remember that in security the question is not to know if someone will -break in, but rather when, how you will detect it, and how to limit -potential damages.* - -In this phase we will take care to limit options for a malicious user to -move sideways and activate code that would help him to get more control -over the system. -We will pay a detailed attention to any code which can -grant more privileges, change MAC label, create new user, install new -Apps or update. -Those types of code are normally called from a very -limited entry points in the system and once again the MAC system is your -best friend when it comes to restrict activation from valid vector. - -## Glossary - -DAC Discretionaly Access Control -MAC Mandatory Access Control -SoC System on Chip +# Introduction + +## Security in Modern Connected Vehicles + +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. + +## Connected Car: A Hostile Environment + +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. + +## Abstract + +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. Finally it provides recommendations and requirements for +areas that are out of scope of this document and AGL. + + +# Scope +This document will focus on the following key areas: + +* Adversaries - Common categories of Attackers +* Threat Analysis - Common threats to AGL system +* Security Concepts - Technologies and practices that can be used to mitigate attacks +* Platform Security - How AGL applies these security concepts for platform security +* Application Security - How AGL applies these security concepts for application security +* System Hardening - Recommendations on hardening AGL systems diff --git a/sec-blueprint/02-adversaries.md b/sec-blueprint/02-adversaries.md new file mode 100644 index 0000000..3ece5bb --- /dev/null +++ b/sec-blueprint/02-adversaries.md @@ -0,0 +1,62 @@ +--- + +title : Adversaries +date : 2017-07-07 +category: security +tags: security, architecture, automotive, linux +layout: techdoc + +--- + +**Table of Content** + +1. TOC +{:toc} + +This section lists some of the 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 automitive 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. + diff --git a/sec-blueprint/02-threat-analysis.md b/sec-blueprint/02-threat-analysis.md deleted file mode 100644 index c2e4372..0000000 --- a/sec-blueprint/02-threat-analysis.md +++ /dev/null @@ -1,48 +0,0 @@ ---- - -title : Treat Analysis & Coverage -date : 2016-06-30 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -## Factory/Dealer installed applications - -## Factory/Dealer installed application updates - -## Factory/Dealer installed application removal - -## User installed applications - -## User installed application update - -## User installed application removal - -## Application Data security - -## Application Data upgrades - -## Vehicle bus write access by Factoy applications - -## Vehicle bus write access by User applications - -## Vehicle bus read access by Factoy applications - -## Vehicle bus read access by User applications - -## Platform software update failure due to corrupted update package - -## Platform software update failure due to corrupted invalid package - -## Attack from the Cloud - -## Man in the middle - -## Malicious CAN / USB devices diff --git a/sec-blueprint/03-attack-surfaces.md b/sec-blueprint/03-attack-surfaces.md deleted file mode 100644 index b82efe1..0000000 --- a/sec-blueprint/03-attack-surfaces.md +++ /dev/null @@ -1,36 +0,0 @@ ---- - -title : Attack Surfaces -date : 2016-06-30 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -## OS installation at factory Key leak risk - -## OS boot - -## OS upgrade - -## Device bus (static and autodetection) USB - -## "Wireless connections (Wifi## Bluetooth## ...)" - -## "Wired connection (Can## Serial## Eth ...)" - -## OS-Device file system - -## User data (local & cloud) - -## Application FW - -## Application Store - -## Application data (local & Cloud) diff --git a/sec-blueprint/03-threat-analysis.md b/sec-blueprint/03-threat-analysis.md new file mode 100644 index 0000000..deab845 --- /dev/null +++ b/sec-blueprint/03-threat-analysis.md @@ -0,0 +1,347 @@ +--- + +title : Threat Analysis & Coverage +date : 2017-07-07 +categories: architecture, automotive +tags: architecture, automotive, linux +layout: techdoc + +--- + +**Table of Content** + +1. TOC +{:toc} + +# Introduction + +The Automotive Grade Linux (AGL) platform has set out to be an open source solution for automotive applications. With an open system come many avenues of attack by the spectrum of attackers, from hobbyists to university students to well-funded hacking organizations. AGL introduces an application framework and has adopted the Cynara system from Tizen, which uses SMACK as its kernel-level underpinnings. + +This document first looks at attack goals and how the intruder may get to these goals. Then attacks on specific assets of the system are considered. Further, the analysis looks at the attack surface and possible branches into these assets. As these avenues are analyzed, we discuss mitigations individually and broader approaches, such as defense-in-depth which resists an attacker's ability to attain their goals by deploying *overlapping* defenses. + +This threat analysis was written from an investigation of the following sources of information: + +* AGL on-line documentation. +* The AGL source code-base, Charming Chinook Release, made available on Jan 6, 2017. +* Tizen documentation, on-which the security features of AGL have been based. + +## 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) | + +## 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 prioritziation of the the assets in a concrete vehicle network can be achived 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 | | | + +# Execution Environment + +The execution environment used for AGL leverages a Linux kernel combined with an application framework. The foundation of the environment is a pre-configured Linux kernel which will inherit any existing vulnerabilities associated with the kernel. The following are, therefore, important to the system: + +## Kernel Version + +The choice of kernel version for the AGL system is essential to its security. Depending on the type of board and eventual production system, different kernel versions are used. For example, one of the systems under study uses the Linux kernel version 3.10, while another uses the Linux kernel version 4.4. For the Linux kernel version 3.10.31, there are [25 known vulnerabilities](https://www.cvedetails.com/version/194332/Linux-Linux-Kernel-3.10.31.html). These vulnerabilities would allow an attacker to gain privileges, bypass access restrictions, allow memory to be corrupted, or cause denial of service. In contrast, the Linux kernel version of 4.4 has [many fewer known vulnerabilities](https://www.cvedetails.com/version/190796/Linux-Linux-Kernel-4.4.html). For this reason, we would in general recommend the later kernel version as a basis for the platform. + +Note that, although there are fewer *known* vulnerabilities in the most recent kernel versions there may be many unknown vulnerabilities underlying. A rule of thumb is to update the kernel as much as possible to avoid the problems you do know, but you should not be complacent in the trust that you place in it. A defense-in-depth approach would then apply. + +If there are constraints and dependencies in upgrading to a newer kernel version (e.g. device drivers, board support providers) and you are forced to an older Linux kernel version, there need to be additional provisions made to reduce the risk of kernel exploits, which can include memory monitoring, watch-dog services, and system call hooking. In this case, further defense-in-depth techniques may be required to mitigate the risk of attacks to known vulnerabilities, which can also include runtime integrity verfication of components that are vulnerable to tampering. + +## Kernel Build Configuration + +The kernel build configuration is extremely important for determining the level of access to services and to reduce the breadth of the attack surface. Linux contains a great and flexible number of capabilities and this is only controlled through the build configuration. For example, the *CONFIG_MODULES* parameter allows kernel modules to be loaded at runtime extending the capabilities of the kernel. This capability needs to be either inhibited or controlled at runtime through other configuration parameters. For example, *CONFIG_MODULE_SIG_FORCE=y* ensures that only signed modules are loaded. There is a very large number of kernel configuration parameters, and these are discussed in detail in [the hardening guide of the AGL security blueprint](http://docs.automotivelinux.org/docs/architecture/en/dev/reference/security/08-Hardening.html) + +## Discretionary Access Control + +Discretionary Access Control (DAC) is the traditional Linux method of separating users and groups from one another. In a shared environment where multiple users have access to a computer or network, Unix IDs have offered a way to contain access within privilege areas for individuals, or shared among the group or system. The Android system took this one step further, assigning new user IDs for each App. This was never the original intention of Linux UIDs, but was able to provide Android's initial security element - the ability to *sandbox* applications. + +Although AGL mentions use of DAC for security isolation, the weight of the security responsibility lies in the Mandatory Access Control (MAC) and Cynara. Furthermore, there are system services with unique UIDs; however, the system does not go to the extreme of Android, where every application has its own UID. All sandboxing (app isolation) in AGL is handled in the MAC contexts. + +## Mandatory Access Control + +Mandatory Access Control (MAC) is an extension to DAC, whereby extended attributes (xattr) are associated with the filesystem. In the case of AGL, the `smackfs` filesystem allows files and directories to be associated with a SMACK label, providing the ability of further discrimination on access control. A SMACK label is a simple null terminated character string with a maximum of 255 bytes. While it doesn't offer the richness of an SELinux label, which provides a user, role, type, and level, the simplicity of a single value makes the overall design far less complex. There is arguably less chance of the security author making mistakes in the policies set forth. + +## Application Types + +AGL provides a framework for applications to be written in different forms: + +* Web application: HTML5 + JavaScript +* Qt application: in a QML file +* Native application: in C + +While there is no harm in providing multiple types of applications, from a security perspective this does increase the attack surface for an intruder. The application framework consists of a number of utilities and daemons which provide context for the applications. Isolation is provided through SMACK labels. + + +# Application Security Model + +The AGL application framework consists of several interworking parts: + +* SMACK - Simplified Mandatory Access Control Kernel, the kernel level LSM (Linux Security Module) that performs extended access control of the system +* Cynara - the native gatekeeper daemon used for policy handling, updating to the database and policy checking. +* Security Manager - a master service, through which all security events are intended to take place. +* Several native application framework utilities: afm-main-binding, afm-user-daemon, afm-system-daemon + +## Application Framework + +The [AGL app framework](http://iot.bzh/download/public/2016/appfw/02_Documentation-AppFW-Core-2.0.pdf), provides the management around installation, starting/stopping, bindings to D-Bus, and communications to Cynara and the Security Manager. Installation of applications flows through the `afm_system_daemon` and the `security_manager`. The Security Manager retains information in an SQLite database and also sets SMACK policies. The Security Manager also has the definition of an API for external entities. + +The Security Manager communicates policy information to cynara, which retains information in its own database in the format of a text file with comma-separated values (CSV). There are provisions to retain a copy of the CSV text file when the file is being updated. + +Runtime checking occurs through Cynara. Each application that is added to the framework has its own instantiation of a SMACK context and D-bus bindings. The `afb_daemon` and Binder form a web-service that is communicated to through http or a websocket from the application-proper. This http or websocket interface uses a standard unique web token for API communication. + + + +### Attack Vectors + +The following attack vectors are not completely independent. While attackers may have varying levels of access to an AGL system, experience has shown that a typical attack can start with direct access to a system, find the vulnerabilities, then proceed to automate the attack such that it can be invoked from less accessible standpoint (e.g. remotely). Therefore, it is important to assess all threat levels, and protect the system appropriately understanding that direct access attacks are the door-way into remote attacks. + +#### Remote Attacks + +The local web server interface used for applications is the first point of attack, as web service APIs are well understood and easily intercepted. The local web server could potentially be exploited by redirecting web requests through the local service and exploiting the APIs. While there is the use of a security token on the web service API, this is weak textual matching at best. This will not be difficult to spoof. It is well known that [API Keys do not provide any real security](http://nordicapis.com/why-api-keys-are-not-enough/). + +It is likely that the architectural inclusion of an http / web-service interface provided the most flexibility for applications to be written natively or in HTML5; however, this flexibility may trade-off with security concerns. For example, if a native application were linked directly to the underlying framework services, there would be fewer concerns over remote attacks coming through the web-service interface. + + +Leaving the interface as designed, mitigations to attacks could include further securing the interface layer with cryptographic protocols: e.g. encrypted information passing, key exchange (e.g. Elliptic-Curve Diffie-Hellman). + +#### User-level Native Attacks + +* Modifying the CSV data-base +* Modifying the SQLite DB +* Tampering with the user-level binaries +* Tampering with the user daemons +* Spoofing the D-bus Interface +* Adding executables/libraries + +With direct access to the device, there are many security concerns on the native level. For example, as Cynara uses a text file data-base with comma-separated values (CSV), an attacker could simply modify the data-base to escalate privileges of an application. Once a single application has all the privileges possible on the system, exploits can come through in this manner. Similarly the SQLite database used by the Security Manager is not much different than a simple text file. There are many tools available to add, remove, modify entries in an SQLite data-base. + +On the next level, a common point of attack is to modify binaries or daemons for exploiting functionality. There are many Linux tools available to aid in this regard, including: [IDA Pro](https://www.hex-rays.com/products/ida/index.shtml), and [radare2](https://rada.re/r/). With the ability to modify binaries, an attacker can do any number of activities including: removing calls to security checks, redirecting control to bypass verification functionality, ignoring security policy handling, escalating privileges, etc. + +Additionally, another attack vector would be to spoof the D-bus interface. D-bus is a message passing system built upon Inter-Process Communication (IPC), where structured messages are passed based upon a protocol. The interface is generic and well documented; and therefore, modifying or adding binaries/libraries to spoof this interface is a relatively straight-forward process. Once the interface has been spoofed, the attacker can issue any number of commands that lead into control of low-level functionality. + +Protecting a system from native attacks requires a methodical approach. First, the system should reject processes that are not sanctioned to run. Signature-level verification at installation time will help in this regard, but run-time integrity verification is much better. Signatures need to originate from authorized parties, which is discussed further in a later section on the Application Store. + +On the next level, executables should not be allowed to do things where they have not been granted permission. DAC and SMACK policies can help in this regard. On the other hand, there remain concerns with memory accesses, system calls, and other process activity that may go undetected. For this reason, a secure environment which monitors all activity can give indication of all unauthorized activity on the system. + +Finally, it is very difficult to catch attacks of direct tampering in a system. These types of attacks require a defense-in-depth approach, where complementary software protection and hardening techniques are needed. Tamper-resistance and anti-reverse-engineering technologies include program transformations/obfuscation, integrity verification, and white-box cryptography. If applied in a mutually-dependent fashion and considering performance/security tradeoffs, the approach can provide an effective barrier to direct attacks to the system. Furthermore, the use of threat monitoring provides a valuable telemetry/analytics capability and the ability to react and renew a system under attack. + +#### Root-level Native Attacks + +* Tampering the system daemon +* Tampering Cynara +* Tampering the security manager +* Disabling SMACK +* Tampering the kernel + +Once root-level access (i.e. su) has been achieved on the device, there are many ways to compromise the system. The system daemon, Cynara, and the security manager are vulnerable to tampering attacks. For example, an executable can be modified in memory to jam a branch, jump to an address, or disregard a check. This can be as simple as replacing a branch instruction with a NOP, changing a memory value, or using a debugger (e.g. gdb, IDA) to change an instruction. Tampering these executables would mean that policies can be ignored and verification checks can be bypassed. + +Without going so far as to tamper an executable, the SMACK system is also vulnerable to attack. For example, if the kernel is stopped and restarted with the *security=none* flag, then SMACK is not enabled. Furthermore, systemd starts the loading of SMACK rules during start-up. If this start-up process is interfered with, then SMACK will not run. Alternatively, new policies can be added with smackload allowing unforseen privileges to alternative applications/executables. + +Another intrusion on the kernel level is to rebuild the kernel (as it is open-source) and replace it with a copy that has SMACK disabled, or even just the SMACK filesystem (smackfs) disabled. Without the extended label attributes, the SMACK system is disabled. + +Root-level access to the device has ultimate power, where the entire system can be compromised. More so, a system with this level access allows an attacker to craft a simpler *point-attack* which can operate on a level requiring fewer privileges (e.g. remote access, user-level access). + + +### Vulnerable Resources + +#### Resource: `afm-user-daemon` + +The `afm-user-daemon` is in charge of handling applications on behalf of a user. Its main tasks are: + +* Enumerate applications that the end user can run and keep this list available on demand +* Start applications on behalf of the end user, set user running environment, set user security context +* List current runnable or running applications +* Stop (aka pause), continue (aka resume), terminate a running instance of a given application +* Transfer requests for installation/uninstallation of applications to the corresponding system daemon afm-system-daemon + +The afm-user-daemon launches applications. It builds a secure environment for the application before starting it within that environment. Different kinds of applications can be launched, based on a configuration file that describes how to launch an application of a given kind within a given launching mode: local or remote. Launching an application locally means that the application and its binder are launched together. Launching an application remotely translates in only launching the application binder. + +The UI by itself has to be activated remotely by a request (i.e. HTML5 homescreen in a browser). Once launched, running instances of the application receive a runid that identifies them. afm-user-daemon manages the list of applications that it has launched. When owning the right permissions, a client can get the list of running instances and details about a specific running instance. It can also terminate, stop or continue a given application. If the client owns the right permissions, afm-user-daemon delegates the task of installing and uninstalling applications to afm-system-daemon. + +afm-user-daemon is launched as a systemd service attached to a user session. Normally, the service file is located at /usr/lib/systemd/user/afm-user-daemon.service. + +Attacker goals: + +* Disable `afm-user-daemon` +* Tamper with the afm-user-daemon configuration + * /usr/lib/systemd/user/afm-user-daemon.service + * Application(widget) config.xml file + * /etc/afm/afm-launch.conf (launcher configuration) + +* Escalate user privileges to gain more access with afm-user-daemon +* Install malicious application (widget) +* Tamper with afm-user-daemon on disk or in memory + +#### Resource: `afm-system-daemon` + +The `afm-system-daemon` is in charge of installing applications on the AGL system. Its main tasks are: + +* Install applications and setup security framework for newly installed applications +* Uninstall applications + +`afm-system-daemon` is launched as a systemd service attached to system. Normally, the service file is located at /lib/systemd/system/afm-systemdaemon.service. + +Attacker goals: + +* Disable afm-system-daemon +* Tamper with the afm-system-daemon configuration +* Tamper afm-system-daemon on disk or in memory + +#### Resource `afb-daemon` + +`afb-binder` is in charge of serving resources and features through an HTTP interface. `afb-daemon` is in charge of binding one instance of an application to the AGL framework and AGL system. The application and its companion binder run in a secured and isolated environment set for them. Applications are intended to access to AGL system through the binder. afb-daemon binders serve files through HTTP protocol and offers developers the capability to expose application API methods through HTTP or WebSocket protocol. + +Binder bindings are used to add APIs to afb-daemon. The user can write a binding for afb-daemon. The binder afb-daemon serves multiple purposes: + +1. It acts as a gateway for the application to access the system; +2. It acts as an HTTP server for serving files to HTML5 applications; +3. It allows HTML5 applications to have native extensions subject to security enforcement for accessing hardware resources or for speeding up parts of algorithm. + +Attacker goals: + +* Break from isolation +* Disable afb-daemon +* Tamper afb-demon on disk or in memory +* Tamper capabilities by creating/installing custom bindings for afb-daemon + +## Cynara + +[Cynara](https://wiki.tizen.org/Security:Cynara) was adopted from the Tizen security framework and consists of several parts: + +* Cynara - a daemon for controlling policies and responding to access control requests +* Database - a spot to hold policies +* Libraries - several static and dynamic libraries for communicating with Cynara + +The daemon communicates to the libraries over Unix domain sockets. The database storage format is a [series of CSV-like files with an index file](https://wiki.tizen.org/Security:Cynara:Storage). + +There are several ways that an attacker can manipulate policies of the Cynara system: + +* Disable Cynara by killing the process +* Tamper with the Cynara binary on-disk or in-memory +* Corrupt the database controlled by Cynara +* Tamper with the database controlled by Cynara +* Highjack the communication between Cynara and the database + +The text-based database is the weakest part of the system and although there are some consistency mechanisms in place (i.e. the backup guard), these mechanisms are weak at best and can be countered by an attacker very easily. + +## SMACK + +Linux Security Modules (LSM) is a framework in the linux kernel which provides the ability to implement Mandatory Access Control (MAC) with different models. The SMACK model is a simplified mandatory access control, starting with character-based labels on files and directories. There are 4 major components to the system: + +1. The LSM kernel module. +2. The `smackfs` filesystem. +3. Basic utilites for policy management and checking +4. The policy/configuration data + +As with any mandatory access system, the policy management needs to be carefully separated from the checking, as the management utilities can become a convenient point of attack. Dynamic additions to the policy system need to be carefully verified, as the ability to update the policies is often needed, but introduces a possible threat. Finally, even if the policy management is well secured, the policy checking and failure response to that checking is also of vital importance to the smooth operation of the system. + +While MAC is a certainly a step up in security when compared to DAC, there are still many ways to compromise a SMACK-enabled Linux system. Some of these ways are as follows: + +* Disabling SMACK at invocation of the kernel (with command-line: security=none). +* Disabling SMACK in the kernel build and redeploying the kernel. +* Changing a SMACK attribute of a file or directory at install time. +* Tamperig with a process with the `CAP_MAC_ADMIN` privilege. +* Setting/Re-setting the SMACK label of a file. +* Tampering with the default domains (i.e. /etc/smack/accesses.d/default-access-domains). +* Disabling or tampering with the SMACK filesystem (i.e. /smackfs). +* Adding policies with smackload (adding the utility if not present). +* Changing labels with chsmack (adding the utility if not present). + +# Application Store + +Although the Tizen system has defined a [system of App signing and signing flow](https://wiki.tizen.org/Security/Tizen_3.X_Overview#Application_Singing_and_Certificates) to avoid the spread of unauthorized Apps that might contain malware. At this point, it is unclear how much of this flow AGL will adopt; however, judging from the experience, it is an essential topic. For example, the Google Play Store controls the authorization of Apps through signing, and still, there are [many accounts of Apps containing malware on the store](http://www.eweek.com/mobile/researchers-find-132-malware-infected-android-apps-on-google-play). + +Tizen defines 5 levels of certificates and signing at each level, including an author, testing distributor, public level store distributor, partner level store distributor, and platform level store distributor. AGL may define a different number of third parties, but at a minimum an author and store distributor should be defined. + + + +Once the number of signatures has been established, verification of those signatures needs to be done at a minimum at installation time on the AGL device. It is important to ensure the robustness/integrity of the public key used for signature verification. If the public key is modified, then this compromised key can be used to verify an attacker's private key signature. + +Further to this, installation-time verification is limited. Attacks can happen to apps in-memory at runtime. Any modifications made after installation will be missed by installation-time verification. Integrity verification that runs during execution makes for a more complete security story. + +# External Threats + +## Attacks from the Cloud + +### OTA Updates + +Updates of software over-the-air are one of the most common points where an attacker will penetrate. An OTA update mechanism is one of the highest threats in the system. If an attacker is able to install his own application or firmware on the system, he can get the same level of access that the original application or firmware had. From that point, the intruder can get unfettered access to the rest of the system, which might include making modifications, downloading other pieces of software, and stealing assets. + +#### Man-in-the-middle (MITM) + +The man-in-the-middle attack is the most classic example of an attack, where an adversary inserts himself between two communicating entities and grabs whatever is being communicated. In the case of OTA attacks, the connection in the network may be intercepted: + +* On the internet, before the cloud backend. +* At the base station, 3G,4G,5G connection to the internet. +* At the receiving antenna, connection to the car. +* Between the receiving antenna and the gateway router (if present), connection within the car. +* Between the gateway router and the target component (IVI, In-Vehicle Infotainment unit). + +There are many ways to mount a MITM attack. For example, proxy tools like Burp Proxy can be used to intercept web traffic as a man-in-the-middle. Under the guise of being a testing tool, the proxy server is often used in attack scenarios. It runs on a variety of platforms. + +As another example, false base station attacks are known to be fairly easy to set-up. The problem is apparently fairly prevalent in countries like China and in the UK. These fake base stations are sometimes just eavesdropping on the communication, but others have the potential to do serious harm. + +Defenses against MITM attacks include encrypted and signed data pipes. Furthermore, architects and developers are also recommended to encrypt and sign the payloads that are being passed over these pipes, to defend against perusal of the data. + +### Man-at-the-end (MATE) Attacks + +The man-at-the-end attack is when an intruder analyzes the end-point of the communication when software is accessing the data communication. This is a more severe attack type where the attacker can: + +* Steal keys. + + For example, a simple debugging session in running software could reveal a key used in memory. + +* Tamper software. + + For example, replacing just one function call in software with a NOP (i.e. no operation) can drastically change the behavior of the program. + +* Jam branches of control. + + For example, making a program take one branch of control rather than the intended branch can mean the difference between an authorized and a non-authorized installation. + +* Modify important data. + + For example, if the data changed is a key or data leading to a control path, then this attack can be severe. + + In the case of OTA updates, MATE attacks are particularly problematic for the system. One of the consequences of MATE attacks can be installed software that allows installation of any other software. For example, an attacker might install remote access software to control any part of the system. + + + +## Malicious Physical Attacks + +### CAN & USB devices + +On just about every vehicle, ECUs (Electronic Control Units) communicate over a CAN (Controller Area Network) 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. + + +# Conclusion + +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. + +This document has described both general attack goals and specific threats to the AGL system. While those may think that a remote attack is the biggest concern, the reader should be aware that an open-source software system invites people to first research direct attacks before crafting remote attacks. Don't underestimate the creative ability for hackers to find the weakest link in a product. This has been shown time and time again in open products. + diff --git a/sec-blueprint/04-adversaries.md b/sec-blueprint/04-adversaries.md deleted file mode 100644 index 1dd4758..0000000 --- a/sec-blueprint/04-adversaries.md +++ /dev/null @@ -1,49 +0,0 @@ -This section lists some of the adversaries and attackers in Automotive. - -## 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 hacked previously 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 Dealers - - These 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 Criminal - - 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 an OEMs and/or governments by - threatening to disable multiple vehicles. - -## Malware Developers - - Malware Developers have developed malicious software to attach - and compromise a large number of vehicle. The malicious software - would usually be designed spread from one vehicle to another. - The goal usually is to take control of multiple machines then sell - access to them for malicious purposes like denial-of-service (DoS) - attacks or stealing private information and data. - -## Security Researchers - - These attackers are ‘self-publicized’ security consultants trying - to make a name for themselves. They have access 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 - gains.
\ No newline at end of file diff --git a/sec-blueprint/04-security-concepts.md b/sec-blueprint/04-security-concepts.md new file mode 100644 index 0000000..5080b4c --- /dev/null +++ b/sec-blueprint/04-security-concepts.md @@ -0,0 +1,88 @@ +--- + +title : Security Concepts +date : 2017-07-07 +categories: architecture, automotive +tags: architecture, automotive, linux +layout: techdoc + +--- + +**Table of Content** + +1. TOC +{:toc} + + +This document addresses the following security concepts that help make +connected vehicles less vulnerable to security threats. + +## Secure Boot + +Secure boot refers to preventing malicious software applications and +"unauthorized" operating systems from loading during the system start-up +process. The goal is to protect users from rootkits and other +low-level malware attacks. Modern bootloaders come with features that +can be used to enable secure boot in the system. + +## Software Integrity + +The goal of software integrity is to ensure that all software running on +a system has not been altered in any way, either accidentally or +maliciously. This is typically achieved by checking a file's hash or +signature against a protected, “good” value that exists in the system. +Maintaining software integrity ensures that your system behaves as +intended. In principle, it protects the system against any malicious +code trying to tamper your system. + +## Secure Update/Upgrade + +Software updates in connected vehicles are a very useful feature, which +can deliver significant benefits. If not implemented with security in +mind, software updates can incur serious vulnerabilities. Any software +update system must ensure that not only are the software updates to +devices done in a secure way, but also that the repositories and servers +hosting these updates are adequately protected. As the process of updating +software migrates from a `Dealership` update model towards an `Over-The-Air` +update model, securing these processes becomes a high priority. + +## Layered Security + +It has been well established amongst software security researchers, that +a layered approach to security ensures a stronger protection against attackers. +A multi-layered approach to security should be included when designing the +architecture of a connected car. The goal is to ensure that even if one layer +of security is compromised, the other layers will protect the platform, while at the +same time making it harder for attackers to breach the security of the +system. + +## Read-Only File Systems + +When following a layered security design, one simple yet effective way +to protect the platform is to make the file system read-only. It is +important to note that making the filesystem read-only is not a +foolproof security mechanism. It does, however, make life more complex +for an attacker. + +## Mandatory Access Control + +Mandatory Access Control (MAC) refers to a type of access control in a +Linux system that constrains the ability of a “subject” to access a +“resource”. The Linux kernel makes these decisions based on a +pre-existing policy. User are not allowed to override or modify this +policy, either accidentally or intentionally. MAC uses the underlying +kernel framework of Linux Security Modules (LSM). There are multiple +LSMs available including SELinux, Simplified Mandatory Access Control +Kernel (SMACK), AppArmor and others. AGL uses SMACK as the MAC. + +## Secured Applications + +Applications in the modern car are steadily improving the dashboard and +control of the car. Applications have also proven to be frequent point +of attack for hackers. In AGL, The term of Application (App) has a very +wide definition. Almost anything which is not in the core OS is considered +an Application. At the same time, when talking about the security of applications, +any mobile applications that have been designed to interact with the car +must also be considered. Secured applications are mission-critical for OEMs +who want to meet customer expectations for innovative software features, +while ensuring the safety and proper functioning of their vehicles. diff --git a/sec-blueprint/05-platform-security.md b/sec-blueprint/05-platform-security.md new file mode 100644 index 0000000..9bf96d6 --- /dev/null +++ b/sec-blueprint/05-platform-security.md @@ -0,0 +1,162 @@ +--- + +title : Platform Security +date : 2017-07-07 +categories: architecture, automotive +tags: architecture, automotive, linux +layout: techdoc + +--- + +**Table of Content** + +1. TOC +{:toc} + +This section describes how the Automotive Grade Linux (AGL) platform +applies some of the previously described security concepts to +implement platform security + +# Platform Definition +The Automotive Grade Linux(AGL) platform is a Linux distribution +with AGL compliant applications and services. The platform includes the +following hardware: + - SoC (System-on-Chip) + - Memory (RAM, ROM, storage, etc.) + - Peripherals + +The AGL platform includes the following software: + - Linux BSP configured for reference boards + - Proprietary device drivers for common peripherals on reference boards + - Application framework + - Windows/layer management (Graphics) + - Sound resource management + - An atomic software update system + - Building and debug tools (based on Yocto project) + +For more details, refer to the AGL Architecture/Specification Document. + +# Secure Boot +Currently, AGL does not provide a secure boot solution but highly recommends +that the manufactured solution make use of a secure boot mechanism. For +instructions on securing u-boot, please refer to the System Hardening Guide. + +# Certificate and Key Management +Currently, AGL does not provide a secure certificate and key management +solution but highly recommends that the manufactured solution make use +of secure key management. + +# Mandatory Access Control +Mandatory Access Control (MAC) is a protection provided +by the Linux kernel that requires a Linux Security Module (LSM). +AGL uses an LSM called Simplified Mandatory Access Control Kernel (SMACK). +This protection involves the creation of SMACK labels as part of the extended +attributes SMACK *labels* to the extended attributes of the file and then +creation of a policy to define the behaviour of each label. The kernel controls +access based on these labels and this policy. + +There are two types of SMACK labels. +* An *Execution* SMACK label of a process defines how files +are accessed and created by that process. + +* The *File Access* SMACK label defines which process can access the file. +This SMACK label is written to the extended attribute of the file. + + +By default a process executes with its File Access +SMACK label unless an Execution SMACK label is defined. + +AGL's SMACK scheme is based on the Tizen 3 Q2/2015. +It divides the System into the following domains : + +## Floor +The *floor* domain includes the base system services and any associated data +and libraries. This data remains unchanged at runtime. +Writing to floor files or directories is allowed only in development +mode or by installation and upgrade software. + +The following table details the *floor* domain: + +------------------------------------------------------------------------------------------------------------------------- + +|Label| Name | File | Process | Comment | +|:-:|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| +| | +| - | Floor | r-x for all | Only kernel and<br>internal kernel thread <br>| -- | +| ^ | Hat | --- for all | rx on all domains | Only for privileged system services (currently only systemd-journal). Useful for backup or virus scans. No file with this label should exist except in the debug log. | +| * | Star | rwx for all | None | used for device files or /tmp Access restriction managed via DAC. Individual files remain protected by their SMACK label. | + + + +## System +The *system* domain includes a reduced set of core system services of the OS and +any associated data. This data may change at runtime. + +The following table details the *system* domain: + +------------------------------------------------------------------------------------------------------------------------- + +|Label| Name | File | Process | Comment | +|:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| +| | +|System|System|none|Privileged<br>processes|Process should write only to file with transmute attribute.| +|System::run|Run|rwxatl for User and System label|None|Files are created with the directory label<br>from user and system domain (transmute)<br>Lock is implicit with w.| +|System::shared|Shared|rwxatl for system domain<br>r-x for User label|None|Files are created with the directory label from system domain (transmute)<br>User domain has locked privilege| +|System::Log|Log|rwa for System label<br>xa for user label|None|Some limitation may impose to add w to enable append.| +|System::Sub|SubSystem|Subsystem Config files|SubSystem only|Isolation of risky Subsystem**| + + +## Applications, Services and User +The *application, services and user* domain includes code that +provides services to the system and user, as well as +any associated data. All code running in this domain is under Cynara +control. + +The following table details the *application, services and user* domain: + +------------------------------------------------------------------------------------------------------------------------- + +|Label| Name | File | Process | Comment | +|:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| +| | +|App::$AppID|AppID|rwx (for files created by the App).<br>rx for files installed by AppFW|$App runtime<br>executing $App|Only one Label is allowed per App.<br>A data directory is created by the AppFW in rwx mode.<br>Older releases still use User::App::$AppID | +|User::Home|Home|rwx-t from System label<br>r-x-l from App|None|AppFW needs to create a directory in /home/$USER/App-Shared at first launch if not present with label<br>app-data access is "User::App-Shared"<br>without transmute.| +|App-Shared|Shared|rwxat from System and User domains label of $User|None|Shared space between all App running for a given user.<br>Older releases may still use User::App-Shared| + +# Yocto Security Layer +Currently, AGL relies on Cynara and Security Manager from Yocto Layer +meta-intel-iot-security. Please note that support for these components has +been dropped in the upstream project. + +# Application API Transport +Currently, AGL Application framework uses D-Bus interface for transport +and uses the inherent security that comes with this protocol. + +# Resource Management and Protection +AGL provides resource management and protection through SMACK labels. +Please refer to application framework documentation for more details. + +# TrustZone +Currently, AGL does not provide any direct support for TrustZone. +This feature strictly depends on the SoC and is only available on ARM architectures. + +# AGL Platform Software Update + +The update solution must be atomic and the following update requirements: +- Support Smack as MAC +- Support Read-Only Filesystem +- Support Integrity Enforcement + +Currently AGL offers a reference implementation of the Over-The-Air +update system using OSTree. Work is being done to secure the OTA +updates using *Uptane*. + +For more information on Uptane, please refer to: + +https://uptane.github.io/ + +# Cloud Service Infrastructure +Currently, AGL does not provide a any cloud service infrastructure + + +For recommendations on hardening the system, please refer to the System Hardening Guide. diff --git a/sec-blueprint/05-security-concepts.md b/sec-blueprint/05-security-concepts.md deleted file mode 100644 index 1ae1706..0000000 --- a/sec-blueprint/05-security-concepts.md +++ /dev/null @@ -1,466 +0,0 @@ ---- - -title : Application Security Concepts -date : 2016-06-30 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -## Security Principles - -When connecting a car to the internet, not only we create a mobile entry -point to our private life, we also relocate our entry doors anywhere in -the world. - -Neither all places on this planet are nice nor safe, nor are -the people. -The locks and alarms on cars, will give only a fake -impression of security once that internet connection has entered the -place. - -Internet enables the worse of human side to get access to private -domains. -If we are not careful, it will likely be invaded in a very -short time following connection.. - -**So, connected cars security must be designed as a military vehicle -which would be deployed in a high risk zone even when designing cars for -out towns and villages**: - -- Physical access to the car should not be a white card to hack - the system. - Most cars sleep in the streets and public car parks where physical - accessibility is easy. -- Known defect should be corrected by SW update in real time, without a return to - home or garage. -- A separation of functionalities in isolated domains should allow the - car to remain safe and operational by limiting the contamination, - would a malicious SW succeed to pass the protections. -- Connectivity between the various domains should be restricted to the - minimal set required for their operation. -- Software loaded in cars and in the cloud should be vetted in - accordance with its capability to access critical resources. - The vetting authority must be controllable, enforceable and revocable. -- Inside each domain, sub domains should be created to limit even - more, the nuisances capabilities of a successful malicious code. -- Software or devices not wetted should never be able to access any - critical resources. - -**The strategy can be summarise as “anything, which is not explicitly -authorise is strictly forbidden”,also known as ‘white listing’ policy.** - -We all understand those concepts, and nevertheless reports still show -that very little people care about implementing protection against those -risks yet. -As a consequence most Connected Car projects are coming on -the market with major security holes. -It will take some time *(and likely some catastrophes)* for the Automotive Industry to clean up the -pre-cyber security awareness designed products. - -The complexity induced by a security framework requires serious effort -on the design side and complexifies the code execution. -Fortunately our modern CPUs, which are very fast and ernergy efficient, can reduce this overhead -to very acceptable extra work load on the computing and energy -sub-systems. - -The challenge of Connected Cars is very similar to embedded devices -in general. -Within AGL we are defining solutions, which can enable this -new market to emerge without requiring each product design to be -chaperoned by security experts. -*The world does not hold enough security experts to even overview even a few percent of the projects that are required -to create all connected devices that will be launched in the next 10 -years.* - -If embedded developers must implement complex security models -without, having neither the time nor the skills, to architecture them -correctly, *they can only succeed by reusing ready made trusted -solutions*. -Fortunately Connected Cars are based on some flavour of -Linux operating system which has, due to its long serving years in many -critical domains, a large offering of security options. - -AGL only focus on the security facilities offered under -Linux operating system for the connected car market. -Non Linux Operating systems which can also be present in a connected car, are not covered by AGL platform security model. - -## Strategy - -There is no miracle solution. -When deciding which security strategy, you -will need, first to try to evaluate all the possible attack vectors, -then to define your priorities and your limits. - -Even if today complexity is mostly in the software (SW), we still need -some hardware (HW) to run it. -Securing the HW is a very complex task which fortunately is likely yet not required for Connected Cars. -I will not open more the topic here. -Nevertheless applying a healthy design attitude by reducing obvious direct risk vectors (debug serial connector -wired in production, tracks with clear communication channel easy -accessible on PCB, …) should be done. - -Would your automotive project requires a more protected HW, you will -find plenty of literature on that topic. -I personally like this relatively old (2004) paper from J Grand as an introduction to the -domain. -<http://www.grandideastudio.com/wp-content/uploads/secure\_embed\_paper.pdf> - -On the SW side, the most efficient model is to work by layer : - -- **be sure that the desired SW is loaded** - On non connected devices, a trusted boot is considered a valid - enough solution, but Connected Cars requirement to enable - applications be added after the initial equipment provisioning, - requires more than a simple trusted boot. - A strategy to control the integrity of the software and its - configuration is required. -- **Be able to change (upgrade) the software to correct a newly - discovered risk.** - Assuming that the system will never be broken is an utopia. - The right strategy is to plan how to recover from the discovering of a - new security issue to avoid its propagation. - *This upgrade mechanism must be particularly solid has it has to be - capable of being executed on a compromised system without the - support of a skilled operator.* -- **Only select trusted Linux drivers.** - In Linux, drivers are executed with the same privilege level than - the Kernel itself. - I short a malicious or hacked driver is an - uncontrolled open door to the hart of the system. - Only vetted driver should be used and any complexity unique to the platform should be - pushed in the user space domain. - This remark is particularly important when introducing drivers that are connecting with the - outside world. - Ideally dynamic driver integration after boot should be banned even - if that would limit the flexibility of hot plug for USB devices. - Solutions to reinforce the Linux Kernel integrity during execution, - can be activated but they are an order of magnitude more complex to - activate than keeping bespoke logic in user space. - <https://www.isoc.org/isoc/conferences/ndss/11/pdf/3\_1.pdf> -- **Isolate the core of the system from the middleware.** - By default the protection on Unix type systems (and so Linux) is - done by allocating the user a set of access rights. - The side effect is that any code running under a given name can access all the - resources that is given to that user. - Furthermore it is possible at any time to further expend this access to other users. - *As most of code in traditional embedded software run with the Administrator - privilege (root) we foresee the danger of this traditional - embedded model. - Fortunately Linux provides a Security model called LSM.* ( - <https://en.wikipedia.org/wiki/Linux\_Security\_Modules>) - It allows to create an access strategy which is not controlled by - the user but rather by the system configuration. - Multiple front end are available to control LSM and that will be studied a bit later in - this paper. - This allows to create a Mandatory Access Control (MAC) - which is a powerful tools to avoid compromised code to gain access - to extra resources to propagate further. - Other restriction based on the c-groups, the Posix capabilities and - the Seccomp can used in addition to LSM to further mitigate - the risks. -- **Isolate Applications** - IoS and Android phones have initiated the Apps model and nowadays - launching a product which cannot be extended by Apps (from a closed - or open Store) after the creation of the device is a risky - marketing strategy. - While the model of Apps loaded from an open store is reserved to a very small category of mass consumer devices, - the capability to load Apps after the creation of the initial SW is - a very attractive way to reduce the time to market as well as the - reaction time to changing market demand. - In particular it would allow car manufacturers, to customise the car - SW, individually on the production line, to the buyer wish. - *By design Apps are created with a quite loose coupling with the - core SW. - The default Linux DAC (Discretionary Access Model) is not - the most reliable for limiting the access to the system capabilities - to the minimum required.* - Associating the validation of the origin of an App to the resource - that such App can claim access, with the enforcement of restriction - in accessing the system resources to those explicitly granted, is a - far more reliable approach. -- **Private data protection** - *Cars know a lot about us, from where we go, to who we call, who get - in our car (via the phone detection) and hold data that we are not - willing to let go in the Open without our explicit consent.* - This creates three main families of requirements : - - Requires a safe provisioning of new devices and App in the - system (know who is who and who does what. ) - - Enforce encryption to any traffic going out. - - Enforce encryption on local storage for personal data to - mitigate off line attack risk. - - Enforce isolation of devices own by multiple users that connect - to the car. - -## Secure Boot - -The trusted or secured boot is a facility offered by most Systems on Chip (SoC) -which enforces : - -- booting the system in a known state - (e.g. all the RAM set to "0", all internal peripherals set to silent) -- providing a validation that the loaded initial code is signed by a valid authority - (in short the SW is really coming from a known valid source). - -As the feature is very closed to the HW, almost as many solutions exist -than SoC vendors and many of them requires to buy a large volume of SoC -in order to get access to the facility and are by that requirement not available to generic platform developers. - -The Secured Boot option associated to a modern boot loader such as UEFI or uboot -allows to restrict the execution of the system initialisation code to those which which carries a valid signature. -Even if the system presents some weaknesses and constrains, it is likely -*a valid and accessible solution for most device manufacturers even for -medium volume.* - -Once the trusted boot activated, you will have a good confidence -*(history shows that security loop holes are always available -somewhere)* that the code which will start to run when powering the -device, is the expected one. - -## Read Only root file system - -In most embedded system the core OS is under control of the device -manufacturer. -*A very simple and efficient way to limit opportunities to -get the core OS and middle-ware to be modified by a malicious code, is -to store it on a read only partition*. -Even if that is not 100% bulletproof it seriously complexifies the level of required knowledge to -break into the OS and greatly eases, the implementation of a recovery -strategy. - -In order to enable some local persistent changes such as those required -to register some network or locale configurations, an overlay can be -created for some directories. -Since Linux 4.0, the kernel supports by default OverlayFS which provides that facility and support the extended -file attributes required by file base MAC such as SELinux and Smack. -<https://github.com/torvalds/linux/commit/e9be9d5e76e34872f0c37d72e25bc27fe9e2c54c> - -## Code Integrity during execution - -In the embedded world it is quite acceptable to restrict the end user to -operate the system as designed. -We can take profit of this favorable position, to limit the capabilities of a malicious applications to -change our Operating System (OS) after the protected initialisation -(trusted boot). -This can be done *by activating an integrity enforcement such as IMA/EVM on all the core OS.* -<http://sourceforge.net/p/linux-ima/wiki/Home/> - -In short IMA allows the kernel to check that a file has not been changed -by validating it against a stored/calculate hash (called label) while -EVM checks the file attributes (including the extended ones). - -Two types of labels are available : - -- immutable and signed -- simple - -The signed labels are reserved for code or data which are static and -provide the best level of protection. -The signing tool remains external of the device. -The simple hashes are reserved for code which can be -install dynamically and the hash can be recalculated on the fly by the -OS providing a lesser level of protection. - -Obviously some restriction will be imposed on which SW modules are -allowed to update an IMA/EVM label and all public keys used for -signature checking must be protected with an unmutable label or stored -in the HW security sub-system. - -## Update and Ugrade - -The integrity enforcement does not allow immutable files to be updated -on line. -The Integrity system would detect the violation and block any -further reading of such file. - -*The update solution must cater with this constrain and must be -implemented via an atomic model where all changes are done in one step, -on the entire core OS, generally just before a reboot..* - -## Mandatory Access Control (MAC) - -Connected Cars are comparable to middle volume consumer managed products -(very similar to connected TV), by this, I mean, product where the -software is entirely provided by the device manufacturer. -The main side effects are well known : - -- low cost and small CPU -- high control of the OS and Middleware loaded on the box -- user, at best, very slow to activate update -- no visibility by the manufacturer of the external environment where - the device is connected. -- No skilled administrator -- No recovery console. - -For those reasons, a solution like Smack has been selected by AGL as the -best suited LSM front end. -Furthermore, its adoption on Tizen by Samsung -for delivering millions of Smart TVs enable an active community focussed -on keeping good performance on smaller CPUs. -<https://wiki.tizen.org/wiki/Category:Security> - -## Applications - -*Apps are the weak security vector in many modern system.* -Car manufacturers need to add bespoke/localised App developers in order to -make their product commercially attractive. -It is a fast moving world very different to the use and habits of the Automotive industry. - -Defining the right level of App vetting is a real challenge. -A quick reality check on markets where Apps exist, such as Mobile, Smart TV or -Smart Watches, show that the detection of roke Apps is very complex -already on platforms that impose the execution via a Virtual Machine, so -we can imagine what is the complexity, when native code support is -required in order to run on very small CPU. - -**As we cannot fully trust Apps, we have to contain them**. -This can be done by : - -- Limiting Apps download origin to trusted ones. -- Restrict Apps privileges, resources and APIs access to what is - explicitly authorised -- Isolate Apps runtime - -Restricting Apps origin to trusted source is quite simple. -The simple use of a certificate to validate the App signature is a powerful model -when associated with an installer code which cannot be called via a back -door. -A simple model consists in separating the download process and -exposed (UX, connected) from the installer code which can validate the -App origin and installation in a isolated process with a lower surface -of attack. - -Restricting Apps privileges requires first to know what are the -requested and authorised privileges. -The granularity of these privileges, must offer a good flexibility while remains simple, to be -understood by the developers and the user. -The compromise will depend of the target audience. -The current return of experience from Android and Tizen, tend to reduce the list of privileges to a shorter list rather -than in opposite. -The creation of goup or App class is an other valid model. - -The list of requested privileges will be associated to the App in a -Manifest. -A practical extra validation of the requested privileges can -be done depending of the App origin and signature level (e.g. -Manufacturer, Partner and Community stores). - -The association between the App and its privileges list must be kept -safe and available for enforcement in the system. -The Samsung originated Open Source project Cynera (<https://github.com/Samsung/cynara>) provides -such service and is optimised for execution on small SoC. - -Isolating the App when running is the most challenging task, it requires -to let the App access enough of the system to execute its task but no -more, to mitigate any malicious activity. -One model to address this challenge consist in slicing the access to the system : - -- CPU, RAM -- devices -- network -- middleware -- files -- libraries and system calls. - -CPU and RAM over use can be restricted with a correct C-Group -configuration. - -Devices and files can be isolated by MAC and DAC. - -Network access can be controlled via MAC in association with the -nftables. - -Middleware in AGL is access via binders which provides not only an -isolation via creation of different security context but adds the -concept of authentication which limit attack through man-in-the-middle -*<https://en.wikipedia.org/wiki/Man-in-the-middle\_attack>*. - -The control of Libraries and system API usage is far more complex. -MAC advanced usages can help in this domain but Seccomp-BPF can go further. -Seccomp which is an upstream feature of the Linux kernel is used by -Mozilla and Chrome in their browsers and enable a low level protection -solution. -Seccomp can quickly induce a performance hit and access rules -must remain simple. -The following page provides interserting reports on performance cost of -that feature. (<https://wiki.tizen.org/wiki/Security:Seccomp>) for one -system. - -### Name spaces - -Containers have made Linux name spaces visible to the mass. -They are very popular and unfortunately often confused with security enforcement -due to their common use as light virtualisation solution in the cloud. - -Whichever model of container is referenced, they all use the Linux -various name spaces -(<http://man7.org/linux/man-pages/man7/namespaces.7.html>). -The general idea is to share a common kernel and to let each containers run its own -virtual Linux user space and middleware. -With the increased CPU performance and the facility provided by novel filesystem architectures -such as overlayfs, the files and code which happen to be unchanged -between different containers can even remain shared transparently on -disk and in RAM, enabling the use of containers for single App in the -cloud or on small embedded system. - -From a security point of view, while containers provides an isolation -between themselves, it must remain present to the designer that : - -- kernel is shared and security weaknesses and zero day defects can be - used to cross domains. -- As each container can provides its own version of the middleware, - upgrading the system is not enough to correct known security issues. - Each container must individually be updated. -- Due to the transparent overlay model sharing files between - containers, predicting the actually used disk space is challenging. -- UX needs to share the same Display and Input what can open back - doors in the system. - -At least two lines of interest seem to provide a serious value for the -Automotive domain : - -- Isolating subsystem -- Easing development - -The isolation model is very interesting when multiple service providers -needs to share the same embedded device. -A commonly listed use case, is the sharing of an IVI system with games or cloud multimedia services. - -The ease of development, is potentially even more valuable. -One of the challenge faced by the embedded SW industry is the lack of skilled -embedded software developers. -*Enabling web and traditional IT programmers to work in a known environment and to run their App on an -IoT device without requiring to become an embedded SW expert would be of -a high value*. - -The Smack provides a solution to create MAC name spaces, so in theory -nothing would stop to launch containers for each Apps in an isolated -environment. - -As further reading on similar topic, you can have a look at the Open -Source Vasum project. -<https://github.com/Samsung/vasum> -<https://wiki.tizen.org/wiki/Security:Vasum> - -## Process Management - -While developers will always have a good reason for delaying the -activation of the security layers, to succeed, you will need to keep a -few base concepts enforced: - -- Security is invasive. It goes everywhere. -- Security cannot be apply as a patch at the end of the project. -- System must be developed with the security 'on' or it will - never work. -- SW must be written secured first time, as late adaptation is - too difficult. -- Underestimating the resistance of the developer team is a common - mistake which can lead to massive over costs and delays. -- Implication of the right expert and management drive from the beginning is a - requirement that cannot be negotiated. diff --git a/sec-blueprint/06-application-security.md b/sec-blueprint/06-application-security.md new file mode 100644 index 0000000..44a4622 --- /dev/null +++ b/sec-blueprint/06-application-security.md @@ -0,0 +1,67 @@ +--- + +title : Application Security +date : 2017-07-07 +categories: architecture, automotive +tags: architecture, automotive, linux +layout: techdoc + +--- + +**Table of Content** + +1. TOC +{:toc} + +This section describes how the Automotive Grade Linux (AGL) platform +applies some of the previously described security concepts to +implement application security + +# Application Definition +The term of Application (App) has a very wide definition in AGL. +Almost anything which is not in the core Operating System (OS) is an Application. +Applications can be included in the base software package (image) or +can be added at run-time. + +# Application Installation +Applications are installed under the control of the Application Framework (AppFw). +Applications can be delivered and installed with the base image using a +special offline-mode provided by the Application Framework. Apps can also be installed +at runtime. + +**Note** In early release, default Apps are installed on the image at first boot. + +# Application Containment +Application containment is achieved using the following protections: + +* **Linux Native protection** + * Mandatory Access Control (SMACK) +* **AGL Platform protections** + * Origin Tracking and Validation + * Application Privilege Management and Enforcement via Cynara + * Authenticated Transport via D-Bus + +## Mandatory Access Control +Mandatory Access Control (MAC) is a protection provided +by the Linux kernel that requires a Linux Security Module (LSM). +AGL uses an LSM called Simplified Mandatory Access Control Kernel (SMACK). +This protection requires writing SMACK *labels* to the extended attributes of the file +and then writing a policy to define the behavior of each label. +The kernel controls access based on these labels +and this policy. +For more details on SMACK scheme in AGL, please refer to the +security platform security document in the security blueprint. + +## Origin Tracking and Validation +Currently, AGL applications are tracked and verified at installation +time by the application and security framework using SMACK labels. +For more details, please refer to the application framework documentation. + +## Privilege Management and Enforcement +Application priveleges are managed by Cynara and the security manager +in the application framework. +For more details, please refer to the application framework documentation. + +## Autenticated Message Transport +Currently AGL uses the D-Bus interface for transport, using the security +inherent in this interface. diff --git a/sec-blueprint/06-plateform-security.md b/sec-blueprint/06-plateform-security.md deleted file mode 100644 index 6689668..0000000 --- a/sec-blueprint/06-plateform-security.md +++ /dev/null @@ -1,143 +0,0 @@ ---- - -title : platform Security -date : 2016-06-30 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -## Platform Definition - -The platform includes a set of HW supporting an AGL Linux distribution and AGL compliant Application and Services. -On the HW side this will include : - -- A SoC -- RAM, ROM and Storage -- Peripherial - -The AGL SW platform includes all the SW required after the initial boot loader in order to support AGL compliant applications and services : - -- Linux BPS configured for the reference boards -- Set of drivers for the common peripherials available on the reference boards (they may not all be Open Source) -- Application Framework -- Windows/layer management to allow Application to gracefully share the displays -- Sound resource manager to allow Application to gracefully share the displays -- An atomic update system support / as read only and MAC (Smack) -- Set of building and debug tools (based on yocto project) - -## Secure boot - -The secure boot is tighly linked to the SoC and will vary from SoC to SoC. -AGL does not provide the secure boot but AGL platform is designed to be able to operate with a secure boot. - -## Certificate and Key Management - -The default Key management provided by AGL is SoC independant and use leyrings. -This model is less secured than a SoC HW integrated model and we advise AGL adopters to activate HW support from their selected SoC as much as possible. -The activation of HW support for Key management if left to the integrator. - -## Madatory Access Control configuration - -The general Smack schema used by AGL is inspired from Tizen 3 Q2/2015 -but tries to enable a better protection of code ran via run time (e.g. -JavaScript, Python) and enable Cloud/Device hybrid applications model. - -It takes into account the Tizen2 experience of creating too complex MAC -rules and limit the use of MAC for process file access tracking leaving -the application capabilities management to other model (Cynara and the -Security manager). - -<https://wiki.tizen.org/wiki/Security/Overview\#Implementation\_in\_Tizen\_3.0\_2015.Q2> - -** You will notice that the Smack initial configuration described bellow, -even if not obvious to read, represents a manageable complexity which -should be understood in no more than a few hours.** - -This initial Smack schema tries to clearly keep the differentiation -between the execution Smack label of a Process and the Smack label of a -file. -The first one defines which file a process can access and how -files will be created by the process. -The second defines which process can access the file. -By default a process will execute with its file -access Smack label but that can be overwritten by an execution Smack -label. - -The system is split in 3 domains : - -- **Floor**, which includes the base services and associated data and libraries of the OS which are unchanged during the execution of the OS. - Outside of development mode, installation and upgrade software, no one is allowed to write in Floor files and directories. -- **System**; which includes a reduced set of core services of the OS and the data that they maintain. - Those data are expected to change during the execution of the OS. -- **Apps, Services and User**, which includes code providing services to the system and user and their associated data. - Per concept all code running in this domain are under strict control and isolation by the Cynara and Smacks rules. - -## Floor Domain - -------------------------------------------------------------------------------------------------------------------------- - -|Label| Name | File | Process | Comment | -|:-:|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| -| | -| - | Floor | r-x for all | Only kernel and internal kernel thread | -- | -| ^ | Hat | --- for all | rx on all domains | only for privileged system Services (today only systemd-journal) useful for backup or virus scan. No file with that label should exist except debug log. | -| * | Star | rwx for all | None | used for device files or /tmp Access restriction managed via DAC. Individual files remain protected by their Smack label. | - -## System Domain - -------------------------------------------------------------------------------------------------------------------------- - -|Label| Name | File | Process | Comment | -|:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| -| | -|System|System|none|Privileged processes|Process should only write on file with transmute attribute.| -|System::run|Run|rwxatl for User and System label|None|files are created with directory label from user and system domain (transmute) Lock is implicit with w.| -|System::shared|Shared|rwxatl for system domain r-x for User label|None|files are created with directory label from system domain (transmute) User domain has lock privilege| -|System::Log|Log|rwa for System label xa for user label|None|Some limitation may impose to add w to enable append.| -|System::Sub|SubSystem|SubSystem Config files|SubSystem only|Isolation of risky SubSystem**| - -- Runtime: IoT-OS AppFW always starts a new instance of the runtime for each application (no shared process model is allowed and change the runtime process label to the App Smack label) -- Unconfined mode is reserved for future evolution. - -## Apps, services and User Domain - -------------------------------------------------------------------------------------------------------------------------- - -|Label| Name | File | Process | Comment | -|:--|:-------|:-------------|:------------------------------------|:-----------------------------------------------------| -| | -|App::$AppID|AppID|rwx (for files created by the App). rx for files installed by AppFW|$App runtime executing $App|One Label per App. A data Dir is created by the AppFW in rwx. Older releases still use User::App::$AppID | -|User::Home|Home|rwx-t from System label r-x-l from App|None|AppFW needs to create Dir in /home/$USER/App-Shared at 1st launch if not present/ with label app-data access="User::App-Shared" without transmute.| -|App-Shared|Shared|rwxat from System and User domains label of $User|None|Shared space between all App running for a given user. Older releases may still use User::App-Shared| - -## Secured transport for Binder implementation - -## Resource Management - -## Trust Zone and Trusted Execution - -Trusted zone and Trusted execution are services provided by the SoC vendors and services offered can varie even within the same familly of SoC depending of their configuration. -AGL platform does not provide any Trusted Zone or Tusted Execution direct support as these are specific to each indivual SoC but on the other side the AGL platform is architectured to ease the use of HW helpers. -In particular AGL advise whenever possible to take profit of HW helpers available to store critical data in the secure zone and to execute critical validatin code (in particular signature check) in trusted execution mode. - -## Critical Resource Protection - -## AGL Platform Software Update - -AGL platform provides by default a software update module which is capable to respect the AHL platform update requirements: - -- support Smack as MAC -- support read only / file system -- support integrity enforcement such as IMA and EVM. - -Any update software respecting these requirement can be used. -AGL advise strongly to only use solutions that enable a strong verification of the validity and integrity of the download update or upgrade what ever is the selected solution. - -## cloud service infrastructure diff --git a/sec-blueprint/07-application-security.md b/sec-blueprint/07-application-security.md deleted file mode 100644 index 2c757b0..0000000 --- a/sec-blueprint/07-application-security.md +++ /dev/null @@ -1,131 +0,0 @@ ---- - -title : Application Security -date : 2016-12-07 -categories: architecture, automotive -tags: architecture, automotive, linux -layout: techdoc - ---- - -**Table of Content** - -1. TOC -{:toc} - -## Application Definition - -The term of Application (Apps) has a very wide coverage in AGL. -To make it short, anything which is not in the core OS, is an App. - -Apps can be included in the base image or added after the fact, they can offer a UI, or only offer a service. -In AGL, most of the middleware will be treated as Apps. - -## Apps must be installed - -Undependently of the fact that Apps are delivered with the base image or later installed on a running image, Apps are installed under the control of the Application Framework (AppFW). -A special off-line mode of the AppFW, allows to install Apps at image creation.\* - -**Note :** In early release, default Apps are installed on the image at first boot. - -## App containement - -Apps are running in isolation of the system and other Apps. -In order to acheive an efficient containement multiple strategies are used : - -* **Linux Native protection** - * Smack label (Mandatory Access Control) - * Capabilities - * Names Spaces - * Seccomp filter - * Cgroup - * File Integrity -* **AGL Platform protections** - * End2end App author tracking and validation - * Apps Privileges - * Autiticated Apps to Apps/Services transport - -## Which protection are enforced on an App - -### App origin - -The AGL App development process enforces of the level of autorisation given to an App developper and tracks that autorisation level end2end. -Depending of the implementation, the tracking may be : - -* static, simply enforced at the registration of the App on the repository or dynamic. -* dynamic, track and verified at installation by the AppFW. - -The origin tracking and validation is critical. -It is the first section the chain of trust for providing valid information to the AppFW installer module. - -### Platform security configuration - -The AppFW derives from the Meta data received with the App at delivery, which privileges will be granted to this App : - -* Max CPU, RAM, IO, ... -* Firewall configuration -* Name spaces ... - -It will create the directories required for the App following the Smack rules described in the "Platform Security" blueprint as well as the associated systemd config files to be used by the launcher. -As the platform securities services are static for a given release of the OS, the mapping remains simple. - -**Important**: - -* An App cannot change the CoreOS. - -It s not allowed for an App to modify or add an element to the CoreOS. -Like with containers App are required to embed all the code required for their operation. -Within this limitation Apps (which can be a only a service) can still offer services to other App by the mean of AGL binders which use the autenticated AGL transport. - -### AGL Platform protections - -By default AGL provides three specific protection services : - -* Privilege management and enforment via cynara -* Autenticated transport (via AGL binders, websocket and Oauth2) -* App origin validation - -Because AGL Apps also include services provided by Middleware, new APIs can be created by Apps and new privileges may be required to access those API. -e.g. a Free Parking space service App from Vinci may offer an API for any Navigation system to read the free parking space count for a given location in order to display it on the Map. -We may not want to leave wide open that new API what would induce mobile data with its associated charges. - -That small use case, shows how AGL AppFW will not only, have to register the privileges requested by an App in Cynara, it will also have to add new privileges associated with API created by Apps. - -### Protections enforcement - -Platform Securities are enforced by Linux as soon as they are activated. -This is the simpler case. -We just need to be sure that means to deactivate those protections are removed from the kernel configuration (see Kernel hardning). - -AGL Platform protections are mostly enforced by dedicated middleware which are protected by the platform securities. -Some more risky zones are identified : - -* the creation of binding where an App could create a look a like binding that does not respect any protection. -* services which provide a wide range of service and need to restict the user request following his profile. - -The first one can be enforced by removing by setcomp the option to create websocket directly by an App and requesting the creation to be done via a trusted service at binding enabling. -The second requires a duplication of some API in order to be able to keep the filtering on the verbs of the API without requiring to drill down to the parameters. - -The side effect of this complexity will impose to create an introspection mode where there is the possibility to verify all the API offered by an App and which privileges are required to activate them. - -### Privilege grouping - -In order keep the concept of White listing manageable, a privilege hiercharchy is used. -A small example shoudl clarify that concept. - -* System:Com:SMS:notify -* System:Com:SMS:list -* System:Com:SMS:display -* System:Com:SMS:send -* System:Com:SMS:transfer -* System:Com:SMS: (*the* requires to be explicit on global capability request) -* System:Com:Phone:notify -* System:Com:Phone:list -* System:Com:Phone:display -* System:Com:Phone:send -* System:Com:Phone:transfer -* System:Com:Phone:* -* System:Com:* (includes SMS:* & Phone:*) -* System:Com:*:notify (includes SMS:notify & Phone:notify) - - That last concept might be too complex to implement and real usefulness should be validated. diff --git a/sec-blueprint/08-Hardening.md b/sec-blueprint/07-system-hardening.md index 91bd823..5ffe501 100644 --- a/sec-blueprint/08-Hardening.md +++ b/sec-blueprint/07-system-hardening.md @@ -17,17 +17,18 @@ layout: techdoc ## Scope -The information contained in this document is applicable to systems based -on Automotive Grade Linux. +This document provides recommended guidelines for adding protection to an +embedded system. The information contained in this document is applicable +to systems based on Automotive Grade Linux. ## Limitations -* This document is based on knowledge and research gained from looking - at security desktop and server versions of Linux as well as Android - exploits and hardening. +- This document is based on knowledge and research gained from looking + at security desktop and server versions of Linux as well as Android + exploits and hardening. -* Some kernel configuration options can have an impact on performance. - This will be noted where applicable. +- Some kernel configuration options can have an impact on performance. + This will be noted where applicable. ## Document Structure @@ -67,27 +68,27 @@ attack surfaces used by potential attackers. ## Secure Boot Software Flow Steps -1. After power on, the processor will perform the verification - of the Stage 1 boot image, the stage 2 boot image and the Secure - loader image. +1. After power on, the processor will perform the verification + of the Stage 1 boot image, the stage 2 boot image and the Secure + loader image. - a. If any of the images fail the verification process the device - will not boot. + a. If any of the images fail the verification process the device + will not boot. -1. Upon successful verification of all of the boot and loader images, +2. Upon successful verification of all of the boot and loader images, the secure process will initiate the Stage 1 boot process. -1. The Stage 1 boot process will perform processor initialization, and - then initiate the Stage 2 boot process. +3. The Stage 1 boot process will perform processor initialization, and + then initiate the Stage 2 boot process. -1. The Stage 2 boot process will initiate the Secure Loader, which will - process any customer specific customizations (e.g. front panel - of ECU, USB based image updates, etc). +4. The Stage 2 boot process will initiate the Secure Loader, which will + process any customer specific customizations (e.g. front panel + of ECU, USB based image updates, etc). -1. The Secure Loader will check to determine if there are any updates - to be processed. If the update settings indicate that an upgrade - should occur then the Secure Loader will will determine the correct - action based on the nature of the upgrades: +5. The Secure Loader will check to determine if there are any updates + to be processed. If the update settings indicate that an upgrade + should occur then the Secure Loader will will determine the correct + action based on the nature of the upgrades: a. If the Secure Loader determines that an upgrade was performed (or attempted), it will initiate the reboot process. @@ -95,25 +96,25 @@ attack surfaces used by potential attackers. b. If no upgrades were processed: then the Secure Loader will pass control back to the Stage 2 boot process for further processing -1. The Stage 2 boot process will continue with the boot process, by +6. The Stage 2 boot process will continue with the boot process, by performing a verification of the kernel image prior to the load of that image a. If the kernel image verification fails, the Stage 2 boot loader will not boot -1. The Stage 2 boot loader will load the successfully verified kernel - and boot the linux OS +8. The Stage 2 boot loader will load the successfully verified kernel + and boot the linux OS -1. The booted Linux OS will perform the normal Linux init sequence +9. The booted Linux OS will perform the normal Linux init sequence -1. The Linux init process will start the required applications and - services as described in the init process and present on the rootfs. +10. The Linux init process will start the required applications and + services as described in the init process and present on the rootfs. -## Requirements +# Requirements For the purposes of reference and explanation, we are providing guidance - on how to configure an embedded device that runs with a linux 3. 10.17 + on how to configure an embedded device that runs with a 3.10.17 Linux kernel, and includes the use of U-Boot as the *Stage 2* These requirements must still be met by manufacturers that opt to build using an alternative version of the Linux kernel. @@ -137,7 +138,7 @@ feature is available from U-Boot 2013.07 version. To enable the secure boot feature, enable the following features: -```bash +``` CONFIG_FIT: enables support for Flat Image Tree (FIT) uImage format. CONFIG_FIT_SIGNATURE: enables signature verification of FIT images. CONFIG_RSA: enables RSA algorithm used for FIT image verifitcation. @@ -155,7 +156,7 @@ image. It shall use RSA2048 and SHA256 for authentication. To disable USB support in U-Boot, following configs shall not be defined: -```bash +``` CONFIG_CMD_USB: enables basic USB support and the usb command CONFIG_USB_UHCI: defines the lowlevel part. CONFIG_USB_KEYBOARD: enables the USB Keyboard @@ -168,7 +169,7 @@ CONFIG_USB_HOST_ETHER: enables USB ethernet adapter support Serial console output shall be disabled. To disable console output in U-Boot, set the following macros: -```bash +``` CONFIG_SILENT_CONSOLE CONFIG_SYS_DEVICE_NULLDEV CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC @@ -178,7 +179,7 @@ and set “***silent”*** environment variable. For the Secure loader, disable the traces by undefining the below macro -```bash +``` INC_DEBUG_PRINT ``` @@ -214,7 +215,7 @@ default environment variable and not in non-volatile memory. Remove configuration options related to non-volatile memory such as: -```bash +``` #define CONFIG_ENV_IS_IN_MMC #define CONFIG_ENV_IS_IN_EEPROM #define CONFIG_ENV_IS_IN_FLASH @@ -231,7 +232,7 @@ Remove configuration options related to non-volatile memory such as: and include the following definition: -```bash +``` #define** CONFIG_ENV_IS_NOWHERE ``` @@ -270,7 +271,7 @@ and include the following definition: applications, the following kernel option should be set in the compile-time kernel configuration: -```bash +``` CONFIG_DEVKMEM=n ``` @@ -538,23 +539,28 @@ and include the following definition: ```bash CONFIG_MODULE_FORCE_LOAD=n ``` - ### System Services #### Console & Remote Access -* The kernel console interfaces shall be disabled. Do not pass any statements - of the following kind (e.g. console=ttyS0 console=tty0) on the kernel - command line. All of the console=<interface> statements should be - stripped and removed from the kernel command line. -* The telnet server shall be disabled. -* Do not start telnetd in init scripts. -* Remove telnetd from the root file system. -* Root login access via the console shall be disabled. -* Do not run shell or getty on /dev/ttySx or /dev/console from - init scripts. -* Root login access through remote access such as SSH shall - be disabled or completely removed +- The kernel console interfaces shall be disabled. Do not pass any statements + of the following kind (e.g. console=ttyS0 console=tty0) on the kernel + command line. All of the console=<interface> statements should be + stripped and removed from the kernel command line. + +- The telnet server shall be disabled. + +- Do not start telnetd in init scripts. + +- Remove telnetd from the root file system. + +- Root login access via the console shall be disabled. + +- Do not run shell or getty on /dev/ttySx or /dev/console from + init scripts. + +- Root login access through remote access such as SSH shall + be disabled or completely removed #### Disable *sudo* for other users @@ -574,46 +580,46 @@ and include the following definition: #### User Account Management -All user accounts shall have strong, non-default passwords. -A strong password is described to have all of the following attributes: + All user accounts shall have strong, non-default passwords. A strong + password is described to have all of the following attributes: -* At least one upper-case letter +- At least one upper-case letter -* At least one numeric character +- At least one numeric character -* At least one lower-case letter +- At least one lower-case letter -* Password shall be eight or more characters in length +- Password shall be eight or more characters in length -* Shall not use a known, common pattern (e.g. Xxxxxxx\# - or Xxxxxxx\#\#) +- Shall not use a known, common pattern (e.g. Xxxxxxx\# + or Xxxxxxx\#\#) #### Remove known insecure services The following legacy services are inherently insecure and should be avoided: -* rlogind +- rlogind -* rshd +- rshd -* rcmd +- rcmd -* rexecd +- rexecd -* rbootd +- rbootd -* rquotad +- rquotad -* rstatd +- rstatd -* rusersd +- rusersd -* rwalld +- rwalld -* rhosts +- rhosts -* rexd +- rexd These services offer insufficient authentication, no encryption, and are not considered secure. They shall be removed along with their @@ -627,51 +633,51 @@ A strong password is described to have all of the following attributes: non-exhaustive sample of commonly used utilities that are part of the mtd-utils package: -* flash\_erase +- flash\_erase -* flash\_eraseall +- flash\_eraseall -* flashcp +- flashcp -* flash\_lock +- flash\_lock -* flash\_otp\_dump +- flash\_otp\_dump -* flash\_otp\_info +- flash\_otp\_info -* flash\_unlock +- flash\_unlock -* mkfs.jffs2 +- mkfs.jffs2 -* mkfs.ubifs +- mkfs.ubifs -* nanddump +- nanddump -* nandtest +- nandtest -* nandwrite +- nandwrite -* ubiattach +- ubiattach -* ubicrc32 +- ubicrc32 -* ubidetach +- ubidetach -* ubiformat +- ubiformat -* ubimkvol +- ubimkvol -* ubinfo +- ubinfo -* ubinize +- ubinize -* ubirename +- ubirename -* ubirmvol +- ubirmvol -* ubirsvol +- ubirsvol -* ubiupdatevol +- ubiupdatevol The mtd-utils package as a whole (including all of its executable binaries) shall not be present on the file system. Including these @@ -708,6 +714,7 @@ A strong password is described to have all of the following attributes: The following flags shall be used for mounting common filesystems: + | Partition | Notes | |------------------------------|---------------------------------------------------------------------------------------------| | /boot | Use nosuid and nodev and consider using noexec. | @@ -720,8 +727,9 @@ A strong password is described to have all of the following attributes: | | Note: if CONFIG\_DEVTMPFS\_MOUNT is set then the kernel will mount /dev and will not apply | | | the nosuid, noexec options. Either disable CONFIG\_DEVTMPFS\_MOUNT or add a remount with | | | noexec and nosuid options to system startup. | + -## Recommendations +# Recommendations The following sections detail best practices that should be applied in order to secure a device. @@ -730,7 +738,7 @@ requirements, they may be upgraded to requirements status in the future. In addition, specific operators may change some of these recommendations into requirements based on their specific needs and objectives. -### Hardened Boot +## Hardened Boot The boot loader consists of the Primary boot loader residing in OTP memory, sboot, U-Boot and Secure loader residing in external flash (NAND @@ -745,7 +753,7 @@ Kernel/system image before passing control to it. In U-Boot, following commands shall be disabled to avoid memory dumps -```bash +``` md : Memory Display command mm : Memory modify command – auto incrementing address @@ -787,7 +795,7 @@ if any. enabled services should be restricted to only those described in the STB’s functional description. -### Remove or Disable Unnecessary Services, Ports, and Devices +### Remove or Disable Unnecessary Services, Ports, and Devices. Services and utilities that do not have a defined purpose on a system should be removed. If removal is not possible, but the service or @@ -877,7 +885,6 @@ if any. This configuration is supported in Linux 3.5 and greater and thus should only be disabled for such versions. - ```bash CROSS_MEMORY_ATTACH=n ``` @@ -1007,43 +1014,35 @@ applications to avoid stack smashing, buffer overflow attacks. ### Stack Smashing Attacks -```c -**-fstack-protector-all** -``` - -Emit extra code to check for buffer overflows, such as stack smashing attacks + **-fstack-protector-all** + + Emit extra code to check for buffer overflows, such as stack smashing + attacks ### Position Independent Executables -```c -**-pie –fpic**: -``` - -Produce a position independent executable on targets which supports it. + **-pie –fpic** + + Produce a position independent executable on targets which supports + it. ### Detect Buffer Overflows -```c -**-D\_FORTIFY\_SOURCE=2**: -``` - -Helps detect some buffer overflow errors. + **-D\_FORTIFY\_SOURCE=2** + + Helps detect some buffer overflow errors. ### Prevent Overwrite Attacks -```c -**–z,relro** -``` - + **–z,relro** + This linking option helps during program load, several ELF memory sections need to be written by the linker, but can be turned read-only before turning over control to the program. This prevents some Global Offset Table GOT overwrite attacks, or in the dtors section of the ELF binary. - -```c -**-z,now** -``` + + **-z,now** During program load, all dynamic symbols are resolved, allowing for the complete GOT to be marked read-only (due to -z relro above). This @@ -1053,9 +1052,7 @@ resolved, but this shouldn't be an issue for daemons. ### Library linking -```c -**–static** -``` + **–static** It is recommended that dynamic linking should not be allowed. This will avoid user from replacing a library with malicious library. All libraries @@ -1110,7 +1107,7 @@ utilities are not required by the device then those should be removed. **sed, awk, cut, df, dmesg, echo, fdisk, grep, mkdir, mount (vfat), printf, tail, tee, test (directory), test (file)** -## Root Access +## Root Access The main applications, those that provide the principal functionality of the embedded device, **should not execute** with root identity or any @@ -1133,7 +1130,7 @@ the same resources at the same time. Root access **should not be allowed** for the following utilities: -```bash +``` login su ssh @@ -1223,11 +1220,12 @@ environment via sudo. SYN requests with the appropriate SYN+ACK reply, but it does not store the connection in its backlog queue. -## Validation -### Hardened System +# Validation + +## Hardened System -#### Image Security Analysis Framework (ISAFW) +### Image Security Analysis Framework (ISAFW) **meta-security-isafw** is an OE layer that allows enabling the Image Security Analysis Framework (isafw) for your image builds. @@ -1237,12 +1235,12 @@ framework for analysing different security aspects of images during the build process. The isafw project itself can be found at - <https://github.com/01org/isafw> + https://github.com/01org/isafw This layer can be added to your builds to produce an analysis report, including a kernel config analysis. -#### Usage +### Usage In order to enable the isafw during the image build, please add the following line to your build/conf/local.conf file: diff --git a/sec-blueprint/App-flow.png b/sec-blueprint/App-flow.png Binary files differnew file mode 100644 index 0000000..7b87c29 --- /dev/null +++ b/sec-blueprint/App-flow.png diff --git a/sec-blueprint/App_signing_flow.png b/sec-blueprint/App_signing_flow.png Binary files differnew file mode 100644 index 0000000..56a7c23 --- /dev/null +++ b/sec-blueprint/App_signing_flow.png diff --git a/sec-blueprint/index.md b/sec-blueprint/index.md index e20c2aa..776d5ed 100644 --- a/sec-blueprint/index.md +++ b/sec-blueprint/index.md @@ -1,7 +1,7 @@ --- title : Security BluePrint Overview -date : 2016-07-06 +date : 2017-07-07 category: security tags: security, architecture, automotive, linux layout: techdoc @@ -10,12 +10,14 @@ layout: techdoc ## [Overview](./01-overview.html) -## [Plateform Security](./02-plateform-security.html) +## [Adversaries](./02-adversaries.html) -## [Security Concepts](./03-security-concepts.html) +## [Threat Analysis](./03-threat-analysis.html) -## [Adversaries](./04-adversaries.html) +## [Security Concepts](./04-security-concepts.html) -## [Threat Analysis](./04-threat-analysis.html) +## [Plateform Security](./05-plateform-security.html) -## [Attack Surfaces](./06-attack-surfaces.html) +## [Application Security](./06-application-security.html) + +## [System Hardening](./07-system-hardening.html) |
