Sascha Wessel
email: sascha.wessel@aisec.fraunhofer.de

Frederic Stumpf
email: frederic.stumpf@aisec.fraunhofer.de

Ilja Herdt
email: ilja.herdt@aisec.fraunhofer.de

Claudia Eckert
email: claudia.eckert@aisec.fraunhofer.de

Improving Mobile Device Security with Operating System-level Virtualization

Keywords:

In this paper, we propose a lightweight mechanism to isolate one or more Android userland instances from a trustworthy and secure entity. This entity controls and manages the Android instances and provides an interface for remote administration and management of the device and its software. Our approach includes several security extensions for secure network access, integrity protection of data on storage devices, and secure access to the touchscreen. Our implementation requires only minimal modification to the software stack of a typical Android-based smartphone, which allows easy porting to other devices when compared to other virtualization techniques. Practical tests show the feasibility of our approach regarding runtime overhead and battery lifetime impact.

Introduction

Smartphones are already an omnipresent part of our everyday lives. They are used for various tasks with different security requirements like web browsing, banking, or business use cases. This results in an increased demand for isolated environments with different security levels for different tasks on a single device. Payment service providers want a secure environment to protect their applications for financial transactions. Companies want a corporate environment isolated from the private environment of a user and the possibility to manage the devices remotely. This especially includes the enforcement of various security policies, which cannot be enforced with a stock Android-based smartphone today, e.g., whitelisting and/or blacklisting of applications and versions of applications in case of known vulnerabilities.

In this contribution, we propose a lightweight isolation mechanism for Android based on operating system-level virtualization and access control policies to separate one or more Android userland instances from a trustworthy and secure environment. Furthermore, we propose several security extensions based on this environment to control and manage the Android instances and their input and output data. This includes secure network communication, integrity protection of data on storage devices, and secure access to the touchscreen, e.g., for password entry dialogs. Another important part of our security concept is the integration of a secure element (SE) (e.g., embedded into a microSD card) to store secret keys and data physically separated from the application processor of the smartphone. This is to ensure its protection even in case of hardware-based attacks. Furthermore, our concept aims at straightforward remote manageability for integration in IT infrastructures. This includes easy snapshot and recovery functionalities and, moreover, security updates independent of the smartphone manufacturer. The evaluation of our prototype implementation shows that our modifications introduce only a negligible performance overhead and reduce the battery lifetime by only 7.5 percent in the worst case.

This paper is organized as follows. In Section 2, we introduce our attacker model and in Section 3 an overview of virtualization techniques for Android is given, followed by a discussion of related work in Section 4. Section 5 introduces the basic concept of operating system-level virtualization for Android and our additional security mechanisms are described in Section 6. General implementation aspects are presented in Section 7 and our prototype is described in Section 8. Finally, we evaluate our results in Section 9 and conclude in Section 10.

Attacker Model

In our attacker model, we assume an attacker using common attack vectors on Android-based smartphones. This especially includes eavesdropping and modification of remote communication, installation of malicious applications on the device, and exploiting (known) vulnerabilities to gain access to higher privilege levels, typically root access. Besides remote attackers, we also consider local attackers with physical access to the device. However, it is not possible to protect the data and software running on the application processor against attacks using JTAG or similar mechanisms without modifications to the smartphone hardware, so such attacks are out of scope for this paper.

Virtualization Techniques for Android

Isolation mechanisms or rather virtualization techniques for Android can be classified in three groups, namely user-level isolation, operating system-level virtualization and system virtualization. Figure 1 shows these three basic concepts Fig. 1. Isolation and Virtualization Mechanisms for Android on three different Layers for an example system with two isolated groups of applications and an additional control and management entity. By default, an Android system consists of an application layer, a middleware layer, and the kernel layer on top of the hardware. As shown in the figure, the main difference between the three concepts is which layers are shared by the isolated environments. Our concept is based on the architecture shown in the middle and is described in Section 5.

Related Work

The default Android security architecture uses different user identifiers (UIDs) per application group to implement a sandboxing mechanism. The communication between applications and core Android components is restricted based on permissions, which are requested during the installation of applications. It was shown that these mechanisms do not meet all security requirements [START_REF] Barrera | A Methodology for Empirical Analysis of Permission-Based Security Models and its Application to Android[END_REF][START_REF] Davi | Privilege Escalation Attacks on Android[END_REF], which led to a number of extensions to the Android architecture [START_REF] Bugiel | Practical and Lightweight Domain Isolation on Android[END_REF][START_REF] Shabtai | Securing Android-Powered Mobile Devices Using SELinux[END_REF][START_REF] Ongtang | Porscha: Policy Oriented Secure Content Handling in Android[END_REF]. In contrast to our approach, these user-level isolation mechanisms usually require massive modifications to Android userspace components and introduce more complexity to the overall system.

Isolation based on operating system-level virtualization, as used in our approach, is a common concept of Unix-like operating systems today, especially on servers. In [START_REF] Andrus | Cells: A Virtual Mobile Smartphone Architecture[END_REF] Cells is introduced, a virtual mobile smartphone architecture, which utilizes Linux containers for isolation of two Android userspace instances running on one smartphone. In contrast to our approach, Cells does not focus on security. Specifically, it does not utilize access control policies and does not provide integrity protection or transparently encrypted and tunneled network connections.

Another approach to isolate runtime environments with different security requirements is system virtualization. System virtualization allows one to run multiple operating systems on one physical device using an additional software layer (a hypervisor [START_REF] Hwang | Xen on ARM: System Virtualization Using Xen Hypervisor for ARM-Based Secure Mobile Phones[END_REF] or microkernel [START_REF] Lange | L4Android: A Generic Operating System Framework for Secure Smartphones[END_REF]) as shown on the right side in Figure 1. This approach is also often used to add isolated security extensions to desktop or server systems [START_REF] Alkassar | Security Architecture for Device Encryption and VPN[END_REF][START_REF] Hartig | The Nizza Secure-System Architecture[END_REF][START_REF] Garfinkel | Terra: A Virtual Machine-Based Platform for Trusted Computing[END_REF]. Since current smartphone hardware does not provide hardware-assisted virtualization extensions, todays implementations usually require a paravirtualized kernel, like L4Android [START_REF] Lange | L4Android: A Generic Operating System Framework for Secure Smartphones[END_REF] for example. The main disadvantage of this approach is the complex and time-consuming act of porting software to new hardware and new Linux kernel versions. Furthermore, this approach usually results in a higher performance overhead when compared to operating system-level virtualization. This is mainly caused by additional context switches.

