fix markdown sec-blueprint

Signed-off-by: Ronan <ronan.lemartret@iot.bzh>

1 files changed, 122 insertions, 104 deletions

diff --git a/sec-blueprint/05-security-concepts.md b/sec-blueprint/05-security-concepts.md
index 114bc8b..5ddfe5b 100644
--- a/sec-blueprint/05-security-concepts.md
+++ b/sec-blueprint/05-security-concepts.md
@@ -16,13 +16,17 @@ layout: techdoc
 ## Security Principles
 When connecting a car to the internet, not only we create a mobile entry
 point to our private life, we also relocate our entry doors anywhere in
-the world. Neither all places on this planet are nice nor safe, nor are
-the people. The locks and alarms on cars, will give only a fake
+the world.
+
+Neither all places on this planet are nice nor safe, nor are
+the people.  
+The locks and alarms on cars, will give only a fake
 impression of security once that internet connection has entered the
 place.
 
 Internet enables the worse of human side to get access to private
-domains. If we are not careful, it will likely be invaded in a very
+domains.  
+If we are not careful, it will likely be invaded in a very
 short time following connection..
 
 **So, connected cars security must be designed as a military vehicle
@@ -30,7 +34,8 @@ which would be deployed in a high risk zone even when designing cars for
 out towns and villages**:
 
 -   Physical access to the car should not be a white card to hack
-    the system. Most cars sleep in the streets and public car parks where physical
+    the system.  
+    Most cars sleep in the streets and public car parks where physical
     accessibility is easy.
 -   Known defect should be corrected by SW update in real time, without a return to
     home or garage.
@@ -40,8 +45,8 @@ out towns and villages**:
 -   Connectivity between the various domains should be restricted to the
     minimal set required for their operation.
 -   Software loaded in cars and in the cloud should be vetted in
-    accordance with its capability to access critical resources. The
-    vetting authority must be controllable, enforceable and revocable.
+    accordance with its capability to access critical resources.  
+    The vetting authority must be controllable, enforceable and revocable.
 -   Inside each domain, sub domains should be created to limit even
     more, the nuisances capabilities of a successful malicious code.
 -   Software or devices not wetted should never be able to access any
@@ -52,52 +57,56 @@ authorise is strictly forbidden”,also known as ‘white listing’ policy.**
 
 We all understand those concepts, and nevertheless reports still show
 that very little people care about implementing protection against those
-risks yet. As a consequence most Connected Car projects are coming on
-the market with major security holes. It will take some time *(and
-likely some catastrophes)* for the Automotive Industry to clean up the
+risks yet.  
+As a consequence most Connected Car projects are coming on
+the market with major security holes.  
+It will take some time *(and likely some catastrophes)* for the Automotive Industry to clean up the
 pre-cyber security awareness designed products.
 
 The complexity induced by a security framework requires serious effort
-on the design side and complexifies the code execution. Fortunately our
-modern CPUs, which are very fast and ernergy efficient, can reduce this overhead
+on the design side and complexifies the code execution.  
+Fortunately our modern CPUs, which are very fast and ernergy efficient, can reduce this overhead
 to very acceptable extra work load on the computing and energy
 sub-systems.
 
 The challenge of Connected Cars is very similar to embedded devices
-in general. Within AGL we are defining solutions, which can enable this
+in general.  
+Within AGL we are defining solutions, which can enable this
 new market to emerge without requiring each product design to be
-chaperoned by security experts. *The world does not hold enough security
-experts to even overview even a few percent of the projects that are required
+chaperoned by security experts.  
+*The world does not hold enough security experts to even overview even a few percent of the projects that are required
 to create all connected devices that will be launched in the next 10
 years.*
 
 If embedded developers must implement complex security models
 without, having neither the time nor the skills, to architecture them
 correctly, *they can only succeed by reusing ready made trusted
-solutions*. Fortunately Connected Cars are based on some flavour of
+solutions*.  
+Fortunately Connected Cars are based on some flavour of
 Linux operating system which has, due to its long serving years in many
 critical domains, a large offering of security options.
 
 AGL only focus on the security facilities offered under
