Linköpings universitet SE–581 83 Linköping
Linköping University | Department of Computer Science
Bachelor thesis, 16 ECTS | Datateknik
2017 | LIU-IDA/LITH-EX-G--17/065--SE
Improving smartphone
secu-rity with remote attestation
Förbättra säkerheten hos smartphones med remote attestation
Jesper Persson
Supervisor : Marcus Bendtsen Examiner : Nahid Shahmehri
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
Students in the 5 year Information Technology program complete a semester-long software development project during their sixth semester (third year). The project is completed in mid-sized groups, and the students implement a mobile application intended to be used in a multi-actor setting, currently a search and rescue scenario. In parallel they study several topics relevant to the technical and ethical considerations in the project. The project culminates by demonstrating a working product and a written report documenting the results of the practical development process including requirements elicitation. During the final stage of the semester, students create small groups and specialise in one topic, resulting in a bachelor thesis. The current report represents the results obtained during this specialisation work. Hence, the thesis should be viewed as part of a larger body of work required to pass the semester, including the conditions and requirements for a bachelor thesis.
Abstract
Smartphones are becoming increasingly powerful and useful in a work environment. This has led to their adoption at the workplace. Many companies hand out smartphones to their employees and allow employees to bring their own devices to work. There are multiple potential vulnerabilities with such a situation. What happens if the device an employee uses to access secret company data with becomes infected by malware? Existing techniques such as remote attestation is widely used on desktop computers using a Trusted Platform Module (TPM) to allow remote parties to determine the integrity of a computer. However, no smartphones come equipped with a TPM, resulting in the need of alternate solutions. This report proposes a remote attestation system for the Android platform that allows employers to detect compromised devices. Any modification to an application is detected and reliably reported to a remote party.
Contents
Abstract iii
Acknowledgments v
Contents v
List of Figures vi
List of Tables vii
1 Introduction 1 1.1 Aim . . . 1 1.2 Delimitations . . . 2 1.3 Organization . . . 2 2 Background 3 2.1 Related work . . . 3 2.2 Trusted Computing . . . 3
2.3 Root of trust on mobile devices . . . 5
2.4 Android architecture . . . 6
2.5 Installing malware on Android devices . . . 8
3 Remote attestation system 9 3.1 Goals . . . 9
3.2 Assumptions . . . 9
3.3 Policies . . . 9
3.4 Architecture . . . 10
3.5 Protection against attacks . . . 11
4 Evaluation 12 4.1 Attack scenarios . . . 12 4.2 Performance . . . 13 5 Discussion 16 5.1 Future work . . . 16 5.2 Wider context . . . 17 6 Conclusion 18 Bibliography 19
List of Figures
2.1 General overview of data exchange during attestation . . . 4
2.2 The Android platform architecture. Image by Google. . . 7
3.1 Overview of remote attestation system . . . 10
4.1 Time to load APK’s and hash them with SHA-256 . . . 13
4.2 Time to load APK’s and hash them with SHA-1 . . . 14
List of Tables
4.1 Average app parameters using SHA-256 . . . 14 4.2 Average app parameters using SHA-1 . . . 14
1
Introduction
It is becoming popular for companies to hand out smartphones to their employees to boost productivity. Some employers also allow employees to bring there own devices to work. This exposes the company to potential vulnerabilities, especially if employees can install any application they want to. Some may even decide to root or jailbreak their device, which could increase the threat of malware infection according to [18]. Gartner [13] have predicted that "by 2017, 75 % percent of mobile security breaches will be the result of mobile application misconfiguration". Rooting a phone would be considered such a misconfiguration. In 2016 a malware by the name HummingBad [25] was discovered. The malware installs a permanent rootkit on devices and generates fraudulent adds and installs fraudulent apps.
Since a smartphone at the workplace may be used for accessing critical company data, an infected device could pose a threat to the company. The ability for employers to remotely check the integrity of a device would be useful in order to deny access to critical information if an infected device is found. This process is called remote attestation and is heavily relied upon in computers today [20]. By using remote attestation rootkits caused by Hummingbad could be detected.
A secure implementation of remote attestation requires a hardware root of trust, tradi-tionally provided by a Trusted Platform Module (TPM) on computers. However, such a ded-icated hardware is not present in most smartphones. Furthermore it is only recently that smartphones have seen widespread use in the workplace and the need for mobile security is relatively new. There exists means of providing a hardware root of trust, such as ARM TrustZone that is used by Samsung Knox in their remote attestation system [23].
1.1
Aim
This report aims to present a remote attestation system that forces devices to adhere to a policy that specifies whether a given application may run. The system is able to detect mod-ifications to an application’s source code and report the device’s integrity state to a remote party in a trustworthy manner. Most mobile attacks are the result of users running outdated software [28]. By using the proposed attestation system, employers would be able to detect devices that run outdated software and thus prevent potential attacks.
1.2. Delimitations
1.2
Delimitations
The proposed system is a proof of concept that shows how remote attestation can be imple-mented on Android. To facilitate development of the system an Android application is built to emulate the operating system. This allows for fine-grained control of how and when appli-cations are started. The built Android app acts as the home screen from which appliappli-cations are launched. The system assumes that the phone was booted into a trusted state. It is not shown or discussed how the proposed system could be implemented by modifying the Java virtual machine (JVM) in the Android kernel. This would require a custom build of Android which is out of scope for this report. Furthermore, in a production environment the system would require hardware support for shielded execution and storage. This is discussed in Chapter 2 but not implemented in the proof of concept.
1.3
Organization
The reminder of this report is organized as follows. Chapter 2 presents remote attestation, trusted computing and the Android architecture as well as alternatives to TPM for smart-phones. Chapter 3 outlines the proposed attestation system and explains how it is imple-mented. Chapter 4 evaluates the proposed system with regard to different attack scenarios and the system’s performance. Then follows a discussion on the system and suggested future work.
2
Background
This chapter gives an overview of the theory behind the proposed remote attestation system. Initially an introduction to remote attestation and trusted computing is given. Then follows a discussion on Android and its built in security mechanisms.
2.1
Related work
In [21] a remote attestation system for the Android platform was prototyped and imple-mented. In that paper the authors built their system to handle two scenarios. The first sce-nario concerned a workplace environment similar to the one presented in the introduction of this report. The second scenario concerned a self-employed IT consultant who wanted to pro-tect himself against virus threats without running battery draining anitvirus software on the device. In order to handle these scenarios the authors modified the JVM to perform integrity measurement of all loaded Java classes. The measurement and the loaded classes was added to a log. During attestation the measurements and the log was used to verify the integrity of the device.
This report builds on their system and adds the ability to disallow running apps accord-ing to a defined policy. Furthermore, this report discusses the available techniques on smart-phones to implement remote attestation in more depth.
2.2
Trusted Computing
Trusted Computing is a term coined by the Trusted Computing Group (TCG) [24]. They de-fine trust as "the expectation that a device will behave in a particular manner for a specific purpose" [17]. TCG develops specifications for Trusted Computing, one of these specifica-tions are the Trusted Platform Module 2.0 (TPM) which has been adopted by International Standards Organization as an international standard. The TPM provides a hardware root of trust that enables tamper-proof implementation of cryptographic operations including public key cryptography, key generation, hashing and random number generation [26]. The TPM contains a public/private key pair called the application identity key (AIK) or the endorse-ment key (EK). This key is signed by a certificate authority (CA). The certificate ensures that the public key does in fact belong to the TPM which increases the trustworthiness when com-municating with a remote server.
2.2. Trusted Computing
Remote attestation
One of the key components of Trusted Computing is remote attestation. Remote attestation allows an appraiser to verify the trustworthiness of a target platform, the attester. One way of doing this is by presenting the appraiser with integrity measurements such as hashes of executable files and let the appraiser perform the same hashes and compare the results. This is the approach used in the remote attestation system of this report with some minor modifi-cations. On computer systems the TPM enables secure storage and isolated execution so that no application can access its memory or execution path which is crucial to provide reliable attestation.
TCG specifies several components that are needed for trusted computing and thus remote attestation. The components that are relevant for the remainder of this report are outlined below: [22]
• Root of trust for measurement (RTM). A dedicated chip that performs integrity mea-surements of the system.
• Root of trust for storage (RTS). The part of the system responsible for providing a stor-age that is inaccessible to the rest of the system.
• Root of trust for reporting (RTR). The part of the system that makes sure integrity is provided when reporting the information held by the RTS.
• Trusted platform module (TPM). A dedicated chip that implements the functions de-fined by TCG.
• Platform configuration registers (PCR). A set of tamper-proof registers that stores hash values of parts of the system. Some PCRs are reserved for measuring the boot sequence while others can be used by applications. Modern PCRs usually store 24 bytes.
Figure 2.1: General overview of data exchange during attestation
A general attestation architecture works as follows. When a remote appraiser wants a system to attest itself it sends a request to an attestation service running on the attesting system. This requests contains a unique unguessable nonce generated by the server that it expects to get back in the response, see Figure 2.1. The attestation service communicates with the TPM to receive a quote. The quote consists of the nonce and a subset of the PCRs. Additionally the TPM’s certificate is returned together with a signature of the quote. All of this is then sent back to the appraiser. To verify the quote the appraiser checks the validity
2.3. Root of trust on mobile devices
of the TPM’s certificate and makes sure the nonce is the one it sent in the initial request. The latter prevents replay and masquerading attacks discussed later. The final part consists of ensuring that the PCRs represent a valid (trusted) system state.
Vulnerabilities
In [22] three vulnerabilities that a remote attestation system must protect against are dis-cussed. These are:
• Replay attack: the attacker uses old valid measurements when attesting the system. • Tampering: the attacker alters the integrity measurements either before or during
trans-mission to the appraiser.
• Masquerading: the attacker uses valid measurements from another system that has not been compromised.
The proposed remote attestation system has mechanisms in place to protect against these three attacks.
2.3
Root of trust on mobile devices
As noted in the previous section a system must be able to provide isolated execution, mean-ing that no application can alter the code of another application, and secure storage which ensures integrity and confidentiality of data. The secure storage, or root of trust for storage, is paramount when storing the keys used for cryptographic operations such as signing data. While a TPM is not present on mobile devices, multiple other techniques exists. These are presented in this section.
Mobile Trusted Module
The Mobile Trusted Module (MTM) [16] is a TCG approved specification of an alternative to TPM on mobile devices. It differs from the TPM in that it does not require a dedicated chip. However the MTM has not seen widespread use and is therefor not particularly useful.
Trusted Execution Environment
A Trusted Execution Environment (TEE), is a combination of software and hardware to pro-vide isolated execution and secure storage. GlobalPlatform propro-vides specifications for TEE available here [15]. A TEE consists of a rich execution environment, where the normal OS like Android can run, and a trusted execution environment, where a secure OS runs [9]. In the secure OS critical applications, referred to as trusted applications, runs. These trusted ap-plications could for instance be used to perform cryptographic operations. A TEE typically provides a way for applications in the different areas to communicate with each other. A se-cure boot is paramount to provide security in the TEE. This works by reading from a trusted ROM and then integrity checking the secure OS before giving it the control [9].
The difference between a TEE and a TPM is that the execution in both the insecure and secure area is performed on the same processor in a TEE.
Secure Element
A Secure Element [14] (SE) is a tamper-resistant chip where critical code can execute and where cryptographic keys can be stored. In that sense a SE can be considered a type of TEE,
2.4. Android architecture
however a distinction is often made. Generally a SE provides a more tamper-resistant envi-ronment than a TEE, sometimes including the ability to self-destruct to protect against phys-ical attacks. A SE can be implemented in a SIM-card, SD-card or directly on the motherboard [9].
ARM TrustZone
ARM TrustZone [8] provides a TEE with two execution environments called the secure and the non-secure world respectively. Each environment has its own dedicated RAM and CPU registers. The non-secure world does not know about the secure world or its memory ad-dresses. However, the secure world can inspect the memory of the non-secure world. This provides a way for processes in the different worlds to communicate with each other. There is also a monitor responsible for context switching between the worlds and to make sure no data leak when switching context.
To make use of TrustZone a secure OS must run in the secure world. An example of a secure OS is Trusty OS [6]. Developed by Google, Trusty offers a set of components for trusted execution on mobile devices. It consist of a kernel component as well as a secure OS called Trusty OS. Trusty does not support third party development.
There are also open source alternatives such as SierraTEE1.
Samsung Knox [23] is an example of a commercial product that uses ARM TrustZone to provide security on their phones. With Samsung Knox continuous integrity measurements of the kernel is performed to detect modifications after the phone has booted. Knox also makes use of remote attestation by sending the measured data during the boot sequence to a remote server for verification.
2.4
Android architecture
Figure 2.2 presents the entire Android platform architecture stack [4]. Android is built on top of a modified version of the Linux kernel. Above the kernel is a Hardware Abstraction Layer (HAL) that provides access to hardware components such as camera and Bluetooth. Next up is the Android Runtime (ART) as well as native C/C++ libraries such as Webkit and OpenGL ES. The Android Runtime uses the Linux kernel for threading and low-level memory man-agement. Each app runs as a separate process with its own instance of ART. ART provides just in time compiling (JIT) and ahead of time compiling (AOT). The Java Android API, which sits on top of the Android Runtime and the native libraries, provides an exhaustive API for application developers. This API allows developers to use the native libraries. However, using Android NDK, apps can call native code directly and bypass the Java Android API.
Android security
As Android uses the Linux kernel it inherits its security model including a user-based per-missions model, process isolation and secure inter-process communication [5]. The Android OS enables application sandboxing to ensure that apps cannot interfere with each other. Each application gets its own user ID and runs as a separate process. This enables kernel-level sandboxing. Everything above the kernel (system application, native code, operating system libraries, applications) are a part of this application sandboxing mechanism.
2.4. Android architecture
Figure 2.2: The Android platform architecture. Image by Google.
Keystore
OEMs may provide a Keymaster HAL [2] for devices that support a TEE. This is a mechanism to provide hardware-backed cryptographic services. Any operation using the Keymaster must be performed in a secure environment. However there are some vulnerabilities with Keystore on Android [12] especially on non-hardware backed devices.
Verified boot
As of Android 4.4 verified boot is supported in some devices. Verified boot helps to protect against rootkits by performing integrity measurements of code before executing it. Each stage in the boot process verifies the integrity of the next stage before executing the code. The root of trust is provided by a hardware stored key that is immutable after the device leaves the factory. This key is used to sign the first-level bootloader [3] [7]. These measurements could be used to implement a remote attestation system for the boot sequence.
Android Runtime
Android Runtime [1] (ART) is the runtime environment used by Android devices. Android applications are distributed using an APK file that contains dex files which contain the appli-cation’s bytecode. During installation ART will compile the dex files to machine code to boost
2.5. Installing malware on Android devices
performance during app usage at the expense of longer installation time. ART also supports just in time compiling that continuously profiles the code and makes optimizations.
2.5
Installing malware on Android devices
Due to the heavy use of sandboxing the Android platform does provide some security to de-vices. However, it is evident that the security provided is not enough since Android devices have been compromised multiple times.
The majority of malware on devices is the result of running software that is not up to date [28]. Typically the way malicious apps are installed is by tricking the user into installing them. In [28] attacks are categorized into repackaging attacks, update attacks, and drive-by downloads. Repackaging refers to taking popular apps and adding malware to them, then uploading them to Google Play with a fake name. Update attack is a variation of repackaging where the malware is presented as an update to an installed app. Drive-by download refers to downloading and installing apps without the user’s awareness of the actual intent of the app.
During 2015 the Stagefright attacks [19] allowed attackers to remotely execute code on devices through a specially crafted MMS message by exploiting bugs in Android.
Furthermore Android is susceptible to privilege escalation attacks where applications by various techniques can have their permissions raised, which can help apps escape the sand-boxing mechanism [10].
A remote attestation system could be used to deny users’ access to critical company data as well as prompting the user to update their software in the event of a user running old software.
3
Remote attestation system
In this chapter the remote attestation system is presented. First the goals of the systems are outlined, then different policies that a company could use to determine what applications can run are discussed. Finally the architecture is presented.
3.1
Goals
The remote attestation system has two goals it must attain:
1. Maintaining the integrity of a device with regard to a policy that specifies which appli-cations can run.
2. Detecting modifications to installed applications.
3.2
Assumptions
It is assumed that the chain of trust stretches to the Android Runtime. This means that the JVM was loaded into a non-compromised state. This could be achieved by using verified boot as discussed in Section 2.4.
3.3
Policies
The system is built to satisfy a defined policy. Different policies could be defined for different companies. At a very security critical company whitelisting applications that have been pre-approved by the IT department or a third party might be the way to go, whereas blacklisting known malicious apps might be more appropriate for other companies. Both policies works for the remote attestation system proposed. In this report we assume a whitelisting policy containing a list of package names. Every app on Google Play has a unique package name which makes this attribute useful for identifying applications.
3.4. Architecture
Figure 3.1: Overview of remote attestation system
3.4
Architecture
Since the system is a proof-of-concept an Android application is used to emulate the entire operating system. This allows for more control when developing the system since Android’s security model makes some modifications difficult. For each part it is shown how the sys-tem could be implemented in a production environment, taking advantage of the techniques presented in the background section.
The visual part of the system consist of an app that emulates the JVM. This app displays a custom app menu where every installed application can be launched from. Applications can be installed using Google Play or a third party repository. Whenever the emulated JVM is instructed to launch an activity it first checks if the app is allowed by the policy. If the app is not allowed the user is notified. If the app is allowed an integrity measurement is performed by calculating a hash of the app’s APK file. This calculation and the resulting hash must be shielded from the rich OS to provide security. In a production environment the integrity measurement should be provided by an application in the secure OS using a TEE such as ARM TrustZone. The hash is stored in the trusted world with a log that contains every application that has been executed by the JVM.
To perform the integrity measurement the JVM calls the Trusted Attestation Service (TAS) with the path to the application’s source code. The integrity measurement is then calculated as follows:
newHash=h(h(s)||oldHash)
where h is some hash function and s is the source code. SHA-256 is used in this system as it is supported by TPM 2.0, but this could easily be exchanged for a different algorithm. In a TPM the operation of calculating a new hash by including the old hash is called extending the PCR. This ensures a PCR cannot be set to a certain value by an attacker.
The appraiser can at any time request a device to attest its integrity. The mechanism is shown in Figure 2.2 and explained below.
1. The remote appraiser generates a nonce and sends this to the attestation service (AS) running on the device that should attest itself.
3.5. Protection against attacks
2. The attestation service passes the nonce to the trusted attestation service (TAS) and requests a quote.
3. The TAS creates a quote containing the measurement hash, the execution log and the nonce. The quote is signed using the private AIK. Finally the TAS returns the quote, the signature and its certificate to the AS.
4. The AS sends everything back to the appraiser. The appraiser ensures that it trusts the TAS by verifying its certificate by using the issuer’s public key. Next the signature is verified by using the TAS’s public key. If the signature is successfully verified in-tegrity and authenticity of the quote is maintained. Finally using the measurement list the appraiser calculates a hash of the application files and compares this with the mea-surement hash provided by the attester. If these hashes match the system is in a valid state.
In this system the TAS represents the system’s root of trust for storage (RTS), root of trust for measurement (RTM) and root of trust for reporting (RTR) as discussed in Section 2.2. The TAS’s certificate is signed by a CA that is vouching for the TAS. The CA is a self-signed certificate located on the appraiser. Upon preparing a device for the system the CA generates and signs a certificate that is moved to the device. It might be tolerable for each company to be their own CA, as long as they keep the CA certificate safe, preferably storing the CA and performing any signing on an offline computer.
3.5
Protection against attacks
If a malicious app for some reason has gained root access the JVM cannot be trusted to stop disallowed apps from executing or performing the integrity measurements since the JVM runs in the non-secure environment. It is therefore crucial that the chain of trust stretches to the JVM.
If a device is compromised it could send an old log with an old corresponding hash when-ever there is a request for attestation. The remote party would find that the hash is valid, however it does not represent the actual state of the client. The appraiser detects this by com-paring the nonce with its own. This secures the system from replay attacks and masquerading attacks. It is important that the nonce is not predictable since this allows a client to guess the nonce.
Since the TAS signs the quote with its private key, any modifications to the nonce, mea-surement list or meamea-surement hash would be detected when the appraiser verifies the sig-nature. This ensures that the system is protected against tampering during the data transfer between the appraiser and the attesting system.
4
Evaluation
For the system to be used in a production environment it is paramount that it meets the goals stated in Section 3.1 and that its performance impact does not impact the end user significantly. This chapter is divided into two sections. First the system is evaluated against different attack scenarios, then the performance impact of the system is evaluated.
4.1
Attack scenarios
Multiple attack scenarios are performed to test the system. For each scenario it is explained how the attack is implemented and the outcome of the attack.
• The attester performs a replay attack by using an old valid quote and sends this quote to the appraiser during a request for attestation. To perform the attack the attestation service is modified to return a hard coded quote.
Outcome: The appraiser finds that the nonce in the quote is invalid, as it has already been used.
• The attester runs a modified version of an application. The application is modified by changing its binary source code with a third-party app.
Outcome: The appraiser finds that the integrity measurement in the quote does not match the one the appraiser calculates locally.
• The attester tampers with the quote by modifying the execution log and the integrity measure-ment before sending the quote to the appraiser. To perform the attack the attestation service is modified to change the execution log and measurement of the quote before sending it off to the appraiser.
Outcome: The appraiser finds that the signature signed by the TAS cannot be verified. • The attester creates a new certificate, private key, execution log and measurement hash and builds
his own quote during attestation. He signs the quote with his own private key. The attack is performed by modifying the attestation service to return a different quote than the one provided by the TAS.
4.2. Performance
• The attester modifies the JVM to remove policy checking prior to launching apps. The attack is performed by manually removing policy checking from the emulated JVM.
Outcome: The attester can execute apps not allowed by the policy. However, the apps are added to the execution log. Upon attesting, the appraiser will find the disallowed apps in the execution log and classify the attester as untrustworthy.
• The attester modifies the JVM to remove calling the TAS to perform an integrity measurement prior to launching apps. The attack is performed by manually modifying the emulated JVM to exclude calling the TAS.
Outcome: Modified applications are able to run without being detected. This is the one scenario the system is not protected against. It is paramount that the chain of trust stretches to the JVM as noted earlier. If apps are not measured the TAS will not know that they executed and will thus send an empty execution log to the appraiser, which of course is valid.
4.2
Performance
In order to maintain a good user experience it is important to ensure that the system does not impact the battery consumption or the time a user has to wait until the app launches due to performing integrity measurements. Furthermore the performance impact for the appraiser must be low enough to handle potentially hundreds or thousands of employees attesting their devices every hour.
Performance on the attester
To test the performance on the attester a system running Android 5.1 on the MEmu Android emulator is set up with 20 popular apps from Google Play of different sizes. Figure 4.1 shows the result of performing the integrity measurement of each application with SHA-256 ten times and then calculating the average time spent measuring it. The time to load the file and the time to hash its content is measured separately, and presented in a blue and red bar respectively. It is evident that the performance impact due to performing the integrity measurement of applications is directly proportional to the size of the APK file.
4.2. Performance
Table 4.1: Average app parameters using SHA-256 Average APK size Average load time Average hash time
35 MB 103 ms 205 ms
Table 4.1 summarizes the average APK size, load time and hash time from Figure 4.1. The average time to load a APK file is 103 ms and the average time to hash its content with SHA-256 is 205 ms. This means that the average time to measure an application would be 308 ms. This would incur quite a noticeable performance impact at the end user.
Since hashing makes up about twice the time to load the app the best way to reduce the total measurement time would be to reduce the time to hash.
Figure 4.2 shows the result of running the same test again but using SHA-1 instead of SHA-256. Table 4.2 shows that the average hash time is brought down from 205 ms to 68 ms which brings the average measurement time to 172 ms. This is more tolerable than 308 ms. However, as of February 2017 SHA-1 is considered broken as Google managed to produce two PDF files with the same hash value [11].
Figure 4.2: Time to load APK’s and hash them with SHA-1
Table 4.2: Average app parameters using SHA-1 Average APK size Average load time Average hash time
35 MB 104 ms 68 ms
SHA-512 results in the same performance impact as SHA-256. MD5 is also tested and performs roughly like SHA-1. However, MD5 has been shown to be vulnerable to collision attacks [27].
Another concern on mobile devices is battery consumption. Measuring the battery con-sumption on Android devices is generally difficult as Android does not provide detailed information. However, as shown earlier the average time to load and hash an APK file is 308 ms, which would be a fraction of the time the phone is in active use. The frequency of which the appraiser requests attestation is of more concern as this involves radio
communi-4.2. Performance
cation. The system does not have a preconfigured interval for requesting attestation, letting the companies themselves decide on an appropriate interval.
Performance on the appraiser
The system’s performance implication should not only be considered on smartphones. It is also paramount that the system on the appraiser runs efficiently. An estimate is provided using the data gathered from the tests on the emulator, it should be noted that there are no hardware constraints for the appraiser as there are with smartphones. The appraiser could potentially be configured to handle any traffic load imaginable. The following formula is used to estimate the time needed to determine the trustworthiness of every device that is part of the remote attestation system:
Execution time=x ¨ y ¨ w ¨ z
where x is the amount of employees, y is the amount of apps launched per hour, w is the average time to measure an app in seconds and z is the number of times per hour the appraiser requests attestation.
A reasonable scenario might be a company with 1000 employees. Each employee launches 5 apps per hour on average with an average measurement time of 200 ms. The appraiser requests attestation every hour.
1000 ¨ 5 ¨ 0.2 ¨ 1=1000 sec « 17 minutes
The number could be brought down significantly by caching hash measurements. This would save the time of reading the file and hashing its content both of which account for the major time spent performing an integrity measurement.
In this example the time of downloading an app from the app store is not taken in account, instead it is assumed that every allowed app has been downloaded in advance for easy access by the appraiser. Furthermore, the time required to communicate and exchange data with the attester is also neglected.
5
Discussion
In this report a system for remotely attesting the integrity of smartphones running Android has been proposed. The system performs integrity measurements of apps before executing them. A remote party regularly requests the measurement data in order to determine whether the device is in a trusted state or not.
The proposed system is general enough to be adapted to different use cases depending on the company’s needs. Figure 5.1 shows a modified scenario in which the appraiser has a more passive role. The appraiser acts as a guard on behalf of a protected resource, for instance company emails. When a device wants access to the company emails it first requests access through the guard by providing a quote of its system state. The guard either grants or denies access to the protected resource. If the access was granted the devices is allowed access to the protected resource. This use case might fit a company where the integrity of devices does not matter until they access a certain resource.
Figure 5.1: Remote attestation system with a guard
5.1
Future work
There are some challenges that must be dealt with before the proposed system can be de-ployed in a production environment. First and foremost the JVM in Android must be
modi-5.2. Wider context
fied to perform integrity measurements. This would probably require a custom build of the Android kernel.
Furthermore the system in its current state does not handle different versions of the same app. This becomes an issue when a device updates an application to the latest version and the appraiser has not yet updated its version. The attester would falsely be regarded as having low integrity since the appraiser would detect source code modifications caused by updating the application. The reverse is also an issue where the appraiser has updated an application but the attester uses an old version. In a security critical environment new app versions might need to be scrutinized before being allowed by the policy. Furthermore not using the latest version of an application might be prohibited due to the huge threat of out-of-date software. It should be fairly easy for employers to modify their app policy to add or remove whitelisted or blacklisted apps. Performing local policy checks on each phone requires that each phone is updated with the latest policy which might add some overhead. The system currently lacks efficient ways to create, distribute and manage policies.
Extending the policy system to handle specific app versions and better ways to manage it is subjects for future work.
As for performance it took 308 ms on average to measure an app before launching it using SHA-256. This overhead might not be acceptable to some users. Additional work should focus on bringing down the measurement time by looking into alternate hash methods or possibly caching integrity measurements. Caching hash values would be very beneficial on the appraiser. However, caching on the attester could result in out-of-date hash values being used and modifications to source code could execute undetected.
When the appraiser detects a compromised device it merely logs the occurrence which would let the employers or IT department manually deal with the matter. The system at its current state is not able to detect which application has been compromised, just that there is a compromised application. Future work could focus on identifying the compromised application and automatically remove it or notify the user about it so that he or she can remove it manually.
5.2
Wider context
The importance of remote attestation in a world where computing is increasingly distributed is indisputable. Companies and governments are becoming more digitalized in terms of stor-ing and gatherstor-ing data. This motivates the need of bestor-ing able to determine the trustworthi-ness of a device before communicating with it. By using the proposed system companies, organizations and governments could increase their protection against different types of at-tacks that try to steal and compromise data.
6
Conclusion
The proposed remote attestation system can be made ready for a production environment with a few modifications. It contains the necessary security features to provide a reliable attestation that lets employers detect compromised devices. The system successfully detects replay and masquerading attacks as well as any tampering during the attestation process.
The only major threat to the system is when the chain of trust does not stretch to the JVM. If malicious code is allowed to execute prior to loading the JVM the system could be modified to exclude integrity measurements which would make the remote attestation useless.
Furthermore it is paramount that the trusted attestation service runs in a shielded envi-ronment. This is currently not easy as Android does not provide a way to execute code in a trusted environment. As it becomes easier for developers to take advantage of technolo-gies like ARM TrustZone, systems like the one proposed in this report should be able to see widespread use and ensure that company data remain safe in the event of a compromised device.
Bibliography
[1] Android. ART and Dalvik. n.d.URL: https://source.android.com/devices/ tech/dalvik/index.html(visited on 03/13/2017).
[2] Android. Hardware-backed Keystore. n.d. URL: https : / / source . android . com / security/keystore/index.html(visited on 03/14/2017).
[3] Android. Implementing dm-verity. n.d. URL: https : / / source . android . com / security/verifiedboot/dm-verity.html(visited on 03/13/2017).
[4] Android. Platform Architecture. n.d. URL: https : / / developer . android . com / guide/platform/index.html(visited on 03/14/2017).
[5] Android. System and kernel security. n.d. URL: https : / / source . android . com / security/overview/kernel-security.html(visited on 03/14/2017).
[6] Android. Trusty TEE. n.d. URL: https : / / source . android . com / security / trusty/(visited on 03/28/2017).
[7] Android. Verified Boot. n.d. URL: https : / / source . android . com / security / verifiedboot(visited on 03/13/2017).
[8] ARM. ARM Security Technology. n.d.URL: http://infocenter.arm.com/help/ topic / com . arm . doc . prd29 - genc - 009492c / PRD29 - GENC - 009492C _ trustzone_security_whitepaper.pdf(visited on 03/30/2017).
[9] Mohamed Amine Bouazzouni, Emmanuel Conchond, and Fabrice Peyrard. “Trusted mobile computing: An overview of existing solutions”. In: Future Generation Computer Systems (2015).
[10] Sven Bugiel, Lucas Davi, Alexandra Dmitrienko, and Thomas Fischer. “Towards Tam-ing Privilege-Escalation Attacks on Android”. In: ProceedTam-ings / 2012 Network and Dis-tributed System Security Symposium : 5 February to 8 February 2012, San Diego. Internet Soc, 2013.
[11] Lucian Constantin. Stop using SHA1 encryption: It’s now completely unsafe, Google proves. 2017-02-23. URL: http : / / www . pcworld . com / article / 3173791 / security / stop - using - sha1 - it - s - now - completely - unsafe . html (visited on 05/02/2017).
Bibliography
[12] Tim Cooijmans, Joeri de Ruiter, and Erik Poll. “Analysis of Secure Key Storage Solu-tions on Android”. In: Wang, C. (ed.), SPSM ’14 : Proceedings of the 4th ACM Workshop on Security and Privacy in Smartphones Mobile Devices, Scottsdale, AZ, USA — November 03 -07, 2014, pp. 11-20. New York : ACM, 2014.
[13] Gartner, Inc. Gartner Says 75 Percent of Mobile Security Breaches Will Be the Result of Mobile Application Misconfiguration. 2014.URL: http://www.gartner.com/newsroom/id/ 2753017(visited on 03/18/2017).
[14] GlobalPlatform. GlobalPlatform made simple guide: Trusted Execution Environment (TEE) Guide. n.d.URL: https://www.globalplatform.org/mediaguidetee.asp# _Toc419214134(visited on 03/30/2017).
[15] GlobalPlatform. Trusted Execution Environment. 2017. URL: https : / / www . globalplatform.org/specificationsdevice.asp(visited on 03/19/2017). [16] Trusted Computing Group. Mobile Trusted Module FAQ. 2010. URL: https : / /
trustedcomputinggroup . org / mobile - trusted - module - faq/(visited on 03/27/2017).
[17] Trusted Computing Group. TCG Glossary. 2012. URL: https : / / www . trustedcomputinggroup . org / wp - content / uploads / TCG _ Glossary _ Board-Approved_12.13.2012.pdf(visited on 03/19/2017).
[18] Serge Malenkovich. Rooting and Jailbreaking: What Can They Do, and How Do They Af-fect Security? 2013. URL: https : / / blog . kaspersky . com / rooting and -jailbreaking/1979/(visited on 03/18/2017).
[19] McAfee. Mobile Threat Report. 2016. URL: https : / / www . mcafee . com / us / resources / reports / rp - mobile - threat - report - 2016 . pdf (visited on 03/21/2017).
[20] Microsoft. Secure the Windows 8.1 boot process. n.d. URL: https : / / technet . microsoft.com/en-us/windows/dn168167.aspx(visited on 03/15/2017). [21] Mohammad Nauman, Sohail Khan, Xinwen Zhang, and Jean-Pierre Seifert. Beyond
Kernel-Level Integrity Measurement: Enabling Remote Attestation for the Android Platform. 2010.
[22] Reiner Sailer, Xiaolan Zhang, Trent Jaeger, and Leendert van Doorn. “Design and Im-plementation of a TCG-based Integrity Measurement Architecture”. In: PROCEED-INGS OF THE USENIX SECURITY SYMPOSIUM. USENIX security symposium. 2004, pp. 223–238.
[23] Samsung. Platform Security. n.d.URL: http://developer.samsung.com/tech-insights/knox/platform-security(visited on 03/18/2017).
[24] TCG. About TCG. n.d. URL: https : / / trustedcomputinggroup . org / about/ (visited on 03/13/2017).
[25] Check Point Software Technologies. From HummingBad to Worse. 2016.URL: https : / / blog . checkpoint . com / wp content / uploads / 2016 / 07 / HummingBad -Research-report_FINAL-62916.pdf(visited on 03/18/2017).
[26] “Trusted Computing”. In: Trusted Computing. Lecture Notes in Computer Science. Ox-ford, UK: Springer, 2009.
[27] Tao Xie, Fanbao Liu, and Dengguo Feng. Fast Collision Attack on MD5. 2013. [28] Yajin Zhou Xuxian Jiang. Android malware. Springer, 2013.