A trusted execution environment (TEE) is an isolated runtime environment for applications with high security requirements. These are typically used to implement a SE-like functionality on the same hardware as the normal system. Since access to TEEs is usually restricted by the device manufacturer and TEEs cannot provide the level of security that a SE can, we have chosen to use an external SE built into a microSD card for our prototype.

Our concept is based on operating system-level virtualization, which provides userspace containers to isolate and control the resources of single applications or groups of applications running on top of one kernel as shown in the middle of Figure 1. This typically includes a unique hostname, process identifiers (PIDs), inter-process communications (IPCs), a filesystem, and network resources.

A trustworthy control and management environment is the first to run after boot and is the only component with full system access. Depending on the desired level of security, several Android userland instances are started from this environment or, alternatively, it ensures that only one additional Android userland instance is running at the same time. This means that processes are either frozen and not scheduled or stopped and removed from memory. In the following figures, we only depict a simplified system with one Android userspace instance. Figure 2 shows the basic concept of operating system-level virtualization exemplarily for PIDs. From inside the container, only the processes corresponding to the particular container are visible. For an Android userland this looks like a process tree on a regular device. On the right side, the full system is shown including the processes 1, 2, 11 and 12 running outside of the container. The PIDs of the processes inside the container are mapped accordingly. Other resources are handled in a similar way.

A major advantage of this virtualization technique compared to system virtualization is that the isolation layer -here the kernel -has full control over all resources and can directly interfere at all processing layers and in all subsystems. This allows fine grained policy enforcement for system calls and integrity measurements of sensitive application groups at runtime. Additionally, for any input/output operation to devices, system call hooks can be used to add security extensions. We show four common implementation strategies of this approach in Section 7.

In this section, we give an overview of security mechanisms and their integration in our basic concept. We systematically cover the three security aspects: isolation, communication, and storage. Most mechanisms are optional and can be applied to one or more containers if desired. The mechanisms are grouped into the following categories: remote management, capabilities and access control, network, storage, and display and user input.

Remote Management

A core component of our concept is a powerful remote management component. The trusted control and management component on the smartphone is isolated from the Android userspace through operating system-level virtualization as described in Section 5. It establishes a secure connection to a management server to fetch information. Alternatively, the management server can initiate the connection if the device has a public IP address or a VPN connection is already established (see Section 6.3). It is also possible to send an encrypted SMS to control the device. Since it is possible to send new binaries and scripts to the device, nearly everything can be triggered remotely. This also includes software updates independent from the device manufacturer to fix disclosed vulnerabilities and updates for integrity reference values and access control policies.

Capabilities and Access Control

On a stock Android system, the root user has full control over the system. Capabilities enhance the system security by enabling more fine-grained access control. This includes rebooting the system, configuring the network, loading kernel modules, and overriding file access permissions for example. Our concept ensures that all capabilities that are not necessary for an application to work properly are dropped systematically.

A similar approach is realized for access to devices, e.g., framebuffer, camera, network, and storage devices. So it is (remotely) configurable whether and when an Android container gets access to these devices.

To provide even more fine-grained access control, our concept provides access control for system calls based on well-known security models like mandatory access control (MAC) and access control lists (ACLs) as already utilized in other papers [START_REF] Shabtai | Securing Android-Powered Mobile Devices Using SELinux[END_REF][START_REF] Zhang | A Trusted Mobile Phone Reference Architecture via Secure Kernel[END_REF]. In our system, policies are typically configured by the administrator or automatically generated in learning mode or permissive mode. Another approach here is the automatic generation of policies on one reference smartphone, then slightly modified by an administrator, and finally the distribution to all managed devices.

Network and Telephony

A core component of our concept is the restriction of network and telephony services. Network filtering and routing can only be configured from the trustworthy environment. This includes the routing of all connections from and to an Android userland through an encrypted virtual private network (VPN) tunnel as shown in Figure 3. In this scenario, the Android userland accesses a virtual ethernet interface (veth0), which is bridged (br0) with a tunnel interface (tun0) of a VPN. The asymmetric keys are stored in the SE and the negotiation of a symmetric session key is handled entirely in the SE. The secret key never leaves the SE. Additionally, to prevent unauthorized access to the VPN, the SE is protected with a personal identification number (PIN) as described in Section 6.5. Besides the network routing, in Figure 3 a scenario is shown, in which the Android userland cannot configure or access the WLAN interface (wlan0). This is only possible from the trustworthy part of the system. The authentication for encrypted WLANs can be handled similar to the VPN authentication. The second main communication channel to the outside world is the GSM/UMTS/LTE radio interface. Besides packet-based communication as described above, a common use case here are filter functions for SMS and calls. It is also possible to have separate phone numbers and connections for more than one Android container using VoIP for telephony as described in [START_REF] Andrus | Cells: A Virtual Mobile Smartphone Architecture[END_REF].

Kernel

Storage

Virtualizing the root filesystem of the Android containers allows easy integration of snapshot and recovery functions and remote wipe functions as well as full and transparent root filesystem encryption. Furthermore, we apply integrity protection mechanisms to files as described in the following. Figure 4 shows a typical scenario with filesystem encryption and integrity protection controlled from the trustworthy control and management environment. Encryption Storage encryption can be integrated at the device level for a whole filesystem or at a per-file basis. Our default configuration uses an encrypted file system image, either in a single file or in a separate partition which is mounted during the start of a container. The block-based symmetric encryption and decryption (e.g., aes-cbc-essiv) is handled by the kernel, which means that the key needs to be available in the kernel. Of course, the key is only accessible from the trustworthy environment during runtime and it is not accessible from Android containers. Furthermore, the key is never written unencrypted to persistent storage readable for an attacker on a switched off device. Instead, it is stored in the SE and protected with a PIN (see Section 6.5). Furthermore, if the security policy for the device allows only one active container at a time, the key is erased after the container is stopped and before another container is started. Highly sensitive information can also be encrypted and decrypted directly in a SE with a lower data throughput. Another option would be the utilization of a TEE-based implementation.

