diff options
Diffstat (limited to 'sec-blueprint/05-security-concepts.md')
| -rw-r--r-- | sec-blueprint/05-security-concepts.md | 446 |
1 files changed, 446 insertions, 0 deletions
diff --git a/sec-blueprint/05-security-concepts.md b/sec-blueprint/05-security-concepts.md new file mode 100644 index 0000000..114bc8b --- /dev/null +++ b/sec-blueprint/05-security-concepts.md @@ -0,0 +1,446 @@ +--- + +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. |