3 files changed, 85 insertions, 0 deletions
diff --git a/security-blueprint/part-8/0_Abstract.md b/security-blueprint/part-8/0_Abstract.md
new file mode 100644
index 0000000..daeaa6f
--- /dev/null
+++ b/security-blueprint/part-8/0_Abstract.md
@@ -0,0 +1,22 @@
+# Part 8 - Update (**OTA**)
+
+## Abstract
+
+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 divert its first use, 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.
+
+--------------------------------------------------------------------------------
+
+## 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
+_OTA_                     | **O**ver **T**he **A**ir
+_SOTA_                    | **S**oftware **O**ver **T**he **A**ir
diff --git a/security-blueprint/part-8/1-FOTA.md b/security-blueprint/part-8/1-FOTA.md
new file mode 100644
index 0000000..a65a239
--- /dev/null
+++ b/security-blueprint/part-8/1-FOTA.md
@@ -0,0 +1,51 @@
+# 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.
+The principle of verifying chain integrity fulfills much of AGL's security.
+During a firmware update, it is necessary to update the different signatures to
+check the integrity of the system.
+
+There is also the constraint of the update time: The system must start quickly
+and therefore, update itself as quickly. We imagine that the **FOTA** is mainly
+used in the vehicle maintenance session (e.g. Garage). We will then use no more
+ **FOTA** but a wired update. There is a limit to what can be updated wirelessly.
+ This maintenance update could solve these problems.
+
+Field upgrades can be achieved securely by using a Secure Loader. This loader
+will authenticate an incoming image (USB, Serial, Network) prior to writing it
+to the flash memory on the device. It should not be possible to write to flash
+from bootloader (U-Boot). Note that because USB support is to be disabled within
+the sboot/U-Boot code, the board specific implementation of the Secure Loader
+will have to manage the entire USB initialization, enumeration, and read/write
+access to the mass storage device.
+
+<!-- config -->
+
+Domain        | Object                                    | Recommendations
+------------- | ----------------------------------------- | ---------------
+Update-FOTA-1 | Integrity, confidentiality and legitimacy | Must be secure.
+
+<!-- endconfig -->
+
+Different possible type of **FOTA**:
+
+- Package-based like rpm, dpkg:
+
+  - `+` Simple.
+  - `-` Power-off.
+  - `-` Dependency.
+
+- Full file system updates:
+
+  - `+` Robust.
+  - `-` Tends device-specific.
+  - `-` Need rsync or similar.
+
+- Atomic differential:
+
+  - `+` Robust.
+  - `+` Minimal bandwidth consumption.
+  - `+` Easy reusable.
+  - `-` Physically one file system (Corruption -> unbootable system).
+  - `-` No rollback logic.
diff --git a/security-blueprint/part-8/2-SOTA.md b/security-blueprint/part-8/2-SOTA.md
new file mode 100644
index 0000000..287a91a
--- /dev/null
+++ b/security-blueprint/part-8/2-SOTA.md
@@ -0,0 +1,12 @@
+# Software Over The Air
+
+**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).
+
+<!-- todo -->
+
+Domain        | Improvement
+------------- | -----------------
+Update-SOTA-1 | Part to complete.
+
+<!-- endtodo -->