Integrity Protection Basically, integrity protection can be enforced at the start of a container either on a whole filesystem or on a per file basis. This is especially useful after a recovery of the filesystem. Furthermore, our concept provides integrity protection of files while an Android container is running. Based on a whitelist or blacklist of file hashes, reading and/or writing to/from files is allowed or forbidden. This mechanism allows us to control which applications and system components are installed in the Android userland and to enforce that these applications and components fulfill certain requirements, like blacklisting of vulnerable versions of applications. It also allows blacklisting of known Malware. Our implementation for this mechanism is described in detail in Section 8. A similar approach could also be used for anomaly detection at runtime.

Display and User Input

A common problem for business and payment scenarios is the need for a trusted graphical user interface (GUI) for a secure password entry, e.g., to unlock a SE.

Our concept uses a SE to store keys for several use cases and therefore also requires a secure password input dialog. Moreover, in our prototype switching from one Android container to another typically also requires a password.

To not introduce a performance impact, we usually give exclusive and full access rights to one Android container for the screen and touchscreen. To switch to the trustworthy environment, we use a hardware key (typically the power button). Additionally, we utilize the hardware LED of the device to indicate which environment receives the touchscreen events and which environment has access to the screen at the moment. Depending on the capabilities of the smartphone, different colors are associated to different containers (e.g., green for corporate, blue for private, red for guest and white for the trusted environment including the secure password entry). Of course, Android containers cannot directly access the LED driver any more.

Input and Output Hooks

In our concept, access to devices (like the LED) and other components needs to be restricted and sometimes virtualized to ensure the system's security. In this section, we give an overview of the generic approaches used in our implementation. Figure 5 shows four implementations to interfere with input and output operations to devices. Depicted are the data and control flow and the (un)modified components. The four implementation concepts are described in the following.

1. An unmodified Android userland component sends and receives data directly to/from a kernel component which has direct access to the hardware. The Android userspace has no permission to control the kernel component. This is reserved for the control and management environment. An example for this scenario is storage encryption, whereby the Android userland cannot set or get the encryption key (see Section 6.4).

An unmodified Android userland component sends and receives data directly

to/from a kernel component which forwards this data to a trusted control component which itself forwards the data to a kernel component. This is to/from a trusted userland component. The communication can be based on a shared memory segment or another IPC mechanism. For filtering purposes, this approach can provide already preprocessed data, which might be simpler to handle. An example for this scenario is the replacement of the rild or wpa supplicant binaries in the Android userspace with stubs, if the Android userland does not have the permission to directly configure the radio modem and WLAN interface. On a device with more than one Android userland, this approach can also be used to share components between the Android userlands, e.g., the address book, or for multiplexing devices. 4. A special Android application communicates with a trusted component. This scenario can be used to allow an Android application to call a trusted dialog implemented in a trusted component outside the Android container, e.g., a password entry dialog. This can be useful for a modified Email application with SE-based S/MIME signatures.

Prototype Implementation

Our prototype implementation uses Debian GNU/Linux for the trusted control and management environment and to verify the portability of our approach, we used a rather old Android 2.3.5 on a Google Nexus One and a recent Android 4.0.4 on a Samsung Galaxy S3 for the Android userspace instances. In both cases, the filesystems are stored on a microSD card. The stock kernel was modified to support Linux containers for operating system-level virtualization. This mainly includes resource isolation based on namespaces and resource control based on Linux kernel control groups (cgroups). Most capabilities are dropped for containers and access to devices etc. is restricted. Most of our additional concepts are implemented based on the generic approaches described in Section 7. However, one primary aspect of our approach is described in the following in more detail.

Our access control and integrity protection mechanisms are based on Linux Security Modules (LSM) [START_REF] Wright | Linux Security Modules: General Security Support for the Linux Kernel[END_REF], which provide lightweight, general support for access control by allowing modules to define security hooks for system calls. This allows a straightforward integration of task hooks, program loading hooks, IPC hooks, filesystem hooks, network hooks, module hooks (e.g., module initialization) and system hooks (e.g., hostname setting). The called hook function can allow or deny the requested access. This approach has also been used by other research papers, which utilize Linux Security Modules on an Android system without operating system-level virtualization. These typically utilize a module directly included in the mainline Linux kernel, like TOMOYO or SELinux [START_REF] Shabtai | Securing Android-Powered Mobile Devices Using SELinux[END_REF][START_REF] Zhang | A Trusted Mobile Phone Reference Architecture via Secure Kernel[END_REF]. Of course, without a container-based virtualization environment, all userspace components need to be included in the Android userspace. Here, we have a significant advantage in our virtualized system where the userspace components run in the trustworthy environment. As an example, in Figure 4 a typical storage scenario with two security extensions is shown. First, we use the device mapper (DM) in the kernel for transparent encryption. It is controlled by the userspace tool cryptsetup running in the trustworthy environment. Second, for integrity protection, we use a LSM implementation controlled by our userspace daemon icheck. Figure 6 shows the control and data flow for file-based read (left side of the figure) and write (right side of the figure) operations. In our prototype implementation, this daemon calculates a SHA1 of files on file accesses and compares this hash with a whitelist of hashes stored in the trustworthy environment. If a hash is not found in the whitelist, access will be denied. The whitelist for system components is usually distributed with the system image and the whitelist of Android applications can either be distributed via the remote management interface or directly generated on the device by verifying and analyzing Android application packages (apk) including its cryptographic signatures.

Evaluation and Measurements

In this section, we present measurements regarding the performance impact, the power consumption, and the memory usage of our prototype implementation. The measurements show that our approach has a very limited impact on the performance of the system and especially the power consumption. Finally, a security evaluation is given.

