IMPROVING ANDROID SECURITY FOR AUTOMOTIVE WITH A DEFENSE-IN-DEPTH STRATEGY

Transcription

1 IMPROVING ANDROID SECURITY FOR AUTOMOTIVE WITH A DEFENSE-IN-DEPTH STRATEGY INNOVATORS START HERE.

2 EXECUTIVE SUMMARY Automotive computer systems are increasingly integrated, and manage a number of convenience and safety features. In-vehicle infotainment (IVI) systems are also increasingly popular and are now expected, at least as options, on most vehicles. Android, with its rich development environment and friendly graphical and multimedia-based user interface, is an ideal match for this situation. But Android was not developed with high levels of security as a design requirement. Care must be taken when using Android in an automotive environment in order to avoid inadvertently creating high-risk situations and opening vulnerabilities that can be exploited by malicious code. This paper proposes ways to alleviate the known Android problems in an automotive environment, following a multilayered defense-in-depth strategy. TABLE OF CONTENTS Executive Summary Security Enhancement Strategy... 3 Defense in Depth Layers Secure Private Marketplace and App Preinstall Filter Security Enhanced Android Secure Boot and Firmware Management System Network Firewall Data Protection in Motion and at Rest Data Isolation... 5 Protection Coverage Conclusion White Paper

3 SECURITY ENHANCEMENT STRATEGY It is no secret that standard Android, as released by Google and implemented on hundreds of thousands of cellular and tablet devices, is not secure enough to work in an integrated automotive environment. The availability of hundreds of thousands of applications provides a seeming advantage. But most of these applications are designed and developed by programmers unfamiliar with the basic principles of software security, creating a huge potential attack surface and extreme risk. And combining the vulnerabilities in core Android with automotive systems creates additional risk. Standard Android must go through a series of security enhancements before deployment or connection to systems that are security sensitive. In a separate paper, we discussed the most common security vulnerabilities of Android. In this paper, we show how using appropriate enhancements makes it possible to create an Android environment that is sufficiently secure. The following paragraphs list a series of strategies which conform to a defense-in-depth 1 strategy, combining hardware separation and software enhancements to achieve a practical level of assurance of system security and safety (see Figure 1). Defense in depth is a best practice strategy in the computing security field. Android Sandbox Provides standard Android security SE Android Detects and prevents abnormal application behavior The goal is to create multiple layers of security, each of which protects the system in a different way that is as independent of other layers as is practical. This strategy makes it possible to prevent multiple types and categories of attacks from multiple types of attackers. The strategies listed here are all directed at the vehicle s electronic control unit (ECU) elements, specifically those based on Android. Other, non-android ECU elements may also benefit from some of these strategies. Strategies related to procedures, training, mechanical systems, social engineering, and other aspects of vehicle safety and security are not listed here. DEFENSE IN DEPTH LAYERS 1. Secure Private Marketplace and App Preinstall Filter The first layer of software protection is provided by a custom or private application marketplace combined with a mechanism to review applications before allowing them to be installed. Applications cannot be installed unless they were downloaded from the approved market and contain an approved electronic signature. Limiting the applications to those that pass a set of criteria ensures that they do not create vulnerabilities or worse, directly contain malware. Application verification is enhanced by relying on encryption keys retrieved during a secure device boot (see more on secure boot below). DeviceManagement Firmware Management Detects compromises to the system and notifies the proper authorities Updates system firmware to close vulnerabilities in deployed systems PRIVATE APP STORE Network MARKET APPLICATION Isolation Technologies Separate data to prevent a compromise of one component from compromising any other component Secure Boot In the case of a successful compromise, prevents the attacker from installing code permanently in the system PACKAGE MANAGER Firewall Prevents attacks from reaching the system Application Management Attestation/ Integrity Check Prevents high-risk applications from being installed on the system Periodically checks the system from afar against known golden images App Preinstall FIlter Veto Filter Veto? No Install Application Exit Physical Security Secures various ports and interfaces using physical means Figure 1: Defense in depth: Each layer provides a different kind of protection; to successfully attack the system, the attacker must find vulnerabilities in multiple layers Figure 2: Application preinstall filter 3 White Paper

