summaryrefslogtreecommitdiffstats
path: root/docs/2_Architecture_Guides
diff options
context:
space:
mode:
authorVinod Ahuja <vahuja@unomaha.edu>2022-11-07 16:18:44 -0600
committerJan-Simon Moeller <jsmoeller@linuxfoundation.org>2022-11-08 14:47:43 +0000
commit8be9db6f309e1e1b547e187c5db6ceac15f85a50 (patch)
treeca3a6179b37b381eaee1bf948aebf78c809883b4 /docs/2_Architecture_Guides
parente660399f8b909146a699e44eb340b8c0b7e7f12f (diff)
Fixing the index numbering
Fixing the index numbering for all documentation Bug-AGL: [SPEC-4470] Signed-off-by: Vinod Ahuja <vahuja@unomaha.edu> Change-Id: I96b482a3ab598f0739c692e301de66c0553ba0e4 Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/documentation/+/28118 Reviewed-by: Walt Miner <wminer@linuxfoundation.org> Reviewed-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org> Tested-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
Diffstat (limited to 'docs/2_Architecture_Guides')
-rw-r--r--docs/2_Architecture_Guides/1_Introduction/0_Overview.md53
-rw-r--r--docs/2_Architecture_Guides/1_Introduction/1_AGL_Requirements_Specifications.md8
-rw-r--r--docs/2_Architecture_Guides/1_Introduction/AGL Requirements Specifications.pdfbin3801991 -> 0 bytes
-rw-r--r--docs/2_Architecture_Guides/1_Introduction/images/architecture.jpgbin687441 -> 0 bytes
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/0_Overview.md250
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/1_Hardware.md64
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/2_Secure_Boot.md261
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/3_Hypervisor.md17
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/4_Kernel.md941
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/5_Platform.md921
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/6_Application.md125
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/7_Connectivity.md487
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/8_Update_OTA.md154
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/9_Secure_development.md58
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/Annexes.md578
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/images/App-flow.pngbin73545 -> 0 bytes
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/images/App_signing_flow.pngbin154923 -> 0 bytes
-rw-r--r--docs/2_Architecture_Guides/2_Security_Blueprint/images/WhiteBoxArchi.pngbin348110 -> 0 bytes
18 files changed, 0 insertions, 3917 deletions
diff --git a/docs/2_Architecture_Guides/1_Introduction/0_Overview.md b/docs/2_Architecture_Guides/1_Introduction/0_Overview.md
deleted file mode 100644
index 0648aa9..0000000
--- a/docs/2_Architecture_Guides/1_Introduction/0_Overview.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: Overview
----
-
-The AGL Unified Code Base (UCB) is a Linux distribution built from the ground up
-through a joint effort by automakers and suppliers to deliver a modern
-in-vehicle infotainment and connected car experience for consumers. Further
-helping reduce fragmentation and facilitate innovation in the development
-process. The following use cases are in development or planned to be developed :
-
- - In Vehicle Infotainment (IVI)
- - Instrument Cluster (IC)
- - Telematics
- - and more :
- - Heads-up Display (HUD)
- - Advanced Driver Assistance Systems (ADAS)
- - Autonomous Driving (AD)
-
-The goal of the UCB platform is to provide 70-80% of the starting
-point for a production project. This enables automakers and suppliers to focus
-their resources on customizing the other 20-30% to meet their unique product needs.
-
-The [System Architecture Team](https://wiki.automotivelinux.org/agl-sat) defines the overall architecture of the AGL
-software according to the business requirements established by the [Steering Committee](https://www.automotivelinux.org/about/steering-committee/).
-
-There are multiple parallel efforts in the areas of the following, with most having specialized [Expert Groups
-(EG)](https://wiki.automotivelinux.org/#active_expert_groups) :
-
- - [App Framework and Security](https://wiki.automotivelinux.org/eg-app-fw)
- - [Navigation](https://wiki.automotivelinux.org/eg-navi)
- - [Speech](https://wiki.automotivelinux.org/eg-speech)
- - [UI and Graphics](https://wiki.automotivelinux.org/eg-ui-graphics)
- - [Connectivity](https://wiki.automotivelinux.org/eg-connectivity)
- - [Continuous Integration and Test](https://wiki.automotivelinux.org/eg-ciat)
- - [Instrument Cluster](https://wiki.automotivelinux.org/eg-ic)
- - In Vehicle Infotainment (IVI)
- - [Reference Hardware System Architecture](https://wiki.automotivelinux.org/eg-rhsa)
- - Telematics
- - [Requirements Specification](https://wiki.automotivelinux.org/eg-requirements-specification)
- - [Vehicle to Cloud](https://wiki.automotivelinux.org/eg-v2c)
- - [Virtualization](https://wiki.automotivelinux.org/eg-virt)
-
-The Automotive Grade Linux Software Architecture diagram is below. The architecture consists
-of five layers. The App/HMI layer contains applications with their associated business logic and
-HMI.
-
-![Architecture Diagram](images/architecture.jpg)
-
-The Application Framework layer provides the APIs for creating both managing and running
-applications on an AGL system. The Services layer contains user space services that all
-applications can access. The Operating System (OS) layer provides the Linux kernel and device
-drivers along with standard OS utilities. For IVI (In Vehicle Infotainment)
-system a full fledged demo is [available](../../0_Getting_Started/1_Quickstart/Using_Ready_Made_Images.md). \ No newline at end of file
diff --git a/docs/2_Architecture_Guides/1_Introduction/1_AGL_Requirements_Specifications.md b/docs/2_Architecture_Guides/1_Introduction/1_AGL_Requirements_Specifications.md
deleted file mode 100644
index b15202a..0000000
--- a/docs/2_Architecture_Guides/1_Introduction/1_AGL_Requirements_Specifications.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: AGL Requirements Specifications
----
-
-<meta http-equiv="content-type" content="text/html; charset=utf-8" />
-<meta http-equiv="refresh" content="0;URL='https://www.automotivelinux.org/wp-content/uploads/sites/4/2017/08/agl_spec_v1_280515.pdf'" />
-
-[**AGL Requirements Specifications PDF**](AGL Requirements Specifications.pdf)
diff --git a/docs/2_Architecture_Guides/1_Introduction/AGL Requirements Specifications.pdf b/docs/2_Architecture_Guides/1_Introduction/AGL Requirements Specifications.pdf
deleted file mode 100644
index c5be950..0000000
--- a/docs/2_Architecture_Guides/1_Introduction/AGL Requirements Specifications.pdf
+++ /dev/null
Binary files differ
diff --git a/docs/2_Architecture_Guides/1_Introduction/images/architecture.jpg b/docs/2_Architecture_Guides/1_Introduction/images/architecture.jpg
deleted file mode 100644
index e83cbc4..0000000
--- a/docs/2_Architecture_Guides/1_Introduction/images/architecture.jpg
+++ /dev/null
Binary files differ
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/0_Overview.md b/docs/2_Architecture_Guides/2_Security_Blueprint/0_Overview.md
deleted file mode 100644
index ee5e7f7..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/0_Overview.md
+++ /dev/null
@@ -1,250 +0,0 @@
----
-title: Overview
----
-
-Modern cars have become a lot more technologically sophisticated and different
-than those of the past. We are seeing a wider range of new features and
-functionality, with a lot more complex software. It is fair to say that the cars
-being introduced to the market today have much more in common with computing
-devices like cell phones, than their predecessors did. Modern car manufacturers
-are also integrating support for a broad range of communication technologies for
-these “connected” cars. With the advent of such vehicles, Linux has become a
-natural choice for the software platform, with Automotive Grade Linux as a
-promising example.
-
-From a security point of view, the remote capabilities of a connected car
-results in a much larger attack surface. This opens a whole new world of
-security vulnerabilities that need to be considered during the architectural
-design. History shows that physical access to a device is sufficient for a
-hacker to gain root privileges. This makes the car a hostile environment.
-
-The Security Blueprint documents the security features that are included as part
-of Automotive Grade Linux (AGL) and identifies areas that need to be addressed
-from a security perspective as part of AGL. It also gives guidance around
-existing technologies and solutions.
-
-Security domains will allow us to create a set of tests verifying the security
-of Automotive Grade Linux.
-
-This document is firstly based on an existing AGL security-blueprint.
-
-**For security to be effective, the concepts must be simple. And by default,
-anything that is not allowed is forbidden.**
-
-We will cover topics starting from the lowest level (_Hardware_) up to the
-highest levels (_Connectivity_ and _Application_). We will move quickly on
-_Hardware_ and _Connectivity_ because this is not supported at our level.
-Solutions of connectivity problems concern updates and secured settings while
-hardware securing is related to the manufacturers.
-
-## Adversaries
-
-Adversaries and attackers within the Automotive space.
-
-- Enthusiast Attackers
-
-Enthusiast attackers have physical access to the Engine Control Units (ECUs) at
-the circuit board level. They can solder ‘mod chips’ onto the board and have
-access to probing tools. They also have information on ECUs that have been
-previously compromised and have access to softwares and instructions developed
-by other members of car modification forums. The goal of the enthusiast hacker
-could be, but is not limited to, adding extra horse power to the car or hacking
-it just for fun.
-
-- Corrupt Automotive Dealers
-
-Corrupt automotive dealers are attackers that have access to the same
-capabilities as enthusiasts, but also have access to the car manufacturer’s
-(OEM) dealer network. They may also have access to standard debugging tools
-provided by the car manufacturer. Their goal may be to support local car theft
-gangs or organized criminals.
-
-- Organized Criminals
-
-Organized criminals have access to all of the above tools but may also have some
-level of control over the internal network at many dealerships. They may have
-hacked and gained temporary control of the Over-The-Air (OTA) servers or the
-In-Vehicle Infotainment (IVI) systems. This is very much like the role of
-organized criminals in other industries such as paid media today. Their goal is
-to extort money from OEMs and/or governments by threatening to disable multiple
-vehicles.
-
-- Malware Developers
-
-Malware developers have developed malicious software to attack and compromise a
-large number of vehicles. The malicious software is usually designed to spread
-from one vehicle to another. Usually, the goal is to take control of multiple
-machines and then sell access to them for malicious purposes like
-denial-of-service (DoS) attacks or theft of private information and data.
-
-- Security Researchers
-
-Security researchers are ‘self-publicized’ security consultants trying to make a
-name for themselves. They have access to standard tools for software security
-analysis. They also have physical access to the vehicle and standard hardware
-debugging tools (Logic Analyzers, Oscilloscopes, etc). Their goal is to
-publicize attacks for personal gain or just to gain personal understanding with
-a sense of helping make things more secure.
-
-## Attack Goals
-
-In today’s connected vehicle, more and more functionality is moving to software
-control, meaning that the threat of attack becomes greater and greater. We see
-car features like navigation and summoning, car access/engine start, and
-motor/ECU upgrades all controlled through software and connections to the cloud.
-The risk of attack is high because there are high value targets in play.
-
-Here, we outline some of the major threats categories along with some sample
-attackers, example attacks, and a relative importance. These threat categories
-are intended to be general examples. There can be many nuances to threat types.
-Additionally, there can be many sub-attacks that eventually lead to these higher
-level attack goals.
-
-| Threat Category | Sample Attacker | Example Attacks | Relative Importance |
-|-------------------------------|-----------------------------------------|-------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------|
-| Vehicle theft | Individual, organized criminals | Send the car to an unplanned destination, get a key for the car, gain control of the unlock mechanism | Reduced likelihood of future vehicle purchases (Profit Later), bad press (Brand Integrity) |
-| Reduced vehicle functionality | Terrorist groups, disgruntled employees | Lock the driver out of the car, cause the car to crash, block access to infotainment system | Inability sell paid-for apps and content (Profit Now), bad press (Brand Integrity), possible loss of life (Physical Injury) |
-| Vehicle hacking | Vehicle owner, competitor | Get content without paying, modify DRM licenses, unlock of after-market features, theft of IP | Loss of sales for content and features (Profit Now), lawsuits from content owners (Profit Later), loss of competitive advantage (Profit Later) |
-| Sensitive asset theft | Organized criminals, blackmailers | Steal credit card numbers, health information, camera data, steal bandwidth | Bad press (Brand Integrity), lawsuits from vehicle owners (Profit Later) |
-
-The Automotive Grade Linux (AGL) initiative builds upon open-source software
-including Linux and Tizen to offer a flexible application framework. However,
-the security provisions of the app framework, Cynara, and the security manager
-only go so far in keeping the biggest threats at bay. As experience has shown,
-providing a constrained app (like that in the Android Open Source Platform) and
-store development flow, signature verification, DAC sandboxing, and MAC (SMACK)
-controls over the platform can have a certain amount of success with the
-security of the system. However, the openness of the system invites many
-researchers, hobbyists and hackers and financially motivated attackers to
-compromise the system for their own gains.
-
-As AGL arrives on modern automobiles, this is inevitably inviting many capable
-actors to modify, attack, and compromise these well thought-out systems and
-their applications. With concerns like safety and security, the auto industry
-cannot afford to go the way of consumer devices like phones and tablets where
-security problems are encountered on a frequent basis. It is imperative to use a
-layered approach and defense-in-depth to protect the system from inevitable
-attack.
-
-## Assets and Security Categorization
-
-This section outlines some of the assets that are likely to be found in the
-vehicle and their relative sensitivity from an attack point of view.
-Additionally, the final column on the right lists some of the recommended
-protection types that can be applied to these types of assets (Note that the
-empty cells refer to the cells above them). A good protection approach will give
-priority to the most sensitive assets, using a defense-in-depth approach to
-cover these assets. Less sensitive assets are treated at a lower priority,
-typically protected with fewer protection techniques. A more fine-grained
-prioritization of the the assets in a concrete vehicle network can be achieved
-with detailed threat analysis which considers the topology of the vehicle
-network and access-controls that are in-place. e.g. the EVITA framework for
-attack trees.
-
-| Asset Category | Examples | Sensitivity | Recommended Protection Types |
-|-------------------|--------------------------------------------------------------------------------|-------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Software | ECU software, infotainment software, OS images | Critical | Key Management, Mutual Asymmetric Authentication, HSM and WhiteBox Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms/ Obfuscation, Integrity Verification, Secure OS |
-| Car Access | Biometric data, car keys | | |
-| Payment Data | Credit cards, User profile critical data | | |
-| Recordings | Internal camera recording, internal audio recording, external camera recording | High | Encryption, Message Integrity Checks, Hardening/SW Protection, Program Transforms / Obfuscation |
-| User Profile | Usernames and passwords, customization, calendar, contacts | | |
-| Location | GPS coordinates, vehicle usage data | | |
-| Purchased Content | Video, audio, licenses | | |
-| Teleconference | Chat, audio, video | Medium | SW Protection, Program Transforms / Obfuscation, Authenticated encryption for transmission |
-| Vehicle data | Vehicle info, sensor data | | |
-| Navigation data | Static and dynamic maps | | |
-| 3rd party data | Home automation commands, cloud game data | | |
-
-## Hardening term
-
-The term Hardening refers to the tools, techniques and processes required in
-order to reduce the attack surface on an embedded system, such as an embedded
-control unit (**ECU**) or other managed devices. The target for all hardening
-activities is to prevent the execution of invalid binaries on the device, and to
-prevent copying of security related data from the device.
-
-## AGL security overview
-
-AGL roots are based on security concepts. Those concepts are implemented by the
-security framework as shown in this picture:
-
-![AGL architecture](images/WhiteBoxArchi.png)
-
---------------------------------------------------------------------------------
-
-# Acronyms and Abbreviations
-
-The following table lists the strongest terms utilized within all this document.
-
-| Acronyms or Abbreviations | Description |
-|---------------------------|-------------------------------------|
-| _AGL_ | **A**utomotive **G**rade **L**inux |
-| _ECU_ | **E**lectronic **C**ontrol **U**nit |
-
---------------------------------------------------------------------------------
-
-# References
-
-- [security-blueprint](http://docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html).
- - _http://
- docs.automotivelinux.org/docs/architecture/en/dev/reference/security/01-overview.html_
-- **[2017]** - [kernel
- security](https://www.kernel.org/doc/Documentation/security/).
- - _https:// www.kernel.org/doc/Documentation/security/_
-- **[2017]** - [Systemd integration and user
- management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf).
- - _http:// iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf_
-- **[2017]** - [AGL - Application Framework
- Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf).
- - _http:// iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf_
-- **[2017]** - [Improving Vehicle
- Cybersecurity](https://access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf).
- - _https://
- access.atis.org/apps/group_public/download.php/35648/ATIS-I-0000059.pdf_
-- **[2016]** - [AGL framework
- overview](http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html).
- - _http://
- docs.automotivelinux.org/docs/apis_services/en/dev/reference/af-main/0-introduction.html_
-- **[2016]** -
- [SecureBoot-SecureSoftwareUpdates](http://iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf).
- - _http://
- iot.bzh/download/public/2016/publications/SecureBoot-SecureSoftwareUpdates.pdf_
-- **[2016]** - [Linux Automotive
- Security](http://iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf).
- - _http://
- iot.bzh/download/public/2016/security/Linux-Automotive-Security-v10.pdf_
-- **[2016]** - [Automotive Security Best
- Practices](https://www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf).
- - _https://
- www.mcafee.com/it/resources/white-papers/wp-automotive-security.pdf_
-- **[2016]** - [Gattacking Bluetooth Smart
- Devices](http://gattack.io/whitepaper.pdf).
- - _http:// gattack.io/whitepaper.pdf_
-- **[2015]** - [Comprehensive Experimental Analysis of Automotive Attack
- Surfaces](http://www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf).
- - _http://
- www.cs.wayne.edu/fengwei/15fa-csc6991/slides/8-CarHackingUsenixSecurity.pdf_
-- **[2015]** - [Security in Automotive Bus
- Systems](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf).
- - _http://
- citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf_
-- **[2014]** - [IOActive Remote Attack
- Surface](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf).
- - _https:// www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf_
-- **[2011]** - [A practical attack against GPRS/EDGE/UMTS/HSPA mobile data
- communications](https://media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf).
- - _https://
- media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf_
-- **[2011]** - [Comprehensive Experimental Analyses of Automotive Attack
- Surfaces](http://www.autosec.org/pubs/cars-usenixsec2011.pdf).
- - _http:// www.autosec.org/pubs/cars-usenixsec2011.pdf_
-- **[2010]** - [Relay Attacks on Passive Keyless Entry and Start Systems in
- Modern Cars](https://eprint.iacr.org/2010/332.pdf).
- - _https:// eprint.iacr.org/2010/332.pdf_
-- **[2010]** - [Wifi attacks wep
- wpa](https://matthieu.io/dl/wifi-attacks-wep-wpa.pdf).
- - _https:// matthieu.io/dl/wifi-attacks-wep-wpa.pdf_
-- **[2008]** -
- [SMACK](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf).
- - _http://
- schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf_
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/1_Hardware.md b/docs/2_Architecture_Guides/2_Security_Blueprint/1_Hardware.md
deleted file mode 100644
index 328dd15..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/1_Hardware.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-title: Hardware
----
-
-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
-to alter the integrity of the boot. We should also prevent hardware
-modifications in order to achieve this goal. We will expose below some examples
-of possible configurations.
-
---------------------------------------------------------------------------------
-
-## Acronyms and Abbreviations
-
-The following table lists the terms utilized within this part of the document.
-
-Acronyms or Abbreviations | Description
-------------------------- | --------------------------------------
-_HSM_ | **H**ardware **S**ecurity **M**odule
-_NVM_ | **N**on-**V**olatile **M**emory
-_SHE_ | **S**ecure **H**ardware **E**xtensions
-
---------------------------------------------------------------------------------
-
-## Integrity
-
-The board must store hardcoded cryptographic keys in order to verify among
-others the _integrity_ of the _bootloader_. Manufacturers can use **HSM** and
-**SHE** to enhance the security of their board.
-
-Domain | Object | Recommendations
--------------------- | ---------- | ----------------------------------
-Hardware-Integrity-1 | Bootloader | Must control bootloader integrity.
-Hardware-Integrity-2 | Board | Must use a HSM.
-Hardware-Integrity-3 | RTC | Must not be alterable.
-
---------------------------------------------------------------------------------
-
-## Certificates
-
-Domain | Object | Recommendations
----------------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------
-Hardware-Certificate-1 | System | Shall allow storing dedicated certificates.
-Hardware-Certificate-2 | ECU | The ECU must verify the certification authority hierarchy.
-Hardware-Certificate-3 | System | Allow the modification of certificates only if the source can be authenticated by a certificate already stored or in the higher levels of the chain of trust.
-
---------------------------------------------------------------------------------
-
-## Memory
-
-Domain | Object | Recommendations
------------------ | ---------- | ------------------------------------------------------------------------------------
-Hardware-Memory-1 | ECU | The ECU shall never expose the unencrypted key in RAM when using cryptographic keys.
-Hardware-Memory-2 | Bootloader | Internal NVM only
-Hardware-Module-3 | - | HSM must be used to secure keys. \ No newline at end of file
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/2_Secure_Boot.md b/docs/2_Architecture_Guides/2_Security_Blueprint/2_Secure_Boot.md
deleted file mode 100644
index cdaa84c..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/2_Secure_Boot.md
+++ /dev/null
@@ -1,261 +0,0 @@
----
-title: Secure Boot
----
-
-Domain | Improvement
---------------- | ----------------------------------------------------
-Boot-Abstract-1 | More generic and add examples (The chain of trust).
-
-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.
-
-In this part, we will see a series of settings that will allow us to improve
-security during boot phase. For the purposes of reference and explanation, we
-are providing guidance on how to configure an embedded device that runs with a
-3.10.17 Linux kernel. If the integrity is not checked or if a critical error
-occurs, the system must boot on a very stable backup image.
-
-**Requirements**: These requirements must be met even if an alternative version
-of the Linux kernel is chosen.
-
-**Recommendations**: Detailed best practices that should be applied in order to
-secure a device. Although they are not currently listed as hard 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.
-
-Domain | Improvement
---------------- | -------------------------------------------
-Boot-Abstract-1 | Review the definition of the "boot loader".
-
-**Boot loader**: The boot loader consists of the Primary boot loader residing in
-**OTP** memory, sboot, U-Boot and Secure loader residing in external flash (NAND
-or SPI/NOR flash memory). The CPU on power on or reset executes the primary boot
-loader. The **OTP** primary boot loader makes the necessary initial system
-configuration and then loads the secondary boot loader sboot from external flash
-memory to ram memory. The sboot then loads the U-Boot along with the Secure
-loader. U-Boot then verifies the Kernel/system image integrity, then loads the
-Kernel/system image before passing control to it.
-
---------------------------------------------------------------------------------
-
-## Acronyms and Abbreviations
-
-The following table lists the terms utilized within this part of the document.
-
-Acronyms or Abbreviations | Description
-------------------------- | -----------------------------------------------------------------------
-_FUSE_ | **F**ilesystem in **U**ser**S**pac**E**
-_OTP_ | **O**ne-**T**ime-**P**rogrammable
-_DOCSIS_ | **D**ata **O**ver **C**able **S**ervice **I**nterface **S**pecification
-
-# Image
-
-## Image selection
-
-The boot process shall be uninterruptible and shall irrevocably boot the image
-as specified in the boot environment.
-
-In U-Boot set the "_bootdelay_" environment variable and/or define
-`CONFIG_BOOTDELAY` to _-2_.
-
-Domain | _Variable_ / `Config` name | `Value`
----------------------- | -------------------------- | -------
-Boot-Image-Selection-1 | `CONFIG_BOOTDELAY` | `-2`
-Boot-Image-Selection-2 | _bootdelay_ | `-2`
-
---------------------------------------------------------------------------------
-
-## Image authenticity
-
-It shall not be possible to boot from an unverified image. The secure boot
-feature in U-Boot shall be enabled. The secure boot feature is available from
-U-Boot 2013.07 version. To enable the secure boot feature, enable the following
-features:
-
-```sh
-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 verification.
-CONFIG_OF_CONTROL: Enables Flattened Device Tree (FDT) configuration.
-CONFIG_OF_SEPARATE: Enables separate build of u-Boot from the device tree.
-CONFIG_DEFAULT_DEVICE_TREE: Specifies the default Device Tree used for the run-time configuration of U-Boot.
-```
-
-Generate the U-Boot image with public keys to validate and load the image. It
-shall use RSA2048 and SHA256 for authentication.
-
-Domain | `Config` name | _State_
-------------------------- | ---------------------------- | --------
-Boot-Image-Authenticity-1 | `CONFIG_FIT` | _Enable_
-Boot-Image-Authenticity-2 | `CONFIG_FIT_SIGNATURE` | _Enable_
-Boot-Image-Authenticity-3 | `CONFIG_RSA` | _Enable_
-Boot-Image-Authenticity-4 | `CONFIG_OF_CONTROL` | _Enable_
-Boot-Image-Authenticity-5 | `CONFIG_OF_SEPARATE` | _Enable_
-Boot-Image-Authenticity-6 | `CONFIG_DEFAULT_DEVICE_TREE` | _Enable_
-
-# Communication modes
-
-## Disable USB, Serial and DOCSIS Support
-
-To disable USB support in U-Boot, following config's shall not be defined:
-
-```
-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.
-CONFIG_USB_STORAGE: Enables the USB storage devices.
-CONFIG_USB_HOST_ETHER: Enables USB Ethernet adapter support.
-```
-
-In addition, disable unnecessary communication modes like Ethernet, Serial
-ports, DOCSIS in U-Boot and sboot that are not necessary.
-
-Linux Kernel support for USB should be compiled-out if not required. If it is
-needed, the Linux Kernel should be configured to only enable the minimum
-required USB devices. User-initiated USB-filesystems should be treated with
-special care. Whether or not the filesystems are mounted in userspace
-(**FUSE**), restricted mount options should be observed.
-
-Domain | Communication modes | _State_
--------------------- | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------
-Boot-Communication-1 | `USB` | _Disabled_ and _Compiled-out_ if not required.
-Boot-Communication-2 | `USB` | Else, Kernel should be configured to only enable the minimum required USB devices and filesystems should be treated with special care.
-Boot-Communication-3 | `Ethernet` | _Disabled_
-Boot-Communication-4 | U-boot and sboot `DOCSIS` | _Disabled_
-Boot-Communication-5 | `Serial ports` | _Disabled_
-
-Domain | `Config` name | _State_
------------------------- | ----------------------- | -------------
-Boot-Communication-USB-1 | `CONFIG_CMD_USB` | _Not defined_
-Boot-Communication-USB-2 | `CONFIG_USB_UHCI` | _Not defined_
-Boot-Communication-USB-3 | `CONFIG_USB_KEYBOARD` | _Not defined_
-Boot-Communication-USB-4 | `CONFIG_USB_STORAGE` | _Not defined_
-Boot-Communication-USB-5 | `CONFIG_USB_HOST_ETHER` | _Not defined_
-
---------------------------------------------------------------------------------
-
-## Disable all unused Network Interfaces
-
-Only used network interfaces should be enabled. Where possible, services should
-also be limited to those necessary.
-
-Domain | Communication modes | _State_
--------------------- | -------------------- | ---------------------------------------------------------------------------------------------
-Boot-Communication-1 | `Network interfaces` | Preferably _no network interface is allowed_, otherwise, restrict the services to those used.
-
-## Remove or Disable Unnecessary Services, Ports, and Devices
-
-Restrict the `services`, `ports` and `devices` to those used.
-
-Domain | Object | Recommendations
--------------------- | --------------------------------- | -------------------------------------------------------------
-Boot-Communication-1 | `Services`, `ports` and `devices` | Restrict the `services`, `ports` and `devices` to those used.
-
-## Disable flash access
-
-**Recommendation**:
-
-In U-Boot following flash memory commands shall be disabled:
-
-**NAND**: Support for nand flash access available through `do_nand` has to be
-disabled.
-
-Domain | `Command` name | _State_
--------------------------- | -------------- | ---------
-Boot-Communication-Flash-1 | `do_nand` | _Disable_
-
-Similarly sboot should disable flash access support through command line if any.
-
-# Consoles
-
-## Disable serial console
-
-Serial console output shall be disabled. To disable console output in U-Boot,
-set the following macros:
-
-Domain | `Config` name | `Value`
----------------------- | --------------------------------------- | ---------
-Boot-Consoles-Serial-1 | `CONFIG_SILENT_CONSOLE` | `Disable`
-Boot-Consoles-Serial-2 | `CONFIG_SYS_DEVICE_NULLDEV` | `Disable`
-Boot-Consoles-Serial-3 | `CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC` | `Disable`
-
-Domain | Improvement
---------------- | ------------------------------------
-Boot-Consoles-1 | Secure loader: No reference earlier?
-
-And set "**silent**" environment variable. For the Secure loader, disable the
-traces by not defining the below macro:
-
-Domain | `Environment variable` name | _State_
----------------------- | --------------------------- | -------------
-Boot-Consoles-Serial-1 | `INC_DEBUG_PRINT` | _Not defined_
-
-For sboot proper configuration needs to be done to disable the serial console.
-
---------------------------------------------------------------------------------
-
-## Immutable environment variables
-
-In U-Boot, ensure Kernel command line, boot commands, boot delay and other
-environment variables are immutable. This will prevent side-loading of alternate
-images, by restricting the boot selection to only the image in FLASH.
-
-The environment variables shall be part of the text region in U-Boot as default
-environment variable and not in non-volatile memory.
-
-Remove configuration options related to non-volatile memory, such as:
-
-Domain | `Config` name | _State_
--------------------------- | ---------------------------- | ---------
-Boot-Consoles-Variables-1 | `CONFIG_ENV_IS_IN_MMC` | `#undef`
-Boot-Consoles-Variables-2 | `CONFIG_ENV_IS_IN_EEPROM` | `#undef`
-Boot-Consoles-Variables-3 | `CONFIG_ENV_IS_IN_FLASH` | `#undef`
-Boot-Consoles-Variables-4 | `CONFIG_ENV_IS_IN_DATAFLASH` | `#undef`
-Boot-Consoles-Variables-5 | `CONFIG_ENV_IS_IN_FAT` | `#undef`
-Boot-Consoles-Variables-6 | `CONFIG_ENV_IS_IN_NAND` | `#undef`
-Boot-Consoles-Variables-7 | `CONFIG_ENV_IS_IN_NVRAM` | `#undef`
-Boot-Consoles-Variables-8 | `CONFIG_ENV_IS_IN_ONENAND` | `#undef`
-Boot-Consoles-Variables-9 | `CONFIG_ENV_IS_IN_SPI_FLASH` | `#undef`
-Boot-Consoles-Variables-10 | `CONFIG_ENV_IS_IN_REMOTE` | `#undef`
-Boot-Consoles-Variables-11 | `CONFIG_ENV_IS_IN_UBI` | `#undef`
-Boot-Consoles-Variables-12 | `CONFIG_ENV_IS_NOWHERE` | `#define`
-
---------------------------------------------------------------------------------
-
-## (Recommendation) Removal of memory dump commands
-
-In U-Boot, following commands shall be disabled to avoid memory dumps:
-
-```
-md : Memory Display command.
-mm : Memory modify command - auto incrementing address.
-nm : Memory modify command - constant address.
-mw : Memory write.
-cp : Memory copy.
-mwc : Memory write cyclic.
-mdc : Memory display cyclic.
-mtest : Simple ram read/write test.
-loopw : Infinite write loop on address range.
-```
-
-Domain | `Command` name | _State_
------------------------ | -------------- | ----------
-Boot-Consoles-MemDump-1 | `md` | _Disabled_
-Boot-Consoles-MemDump-2 | `mm` | _Disabled_
-Boot-Consoles-MemDump-3 | `nm` | _Disabled_
-Boot-Consoles-MemDump-4 | `mw` | _Disabled_
-Boot-Consoles-MemDump-5 | `cp` | _Disabled_
-Boot-Consoles-MemDump-6 | `mwc` | _Disabled_
-Boot-Consoles-MemDump-7 | `mdc` | _Disabled_
-Boot-Consoles-MemDump-8 | `mtest` | _Disabled_
-Boot-Consoles-MemDump-9 | `loopw` | _Disabled_
-
-Similarly, memory dump support shall be disabled from sboot. \ No newline at end of file
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/3_Hypervisor.md b/docs/2_Architecture_Guides/2_Security_Blueprint/3_Hypervisor.md
deleted file mode 100644
index 61cc227..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/3_Hypervisor.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Hypervisor
----
-
-**Definition** : "A hypervisor or virtual machine monitor (VMM) is computer
-software, firmware or hardware that creates and runs virtual machines".
-
-It must include a signature verification (possibly delegated).
-
-Domain | Improvement
---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
-Hypervisor-Abstract-1 | Complete Hypervisor part ([jailhouse](https://github.com/siemens/jailhouse) / [KVM](https://www.linux-kvm.org/page/Main_Page) / [Xen](https://www.xenproject.org/developers/teams/embedded-and-automotive.html)).
-
-## Native or Bare-metal hypervisors
-
-These hypervisors run directly on the host's hardware to control the hardware
-and to manage guest operating systems. Those are the ones we're interested in. \ No newline at end of file
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/4_Kernel.md b/docs/2_Architecture_Guides/2_Security_Blueprint/4_Kernel.md
deleted file mode 100644
index 33e24d5..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/4_Kernel.md
+++ /dev/null
@@ -1,941 +0,0 @@
----
-title: Kernel
----
-
-**System Hardening:** Best practices associated with the configuration of an
-embedded Linux based operating system. This section includes both hardening of
-the kernel itself, as well as specific configurations and patches used to
-protect against known vulnerabilities within the build and configuration of the
-root filesystem.
-
-At the Kernel level, we must ensure that no console can be launched. It could be
-used to change the behavior of the system or to have more information about it.
-Another aspect is the protection of the memory used by the Kernel.
-
-The next sub-sections contain information on various kernel configuration
-options to enhance the security in the kernel (3.10.17) and also for
-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.
-
-# General configuration
-
-## Mandatory Access Control
-
-Kernel should controls access with labels and policy.
-
-Domain | `Config` name | `Value`
--------------------- | -------------- | --------------------------------------
-Kernel-General-MAC-1 | CONFIG_IP_NF_SECURITY | m
-Kernel-General-MAC-2 | CONFIG_IP6_NF_SECURITY | m
-Kernel-General-MAC-3 | CONFIG_EXT2_FS_SECURITY | y
-Kernel-General-MAC-4 | CONFIG_EXT3_FS_SECURITY | y
-Kernel-General-MAC-5 | CONFIG_EXT4_FS_SECURITY | y
-Kernel-General-MAC-6 | CONFIG_SECURITY | y
-Kernel-General-MAC-7 | CONFIG_SECURITY_SMACK | y
-Kernel-General-MAC-8 | CONFIG_TMPFS_XATTR | y
-
-Please also refer to the [Mandatory Access Control documentation in
-Platform](5_Platform.md). You can also find useful documentation and
-links on wikipedia about
-[**MAC**](https://en.wikipedia.org/wiki/Mandatory_access_control) and about
-[**SMACK**](https://en.wikipedia.org/wiki/Simplified_Mandatory_Access_Control_Kernel).
-
---------------------------------------------------------------------------------
-
-## Disable kexec
-
-**Kexec** is a system call that enables you to load and boot into another kernel
-from the currently running kernel. This feature is not required in a production
-environment.
-
-
-
-Domain | `Config` name | `Value`
----------------------- | -------------- | -------
-Kernel-General-kexec-1 | `CONFIG_KEXEC` | `n`
-
-
-
-
-
-**kexec** can load arbitrary kernels but signing of new kernel can be enforced
-like it is can be enforced for new modules.
-
---------------------------------------------------------------------------------
-
-## Disable kernel IP auto-configuration
-
-It is preferable to have an IP configuration performed using a user-space tool
-as these tend to have more validation. We do not want the network interface
-coming up until the system has come up properly.
-
-
-
-Domain | `Config` name | `Value`
---------------------------- | --------------- | -------
-Kernel-General-IPAutoConf-1 | `CONFIG_IP_PNP` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Disable Sysctl syscall support
-
-Enabling this will result in code being included that is hard to maintain and
-not well tested.
-
-
-
-Domain | `Config` name | `Value`
-------------------------------- | ----------------------- | -------
-Kernel-General-SysCtl_SysCall-1 | `CONFIG_SYSCTL_SYSCALL` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Disable Legacy Linux Support
-
-There are some Kernel Configs which are present only to support legacy binaries.
-See also "Consoles" part in order to disabling support for legacy binary
-formats. The `uselib` system call, in particular, has no valid use in any
-`libc6` or `uclibc` system in recent times. This configuration is supported in
-**Linux 3.15 and greater** and thus should only be disabled for such versions.
-
-
-
-Domain | `Config` name | `Value`
----------------------------- | --------------- | -------
-Kernel-General-LegacyLinux-1 | `CONFIG_USELIB` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Disable firmware auto-loading user mode helper
-
-The firmware auto loading helper, which is a utility executed by the kernel on
-`hotplug` events requiring firmware, can to be set `setuid`. As a result of
-this, the helper utility is an attractive target for attackers with control of
-physical ports on the device. Disabling this configuration that is supported in
-**Linux 3.9 and greater**.
-
-
-
-Domain | `Config` name | `Value`
---------------------------- | ------------------------------ | -------
-Kernel-General-FirmHelper-1 | `CONFIG_FW_LOADER_USER_HELPER` | `n`
-
-
-
-
-
-It doesn't strictly need to be `setuid`, there is an option of shipping firmware
-builtin into kernel without initrd/filesystem.
-
-
-
---------------------------------------------------------------------------------
-
-## Enable Kernel Panic on OOPS
-
-When fuzzing the kernel or attempting kernel exploits attackers are likely to
-trigger kernel OOPSes. Setting the behavior on OOPS to PANIC can impede their
-progress.
-
-This configuration is supported in **Linux 3.5 and greater** and thus should
-only be enabled for such versions.
-
-
-
-Domain | `Config` name | `Value`
----------------------------- | ---------------------- | -------
-Kernel-General-PanicOnOOPS-1 | `CONFIG_PANIC_ON_OOPS` | `y`
-
-
-
---------------------------------------------------------------------------------
-
-
-
-## Disable socket monitoring interface
-
-These monitors can be used to inspect shared file descriptors on Unix Domain
-sockets or traffic on 'localhost' which is otherwise assumed to be confidential.
-
-The `CONFIG_PACKET_DIAG` configuration is supported in **Linux 3.7 and greater**
-and thus should only be disabled for such versions.
-
-The `CONFIG_UNIX_DIAG` configuration is supported in **Linux 3.3 and greater**
-and thus should only be disabled for such versions.
-
-
-
-Domain | `Config` name | `Value`
--------------------------- | -------------------- | -------
-Kernel-General-SocketMon-1 | `CONFIG_PACKET_DIAG` | `n`
-Kernel-General-SocketMon-2 | `CONFIG_UNIX_DIAG` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Disable BPF JIT
-
-The BPF JIT can be used to create kernel-payloads from firewall table rules.
-
-This configuration for is supported in **Linux 3.16 and greater** and thus
-should only be disabled for such versions.
-
-
-
-Domain | `Config` name | `Value`
------------------------- | ---------------- | -------
-Kernel-General-BPF_JIT-1 | `CONFIG_BPF_JIT` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Enable Enforced Module Signing
-
-The kernel should never allow an unprivileged user the ability to load specific
-kernel modules, since that would provide a facility to unexpectedly extend the
-available attack surface.
-
-To protect against even privileged users, systems may need to either disable
-module loading entirely, or provide signed modules (e.g.
-`CONFIG_MODULE_SIG_FORCE`, or dm-crypt with LoadPin), to keep from having root
-load arbitrary kernel code via the module loader interface.
-
-This configuration is supported in **Linux 3.7 and greater** and thus should
-only be enabled for such versions.
-
-
-
-Domain | `Config` name | `Value`
------------------------------- | ------------------------- | -------
-Kernel-General-ModuleSigning-1 | `CONFIG_MODULE_SIG_FORCE` | `y`
-
-
-
-It is also possible to block the loading of modules after startup with
-"kernel.modules_disabled".
-
-
-
-Domain | `Variable` name | `Value`
------------------------------- | ------------------------- | -------
-Kernel-General-ModuleSigning-2 | `kernel.modules_disabled` | `1`
-
-
-
---------------------------------------------------------------------------------
-
-
-
-## Disable all USB, PCMCIA (and other `hotplug` bus) drivers that aren't needed
-
-To reduce the attack surface, the driver enumeration, probe, and operation
-happen in the kernel. The driver data is parsed by the kernel, so any logic bugs
-in these drivers can become kernel exploits.
-
-
-
-Domain | Object | _State_
------------------------- | ------------------- | ----------
-Kernel-General-Drivers-1 | `USB` | _Disabled_
-Kernel-General-Drivers-2 | `PCMCIA` | _Disabled_
-Kernel-General-Drivers-3 | Other `hotplug` bus | _Disabled_
-
-
-
---------------------------------------------------------------------------------
-
-## Position Independent Executables
-
-
-
-Domain | Improvement
--------------------------------- | -----------------------------
-Kernel-General-IndependentExec-1 | Kernel or/and platform part ?
-
-
-
-
-
-Domain | `compiler` and `linker` options | _State_
--------------------------------- | ------------------------------- | --------
-Kernel-General-IndependentExec-1 | `-pie -fpic` | _Enable_
-
-
-
-Produce a position independent executable on targets which supports it.
-
---------------------------------------------------------------------------------
-
-## Prevent Overwrite Attacks
-
-`-z,relro` 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.
-
-
-
-Domain | `compiler` and `linker` options | _State_
---------------------------------- | ------------------------------- | --------
-Kernel-General-OverwriteAttacks-1 | `-z,relro` | _Enable_
-Kernel-General-OverwriteAttacks-2 | `-z,now` | _Enable_
-
-
-
-During program load, all dynamic symbols are resolved, allowing for the complete
-GOT to be marked read-only (due to `-z relro` above). This prevents GOT
-overwrite attacks. For very large application, this can incur some performance
-loss during initial load while symbols are resolved, but this shouldn't be an
-issue for daemons.
-
---------------------------------------------------------------------------------
-
-
-
-## Library linking
-
-
-
-Domain | Improvement
-------------------------------- | ---------------
-Kernel-General-LibraryLinking-1 | Keep this part?
-
-
-
-It is recommended that dynamic linking should generally not be allowed. This
-will avoid the user from replacing a library with malicious library.
-
-
-
-Domain | Object | Recommendations
-------------------------------- | --------------- | --------------------------------
-Kernel-General-LibraryLinking-1 | Dynamic linking | Should generally not be allowed.
-
-Linking everything statically doesn't change anything wrt security as binaries
-will live under same user:group as libraries and setuid executables ignore
-`LD_PRELOAD/LD_LIBRARY_PATH`. It also increases RSS footprint and creates
-problems with upgrading.
-
-# Memory
-
-## Restrict access to kernel memory
-
-The /dev/kmem file in Linux systems is directly mapped to kernel virtual memory.
-This can be disastrous if an attacker gains root access, as the attacker would
-have direct access to kernel virtual memory.
-
-To disable the /dev/kmem file, which is very infrequently used by applications,
-the following kernel option should be set in the compile-time kernel
-configuration:
-
-Domain | `Config` name | `Value`
------------------------------- | ---------------- | -------
-Kernel-Memory-RestrictAccess-1 | `CONFIG_DEVKMEM` | `n`
-
-In case applications in userspace need /dev/kmem support, it should be available
-only for authenticated applications.
-
---------------------------------------------------------------------------------
-
-## Disable access to a kernel core dump
-
-This kernel configuration disables access to a kernel core dump from user space.
-If enabled, it gives attackers a useful view into kernel memory.
-
-
-
-Domain | `Config` name | `Value`
------------------------- | ------------------- | -------
-Kernel-Memory-CoreDump-1 | `CONFIG_PROC_KCORE` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Disable swap
-
-If not disabled, attackers can enable swap at runtime, add pressure to the
-memory subsystem and then scour the pages written to swap for useful
-information.
-
-
-
-Domain | `Config` name | `Value`
--------------------- | ------------- | -------
-Kernel-Memory-Swap-1 | `CONFIG_SWAP` | `n`
-
-
-
-
-
-- Enabling swap at runtime require `CAP_SYS_ADMIN`.
-- Swap block device is usually under root:disk.
-- Linux never swaps kernel pages.
-- If swap disabling is not possible, swap encryption should be enabled.
-
-
-
---------------------------------------------------------------------------------
-
-
-
-## Disable "Load All Symbols"
-
-There is a /proc/kallsyms file which exposes the kernel memory space address of
-many kernel symbols (functions, variables, etc...). This information is useful
-to attackers in identifying kernel versions/configurations and in preparing
-payloads for the exploits of kernel space.
-
-Both `KALLSYMS_ALL` and `KALLSYMS` shall be disabled;
-
-
-
-Domain | `Config` name | `Value`
------------------------------- | --------------------- | -------
-Kernel-Memory-LoadAllSymbols-1 | `CONFIG_KALLSYMS` | `n`
-Kernel-Memory-LoadAllSymbols-2 | `CONFIG_KALLSYMS_ALL` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Stack protection
-
-To prevent stack-smashing, similar to the stack protector used for ELF programs
-in user-space, the kernel can protect its internal stacks as well.
-
-This configuration is supported in **Linux 3.11 and greater** and thus should
-only be enabled for such versions.
-
-This configuration also requires building the kernel with the **gcc compiler 4.2
-or greater**.
-
-
-
-Domain | `Config` name | `Value`
---------------------- | -------------------------- | -------
-Kernel-Memory-Stack-1 | `CONFIG_CC_STACKPROTECTOR` | `y`
-
-
-
-Other defenses include things like shadow stacks.
-
---------------------------------------------------------------------------------
-
-## Disable access to /dev/mem
-
-The /dev/mem file in Linux systems is directly mapped to physical memory. This
-can be disastrous if an attacker gains root access, as the attacker would have
-direct access to physical memory through this convenient device file. It may not
-always be possible to disable such file, as some applications might need such
-support. In that case, then this device file should be available only for
-authenticated applications.
-
-This configuration is supported in **Linux 4.0 and greater** and thus should
-only be disabled for such versions.
-
-
-
-Domain | `Config` name | `Value`
----------------------- | --------------- | -------
-Kernel-Memory-Access-1 | `CONFIG_DEVMEM` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-
-
-## Disable cross-memory attach
-
-Disable the process_vm_*v syscalls which allow one process to peek/poke the
-virtual memory of another.
-
-This configuration is supported in **Linux 3.5 and greater** and thus should
-only be disabled for such versions.
-
-
-
-Domain | `Config` name | `Value`
------------------------------- | --------------------- | -------
-Kernel-Memory-CrossMemAttach-1 | `CROSS_MEMORY_ATTACH` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Stack Smashing Attacks
-
-
-
-Domain | `compiler` and `linker` options | _State_
------------------------------ | ------------------------------- | --------
-Kernel-Memory-StackSmashing-1 | `-fstack-protector-all` | _Enable_
-
-
-
-Emit extra code to check for buffer overflows, such as stack smashing attacks.
-
---------------------------------------------------------------------------------
-
-## Detect Buffer Overflows
-
-Domain | `compiler` options and `config` name | `Value`
-------------------------------- | ------------------------------------ | -------
-Kernel-Memory-BufferOverflows-1 | `-D_FORTIFY_SOURCE` | `2`
-Kernel-Memory-BufferOverflows-2 | `CONFIG_FORTIFY_SOURCE` | `y`
-
-Helps detect some buffer overflow errors.
-
-# Serial
-
-## Disable serial console
-
-The serial console should be disabled to prevent an attacker from accessing this
-powerful interface.
-
-Domain | `Config` name | `Value`
------------------------- | ---------------------------- | -------
-Kernel-Consoles-Serial-1 | `CONFIG_SERIAL_8250` | `n`
-Kernel-Consoles-Serial-2 | `CONFIG_SERIAL_8250_CONSOLE` | `n`
-Kernel-Consoles-Serial-3 | `CONFIG_SERIAL_CORE` | `n`
-Kernel-Consoles-Serial-4 | `CONFIG_SERIAL_CORE_CONSOLE` | `n`
-
---------------------------------------------------------------------------------
-
-## Bake-in the kernel command-line
-
-The kernel command-line is used to control many aspects of the booting kernel,
-and is prone to tampering as they are passed in RAM with little to no reverse
-validation on these parameters. To prevent this type of attack, the kernel shall
-be configured to ignore commands line arguments, and use pre-configured (compile
-time) options instead.
-
-Set the kernel command line in the `CONFIG_CMDLINE KConfig` item and then pass
-no arguments from the bootloader.
-
-
-
-Domain | `Config` name | `Value`
------------------------------ | ------------------------- | -----------------------------------
-Kernel-Consoles-CommandLine-1 | `CONFIG_CMDLINE_BOOL` | `y`
-Kernel-Consoles-CommandLine-2 | `CONFIG_CMDLINE` | `"insert kernel command line here"`
-Kernel-Consoles-CommandLine-3 | `CONFIG_CMDLINE_OVERRIDE` | `y`
-
-
-
-It is recommended that any per-device settings (e.g: MAC addresses, serial
-numbers, etc.) be stored and accessed from read-only memory (or files), and that
-any such parameters be verified (signature checking) prior to their use.
-
---------------------------------------------------------------------------------
-
-## Disable KGDB
-
-The Linux kernel supports KGDB over USB and console ports. These mechanisms are
-controlled by the `kgdbdbgp` and `kgdboc` kernel command-line parameters. It is
-important to ensure that no shipping product contains a kernel with KGDB
-compiled-in.
-
-
-
-Domain | `Config` name | `Value`
----------------------- | ------------- | -------
-Kernel-Consoles-KDBG-1 | `CONFIG_KGDB` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Disable magic sysrq support
-
-On a few architectures, you can access a powerful debugger interface from the
-keyboard. The same powerful interface can be present on the serial console
-(responding to serial break) of Linux on other architectures. Disable to avoid
-potentially exposing this powerful backdoor.
-
-
-
-Domain | `Config` name | `Value`
------------------------ | -------------------- | -------
-Kernel-Consoles-SysRQ-1 | `CONFIG_MAGIC_SYSRQ` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Disable support for binary formats other than ELF
-
-This will make possible to plug wrapper-driven binary formats into the kernel.
-It enables support for binary formats other than ELF. Providing the ability to
-use alternate interpreters would assist an attacker in discovering attack
-vectors.
-
-
-
-Domain | `Config` name | `Value`
------------------------------- | -------------------- | -------
-Kernel-Consoles-BinaryFormat-1 | `CONFIG_BINFMT_MISC` | `n`
-
-# Debug
-
-No debuggers shall be present on the file system. This includes, but is not
-limited to, the GNU Debugger client/server (commonly known in their short form
-names such as the `gdb` and `gdbserver` executable binaries respectively), the
-`LLDB` next generation debugger or the `TCF` (Target Communications Framework)
-agnostic framework. Including these binaries as part of the file system will
-facilitate an attacker's ability to reverse engineer and debug (either locally
-or remotely) any process that is currently executing on the device.
-
-## Kernel debug symbols
-
-Debug symbols should always be removed from production kernels as they provide a
-lot of information to attackers.
-
-
-
-Domain | `Config` name | `Value`
----------------------- | ------------------- | -------
-Kernel-Debug-Symbols-1 | `CONFIG_DEBUG_INFO` | `n`
-
-
-
-These kernel debug symbols are enabled by other config items in the kernel. Care
-should be taken to disable those also. If `CONFIG_DEBUG_INFO` cannot be
-disabled, then enabling `CONFIG_DEBUG_INFO_REDUCED` is second best.
-
-
-
-At least `CONFIG_DEBUG_INFO_REDUCED` should be always enabled for developers to
-convert addresses in oops messages to line numbers.
-
-
-
---------------------------------------------------------------------------------
-
-## Disable Kprobes
-
-Kprobes enables you to dynamically break into any kernel routine and collect
-debugging and performance information non-disruptively. You can trap at almost
-any kernel code address, specifying a handler routine to be invoked when the
-breakpoint is hit.
-
-
-
-Domain | `Config` name | `Value`
----------------------- | ---------------- | -------
-Kernel-Debug-Kprobes-1 | `CONFIG_KPROBES` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Disable Tracing
-
-FTrace enables the kernel to trace every kernel function. Providing kernel trace
-functionality would assist an attacker in discovering attack vectors.
-
-
-
-Domain | `Config` name | `Value`
----------------------- | --------------- | -------
-Kernel-Debug-Tracing-1 | `CONFIG_FTRACE` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Disable Profiling
-
-Profiling and OProfile enables profiling the whole system, include the kernel,
-kernel modules, libraries, and applications. Providing profiling functionality
-would assist an attacker in discovering attack vectors.
-
-
-
-Domain | `Config` name | `Value`
------------------------- | ------------------ | -------
-Kernel-Debug-Profiling-1 | `CONFIG_OPROFILE` | `n`
-Kernel-Debug-Profiling-2 | `CONFIG_PROFILING` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Disable OOPS print on BUG()
-
-The output from OOPS print can be helpful in Return Oriented Programming (ROP)
-when trying to determine the effectiveness of an exploit.
-
-
-
-Domain | `Config` name | `Value`
------------------------- | ------------------------- | -------
-Kernel-Debug-OOPSOnBUG-1 | `CONFIG_DEBUG_BUGVERBOSE` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Disable Kernel Debugging
-
-There are development-only branches of code in the kernel enabled by the
-`DEBUG_KERNEL` conf. This should be disabled to compile-out these branches.
-
-
-
-Domain | `Config` name | `Value`
------------------- | --------------------- | -------
-Kernel-Debug-Dev-1 | `CONFIG_DEBUG_KERNEL` | `n`
-Kernel-Debug-Dev-2 | `CONFIG_EMBEDDED` | `n`
-
-
-
-In some kernel versions, disabling this requires also disabling
-`CONFIG_EMBEDDED`, and `CONFIG_EXPERT`. Disabling `CONFIG_EXPERT` makes it
-impossible to disable `COREDUMP`, `DEBUG_BUGVERBOSE`, `NAMESPACES`, `KALLSYMS`
-and `BUG`. In which case it is better to leave this enabled than enable the
-others.
-
---------------------------------------------------------------------------------
-
-
-
-## Disable the kernel debug filesystem
-
-The kernel debug filesystem presents a lot of useful information and means of
-manipulation of the kernel to an attacker.
-
-
-
-Domain | `Config` name | `Value`
-------------------------- | ----------------- | -------
-Kernel-Debug-FileSystem-1 | `CONFIG_DEBUG_FS` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Disable BUG() support
-
-The kernel will display backtrace and register information for BUGs and WARNs in
-kernel space, making it easier for attackers to develop exploits.
-
-
-
-Domain | `Config` name | `Value`
------------------- | ------------- | -------
-Kernel-Debug-BUG-1 | `CONFIG_BUG` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-## Disable core dumps
-
-Core dumps provide a lot of debug information for hackers. So disabling core
-dumps are recommended in production builds.
-
-This configuration is supported in **Linux 3.7 and greater** and thus should
-only be disabled for such versions.
-
-
-
-Domain | `Config` name | `Value`
------------------------- | ----------------- | -------
-Kernel-Debug-CoreDumps-1 | `CONFIG_COREDUMP` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-
-
-## Kernel Address Display Restriction
-
-When attackers try to develop "run anywhere" exploits for kernel
-vulnerabilities, they frequently need to know the location of internal kernel
-structures. By treating kernel addresses as sensitive information, those
-locations are not visible to regular local users.
-
-**/proc/sys/kernel/kptr_restrict is set to "1"** to block the reporting of known
-kernel address leaks.
-
-
-
-Domain | `File` name | `Value`
----------------------------- | -------------------------------- | -------
-Kernel-Debug-AdressDisplay-1 | `/proc/sys/kernel/kptr_restrict` | `1`
-
-
-
-Additionally, various files and directories should be readable only by the root
-user: `/boot/vmlinuz*`, `/boot/System.map*`, `/sys/kernel/debug/`,
-`/proc/slabinfo`
-
-
-
-Domain | `File` or `Directorie` name | _State_
----------------------------- | --------------------------- | -----------------------------
-Kernel-Debug-AdressDisplay-1 | `/boot/vmlinuz*` | _Readable Only for root user_
-Kernel-Debug-AdressDisplay-2 | `/boot/System.map*` | _Readable Only for root user_
-Kernel-Debug-AdressDisplay-3 | `/sys/kernel/debug/` | _Readable Only for root user_
-Kernel-Debug-AdressDisplay-4 | `/proc/slabinfo` | _Readable Only for root user_
-
-
-
---------------------------------------------------------------------------------
-
-## DMESG Restrictions
-
-When attackers try to develop "run anywhere" exploits for vulnerabilities, they
-frequently will use `dmesg` output. By treating `dmesg` output as sensitive
-information, this output is not available to the attacker.
-
-**/proc/sys/kernel/dmesg_restrict can be set to "1"** to treat dmesg output as
-sensitive.
-
-
-
-Domain | `File` name | `Value`
--------------------- | --------------------------------- | -------
-Kernel-Debug-DMESG-1 | `/proc/sys/kernel/dmesg_restrict` | `1`
-
-
-
-Enable the below compiler and linker options when building user-space
-applications to avoid stack smashing, buffer overflow attacks.
-
---------------------------------------------------------------------------------
-
-
-
-## Disable /proc/config.gz
-
-It is extremely important to not expose the kernel configuration used on a
-production device to a potential attacker. With access to the kernel config, it
-could be possible for an attacker to build a custom kernel for the device that
-may disable critical security features.
-
-
-
-Domain | `Config` name | `Value`
---------------------- | ----------------- | -------
-Kernel-Debug-Config-1 | `CONFIG_IKCONFIG` | `n`
-
-# File System
-
-## Disable all file systems not needed
-
-To reduce the attack surface, file system data is parsed by the kernel, so any
-logic bugs in file system drivers can become kernel exploits.
-
-### Disable NFS file system
-
-NFS FileSystems are useful during development phases, but this can be a very
-helpful way for an attacker to get files when you are in production mode, so we
-must disable them.
-
-
-
-Domain | `Config` name | `Value`
------------------------- | --------------- | -------
-Kernel-FileSystems-NFS-1 | `CONFIG_NFSD` | `n`
-Kernel-FileSystems-NFS-2 | `CONFIG_NFS_FS` | `n`
-
-
-
---------------------------------------------------------------------------------
-
-
-
-## Partition Mount Options
-
-There are several security restrictions that can be set on a filesystem when it
-is mounted. Some common security options include, but are not limited to:
-
-`nosuid` - Do not allow set-user-identifier or set-group-identifier bits to take
-effect.
-
-`nodev` - Do not interpret character or block special devices on the filesystem.
-
-`noexec` - Do not allow execution of any binaries on the mounted filesystem.
-
-`ro` - Mount filesystem as read-only.
-
-The following flags shall be used for mounting common filesystems:
-
-
-
-Domain | `Partition` | `Value`
--------------------------- | ------------------- | -----------------------------------------------------------------
-Kernel-FileSystems-Mount-1 | `/boot` | `nosuid`, `nodev` and `noexec`.
-Kernel-FileSystems-Mount-2 | `/var` & `/tmp` | In `/etc/fstab` or `vfstab`, add `nosuid`, `nodev` and `noexec`.
-Kernel-FileSystems-Mount-3 | _Non-root local_ | If type is `ext2` or `ext3` and mount point not '/', add `nodev`.
-Kernel-FileSystems-Mount-4 | _Removable storage_ | Add `nosuid`, `nodev` and `noexec`.
-Kernel-FileSystems-Mount-5 | _Temporary storage_ | Add `nosuid`, `nodev` and `noexec`.
-Kernel-FileSystems-Mount-6 | `/dev/shm` | Add `nosuid`, `nodev` and `noexec`.
-Kernel-FileSystems-Mount-7 | `/dev` | Add `nosuid` and `noexec`.
-
-
-
-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.
-
-
-
-Domain | `Config` name | _State_ or `Value`
--------------------------- | ----------------------- | -----------------------------------------------------------------------
-Kernel-FileSystems-Mount-1 | `CONFIG_DEVTMPFS_MOUNT` | _Disabled_ or add remount with `noexec` and `nosuid` to system startup. \ No newline at end of file
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/5_Platform.md b/docs/2_Architecture_Guides/2_Security_Blueprint/5_Platform.md
deleted file mode 100644
index 2112fdc..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/5_Platform.md
+++ /dev/null
@@ -1,921 +0,0 @@
----
-title: Platform
----
-
-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).
-
-
-
-Domain | Improvement
-------------------- | --------------------------------
-Platform-Abstract-1 | Create a graphics and sound part.
-
-
-
-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
-of all, security management must remain simple. You must also prohibit
-everything by default, and then define a set of authorization rules. As cases to
-deal with, we must:
-
-- Implement a **MAC** for processes and files.
-- Limit communication between applications (_SystemBus_ and _SystemD_ part).
-- Prohibit all tools used during development mode (_Utilities_ and _Services_
- part).
-- Manage user capabilities (_Users_ part).
-- Manage application permissions and policies (_AGLFw_ part).
-
-
-
-The tools and concepts used to meet these needs are only examples. Any other
-tool that meets the need can be used.
-
-
-
-In AGL, as in many other embedded systems, different security mechanisms settle
-in the core layers to ensure isolation and data privacy. While the Mandatory
-Access Control layer (**SMACK**) provides global security and isolation, other
-mechanisms like **Cynara** are required to check application's permissions at
-runtime. Applicative permissions (also called "_privileges_") may vary depending
-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.
-
---------------------------------------------------------------------------------
-
-
-
-## Acronyms and Abbreviations
-
-The following table lists the terms utilized within this part of the document.
-
-Acronyms or Abbreviations | Description
-------------------------- | --------------------------------------------------------------
-_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
-_DOS_ | **D**enial **O**f **S**ervice
-_IPC_ | **I**nter-**P**rocess **C**ommunication
-_MAC_ | **M**andatory **A**ccess **C**ontrol
-_PAM_ | **P**luggable **A**uthentication **M**odules
-_SMACK_ | **S**implified **M**andatory **A**ccess **C**ontrol **K**ernel
-
-# Mandatory Access Control
-
-
-
-We decided to put the **MAC** protection on the platform part despite the fact
-that it applies to the kernel too, since its use will be mainly at the platform
-level (except floor part).
-
-
-
-**M**andatory **A**ccess **C**ontrol (**MAC**) is a protection provided by the
-Linux kernel that requires a **L**inux **S**ecurity **M**odule (**LSM**). AGL
-uses an **LSM** called **S**implified **M**andatory **A**ccess **C**ontrol
-**K**ernel (**SMACK**). This protection involves the creation of **SMACK**
-labels as part of the extended attributes **SMACK** labels to the file extended
-attributes. And a policy is also created to define the behaviour of each label.
-
-The kernel access controls is based on these labels and this policy. If there is
-no rule, no access will be granted and as a consequence, what is not explicitly
-authorized is forbidden.
-
-There are two types of **SMACK** labels:
-
-- **Execution SMACK** (Attached to the process): Defines how files are
- _accessed_ and _created_ by that process.
-- **File Access SMACK** (Written to the extended attribute of the file): Defines
- _which_ process can access 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.
-- System.
-- Applications, Services and User.
-
-See [AGL security framework
-review](http://iot.bzh/download/public/2017/AMMQ1Tokyo/AGL-security-framework-review.pdf)
-and [Smack White
-Paper](http://schaufler-ca.com/yahoo_site_admin/assets/docs/SmackWhitePaper.257153003.pdf)
-for more information.
-
---------------------------------------------------------------------------------
-
-
-
-## 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 during software installation
-or upgrade.
-
-The following table details the _floor_ domain:
-
-Label | Name | Execution **SMACK** | File Access **SMACK**
------ | ----- | ------------------- | ---------------------------------------
-`-` | Floor | `r-x` for all | Only kernel and internal kernel thread.
-`^` | Hat | `---` for all | `rx` on all domains.
-`*` | Star | `rwx` for all | None
-
-
-
-- The Hat label is 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.
-
-- The Star label is used for device files or `/tmp` Access restriction managed
- via **DAC**. Individual files remain protected by their **SMACK** label.
-
-
-
-Domain | `Label` name | Recommendations
------------------- | ------------ | -----------------------------------------------------------
-Kernel-MAC-Floor-1 | `^` | Only for privileged system services.
-Kernel-MAC-Floor-2 | `*` | Used for device files or `/tmp` Access restriction via DAC.
-
-
-
---------------------------------------------------------------------------------
-
-
-
-## 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 | Execution **SMACK** | File Access **SMACK**
----------------- | --------- | ----------------------------------------------- | ---------------------
-`System` | System | None | Privileged processes
-`System::Run` | Run | `rwxatl` for User and System label | None
-`System::Shared` | Shared | `rwxatl` for system domain `r-x` for User label | None
-`System::Log` | Log | `rwa` for System label `xa` for user label | None
-`System::Sub` | SubSystem | Subsystem Config files | SubSystem only
-
-
-
-Domain | `Label` name | Recommendations
-------------------- | ---------------- | -------------------------------------------------------------------------------------------------------------
-Kernel-MAC-System-1 | `System` | Process should write only to file with transmute attribute.
-Kernel-MAC-System-2 | `System::run` | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`.
-Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege.
-Kernel-MAC-System-4 | `System::Log` | Some limitation may impose to add `w` to enable append.
-Kernel-MAC-System-5 | `System::Sub` | 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 on this domain is under _Cynara_ control.
-
-The following table details the _application_, _services_ and _user_ domain:
-
-Label | Name | Execution **SMACK** | File Access **SMACK**
-------------------- | ------ | --------------------------------------------------------------------------- | ---------------------------
-`User::Pkg::$AppID` | AppID | `rwx` (for files created by the App). `rx` for files installed by **AppFw** | $App runtime executing $App
-`User::Home` | Home | `rwx-t` from System label `r-x-l` from App | None
-`User::App-Shared` | Shared | `rwxat` from System and User domains label of $User | None
-
-
-
-Domain | `Label` name | Recommendations
-------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------
-Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode.
-Kernel-MAC-System-2 | `User::Home` | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute.
-Kernel-MAC-System-3 | `User::App-Shared` | Shared space between all App running for a given user.
-
-
-
-## 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).
-
-# SystemD
-
-`afm-system-daemon` is used to:
-
-- Manage users and user sessions.
-- Setup applications and services (_CGroups_, _namespaces_, autostart,
- permissions).
-- Use of `libsystemd` for its programs (event management, **D-Bus** interface).
-
-
-
-Domain | Object | Recommendations
------------------- | -------------- | ------------------------------------
-Platform-SystemD-1 | Security model | Use Namespaces for containerization.
-Platform-SystemD-2 | Security model | Use CGroups to organise processes.
-
-
-
-See [systemd integration and user
-management](http://iot.bzh/download/public/2017/AMM-Dresden/AGL-systemd.pdf) for
-more information.
-
-## Benefits
-
-- Removal of one privileged process: **afm-user-daemon**
-- Access and use of high level features:
-
- - Socket activation.
- - Management of users and integration of **PAM**.
- - Dependency resolution to services.
- - `Cgroups` and resource control.
- - `Namespaces` containerization.
- - Autostart of required API.
- - Permissions and security settings.
- - Network management.
-
-
-
-## CGroups
-
-Control Groups offer a lot of features, with the most useful ones you can
-control: Memory usage, how much CPU time is allocated, how much device I/O is
-allowed or which devices can be accessed. **SystemD** uses _CGroups_ to organise
-processes (each service is a _CGroups_, and all processes started by that
-service use that _CGroups_). By default, **SystemD** automatically creates a
-hierarchy of slice, scope and service units to provide a unified structure for
-the _CGroups_ tree. With the `systemctl` command, you can further modify this
-structure by creating custom slices. Currently, in AGL, there are 2 slices
-(**user.slice** and **system.slice**).
-
-## Namespaces
-
-### User side
-
-There are several ways of authenticating users (Key Radio Frequency, Phone,
-Gesture, ...). Each authentication provides dynamic allocation of **uids** to
-authenticated users. **Uids** is used to ensure privacy of users and **SMACK**
-for applications privacy.
-
-First, the user initiates authentication with **PAM** activation. **PAM**
-Standard offers highly configurable authentication with modular design like face
-recognition, Voice identification or with a password. Then users should access
-identity services with services and applications.
-
-# D-Bus
-
-D-Bus is a well-known **IPC** (Inter-Process Communication) protocol (and
-daemon) that helps applications to talk to each other. The use of D-Bus is great
-because it allows to implement discovery and signaling.
-
-The D-Bus session is by default addressed by environment variable
-`DBUS_SESSION_BUS_ADDRESS`. Using **systemd** variable
-`DBUS_SESSION_BUS_ADDRESS` is automatically set for user sessions. D-Bus usage
-is linked to permissions.
-
-D-Bus has already had several [security
-issues](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html)
-(mostly **DoS** issues), to allow applications to keep talking to each other. It
-is important to protect against this type of attack to keep the system more
-stable.
-
-
-
-
-Domain | Object | Recommendations
---------------- | -------------- | ------------------------------------
-Platform-DBus-1 | Security model | Use D-Bus as IPC.
-Platform-DBus-2 | Security model | Apply D-BUS security patches: [D-Bus CVE](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html)
-
-
-
-# System services and daemons
-
-
-
-Domain | Improvement
-------------------- | -----------
-Platform-Services-1 | SystemD ?
-Platform-Services-2 | Secure daemon ?
-
-
-
-## Tools
-
-- **connman**: An internet connection manager designed to be slim and to use as
- few resources as possible. It is a fully modular system that can be extended,
- through plug-ins, to support all kinds of wired or wireless technologies.
-- **bluez** is a Bluetooth stack. Its goal is to program an implementation of
- the Bluetooth wireless standards specifications. In addition to the basic
- stack, the `bluez-utils` and `bluez-firmware` packages contain low level
- utilities such as `dfutool` which can interrogate the Bluetooth adapter
- chipset in order to determine whether its firmware can be upgraded.
-- **gstreamer** is a pipeline-based multimedia framework. It can be used to
- build a system that reads files in one format, processes them, and exports
- them in another format.
-- **alsa** is a software framework and part of the Linux kernel that provides an
- **API** for sound card device drivers.
-
-
-
-Domain | `Tool` name | _State_
--------------------- | ----------- | -------
-Platform-Utilities-1 | `connman` | _Used_ as a connection manager.
-Platform-Utilities-2 | `bluez` | _Used_ as a Bluetooth manager.
-Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format.
-Platform-Utilities-4 | `alsa` | _Used_ to provides an API for sound card device drivers.
-
-
-
-# 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,
- ...
-- The life cycle of applications: Start -> (Pause, Resume) -> Stop.
-- Events and signals propagation.
-- Privileges granting and checking.
-- API for interaction with applications.
-
-
-
-- The **security model** refers to the security model used to ensure security
- and to the tools that are provided for implementing that model. It's an
- implementation detail that should not impact the layers above the application
- framework.
-
-- 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.
-
-
-
-The **AppFw** uses the security model to ensure the security and the privacy of
-the applications that it manages. It must be compliant with the underlying
-security model. But it should hide it to the applications.
-
-
-
-Domain | Object | Recommendations
----------------------- | -------------- | --------------------------------
-Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model.
-
-
-
-See [AGL AppFw Privileges
-Management](http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/appfw/03-AGL-AppFW-Privileges-Management.pdf)
-and [AGL - Application Framework
-Documentation](http://iot.bzh/download/public/2017/SDK/AppFw-Documentation-v3.1.pdf)
-for more information.
-
-
-
-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.
-
-![Application Framework Flow](images/App-flow.png)
-
-## Cynara
-
-There's a need for another mechanism responsible for checking applicative
-permissions: Currently in AGL, this task depends on a policy-checker service
-(**Cynara**).
-
-- Stores complex policies in databases.
-- "Soft" security (access is checked by the framework).
-
-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.
-
-
-
-Domain | Object | Recommendations
------------------------ | ----------- | -------------------------------------
-Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service.
-
-
-
-### Policies
-
-- Policy rules:
-
- - Are simple - for pair [application context, privilege] there is straight
- answer (single Policy Type): [ALLOW / DENY / ...].
- - No code is executed (no script).
- - Can be easily cached and managed.
-
-- Application context (describes id of the user and the application credentials)
- It is build of:
-
- - UID of the user that runs the application.
- - **SMACK** label of application.
-
-## Holding policies
-
-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 unforeseen 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`.
-
-# Utilities
-
-- **busybox**: Software that provides several stripped-down Unix tools in a
- single executable file. Of course, it will be necessary to use a "production"
- version of **busybox** in order to avoid all the tools useful only in
- development mode.
-
-
-
-Domain | `Tool` name | _State_
--------------------- | ----------- | ----------------------------------------------------------------------
-Platform-Utilities-1 | `busybox` | _Used_ to provide a number of tools. Do not compile development tools.
-
-
-
-## Functionalities to exclude in production mode
-
-In production mode, a number of tools must be disabled to prevent an attacker
-from finding logs for example. This is useful to limit the visible surface and
-thus complicate the fault finding process. The tools used only in development
-mode are marked by an '**agl-devel**' feature. When building in production mode,
-these tools will not be compiled.
-
-
-
-Domain | `Utility` name and normal `path` | _State_
---------------------- | ---------------------------------------------------- | ----------
-Platform-Utilities-1 | `chgrp` in `/bin/chgrp` | _Disabled_
-Platform-Utilities-2 | `chmod` in `/bin/chmod` | _Disabled_
-Platform-Utilities-3 | `chown` in `/bin/chown` | _Disabled_
-Platform-Utilities-4 | `dmesg` in `/bin/dmesg` | _Disabled_
-Platform-Utilities-5 | `Dnsdomainname` in `/bin/dnsdomainname` | _Disabled_
-Platform-Utilities-6 | `dropbear`, Remove "dropbear" from `/etc/init.d/rcs` | _Disabled_
-Platform-Utilities-7 | `Editors` in (vi) `/bin/vi` | _Disabled_
-Platform-Utilities-8 | `find` in `/bin/find` | _Disabled_
-Platform-Utilities-9 | `gdbserver` in `/bin/gdbserver` | _Disabled_
-Platform-Utilities-10 | `hexdump` in `/bin/hexdump` | _Disabled_
-Platform-Utilities-11 | `hostname` in `/bin/hostname` | _Disabled_
-Platform-Utilities-12 | `install` in `/bin/install` | _Disabled_
-Platform-Utilities-13 | `iostat` in `/bin/iostat` | _Disabled_
-Platform-Utilities-14 | `killall` in `/bin/killall` | _Disabled_
-Platform-Utilities-15 | `klogd` in `/sbin/klogd` | _Disabled_
-Platform-Utilities-16 | `logger` in `/bin/logger` | _Disabled_
-Platform-Utilities-17 | `lsmod` in `/sbin/lsmod` | _Disabled_
-Platform-Utilities-18 | `pmap` in `/bin/pmap` | _Disabled_
-Platform-Utilities-19 | `ps` in `/bin/ps` | _Disabled_
-Platform-Utilities-20 | `ps` in `/bin/ps` | _Disabled_
-Platform-Utilities-21 | `rpm` in `/bin/rpm` | _Disabled_
-Platform-Utilities-22 | `SSH` | _Disabled_
-Platform-Utilities-23 | `stbhotplug` in `/sbin/stbhotplug` | _Disabled_
-Platform-Utilities-24 | `strace` in `/bin/trace` | _Disabled_
-Platform-Utilities-25 | `su` in `/bin/su` | _Disabled_
-Platform-Utilities-26 | `syslogd` in (logger) `/bin/logger` | _Disabled_
-Platform-Utilities-27 | `top` in `/bin/top` | _Disabled_
-Platform-Utilities-28 | `UART` in `/proc/tty/driver/` | _Disabled_
-Platform-Utilities-29 | `which` in `/bin/which` | _Disabled_
-Platform-Utilities-30 | `who` and `whoami` in `/bin/whoami` | _Disabled_
-Platform-Utilities-31 | `awk` (busybox) | _Enabled_
-Platform-Utilities-32 | `cut` (busybox) | _Enabled_
-Platform-Utilities-33 | `df` (busybox) | _Enabled_
-Platform-Utilities-34 | `echo` (busybox) | _Enabled_
-Platform-Utilities-35 | `fdisk` (busybox) | _Enabled_
-Platform-Utilities-36 | `grep` (busybox) | _Enabled_
-Platform-Utilities-37 | `mkdir` (busybox) | _Enabled_
-Platform-Utilities-38 | `mount` (vfat) (busybox) | _Enabled_
-Platform-Utilities-39 | `printf` (busybox) | _Enabled_
-Platform-Utilities-40 | `sed` in `/bin/sed` (busybox) | _Enabled_
-Platform-Utilities-41 | `tail` (busybox) | _Enabled_
-Platform-Utilities-42 | `tee` (busybox) | _Enabled_
-Platform-Utilities-43 | `test` (busybox) | _Enabled_
-
-
-
-The _Enabled_ Unix/Linux utilities above shall be permitted as they are often
-used in the start-up scripts and for USB logging. If any of these utilities are
-not required by the device then those should be removed.
-
-
-
-# Users
-
-The user policy can group users by function within the car. For example, we can
-consider a driver and his passengers. Each user is assigned to a single group to
-simplify the management of space security.
-
-## Root Access
-
-The main applications, those that provide the principal functionality of the
-embedded device, should not execute with root identity or any capability.
-
-If the main application is allowed to execute at any capability, then the entire
-system is at the mercy of the said application's good behaviour. Problems arise
-when an application is compromised and able to execute commands which could
-consistently and persistently compromise the system by implanting rogue
-applications.
-
-It is suggested that the middleware and the UI should run in a context on a user
-with no capability and all persistent resources should be maintained without any
-capability.
-
-One way to ensure this is by implementing a server-client paradigm. Services
-provided by the system's drivers can be shared this way. The other advantage of
-this approach is that multiple applications can share the same resources at the
-same time.
-
-
-
-Domain | Object | Recommendations
---------------------- | ---------------- | -----------------------------------------------------
-Platform-Users-root-1 | Main application | Should not execute as root.
-Platform-Users-root-2 | UI | Should run in a context on a user with no capability.
-
-
-
-Root access should not be allowed for the following utilities:
-
-
-
-Domain | `Utility` name | _State_
---------------------- | -------------- | -------------
-Platform-Users-root-3 | `login` | _Not allowed_
-Platform-Users-root-4 | `su` | _Not allowed_
-Platform-Users-root-5 | `ssh` | _Not allowed_
-Platform-Users-root-6 | `scp` | _Not allowed_
-Platform-Users-root-7 | `sftp` | _Not allowed_
-
-
-
-Root access should not be allowed for the console device. The development
-environment should allow users to login with pre-created user accounts.
-
-Switching to elevated privileges shall be allowed in the development environment
-via `sudo`.
-
---------------------------------------------------------------------------------
-
-
-
-## Capabilities
-
-
-
-Domain | Improvement
------------------------------ | ------------------------
-Platform-Users-Capabilities-1 | Kernel or Platform-user?
-Platform-Users-Capabilities-2 | Add config note.
-
-
-
-The goal is to restrict functionality that will not be useful in **AGL**. They
-are integrated into the **LSM**. Each privileged transaction is associated with
-a capability. These capabilities are divided into three groups:
-
-- e: Effective: This means the capability is “activated”.
-- p: Permitted: This means the capability can be used/is allowed.
-- i: Inherited: The capability is kept by child/subprocesses upon execve() for
- example.
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/6_Application.md b/docs/2_Architecture_Guides/2_Security_Blueprint/6_Application.md
deleted file mode 100644
index c08d06e..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/6_Application.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-title: Application
----
-
-**Application Hardening**: Best practices to apply to the build and release of
-user space applications, in order to reduce the number of attack surfaces used
-by potential attackers.
-
-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 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](images/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
-
-The following table lists the terms utilized within this part of the document.
-
-Acronyms or Abbreviations | Description
-------------------------- | ----------------------------------------------------
-_3GPP_ | **3**rd **G**eneration **P**artnership **P**roject
-_CASB_ | **C**loud **A**ccess **S**ecurity **B**roker
-_DAST_ | **D**ynamic **A**pplication **S**ecurity **T**esting
-_DPI_ | **D**eep **P**acket **I**nspection
-_IDS_ | **I**ntrusion **D**etection **S**ystems
-_IPS_ | **I**ntrusion **P**revention **S**ystems
-_IPSec_ | **I**nternet **P**rotocol **Sec**urity
-_LSM_ | **L**inux **S**ecurity **M**odule
-_MITM_ | **M**an **I**n **T**he **M**iddle
-_OSI_ | **O**pen **S**ystems **I**nterconnection
-_SATS_ | **S**tatic **A**pplication **S**ecurity **T**esting
-
-# Local
-
-Domain | Improvement
--------------------------- | ------------------------------
-Application-Installation-1 | Talk about AppFw offline mode.
-
-## Installation
-
-Applications can be delivered and installed with the base image using a special
-offline-mode provided by the **AppFw**. Apps can also be installed at run time.
-
-During early release, default Apps are installed on the image at first boot.
-
-Domain | Object | Recommendations
--------------------------- | --------- | -----------------------------------------------------------------------
-Application-Installation-1 | AppFw | Provide offline-mode in order to install app with the base image.
-Application-Installation-2 | Integrity | Allow the installation of applications only if their integrity is good.
-
-# Local
-
-## Privilege Management
-
-Application privileges are managed by **Cynara** and the security manager in the
-**AppFw**. For more details, please refer to the **AppFw** documentation in
-Platform part.
-
-# App Signature
-
-Domain | Improvement
------------------------ | ----------------------------------------------------------
-Application-Signature-1 | Add content (see secure build in Secure development part).
-
-
-# Services
-
-Domain | Improvement
----------------------- | ------------
-Application-Services-1 | Add content (Which services?).
-Application-Services-2 | Add Binder. \ No newline at end of file
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/7_Connectivity.md b/docs/2_Architecture_Guides/2_Security_Blueprint/7_Connectivity.md
deleted file mode 100644
index 076c0e0..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/7_Connectivity.md
+++ /dev/null
@@ -1,487 +0,0 @@
----
-title: Connectivity
----
-
-This part shows different Connectivity attacks on the car.
-
-Domain | Improvement
------------------------ | -----------------
-Connectivity-Abstract-1 | Improve abstract.
-
-
-
---------------------------------------------------------------------------------
-
-
-
-## Acronyms and Abbreviations
-
-The following table lists the terms utilized within this part of the document.
-
-Acronyms or Abbreviations | Description
-------------------------- | ---------------------------------------------------------------------------------
-_ARP_ | **A**ddress **R**esolution **P**rotocol
-_BLE_ | **B**luetooth **L**ow **E**nergy
-_CAN_ | **C**ar **A**rea **N**etwork
-_CCMP_ | **C**ounter-Mode/**C**BC-**M**ac **P**rotocol
-_EDGE_ | **E**nhanced **D**ata **R**ates for **GSM** **E**volution - Evolution of **GPRS**
-_GEA_ | **G**PRS **E**ncryption **A**lgorithm
-_GPRS_ | **G**eneral **P**acket **R**adio **S**ervice (2,5G, 2G+)
-_GSM_ | **G**lobal **S**ystem for **M**obile Communications (2G)
-_HSPA_ | **H**igh **S**peed **P**acket **A**ccess (3G+)
-_IMEI_ | **I**nternational **M**obile **E**quipment **I**dentity
-_LIN_ | **L**ocal **I**nterconnect **N**etwork
-_MOST_ | **M**edia **O**riented **S**ystem **T**ransport
-_NFC_ | **N**ear **F**ield **C**ommunication
-_OBD_ | **O**n-**B**oard **D**iagnostics
-_PATS_ | **P**assive **A**nti-**T**heft **S**ystem
-_PKE_ | **P**assive **K**eyless **E**ntry
-_PSK_ | **P**hase-**S**hift **K**eying
-_RDS_ | **R**adio **D**ata **S**ystem
-_RFID_ | **R**adio **F**requency **I**dentification
-_RKE_ | **R**emote **K**eyless **E**ntry
-_SDR_ | **S**oftware **D**efined **R**adio
-_SSP_ | **S**ecure **S**imple **P**airing
-_TKIP_ | **T**emporal **K**ey **I**ntegrity **P**rotocol
-_TPMS_ | **T**ire **P**ressure **M**onitoring **S**ystem
-_UMTS_ | **U**niversal **M**obile **T**elecommunications **S**ystem (3G)
-_USB_ | **U**niversal **S**erial **B**us
-_WEP_ | **W**ired **E**quivalent **P**rivacy
-_WPA_ | **W**ifi **P**rotected **A**ccess
-
-# Bus
-
-We only speak about the **CAN** bus to take an example, because the different
-attacks on bus like _FlewRay_, _ByteFlight_, _Most_ and _Lin_ use retro
-engineering and the main argument to improve their security is to encrypt data
-packets. We just describe them a bit:
-
-- **CAN**: Controller Area Network, developed in the early 1980s, is an
- event-triggered controller network for serial communication with data rates up
- to one MBit/s. **CAN** messages are classified over their respective
- identifier. **CAN** controller broadcast their messages to all connected nodes
- and all receiving nodes decide independently if they process the message.
-- **FlewRay**: Is a deterministic and error-tolerant high-speed bus. With a data
- rate up to 10 MBit/s.
-- **ByteFlight**: Is used for safety-critical applications in motor vehicles
- like air-bags. Byteflight runs at 10Mbps over 2 or 3 wires plastic optical
- fibers.
-- **Most**: Media Oriented System Transport, is used for transmitting audio,
- video, voice, and control data via fiber optic cables. The speed is, for the
- synchronous way, up to 24 MBit/s and asynchronous way up to 14 MBit/s.
- **MOST** messages include always a clear sender and receiver address.
-- **LIN**: Local Interconnect Network, is a single-wire subnet work for
- low-cost, serial communication between smart sensors and actuators with
- typical data rates up to 20 kBit/s. It is intended to be used from the year
- 2001 on everywhere in a car, where the bandwidth and versatility of a **CAN**
- network is not required.
-
-On just about every vehicle, **ECU**s (**E**lectronic **C**ontrol **U**nits)
-communicate over a CAN bus, which is a two-wire bus using hardware arbitration
-for messages sent on the shared medium. This is essentially a *trusted* network
-where all traffic is visible to all controllers and any controller can send any
-message.
-
-A malicious **ECU** on the CAN bus can easily inject messages destined for any
-other device, including things like the instrument cluster and the head unit.
-There are common ways for hardware to do USB to CAN and open source software to
-send and receive messages. For example, there is a driver included in the Linux
-kernel that can be used to send/receive CAN signals. A malicious device on the
-CAN bus can cause a great number of harmful things to happen to the system,
-including: sending bogus information to other devices, sending unintended
-commands to ECUs, causing DOS (Denial Of Service) on the CAN bus, etc.
-
-
-
-Domain | Tech name | Recommendations
----------------------------------- | --------- | --------------------------------------------------------------------------
-Connectivity-BusAndConnector-Bus-1 | CAN | Implement hardware solution in order to prohibit sending unwanted signals.
-
-
-
-See [Security in Automotive Bus
-Systems](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.728&rep=rep1&type=pdf)
-for more information.
-
-# Connectors
-
-For the connectors, we supposed that they were disabled by default. For example,
-the **USB** must be disabled to avoid attacks like BadUSB. If not, configure the
-Kernel to only enable the minimum require **USB** devices. The connectors used
-to diagnose the car like **OBD-II** must be disabled outside garages.
-
-
-
-Domain | Tech name | Recommendations
------------------------------------------ | --------- | ----------------------------------------------------------------------
-Connectivity-BusAndConnector-Connectors-1 | USB | Must be disabled. If not, only enable the minimum require USB devices.
-Connectivity-BusAndConnector-Connectors-2 | USB | Confidential data exchanged with the ECU over USB must be secure.
-Connectivity-BusAndConnector-Connectors-3 | USB | USB Boot on a ECU must be disable.
-Connectivity-BusAndConnector-Connectors-4 | OBD-II | Must be disabled outside garages.
-
-
-
-# Wireless
-
-In this part, we talk about possible remote attacks on a car, according to the
-different areas of possible attacks. For each communication channels, we
-describe attacks and how to prevent them with some recommendations. The main
-recommendation is to always follow the latest updates of these remote
-communication channels.
-
-
-
-Domain | Object | Recommendations
------------------------ | ------ | ------------------------------------------------------------------
-Connectivity-Wireless-1 | Update | Always follow the latest updates of remote communication channels.
-
-
-
-We will see the following parts:
-
-- [Wifi](#wifi)
-
-- [Bluetooth](#bluetooth)
-
-- [Cellular](#cellular)
-
-- [Radio](#radio)
-
-- [NFC](#nfc)
-
-
-
-Domain | Improvement
------------------------ | -------------------------------------------
-Connectivity-Wireless-1 | Add communication channels (RFID, ZigBee?).
-
-
-
---------------------------------------------------------------------------------
-
-For existing automotive-specific means, we take examples of existing system
-attacks from the _IOActive_ document ([A Survey of Remote Automotive Attack
-Surfaces](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf))
-and from the ETH document ([Relay Attacks on Passive Keyless Entry and Start
-Systems in Modern Cars](https://eprint.iacr.org/2010/332.pdf)).
-
-- [Telematics](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A40%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D)
-
-- [Passive Anti-Theft System
- (PATS)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A11%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C574%2C0%5D)
-
-- [Tire Pressure Monitoring System
- (TPMS)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A17%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D)
-
-- [Remote Keyless Entry/Start
- (RKE)](https://www.ioactive.com/pdfs/IOActive_Remote_Attack_Surfaces.pdf#%5B%7B%22num%22%3A26%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C60%2C720%2C0%5D)
-
-- [Passive Keyless Entry (PKE)](https://eprint.iacr.org/2010/332.pdf)
-
---------------------------------------------------------------------------------
-
-
-
-## Wifi
-
-### Attacks
-
-We can differentiate existing attacks on wifi in two categories: Those on
-**WEP** and those on **WPA**.
-
-- **WEP** attacks:
-
- - **FMS**: (**F**luhrer, **M**antin and **S**hamir attack) is a "Stream cipher
- attack on the widely used RC4 stream cipher. The attack allows an attacker
- to recover the key in an RC4 encrypted stream from a large number of
- messages in that stream."
- - **KoreK**: "Allows the attacker to reduce the key space".
- - **PTW**: (**P**yshkin **T**ews **W**einmann attack).
- - **Chopchop**: Found by KoreK, "Weakness of the CRC32 checksum and the lack
- of replay protection."
- - **Fragmentation**
-
-- **WPA** attacks:
-
- - **Beck and Tews**: Exploit weakness in **TKIP**. "Allow the attacker to
- decrypt **ARP** packets and to inject traffic into a network, even allowing
- him to perform a **DoS** or an **ARP** poisoning".
- - [KRACK](https://github.com/kristate/krackinfo): (K)ey (R)einstallation
- (A)tta(ck) ([jira AGL
- SPEC-1017](https://jira.automotivelinux.org/browse/SPEC-1017)).
-
-### Recommendations
-
-- Do not use **WEP**, **PSK** and **TKIP**.
-
-- Use **WPA2** with **CCMP**.
-
-- Should protect data sniffing.
-
-
-
-Domain | Tech name or object | Recommendations
----------------------------- | ------------------- | -------------------------------------------------------------------------
-Connectivity-Wireless-Wifi-1 | WEP, PSK, TKIP | Disabled
-Connectivity-Wireless-Wifi-2 | WPA2 and AES-CCMP | Used
-Connectivity-Wireless-Wifi-3 | WPA2 | Should protect data sniffing.
-Connectivity-Wireless-Wifi-4 | PSK | Changing regularly the password.
-Connectivity-Wireless-Wifi-5 | Device | Upgraded easily in software or firmware to have the last security update.
-
-
-
-See [Wifi attacks WEP WPA](https://matthieu.io/dl/wifi-attacks-wep-wpa.pdf) and
-[Breaking wep and wpa (Beck and
-Tews)](https://dl.aircrack-ng.org/breakingwepandwpa.pdf) for more information.
-
---------------------------------------------------------------------------------
-
-
-
-## Bluetooth
-
-### Attacks
-
-- **Bluesnarfing** attacks involve an attacker covertly gaining access to your
- Bluetooth-enabled device for the purpose of retrieving information, including
- addresses, calendar information or even the device's **I**nternational
- **M**obile **E**quipment **I**dentity. With the **IMEI**, an attacker could
- route your incoming calls to his cell phone.
-- **Bluebugging** is a form of Bluetooth attack often caused by a lack of
- awareness. Similar to bluesnarfing, bluebugging accesses and uses all phone
- features but is limited by the transmitting power of class 2 Bluetooth radios,
- normally capping its range at 10-15 meters.
-- **Bluejacking** is the sending of unsolicited messages.
-- **BLE**: **B**luetooth **L**ow **E**nergy
- [attacks](https://www.usenix.org/system/files/conference/woot13/woot13-ryan.pdf).
-- **DoS**: Drain a device's battery or temporarily paralyze the phone.
-
-### Recommendations
-
-- Not allowing Bluetooth pairing attempts without the driver's first manually
- placing the vehicle in pairing mode.
-- Monitoring.
-- Use **BLE** with caution.
-- For v2.1 and later devices using **S**ecure **S**imple **P**airing (**SSP**),
- avoid using the "Just Works" association model. The device must verify that an
- authenticated link key was generated during pairing.
-
-
-
-Domain | Tech name | Recommendations
---------------------------------- | ------------- | ------------------------------------------------------------
-Connectivity-Wireless-Bluetooth-1 | BLE | Use with caution.
-Connectivity-Wireless-Bluetooth-2 | Bluetooth | Monitoring
-Connectivity-Wireless-Bluetooth-3 | SSP | Avoid using the "Just Works" association model.
-Connectivity-Wireless-Bluetooth-4 | Visibility | Configured by default as undiscoverable. Except when needed.
-Connectivity-Wireless-Bluetooth-5 | Anti-scanning | Used, inter alia, to slow down brute force attacks.
-
-
-
-See [Low energy and the automotive
-transformation](http://www.ti.com/lit/wp/sway008/sway008.pdf), [Gattacking
-Bluetooth Smart Devices](http://gattack.io/whitepaper.pdf), [Comprehensive
-Experimental Analyses of Automotive Attack
-Surfaces](http://www.autosec.org/pubs/cars-usenixsec2011.pdf) and [With Low
-Energy comes Low
-Security](https://www.usenix.org/system/files/conference/woot13/woot13-ryan.pdf)
-for more information.
-
---------------------------------------------------------------------------------
-
-
-
-## Cellular
-
-### Attacks
-
-- **IMSI-Catcher**: Is a telephone eavesdropping device used for intercepting
- mobile phone traffic and tracking location data of mobile phone users.
- Essentially a "fake" mobile tower acting between the target mobile phone and
- the service provider's real towers, it is considered a man-in-the-middle
- (**MITM**) attack.
-
-- Lack of mutual authentication (**GPRS**/**EDGE**) and encryption with
- **GEA0**.
-
-- **Fall back** from **UMTS**/**HSPA** to **GPRS**/**EDGE** (Jamming against
- **UMTS**/**HSPA**).
-
-- 4G **DoS** attack.
-
-### Recommendations
-
-- Check antenna legitimacy.
-
-
-
-Domain | Tech name | Recommendations
--------------------------------- | --------- | --------------------------
-Connectivity-Wireless-Cellular-1 | GPRS/EDGE | Avoid
-Connectivity-Wireless-Cellular-2 | UMTS/HSPA | Protected against Jamming.
-
-
-
-See [A practical attack against GPRS/EDGE/UMTS/HSPA mobile data
-communications](https://media.blackhat.com/bh-dc-11/Perez-Pico/BlackHat_DC_2011_Perez-Pico_Mobile_Attacks-wp.pdf)
-for more information.
-
---------------------------------------------------------------------------------
-
-## Radio
-
-### Attacks
-
-- Interception of data with low cost material (**SDR** with hijacked DVB-T/DAB
- for example).
-
-### Recommendations
-
-- Use the **R**adio **D**ata **S**ystem (**RDS**) only to send signals for audio
- output and meta concerning radio.
-
-
-
-Domain | Tech name | Recommendations
------------------------------ | --------- | --------------------------------------------
-Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concerning radio.
-
-
-
---------------------------------------------------------------------------------
-
-
-
-## NFC
-
-### Attacks
-
-- **MITM**: Relay and replay attack.
-
-### Recommendations
-
-- Should implements protection against relay and replay attacks (Tokens,
- etc...).
-- Disable unneeded and unapproved services and profiles.
-- NFC should be use encrypted link (secure channel). A standard key agreement
- protocol like Diffie-Hellmann based on RSA or Elliptic Curves could be applied
- to establish a shared secret between two devices.
-- Automotive NFC device should be certified by NFC forum entity: The NFC Forum
- Certification Mark shows that products meet global interoperability standards.
-- NFC Modified Miller coding is preferred over NFC Manchester coding.
-
-
-
-Domain | Tech name | Recommendations
---------------------------- | --------- | ------------------------------------------------------
-Connectivity-Wireless-NFC-1 | NFC | Protected against relay and replay attacks.
-Connectivity-Wireless-NFC-2 | Device | Disable unneeded and unapproved services and profiles.
-
-
-
-# Cloud
-
-## Download
-
-- **authentication**: Authentication is the security process that validates the
- claimed identity of a device, entity or person, relying on one or more
- characteristics bound to that device, entity or person.
-
-- **Authorization**: Parses the network to allow access to some or all network
- functionality by providing rules and allowing access or denying access based
- on a subscriber's profile and services purchased.
-
-
-
-Domain | Object | Recommendations
----------------------------- | -------------- | --------------------------------------
-Application-Cloud-Download-1 | authentication | Must implement authentication process.
-Application-Cloud-Download-2 | Authorization | Must implement Authorization process.
-
-
-
---------------------------------------------------------------------------------
-
-## Infrastructure
-
-- **Deep Packet Inspection**: **DPI** provides techniques to analyze the payload
- of each packet, adding an extra layer of security. **DPI** can detect and
- neutralize attacks that would be missed by other security mechanisms.
-
-- A **DoS** protection in order to avoid that the Infrastructure is no more
- accessible for a period of time.
-
-- **Scanning tools** such as **SATS** and **DAST** assessments perform
- vulnerability scans on the source code and data flows on web applications.
- Many of these scanning tools run different security tests that stress
- applications under certain attack scenarios to discover security issues.
-
-- **IDS & IPS**: **IDS** detect and log inappropriate, incorrect, or anomalous
- activity. **IDS** can be located in the telecommunications networks and/or
- within the host server or computer. Telecommunications carriers build
- intrusion detection capability in all network connections to routers and
- servers, as well as offering it as a service to enterprise customers. Once
- **IDS** systems have identified an attack, **IPS** ensures that malicious
- packets are blocked before they cause any harm to backend systems and
- networks. **IDS** typically functions via one or more of three systems:
-
- 1. Pattern matching.
- 2. Anomaly detection.
- 3. Protocol behavior.
-
-
-
-
-
-Domain | Object | Recommendations
----------------------------------- | ------------- | ----------------------------------------------------------
-Application-Cloud-Infrastructure-1 | Packet | Should implement a DPI.
-Application-Cloud-Infrastructure-2 | DoS | Must implement a DoS protection.
-Application-Cloud-Infrastructure-3 | Test | Should implement scanning tools like SATS and DAST.
-Application-Cloud-Infrastructure-4 | Log | Should implement security tools (IDS and IPS).
-Application-Cloud-Infrastructure-5 | App integrity | Applications must be signed by the code signing authority.
-
-
-
---------------------------------------------------------------------------------
-
-## Transport
-
-For data transport, it is necessary to **encrypt data end-to-end**. To prevent
-**MITM** attacks, no third party should be able to interpret transported data.
-Another aspect is the data anonymization in order to protect the leakage of
-private information on the user or any other third party.
-
-The use of standards such as **IPSec** provides "_private and secure
-communications over IP networks, through the use of cryptographic security
-services, is a set of protocols using algorithms to transport secure data over
-an IP network._". In addition, **IPSec** operates at the network layer of the
-**OSI** model, contrary to previous standards that operate at the application
-layer. This makes its application independent and means that users do not need
-to configure each application to **IPSec** standards.
-
-**IPSec** provides the services below :
-
-- Confidentiality: A service that makes it impossible to interpret data if it is
- not the recipient. It is the encryption function that provides this service by
- transforming intelligible (unencrypted) data into unintelligible (encrypted)
- data.
-- Authentication: A service that ensures that a piece of data comes from where
- it is supposed to come from.
-- Integrity: A service that consists in ensuring that data has not been tampered
- with accidentally or fraudulently.
-- Replay Protection: A service that prevents attacks by re-sending a valid
- intercepted packet to the network for the same authorization. This service is
- provided by the presence of a sequence number.
-- Key management: Mechanism for negotiating the length of encryption keys
- between two **IPSec** elements and exchange of these keys.
-
-An additional means of protection would be to do the monitoring between users
-and the cloud as a **CASB** will provide.
-
-
-
-Domain | Object | Recommendations
------------------------------ | ----------------------------------------- | ---------------------------------
-Application-Cloud-Transport-1 | Integrity, confidentiality and legitimacy | Should implement IPSec standards.
-
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/8_Update_OTA.md b/docs/2_Architecture_Guides/2_Security_Blueprint/8_Update_OTA.md
deleted file mode 100644
index 60ae8e4..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/8_Update_OTA.md
+++ /dev/null
@@ -1,154 +0,0 @@
----
-title: Update (Over The Air)
----
-
-Updating applications and firmware is essential for the development of new
-features and even more to fix security bugs. However, if a malicious third party
-manages to alter the content during transport, it could 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
-
-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
-
-# Firmware Over The Air
-
-The firmware update is critical since its alteration back to compromise the
-entire system. It is therefore necessary to take appropriate protective
-measures.
-
-AGL includes the _meta-updater_ Yocto layer that enables OTA software updates
-via [Uptane](https://uptane.github.io), an automotive-specific extension to [The
-Update Framework](https://theupdateframework.github.io/). Uptane and TUF are
-open standards that define a secure protocol for delivering and verifying
-updates even when the servers and network--internet and car-internal--aren't
-fully trusted.
-
-_meta-updater_ includes the application
-[`aktualizr`](https://github.com/advancedtelematic/aktualizr), developed
-Advanced Telematic Systems (now part of HERE Technologies) that enables OTA for
-an ECU. `aktualizr` combined with Uptane is suitable for updating the firmware,
-software, and other packages on even functionally critical ECUs. `aktualizr` can
-be enabled with the free, open souce backend
-[`ota-community-edition`](https://github.com/advancedtelematic/ota-community-edition).
-
-This FOTA update mechanism can be enabled through the `agl-sota` feature.
-
-## Building
-
-To build an AGL image that uses `aktualizr`, the following can be used.
-
-```
-source meta-agl/scripts/aglsetup.sh -m <machine> agl-sota <other-features...>
-```
-
-During the build, _meta-updater_ will use credentials downloaded from
-`ota-community-edition` to sign metadata verifying the build as authentic. These
-signatures are part of the Uptane framework and are used to verify FOTA updates.
-
-## Atomic Upgrades with Rollbacks
-
-`aktualizr`'s primary method of updating firmware is to use `libostree` with
-binary diffs. The binary diffs use the least amout of bandwidth, and by it's
-nature `libostree` stores current and previous firmware versions on disk or in
-flash memory to allow for rollbacks.
-
-`libostree` is a content addressable object store much like `git`. Versions are
-specified via SHA2-256. These hashes are signed in the Uptane metadata and are
-robust against cryptographic compromise.
-
-# 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).
-
-Domain | Improvement
-------------- | -----------------
-Update-SOTA-1 | Part to complete. \ No newline at end of file
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/9_Secure_development.md b/docs/2_Architecture_Guides/2_Security_Blueprint/9_Secure_development.md
deleted file mode 100644
index 9cbe3b4..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/9_Secure_development.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: Secure development
----
-
-In order to save a lot of time in code auditing, developers must follow coding
-guidelines.
-
-## Secure build
-
-### Kernel build
-
-Tools like:
-
-- [Code optimisation](https://github.com/jduck/lk-reducer).
-- [Kernel Drivers test](https://github.com/ucsb-seclab/dr_checker) with
- [docs](https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-machiry.pdf).
-
-Domain | Improvement
------------------------ | ------------
-SecureDev-SecureBuild-1 | Add content.
-
-## App/Widget signatures
-
-Domain | Improvement
----------------------- | ------------
-SecureDev-Signatures-1 | Add content.
-
-## Code audit
-
-These tools are used to check the correct implementation of functionalities and
-compliance with related good practices.
-
-- [Continuous Code Quality](https://www.sonarqube.org/).
-
-Domain | Improvement
---------------------- | -----------------------------------------------------
-SecureDev-CodeAudit-1 | Add CVE analyser.
-SecureDev-CodeAudit-2 | [OSSTMM](http://www.isecom.org/mirror/OSSTMM.3.pdf).
-
-### SATS
-
-- [RATS](https://github.com/andrew-d/rough-auditing-tool-for-security) (Maybe to
- old).
-- [Flaw Finder](https://www.dwheeler.com/flawfinder/).
-
-- [wiki
- list](https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis).
-
-- [Mathematical
- approach](https://perso.univ-rennes1.fr/david.lubicz/planches/David_Pichardie.pdf).
-
-It is necessary to verify that the application code does not use functions that
-are depreciated and recognized as unsecured or cause problems.
-
-### DATS
-
-- [wiki
- list](https://en.wikipedia.org/wiki/Dynamic_program_analysis#Example_tools). \ No newline at end of file
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/Annexes.md b/docs/2_Architecture_Guides/2_Security_Blueprint/Annexes.md
deleted file mode 100644
index c279203..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/Annexes.md
+++ /dev/null
@@ -1,578 +0,0 @@
----
-title: Annexes
----
-
-The first part resumed all the configurations you must implement without any
-explications since all the explanations are given as and when in the document.
-
-- The _config_ tag quickly identifies the configurations and the recommendations
- to take.
-
-- The _note_ tag allows you to notify some additional details.
-
-- The _todo_ tag shows the possible improvements.
-
-The second one allows to visualize all the todo notes in order to have a global
-vision of the possible improvements of the document.
-
-# Config notes
-
-
-Domain | Object | Recommendations
--------------------- | ---------- | ----------------------------------
-Hardware-Integrity-1 | Bootloader | Must control bootloader integrity.
-Hardware-Integrity-2 | Board | Must use a HSM.
-Hardware-Integrity-3 | RTC | Must not be alterable.
-
-Domain | Object | Recommendations
----------------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------
-Hardware-Certificate-1 | System | Shall allow storing dedicated certificates.
-Hardware-Certificate-2 | ECU | The ECU must verify the certification authority hierarchy.
-Hardware-Certificate-3 | System | Allow the modification of certificates only if the source can be authenticated by a certificate already stored or in the higher levels of the chain of trust.
-
-Domain | Object | Recommendations
------------------ | ---------- | ------------------------------------------------------------------------------------
-Hardware-Memory-1 | ECU | The ECU shall never expose the unencrypted key in RAM when using cryptographic keys.
-Hardware-Memory-2 | Bootloader | Internal NVM only
-Hardware-Module-3 | - | HSM must be used to secure keys.
-
-Domain | _Variable_ / `Config` name | `Value`
----------------------- | -------------------------- | -------
-Boot-Image-Selection-1 | `CONFIG_BOOTDELAY` | `-2`
-Boot-Image-Selection-2 | _bootdelay_ | `-2`
-
-Domain | `Config` name | _State_
-------------------------- | ---------------------------- | --------
-Boot-Image-Authenticity-1 | `CONFIG_FIT` | _Enable_
-Boot-Image-Authenticity-2 | `CONFIG_FIT_SIGNATURE` | _Enable_
-Boot-Image-Authenticity-3 | `CONFIG_RSA` | _Enable_
-Boot-Image-Authenticity-4 | `CONFIG_OF_CONTROL` | _Enable_
-Boot-Image-Authenticity-5 | `CONFIG_OF_SEPARATE` | _Enable_
-Boot-Image-Authenticity-6 | `CONFIG_DEFAULT_DEVICE_TREE` | _Enable_
-
-Domain | Communication modes | _State_
--------------------- | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------
-Boot-Communication-1 | `USB` | _Disabled_ and _Compiled-out_ if not required.
-Boot-Communication-2 | `USB` | Else, Kernel should be configured to only enable the minimum required USB devices and filesystems should be treated with special care.
-Boot-Communication-3 | `Ethernet` | _Disabled_
-Boot-Communication-4 | U-boot and sboot `DOCSIS` | _Disabled_
-Boot-Communication-5 | `Serial ports` | _Disabled_
-
-Domain | `Config` name | _State_
------------------------- | ----------------------- | -------------
-Boot-Communication-USB-1 | `CONFIG_CMD_USB` | _Not defined_
-Boot-Communication-USB-2 | `CONFIG_USB_UHCI` | _Not defined_
-Boot-Communication-USB-3 | `CONFIG_USB_KEYBOARD` | _Not defined_
-Boot-Communication-USB-4 | `CONFIG_USB_STORAGE` | _Not defined_
-Boot-Communication-USB-5 | `CONFIG_USB_HOST_ETHER` | _Not defined_
-
-Domain | Communication modes | _State_
--------------------- | -------------------- | ---------------------------------------------------------------------------------------------
-Boot-Communication-1 | `Network interfaces` | Preferably _no network interface is allowed_, otherwise, restrict the services to those used.
-
-Domain | Object | Recommendations
--------------------- | --------------------------------- | -------------------------------------------------------------
-Boot-Communication-1 | `Services`, `ports` and `devices` | Restrict the `services`, `ports` and `devices` to those used.
-
-Domain | `Command` name | _State_
--------------------------- | -------------- | ---------
-Boot-Communication-Flash-1 | `do_nand` | _Disable_
-
-Domain | `Config` name | `Value`
----------------------- | --------------------------------------- | ---------
-Boot-Consoles-Serial-1 | `CONFIG_SILENT_CONSOLE` | `Disable`
-Boot-Consoles-Serial-2 | `CONFIG_SYS_DEVICE_NULLDEV` | `Disable`
-Boot-Consoles-Serial-3 | `CONFIG_SILENT_CONSOLE_UPDATE_ON_RELOC` | `Disable`
-
-Domain | `Environment variable` name | _State_
----------------------- | --------------------------- | -------------
-Boot-Consoles-Serial-1 | `INC_DEBUG_PRINT` | _Not defined_
-
-Domain | `Config` name | _State_
--------------------------- | ---------------------------- | ---------
-Boot-Consoles-Variables-1 | `CONFIG_ENV_IS_IN_MMC` | `#undef`
-Boot-Consoles-Variables-2 | `CONFIG_ENV_IS_IN_EEPROM` | `#undef`
-Boot-Consoles-Variables-3 | `CONFIG_ENV_IS_IN_FLASH` | `#undef`
-Boot-Consoles-Variables-4 | `CONFIG_ENV_IS_IN_DATAFLASH` | `#undef`
-Boot-Consoles-Variables-5 | `CONFIG_ENV_IS_IN_FAT` | `#undef`
-Boot-Consoles-Variables-6 | `CONFIG_ENV_IS_IN_NAND` | `#undef`
-Boot-Consoles-Variables-7 | `CONFIG_ENV_IS_IN_NVRAM` | `#undef`
-Boot-Consoles-Variables-8 | `CONFIG_ENV_IS_IN_ONENAND` | `#undef`
-Boot-Consoles-Variables-9 | `CONFIG_ENV_IS_IN_SPI_FLASH` | `#undef`
-Boot-Consoles-Variables-10 | `CONFIG_ENV_IS_IN_REMOTE` | `#undef`
-Boot-Consoles-Variables-11 | `CONFIG_ENV_IS_IN_UBI` | `#undef`
-Boot-Consoles-Variables-12 | `CONFIG_ENV_IS_NOWHERE` | `#define`
-
-Domain | `Command` name | _State_
------------------------ | -------------- | ----------
-Boot-Consoles-MemDump-1 | `md` | _Disabled_
-Boot-Consoles-MemDump-2 | `mm` | _Disabled_
-Boot-Consoles-MemDump-3 | `nm` | _Disabled_
-Boot-Consoles-MemDump-4 | `mw` | _Disabled_
-Boot-Consoles-MemDump-5 | `cp` | _Disabled_
-Boot-Consoles-MemDump-6 | `mwc` | _Disabled_
-Boot-Consoles-MemDump-7 | `mdc` | _Disabled_
-Boot-Consoles-MemDump-8 | `mtest` | _Disabled_
-Boot-Consoles-MemDump-9 | `loopw` | _Disabled_
-
-Domain | `Config` name | `Value`
--------------------- | -------------- | --------------------------------------
-Kernel-General-MAC-1 | CONFIG_IP_NF_SECURITY | m
-Kernel-General-MAC-2 | CONFIG_IP6_NF_SECURITY | m
-Kernel-General-MAC-3 | CONFIG_EXT2_FS_SECURITY | y
-Kernel-General-MAC-4 | CONFIG_EXT3_FS_SECURITY | y
-Kernel-General-MAC-5 | CONFIG_EXT4_FS_SECURITY | y
-Kernel-General-MAC-6 | CONFIG_SECURITY | y
-Kernel-General-MAC-7 | CONFIG_SECURITY_SMACK | y
-Kernel-General-MAC-8 | CONFIG_TMPFS_XATTR | y
-
-Domain | `Config` name | `Value`
----------------------- | -------------- | -------
-Kernel-General-kexec-1 | `CONFIG_KEXEC` | `n`
-
-Domain | `Config` name | `Value`
---------------------------- | --------------- | -------
-Kernel-General-IPAutoConf-1 | `CONFIG_IP_PNP` | `n`
-
-Domain | `Config` name | `Value`
-------------------------------- | ----------------------- | -------
-Kernel-General-SysCtl_SysCall-1 | `CONFIG_SYSCTL_SYSCALL` | `n`
-
-Domain | `Config` name | `Value`
----------------------------- | --------------- | -------
-Kernel-General-LegacyLinux-1 | `CONFIG_USELIB` | `n`
-
-Domain | `Config` name | `Value`
---------------------------- | ------------------------------ | -------
-Kernel-General-FirmHelper-1 | `CONFIG_FW_LOADER_USER_HELPER` | `n`
-
-Domain | `Config` name | `Value`
----------------------------- | ---------------------- | -------
-Kernel-General-PanicOnOOPS-1 | `CONFIG_PANIC_ON_OOPS` | `y`
-
-Domain | `Config` name | `Value`
--------------------------- | -------------------- | -------
-Kernel-General-SocketMon-1 | `CONFIG_PACKET_DIAG` | `n`
-Kernel-General-SocketMon-2 | `CONFIG_UNIX_DIAG` | `n`
-
-Domain | `Config` name | `Value`
------------------------- | ---------------- | -------
-Kernel-General-BPF_JIT-1 | `CONFIG_BPF_JIT` | `n`
-
-Domain | `Config` name | `Value`
------------------------------- | ------------------------- | -------
-Kernel-General-ModuleSigning-1 | `CONFIG_MODULE_SIG_FORCE` | `y`
-
-Domain | `Variable` name | `Value`
------------------------------- | ------------------------- | -------
-Kernel-General-ModuleSigning-2 | `kernel.modules_disabled` | `1`
-
-Domain | Object | _State_
------------------------- | ------------------- | ----------
-Kernel-General-Drivers-1 | `USB` | _Disabled_
-Kernel-General-Drivers-2 | `PCMCIA` | _Disabled_
-Kernel-General-Drivers-3 | Other `hotplug` bus | _Disabled_
-
-Domain | `compiler` and `linker` options | _State_
--------------------------------- | ------------------------------- | --------
-Kernel-General-IndependentExec-1 | `-pie -fpic` | _Enable_
-
-Domain | `compiler` and `linker` options | _State_
---------------------------------- | ------------------------------- | --------
-Kernel-General-OverwriteAttacks-1 | `-z,relro` | _Enable_
-Kernel-General-OverwriteAttacks-2 | `-z,now` | _Enable_
-
-Domain | Object | Recommendations
-------------------------------- | --------------- | --------------------------------
-Kernel-General-LibraryLinking-1 | Dynamic linking | Should generally not be allowed.
-
-Domain | `Config` name | `Value`
------------------------------- | ---------------- | -------
-Kernel-Memory-RestrictAccess-1 | `CONFIG_DEVKMEM` | `n`
-
-Domain | `Config` name | `Value`
------------------------- | ------------------- | -------
-Kernel-Memory-CoreDump-1 | `CONFIG_PROC_KCORE` | `n`
-
-Domain | `Config` name | `Value`
--------------------- | ------------- | -------
-Kernel-Memory-Swap-1 | `CONFIG_SWAP` | `n`
-
-Domain | `Config` name | `Value`
------------------------------- | --------------------- | -------
-Kernel-Memory-LoadAllSymbols-1 | `CONFIG_KALLSYMS` | `n`
-Kernel-Memory-LoadAllSymbols-2 | `CONFIG_KALLSYMS_ALL` | `n`
-
-Domain | `Config` name | `Value`
---------------------- | -------------------------- | -------
-Kernel-Memory-Stack-1 | `CONFIG_CC_STACKPROTECTOR` | `y`
-
-Domain | `Config` name | `Value`
----------------------- | --------------- | -------
-Kernel-Memory-Access-1 | `CONFIG_DEVMEM` | `n`
-
-Domain | `Config` name | `Value`
------------------------------- | --------------------- | -------
-Kernel-Memory-CrossMemAttach-1 | `CROSS_MEMORY_ATTACH` | `n`
-
-Domain | `compiler` and `linker` options | _State_
------------------------------ | ------------------------------- | --------
-Kernel-Memory-StackSmashing-1 | `-fstack-protector-all` | _Enable_
-
-Domain | `compiler` options and `config` name | `Value`
-------------------------------- | ------------------------------------ | -------
-Kernel-Memory-BufferOverflows-1 | `-D_FORTIFY_SOURCE` | `2`
-Kernel-Memory-BufferOverflows-2 | `CONFIG_FORTIFY_SOURCE` | `y`
-
-Domain | `Config` name | `Value`
------------------------- | ---------------------------- | -------
-Kernel-Consoles-Serial-1 | `CONFIG_SERIAL_8250` | `n`
-Kernel-Consoles-Serial-2 | `CONFIG_SERIAL_8250_CONSOLE` | `n`
-Kernel-Consoles-Serial-3 | `CONFIG_SERIAL_CORE` | `n`
-Kernel-Consoles-Serial-4 | `CONFIG_SERIAL_CORE_CONSOLE` | `n`
-
-Domain | `Config` name | `Value`
------------------------------ | ------------------------- | -----------------------------------
-Kernel-Consoles-CommandLine-1 | `CONFIG_CMDLINE_BOOL` | `y`
-Kernel-Consoles-CommandLine-2 | `CONFIG_CMDLINE` | `"insert kernel command line here"`
-Kernel-Consoles-CommandLine-3 | `CONFIG_CMDLINE_OVERRIDE` | `y`
-
-Domain | `Config` name | `Value`
----------------------- | ------------- | -------
-Kernel-Consoles-KDBG-1 | `CONFIG_KGDB` | `n`
-
-Domain | `Config` name | `Value`
------------------------ | -------------------- | -------
-Kernel-Consoles-SysRQ-1 | `CONFIG_MAGIC_SYSRQ` | `n`
-
-Domain | `Config` name | `Value`
------------------------------- | -------------------- | -------
-Kernel-Consoles-BinaryFormat-1 | `CONFIG_BINFMT_MISC` | `n`
-
-Domain | `Config` name | `Value`
----------------------- | ------------------- | -------
-Kernel-Debug-Symbols-1 | `CONFIG_DEBUG_INFO` | `n`
-
-Domain | `Config` name | `Value`
----------------------- | ---------------- | -------
-Kernel-Debug-Kprobes-1 | `CONFIG_KPROBES` | `n`
-
-Domain | `Config` name | `Value`
----------------------- | --------------- | -------
-Kernel-Debug-Tracing-1 | `CONFIG_FTRACE` | `n`
-
-Domain | `Config` name | `Value`
------------------------- | ------------------ | -------
-Kernel-Debug-Profiling-1 | `CONFIG_OPROFILE` | `n`
-Kernel-Debug-Profiling-2 | `CONFIG_PROFILING` | `n`
-
-Domain | `Config` name | `Value`
------------------------- | ------------------------- | -------
-Kernel-Debug-OOPSOnBUG-1 | `CONFIG_DEBUG_BUGVERBOSE` | `n`
-
-Domain | `Config` name | `Value`
------------------- | --------------------- | -------
-Kernel-Debug-Dev-1 | `CONFIG_DEBUG_KERNEL` | `n`
-Kernel-Debug-Dev-2 | `CONFIG_EMBEDDED` | `n`
-
-Domain | `Config` name | `Value`
-------------------------- | ----------------- | -------
-Kernel-Debug-FileSystem-1 | `CONFIG_DEBUG_FS` | `n`
-
-Domain | `Config` name | `Value`
------------------- | ------------- | -------
-Kernel-Debug-BUG-1 | `CONFIG_BUG` | `n`
-
-Domain | `Config` name | `Value`
------------------------- | ----------------- | -------
-Kernel-Debug-CoreDumps-1 | `CONFIG_COREDUMP` | `n`
-
-Domain | `File` name | `Value`
----------------------------- | -------------------------------- | -------
-Kernel-Debug-AdressDisplay-1 | `/proc/sys/kernel/kptr_restrict` | `1`
-
-Domain | `File` or `Directorie` name | _State_
----------------------------- | --------------------------- | -----------------------------
-Kernel-Debug-AdressDisplay-1 | `/boot/vmlinuz*` | _Readable Only for root user_
-Kernel-Debug-AdressDisplay-2 | `/boot/System.map*` | _Readable Only for root user_
-Kernel-Debug-AdressDisplay-3 | `/sys/kernel/debug/` | _Readable Only for root user_
-Kernel-Debug-AdressDisplay-4 | `/proc/slabinfo` | _Readable Only for root user_
-
-Domain | `File` name | `Value`
--------------------- | --------------------------------- | -------
-Kernel-Debug-DMESG-1 | `/proc/sys/kernel/dmesg_restrict` | `1`
-
-Domain | `Config` name | `Value`
---------------------- | ----------------- | -------
-Kernel-Debug-Config-1 | `CONFIG_IKCONFIG` | `n`
-
-Domain | `Config` name | `Value`
------------------------- | --------------- | -------
-Kernel-FileSystems-NFS-1 | `CONFIG_NFSD` | `n`
-Kernel-FileSystems-NFS-2 | `CONFIG_NFS_FS` | `n`
-
-Domain | `Partition` | `Value`
--------------------------- | ------------------- | -----------------------------------------------------------------
-Kernel-FileSystems-Mount-1 | `/boot` | `nosuid`, `nodev` and `noexec`.
-Kernel-FileSystems-Mount-2 | `/var` & `/tmp` | In `/etc/fstab` or `vfstab`, add `nosuid`, `nodev` and `noexec`.
-Kernel-FileSystems-Mount-3 | _Non-root local_ | If type is `ext2` or `ext3` and mount point not '/', add `nodev`.
-Kernel-FileSystems-Mount-4 | _Removable storage_ | Add `nosuid`, `nodev` and `noexec`.
-Kernel-FileSystems-Mount-5 | _Temporary storage_ | Add `nosuid`, `nodev` and `noexec`.
-Kernel-FileSystems-Mount-6 | `/dev/shm` | Add `nosuid`, `nodev` and `noexec`.
-Kernel-FileSystems-Mount-7 | `/dev` | Add `nosuid` and `noexec`.
-
-Domain | `Config` name | _State_ or `Value`
--------------------------- | ----------------------- | -----------------------------------------------------------------------
-Kernel-FileSystems-Mount-1 | `CONFIG_DEVTMPFS_MOUNT` | _Disabled_ or add remount with `noexec` and `nosuid` to system startup.
-
-Domain | `Label` name | Recommendations
------------------- | ------------ | -----------------------------------------------------------
-Kernel-MAC-Floor-1 | `^` | Only for privileged system services.
-Kernel-MAC-Floor-2 | `*` | Used for device files or `/tmp` Access restriction via DAC.
-
-Domain | `Label` name | Recommendations
-------------------- | ---------------- | -------------------------------------------------------------------------------------------------------------
-Kernel-MAC-System-1 | `System` | Process should write only to file with transmute attribute.
-Kernel-MAC-System-2 | `System::run` | Files are created with the directory label from user and system domain (transmute) Lock is implicit with `w`.
-Kernel-MAC-System-3 | `System::Shared` | Files are created with the directory label from system domain (transmute) User domain has locked privilege.
-Kernel-MAC-System-4 | `System::Log` | Some limitation may impose to add `w` to enable append.
-Kernel-MAC-System-5 | `System::Sub` | Isolation of risky Subsystem.
-
-Domain | `Label` name | Recommendations
-------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------
-Kernel-MAC-System-1 | `User::Pkg::$AppID` | Only one Label is allowed per App. A data directory is created by the AppFw in `rwx` mode.
-Kernel-MAC-System-2 | `User::Home` | AppFw needs to create a directory in `/home/$USER/App-Shared` at first launch if not present with label app-data access is `User::App-Shared` without transmute.
-Kernel-MAC-System-3 | `User::App-Shared` | Shared space between all App running for a given user.
-
-Domain | Object | Recommendations
------------------- | -------------- | ------------------------------------
-Platform-SystemD-1 | Security model | Use Namespaces for containerization.
-Platform-SystemD-2 | Security model | Use CGroups to organise processes.
-
-Domain | Object | Recommendations
---------------- | -------------- | ------------------------------------
-Platform-DBus-1 | Security model | Use D-Bus as IPC.
-Platform-DBus-2 | Security model | Apply D-BUS security patches: [D-Bus CVE](https://www.cvedetails.com/vulnerability-list/vendor_id-13442/D-bus-Project.html)
-
-Domain | `Tool` name | _State_
--------------------- | ----------- | -------
-Platform-Utilities-1 | `connman` | _Used_ as a connection manager.
-Platform-Utilities-2 | `bluez` | _Used_ as a Bluetooth manager.
-Platform-Utilities-3 | `gstreamer` | _Used_ to manage multimedia file format.
-Platform-Utilities-4 | `alsa` | _Used_ to provides an API for sound card device drivers.
-
-Domain | Object | Recommendations
----------------------- | -------------- | --------------------------------
-Platform-AGLFw-AppFw-1 | Security model | Use the AppFw as Security model.
-
-Domain | Object | Recommendations
------------------------ | ----------- | -------------------------------------
-Platform-AGLFw-Cynara-1 | Permissions | Use Cynara as policy-checker service.
-
-Domain | `Tool` name | _State_
--------------------- | ----------- | ----------------------------------------------------------------------
-Platform-Utilities-1 | `busybox` | _Used_ to provide a number of tools. Do not compile development tools.
-
-Domain | `Utility` name and normal `path` | _State_
---------------------- | ---------------------------------------------------- | ----------
-Platform-Utilities-1 | `chgrp` in `/bin/chgrp` | _Disabled_
-Platform-Utilities-2 | `chmod` in `/bin/chmod` | _Disabled_
-Platform-Utilities-3 | `chown` in `/bin/chown` | _Disabled_
-Platform-Utilities-4 | `dmesg` in `/bin/dmesg` | _Disabled_
-Platform-Utilities-5 | `Dnsdomainname` in `/bin/dnsdomainname` | _Disabled_
-Platform-Utilities-6 | `dropbear`, Remove "dropbear" from `/etc/init.d/rcs` | _Disabled_
-Platform-Utilities-7 | `Editors` in (vi) `/bin/vi` | _Disabled_
-Platform-Utilities-8 | `find` in `/bin/find` | _Disabled_
-Platform-Utilities-9 | `gdbserver` in `/bin/gdbserver` | _Disabled_
-Platform-Utilities-10 | `hexdump` in `/bin/hexdump` | _Disabled_
-Platform-Utilities-11 | `hostname` in `/bin/hostname` | _Disabled_
-Platform-Utilities-12 | `install` in `/bin/install` | _Disabled_
-Platform-Utilities-13 | `iostat` in `/bin/iostat` | _Disabled_
-Platform-Utilities-14 | `killall` in `/bin/killall` | _Disabled_
-Platform-Utilities-15 | `klogd` in `/sbin/klogd` | _Disabled_
-Platform-Utilities-16 | `logger` in `/bin/logger` | _Disabled_
-Platform-Utilities-17 | `lsmod` in `/sbin/lsmod` | _Disabled_
-Platform-Utilities-18 | `pmap` in `/bin/pmap` | _Disabled_
-Platform-Utilities-19 | `ps` in `/bin/ps` | _Disabled_
-Platform-Utilities-20 | `ps` in `/bin/ps` | _Disabled_
-Platform-Utilities-21 | `rpm` in `/bin/rpm` | _Disabled_
-Platform-Utilities-22 | `SSH` | _Disabled_
-Platform-Utilities-23 | `stbhotplug` in `/sbin/stbhotplug` | _Disabled_
-Platform-Utilities-24 | `strace` in `/bin/trace` | _Disabled_
-Platform-Utilities-25 | `su` in `/bin/su` | _Disabled_
-Platform-Utilities-26 | `syslogd` in (logger) `/bin/logger` | _Disabled_
-Platform-Utilities-27 | `top` in `/bin/top` | _Disabled_
-Platform-Utilities-28 | `UART` in `/proc/tty/driver/` | _Disabled_
-Platform-Utilities-29 | `which` in `/bin/which` | _Disabled_
-Platform-Utilities-30 | `who` and `whoami` in `/bin/whoami` | _Disabled_
-Platform-Utilities-31 | `awk` (busybox) | _Enabled_
-Platform-Utilities-32 | `cut` (busybox) | _Enabled_
-Platform-Utilities-33 | `df` (busybox) | _Enabled_
-Platform-Utilities-34 | `echo` (busybox) | _Enabled_
-Platform-Utilities-35 | `fdisk` (busybox) | _Enabled_
-Platform-Utilities-36 | `grep` (busybox) | _Enabled_
-Platform-Utilities-37 | `mkdir` (busybox) | _Enabled_
-Platform-Utilities-38 | `mount` (vfat) (busybox) | _Enabled_
-Platform-Utilities-39 | `printf` (busybox) | _Enabled_
-Platform-Utilities-40 | `sed` in `/bin/sed` (busybox) | _Enabled_
-Platform-Utilities-41 | `tail` (busybox) | _Enabled_
-Platform-Utilities-42 | `tee` (busybox) | _Enabled_
-Platform-Utilities-43 | `test` (busybox) | _Enabled_
-
-Domain | Object | Recommendations
---------------------- | ---------------- | -----------------------------------------------------
-Platform-Users-root-1 | Main application | Should not execute as root.
-Platform-Users-root-2 | UI | Should run in a context on a user with no capability.
-
-Domain | `Utility` name | _State_
---------------------- | -------------- | -------------
-Platform-Users-root-3 | `login` | _Not allowed_
-Platform-Users-root-4 | `su` | _Not allowed_
-Platform-Users-root-5 | `ssh` | _Not allowed_
-Platform-Users-root-6 | `scp` | _Not allowed_
-Platform-Users-root-7 | `sftp` | _Not allowed_
-
-Domain | Object | Recommendations
--------------------------- | --------- | -----------------------------------------------------------------------
-Application-Installation-1 | AppFw | Provide offline-mode in order to install app with the base image.
-Application-Installation-2 | Integrity | Allow the installation of applications only if their integrity is good.
-
-Domain | Tech name | Recommendations
----------------------------------- | --------- | --------------------------------------------------------------------------
-Connectivity-BusAndConnector-Bus-1 | CAN | Implement hardware solution in order to prohibit sending unwanted signals.
-
-Domain | Tech name | Recommendations
------------------------------------------ | --------- | ----------------------------------------------------------------------
-Connectivity-BusAndConnector-Connectors-1 | USB | Must be disabled. If not, only enable the minimum require USB devices.
-Connectivity-BusAndConnector-Connectors-2 | USB | Confidential data exchanged with the ECU over USB must be secure.
-Connectivity-BusAndConnector-Connectors-3 | USB | USB Boot on a ECU must be disable.
-Connectivity-BusAndConnector-Connectors-4 | OBD-II | Must be disabled outside garages.
-
-Domain | Object | Recommendations
------------------------ | ------ | ------------------------------------------------------------------
-Connectivity-Wireless-1 | Update | Always follow the latest updates of remote communication channels.
-
-Domain | Tech name or object | Recommendations
----------------------------- | ------------------- | -------------------------------------------------------------------------
-Connectivity-Wireless-Wifi-1 | WEP, PSK, TKIP | Disabled
-Connectivity-Wireless-Wifi-2 | WPA2 and AES-CCMP | Used
-Connectivity-Wireless-Wifi-3 | WPA2 | Should protect data sniffing.
-Connectivity-Wireless-Wifi-4 | PSK | Changing regularly the password.
-Connectivity-Wireless-Wifi-5 | Device | Upgraded easily in software or firmware to have the last security update.
-
-Domain | Tech name | Recommendations
---------------------------------- | ------------- | ------------------------------------------------------------
-Connectivity-Wireless-Bluetooth-1 | BLE | Use with caution.
-Connectivity-Wireless-Bluetooth-2 | Bluetooth | Monitoring
-Connectivity-Wireless-Bluetooth-3 | SSP | Avoid using the "Just Works" association model.
-Connectivity-Wireless-Bluetooth-4 | Visibility | Configured by default as undiscoverable. Except when needed.
-Connectivity-Wireless-Bluetooth-5 | Anti-scanning | Used, inter alia, to slow down brute force attacks.
-
-Domain | Tech name | Recommendations
--------------------------------- | --------- | --------------------------
-Connectivity-Wireless-Cellular-1 | GPRS/EDGE | Avoid
-Connectivity-Wireless-Cellular-2 | UMTS/HSPA | Protected against Jamming.
-
-Domain | Tech name | Recommendations
------------------------------ | --------- | --------------------------------------------
-Connectivity-Wireless-Radio-1 | RDS | Only audio output and meta concerning radio.
-
-Domain | Tech name | Recommendations
---------------------------- | --------- | ------------------------------------------------------
-Connectivity-Wireless-NFC-1 | NFC | Protected against relay and replay attacks.
-Connectivity-Wireless-NFC-2 | Device | Disable unneeded and unapproved services and profiles.
-
-Domain | Object | Recommendations
----------------------------- | -------------- | --------------------------------------
-Application-Cloud-Download-1 | authentication | Must implement authentication process.
-Application-Cloud-Download-2 | Authorization | Must implement Authorization process.
-
-Domain | Object | Recommendations
----------------------------------- | ------------- | ----------------------------------------------------------
-Application-Cloud-Infrastructure-1 | Packet | Should implement a DPI.
-Application-Cloud-Infrastructure-2 | DoS | Must implement a DoS protection.
-Application-Cloud-Infrastructure-3 | Test | Should implement scanning tools like SATS and DAST.
-Application-Cloud-Infrastructure-4 | Log | Should implement security tools (IDS and IPS).
-Application-Cloud-Infrastructure-5 | App integrity | Applications must be signed by the code signing authority.
-
-Domain | Object | Recommendations
------------------------------ | ----------------------------------------- | ---------------------------------
-Application-Cloud-Transport-1 | Integrity, confidentiality and legitimacy | Should implement IPSec standards.
-
-# Todo notes
-
-Domain | Improvement
---------------- | ----------------------------------------------------
-Boot-Abstract-1 | More generic and add examples (The chain of trust).
-
-Domain | Improvement
---------------- | -------------------------------------------
-Boot-Abstract-1 | Review the definition of the "boot loader".
-
-Domain | Improvement
---------------- | ------------------------------------
-Boot-Consoles-1 | Secure loader: No reference earlier?
-
-Domain | Improvement
---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
-Hypervisor-Abstract-1 | Complete Hypervisor part ([jailhouse](https://github.com/siemens/jailhouse) / [KVM](https://www.linux-kvm.org/page/Main_Page) / [Xen](https://www.xenproject.org/developers/teams/embedded-and-automotive.html)).
-
-Domain | Improvement
--------------------------------- | -----------------------------
-Kernel-General-IndependentExec-1 | Kernel or/and platform part ?
-
-Domain | Improvement
-------------------------------- | ---------------
-Kernel-General-LibraryLinking-1 | Keep this part?
-
-Domain | Improvement
-------------------- | --------------------------------
-Platform-Abstract-1 | Create a graphics and sound part.
-
-Domain | Improvement
-------------------- | -----------
-Platform-Services-1 | SystemD ?
-Platform-Services-2 | Secure daemon ?
-
-Domain | Improvement
------------------------------ | ------------------------
-Platform-Users-Capabilities-1 | Kernel or Platform-user?
-Platform-Users-Capabilities-2 | Add config note.
-
-Domain | Improvement
--------------------------- | ------------------------------
-Application-Installation-1 | Talk about AppFw offline mode.
-
-Domain | Improvement
------------------------ | ----------------------------------------------------------
-Application-Signature-1 | Add content (see secure build in Secure development part).
-
-Domain | Improvement
----------------------- | ------------
-Application-Services-1 | Add content (Which services?).
-Application-Services-2 | Add Binder.
-
-Domain | Improvement
------------------------ | -----------------
-Connectivity-Abstract-1 | Improve abstract.
-
-Domain | Improvement
------------------------ | -------------------------------------------
-Connectivity-Wireless-1 | Add communication channels (RFID, ZigBee?).
-
-Domain | Improvement
-------------- | -----------------
-Update-SOTA-1 | Part to complete.
-
-Domain | Improvement
------------------------ | ------------
-SecureDev-SecureBuild-1 | Add content.
-
-Domain | Improvement
----------------------- | ------------
-SecureDev-Signatures-1 | Add content.
-
-Domain | Improvement
---------------------- | -----------------------------------------------------
-SecureDev-CodeAudit-1 | Add CVE analyser.
-SecureDev-CodeAudit-2 | [OSSTMM](http://www.isecom.org/mirror/OSSTMM.3.pdf). \ No newline at end of file
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/images/App-flow.png b/docs/2_Architecture_Guides/2_Security_Blueprint/images/App-flow.png
deleted file mode 100644
index 7b87c29..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/images/App-flow.png
+++ /dev/null
Binary files differ
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/images/App_signing_flow.png b/docs/2_Architecture_Guides/2_Security_Blueprint/images/App_signing_flow.png
deleted file mode 100644
index 56a7c23..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/images/App_signing_flow.png
+++ /dev/null
Binary files differ
diff --git a/docs/2_Architecture_Guides/2_Security_Blueprint/images/WhiteBoxArchi.png b/docs/2_Architecture_Guides/2_Security_Blueprint/images/WhiteBoxArchi.png
deleted file mode 100644
index d984d1a..0000000
--- a/docs/2_Architecture_Guides/2_Security_Blueprint/images/WhiteBoxArchi.png
+++ /dev/null
Binary files differ