All measurements were done for three Android environments running on a Google Nexus One with equal configuration parameters and with the same set of Android system services and applications running in the background:

1. Default Android An Android userland is running directly on the system without operating system-level virtualization and without a trusted control and management entity. This is the reference value in the following figures (7, 8 and 9).

2. Container An Android userland is running inside a Linux container. All security extensions which may result in an overhead are disabled. 3. Encrypted Container An Android userland is running inside a Linux container and the whole filesystem of this container is encrypted.

Power Consumption

Power consumption of the device is measured in three typical usage scenarios.

In the first scenario, the device runs continuously in the idle state without communication over WLAN or cellular and with display backlight turned off. In the second scenario, a music player application runs in the foreground while the display is still turned off. In the third scenario, the power consumption is measured during the usage of the web browser. Here, the display is turned on and user interaction is simulated every five minutes. Figure 7 shows our results. The highest impact on the power consumption was measured in the idle test scenario with 7.5 percent for the encrypted container and 7.1 percent for an Android container without storage encryption. For the music player scenario, the impact goes down to 4.0 and 3.6 percent and for the web browsing scenario it's below 1 percent for both containers. This increased power consumption is mainly a result of additional threads running outside the Android container in the trustworthy environment.

Idle

Performance

We run six Android benchmarks to measure the performance impact of our approach compared to a default Android userland without operating systemlevel virtualization. The results are shown in Figure 8.

Most benchmarks show less than 1 percent variation in performance overhead for Android containers. This shows that our approach provides nearly native performance for an Android userland running inside a Linux container. However, there are some values, which will be explained a little more closely. AndroBench Storage benchmark shows a higher performance for an Android container with encrypted root filesystem. This can be explained by an additional caching of the encrypted filesystem image, which cannot be prevented by the benchmark tool. Next, the boot procedure of an Android container is considerably faster due to different caching behavior, as shown in the next section.

Memory Usage

In Figure 9, the memory usage of the whole system is shown. A system with operating system-level virtualization naturally results in a slightly higher memory usage (depicted red). Noticeable here is the much higher amount of memory used for caching (depicted blue). For our measurements, we considered two system states. First, the memory usage of the system after the boot (depicted on the left) and second, the increase of memory usage after the start of additional applications (depicted on the right).

No Apps Apps

Security Evaluation

Our implementation is based mainly on two Linux kernel-level security mechanisms, namely Linux containers including namespaces and control groups, and Linux security modules. Because of our systematic approach to drop as many capabilities and privileges as possible and to restrict inter process communication, we can provide a higher security level than a stock Android system. In particular, getting root access rights to get full control over the system is a common attack vector on stock Android systems. In our system, root access in an Android container does not provide full control over the system and more importantly no access to confidential keys stored in the SE. Furthermore, practical tests showed that our integrity protection mechanism can reliably prevent the installation of unknown and therefore possibly malicious applications. Finally, we prevented real attacks using exploits for the /dev/exynos-mem device security hole found in the stock Samsung Galaxy S3 firmware (CVE-2012-6422).

Comparing our approach to other virtualization techniques for Android as described in Section 3 indicates the following. On the one hand, our implementation has a smaller trusted computing base (TCB) compared to user-level isolation. Not sharing the middleware layer simply means that attacks on this layer, as described in [START_REF] Davi | Privilege Escalation Attacks on Android[END_REF], are not possible between Android containers. On the other hand, system virtualization with a focus on security (e.g., based on a microkernel) has a smaller TCB. However, this approach typically has practical disadvantages as already mentioned, but can be combined with our approach, e.g., in form of a TEE. To protect highly sensitive information in our prototype, we utilize a hardware SE to provide an even higher level of security including hardware-based attacks.

Conclusion

In this paper, we presented a lightweight mechanism to isolate one or more Android userland instances from a trustworthy control and management environment. In contrast to existing solutions based on full system virtualization, our approach requires no complex software modifications.

Additionally, we implemented several security extensions. A key functionality is the easy remote administration and management of mobile devices. Further key features are transparent encryption and tunneling of network connections and transparent storage encryption, where the Android userland does not have access to the used cryptographic keys. Moreover, we implemented integrity protection mechanisms and a secure GUI for password entry dialogs etc.

Our evaluation results show that our approach is practical and introduces only a negligible performance overhead and reduces the battery lifetime by only 7.5 percent in the worst case.

Fig. 2 .

 2 Fig. 2. Mapping of PIDs (Background Colors as in Figure 1)

Fig. 3 .

 3 Fig. 3. Network with Transparent VPN

Fig. 4 .

 4 Fig. 4. Storage with Encryption and Integrity Protection

Fig. 5 .

 5 Fig. 5. Implementations to Interfere with Input and Output Operations of Containers

Fig. 6 .

 6 Fig. 6. Data and Control Flow for File-based Integrity Measurements

Fig. 9 .

 9 Fig. 9. Memory Usage for Default Android and Containers

Acknowledgments. Parts of this work were supported by the German Federal Ministry of Education and Research (BMBF) under grant 01BY1011 within the project ASMONIA.


Hartmut Hintze
email: hartmut.hintze@tuhh.de

Benjamin Wiegraefe
email: benjamin.wiegraefe@tuhh.de

Ralf God
email: ralf.god@tuhh.de

A security engineering process approach for the future development of complex aircraft cabin systems

Keywords: Security, Aircraft Cabin Systems, Complex Systems, Development Process, Three-V-Model, Security Context Parameters

Due to increasing functionality associated with rising complexity of aircraft cabin systems which are used by cabin crew, passengers, maintenance staff and other stakeholders, security engineering has to become an integral part of the system engineering process in aviation industry. This paper deals with a security engineering process approach for the development of complex aircraft systems, which is fully integrated into the development process. As an appropriate process model we introduce the so called three-V-model, which represents the governing system engineering process (SEP) associated with the safety engineering process (SafEP) and the security engineering process (SecEP). All three processes are pursued concurrently and are interacting reciprocally on each development level with the predominant SEP. We describe in detail involved security engineering activities and finally demonstrate how the interaction between the SEP and the SecEP is improved and optimized by the use of so called security context parameters (SCPs).