4 2. Security Enhanced Android If any malware or damaging bugs are allowed to be installed, a second layer, Security Enhanced Android (SE Android), based on SELinux, provides mandatory access controls (MAC) that protect against unwanted access to data and system resources. It also helps prevent applications from sending information where that information should not go. Despite its stricter security model, SE Android is as fully featured as Android. SE Android provides a mechanism to detect attacks in progress and defend against them. It does so by creating a model of normal system behavior and enforcing that model. Any activity that does not conform to the model is assumed to be malicious, and SE Android prevents it from being successful. Furthermore, SE Android affects the entire system. On traditional Unix and Linux systems, there is a special account, called root, which has full privileges to do anything that the system is capable of doing. The root account bypasses the traditional security mechanisms entirely, as a sort of built-in back door. But SELinux and SE Android treat the root account like any other, and limit the activities that a process owned by root can perform. In this way, root is not root, so privilege escalation is not enough for the attacker. Instead, the attacker must escalate privileges and then gain access to the specific functionality they need, which is significantly more difficult. SE Android is available in Android v4.3 (Jelly Bean Maintenance Release 1) in permissive mode and in Android v4.4 (Jelly Bean Maintenance Release 2) in enforcing mode. The default security policy distributed in the Android Open Source Project (AOSP) is rather limited. In an automotive use case, the security policy would need to be strengthened, potentially implementing extensions to SE Android to cover even more of the standard system. 3. Secure Boot and Firmware Management System A third layer, secure boot combined with a secure firmware management system, prevents any intrusive malware or bugs from being installed as part of the system image, thus preventing a perpetual state of threat. This layer helps protect the overall integrity of the system. Secure Boot The purpose of a secure boot solution is to ensure that the firmware has not been tampered with. In general, this is accomplished by measuring an image before making use of it. (Attestion, on the other hand, measures an image while it is operational.) The boot stages are: Power on (rominit) to bootloader Bootloader(s) to Linux Linux to Android A good secure boot solution starts working during the power on code. This code is typically physically located in ROM (readonly memory), which the processor literally cannot write to, and is therefore invulnerable to post-manufacture attacks. It verifies the bootloader image and then starts the bootloader running. The bootloader then verifies the Linux stage by verifying that the Linux kernel image itself has not been tampered with, and that the root file system image has not been tampered with. During system build, these two components are packaged into boot.img. The next step is to verify the Android /system file system. The bootloader, Linux kernel, and root file system images are all relatively small and can be verified relatively quickly. But the /system file system is large, so a straightforward checksum or encryption signature check would take a very long time to complete. However, for a secure boot solution, this file system must be checked, so a different mechanism is used to avoid slowing the boot process to unacceptable levels. A secure boot sequence not only validates the system firmware, it also establishes a chain of trust that originates from unmodifiable hardware. System encryption keys can be part of the chain of trust which can then be used to validate applications, malware detection, communication, and data storage encryption. Device/Firmware Management Device/firmware upgrades require external connectivity to upgrade servers. Security measures can be applied to validate that the data comes from a secured source and the device or system only accepts updates from the single system that provides 4 White Paper

