Added content from the hidden chapter of the "old" security-blueprint.

13 files changed, 553 insertions, 10 deletions

diff --git a/security-blueprint/README.md b/security-blueprint/README.md
index 4ae67de..a3cf24c 100644
--- a/security-blueprint/README.md
+++ b/security-blueprint/README.md
@@ -1,7 +1,13 @@
 # Introduction
 
-This document presents the different attacks that can be envisaged on a recent car in order to be able to create a set of tests verifying the security of Automotive Grade Linux (AGL).
-The more general utility behind this document is to protect the manufacturers, customers and third party from potential financial and information loss.
+Modern cars have become a lot more technologically sophisticated and different than those of the past. We are seeing a wider range of new features and functionality, with a lot more complex software. It is fair to say that the cars being introduced to the market today have much more in common with computing devices like cell phones, than their predecessors did. Modern car manufacturers are also integrating support for a broad range of communication technologies for these “connected” cars. With the advent of such vehicles, Linux has become a natural choice for the software platform, with Automotive Grade Linux as a promising example.
+
+From a security point of view, the remote capabilities of a connected car results in a much larger attack surface. This opens a whole new world of security vulnerabilities that need to be considered during the architectural design. History shows that physical access to a device is sufficient for a hacker to gain root privileges. This makes the car a hostile environment.
+
+The Security Blueprint documents the security features that are included as part of Automotive Grade Linux (AGL) and identifies areas that need to be addressed from a security perspective as part of AGL. It also gives guidance around existing technologies and solutions.
+
+Security domains will allow us to create a set of tests verifying the security of Automotive Grade Linux.
+
 This document is firstly based on an existing AGL security-blueprint.
 
 **For security to be effective, the concepts must be simple. And by default, anything that is not allowed is forbidden.**
@@ -26,6 +32,65 @@ The document is filled with tags to easily identify important points:
 
 In annexes of this document, you can find all the _config_ and _todo_ notes.
 