Introduction

The cabin management system takes on a central role for all tasks to operate the aircraft cabin. Primary functions are communication, indication, control, monitoring and configuration of other cabin systems. For this reason it represents a complex system characterized by a large amount of interactions between a plurality of aircraft cabin systems. To achieve the objectives of SAE ARP-4754 [START_REF] Eurocae / Sae | Certification considerations for highly-integrated or complex aircraft systems[END_REF] for certification of highly integrated and complex aircraft systems, the development process is following a process model which is called the V-model. The development of the system functions is supported by the safety assessment process [START_REF] Eurocae / Sae | Certification considerations for highly-integrated or complex aircraft systems[END_REF][START_REF] Eurocae / Sae | Guidelines and methods for conducting the safety assessment process on civil airborne systems[END_REF], which follows a V-model as well and has to ensure the reliability of the system functions. The combination of the functional V-model and the safety V-model is known in literature as the Two-V-Model [START_REF] Benz | Eine Entwicklungsmethodik für sicherheitsrelevante Elektroniksysteme im Automobil[END_REF]. To cover security requirements which are related to the system functions, the recent EUROCAE / RTCA documents [START_REF]EUROCAE / RTCA: Airworthiness security process specification[END_REF] provides guidance material for a security engineering process. This process will become mandatory for the development of aircraft cabin functions and related systems. In this paper we take up this approach, refine it and integrate it as a 'third V' to end up with an appropriate and comprehen-sive new process model for the development process in aircraft industry. The resulting Three-V-Model is intended to be used as the baseline for the development of future aircraft cabin systems and will consider the system engineering process (SEP) associated with the safety engineering process (SafEP) and the security engineering process (SecEP) at the same time. Furthermore the interactions between the SEP and the Se-cEP are improved via the introduction of so called security context parameters (SCPs). Theses parameters help to quantify and transfer required information for security management from the SEP to the SecEP and vice versa. This approach avoids time consuming information filtering work at SecEP side and thus provides the opportunity for speeding up the overall development process.

System Security in the development of cabin management systems

Historical overview

Within the past 20th century engineering work in commercial aviation was focused on improving the performance parameters for higher payload, extended range, higher speed and more comfort for the passengers. Important milestones were reached by major achievements in aircraft design, engine technology and by the use of pressurized cabins for higher cruise altitude. The use of electronics within passenger aircraft started with engine control in the 1950s and then in the 1970s was extended to electronic flight control. A peak was reached in 1988 when Airbus introduced its fully digital fly-by-wire technology in the A320. With this aircraft, Airbus completely discarded the use of analog primary flight controls and replaced them by fully computer-controlled digital signaling via an avionics data communication network to control hydraulic actuators at the flight-control surfaces.

Today, in the 21 st century the focus has moved to the aircraft cabin with its complex systems. The cabin is the central element within air travel and the business card of the airline. The primary transport service of an airline comes along with a fierce competition for customers and forces the airline to deal intensively with passenger's future travel requirements. The cabin management system with its various service functionalities plays a central role in this struggle for customer satisfaction. Electronics and data network of the cabin management system have continuously been refined over the past 25 years. This on-going evolution led to a mature and sophisticated system. However a still increasing range of cabin functions, maintenance tasks and passenger services and a related growing amount of processes are now culminating in a challenging situation where the existing architecture needs to be reconsidered and reworked in terms of flexibility and scalability to be fit for the future.

Preferred types of architectures for next-generation cabin management systems are based on the concept of distributed systems with wireless communication links e.g. for ad-hoc-sensor networks, mobile PCs and other mobile devices to satisfy the needs of the various stakeholders in the cabin [START_REF] Hintze | Cabin core system -A next generation platform for combined electrical power and data services[END_REF][START_REF] Rosenberg | Cabin Management Systems[END_REF]. These novel architecture principles aboard passenger aircraft place special emphasis on the aspects of security. In the past, security was mostly handled by physical security mechanisms: the hardware was physically separated, software was encapsulated and communication paths were regulated and secured. But for distributed architectures with wireless communication interfaces the means of physical security mechanism is no longer sufficient. Hence, it is necessary to establish logical security mechanisms, i.e. security mechanisms against unauthorized access to communication networks, software, information and data of a system. Furthermore, the unauthorized execution of activities within the system has to be prohibited. Logical security in aircraft is becoming more and more a challenge and therefore has to be considered from the very beginning when developing a new aircraft.

2.2

The need for a change A closer look into today's cabin management systems proves that an evolutionary system extension lead to the involvement of new stakeholders, an integration of a multitude of functionalities to deal with novel use cases and to an extension of data intercommunication to infrastructures outside of the cabin as describes in [START_REF] Rosenberg | Cabin Management Systems[END_REF]. This progression was mainly achieved on a system level and thus can be considered to be a bottom-up approach in the development process. In consequence the emerging security issues were predominately handled on a system level as well. This strategy has led to a substantial workload dealing with security at a late engineering stage during the overall aircraft development process. According to systems engineering principles [START_REF] Ebert | Systematisches Requirements Engineering[END_REF] it is feared that this strategy can negatively influence development timelines and development cost and may even lead to imperfect or unsatisfying technical solutions.

To cope with these potentially adverse effects there is the need for a change in the development strategy which relocates a significant part of security engineering activities to the first development level, i.e. the aircraft level, and thus enables a favored top-down approach. This top-down approach for security management is feasible when an optimized and standardized communication starts already on an aircraft development level. Further refinement on subsequent development levels will then be reached with reduced effort and in a more directed manner.

Such type of top-down approach for a security engineering process is generally applicable, e.g. in automotive and railway industry or for nuclear power plants and electric power utilities. Due to our specific work in aircraft industry and security, we have tailored this approach to the development of a next-generation cabin management system. The above mentioned means of logical security coming along with novel system architectures in the cabin will be considered.

2.3

The Three-V-Model

