path: root/sec-blueprint/05-security-concepts.md

---

title : Application Security Concepts
date  : 2016-06-30
categories: architecture, automotive
tags: architecture, automotive, linux
layout: techdoc 
 
---

**Table of Content**

1. TOC
{: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.

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.