+## Adversaries
+
+Adversaries and attackers within the Automotive space.
+
+- Enthusiast Attackers
+
+Enthusiast attackers have physical access to the Engine Control Units (ECUs) at the circuit board level. They can solder ‘mod chips’ onto the board and have access to probing tools. They also have information on ECUs that have been previously compromised and have access to softwares and instructions developed by other members of car modification forums. The goal of the enthusiast hacker could be, but is not limited to, adding extra horse power to the car or hacking it just for fun.
+
+- Corrupt Automotive Dealers
+
+Corrupt automotive dealers are attackers that have access to the same capabilities as enthusiasts, but also have access to the car manufacturer’s (OEM) dealer network. They may also have access to standard debugging tools provided by the car manufacturer. Their goal may be to support local car theft gangs or organized criminals.
+
+- Organized Criminals
+
+Organized criminals have access to all of the above tools but may also have some level of control over the internal network at many dealerships. They may have hacked and gained temporary control of the Over-The-Air (OTA) servers or the In-Vehicle Infotainment (IVI) systems. This is very much like the role of organized criminals in other industries such as paid media today. Their goal is to extort money from OEMs and/or governments by threatening to disable multiple vehicles.
+
+- Malware Developers
+
+Malware developers have developed malicious software to attack and compromise a large number of vehicles. The malicious software is usually designed to spread from one vehicle to another. Usually, the goal is to take control of multiple machines and then sell access to them for malicious purposes like denial-of-service (DoS) attacks or theft of private information and data.
+
+- Security Researchers
+
+Security researchers are ‘self-publicized’ security consultants trying to make a name for themselves. They have access to standard tools for software security analysis. They also have physical access to the vehicle and standard hardware debugging tools (Logic Analyzers, Oscilloscopes, etc). Their goal is to publicize attacks for personal gain or just to gain personal understanding with a sense of helping make things more secure.
+
+## Attack Goals
+
+In today’s connected vehicle, more and more functionality is moving to software control, meaning that the threat of attack becomes greater and greater. We see car features like navigation and summoning, car access/engine start, and motor/ECU upgrades all controlled through software and connections to the cloud. The risk of attack is high because there are high value targets in play.
+
+Here, we outline some of the major threats categories along with some sample attackers, example attacks, and a relative importance. These threat categories are intended to be general examples. There can be many nuances to threat types. Additionally, there can be many sub-attacks that eventually lead to these higher level attack goals.
+
+| Threat Category               | Sample Attacker                         | Example Attacks                                                                                       | Relative Importance                                                                                                                            |
+|-------------------------------|-----------------------------------------|-------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------|
+| Vehicle theft                 | Individual, organized criminals         | Send the car to an unplanned destination, get a key for the car, gain control of the unlock mechanism | Reduced likelihood of future vehicle purchases (Profit Later), bad press (Brand Integrity)                                                     |
+| Reduced vehicle functionality | Terrorist groups, disgruntled employees | Lock the driver out of the car, cause the car to crash, block access to infotainment system           | Inability sell paid-for apps and content (Profit Now), bad press (Brand Integrity), possible loss of life (Physical Injury)                    |
+| Vehicle hacking               | Vehicle owner, competitor               | Get content without paying, modify DRM licenses, unlock of after-market features, theft of IP         | Loss of sales for content and features (Profit Now), lawsuits from content owners (Profit Later), loss of competitive advantage (Profit Later) |
+| Sensitive asset theft         | Organized criminals, blackmailers       | Steal credit card numbers, health information, camera data, steal bandwidth                           | Bad press (Brand Integrity), lawsuits from vehicle owners (Profit Later)                                                                       |
+
+The Automotive Grade Linux (AGL) initiative builds upon open-source software including Linux and Tizen to offer a flexible application framework. However, the security provisions of the app framework, Cynara, and the security manager only go so far in keeping the biggest threats at bay. As experience has shown, providing a constrained app (like that in the Android Open Source Platform) and store development flow, signature verification, DAC sandboxing, and MAC (SMACK) controls over the platform can have a certain amount of success with the security of the system. However, the openness of the system invites many researchers, hobbyists and hackers and financially motivated attackers to compromise the system for their own gains.
+
+As AGL arrives on modern automobiles, this is inevitably inviting many capable actors to modify, attack, and compromise these well thought-out systems and their applications. With concerns like safety and security, the auto industry cannot afford to go the way of consumer devices like phones and tablets where security problems are encountered on a frequent basis. It is imperative to use a layered approach and defense-in-depth to protect the system from inevitable attack.
+
+## Assets and Security Categorization
+
+This section outlines some of the assets that are likely to be found in the vehicle and their relative sensitivity from an attack point of view. Additionally, the final column on the right lists some of the recommended protection types that can be applied to these types of assets (Note that the empty cells refer to the cells above them). A good protection approach will give priority to the most sensitive assets, using a defense-in-depth approach to cover these assets. Less sensitive assets are treated at a lower priority, typically protected with fewer protection techniques. A more fine-grained prioritization of the the assets in a concrete vehicle network can be achieved with detailed threat analysis which considers the topology of the vehicle network and access-controls that are in-place. e.g. the EVITA framework for attack trees.
+
+| Asset Category    | Examples                                                                       | Sensitivity | Recommended Protection Types                                                                                                                                                                         |
+|-------------------|--------------------------------------------------------------------------------|-------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Software          | ECU software, infotainment software, OS images                                 | Critical    | Key Management, Mutual Asymmetric Authentication, HSM and WhiteBox Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms/ Obfuscation, Integrity Verification, Secure OS |
+| Car Access        | Biometric data, car keys                                                       |             |                                                                                                                                                                                                      |
+| Payment Data      | Credit cards, User profile critical data                                       |             |                                                                                                                                                                                                      |
+| Recordings        | Internal camera recording, internal audio recording, external camera recording | High        | Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms / Obfuscation                                                                                                      |
+| User Profile      | Usernames and passwords, customization, calendar, contacts                     |             |                                                                                                                                                                                                      |
+| Location          | GPS coordinates, vehicle usage data                                            |             |                                                                                                                                                                                                      |
+| Purchased Content | Video, audio, licenses                                                         |             |                                                                                                                                                                                                      |
+| Teleconference    | Chat, audio, video                                                             | Medium      | SW Protection, Program Transforms / Obfuscation, Authenticated encryption for transmission                                                                                                           |
+| Vehicle data      | Vehicle info, sensor data                                                      |             |                                                                                                                                                                                                      |
+| Navigation data   | Static and dynamic maps                                                        |             |                                                                                                                                                                                                      |
+| 3rd party data    | Home automation commands, cloud game data                                      |             |                                                                                                                                                                                                      |
+
 ## Hardening term
 
 The term Hardening refers to the tools, techniques and processes required in order to reduce the attack surface on an embedded system, such as an embedded control unit (**ECU**) or other managed devices. The target for all hardening activities is to prevent the execution of invalid binaries on the device, and to prevent copying of security related data from the device.