Figure 1 shows our so called Three-V-Model. The first V represents the fundamental system engineering process (SEP) for the development of aircraft functions according to literature [START_REF] Eurocae / Sae | Certification considerations for highly-integrated or complex aircraft systems[END_REF]. The two branches of this V are symbolizing the three major phases of system design, implementation and system integration. The second V ac-companies and supports the basic SEP and represents the safety engineering process (SafEP). This process is well known from literature [START_REF] Eurocae / Sae | Guidelines and methods for conducting the safety assessment process on civil airborne systems[END_REF] and focuses on system safety requirements and airworthiness design, i.e. reliability and fault tolerance topics. To make sure that for novel aircraft system architectures the security requirements are visualized and encountered more comprehensively and at an early stage during the development process we introduce an accompanying and supporting third V, which represents the security engineering process (SecEP). A generic specification for a SecEP is given in [START_REF]EUROCAE / RTCA: Airworthiness security process specification[END_REF]. To cope with all particular guidelines of the aircraft development process we further on refer to this Three-V-Model as a comprehensive process model. In this model the SEP for the development of system functions, the SafEP covering system reliability and the SecEP to protect the system from attack and misuse are pursued in a concurrent way. Figure 1 additionally illustrates, that the requirements for the system functions in the SEP are governing the respective safety and security requirements and these requirements reciprocally affect the system functions. The Three-V-Model ensures that for the design of future cabin management architectures the security aspects are encountered right from the beginning. This will guarantee that the required security level (SL) can be finally reached and security can serve as an enabler for the intended system functions.

2.4

The Aircraft Domain Model Within the well-established safety engineering process (SafEP), i.e. the 'second V', the so called design assurance level (DAL) is defined at an early stage during the development phase. The DAL is introduced by the EASA and FAA documents CS 25.1309 and FAR Part 25.1309 [START_REF]FAA: Equipment, systems, and installations[END_REF] and specifies the relationship between the likelihood that a system functions fails and the respective consequences for the aircraft within its mission. Accordingly, the total loss of the aircraft must be extremely improbable whereas some slight inconvenience to occupants, e.g. the loss of in-flight entertainment, can be tolerated.

By analogy with the DAL definition, the security development process (SecEP) is using a security level (SL), which is currently related to a specific categorization of aircraft cabin functions. In detail this classification is derived from the so called domain model of the aircraft network. This domain model is shown in Figure 2. The ARINC report 811 [START_REF]ARINC: Commercial aircraft information security concepts of operation and process framework[END_REF] refers to these four aircraft domains for a classification of security domains. The first domain, the aircraft control domain (ACD), represents the highest criticality level and hosts all flight relevant and embedded control functions. Furthermore, basic cabin safety functions are located within the ACD as well. The airline information and services domain (AISD) contains all global functions for cabin operation and maintenance purposes which are not safety critical. This implies that the AISD has a lower SL than the ACD. An even lower SL is assigned to the passenger information and entertainment services domain (PIESD) with its adjacent passenger owned devices domain (PODD) at lowest SL. These two domains host information and entertainment functions and deliver interfaces to connect passenger notebooks or other mobile devices to the aircraft.

However it must be taken into account that a sustainable and more generic approach for a security engineering process must be applicable to all existing and pro-spective cabin functions and nevertheless should be in accordance with the nowadays defined domain allocation. Therefore a top-down approach for the security management process which matches with the conventions of the past and allows an efficient handling of challenges in the future has to be ensured. The next chapter describes such type of a top-down approach, i.e. a generic security engineering process.

A generic security engineering process approach

There are three major objectives for a generic and efficient security engineering process in aircraft development. The first is a top-down approach, i.e. security engineering has to start at the very beginning of the development and to follow the overall process. The second is a global applicability to existing and prospectively expected aircraft functions and the third is an enhanced communication between engineering departments by using a standardized information transfer for security topics on all development levels. The subsequent four sections will provide an elucidation of an approach which is able to comply with these three major objectives:

1. Execute SEP and SecEP concurrently and on all development levels 2. Define the links for process interaction and synchronization 3. Specify the SecEP objectives at a particular development level 4. Use security context parameters (SCPs) for standardized communication

Execute SEP and SecEP concurrently and on all development levels

The Three-V-Model in Figure 1 suggests three concurrent processes during system development, i.e. the system engineering process (SEP), the safety engineering process (SafEP) and the security engineering process (SecEP). The SafEP and the SecEP are interacting reciprocally with the governing SEP. Figure 3 provides a more detailed view to dedicated development levels. The illustration focuses on the simultaneous execution of the SEP and the SecEP during the functional development of the system, i.e. the system design phase which is represented by the left branch of the V-model. Note, that the established SafEP will not be considered hereafter. Due to the high complexity of aircraft, the design phase is subdivided into four development levels (cf. Figure 3): the aircraft level, the multi-system level, the system level and finally the item level. Each development level refines the higher level information to an appropriate granularity until the design process reaches the lowest development level, which is the item level. The aircraft level, system level and the item level are defined and described in [START_REF] Eurocae / Sae | Certification considerations for highly-integrated or complex aircraft systems[END_REF]. The inserted multi-system level is deduced from EUROCAE ED-202 [START_REF]EUROCAE / RTCA: Airworthiness security process specification[END_REF], which proposes a security management process for all development levels and points out the need to additionally consider the aircraft domain model (cf. section 2.4) for the risk management within the SecEP. This prerequisite can be referred to a treatment on a multi-system development level. Unfortunately the SEP, as it is today, does not address a multi-system development level. This is due to the fact that still today aircraft functions are grouped and developed hierarchically according to historically defined ATA chapters [11] which do not sufficiently consider system interactions and crosscutting aircraft functions. Hence we have introduced and inserted an implied multi-system level between the aircraft level and system level to consider the aircraft domain model.

Define the links for process interaction and synchronization

