Mobile Device Security
Exploring the possibilities and limitations with Bring Your Own Device (BYOD)
KRISTOFFER SVENSK
Master’s Degree Project Stockholm, Sweden December 6, 2013 XR-EE-LCN 2013:020
A B S T R A C T
The goal for this thesis is to explore the possibilities with Bring Your Own Device (BYOD) on mobile devices using various Mobile Device Management (MDM) features on three different platforms - Android, iOS and Windows Phone 8. The work involves a theoretical study and a practical implementation. The research is to investigate the native (built-in) and implementable support for
MDM using a client application, while the practical work is to implement a client application for Android as a proof of concept based on the research result. The current threat landscape is revealed as well as suggestions on how to protect mobile devices forBYOD. The result shows that Android is the most vulnerable platform and lacks native and implementable support forBYODand
MDMfunctionality using public frameworks. To provide more comprehensive support a client application would require more high-risk permissions, that are only available using firmware signatures or restrictive manufacturer-specific Application Programming Interface (API).
i
S A M M A N F A T T N I N G
Målet med examensarbetet är att utforska möjligheterna med Bring Your Own Device (BYOD) på mobila enheter med hjälp av olika Mobile Device Management (MDM) funktioner. Arbetet involverar tre olika plattformar: Android, iOS och Windows Phone 8, och inkluderar en studie och ett praktiskt arbete. Studien handlar om att undersöka det inbyggda stödet för MDM samt det som går att utöka genom en klient applikation, medan det praktiska arbetet omfattar utveckling av en klient applikation för BYOD till Android plattformen med resultatet av undersökningen som stöd.
De aktuella hoten med BYODoch mobila enheter presenteras samt lösnings- förslag för att skydda enheterna mot dessa hot. Resultatet av arbetet visar att Android är den mest utsatta mobila plattformen i dagsläget och har dessu- tom minimalt med stöd förBYOD ochMDM-relaterad funktionalitet genom de generella ramverken. För att tillhandahålla en mer omfattande lösning förBYOD
så behövs tillgång till mer restriktiv funktionalitet som endast kan fås genom tillverkarnas egna ramverk eller om en digital signatur från hårdvaran har tilldelats applikationen.
iii
A C K N O W L E D G E M E N T S
I would like to thank Anders Eriksson for providing me with the opportunity to carry out my master’s thesis at Giesecke & Devrient, and to Pär Thorstensson and Jonas Claudelin for their help and support during the entire process.
I would also like to thank my supervisor Panagiotis Papadimitratos for his help and guidance into making this thesis work.
Kristoffer Svensk
v
C O N T E N T S
Acronyms ix
1 Introduction 1
1.1 Background . . . . 2
1.2 Method of Research . . . . 3
I Theoretical study 5 2 The threat landscape 7 2.1 General issues with BYOD . . . . 7
2.2 Malware . . . . 8
2.3 Data leakage and theft . . . . 9
2.4 Social engineering . . . . 10
2.5 Phishing . . . . 10
2.6 Software vulnerabilities . . . . 11
3 Securing mobile devices 13 3.1 Screen-lock policy . . . . 13
3.2 Remote lock and wipe . . . . 14
3.3 Encryption . . . . 15
3.4 Application control . . . . 16
3.5 Device life-cycle . . . . 17
3.5.1 Initiation . . . . 17
3.5.2 Development . . . . 18
3.5.3 Implementation . . . . 18
3.5.4 Operations and maintenance . . . . 19
3.5.5 Disposal . . . . 20
3.6 Recommendations. . . . 20
4 Platform overview 23 4.1 Android . . . . 23
4.1.1 System architecture . . . . 23
4.1.2 App development. . . . 26
4.2 iOS . . . . 26
4.2.1 System architecture . . . . 26 vi
4.2.2 App development . . . . 29
4.3 Windows Phone 8 . . . . 30
4.3.1 System architecture . . . . 30
4.3.2 App development . . . . 31
5 Platform vulnerabilities 33 5.1 Android . . . . 33
5.2 iOS . . . . 35
5.3 Windows Phone 8 . . . . 36
6 Platform support 39 6.1 Android . . . . 39
6.1.1 Additional solutions . . . . 41
6.2 iOS . . . . 42
6.3 Windows Phone 8 . . . . 43
II Practical work 45 7 Android Programming 47 7.1 Activity . . . . 47
7.2 Service . . . . 48
7.3 Broadcast Receiver . . . . 50
7.4 Intents . . . . 50
7.5 Threading . . . . 51
7.6 Google Cloud Messaging (GCM) . . . . 52
8 Implementation 53 8.1 Client . . . . 54
8.1.1 Device Administration API . . . . 54
8.1.2 Public API . . . . 55
8.1.3 Manufacturer-specific API . . . . 56
8.1.4 Design . . . . 56
8.2 Server . . . . 60
8.2.1 Enrollment server . . . . 61
8.2.2 GCM application server . . . . 63
9 Conclusion 65 9.1 Summary . . . . 65
9.2 Further work - Mobile Network Operator . . . . 67
Bibliography 69
vii
L I S T O F F I G U R E S
2.1 APT life-cycle (Inspired by Mandiant [36]) . . . . 8
3.1 Device life-cycle for a secure enterprise . . . . 17
4.1 Android software stack (Inspired by Google Inc. [25]) . . . 25
4.2 The iOS Boot-up sequence . . . . 27
4.3 iOS File Protection . . . 28
7.1 Activity lifecycle (Inspired by Google Inc. [23]) . . . 49
7.2 Google Cloud Messaging: architectural overview . . . 52
8.1 Architectural overview . . . 53
8.2 Activities . . . . 57
8.3 Client package overview . . . . 57
8.4 Enrollment state diagram . . . 58
8.5 Client package details part 1 . . . 59
8.6 Client package details part 2 . . . 60
8.7 Enrollment server package overview . . . . 61
8.8 Enrollment sequence diagram . . . 62
8.9 Enrollment server package details . . . 63
9.1 Type of Mobile Device Management (MDM) providers . . . . 67
L I S T O F T A B L E S
4.1 Android protection levels . . . . 246.1 MDM Native and Public API Functionality . . . 39
6.2 Android Functionality Matrix . . . 40
viii
A C R O N Y M S
3S Server Software and Services . . . .2
AES Advanced Encryption Standard . . . .18
API Application Programming Interface . . . .2
APT Advanced Persistent Threat . . . .7
APN Access Point Name . . . .67
BYOD Bring Your Own Device . . . .1
CA Certificate Authority . . . .15
CCS Cloud Connection Server . . . .52
CPU Central Processing Unit . . . .24
DBMS Database Management System . . . .53
DM Device Management . . . .1
DVM Dalvik Virtual Machine . . . .24
DDoS Distributed Denial of Service . . . .7
EAS Exchange ActiveSync . . . .36
GCM Google Cloud Messaging . . . .52
GPS Global Positioning System . . . .9
HTTP Hypertext Transfer Protocol . . . .15
HTTPS Hypertext Transfer Protocol Secure . . . .15
iPCU iPhone Configuration Utility . . . .43
iDEP iOS Developer Enterprise Program . . . .29
IP Internet Protocol . . . .15
IMEI International Mobile Equipment Identity . . . .55
IRM Information Rights Management . . . .31
JAX-RS Java API for RESTful Services . . . .60
JDBC Java Database Connectivity . . . .61
JSON JavaScript Object Notation . . . .61
JVM Java Virtual Machine . . . .24
LLB Low-Level Bootloader . . . .26 ix
LOB Line of Business . . . .31
MDM Mobile Device Management. . . .viii
MDS Mobile Device Security . . . . 15
MNO Mobile Network Operator . . . .2
MTC Mobile Threat Center . . . .33
NIST National Institute of Standards and Technology . . . .17
NFC Near Field Communication . . . . 2
NTP Network Time Protocol . . . .19
OEM Original Equipment Manufacturer . . . .2
OHA Open Handset Alliance . . . .23
OMA Open Mobile Alliance . . . .44
OS Operating System . . . .2
OTA Over-the-Air . . . .2
OWASP Open Web Application Security Project . . . . 11
PC Personal Computer . . . .7
PIN Personal Identification Number . . . .7
QR Quick Response . . . .11
RAM Random Access Memory . . . .15
ROM Read-Only Memory . . . .25
REST Representational State Transfer . . . .60
RMS Right Management Services . . . .31
SAFE Samsung For Enterprise . . . .41
SEEK Secure Element Evaluation Kit . . . .68
SIM Subscriber Identity Module . . . .2
SIT Secure Information Technology . . . .35
SD Secure Digital . . . .31
SDK Software Development Kit . . . .26
SDL Security Development Lifecycle . . . .31
SE Secure Elements . . . .2
SHA-1 Secure Hash Algorithm . . . .27
SMS Short Message Service . . . . 11
SSID Service Set IDentifier . . . .36 x
SQL Structured Query Language . . . .61
TLS Transport Layer Security . . . .60
TPM Trusted Platform Module . . . .31
UID Unique Identifier . . . .23
UEFI Unified Extensible Firmware Interface . . . .30
UI User Interface . . . .47
URI Uniform Resource Identifier. . . .50
URL Uniform Resource Locator . . . .11
VM Virtual Machine . . . .24
VPN Virtual Private Network . . . .15
WP8 Windows Phone 8 . . . .16
XMPP Extensible Messaging and Presence Protocol . . . .52
xi
1
1 I N T R O D U C T I O N
The usage of mobile devices has increased dramatically during the last decade and has grown significantly in the business sector as well as the private sector, where the majority of citizens in first-world countries depend on smartphones in their daily life. Since the introduction of smartphones into the workplace the perimeter have expanded and allows work to be conducted from the outside of the workplace. Some companies require their employees to be more flexible in their work which can require them to be able to access their email, calendar and other company data remotely. The market is reporting of a trend where employees would prefer to use their private devices for work-related activities instead of company-owned devices and this phenomenon is discussed under the term: Bring Your Own Device (BYOD).
BYOD refers to a concept where employees are allowed to use their private devices (laptops, smartphones, tablets etc.) for work - to carry out work-related tasks and gain access to internal company resources. It offers more freedom and flexibility for the employees and cuts maintenance- and support costs for companies. Since the employees are responsibility for the devices then companies can primarily focus on the safety of their data. However, this is not an easy task since one of the biggest challenges with BYOD is to prevent data leakage and is mainly due to the lack of control over the devices from an enterprise perspective.
Traditionally, the employer provides the employees with devices that are company-owned and is therefore not the property of the individual employee.
Then the company are in control of the devices and its content. The enterprises had a huge influence over these devices and could invoke various Device Management (DM) features that concerned provision settings, access control, application control etc. But since it is not possible to control private devices in the same fashion,BYOD comes with a couple of security concerns that need to be sorted out:
• How can an organization allow untrusted devices (devices not controlled by the organization) within their infrastructure?
• How can confidentiality and integrity of internal resources be ensured?
• When can an untrusted device be considered to be trusted? What require- ments should be met?
2 background 1.1
1.1 background
The research for this MSc thesis is to investigate the possibilities and limitations with BYODfor three of the leading mobile platforms on the market. The goal is to determine the level of support related to MDM functionality and could be used to enforce a solution for BYOD. The problem resides in the fact that each platform is independent and does not share a common standard or public framework to enforce MDM. In order to provide a comprehensive policy for
BYOD using MDM functionality on multiple platforms, then it must exist a common level of protection that can be applied to all the platforms involved.
There is a growing volume of attacks against mobile devices and it is therefore relevant to consider the threat level for each platform in order to determine the precautions needed to protect against it. The major threats against these platforms are investigated and the necessary solutions to minimize these risks are revealed.
This work comprises native (built-in) and implementable support avail- able using public and restrictive Application Programming Interface (API)s to develop a client application for Android. There are several companies that specializes in traditionalMDMsolutions but the functionality differs for each vendor. This investigation strives to determine the possibilities with relation to
BYODandMDMfeatures and the limitations, whether it is due to lack of support in the Operating System (OS) or restrictions set by the Original Equipment Manufacturer (OEM).
The work has been done at Giesecke & Devrient Server Software and Services (3S) in Stockholm. Giesecke & Devrient is a worldwide security company and the 3S division is primarily involved with Over-the-Air (OTA) software, Subscriber Identity Module (SIM) management and other Secure Elements (SE). They are also developing products for secure money transactions and trusted solutions for Near Field Communication (NFC)-supported devices together with their comprehensive knowledge of the characteristics of mobile devices.
Since Giesecke & Devrient works closely with SIMcards, it has also be an interest to look into the scenario where a Mobile Network Operator (MNO) providesBYOD as a service and to determine the possible advantages compared to solutions supplied by traditionalMDMvendors. However, this part is partly outside of the scope for this thesis and is only mentioned as a discussion in section9.2.
1.2 method of research 3
1.2 method of research
The majority of the material on the mobile platforms have been gathered from their respective vendor to describe their functionality and security architecture.
Information on their individual flaws and vulnerabilities have been gathered from various news articles and publications from security researchers and several security companies. The threat situation for each platform is determined by reports published by security firms such as Sophos [56] and Symantec [59]
to describe the current threat landscape and the security drawbacks they have shown in the past. Examples that describe these breaches in security are included to give the reader a broader perspective on the potential consequences that can have a huge impact on companies and organizations.
The features included in the prototype implementation for Android is based on the research results on threat management and the available support for
MDM to provide a comprehensive protection for BYOD and to strengthen the mobile security.
Part I
T H E O R E T I C A L S T U D Y
7
2 T H E T H R E A T L A N D S C A P E
Both profitable and non-profitable organizations are all potential targets in an emerging cyber-threat landscape, the market is reporting an escalation of malware, Advanced Persistent Threat (APT), Distributed Denial of Service (DDoS) and other attacks targeted against enterprises [33,56]. The list of adversaries can range from so called scriptkiddies, teenagers using existing malicious software to vandalize computer systems for their own amusement, to targeted and stealthy attacks made or ordered by rival companies, activist groups or even federal governments. These attackers have primarily been aiming at vulnerabilities found on Personal Computer (PC)s but with the increasing usage of smartphones and tablets the market is starting to see more and more attacks against mobile devices [7].
This section describes some of the most common attacks and vulnerabilities in order to show the factors that needs to be protected to provide a secureBYOD
deployment. The goal is to describe these threats, their impact and how they relate toBYOD.
2.1 general issues with byod
Strict access control is enforced on company-owned devices to prevent unau- thorized access and is usually managed with MDM software provided by a third-party vendor such as Airwatch [1] or MobileIron [45]. But with private devices there are no guarantee that any of such features are available to pro- tect the device and its data. Emails, attachments and other company data is vulnerable and can spread to a third party through e.g. malicious software or by connecting the device to an untrusted laptop. Companies also lack the ability to manage lost or stolen devices. Hence a device that is no longer in possession of its intended user can put company intellectual property at risk.
If the device is neither Personal Identification Number (PIN) nor password protected then an adversary can gain direct access to the device and its content.
But password-protected devices can still be vulnerable to data theft if they are connected to the Internet or plugged in to e.g. a laptop. A private device should be considered as untrusted for enterprise usage until proper review has been made that can deem the device as trusted. For example, by installing a
8 malware 2.2
client application that can confirm that the device fulfills all the requirements specified in a company policy.
2.2 malware
Malware is the general classification for malicious software such as viruses, root-kits, Trojan horses etc., and is most commonly related to destruction or data theft. The definition of malware has changed during recent years and can be divide into two categorized: traditional or modern. Traditional malware refers to the classical form of malware where the goal is to infect and spread to as many devices as possible while maximizing the damage the a system, without any specific motive behind an attack. Modern malware is more sophisticated and strategically planned. APTis an example of modern malware and is becoming more commonly known. AnAPTis a well-planned cyber-attack with a specific target, e.g. a business, organization or federal government. The attack is carried out in multiple steps to reach a specific goal and is intentionally stealthy in order to avoid detection. One of the main differences with modern malware compared to traditional, is that modern malware is targeted and stealthy. The target is specifically chosen since it has something of value to the attacker and avoiding detection is essential in order to carry out a prolonged attack. An
APT attack can last for a long period of time and as long as the attack goes undetected more data can be extracted.
Figure 2.1: APT life-cycle (Inspired by Mandiant [36])
The characteristics of the APT life-cycle can be described as a sequential process that involves research, intrusion, gathering of credentials, data extraction and clean-up [12]. The first step involves research on the target to find weak points, or entry points, in a company perimeter and to determine were the information of interest might be located. An attacker searches for vulnerabilities
2.3 data leakage and theft 9
and then exploits them to establish an initial intrusion using techniques such as spear phishing or social engineering (see section2.5 and 2.4). Once inside, the malware circulates until the required credentials have been gathered in order to get access to the targeted data. The data is eventually extracted and uploaded to a drop-off that is controlled by the adversary e.g., a remote server. When the extraction is completed then the malware cleans up after itself to cover its tracks. It could take weeks or even months before anyone discovers that an attack has been carried out.
Modern malware authors have started targeting mobile devices and Android is their platform of choice. An example of a APT against Android took place recently and was targeted against a Tibetan activist group. Using a compromised email account, the attacker manages to send out a mass email that included a malicious .apk file (Android application file). This attack will be described in more detail in section5.1.
2.3 data leakage and theft
Information security is essential for any enterprise that wants to protect their confidential business information. It can be any form of digital information such as documents, presentations, calculations, patents, employee records etc., which can be classified as company-confidential. Data leakage and theft in this context refers to data that has been received onto the mobile device storage unit, and there are several ways for this data to be leaked or stolen by a third-party.
Malware is one of them, but it can also be stolen by an attack with physical access to a device, using email or by copying data to an external medium. It can also be through a breach at a trusted third-party or business partner.
Malicious applications can possibly track user activity by exploiting device features such as the Global Positioning System (GPS), screen capture, audio recording etc. Unauthorized use of this information can also be considered as data theft or tracking, which has the potential to be used for industrial espionage. An adversary can then spy on employees in real time, listen to private conversations, monitor user location or even capture photos of nearby documents to uncover company-confidential data.
Jailbreaking can also be considered as malicious. A jailbroken (rooted) device can be more vulnerable than a regular device with malicious applications installed, because the underlying software (bootloader, firmware) has been flashed and the security provided by Android might no longer be intact. Users are now able to manage root access to the system and distribute this access to other applications to allow usage of high-risk permissions to these applications, which is not possible with a non-jailbroken device. Jailbroken devices should
10 phishing 2.5
therefore be prohibited for enterprise usage to prevent malicious applications from getting escalated privileges.
Snooping is another possibility. Snooping refers to listening in on network traffic and monitoring the data being exchanged. The goal is to obtain user- names, passwords or other types of data that could be valuable. It can also be used for espionage and the attacker can use network analyzer software such as Wireshark [62] to capture datagrams within a network and extract data from its payload. The Internet was not designed with security in mind so if data is not properly encrypted it can easily be snooped by intermediate adversaries.
2.4 social engineering
In technical terms, social engineering refers to an attack where social skills are used to obtain information about computer systems [43]. People that practice social engineering (con artists) use social interaction to either trick their victims into giving up the information, or manipulating them to trust him or her and share information with the attacker. It could be an face-to-face interaction or over the telephone. Usually the attacker will pretend to be someone else, e.g.
a new employee at the same firm as the victim. There have been reports of attackers that have managed to get credit card information, transaction ids, store numbers and other kinds of information using the finesse and techniques of social engineering and it could easily be used to get passwords and other credentials as well. The Art of Deception [44] describes several real-life scenarios where social engineering techniques have been used in practice for financial gain and hacking large-scale computer systems.
This sort of attack is not a threat specifically against BYOD but rather a general issue for computer and mobile security.
2.5 phishing
Phishing is a form of social engineering. A phishing attack is an attempt to get a hold of sensitive information from users by luring them to believe it is for a legitimate cause [60]. The attack is usually launched using email or malicious websites as a primary tool. A phishing email can be masqueraded to originate from e.g. the victim’s bank or the IT department of the victims workplace, and can contain an inquiry regarding personal or financial information such as credit card information and passwords. There is a more sophisticated type of phishing attack known as spear phishing. Spear phishing refers to more targeted phishing attacks where the target is deliberately chosen in advance, based on
2.6 software vulnerabilities 11
e.g. role or position in an organization where they possess a certain level of clearance or access. The target might have been granted access to information that is necessary for an attacker to get the authorization needed for an even larger attack, e.g. anAPTattack.
2.6 software vulnerabilities
Software vulnerabilities are a constant security risk for any application. The time between vulnerability discovery and until it is fixed and patched an application runs the risk of being exploited. Web browsers is a typical example and they can be found on basically every PCor mobile device available today.
If malware authors discover a breach or flaw, then they can exploit it in order to inject malicious code that can affect millions of devices up to the time when the flaw is fixed and patched on the user’s system. Every year Open Web Application Security Project (OWASP) publishes a list of the Top 10 most common vulnerabilities [50] and most of them are web browser-related. It is not that common for web browser exploits to have catastrophic consequences but all mobile devices have built-in web browsers and they are classified as system applications. This means that the application is part of the operating system and has access to system resources. It should also be noted that the web vulnerabilities are not limited to the web browser application itself and flaws in web technologies such as ActiveX and JavaScript are also targeted with the intention of executing malicious code. More information on the architectural design of each mobile platform will be discussed in section 4.
The use of Quick Response (QR) codes are one example where legitimate functionality could be exploited by malware authors and can be considered as a liability. AQRcode is a matrix-type barcode that can be scanned by the camera on a mobile device and aQRscanner application. The code can be translated into e.g. a Uniform Resource Locator (URL) that points to a website or application download and is often automatically opened by the web browser. This can be exploited and used to download malicious applications. An adversary can create a QRcode that includes aURLto a malicious .apk file and masquerade the code in a legitimate context e.g. a fake ad on a well-known website. The code is not human-readable so the user can therefore not determine if the code is legitimate or not before the code has been scanned. A similar attack recently took place in Russia [37] where a QR code on an ad for a popular Android application was modified and pointed to a malicious application instead. A lot of users unknowingly downloaded this application which started to send Short Message Service (SMS) messages to premium rate numbers once it was installed. The attack exploited the users’ lack of interest in the permissions that
12 software vulnerabilities 2.6
the app requested upon installation, which in this case included a cost-sensitive permission (to send SMS) that charged a lot of money from the victims.
13
3 S E C U R I N G M O B I L E D E V I C E S
As seen in section2, there are several types of attacks that target mobile devices and multiple vulnerabilities that need to be considered before a solution for
BYOD can be deployed into an enterprise environment.
A common principle on the discussion on information security is the CIA triad [57]: Confidentiality, Integrity and Availability.
• Confidentiality – Data should only be read by its intended and authorized users.
• Integrity – Data should only be modified by its intended and authorized users.
• Availability – Authorized users should always be able to access data for which they have been granted access.
What it says is that only users with proper credentials should be able to read, modify and access private data at any time. These three principles sum up the requirements that need to be fulfilled in order to provide an acceptable level of security. In this chapter, the most critical solutions for securing mobile device deployment are presented. Each suggestion is derived from one or more of the above principles. These solutions are persistent throughout the report and are meant to provide some insight on how they can protect against the attacks described in section 2and to be used in the implementation described in section 8.
3.1 screen-lock policy
The ability to configure a screen-lock using a PIN or password is a common feature on mobile devices to increase security and user privacy. It provides a simple authentication mechanism to prevent an adversary to gain direct access to device contents. Usually, multiple types of screen locks are available on different the platforms and includes options such as patterns or simple biometrics. However,PINs or passwords are the most common alternatives in terms of defining a manageable policy.
14 remote lock and wipe 3.2
A screen-lock policy is set to provide a minimum level of PIN or password entropy. Entropy is a measurement of password strength and its resistance against brute-force attacks. A screen-lock policy should therefore not be too simple or easy to predict. A proper screen-lock policy for mobile devices should include the following:
• Screen lock requirement - Users are required to have a PIN or password enabled on the device.
• High entropy - Specify a minimum length, number of letters, digits, symbols etc.
• Failed attempts - If too many unsuccessful log-in attempts are made, wipe the device.
• Screen lock timer - Time of inactivity before screen lock is activated.
This will prevent unauthorized users from gaining direct access to appli- cations and files, and prohibits brute-force and dictionary attacks. Hence the confidentiality and integrity of user data is significantly enhanced when a password policy is configured.
3.2 remote lock and wipe
Company devices that are frequently used are most likely to contain some form of sensitive data. It does not have to be just documents or files but credentials for e-mail or VPN services might also be available. In both cases, company intellectual property is at risk if a device is lost or stolen. An efficient way to protect confidentiality and integrity of data is a remote lock and wipe policy.
This will allow an administrator to remotely activate the device’s screen lock or initiate a device wipe that will erase all the content on the device. The remote lock feature will prohibit direct access to the device and the remote wipe will ensure that company data is no longer at risk. Since a password policy usually includes a screen lock timer (usually set to a couple of minutes) and it would take some time before the remote lock is actually performed, then a remote lock feature is quite redundant to implement. But it can still be useful the current password is changed to one with higher entropy, making it harder to perform brute-force attacks. However, it should be noted that the data is still available on the device once locked and it is still at risk. Remote wipe is therefore a more secure option for enterprise deployment.
3.3 encryption 15
3.3 encryption
Data encryption is a classic protection technique for digital information and is used to ensure data confidentiality. Mobile Device Security (MDS) primarily involves two types of encryption: device encryption and network encryption.
Device encryption refers to encryption of data in storage. As mentioned in the previous section, even if the screen lock is activated on a device it is still vulnerable to offline attacks. These are attacks that are directly targeted against the device hardware in order to extract data either directly from Random Access Memory (RAM) or storage. One example of such an attack is presented in section 5.2. Device encryption is used to protect plain text data and is recommended to prevent this data from getting extracted in the event of an offline attack. This will provide confidentiality for mobile devices but would not protect against the actual data extraction. However, unless the attacker manages to decrypt the data then it would be useless. Depending on encryption scheme, it will either prevent or delay an adversary from get hold of the actual data.
Network encryption concerns data on the network layer and provides protec- tion in transit over untrusted networks (Internet). Hypertext Transfer Protocol Secure (HTTPS) and Virtual Private Network (VPN) are examples on protocols and services that can be used to enforce this level of security and to avoid eavesdropping as well as data leakage. HTTPSis a secure version of Hypertext Transfer Protocol (HTTP) [19] that uses cryptographic features to encrypt the header and payload of a HTTPpacket. It is also widely used for server-side au- thentication in order to prove a server’s (or website’s) identity by presenting the client (user) with a valid certificate. The client can then verify these credentials through its trusted Certificate Authority (CA). Initially a negotiation process is performed to generate the keys needed to encrypt the traffic. This process is on a one-to-one basis, meaning that a negotiation is performed between each server that a user wants to establish a connection with. Another alternative for secure network communication is to use aVPN connection. VPNoperates on a lower level of the Internet protocol suite than HTTPSand resides in the Network layer (compared to HTTPSin the Application layer). Which makes it possible to provide protection to an entire Internet Protocol (IP) packet rather than just the payload. A VPN simulates a virtual network interface that enables users to remotely access resources and services on an internal network. The virtual interface encapsulates an IP packet within anotherIP packet that is used as a container between two end-points on an untrusted network, known as a VPN tunnel. The encapsulated packet is eventually extracted at aVPN gateway (e.g.
a company firewall) and can therefore enable usage of multiple services over the same connection without any additional key negotiations or authentication.
Hence a one-to-many scenario can be established. NeitherHTTPSnorVPN can provide protection for data that is already stored on a device, but it will provide
16 application control 3.4
a secure channel which can be used to transport data.
3.4 application control
The features described in sections 3.1, 3.2 and 3.3 are recurring examples of protection mechanisms used to against external threats. But it does not protect against internal threats, such as malicious applications that could be negligently installed by the user and could eventually steal data using legitimate methods.
Such applications could have been installed without the user’s knowledge, using phishing emails, social engineering or by masquerading as a legitimate application.
The market offers a wide range of devices from different manufacturers and with several operating systems to choose from. When designing a solution for
BYOD every brand andOSneeds to be taken into consideration together with their different capabilities. A general policy for application control is therefore difficult to enforce since the support differs on different platforms. The support for application control on Android, iOS and Windows Phone 8 (WP8) will be presented in section 6. Most mobile OSvendors do not allow applications to be distributed from a third-party and only from their official store. And most these vendors enforce a reviewing process involving test and code review in order to avoid malicious content from being published. The process differs between different vendors and they all have different thoughts on application distribution (see section4).
In addition to application review would be to provide an application blacklist or whitelist. A blacklist is describes a list of prohibited, while a whitelist refers to a list of approved applications. A blacklist is preferred to minimize the risk of known malicious or inappropriate applications getting installed. A whitelist is not suitable for global application control norBYOD, due to the large volume of available applications for each platform. While new applications are constantly released it would only result in many hours of maintenance work for administrators.
But also since the user is still the owner of the device and should be allowed to use the applications of his or her choice. An enterprise should only deny devices with known malicious applications installed from enrolling, and to assist in keeping the device free from malware. A blacklist is therefore the preferred choice and it can be also be complemented with a list of required applications, applications that an enterprise could require the user to have installed, e.g. VPN client.
3.5 device life-cycle 17
3.5 device life-cycle
To ensure the protection of intellectual property, it is important to consider the mobile device’s entire life-cycle. The majority of BYODandMDMsolutions primarily focus on the security for initial enrollment and its active period.
However, it is also important to considered what happens when the disposal of a device. A device that is unrolled from company activity or replaced by another device will most certainly contain valuable content and this needs to be handled. Hence a policy for device and content disposal is needed to protect data integrity.
National Institute of Standards and Technology (NIST) have recently pub- lished a general documentation containing suggestions, or guidelines, on how mobile devices should be handled within large-scale IT infrastructures in order to provide a decent security level [46]. It focuses on the risks that need to be considered when developing suitable device management solutions and how to maintain a high level of security throughout their entire life-cycle; from initial device enrollment to device disposal.
NIST defines the following steps for securing the mobile device life-cycle:
1. Initiation 2. Development 3. Implementation
4. Operations and Maintenance 5. Disposal
Figure 3.1: Device life-cycle for a secure enterprise
3.5.1 Initiation
The first step is to identify the requirements and necessary functionality for deploying mobile devices into the organization. A list of preparative actions includes:
• Level of access
18 device life-cycle 3.5
– Which resources should be accessible?
– How does it differ between company and personal (BYOD) devices?
• Policy
– What should be included in this policy?
– Can the policy be applied on all devices?
– Is it compliant with other company policies?
– Which devices should be allowed or supported?
The principle of least privilege should be considered and organizations should not allow more access than necessary for mobile devices. Users that possess a high level of clearance should still have limited access to resources when using a mobile device in order to minimize the loss during a potential breach. The goal of this initiation step is to obtain a general security policy on how to handle mobile devices. The different devices limitations are also discussed here. It is important to have knowledge of the available support to determine if a certain type of device is capable of fulfilling all the requirements, or if there is a more suitable alternative.
3.5.2 Development
The second step involves design development. There are many factors to con- sider including differentMDMtechnologies, client and server software etc. It is also relevant to consider certain security aspects such as types of authentication, algorithms for encryption, integrity protection and configuration requirements.
The encryption schemes should have been proven to be secure and certificated by a trusted authority. It is also important to use well-known algorithms such as Advanced Encryption Standard (AES) or RSA that have been proved to be secure and because they are continuously tested in order to find potential weaknesses.
3.5.3 Implementation
Once a solution has been designed, it should be implemented and tested properly prior to production deployment. Every device approved in section3.5.1 should be tested and properly verified to fulfill the following requirements:
• Connectivity – A user should be able to establish a maintainable connec- tion to access company resources. Users should also be able to access all resources for which they have been given permission and all resources outside this scope should be inaccessible.
3.5 device life-cycle 19
• Protection – Ensure protection of data on device storage in accordance with the design specifications.
• Authentication – Must work properly and cannot be circumvented.
• Management – A device can be managed efficiently and in a secure manor.
• Logging - The solution should log all events as specified in the company policy and is in accordance with the specifications set in the initiation step.
• Performance - All components in a given solution should perform correctly during normal and peak usage. Even intermediate device or equipment should be checked to avoid unexpected failure, e.g. in firewalls or routers.
• Security of the implementation - The security of the actual implementation should be carefully reviewed and tested properly to avoid vulnerabili- ties to be exploited. Jailbroken devices should not be allowed and the implementation should detect these devices in an initial state if possible.
• Default settings - The default settings should meet the minimum security requirements for the solution and a device should not be able to fall back to settings that would deem as insecure.
3.5.4 Operations and maintenance
This stage includes requirements for evaluation and updates once the solution has been deployed. The availability of recent updates and patches should be regularly checked and applied accordingly for each component in the solution.
The ability to reconfigure devices and modify user access must be functional in case a user’s policy is changed or additional security features are added.
The system should be monitored to detect and record anomalies such as policy violations and malicious behaviour.
It is critical to make sure that the clocks are synchronized on all components in order to avoid mismatches with timestamps between systems. Hence, all components should synchronized to a common time source, e.g. a Network Time Protocol (NTP) server.
Minimizing human error is also part of this step and is accomplished by educating employees on the defined security policies and on current threats to be aware of such as suspicious emails asking for passwords or credit card information.
20 recommendations 3.6
3.5.5 Disposal
The final step of this process is to ensure secure device content on disposal. No data should be at risk of being compromised after a device has been discarded in order to ensure that the integrity of company-confidential information is not exposed.
In some cases, this task might need more drastic measurements than to restore factory default settings. A removable storage card can still be present in a device and might not have been affected by a device wipe. Company data might also have been left on the internal storage and organizations that demand a more comprehensive security policy (e.g. government), it might be appropriate with a policy that involves complete device destruction in order to maintain confidentiality and integrity of intellectual property.
3.6 recommendations
To summarize, the following recommendations are to be considered prior to developing and deploying aBYOD solution:
• Screen-lock requirements
The screen-lock provides a simple protection that would prevent attacks that require direct access to the device, and would be the first impediment for an attacker on a lost or stolen device.
• Remote wipe functionality
Support for remote wipe provides the possibility of erasing proprietary data from a device that have been lost or stolen. A remote lock feature can also be used, but can be considered redundant if a screen-lock policy with a maximum idle time is applied.
• Device and Network encryption
Encryption is efficient to minimize the consequences of data-leakage, offline attacks and snooping. If data has been extracted from an encrypted storage then the data will be worthless until it has been decrypted. As long as the encryption keys are kept safe and their bit length is decent then the encryption will be very hard to crack. However, it is good practice to not fully trust the encryption and have a remote wipe feature available as well.
• Application control
Application control can be used to monitor installation or presence of any known malicious applications and can therefore minimize the risks of enrolling vulnerable devices, or to detect potential threats in real-time.
3.6 recommendations 21
• Device life-cycle and content disposal
It is wise to consider all the aspects of the device life-cycle when defining a policy or developing a client application for BYOD. If the entire life-cycle is evaluated then it is easier to find possible vulnerabilities and thereby limiting scope for an attack.
23
4 P L A T F O R M O V E R V I E W
Each platform has its own architecture but they all have some similarities, espe- cially when it comes to sandboxing. Sandboxing refers to application isolation and means that an application is executed in its own virtual machine to limit access to other applications and the operating system. It can also limit the usage of memory and other resources for each platform. In order to use system features such as network connectivity, each feature must be specifically declared by the application to allow access from its sandbox environment. This section provides an overview of each platform’s system architecture, its security and application development possibilities.
4.1 android
The Android Open Source Project [25] is an open source platform and was orig- inally developed by Android, Inc. It was eventually bought by Google in 2005 [16] and the first version was presented in 2007 in connection with the founding of the Open Handset Alliance (OHA), an organization that creates open standards for mobile devices [3].
4.1.1 System architecture
The Android platform is based on Linux and has inherited several of its security features. One of them is the user-based protection used for sandboxing. Each application is executed as a separate process using a Unique Identifier (UID) that would isolate the application from other apps to ensure that it can only access its own intended resources. For example, application A cannot read files that belong to application B and vice versa. However, it is possible for multiple applications to share the same process (UID) if they have the same issuer. The issuer can specify in the application’s specification (manifest file) that it should get the sameUID as another application (if previously installed) that originates from the same issuer.
An Android application can make use of several system resources. However, most of them are prohibited without the proper permission. Permissions are necessary to get access to OS features such as internet connectivity or cost-
24 android 4.1
sensitive functionality, e.g. SMS. Permission for a specific resource must be explicitly declared in the application’s manifest and the user must accept more sensitive permissions upon installation. The user will be prompted with a list of all the permissions that the application has declared in its manifest, in order to provide some insight on the application’s behaviour. There are four types of permissions and they are categorized based on the potential impact they could have on the system. The categories can be seen in table4.1.
Normal Low-risk permissions; granted automatically without any user interaction or notification at installation.
Dangerous Medium-risk permissions; granted by the user at instal- lation. Otherwise the application will not be installed.
Permissions cannot be selectively granted and therefore either all permissions are granted or none at all.
Signed High-risk permissions; These permissions are powerful but not available for regular developers. The application must carry a firmware signature in order to make use these permissions.
SystemOrSigned Same as the Signed permissions, except that the permis- sions are granted to all applications installed in the sys- tem/apps directory on a device.
Table 4.1: Android protection levels
Permission declaration enables the system to monitor and restrict applica- tions that are trying to communicate outside their isolated virtual environment to prevent malicious applications from getting too much influence over the system.
The Android project has its own Virtual Machine (VM) called the Dalvik Virtual Machine (DVM) which is an open-source software responsible for man- aging the applications on Android. It is optimized for running on devices that are battery-powered and has limited Central Processing Unit (CPU) or memory resources. Because of its low resource requirements theDVM can run efficiently on multiple VM instances simultaneously, which is a good quality for sandboxing. Android applications are written in Java but runs in theDVM, which differs from the traditional Java Virtual Machine (JVM) used in Java [17].
The compilation can be seen as a two-step process; The Java compiler creates
JVM byte code by compiling the source code and store it as class files. Then the Dalvik compiler consumes the complied class files and recompiles them into a single dex file, which will be part of the final application package for Android (.apk).
The Android boot process can be briefly described in six steps [63]. When