@@ -44,10 +109,10 @@ AGL roots are based on security concepts. Those concepts are implemented by the
 
 The following table lists the strongest terms utilized within all this document.
 
-Acronyms or Abbreviations | Description
-------------------------- | -----------------------------------
-_AGL_                     | **A**utomotive **G**rade **L**inux
-_ECU_                     | **E**lectronic **C**ontrol **U**nit
+| Acronyms or Abbreviations | Description                         |
+|---------------------------|-------------------------------------|
+| _AGL_                     | **A**utomotive **G**rade **L**inux  |
+| _ECU_                     | **E**lectronic **C**ontrol **U**nit |
 
 --------------------------------------------------------------------------------
 
diff --git a/security-blueprint/part-1/0_Abstract.md b/security-blueprint/part-1/0_Abstract.md
index 5664890..e13c464 100644
--- a/security-blueprint/part-1/0_Abstract.md
+++ b/security-blueprint/part-1/0_Abstract.md
@@ -2,6 +2,13 @@
 
 ## Abstract
 
+The Automotive Grade Linux 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.
+
 You will find in this first part everything that concerns the hardware security.
 The goal is to protect system against all attacks that are trying to gain
 additional privileges by recovering and/or changing cryptographic keys in order
diff --git a/security-blueprint/part-2/0_Abstract.md b/security-blueprint/part-2/0_Abstract.md
index da9daee..fa99d89 100644
--- a/security-blueprint/part-2/0_Abstract.md
+++ b/security-blueprint/part-2/0_Abstract.md
@@ -10,6 +10,11 @@ Boot-Abstract-1 | More generic and add examples (The chain of trust).
 
 <!-- end-section-todo -->
 
+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.
+
 **Boot Hardening**: Steps/requirements to configure the boot sequence, in order
 to restrict the device from executing anything other than the approved software
 image.
diff --git a/security-blueprint/part-4/0_Abstract.md b/security-blueprint/part-4/0_Abstract.md
index edf75be..01957e4 100644
--- a/security-blueprint/part-4/0_Abstract.md
+++ b/security-blueprint/part-4/0_Abstract.md
@@ -18,3 +18,43 @@ applications compiled to take advantage of these security features.
 Additionally, there are also configuration options that protect from known
 vulnerable configuration options. Here's a high level summary of various kernel
 configurations that shall be required for deployment.
+
+## 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.
+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.
+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 verification 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 this section.
diff --git a/security-blueprint/part-5/0_Abstract.md b/security-blueprint/part-5/0_Abstract.md
index e724321..6841230 100644
--- a/security-blueprint/part-5/0_Abstract.md
+++ b/security-blueprint/part-5/0_Abstract.md
@@ -2,6 +2,17 @@
 
 ## Abstract
 
+The Automotive Grade Linux platform is a Linux distribution with **AGL** compliant applications and services.
+The 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 (chapter Update).
+- Building and debug tools (based on Yocto project).
+
 This part focuses on the AGL platform including all tools and techniques used to
 upgrade the security and downgrade the danger. It must be possible to apply the
 two fundamental principles written at the very beginning of the document. First
@@ -17,8 +28,8 @@ to deal with, we must:
 
 <!-- section-note -->
 
-The tools and concepts used to meet these needs are only examples. Any other
-tool that meets the need can be used.
+The tools and concepts used to meet these needs are only examples.
+Any other tool that meets the need can be used.
 
 <!-- end-section-note -->
 
@@ -31,6 +42,34 @@ on the user and the application being run: an application should have access to
 a given service only if it is run by the proper user and if the appropriate
 permissions are granted.
 