5 secure firmware management. This same mechanism is used to manage plugins and other application database contents on the Android device. 4. Network Firewall Another layer consists of a network firewall combined with functionality to detect and block certain kinds of attacks such as denial of services (DoS). Firewalls prevent exposure of unwanted services to a network and provide a shield against common network-based attacks. There are at least two open source firewall applications available: DroidWall and Android Firewall. But for an automotive application, a more comprehensive and customized solution is likely to be necessary in order to cover the broad networking environment. Commercial virus scanners for use on the Android systems (such as McAfee Mobile Security) are available, and a customized version of such a scanner may be appropriate for adding a firewall in an automotive environment. 5. Data Protection in Motion and at Rest Data must be protected in the automobile for both privacy and safety concerns, so data in motion over networks such as wireless, Wi-Fi, and Bluetooth must be encrypted to avoid interception. A commonly used technique is the secure socket layer (SSL) for TCP/IP communication of various sorts via the OpenSSL libraries. Virtual private networks (VPNs) can be used to establish a secure connection to a known source such as an automotive service center. This approach ensures that the end point (for example, the car dealer or manufacturer) is a known entity and that the connection is secure. Equally important is protecting data at rest when stored in volatile memory such as RAM, or more permanently in flash or hard disk storage. Ensuring proper encryption of data at rest, such as that specified in the FIPS standard, is critical. 6. Data Isolation Data isolation mechanisms can provide another layer of protection. Partitioning of major subsystems prevents user applications from affecting an entire system; by separating critical parts of the system from the less critical, it s possible to ensure the correct operation of the critical components even if an attack is successful in other parts of the system. Wind River has developed a domain partitioning system called lightweight partitioning (LWP) that provides partitioning at the Android OS level, separation of applications from each other, and protection against loss of the user s personal data. A bare metal hypervisor can help protect safety critical components by allowing a portion of the CPU to run a more secure operating system and interact directly with security sensitive components, while Android runs in an isolated system and is not allowed to interact directly with the secured components. This is a robust solution that make sense for aerospace, defense, and automotive applications where safety critical portions of the system must be physically protected from user-level applications. Isolation Using Lightweight Partitioning There are several distinct uses for an Android system in an automotive environment. The system would most frequently be used as the infotainment system for the driver and passengers. While the vehicle is in the service center, the Android system could be used as a secondary display to show diagnostic information. And in the event of an airbag deployment, the Android system could be used as an interface to an emergency service communication link that allows voice communication between the vehicle s occupants and the remote center, and transmits vehicle status data to better equip the remote center to understand the nature and severity of the problem. These three use cases have a common characteristic that makes them ideal for LWP: only one of them is active at any given time. When the vehicle is in the service center, the service configuration should be active and the other configurations inactive. After airbag deployment, the remote assistance configuration should be active and the others inactive. And at other times, the normal configuration should be active to allow the user a high-quality infotainment system. LWP allows time-domain isolation of these configurations, so that the appropriate one is active, and data from the other domains is hidden and unavailable. 5 White Paper

6 LWP is not the same as a multi-user implementation. In the case of LWP, multiple drivers have separate accounts using the normal Android multi-user feature for tablets, which was introduced in Android v4.2. LWP hides the applications and data installed in a specific domain, so that they are unavailable to attackers when that domain is not active. The data in inactive domains is kept encrypted and unmounted, so it can t even be seen, much less modified. Within the normal domain, each driver would have a separate account. The normal Android data, such as phonebook, media files, user-installed applications, and some system settings, is all kept private to the user s account using the normal, weak Android/ Linux sandbox. Service center applications and data are kept separate from user data, and are completely invulnerable to attacks made while the normal user domain is active. Similarly, applications and data for the remote assistance domain are kept separate from user data and from service center data 2. Isolation Using a Hypervisor In addition to, and complementary to, the domain isolation provided by LWP, it may also be appropriate to use a hypervisor solution. Because Android may be vulnerable to attacks that might allow an attacker to reprogram other ECUs on the vehicle, thereby creating a severe safety risk, the hypervisor can help limit the ability of the Android system to modify safety critical systems. The best method for preventing such attacks from affecting safety critical systems is to provide non-programmable hardware devices at the interface between the Android system and any buses connected to safety critical systems. This can be done either with a separate physical device, or with a hypervisor solution using the processor(s) of the Android system and a non-programmable hypervisor layer to filter the data. Separate devices would provide increased security, and a hypervisor solution would result in lower bill-of-materials costs. User data encrypted and not available when the service domain is active, so it cannot attack the service Service applications and data encrypted are not available when the user domain is active so it s not subject to attack DATA APP APP Common DATA APP APP Applications Dad s Account DATA Automotive System Secure OS Android Middleware Linux Kernel Mom s Account DATA APP APP Common Application APP APP DATA Hypervisor Teen s Account DATA Guet s Valet Account Applications hidden from specific users, but still available DATA Android Middleware Linux Kernel Figure 4: A hypervisor can provide a secure interlock to vehicle systems Figure 3: Lightweight partitioning and Android multi-users 6 White Paper