-Linux operating system for the connected car market.
+Linux operating system for the connected car market.  
 Non Linux Operating systems which can also be present in a connected car, are not covered by AGL platform security model.
 
 ## Strategy
-There is no miracle solution. When deciding which security strategy, you
+There is no miracle solution.  
+When deciding which security strategy, you
 will need, first to try to evaluate all the possible attack vectors,
 then to define your priorities and your limits.
 
 Even if today complexity is mostly in the software (SW), we still need
-some hardware (HW) to run it. Securing the HW is a very complex task
-which fortunately is likely yet not required for Connected Cars. I will
-not open more the topic here. Nevertheless applying a healthy design
-attitude by reducing obvious direct risk vectors (debug serial connector
+some hardware (HW) to run it.  
+Securing the HW is a very complex task which fortunately is likely yet not required for Connected Cars.  
+I will not open more the topic here.  
+Nevertheless applying a healthy design attitude by reducing obvious direct risk vectors (debug serial connector
 wired in production, tracks with clear communication channel easy
 accessible on PCB, …) should be done.
 
 Would your automotive project requires a more protected HW, you will
-find plenty of literature on that topic. I personally like this
-relatively old (2004) paper from J Grand as an introduction to the
+find plenty of literature on that topic.  
+I personally like this relatively old (2004) paper from J Grand as an introduction to the
 domain.  
 http://www.grandideastudio.com/wp-content/uploads/secure\_embed\_paper.pdf
 
@@ -110,21 +119,22 @@ On the SW side, the most efficient model is to work by layer :
     requires more than a simple trusted boot.  
     A strategy to control the integrity of the software and its
     configuration is required.
--   Be able to change (upgrade) the software to correct a newly
-    discovered risk.  
-    Assuming that the system will never be broken is an utopia. The
-    right strategy is to plan how to recover from the discovering of a
+-   **Be able to change (upgrade) the software to correct a newly
+    discovered risk.**  
+    Assuming that the system will never be broken is an utopia.  
+    The right strategy is to plan how to recover from the discovering of a
     new security issue to avoid its propagation.  
     *This upgrade mechanism must be particularly solid has it has to be
     capable of being executed on a compromised system without the
     support of a skilled operator.*
 -   **Only select trusted Linux drivers.**  
     In Linux, drivers are executed with the same privilege level than
-    the Kernel itself. I short a malicious or hacked driver is an
-    uncontrolled open door to the hart of the system. Only vetted driver
-    should be used and any complexity unique to the platform should be
-    pushed in the user space domain. This remark is particularly
-    important when introducing drivers that are connecting with the
+    the Kernel itself.  
+    I short a malicious or hacked driver is an
+    uncontrolled open door to the hart of the system.  
+    Only vetted driver should be used and any complexity unique to the platform should be
+    pushed in the user space domain.  
+    This remark is particularly important when introducing drivers that are connecting with the
     outside world.  
     Ideally dynamic driver integration after boot should be banned even
     if that would limit the flexibility of hot plug for USB devices.  
@@ -134,19 +144,20 @@ On the SW side, the most efficient model is to work by layer :
     https://www.isoc.org/isoc/conferences/ndss/11/pdf/3\_1.pdf
 -   **Isolate the core of the system from the middleware.**  
     By default the protection on Unix type systems (and so Linux) is
-    done by allocating the user a set of access rights. The side effect
-    is that any code running under a given name can access all the
-    resources that is given to that user. Furthermore it is possible at
-    any time to further expend this access to other users. *As most of
-    code in traditional embedded software run with the Administrator
+    done by allocating the user a set of access rights.  
+    The side effect is that any code running under a given name can access all the
+    resources that is given to that user.  
+    Furthermore it is possible at any time to further expend this access to other users.  
+    *As most of code in traditional embedded software run with the Administrator
     privilege (root) we foresee the danger of this traditional
-    embedded model. Fortunately Linux provides a Security model
-    called LSM.* (
+    embedded model.  
+    Fortunately Linux provides a Security model called LSM.* (
     https://en.wikipedia.org/wiki/Linux\_Security\_Modules)  
     It allows to create an access strategy which is not controlled by
-    the user but rather by the system configuration. Multiple front end
-    are available to control LSM and that will be studied a bit later in
-    this paper. This allows to create a Mandatory Access Control (MAC)
+    the user but rather by the system configuration.  
+    Multiple front end are available to control LSM and that will be studied a bit later in
+    this paper.  
+    This allows to create a Mandatory Access Control (MAC)
     which is a powerful tools to avoid compromised code to gain access
     to extra resources to propagate further.  
     Other restriction based on the c-groups, the Posix capabilities and
@@ -156,15 +167,16 @@ On the SW side, the most efficient model is to work by layer :
     IoS and Android phones have initiated the Apps model and nowadays
     launching a product which cannot be extended by Apps (from a closed
     or open Store) after the creation of the device is a risky
-    marketing strategy. While the model of Apps loaded from an open
-    store is reserved to a very small category of mass consumer devices,
+    marketing strategy.  
+    While the model of Apps loaded from an open store is reserved to a very small category of mass consumer devices,
     the capability to load Apps after the creation of the initial SW is
     a very attractive way to reduce the time to market as well as the
     reaction time to changing market demand.  
     In particular it would allow car manufacturers, to customise the car
     SW, individually on the production line, to the buyer wish.  
     *By design Apps are created with a quite loose coupling with the
-    core SW. The default Linux DAC (Discretionary Access Model) is not
+    core SW.  
+    The default Linux DAC (Discretionary Access Model) is not
     the most reliable for limiting the access to the system capabilities
     to the minimum required.*  
     Associating the validation of the origin of an App to the resource
@@ -214,28 +226,29 @@ device, is the expected one.
 ## Read Only root file system.
 
 In most embedded system the core OS is under control of the device
-manufacturer. *A very simple and efficient way to limit opportunities to
+manufacturer.  
+*A very simple and efficient way to limit opportunities to
 get the core OS and middle-ware to be modified by a malicious code, is
-to store it on a read only partition*. Even if that is not 100%
-bulletproof it seriously complexifies the level of required knowledge to
+to store it on a read only partition*.  
+Even if that is not 100% bulletproof it seriously complexifies the level of required knowledge to
 break into the OS and greatly eases, the implementation of a recovery
 strategy.
 
 In order to enable some local persistent changes such as those required
 to register some network or locale configurations, an overlay can be
-created for some directories. Since Linux 4.0, the kernel supports by
-default OverlayFS which provides that facility and support the extended
+created for some directories.  
+Since Linux 4.0, the kernel supports by default OverlayFS which provides that facility and support the extended
 file attributes required by file base MAC such as SELinux and Smack.  
 https://github.com/torvalds/linux/commit/e9be9d5e76e34872f0c37d72e25bc27fe9e2c54c
 
 ## Code Integrity during execution
 
 In the embedded world it is quite acceptable to restrict the end user to
-operate the system as designed. We can take profit of this favorable
-position, to limit the capabilities of a malicious applications to
+operate the system as designed.  
+We can take profit of this favorable position, to limit the capabilities of a malicious applications to
 change our Operating System (OS) after the protected initialisation
-(trusted boot). This can be done *by activating an integrity enforcement
-such as IMA/EVM on all the core OS.*  
+(trusted boot).  
+This can be done *by activating an integrity enforcement such as IMA/EVM on all the core OS.*  
 http://sourceforge.net/p/linux-ima/wiki/Home/
 
 In short IMA allows the kernel to check that a file has not been changed
@@ -248,8 +261,9 @@ Two types of labels are available :
 -   simple
 
 The signed labels are reserved for code or data which are static and
-provide the best level of protection. The signing tool remains external
-of the device. The simple hashes are reserved for code which can be
+provide the best level of protection.  
+The signing tool remains external of the device.  
+The simple hashes are reserved for code which can be
 install dynamically and the hash can be recalculated on the fly by the
 OS providing a lesser level of protection.
 
@@ -261,7 +275,8 @@ in the HW security sub-system.
 ## Update and Ugrade
 
 The integrity enforcement does not allow immutable files to be updated
-on line. The Integrity system would detect the violation and block any
+on line.  
+The Integrity system would detect the violation and block any
 further reading of such file.
 
 *The update solution must cater with this constrain and must be
@@ -272,8 +287,8 @@ on the entire core OS, generally just before a reboot..*
 
 Connected Cars are comparable to middle volume consumer managed products
 (very similar to connected TV), by this, I mean, product where the
-software is entirely provided by the device manufacturer. The main side
-effects are well known :
+software is entirely provided by the device manufacturer.  
+The main side effects are well known :
 
 -   low cost and small CPU
 -   high control of the OS and Middleware loaded on the box
@@ -284,63 +299,66 @@ effects are well known :
 -   No recovery console.
 
 For those reasons, a solution like Smack has been selected by AGL as the
-best suited LSM front end. Furthermore, its adoption on Tizen by Samsung
+best suited LSM front end.  
+Furthermore, its adoption on Tizen by Samsung
 for delivering millions of Smart TVs enable an active community focussed
 on keeping good performance on smaller CPUs.  
 <https://wiki.tizen.org/wiki/Category:Security>
 
 ## Applications
-*Apps are the weak security vector in many modern system.* Car
-manufacturers need to add bespoke/localised App developers in order to
-make their product commercially attractive. It is a fast moving world
-very different to the use and habits of the Automotive industry.
+*Apps are the weak security vector in many modern system.*  
+Car manufacturers need to add bespoke/localised App developers in order to
+make their product commercially attractive.  
+It is a fast moving world very different to the use and habits of the Automotive industry.
 
-Defining the right level of App vetting is a real challenge. A quick
-reality check on markets where Apps exist, such as Mobile, Smart TV or
+Defining the right level of App vetting is a real challenge.  
+A quick reality check on markets where Apps exist, such as Mobile, Smart TV or
 Smart Watches, show that the detection of roke Apps is very complex
 already on platforms that impose the execution via a Virtual Machine, so
 we can imagine what is the complexity, when native code support is
 required in order to run on very small CPU.
 
-**As we cannot fully trust Apps, we have to contain them**. This can be
-done by :
+**As we cannot fully trust Apps, we have to contain them**.  
+This can be done by :
 
 -   Limiting Apps download origin to trusted ones.
 -   Restrict Apps privileges, resources and APIs access to what is
     explicitly authorised
 -   Isolate Apps runtime
 
-Restricting Apps origin to trusted source is quite simple. The simple
-use of a certificate to validate the App signature is a powerful model
+Restricting Apps origin to trusted source is quite simple.  
+The simple use of a certificate to validate the App signature is a powerful model
 when associated with an installer code which cannot be called via a back
-door. A simple model consists in separating the download process and
+door.  
+A simple model consists in separating the download process and
 exposed (UX, connected) from the installer code which can validate the
 App origin and installation in a isolated process with a lower surface
 of attack.
 
 Restricting Apps privileges requires first to know what are the
-requested and authorised privileges. The granularity of these
-privileges, must offer a good flexibility while remains simple, to be
-understood by the developers and the user. The compromise will depend of
-the target audience. The current return of experience from Android and
-Tizen, tend to reduce the list of privileges to a shorter list rather
-than in opposite. The creation of goup or App class is an other valid
-model.
+requested and authorised privileges.  
+The granularity of these privileges, must offer a good flexibility while remains simple, to be
+understood by the developers and the user.  
+The compromise will depend of the target audience.   
+The current return of experience from Android and Tizen, tend to reduce the list of privileges to a shorter list rather
+than in opposite.  
+The creation of goup or App class is an other valid model.
 
 The list of requested privileges will be associated to the App in a
-Manifest. A practical extra validation of the requested privileges can
+Manifest.  
+A practical extra validation of the requested privileges can
 be done depending of the App origin and signature level (e.g.
 Manufacturer, Partner and Community stores).
 
 The association between the App and its privileges list must be kept
-safe and available for enforcement in the system. The Samsung originated
-Open Source project Cynera (https://github.com/Samsung/cynara) provides
+safe and available for enforcement in the system.  
+The Samsung originated Open Source project Cynera (https://github.com/Samsung/cynara) provides
 such service and is optimised for execution on small SoC.
 
 Isolating the App when running is the most challenging task, it requires
 to let the App access enough of the system to execute its task but no
-more, to mitigate any malicious activity. One model to address this
-challenge consist in slicing the access to the system :
+more, to mitigate any malicious activity.  
+One model to address this challenge consist in slicing the access to the system :
 
 -   CPU, RAM
 -   devices
@@ -362,28 +380,29 @@ isolation via creation of different security context but adds the
 concept of authentication which limit attack through man-in-the-middle
 *https://en.wikipedia.org/wiki/Man-in-the-middle\_attack*.
 
-The control of Libraries and system API usage is far more complex. MAC
-advanced usages can help in this domain but Seccomp-BPF can go further.
+The control of Libraries and system API usage is far more complex.  
+MAC advanced usages can help in this domain but Seccomp-BPF can go further.  
 Seccomp which is an upstream feature of the Linux kernel is used by
 Mozilla and Chrome in their browsers and enable a low level protection
-solution. Seccomp can quickly induce a performance hit and access rules
+solution.  
+Seccomp can quickly induce a performance hit and access rules
 must remain simple.  
 The following page provides interserting reports on performance cost of
 that feature. (https://wiki.tizen.org/wiki/Security:Seccomp) for one
 system.
 
-###Name spaces
+### Name spaces
 
-Containers have made Linux name spaces visible to the mass. They are
-very popular and unfortunately often confused with security enforcement
+Containers have made Linux name spaces visible to the mass.  
+They are very popular and unfortunately often confused with security enforcement
 due to their common use as light virtualisation solution in the cloud.
 
 Whichever model of container is referenced, they all use the Linux
 various name spaces
-(http://man7.org/linux/man-pages/man7/namespaces.7.html). The general
-idea is to share a common kernel and to let each containers run its own
-virtual Linux user space and middleware. With the increased CPU
-performance and the facility provided by novel filesystem architectures
+(http://man7.org/linux/man-pages/man7/namespaces.7.html).  
+The general idea is to share a common kernel and to let each containers run its own
+virtual Linux user space and middleware.  
+With the increased CPU performance and the facility provided by novel filesystem architectures
 such as overlayfs, the files and code which happen to be unchanged
 between different containers can even remain shared transparently on
 disk and in RAM, enabling the use of containers for single App in the
@@ -395,7 +414,7 @@ between themselves, it must remain present to the designer that :
 -   kernel is shared and security weaknesses and zero day defects can be
     used to cross domains.
 -   As each container can provides its own version of the middleware,
-    upgrading the system is not enough to correct known security issues.
+    upgrading the system is not enough to correct known security issues.  
     Each container must individually be updated.
 -   Due to the transparent overlay model sharing files between
     containers, predicting the actually used disk space is challenging.
@@ -409,13 +428,13 @@ Automotive domain :
 -   Easing development
 
 The isolation model is very interesting when multiple service providers
-needs to share the same embedded device. A commonly listed use case, is
-the sharing of an IVI system with games or cloud multimedia services.
+needs to share the same embedded device.  
+A commonly listed use case, is the sharing of an IVI system with games or cloud multimedia services.
 
-The ease of development, is potentially even more valuable. One of the
-challenge faced by the embedded SW industry is the lack of skilled
-embedded software developers. *Enabling web and traditional IT
-programmers to work in a known environment and to run their App on an
+The ease of development, is potentially even more valuable.  
+One of the challenge faced by the embedded SW industry is the lack of skilled
+embedded software developers.  
+*Enabling web and traditional IT programmers to work in a known environment and to run their App on an
 IoT device without requiring to become an embedded SW expert would be of
 a high value*.
 
@@ -439,8 +458,7 @@ few base concepts enforced:
     never work.
 -   SW must be written secured first time, as late adaptation is
     too difficult.
-
-*Underestimating the resistance of the developer team is a common
-mistake which can lead to massive over costs and delays. *Implication of
-the right expert and management drive from the beginning is a
+- Underestimating the resistance of the developer team is a common
+mistake which can lead to massive over costs and delays.
+- Implication of the right expert and management drive from the beginning is a
 requirement that cannot be negotiated.