+## Discretionary Access Control
+
+**D**iscretionary **A**ccess **C**ontrol (**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 **M**andatory **A**ccess **C**ontrol (**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
+
+**M**andatory **A**ccess **C**ontrol (**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.
+
 --------------------------------------------------------------------------------
 
 <!-- pagebreak -->
@@ -45,6 +84,7 @@ _ACL_                     | **A**ccess **C**ontrol **L**ists
 _alsa_                    | **A**dvanced **L**inux **S**ound **A**rchitecture
 _API_                     | **A**pplication **P**rogramming **I**nterface
 _AppFw_                   | **App**lication **F**rame**w**ork
+_BSP_                     | **B**oard **S**upport **P**ackage
 _Cap_                     | **Cap**abilities
 _DAC_                     | **D**iscretionary **A**ccess **C**ontrol
 _DDOS_                    | **D**istributed **D**enial **O**f **S**ervice
diff --git a/security-blueprint/part-5/1-MAC.md b/security-blueprint/part-5/1-MAC.md
index 02a0e37..73543e9 100644
--- a/security-blueprint/part-5/1-MAC.md
+++ b/security-blueprint/part-5/1-MAC.md
@@ -134,3 +134,32 @@ Kernel-MAC-System-2 | `User::Home`        | AppFw needs to create a directory in
 Kernel-MAC-System-3 | `User::App-Shared`  | Shared space between all App running for a given user.
 
 <!-- end-section-config -->
+
+## Attack Vectors
+
+There are 4 major components to the system:
+
+- The LSM kernel module.
+- The `smackfs` filesystem.
+- Basic utilities for policy management and checking.
+- 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.
+- Tampering 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).
diff --git a/security-blueprint/part-5/5-AppFw.md b/security-blueprint/part-5/5-AppFw.md
index 923c591..292fa1a 100644
--- a/security-blueprint/part-5/5-AppFw.md
+++ b/security-blueprint/part-5/5-AppFw.md
@@ -1,5 +1,12 @@
 # Application framework/model (**AppFw**)
 
+The AGL application framework consists of several inter-working parts:
+
+- **SMACK**: The kernel level **LSM** (**L**inux **S**ecurity **M**odule) 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`.
+
 The application framework manages:
 
 - The applications and services management: Installing, Uninstalling, Listing, ...
@@ -15,8 +22,8 @@ The application framework manages:
   implementation detail that should not impact the layers above the application
   framework.
 
-- The **security model** refers to how **DAC** (Discretionary Access Control),
-  **MAC** (Mandatory Access Control) and Capabilities are used by the system to
+- The **security model** refers to how **DAC** (**D**iscretionary **A**ccess **C**ontrol),
+  **MAC** (Mandatory Access Control) and `Capabilities` are used by the system to
   ensure security and privacy. It also includes features of reporting using
   audit features and by managing logs and alerts.
 
@@ -39,6 +46,19 @@ information.
 
 <!-- pagebreak -->
 
+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.
+
+![App Framework Flow](App-flow.png)
+
 ## Cynara
 
 There's a need for another mechanism responsible for checking applicative
@@ -50,6 +70,27 @@ permissions: Currently in AGL, this task depends on a policy-checker service
 
 Cynara interact with **D-Bus** in order to deliver this information.
 
+Cynara 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.
+
+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.
+
 <!-- section-config -->
 
 Domain                  | Object      | Recommendations
@@ -78,3 +119,197 @@ Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service.
 Policies are kept in buckets. Buckets are set of policies which have additional
 a property of default answer, the default answer is yielded if no policy matches
 searched key. Buckets have names which might be used in policies (for directions).
+
+## 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.
+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`.
\ No newline at end of file
diff --git a/security-blueprint/part-5/App-flow.png b/security-blueprint/part-5/App-flow.png
new file mode 100644
index 0000000..7b87c29
--- /dev/null
+++ b/security-blueprint/part-5/App-flow.png
diff --git a/security-blueprint/part-6/0_Abstract.md b/security-blueprint/part-6/0_Abstract.md
index b8aabb6..3617dbd 100644
--- a/security-blueprint/part-6/0_Abstract.md
+++ b/security-blueprint/part-6/0_Abstract.md
@@ -11,6 +11,54 @@ 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 containment is achieved using the following protections:
+
+- Linux Native protection
+  - Mandatory Access Control (**MAC**)
+- AGL Platform protections
+  - Origin Tracking and Validation
+  - Application Privilege Management and Enforcement via Cynara
+  - Authenticated Transport via D-Bus
+
+## 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 (**AppFw**) consists of a number of utilities and
+daemons which provide context for the applications.
+Isolation is provided through **SMACK** labels.
+
+## 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.
+
+![App Signing Flow](App_signing_flow.png)
+
+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.
+
 --------------------------------------------------------------------------------
 
 ## Acronyms and Abbreviations
diff --git a/security-blueprint/part-6/App_signing_flow.png b/security-blueprint/part-6/App_signing_flow.png
new file mode 100644
index 0000000..56a7c23
--- /dev/null
+++ b/security-blueprint/part-6/App_signing_flow.png
diff --git a/security-blueprint/part-7/1-BusAndConnectors.md b/security-blueprint/part-7/1-BusAndConnectors.md
index 0cdedc2..5ab9ab8 100644
--- a/security-blueprint/part-7/1-BusAndConnectors.md
+++ b/security-blueprint/part-7/1-BusAndConnectors.md
@@ -25,6 +25,20 @@ packets. We just describe them a bit:
   2001 on everywhere in a car, where the bandwidth and versatility of a **CAN**
   network is not required.
 
+On just about every vehicle, **ECU**s (**E**lectronic **C**ontrol **U**nits)
+communicate over a CAN bus, which is a two-wire bus using hardware arbitration
+for messages sent on the shared medium. This is essentially a *trusted* network
+where all traffic is visible to all controllers and any controller can send any message.
+
+A malicious **ECU** on the CAN bus can easily inject messages destined for any
+other device, including things like the instrument cluster and the head unit.
+There are common ways for hardware to do USB to CAN and open source software to send
+and receive messages. For example, there is a driver included in the Linux kernel
+that can be used to send/receive CAN signals. A malicious device on the CAN bus can
+cause a great number of harmful things to happen to the system, including: sending
+bogus information to other devices, sending unintended commands to ECUs,
+causing DOS (Denial Of Service) on the CAN bus, etc.
+
 <!-- section-config -->
 
 Domain                             | Tech name | Recommendations
diff --git a/security-blueprint/part-8/0_Abstract.md b/security-blueprint/part-8/0_Abstract.md
index 1e7bf6b..e438e65 100644
--- a/security-blueprint/part-8/0_Abstract.md
+++ b/security-blueprint/part-8/0_Abstract.md
@@ -10,6 +10,56 @@ alter the functioning of the system and/or applications. The security of the
 updates is therefore a critical point to evaluate in order to guarantee the
 integrity, the confidentiality and the legitimacy of the transmitted data.
 
+## Attack Vectors
+
+Updates 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 back-end.
+* 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)
+
+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.
+
 --------------------------------------------------------------------------------
 
 ## Acronyms and Abbreviations
@@ -19,6 +69,8 @@ The following table lists the terms utilized within this part of the document.
 Acronyms or Abbreviations | Description
 ------------------------- | -------------------------------------------------------------------------
 _FOTA_                    | **F**irmware **O**ver **T**he **A**ir
+_MATE_                    | **M**an **A**t **T**he **E**nd
+_MITM_                    | **M**an **I**n **T**he **M**iddle
 _OTA_                     | **O**ver **T**he **A**ir
 _SOTA_                    | **S**oftware **O**ver **T**he **A**ir
 _TUF_                     | **T**he **U**pdate **F**ramework
diff --git a/security-blueprint/part-8/2-SOTA.md b/security-blueprint/part-8/2-SOTA.md
index ab8d9fd..57df6fc 100644
--- a/security-blueprint/part-8/2-SOTA.md
+++ b/security-blueprint/part-8/2-SOTA.md
@@ -1,5 +1,13 @@
 # Software Over The Air
 
+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 **OTA** update model, securing these processes becomes a high priority.
+
 **SOTA** is made possible by **AppFw** (See Platform part). It will be possible
 to manage in a simple way the packets (i.g. Android like).