7 CONTACT WIND RIVER Visit contact to find your local Wind River sales contact, or call or write to PROTECTION COVERAGE The following table lists how to use the methods described above to protect against the various classes of vulnerabilities. Table 1: Caption Vulnerabilities and Solutions Class of Vulnerability Solutions Rootkits and other system-level threats, middleware vulnerabilities, image/video/audio vulnerabilities, and browser vulnerabilities Application vulnerabilities Service center vulnerabilities Botnets Prevent threats from being installed by using malware detection and virus scanners, and by managing applications based on authentication. When threats manage to get past those measures, prevent them from harming the system with SE Android MAC, and use device management to discover when malware has been installed and allow administrators to take appropriate action. If threats are undetected and get installed, prevent them from being installed permanently on the system with proper application authentication based on a chain of trust established at boot time via secure boot. Use firmware management to update system firmware and close newly discovered vulnerabilities for the lifetime of the vehicle. Use hardware isolation techniques to prevent malware from creating safety problems. Prevent threats from being installed by using malware detection and virus scanners, and by managing applications based on authentication. If threats are undetected and get installed, prevent them from being installed permanently on the system with proper application authentication based on a chain of trust established at boot time via secure boot. Use firmware management to update system firmware and close newly discovered vulnerabilities for the lifetime of the vehicle. Use hardware isolation techniques to prevent malware from creating safety problems. Prevent threats from being installed by using malware detection and virus scanners, and by managing applications based on authentication. When threats manage to get past those measures, use device management to discover when malware has been installed and allow administrators to take appropriate action. If threats are undetected and get installed, prevent them from being installed permanently on the system with proper application authentication based on a chain of trust established at boot time via secure boot. Use firmware management to update system firmware and close newly discovered vulnerabilities for the lifetime of the vehicle. Prevent threats from being installed by using malware detection and virus scanners, and by managing applications based on authentication. Prevent botnets from sending their payloads by using firewalls. When threats manage to get past those measures, prevent them from harming the system with SE Android MAC, and use device management to discover when malware has been installed and allow administrators to take appropriate action. If threats are undetected and get installed, prevent them from being installed permanently on the system with proper application authentication based on a chain of trust established at boot time via secure boot. Use firmware management to update system firmware and close newly discovered vulnerabilities for the lifetime of the vehicle. 7 White Paper

8 CONCLUSION Android as distributed by Google may be suitable for deployment as a stand-alone infotainment system that is not connected to any other automotive components, but when the infotainment system needs to be tied to other automotive components such as driver controls, vehicle status indicators, backup camera, environmental controls, and so on, standard Android does not provide the necessary level of protection. However, by using appropriate enhancements it is possible to create a secure environment. Together, the hardware isolation strategy and the multiple independent layers of software security provide a defense-in-depth barrier, and can help protect against the inherent vulnerabilities designed into Android. They make Android suitable for use in an integrated automotive environment where it is loosely coupled to other automotive components The LWP domain examples were chosen for clarity of explanation. It may be appropriate to combine the service center and remote assistance domains, or the normal and remote assistance domains. The important point is that normal infotainment use, which is at the highest risk, should be strongly isolated from service center functionality. Wind River is a world leader in embedded software for intelligent connected systems. The company has been pioneering computing inside embedded devices since 1981, and its technology is found in more than 1 billion products. To learn more, visit Wind River at Wind River Systems, Inc. The Wind River logo is a trademark of Wind River Systems, Inc., and Wind River and VxWorks are registered trademarks of Wind River Systems, Inc. Rev. 12/2013