summaryrefslogtreecommitdiffstats
path: root/sec-blueprint/03-security-concepts.md
diff options
context:
space:
mode:
authorDominig ar Foll <dominig.arfoll@fridu.net>2016-11-12 17:24:32 +0100
committerDominig ar Foll <dominig.arfoll@fridu.net>2016-11-12 17:24:32 +0100
commit80c4f874dcf204f077f55b7a3b3f457aceeb7839 (patch)
tree11717ede75987051263ea0b4c6a7e713010d81dd /sec-blueprint/03-security-concepts.md
parentd4ec4803980d217cb69725835afb3fbb7e017300 (diff)
initial version of the AGL security blue print Chap 1,2, and 3
Signed-off-by: Dominig ar Foll <dominig.arfoll@fridu.net>
Diffstat (limited to 'sec-blueprint/03-security-concepts.md')
-rw-r--r--sec-blueprint/03-security-concepts.md423
1 files changed, 422 insertions, 1 deletions
diff --git a/sec-blueprint/03-security-concepts.md b/sec-blueprint/03-security-concepts.md
index af50a8c..114bc8b 100644
--- a/sec-blueprint/03-security-concepts.md
+++ b/sec-blueprint/03-security-concepts.md
@@ -14,12 +14,433 @@ layout: techdoc
{:toc}
## 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
+impression of security once that internet connection has entered the
+place.
-## Access Control
+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
+short time following connection..
+
+**So, connected cars security must be designed as a military vehicle
+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
+ accessibility is easy.
+- Known defect should be corrected by SW update in real time, without a return to
+ home or garage.
+- A separation of functionalities in isolated domains should allow the
+ car to remain safe and operational by limiting the contamination,
+ would a malicious SW succeed to pass the protections.
+- 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.
+- 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
+ critical resources.
+
+**The strategy can be summarise as “anything, which is not explicitly
+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
+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
+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
+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
+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
+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.
+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
+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
+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
+domain.
+http://www.grandideastudio.com/wp-content/uploads/secure\_embed\_paper.pdf
+
+On the SW side, the most efficient model is to work by layer :
+
+- **be sure that the desired SW is loaded**
+ On non connected devices, a trusted boot is considered a valid
+ enough solution, but Connected Cars requirement to enable
+ applications be added after the initial equipment provisioning,
+ 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
+ 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
+ outside world.
+ Ideally dynamic driver integration after boot should be banned even
+ if that would limit the flexibility of hot plug for USB devices.
+ Solutions to reinforce the Linux Kernel integrity during execution,
+ can be activated but they are an order of magnitude more complex to
+ activate than keeping bespoke logic in user space.
+ 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
+ privilege (root) we foresee the danger of this traditional
+ 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)
+ 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
+ the Seccomp can used in addition to LSM to further mitigate
+ the risks.
+- **Isolate Applications**
+ 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,
+ 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
+ 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
+ that such App can claim access, with the enforcement of restriction
+ in accessing the system resources to those explicitly granted, is a
+ far more reliable approach.
+- **Private data protection**
+ *Cars know a lot about us, from where we go, to who we call, who get
+ in our car (via the phone detection) and hold data that we are not
+ willing to let go in the Open without our explicit consent.*
+ This creates three main families of requirements :
+
+ - Requires a safe provisioning of new devices and App in the
+ system (know who is who and who does what. )
+ - Enforce encryption to any traffic going out.
+ - Enforce encryption on local storage for personal data to
+ mitigate off line attack risk.
+ - Enforce isolation of devices own by multiple users that connect
+ to the car.
## Secure Boot
+The trusted or secured boot is a facility offered by most Systems on Chip (SoC)
+which enforces :
+
+- booting the system in a known state
+ (e.g. all the RAM set to "0", all internal peripherals set
+ to silent)
+- providing a validation that the loaded initial code is signed by a
+ valid authority
+ (in short the SW is really coming from a known valid source).
+
+As the feature is very closed to the HW, almost as many solutions exist
+than SoC vendors and many of them requires to buy a large volume of SoC
+in order to get access to the facility and are by that requirement not available to generic platform developers.
+
+The Secured Boot option associated to a modern boot loader such as UEFI or uboot
+allows to restrict the execution of the system initialisation code to those which which carries a valid signature.
+Even if the system presents some weaknesses and constrains, it is likely
+*a valid and accessible solution for most device manufacturers even for
+medium volume.*
+
+Once the trusted boot activated, you will have a good confidence
+*(history shows that security loop holes are always available
+somewhere)* that the code which will start to run when powering the
+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
+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
+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
+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
+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.*
+http://sourceforge.net/p/linux-ima/wiki/Home/
+
+In short IMA allows the kernel to check that a file has not been changed
+by validating it against a stored/calculate hash (called label) while
+EVM checks the file attributes (including the extended ones).
+
+Two types of labels are available :
+
+- immutable and signed
+- 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
+install dynamically and the hash can be recalculated on the fly by the
+OS providing a lesser level of protection.
+
+Obviously some restriction will be imposed on which SW modules are
+allowed to update an IMA/EVM label and all public keys used for
+signature checking must be protected with an unmutable label or stored
+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
+further reading of such file.
+
+*The update solution must cater with this constrain and must be
+implemented via an atomic model where all changes are done in one step,
+on the entire core OS, generally just before a reboot..*
+
+## Mandatory Access Control (MAC)
+
+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 :
+
+- low cost and small CPU
+- high control of the OS and Middleware loaded on the box
+- user, at best, very slow to activate update
+- no visibility by the manufacturer of the external environment where
+ the device is connected.
+- No skilled administrator
+- 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
+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.
+
+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 :
+
+- 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
+when associated with an installer code which cannot be called via a back
+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.
+
+The list of requested privileges will be associated to the App in a
+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
+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 :
+
+- CPU, RAM
+- devices
+- network
+- middleware
+- files
+- libraries and system calls.
+
+CPU and RAM over use can be restricted with a correct C-Group
+configuration.
+
+Devices and files can be isolated by MAC and DAC.
+
+Network access can be controlled via MAC in association with the
+nftables.
+
+Middleware in AGL is access via binders which provides not only an
+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.
+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
+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
+
+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
+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
+cloud or on small embedded system.
+
+From a security point of view, while containers provides an isolation
+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.
+ Each container must individually be updated.
+- Due to the transparent overlay model sharing files between
+ containers, predicting the actually used disk space is challenging.
+- UX needs to share the same Display and Input what can open back
+ doors in the system.
+
+At least two lines of interest seem to provide a serious value for the
+Automotive domain :
+
+- Isolating subsystem
+- 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.
+
+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*.
+
+The Smack provides a solution to create MAC name spaces, so in theory
+nothing would stop to launch containers for each Apps in an isolated
+environment.
+
+As further reading on similar topic, you can have a look at the Open
+Source Vasum project.
+https://github.com/Samsung/vasum
+https://wiki.tizen.org/wiki/Security:Vasum
## Process Management
+While developers will always have a good reason for delaying the
+activation of the security layers, to succeed, you will need to keep a
+few base concepts enforced:
+
+- Security is invasive. It goes everywhere.
+- Security cannot be apply as a patch at the end of the project.
+- System must be developed with the security 'on' or it will
+ 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
+requirement that cannot be negotiated.