In order to perform security management within the SecEP the current proposal in EOROCAE and SAE documents [START_REF] Eurocae / Sae | Guidelines and methods for conducting the safety assessment process on civil airborne systems[END_REF] is to have an information transfer from the established SafEP to the prospective SecEP. In contrast to this proposal we advocate a direct information link in-between the leading SEP and the parallel and equal SecEP. This is because the complexity of future aircraft systems with progressive logical security considerations requires a security management process, which is no longer a derived subset of the SafEP, but has to be an autonomously executed process and thus has to have direct links to the governing SEP. These links interlace the SecEP and the SEP by peer-to-peer interaction. This finally leads to a concurrent and continuously interacting process flow which is schematically shown in Figure 4.

In line with both, the guidelines for the SecEP [START_REF]EUROCAE / RTCA: Airworthiness security process specification[END_REF] and the ISO27005 information technology framework for security techniques and information security management systems [START_REF]Information technology -Security techniques -Information security risk management[END_REF] Figure 4 provides a more detailed view on aircraft level to the synchronization of the SEP and SecEP. Harmonization of [START_REF]Information technology -Security techniques -Information security risk management[END_REF] and [START_REF]EUROCAE / RTCA: Airworthiness security process specification[END_REF] is ensured, because the latter one only claims the need for a global security management process and [START_REF]Information technology -Security techniques -Information security risk management[END_REF] explicitly expresses required SecEP activities and covers them in detail. The ISO 27005 framework [START_REF]Information technology -Security techniques -Information security risk management[END_REF] defines the following required activities: concept establishment, risk assessment, risk treatment and risk acceptance. The risk assessment is further split into risk identification, risk estimation and risk evaluation as per definition of [START_REF]Information technology -Security techniques -Information security risk management[END_REF]. A comparable refinement of the SEP activities on aircraft level can be deduced from the system development lifecycle according to [START_REF] Eurocae / Sae | Certification considerations for highly-integrated or complex aircraft systems[END_REF] which defines the four development phases of concept, functions, architecture and design. During concept phase the SEP gathers general and supportive information which is prerequisite for the development of an aircraft. This information might be the operational environment of the considered aircraft including stakeholders, requirements and experience from the development of aircraft in the past. On the next stage follows the elicitation of functions by using the information acquired during the concept phase. During the subsequent architecture phase, the defined functions together with functional requirements are then used to draft the architecture, which assigns the interaction of all pre-defined stakeholders and functions. The subsequent design phase may particularize the proposed architecture, e.g. by a further refinement of functions and assigned stakeholders. However depending on a specific development level the realization of a design phase is optional. Now it is possible to interlink and synchronize the SecEP with the SEP at defined interaction points. This interlink stipulates the required information exchange which is necessary for the SecEP to be able to perform its activities during the security development cycle. The output of the SEP concept phase is directed to the SecEP concept activity, for establishing all process supporting information. A feedback to the SEP is not required because the output of the SecEP concept is mainly security relevant policies and guidelines. The architecture phase and design phase are linked to the security development cycle as given by the ISO 27005 framework [START_REF]Information technology -Security techniques -Information security risk management[END_REF]. The latter one enquires SEP information details and therefore specifies the content of the information which has to be exchanged.

The intensity of the performed activities during the security development cycle will differ at specific development levels depending on the SEP derived information details and drive the objectives of the SecEP at a particular development level.

Specify the SecEP objectives at a particular development level

A fundamental principle of the V-model is the continuous elaboration of details during the design phase. Engineering information is continuously refined on a dedicated development level. In aircraft development this means that on the initial aircraft level there is predominantly notional information, i.e. abstract data without reference to any technical solution. The aircraft level basically specifies functional groups. Hence, the objectives for the SecEP at aircraft level are an investigation on the consequences and on the probability of the loss of functional groups, i.e. the scope or impact of a loss and the likelihood that an attack is successful and will cause such loss. The impact can be assessed via flight safety relevant and commercial aspects of an investigated functional group. This is similar to activities within the SafEP [START_REF] Blanquart | Similarities and dissimilarities between safety levels and security levels[END_REF] and thus can be parallelized. The likelihood can be assessed via known communication paths and their classification into communication partners, communication type and direction. The multi-system level refines the functional groups (e.g. lighting) into generalized aircraft functions (e.g. cabin lighting, emergency lighting and exterior lighting) and allocates them within the aircraft domain model. Thus, major objectives on multisystem level are an impact analysis of the loss of generalized functions on multisystem level, an estimation of the likelihood of an attack, an assignment of attack paths and a security domain allocation. Again the impact can be assessed via flight safety relevant and commercial aspects of a generalized function. On multi-system level the likelihood can be assessed via a known communication partner, a communication direction, the type of information and the purpose of received information. The assessment of these parameters provides additional information on a possible attack path and enables the allocation within the aircraft domain model.

The definition of objectives on an aircraft and multi-system level leads directly to a consistent top-down approach, which can be seamlessly used as a superstructure for nowadays performed security activities on the system level. This generic SecEP approach provides the advantage of filtering out non-security relevant function groups and generalized functions at earlier development levels. This avoids costly and timeconsuming work on later development levels, e.g. the system level. The subsequent section will show how a straightforward and standardized exchange of pre-defined information in-between SEP and SecEP can be achieved by introducing security context parameters (SCPs).

3.4

Use security context parameters (SCPs) for standardized communication

The security context parameters are introduced to extract the beforehand identified security relevant information from the SEP in a standardized and simple way. Keeping it short and simple is beneficial, because the system designer in the SEP usually has less knowledge about security management issues and therefore needs to be guided and supported by experts from the SecEP. Standardization can be accomplished by implementing and using predefined security context parameters (SCPs) comprised of parameter types and valid values. Due to a specific level of detail during aircraft development, the parameter types and values are dependent on a specific development level. Parameter types and values representing the aircraft level are given in Table 1. Referring to [START_REF]Information technology -Security techniques -Information security risk management[END_REF] the function group name assigns a considered asset. For each function group the possible communication partners are specified to address the likelihood and to identify possible attack paths.

A more detailed description of communication requires the communication direction and the type of communication. Valid values for the communication direction are bidirectional or unidirectional. The communication type distinguishes between variable data or pre-defined discrete information. As a result the communication direction and type of communication allows determining the likelihood of an attack of a function group. In spite of this simplicity the SCPs allow to achieve the defined SecEP objective at aircraft level, i.e. to differentiate between security and non-security relevant function groups.

