Conference PaperPDF Available

A communication framework for distributed access control in microkernel-based systems

Authors:

Abstract

Microkernel-based architectures have gained an increasing interest and relevance for embedded systems. These can not only provide real-time guarantees but also offer strong security properties which become increasingly significant in certain application domains such as automotive systems. Nevertheless, the functionality of those complex systems often needs to be distributed across a network of control units for various reasons (e.g. physical location, scalability, separation). Although microkernels have been commercially established, distributed systems like these have not been a major focus. This is basically originated by the fact that – in the microkernel world – policy, device drivers and protocol stacks are userspace concerns and rather left to be solved by the particular application domain. Following the principle of least privilege, we therefore developed a distributed access-control framework for all network-based communication in microkernel-based systems that can be generically deployed. Our design not only enforces security properties such as integrity but is also scalable without adding too much overhead in terms of run time or code
A communication framework for distributed access
control in microkernel-based systems
Mohammad Hamad, Johannes Schlatow, Vassilis Prevelakis and Rolf Ernst
Institute of Computer and Network Engineering, TU Braunschweig
{mhamad,schlatow,prevelakis,ernst}@ida.ing.tu-bs.de
Abstract—Microkernel-based architectures have gained an in-
creasing interest and relevance for embedded systems. These can
not only provide real-time guarantees but also offer strong secu-
rity properties which become increasingly significant in certain
application domains such as automotive systems. Nevertheless,
the functionality of those complex systems often needs to be dis-
tributed across a network of control units for various reasons (e.g.
physical location, scalability, separation). Although microkernels
have been commercially established, distributed systems like these
have not been a major focus. This is basically originated by the
fact that – in the microkernel world – policy, device drivers
and protocol stacks are userspace concerns and rather left to
be solved by the particular application domain. Following the
principle of least privilege, we therefore developed a distributed
access-control framework for all network-based communication
in microkernel-based systems that can be generically deployed.
Our design not only enforces security properties such as integrity
but is also scalable without adding too much overhead in terms
of run time or code.
I. INTRODUCTION
Nowadays embedded systems are ubiquitous, i.e. in most
of the electronic devices in our life; from simple devices
such as microwaves to sophisticated ones such as cars. The
latter is a driving motor when it comes to safety concerns
of complex embedded systems, which is typically approached
by a deliberate system design that uses separation and
“safety nets”. A contemporary car contains from 70 to 100
microcontroller-based computers [1], known as electronic con-
trol units (ECUs). These ECUs control many functions within
the car, ranging from the mundane such as controlling courtesy
lights to the highly critical such as engine control. These
ECUs are distributed around the vehicle and interconnected
using different bus systems such as CAN, MOST or FlexRay
in a rather static setup. The need of exchanging bigger and
more expressive messages is pushing towards using Internet
Protocol (IP) standards for both on-board and vehicle-to-X
communications [2], [3], which is also driven by the desire
of better modifiability and updateability in the automotive
domain. However, one main reason that connected ECUs are
becoming increasingly vulnerable is the use of unprotected
wireless and wired communication [4].
Increasing the flexibility of vehicular (software) platforms
while not neglecting the safety and security therefore is a
major challenge. Moreover, in contrast to traditional comput-
ing systems, embedded systems not only come with limited
resources concerning memory and CPU power but also have
slightly different demands on the system’s security.
Modern sedans run a huge number of applications (func-
tions) with millions of lines of code (LOC) [1]. These
applications come from several vendors with various levels
of code quality. Safety-relevant functions, such as anti-lock
braking systems, are typically well-engineered and heavily
tested, while others, such as the entertainment systems, could
be implemented with security and reliability not as prime
factor. The uncontrolled interference within shared buses
between applications with a mixed level of safety, security
and criticality may create vulnerabilities [5]. Compromising
uncritical components by an adversary could be sufficient to
control critical components across the entire car, which must
be dealt with by appropriate protection mechanisms. Using
microkernels could be the first step towards providing a secure
environment for such systems [6], which will benefit from the
small amount of privileged code, the minimal trusted com-
puting base (TCB), and the memory protection between the
different components. However, providing a comprehensive
framework for controlling the communication between the
various platform subsystems is a crucial complementary task
to the microkernel’s security services.
We have created a distributed access-control framework
which allows only authorized components to interact with each
other inside the vehicle and with external entities. Our frame-
work ensures the ability to define the type of security provided
for each communication link (e.g. integrity, confidentiality),
and other connection properties (e.g. priority). We defined a
secure communication policy, which determines all permitted
paths between different components, centrally and gradually.
Later on, the policy was enforced by each ECU on the vehicle
isolatedly (i.e. without any need for additional interactions).
The rest of the paper is organized as follows. Section II
describes the communication framework and the objectives of
our work. It also explains the security approach of local and
remote communication between the different components. In
Section III, we describe the main parts of the communication
module and its implementation. Finally, related work is pre-
sented in Section IV before we evaluate our implementation
in Section V and discuss our findings in Section VI.
II. COMMUNICATION FRAM EW OR K
Fig. 1 depicts an exemplary distributed system and the
different scenarios of inter-component communication. In our
idealistic world, each ECU is running a microkernel-based
operating system that hosts multiple (interacting) software
C2
C4
C1
C3
ECU1 ECU2
network
C4’
local
remote
Fig. 1. Communication scenarios in distributed automotive systems
components. The ECUs are then inter-connected by a network.
Here, we identify two types of inter-component communica-
tion: Local communication, which refers to the communication
between two components on the same ECU (e.g. C3 and C4),
and remote communication, which denotes the communication
between components on two different ECUs (e.g. C1 and C2).
Our goal is to build a framework that ensures secure
communication between the components in this scenario while
still maintaining a high flexibility. For this purpose, we first
state our objectives before we discuss local communication
mechanisms w.r.t. their application in our scenario and finally
derive our networking architecture approach.
A. (Security) objectives
When it comes to designing a communication framework
for distributed systems in critical application domains such as
automotive systems, we identified the following objectives:
1) Fine-grained access control: Our primary goal is to con-
trol who should talk to whom in an efficient manner without
the need for static access-control mechanisms. Components
should only communicate with other components who are
specified by the policy. One main advantage of this is that
even a compromised component will only be able to interact
with authorized components and will be unable to attack other
components indiscriminately.
2) Secure communication: Providing security services for
authorized connections is a fundamental requirement. The
required security services are varying from one application
to another. However, since most security issues in vehicle
communications are related to the lack of authentication
mechanisms, providing integrity and mutual authentication is
necessary to prevent unauthorized parties from sending false
data or injecting them in established connections.
3) Composability and migratability: In a component-based
system, the desired functionality is integrated by composing
several interacting components. In a distributed scenario, we
also gain the freedom of choice where to execute each com-
ponent. Fig. 1 illustrates this on component C4 which could
alternatively be executed on ECU2 but then requires a remote
communication mechanism to C3. Hence, composability and
migratability are important values whose lack would quickly
restrict the design space. Note that we consider migration in
terms of a (partial) system reconfiguration that must undergo
several admission tests before being applied.
4) Minimum (application-specific) TCB: A common goal
when building secure systems is the minimization of the TCB,
i.e. the subset of hardware and software that must be relied
upon. Microkernels already do their share w.r.t. minimizing
the TCB. Yet, in userspace, a flawed design can easily bloat
the TCB, e.g. by adding a middleware for all applications.
Instead, each application should only rely upon a minimum
set of software components with minimum complexity and
therefore have its specific TCB [7].
5) Legacy application support: Another concern is the
ability to integrate legacy applications into a component-based
system. Note that legacy APIs might need to be monitored
and restricted so that they do not conflict with the above
objectives. In the scope of this work, we demonstrate the
feasibility of this by providing a socket API to conventional
network applications.
B. From IPC towards networked communication
Any microkernel architecture provides strong isolation of
application components in order to minimize the TCB. There-
fore, any communication between isolated components, i.e.
inter-process communication (IPC), needs to be mediated
by the kernel. On the one hand, this introduces additional
overhead which was historically one of the main drawbacks of
the microkernel approach but was weakened by the optimiza-
tion of (synchronous) IPC mechanisms and the evolution of
microkernels [8], [9]. On the other hand, this has the benefit
of making any communication explicit. This property was
further strengthened by introducing capability-based access
control that enables a fine-grained and unforgeable control of
a component’s communication channels. As a result, today’s
microkernel architectures allow us to apply the principle of
least privilege and enforcing security policies when integrating
application components from different, potentially untrusted,
parties [10]. In summary, all these properties helped establish-
ing microkernels as sophisticated, and also commercialized
[11]–[14], implementation vehicles for critical application
domains.
When it comes to more dynamic scenarios like distributed
systems, a service-oriented approach is commonly taken to
equip the system with the required flexibility. Typically, a
communication middleware then takes care of routing the
messages to the communication partner that registered under
a certain service name thereby deploying a communication
mechanism (API) that is agnostic of the actual communication
partners and their location. Yet a major drawback of such a
middleware is that enforcing security policies and providing
isolation (e.g. local namespaces) while not adding too much
overhead is a non-trivial obligation. This approach clearly
trades ease-of-use against simplicity and efficiency.
We therefore believe that the strong architectural guarantees
already provided by microkernels can and should be utilized
in such scenarios. That means local communication shall still
benefit from the existing efficient and secure implementations
C1
TCP/IP
Network Device
Multiplexer
Network
C2
TCP/IP
C3
TCP/IP
Communication Module
RPC
Network Device
C1 C2 C3
(b) (a)
TCP/IP
library call IPC
Fig. 2. Architecture with multiple TCP/IP stacks and a shared multiplexer
(a) compared to a shared communication module with an integrated TCP/IP
stack (b).
while we transparently transform between the local and remote
communication mechanisms where necessary. The challenge
here is to provide similar guarantees for remote communica-
tion, i.e. the fine-grained access control and integrity of remote
communication channels. Yet there is a mismatch between the
fine-grained access control for local IPC and the socket API
typically used for network applications that gives full access
to any attached network. We therefore need to provide the
infrastructure with which we can control network accesses
in order to establish unforgeable network communication
between application components as we are used to on when
using local IPC.
C. From user-level networking towards a distributed firewall
Microkernel philosophy is based on moving all policy,
including device drivers and protocol stacks, from the kernel
to the userspace. Therefore, implementing the network stack in
the userspace was a hot topic for many years; it was proposed
for different motivations, including increasing the performance
and flexibility of the network layer [15].
Providing maximum isolation between different applica-
tions, a straight-forward approach of executing several network
applications on a microkernel consists in using dedicated
network stacks for each application (cf. Fig. 2a). Here, the
low-level Network Interface Controller (NIC) must be multi-
plexed/virtualized, e.g. by a network bridge. As a result each
application is linked to its network-stack library and requires
its own MAC and IP addresses. The drawback of this approach
is that unless some sort of packet filtering is deployed, each
application also gets full access to the shared network, which
contradicts our objective of a fine-grained access control.
More precisely, this approach is susceptible to the following
communication threats:
a) Spoofing: An application, which has a full access to
the network stack, can emit a frame with fake IP or MAC
addresses. Such an application may imitate other applications,
eavesdrop on their communication, or collect relevant infor-
mation about the platform. It could also change the transmitted
data and inject false values.
Authorizer
:
Integrator_public_key
Licensees
:
Platform_public_key
Conditions: (Vendor_id ==“ACME_INSTRUMENTS“
&& Src_device_name == “headlight_control
&& Dst_device_name == “ambient_light_sensor“
&& Src_device_type == CONTROL_PLATFORM
&& Dst_device_type == LIGHT_SENSOR
&& Security_level >= SL_INTEGRITY && Priority_level == HIGH
&& Bitrate_limit == X Kbitd/sec ) -> “ALLOW“
Signature
:
Integrator
signature
Fig. 3. An example of KeyNote credential which enables an ambient light
sensor to communicate with headlight control. The credential ensures integrity
of the communication line with high priority.
b) Denial of service (DoS): One of the primary results
of the IP spoofing can be a DoS attack. I.e. a malicious
application could spoof a target service’s IP address and
send many packets to different receivers. All responses to the
spoofed packets will be directed to the services IP, which will
be flooded. Sometimes, an attack cannot cause a disruption of
the service, but can cause a degradation of its quality (e.g. by
increasing its response time). The DoS could lead to serious
issues if that service is responsible for the users’ safety.
In order to combat these threats, adequate access-control
mechanisms should be implemented to control the interaction
between different applications and to prevent unauthorized
parties from processing foreign data. However, packet filtering
is more network-centric and typically too abstract for fine-
grained application-level access control. Moreover, there is a
consistency challenge when it comes to updating static filtering
rules in a distributed system in case of a dynamically changing
environment.
Integrating other traditional network protection methods
such as firewalls in vehicle communication networks was
shown to be inadequate too [16], especially if the integrator
keeps the assumption that all insider nodes are trusted. More-
over, using a single ECU as a firewall to control the whole
communications within the vehicle is also not an optimal
solution. Such an ECU will create congestion, become a single
point of failure and jeopardize the scalability.
Hence, adopting the distributed firewall technique [17]
seems to be a favorable solution in order to remove any
performance bottleneck. We applied this method by providing
a single communication module for each ECU as shown in
Fig. 2b. This module is playing the role of a firewall by
controlling all incoming and outgoing communications on a
single ECU and by enforcing the security policy locally. The
security policy is managed centrally and then distributed to
all ECUs. Note that the communication module implements
a shared network stack and multiplexes the network device.
It is therefore a potentially complex component that might
compromise the isolation of the application components. We
believe, however, that this design choice can actually simplify
the policy enforcement and multiplexing task in contrast to
solutions that implement these on other layers of abstraction.
In our previous work [18], we presented a mechanism to
integrate the evaluation of communication policy into the
C5
C1
Communication Module
C3
ECU1
network
local IPC (capability-based)
network protocol (IPsec)
socket API (capability-based)
Fig. 4. Architecture with a shared communication module on each ECU
components’ development flow; from the design process until
the final integration stage of the component with the platform.
Such integration will ensure that the defined policy will fulfill
all the operational component requirements. Each component
is identified by its own credential, which gives it the ability to
communicate with other components regardless its topological
location in the network.
We used the KeyNote policy definition language [19] to
formulate the communication policy as shown in Fig. 3.
The application-independent design of KeyNote allows for
the support of a variety of different applications. KeyNote
furthermore enables the delegation of the policy by allowing
principals to delegate authorization to other principals (e.g. in
Fig. 3 where the integrator delegates rights to the platform).
Consequently, the delegation capability allows to decentralize
the administration of policies.
III. IMPLEMENTATION OF THE COMMUNICATION MODULE
We implemented our communication module for the Genode
OS Framework as distinct userspace server which provides and
monitors network accesses. Hence any network application
acts as a client that connects to this server using a socket-like
API. Fig. 4 illustrates the different communication scenarios
(cf. Fig. 1): While C1 represents a network application compo-
nent directly using the socket API, C3’s local IPC is translated
by C5 and the communication module into a network com-
munication. An important detail here is the capability-based
access control used to manage the access to the communication
module. As a system integrator, we can thus perfectly control
the local inter-component communication and thus guarantee
that no application component has direct access to the network
interface. Moreover, the communication module is able to
distinguish its clients by their capabilities and can therefore
select and enforce different (pre-defined) policies for the
network communication. In this way, all network accesses are
securely mediated by the communication module. Note that
this is based on the assumption that capabilities cannot be
arbitrarily delegated between application components.
The communication module is composed of four cooper-
ating submodules as depicted in Fig. 5. The pseudo-socket
layer plays a central role by providing a suitable interface
to the applications as well as by coordinating the other
submodules. In the remainder of this section, we elaborate
on these submodules in more detail:
Fig. 5. Architecture of the communication module
a) Pseudo-socket layer: A lot of conventional (legacy)
applications use a socket-like API (as in the standard C
library) to access the network stack. Similarly, the pseudo-
socket layer represents the interface which the applications
use to interact with the communication module. In contrast
to the conventional function/library calls, the pseudo-socket
layer uses local IPC and must therefore take care of the
memory management between the different address spaces of
the communication module and its clients before a call can be
handed over to the actual network stack. More precisely, we
used shared memory to transfer the data between the address
space of the application and the communication module to
avoid imposing extra overhead by copying data multiple times.
All this is transparently taken care of by this layer, so that the
clients can still use the typical socket API functions. Legacy
applications can be supported by linking against a slightly
modified version of the standard C library that forwards the
socket API calls to the communication module. Additionally,
this layer checks the parameter validity, invokes the policy
decision component with the relevant information related to
the connection, and reacts to the received decision. If an
affirmative decision (i.e. allow) is received, a new rule will
be added to the repository. This rule contains many runtime
specified selectors such as IP addresses and port numbers of
the two ends of the connection. It also includes the required
security level (i.e. integrity or confidentiality), the maximum
allowed bit rate, and the priority level of the connection.
Associating this rule with the opened socket gives us the ability
to enforce this rule in two different layers. The first one is at
the socket layer when an application uses the socket to send
or receive data while the second one is placed at the IP layer
whenever a new packet is received. The rule will be removed
from the repository as soon as the socket is closed.
b) Policy Decision Module: This submodule is responsi-
ble for monitoring, i.e. granting or denying, the main requests
of an application such as initiating a connection, sending, or
receiving data. In order to make a decision, it determines
whether a proposed request is consistent with the local policy
and whether the conditions specified in the credentials were
met. For this purpose, we use the KeyNote library.
c) Network Stack: As mentioned before, the network
stack was integrated into the communication module to pro-
vide the basic network access. In our implementation, we
used the lightweight TCP/IP stack (lwIP). In addition, we
integrated embedded IPsec [20] into this network stack (as
proposed in [21]) in order to provide basic security services
(e.g. integrity, confidentiality) to the clients. Furthermore, we
consider implementing traffic monitoring in a later phase of
our work to keep tracking of the bit rate of a connection in
order to prevent DoS attacks, like proposed in [22].
d) Decision Repository: Providing a repository for sav-
ing the policy decisions is an essential technique in our design
to spare the run-time costs of the request evaluation. By doing
this, the evaluation only occurs when an application initiates
a connection (i.e. accept() and connect() for TCP-based com-
munication). For this purpose, the decision repository stores
the decided rules for any opened connection.
IV. REL ATED WORK
Many authors have addressed deficiencies of vehicle com-
munication and the need for a mechanism to control the
interaction between the components within the vehicle and
between the vehicle and the outside world [23]. However, only
a few proposals have appeared to provide such a mechanism.
Based on legacy network solutions, Chutorash [16] proposes
an approach for using a firewall to control the interaction
between applications on the one side and vehicle bus and
vehicle components on the other side. His approach was
restricted to monitor the interaction between HMI systems
and other vehicle components, which ignored controlling the
interaction between the vehicle’s components. We extended
this approach by using a firewall for each ECU in order
to build a distributed firewall that is concerned about all
communication inside the vehicle.
Concerning multiple network stacks, a userspace port switch
was proposed in [24] that controls interconnecting indepen-
dent network applications which run together. Swarm assigns
the same IP, MAC address to all different stacks and uses
port number to distinguish them. Yet using port numbers to
control the communication flows is not sufficient when the
applications use dynamic port assignment.
The Genode OS Framework [25] proposed the use of a
NIC bridge which implements the Proxy-ARP protocol [26]
to multiplex and monitor the communications of different
applications that run on the same host. Neither solutions use
filtering mechanisms which identify the application properly.
QNX Neutrino RTOS is a commercial microkernel-based
real-time operating system that uses a networking architecture
[27] very similar to what we propose. The dominant (local)
IPC mechanism is synchronous message passing. Network
communication is enabled via a socket API by a central
network manager which implements device drivers and the
network stack. In addition, the so-called Qnet protocol trans-
parently extends the message-passing paradigm over a dis-
tributed system [28]. However, as Qnet is designed to be
deployed for a group of trusted machines, it does not perform
any authentication. Moreover, policy enforcement is only done
in terms of packet filtering.
TABLE I
COMMUNICATION MODULE CODE SIZE
Part SLOC
Pseudo-socket layer 500
Policy Decision Module interface 300
IPsec extension of the Network Stack 2000
Decision Repository 600
(a) Genode on Raspberry Pi (b) Genode on Linux
Fig. 6. Average round-trip latency results for our two test platforms.
V. EVAL UATIO N
We evaluated our implementation of the communication
module w.r.t. its overhead in terms of source lines of code
(SLOC) and latency. Table I summarizes the SLOC values
that have been acquired by the cloc tool. Note that we
only evaluated the part of the policy decision module which
interfaces the unmodified KeyNote library. It is also worth
mentioning, that by our approaches saves about 750 SLOC by
superseding the multiplexing component (i.e. nic bridge).
Regarding the latency, we used the TCP RR test of the
netperf tool in order to measure the average round-trip latency.
As a matter of course, the communication module must
perform worse than a scenario where a single application
directly accesses the network device. We therefore compared
our approach against the scenario illustrated in Fig. 2a. More
precisely, the multiplexer we used is the nic bridge of the
Genode OS Framework that implements the Proxy-ARP proto-
col. Hence the scenarios we compared both include additional
copying and context switching caused by the nic bridge and
the communication module. The netserver component was
executed on the system under test while the netperf binary was
run from a standard linux machine. In particular, we added the
parameters -i 10,3 -I 99,5 in order to perform multiple
iterations and achieve a confidence level of 99 %.
The average round-trip latency results are shown for differ-
ent package sizes and two different platforms in Fig. 6. As a
baseline, we also included the results for a setup in which the
netserver directly accesses the network device. One of the test
platforms was running Genode on a Raspberry Pi whereas the
other platform was running Genode directly on the same linux
machine as the netperf binary. Note that we used the latter to
bypass any physical network devices and drivers as it only
utilizes rather simple virtual network interfaces. Interestingly,
we can observe a slight improvement of the latency for our
approach in comparison to the nic bridge.
Since the TCP RR benchmark does not measure the TCP
connection setup, we accounted the additional latency imposed
by the policy decision module separately. This overhead only
occurs once for every TCP connection and is thus amortized
over the lifetime of the connection. For this, we measured a
maximum of 30 milliseconds. Note that our implementation is
still in a proof-of-concept stage so that various optimization
techniques could be applied to improve the performance.
VI. CONCLUSION
From the microkernel-perspective, using a dedicated net-
work stack for each application is a common and reasonable
design decision in order to achieve a high level of isolation.
However, this approach either enables full and uncontrolled
network access to potentially malicious applications or com-
plicates the process of controlling the network accesses on a
rather low abstraction level. In the scope of this work, we pre-
sented and implemented an alternative approach that consists
in providing a single communication module that efficiently
mediates and controls all network accesses. By deploying this
communication module in a distributed system like an auto-
motive system that feature rather complex networks of many
ECUs, we can equip those systems with a distributed firewall
that enforces the integrity of all network communication. As
this communication module authorizes both, incoming and
outgoing, connection requests, by invoking a policy engine,
it protects the network from malicious processes on the ECU
and the ECU from unauthorized network connections.
Nevertheless, as security often has a price, it is clear that
our access-control mechanism imposes some overhead. For
our approach, this consists in processing overhead by the
communication module and protocol overhead required to
provide secure network communication (i.e. IPsec). For the
latter we have already shown in our preliminary work [21]
that the overhead is typically very low. By introducing the
communication module, we could marginally improve the
average round-trip latency once a connection is established.
However, this also requires some additional (but amortized)
cost for establishing a connection.
In summary, communication integrity is an essential prereq-
uisite for functional safety, a major requirement for automotive
systems. We therefore believe that our approach enables the
use of microkernels in such demanding distributed systems.
ACK NOW LE DG EM EN T
This work was supported by the DFG Research Unit
Controlling Concurrent Change (CCC), funding number
FOR 1800. We thank the members of CCC for their support.
REFERENCES
[1] R. Charette, “This car runs on code,” feb 2009. [Online]. Available:
http://www.spectrum.ieee.org/feb09/7649
[2] A. Bouard, B. Glas, A. Jentzsch, A. Kiening, T. Kittel, F. Stadler, and
B. Weyl, “Driving automotive middleware towards a secure IP-based
future,” in 10th conference for Embedded Security in Cars (Escar’12),
Berlin, Germany, Nov. 2012.
[3] RTI Conntext DDS. [Online]. Available: http://www.rti.com
[4] M. Wolf, A. Weimerskirch, and C. Paar, “Security in automotive bus
systems,” in Workshop on Embedded Security in Cars (ESCAR), 2004.
[5] Y. Laarouchi, Y. Deswarte, D. Powell, J. Arlat, and E. De Nadai,
“Ensuring Safety and Security for Avionics: A Case Study,” in DAta
Systems in Aerospace (DASIA), ser. ESA Special Publication, vol. 669,
May 2009, p. 28.
[6] G. Heiser, “Secure embedded systems need microkernels,” USENIX
;login:, vol. 30, no. 6, pp. 9–13, dec 2005.
[7] H. H ¨
artig, “Security architectures revisited,” in 10th ACM SIGOPS
European Workshop. New York, NY, USA: ACM, 2002, pp. 16–23.
[8] J. Liedtke, “Improving IPC by kernel design,” ACM SIGOPS Operating
Systems Review, vol. 27, no. 5, pp. 175–188, Dec. 1993.
[9] K. Elphinstone and G. Heiser, “From L3 to seL4 – what have we learnt
in 20 years of L4 microkernels?” in ACM Symposium on Operating
Systems Principles, Farmington, PA, USA, nov 2013, pp. 133–150.
[10] A. Lackorzynski and A. Warg, “Taming Subsystems: Capabilities As
Universal Resource Access Control in L4,” in Proceedings of the Second
Workshop on Isolation and Integration in Embedded Systems (IIES).
New York, NY, USA: ACM, 2009, pp. 25–30.
[11] GenodeLabs. [Online]. Available: http://genode-labs.com
[12] Kernkonzept. [Online]. Available: http://www.kernkonzept.com
[13] Cog Systems: OKL4 Microvisor. [Online]. Available: http://cog.
systems/products/okl4-microvisor.shtml
[14] QNX Neutrino RTOS. [Online]. Available: http://www.qnx.com/
products/neutrino-rtos/neutrino- rtos.html
[15] T. von Eicken, A. Basu, V. Buch, and W. Vogels, “U-Net: A user-level
network interface for parallel and distributed computing,” in Proceedings
of the Fifteenth ACM Symposium on Operating Systems Principles
(SOSP). New York, NY, USA: ACM, 1995, pp. 40–53.
[16] R. Chutorash, “Firewall for vehicle communication bus,” Feb. 24
2000, wO Patent App. PCT/US1999/017,852. [Online]. Available:
http://www.google.de/patents/WO2000009363A1?cl=en
[17] S. Ioannidis, A. D. Keromytis, S. M. Bellovin, and J. M. Smith,
“Implementing a distributed firewall,” in Proceedings of the 7th ACM
Conference on Computer and Communications Security (CCS). New
York, NY, USA: ACM, 2000, pp. 190–199.
[18] V. Prevelakis and M. Hamad, “A policy-based communications archi-
tecture for vehicles,” in 1st International Conference on Information
Systems Security and Privacy (ICISSP), Feb. 2015, pp. 155–162.
[19] M. Blaze, J. Feigenbaum, J. Ioannidis, and A. D. Keromytis, “The
keynote trust-management system version 2,” RFC 2704, September
1999, http://www.rfc-editor.org/rfc/rfc2704.txt. [Online]. Available:
http://www.rfc-editor.org/rfc/rfc2704.txt
[20] S. Kent and K. Seo, “Security architecture for the internet protocol,”
RFC 4301, December 2005.
[21] M. Hamad and V. Prevelakis, “Implementation and performance evalua-
tion of embedded ipsec on microkernel os,” in The 2nd World Symposium
On Computer Networks and Information Security, September 2015.
[22] A. Garg and A. N. Reddy, “Mitigation of DoS attacks through QoS
regulation,” Microprocessors and Microsystems, vol. 28, no. 10, 2004.
[23] K. Koscher, A. Czeskis, F. Roesner, S. Patel, T. Kohno, S. Checkoway,
D. Mccoy, B. Kantor, D. Anderson, H. Shacham, and S. Savage, “Ex-
perimental security analysis of a modern automobile,” in In Proceedings
of IEEE Symposium on Security and Privacy in, 2010.
[24] M. Unzner, “A split TCP/IP stack implementation for GNU/Linux,”
Diploma thesis, Technische Universit¨
at Dresden, 2014.
[25] Genode OS framework. [Online]. Available: https://genode.org/
[26] S. Carl-Mitchell and J. S. Quarterman, “Using arp to implement
transparent subnet gateways,” RFC 1027, October 1987, http:
//www.rfc-editor.org/rfc/rfc1027.txt. [Online]. Available: http://www.
rfc-editor.org/rfc/rfc1027.txt
[27] (2014, feb) QNX Neutrino RTOS System Architecture. [Online].
Available: http://support7.qnx.com/download/download/26183/QNX
Neutrino RTOS System Architecture.pdf
[28] (2014, mar) QNX Core Networking Stack User’s Guide. [On-
line]. Available: http://support7.qnx.com/download/download/26171/
Core Networking with io-pkt Users Guide.pdf
... This also means that software components cannot be easily mapped or migrated to other processing nodes without modifying the system composition. Instead, distribution is achieved by inserting proxy components that translate service interfaces (using IPC) into network communication and vice versa [11]. As run-time dependencies are therefore explicitly granted, there is no uncertainty in the system composition and the possible component interactions. ...
Article
Full-text available
As embedded applications are subject to non-functional requirements (latency, safety, reliability, etc.) they require special care when it comes to providing assurances. Traditionally, these systems are quite static in their software and hardware composition. However, there is an increasing interest in enabling adaptivity and autonomy in embedded systems that cannot be satisfied with preprogrammed adaptations any more. Instead, it requires automated software composition in conjunction with model-based analyses that must adhere to requirements and constraints from various viewpoints. A major challenge in this matter is that embedded systems are subject to emergent constraints which are affected by inter-dependent properties resulting from the software composition and platform configuration. As these properties typically require an in-depth evaluation by complex analyses, a holistic formulation of parameters and their constraints is not applicable. We present a compositional framework for model-based integration of component-based embedded systems. The framework provides a structured approach to perform operations on a cross-layer model for model enrichment, synthesis and analysis. It thereby provides the overarching mechanisms to combine existing models, analyses and reasoning. Furthermore, it automates integration decisions and enables an iterative exploration of feasible system compositions. We demonstrate the applicability of this framework on a case study of a stereo-vision robot that uses a component-based operating system.
... In a similar fashion, the use of polices to govern the access to these resources was proposed in [20]. Further attempts to enrich the security of the autonomous vehicles included relying on the tamper proof microkernel, proxy, and network stack to augment the security of the vehicle networks [21]. Others suggested adding more sensors to the autonomous vehicle to monitor the chips' performance to provide integrity and availability [22]. ...
... Furthermore, the use of polices to restrict access to these resources was proposed in [19]. Further attempts to deepen the security of the autonomous vehicles involved counting on tamper proof microkernels, proxies, and network stacks to enhance the security of vehicle networks [20]. Attaching more sensors to the autonomous vehicle helps to observe performance with respect to integrity and availability [21]. ...
... There is no absolute security of a system, and the proof is that despite all these mitigation mechanisms, attackers were able to exploit these vulnerabilities and mount severe attacks against a vehicle [28,7,24]. Therefore, another layer of protection was introduced (i.e., Intrusion Detection Systems (IDSs)) to monitor the vehicular system and its network, and to detect any violation of a predefined security policy or any malicious behavior of the system components during operation [19,29]. ...
Chapter
Recently, significant developments were introduced within the vehicular domain, making the modern vehicle a network of a multitude of embedded systems communicating with each other, while adhering to safety-critical and secure systems specifications. Many technologies have been integrated within modern vehicles to give them the capability to interact with the outside world. These advances have significantly enlarged the attack surface. We already have numerous instances of successful penetration of vehicular networks both from inside the vehicle and from the outside. To face these attacks, many intrusion prevention and detection mechanisms were implemented inside a vehicular system. Nonetheless, even if all security mitigation is adopted, an attack still can happen. In critical-safety environments, such as the vehicle, the response to the attack is as essential as detecting the attack itself. Although Intrusion Response Systems (IRSs) have been adopted in other domains to add an extra layer of security, there is a lack of such systems in the vehicular field. In this work, we investigate the challenges and identify the requirements for integrating such a mechanism within the vehicle system. Besides, we present an IRS framework, which meets the identified requirements. Also, we discuss the integration of IRS through the vehicle system development and the different aspects which support such a process. Finally, we use the automated obstacle avoidance system to explain how we could develop intrusion response strategies and to measure the overhead of such security system.
... Adopting security mechanisms that ensure data integrity, confidentiality, authenticity, and authorization can protect the in-vehicle network system from most of these attacks and facilitate the detection of infected messages (such as m 5 ) [9,8]. However, a malicious software component (such as τ 2 ) might remain able to emit malicious packets (e. g., m 6 ) to its remote peer(s), if it is authorized. ...
Article
Full-text available
The Internet of Vehicle (IoV) is an extension of Vehicle-to-Vehicle (V2V) communication that can improve vehicles’ fully autonomous driving capabilities. However, these communications are vulnerable to many attacks. Therefore, it is critical to provide run-time mechanisms to detect malware and stop the attackers before they manage to gain a foothold in the system. Anomaly-based detection techniques are convenient and capable of detecting off-nominal behavior by the component caused by zero-day attacks. One significant critical aspect when using anomaly-based techniques is ensuring the correct definition of the observed component’s normal behavior. In this paper, we propose using the task’s temporal specification as a baseline to define its normal behavior and identify temporal thresholds that give the system the ability to predict malicious tasks. By applying our solution on one use-case, we got temporal thresholds 20–40 % less than the one usually used to alarm the system about security violations. Using our boundaries ensures the early detection of off-nominal temporal behavior and provides the system with a sufficient amount of time to initiate recovery actions.
... Microkernel OS implements only core functions as a kernel and all other OS functions as OS servers. OS servers are implemented as programs run on the user space, therefore, the application program (AP) processing and the OS processing can be distributed to each core regardless of the distribution form of the AP processing [6]. On the other hand, in the monolithic kernel OS, OS processing is tied to the same core of the AP processing because OS functions are start by issuing the system call. ...
... Since security can never be absolute, Intrusion Detection Systems (IDSs) were introduced as a second layer of defense. The IDS is used to monitor the vehicular system and its network to detect any violation of a predefined security policy or any malicious behavior of the system components during operation (Hamad et al., 2016b;. Whenever an attack is detected, the IDS has to alert the system in order to react accordingly. ...
Conference Paper
Modern vehicles are increasingly equipped with highly automated control systems both for driving and for passenger comfort. An integral part of these systems are the communication channels that allow the on-board systems to interact with passenger devices (e.g. tablets), ITS systems (e.g. roadside units), and other vehicles. These advances have significantly enlarged the attack surface and we already have numerous instances of successful penetration of vehicular networks both from inside the vehicle and from the outside. Traditional mechanisms for detecting and responding to such attacks are ill-suited to the vehicular domain mainly due to the fact that the entire process of dealing with an attack must be handled automatically and in a way that does not affect safety or severely impacts the continued availability of the vehicle or its key systems. Once a security breach is suspected, the system must evaluate the circumstances in order to determine whether the threat is real (and not a false positive) and select the optimal response through the use of an Intrusion Response System (IRS). Although IRSs have been adopted in other domains, there is a lack of such systems in the vehicular field. In this paper, we investigate the challenges and requirements for integrating such a mechanism inside a vehicle. In addition, we present an Intrusion Response System based on the Red-Zone principle which meets the identified requirements. Finally, we discuss the integration of IRS through the vehicle system development and the different aspects which support such a process.
Thesis
Full-text available
In recent years, significant developments were introduced within the vehicular domain, evolving the vehicles to become a network of many embedded systems distributed throughout the car, known as Electronic Control Units (ECUs). Each one of these ECUs runs a number of software components that collaborate with each other to perform various vehicle functions. Modern vehicles are also equipped with wireless communication technologies, such as WiFi, Bluetooth, and so on, giving them the capability to interact with other vehicles and roadside infrastructure. While these improvements have increased the safety of the automotive system, they have vastly expanded the attack surface of the vehicle and opened the door for new potential security risks. The situation is made worse by a lack of security mechanisms in the vehicular system, which allows the escalation of a compromise in one of the non-critical subsystems to threaten the safety of the entire vehicle and its passengers. This dissertation focuses on providing a comprehensive framework that ensures the security of the vehicular system during its whole life-cycle. This framework aims to prevent cyber-attacks against different components by ensuring secure communications among them. Furthermore, it aims to detect attacks that were not prevented successfully, and finally, to respond to these attacks properly to ensure a high degree of safety and stability of the system. The thesis starts by developing a hybrid threat model that combines multiple existing threat modeling approaches to define a more comprehensive one. This model defines (1) the various potential groups of attackers, which may threaten the vehicular system and their capabilities, (2) the potential targets (i.e., assets) of these groups and the various vulnerabilities that they include, and (3) the security requirements for these targets which should be considered to prevent the attacker from compromising them. After defining the security requirements by using the proposed threat model, the thesis addresses the challenges of developing the security policy, which implements these requirements. The thesis presents a methodology supporting the gradual definition of the security policy. Under our methodology, the designer of each software component is responsible for formulating the security policy of their components. As components get integrated into larger subsystems, the individual policies are merged into the subsystem policy. This continues as we go up the ladder of bigger subsystems until we have a complete vehicle. The thesis also shows how to enforce the developed security policy in an efficient manner by using a lightweight distributed access framework implemented within each single ECU. The enforcement takes place at the network level, enforcing communications only between authorized components while employing data integrity mechanisms in the communication between components, even if they run on different ECUs. In this way, we provide a level of compartmentalization in the in-vehicle network. With this precondition, a malicious application might remain able to emit (a) malicious packet(s) to its remote peer(s), if it is authorized. But, at the same time, this application can be prevented from attacking other components, which it is not authorized to communicate with. A heavy-handed security policy may adversely impact availability. Taken to the extreme, a secure system is a silent system that does not interact with its environment, and this is clearly not the intent of a security policy aimed at a vehicular platform. So we face the conundrum of increased security, leading to false positives affecting availability and overall performance against a more permissive system that may fail to detect attacks (false negatives), leading to the demise of the platform. The thesis addresses this issue by using the Red-Zone principle, whereby a tighter inner security envelope alerts the security system of a potential compromise before an actual security violation occurs. In this way, we can observe the suspect component as it operates within the Red-Zone, and characterize the event. We leverage the Red-zone principle in order to develop a run-time mechanism to detect the incidence of an attack and to prevent the attackers from gaining a foothold. The thesis defines temporal specifications for each hard real-time software component within the vehicle to be used as a baseline to define its nominal behavior. Attacks such as code injection, or Denial of Service (DoS) will usually cause a breach of this temporal specification, and thus will be detected. Once a software component is found to have violated its security boundaries, the system needs to take some remedial action. The type of response, e.g., taking the component offline, restarting the component, initiating containment measures (e.g., resetting the entire ECU), and so on, are the responsibility of the Intrusion Response System (IRS). This thesis uses the Red-Zone principle as the basis for developing an IRS framework to manage the interaction between security and safety of the system.
Article
Full-text available
Abstract—The rapid development of the embedded systems and the wide use of them in many sensitive fields require safeguarding their communications. Internet Protocol Security (IPsec) i s widely used t o solve network security problems by providing confidentiality and integrity for the communications in the network, but it introduces communication overhead. This overhead becomes a critical factor with embedded systems because of their low computing power and limited resources. In this research, we studied the overhead of using embedded IPsec in constrained resource systems, which run microkernel operating system (OS), in terms of the network latency and throughput. To conduct our experiment first, we ran the test with an unmodified network stack, and then we ran the same test with the modified network stack which contains the IPsec implementation. Later, we compared the results obtained from these two sets of experiments to examine the overhead. Our research demonstrated that the overhead imposed by IPsec protocols is small and well within the capabilities of even low cost microcontrollers such as the one used in the Raspberry Pi computer.
Conference Paper
Full-text available
The L4 microkernel has undergone 20 years of use and evolution. It has an active user and developer community, and there are commercial versions which are deployed on a large scale and in safety-critical systems. In this paper we examine the lessons learnt in those 20 years about microkernel design and implementation. We revisit the L4 design papers, and examine the evolution of design and implementation from the original L4 to the latest generation of L4 kernels, especially seL4, which has pushed the L4 model furthest and was the first OS kernel to undergo a complete formal verification of its implementation as well as a sound analysis of worst-case execution times. We demonstrate that while much has changed, the fundamental principles of minimality and high IPC performance remain the main drivers of design and implementation decisions.
Article
Full-text available
This work presents a study of current and future bus systems with respect to their security against various malicious attacks. After a brief description of the most well-known and established vehicular com-munication systems, we present feasible attacks and potential exposures for these automotive networks. We also provide an approach for secured automotive communication based on modern cryptographic mechanisms that provide secrecy, manipulation prevention and authentication to sol-ve most of the vehicular bus security issues.
Conference Paper
Despite the fact that numerous studies have indicated that vehicular networks are vulnerable to external and internal attacks, very little effort has been expended in safeguarding communications both between elements within the vehicle and between the vehicle and the outside world. In this paper we present a mechanism that allows communications policy (essentially who can talk with whom and the security parameters of the channel) to be defined during the design of the software component and then adapted as the component undergoes integration first within subsystems and so on all the way to the final integration in the operational vehicle. We provide a mechanism that can maintain the integrity of the policy throughout the development effort and, finally, enforce the policy during the operation of the component in the production vehicle.
Article
We present a case study in the avionics context, in which bidirectional information flows exist between critical components and less critical ones. These flows raise security and safety concerns that have to be taken into account to guarantee correct operation of the critical tasks. To allow upwards flows, we propose fault tolerance mechanisms based on diverse operating systems isolated by virtualization.
Article
The embedded and mobile computing market with its wide range of innovations is expected to remain growing in the foreseeable future. Recent developments in the embedded computing technology offer more performance thereby facilitating applications of unprecedented utility. Open systems, such as Linux, provide access to a huge software base. Nevertheless, these systems have to coexist with critical device infrastructure that insists on stringent timing and security properties. In this paper, we will present a capability-based software architecture, featuring enforceable security policies. The architecture aims to support current and future requirements of embedded computing systems, such as running versatile third-party applications on general purpose and open operating systems side by side with security sensitive programs.