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

2 files changed, 48 insertions, 0 deletions

diff --git a/security-blueprint/part-6/0_Abstract.md b/security-blueprint/part-6/0_Abstract.md
index b8aabb6..3617dbd 100644
--- a/security-blueprint/part-6/0_Abstract.md
+++ b/security-blueprint/part-6/0_Abstract.md
@@ -11,6 +11,54 @@ anything which is not in the core Operating System (OS) is an Application.
 Applications can be included in the base software package (image) or can be
 added at run-time.
 
+Application containment is achieved using the following protections:
+
+- Linux Native protection
+  - Mandatory Access Control (**MAC**)
+- AGL Platform protections
+  - Origin Tracking and Validation
+  - Application Privilege Management and Enforcement via Cynara
+  - Authenticated Transport via D-Bus
+
+## Application Types
+
+AGL provides a framework for applications to be written in different forms:
+
+- Web application: HTML5 + JavaScript
+- Qt application: in a QML file
+- Native application: in C
+
+While there is no harm in providing multiple types of applications, from a
+security perspective this does increase the attack surface for an intruder.
+The application framework (**AppFw**) consists of a number of utilities and
+daemons which provide context for the applications.
+Isolation is provided through **SMACK** labels.
+
+## Application Store
+
+Although the Tizen system has defined a [system of App signing and signing flow](https://wiki.tizen.org/Security/Tizen_3.X_Overview#Application_Singing_and_Certificates)
+to avoid the spread of unauthorized Apps that might contain malware.
+At this point, it is unclear how much of this flow AGL will adopt.
+However, judging from the experience, it is an essential topic. For example,
+the Google Play Store controls the authorization of Apps through signing, and still,
+there are [many accounts of Apps containing malware on the store](http://www.eweek.com/mobile/researchers-find-132-malware-infected-android-apps-on-google-play).
+
+Tizen defines 5 levels of certificates and signing at each level, including an author,
+testing distributor, public level store distributor, partner level store distributor,
+and platform level store distributor. AGL may define a different number of third parties,
+but at a minimum an author and store distributor should be defined.
+
+![App Signing Flow](App_signing_flow.png)
+
+Once the number of signatures has been established, verification of those signatures needs
+to be done at a minimum at installation time on the AGL device. It is important to ensure
+the robustness/integrity of the public key used for signature verification. If the public key is modified,
+then this compromised key can be used to verify an attacker's private key signature.
+
+Further to this, installation-time verification is limited. Attacks can happen to apps in-memory
+at runtime. Any modifications made after installation will be missed by installation-time verification.
+Integrity verification that runs during execution makes for a more complete security story.
+
 --------------------------------------------------------------------------------
 
 ## Acronyms and Abbreviations
diff --git a/security-blueprint/part-6/App_signing_flow.png b/security-blueprint/part-6/App_signing_flow.png
new file mode 100644
index 0000000..56a7c23
--- /dev/null
+++ b/security-blueprint/part-6/App_signing_flow.png