Analogously, parameter types and values representing the multi-system level are given in Table 2. Due to a higher level of detail during the multi-system development phase, these parameter types and values are more specific.

Fig. 1 .

 1 Fig. 1. The Three-V-Model derived from EUROCAE, SAE and RTCA guidelines [1-2, 4] for the systems engineering process (SEP), the safety engineering process (SafEP) and the security engineering process (SecEP)

Fig. 2 .

 2 Fig. 2. The aircraft domain modelThe domain model of the global aircraft network architecture which is specified by the ARINC report 664P5[START_REF]ARINC: Network domain characteristics and interconnection[END_REF] comprises four different domains and is depicted in Figure2. The ARINC report 811[START_REF]ARINC: Commercial aircraft information security concepts of operation and process framework[END_REF] refers to these four aircraft domains for a classification of security domains. The first domain, the aircraft control domain (ACD), represents the highest criticality level and hosts all flight relevant and embedded control functions. Furthermore, basic cabin safety functions are located within the ACD as well. The airline information and services domain (AISD) contains all global functions for cabin operation and maintenance purposes which are not safety critical. This implies that the AISD has a lower SL than the ACD. An even lower SL is assigned to the passenger information and entertainment services domain (PIESD) with its adjacent passenger owned devices domain (PODD) at lowest SL. These two domains host information and entertainment functions and deliver interfaces to connect passenger notebooks or other mobile devices to the aircraft.However it must be taken into account that a sustainable and more generic approach for a security engineering process must be applicable to all existing and pro-

Fig. 3 .

 3 Fig. 3. Development levels of SEP and SecEP and interactions during the design phase

Fig. 4 .

 4 Fig. 4. Particularized SecEP activities at aircraft level interacting with the governing SEP

Table 1 .

 1 Security context parameters (SCPs) on aircraft development level

	Parameter Type	Valid Values
	Function Group Name	[aircraft function group name]

Communication Partner [stakeholder, aircraft function group] Communication Direction [bidirectional, unidirectional (send), unidirectional (receive)] Type of Communication [variable data, pre-defined discrete information]

Forwarding information means piping the received information to other functions without using or processing it.

Using information means utilizing the received information without processing it, e.g. displaying video or audio information.

Processing information means converting and forwarding information to other functions, e.g. information is compressed, decompressed or checked and forwarding it.

Executing information means to use received information for the execution of connected functions, e.g. remote control of a function by another function.

Referring to [START_REF]Information technology -Security techniques -Information security risk management[END_REF] at multi-system level the function name assigns a more detailed asset. Consequently the communication partners are particularized stakeholders and more fine-grained functions, which now elaborate the likelihood and a possible attack path.

Furthermore the SCPs at this level address the interface type in a more specific way. The interface is the basis of every risk analysis because it defines the possibility that a system is attackable at all. Without any interface a system would not be attackable from an information security point of view. Defining the type of an interface as early as possible provides the opportunity to suspend specific threat scenarios.

An industry-specific interface could for instance prevent attacks of a standard malware like the worm Conficker [START_REF] Nahorney | The Downadup Codex -A comprehensive guide to the threat's mechanics[END_REF] but would still be vulnerable to a specifically developed and complex malware like the worm Stuxnet [START_REF] Falliere | Symantec -Security Response[END_REF]. Therefore an industryspecific interface like ARINC 429 which is used in the aircraft industry decreases the risk for a standard malware attack. This finally implies that the interface type allows a meaningful evaluation of the risk at this level.

At multi-system level the communication directions of each communication partner are divided into send and receive. The type of information which is exchanged, i.e. control data or information data, is assigned separately to each communication direction. The purpose of use for received information, which is detailed to forwarding, using, executing and processing information, allows a more explicit assessment of the likelihood. Additionally an allocation of possible attack paths is enabled. The defined SecEP objectives on multi-system level, i.e. to differentiate between security and non-security relevant functions, are finally achieved.

Having defined security context parameters at aircraft and multi-system level, the next step is an SCP definition at system level. At system level there is previous work on security management activities from other groups [START_REF] Bieber | Security and Safety Assurance for Aerospace Embedded Systems[END_REF]. A way straightforward is to use these earlier results for structuring the SecEP at the system level. After synchronizing with the governing SEP and defining SecEP objectives at system level the SCPs can be elaborated and used analogously at the system level. This approach is fully compatible with previous work at a system level. However it resolves the challenge of a top-down approach which is globally applicable to aircraft functions and which enables standardized information exchange for security management issues across all development levels by the use of SCPs.

Summary and Conclusion

Increasing functionality and a rising complexity of aircraft systems leads to a complex aircraft communication network with various communication paths and partners. This progression in aircraft industry requires a reconsideration of the established systems engineering approach with emphasis to security engineering and management. To cope with the challenge of security management we have introduced the Three-V-Model representing three concurrent and interacting processes, i.e. the system engineering process (SEP), the safety engineering process (SafEP) and, for the first time, the security engineering process (SecEP). Compliant with existing guidelines and compatible to the established aircraft development process we execute the SecEP across all development levels and simultaneously to the SEP and SafEP. Defining process links and synchronizing processes on particular development levels enables an equal treatment of the SecEP. Information exchange in-between the processes is achieved by using security context parameters (SCPs). SCPs were introduced to realize a standardized communication of engineering departments and to guarantee a topdown approach for security management starting at aircraft level. In practice, this approach enables filtering of security and non-security relevant functional information starting at the highest development level, i.e. the aircraft level and thus reduces workload on the subsequent development levels. This top-down approach using standardized communication via SCPs facilitates the collaboration of the engineering departments and clearly separates competences and work shares of neighboring departments. Moreover, this approach will particularly enable the parametric assignment of security relevant information using the model based require-ments engineering methodology [START_REF] Hintze | A model-based security engineering process approach for the development of next generation cabin management systems[END_REF] which fosters a consistent tracking and tracing of changes during the overall development process and across all development levels.