iOS Encryption Systems

Deploying iOS Devices in Security-critical Environments

Peter Teuﬂ, Thomas Zefferer, Christof Stromberger and Christoph Hechenblaikner

Institute for Applied Information Processing and Communications,

Graz University of Technology, Inffeldgasse 16a, 8010 Graz, Austria

Keywords:

Smartphone Security, iOS, Encryption, Bring-Your-Own-Device, Mobile Device Management, Mobile

Devices, Risk Analysis, Security Analysis.

Abstract:

The high usability of smartphones and tablets is embraced by consumers as well as the private and public

sector. However, especially in the non-consumer area the factor security plays a decisive role for the platform

selection process. All of the current companies within the mobile device sector added a wide range of security

features to the initially consumer-oriented devices (Apple, Google, Microsoft), or have dealt with security as

a core feature from the beginning (RIM, now Blackerry). One of the key security features for protecting data

on the device or in device backups are the encryption systems, which are deployed in most current devices.

However, even under the assumption that the systems are implemented correctly, there is a wide range of

parameters, speciﬁc use cases, and weaknesses that need to be considered by the security ofﬁcer. As the ﬁrst

part in a series of papers, this work analyzes the deployment of the iOS platform and its encryption systems

within a security-critical context from a security ofﬁcer’s perspective. Thereby, the different sub-systems, the

inﬂuence of the developer, the applied conﬁguration, and the susceptibility to various attacks are analyzed in

detail. Based on these results we present a workﬂow that supports the security ofﬁcer in analyzing the security

of an iOS device and the installed applications within a security-critical context. This workﬂow is supported

by various tools that were either developed by ourselves or are available from other sources.

1 INTRODUCTION

The recent success story of smartphones and tablets –

further referred to as mobile devices – was mainly fu-

eled by user-friendly and consumer-oriented devices

introduced by Apple and Google in 2007 and 2008.

For the past years, Apple’s iOS and Google’s Android

have been dominating the market. Both companies

have introduced a wide range of security related fea-

tures to improve the device security for consumer and

business applications. Recently, the market power of

iOS and Android has been challenged by a new Win-

dows Phone 8 release and a new version of the Black-

Berry platform. For all major smartphone platforms,

encryption represents a core feature that is advertised

for its strong security. However, the deployed encryp-

tion systems differ in various security related aspects.

For instance, different platforms rely on different ap-

proaches to encrypt data (ﬁle based encryption vs.

ﬁle-system based encryption) and implement differ-

ent methods to derive required encryption keys from

user input (e.g. PIN or passcodes

). Furthermore, dif-

ferent platforms offer developers, administrators and

end users different options to use and conﬁgure pro-

vided encryption features.

Thus – if the platform should be deployed in a

security-critical context – a security analysis for a

given mobile device platform must consider a wide

range of different security related aspects. Even un-

der the assumption that the encryption systems and

algorithms are implemented correctly, there are many

other aspects that can render the systems ineffective.

Examples for such higher level aspects are parame-

ters related to system conﬁguration, application de-

velopment or the utilization of backup systems. In

fact those higher level aspects play a vital role in a

security analysis that needs to be conducted by a se-

curity ofﬁcer prior to deploying a platform within a

security-critical context.

Subsequently, we will refer to PIN and passcodes only

with the term passcode.

170

Teuﬂ P., Zefferer T., Stromberger C. and Hechenblaikner C..

iOS Encryption Systems - Deploying iOS Devices in Security-critical Environments.

DOI: 10.5220/0004526201700182

In Proceedings of the 10th International Conference on Security and Cryptography (SECRYPT-2013), pages 170-182

ISBN: 978-989-8565-73-0

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

As the ﬁrst part in a series of security analyses

emphasizing those high-level aspects, this work ana-

lyzes the iOS encryption and backup systems. After

giving a detailed description of the respective systems

and the possible attacks, we present a workﬂow that

can be followed by a security ofﬁcer in order to en-

sure that the various encryption systems provide the

intended protection for security-critical data. This

workﬂow is supported by several tools that were ei-

ther developed by ourselves or other parties.

2 RELATED WORK

The details on the encryption systems presented in

this work, the conductedsecurity analysis and the pro-

posed workﬂow are based on a wide range of infor-

mation sources and projects that were started in late

2011. These projects are related to the authors’ mo-

bile security consulting work within the public sec-

tor and the development of the Secure Send

appli-

cation which relies on the iOS encryption systems to

securely store data, and exchange this data via CMS-

based containers

via email or Dropbox. The details

about the deployed encryption systems have been ex-

tracted from ofﬁcial documents, from sources related

to the iOS jailbreak and forensics communities and

scientiﬁc publications. Especially within the consult-

ing context the authors have extracted many prac-

tical requirements in security-critical environments.

These requirements and the thereby generated ques-

tions form the basis for the proposed workﬂow that is

presented in this work. The development of the Se-

cure Send application helped to understand the iOS

security mechanisms and the inﬂuence of the devel-

oper within a security-critical context. The remainder

of this section will refer to the information sources

that helped us to gain an in-depth understanding of

the iOS encryption systems.

For our contribution, related work dealing with

encryption systems for mobile devices is of special

interest. Indeed, various authors have approached this

topic from different perspectives so far. The rele-

vance of encryption solutions on mobile devices and

possible implications on jurisdiction have been dis-

cussed in (Paul et al., 2011). Proprietary encryption

solutions for smartphone platforms have for instance

been proposed in (Shurui et al., 2010) and (Chen and

Ku, 2009). Interestingly, most related work on en-

cryption systems on mobile devices does not focus

on the platform’s encryption systems, but on the de-

velopment of proprietary solutions. Such solutions

https://itunes.apple.com/app/id560086616

http://tools.ietf.org/html/rfc5652

are often utilized within container applications that

play an important role within the currently popular

Bring-Your-Own-Device (BYOD) scenario. Due to

the private ownership of the devices in such a sce-

nario, those devices and their conﬁguration typically

cannot be controlled via mobile-device-management

(MDM) solutions that activate and conﬁgure the plat-

form’s security mechanisms. Due to the lack of these

management facilities and the thereby associated ac-

tivation and conﬁguration of the platform’s security

mechanisms, unmanaged devices typically cannot be

deployed within a security-critical context.

There is only one white paper available from Ap-

ple that addresses the iOS encryption systems (Apple,

2012). Unfortunately, this document only presents

a superﬁcial overview and lacks many important de-

tails. The most detailed analyses of the iOS encryp-

tion and backup systems are available from the foren-

sics community, where the recovery of the stored data

plays a crucial role. The presentation by (Belenko and

Sklyarov, 2011) describes the evolution of forensics

from the ﬁrst version of iOS to iOS 5.0 and thereby

highlights the weaknesses of the initial versions that

were later addressed by introducing various protec-

tion systems. The same topic is also addressed by

others, such as (Hoog and Strzempka, 2011). Apart

from the forensic oriented approach, many sources

cover the details and the weaknesses of the iOS en-

cryption systems, and iOS security in general. Early

work on the security of the iOS encryption systems

is presented by (Pandya, 2008). The iOS encryption

systems, the involvedkeys and conceptsare addressed

by the following sources: A project

dedicated to

the iOS data protection system describes the keys in-

volved in the encryption systems (Bedrune and Sig-

wald, 2011). A general security analysis for iOS 4 is

presented by (Zovi, 2011). Although, this iOS version

is outdated, the analysis still provides important in-

formation, due to the introduction of the Data Protec-

tion system in iOS 4. A very important aspect of this

Data Protection system is discussed in the iOS Key-

Chain FAQ (Heider and Khayari, 2012). This doc-

ument addresses the problem of choosing protection

classes that do not adequately protect KeyChain en-

tries such as passwords or symmetric and asymmetric

key material. Another relevant source is the iPhone

Wiki

covers a wide range of iOS security related as-

pects.

When analyzing the security of the stored data on

iOS devices, one also needs to consider the iTunes

and iCloud backup systems that are used to backup

application data on a local device or within the Ap-

http://code.google.com/p/iphone-dataprotection/

http://theiphonewiki.com

iOSEncryptionSystems-DeployingiOSDevicesinSecurity-criticalEnvironments

171

ple iCloud solution. Details about the information

stored in iTunes backups can be found on a dedicated

webpage on the previously mentioned iPhone Wiki

The aspects related to forensics are covered by var-

ious other sources that describe the backup process,

the difference between standard and encrypted back-

ups and the implications for a forensic analysis (In-

fosec Institute, 2012b), (Infosec Institute, 2012a).

3 THREATS AND ASSUMPTIONS

The presented security analysis is based on the sce-

nario that a security ofﬁcer within the public or private

sector is confronted with the task of deploying the iOS

platform within a security-critical context. Thereby,

mobile devices and the required applications are uti-

lized to process and store security-critical data.

The main threats in relation to mobile device

security are related to the possibility of an attacker

gaining physical access to the device (theft), or

installing malware on the device. The main em-

phasis of this paper is placed on the ﬁrst threat –

theft. Malware is only considered in the context of

jailbreaking where a piece of software that gains root

access to the device by exploiting a security ﬂaw, is

deliberately installed by the user or attacker.

Theft. The following assumptions for the conducted

analysis are deﬁned within the context of an attacker

stealing a device containing security-critical data.

First, our assessments are based on the assumption

that the iOS encryption systems are implemented

correctly. The goal of this assessment is to analyze

weaknesses located on a higher level, such as miscon-

ﬁgurations, weak passwords, limits of key derivation

functions or wrong assumptions in relation to the

encryption scope (e.g., ﬁles vs. ﬁle-system). Second,

we assume that a passcode-locked iOS device is

stolen by an attacker who is an expert with in-depth

knowledge about the deployed encryption systems

and their weaknesses. This scenario is similar to the

one faced by a forensic expert who needs to analyze

the data stored on an iOS device. In this context we

also assume that the attacker employs jailbreaking

tools. This is the only type of malware

that will

be considered in the conducted analysis. Finally,

the analysis is mainly focused on managed devices

that are conﬁgured via mobile-device-management

http://theiphonewiki.com/wiki/ITunes

Backup

Jailbreak software might not be considered as mali-

cous, when deliberately installed by the user. Still, this type

of software needs to exploit a security ﬂaw in order to gain

root access. Therefore, there is a high similarity to malware.

solutions. The rationale behind this assumption is the

security-critical deployment scenario that forms the

basis for this analysis. In such an environment, the

currently popular Bring-Your-Own-Device scenario

can only play a minor role due to the user’s sole

control of the security related device conﬁguration

(setting passcodes, activating/deactivating encryp-

tion systems, backups). In such a scenario, the

developers/administrators cannot rely on platform

security and encryption systems, but must implement

their own protection mechanisms (e.g., container

applications

), which typically cannot achieve the

same level of security as it is provided by system

functionality.

Malware. Although malware related attacks with the

exception of jailbreaks are not considered in the re-

mainder of this work, a short overview on the differ-

ent malware categories and their implications are dis-

cussed in this section. Also, the reasons for excluding

these kind of attacks in this analysis are explained.

We refer to malware as a piece of software that

is installed on the user’s device, even if the attacker

does not have physical access to the device. The in-

stallation could either be initiated by the user who in-

tentionally installs an application that contains hidden

malicious code, or by an action that triggers the in-

jection of malicious code via a security ﬂaw in the

device’s operating system or applications. An exam-

ple would be a critical browser vulnerability that is

exploited when the user visits the attacker’s webpage

hosting the exploit code and the malicious payload in-

jected via the security ﬂaw.

We need to differentiate between two types of ma-

licious applications: First, malware that exploits crit-

ical system vulnerabilities to gain root access to the

device, and second, malware that only relies on the

standard platform APIs. This malware could either

extract the protected data from the victim’s phone, or

gain additional information that helps the attacker to

break the encryption systems, when physical access

to the device is gained at a later time.

Unfortunately, when a malicious application of

the ﬁrst category gains root privileges on the targeted

device, none of the existing encryption systems can

protect the stored data. Malicious code executed with

root privileges can inspect or modify arbitrary aspects

of the device’s operating system and thus in one way

or another gain access to the protected data. Exam-

ples for such attacks would be the deployment of key-

loggers, the extraction of encryption keys from the

Such as the solutions by Good Technology and Excitor.

http://www1.good.com/mobility-management-solutions/

bring-your-own-device and http://www.excitor.com

SECRYPT2013-InternationalConferenceonSecurityandCryptography

172

device’s memory, or accessing the data while it is de-

crypted (e.g. when the user unlocks the phone). This

does not mean that such attacks do not need to be con-

sidered. However, the defence against such attacks is

already partly covered by a tight security conﬁgura-

tion of the device. Also, the protection mechanisms

for such attacks need to be implemented on a much

lower level that is out of scope of a security ofﬁcer’s

sphere of inﬂuence.

The second malware-category relies on the stan-

dard functionality provided by the platform’s APIs

and thus the capabilities can be compared to those

of standard applications. Although, such malware is

not capable of gaining direct access to the encrypted

data, it could gather information for a later carried out

physical attack. Examples are phishing passcodes,

extracting information about passcode complexity, or

any other side-channel information that might help

the attacker to gain access to the protected informa-

tion. Due to wide range of possible ways to gain ad-

ditional information, this second malware category is

considered as out of scope here, but will be addressed

in future work.

4 iOS ENCRYPTION SYSTEMS

The iOS encryption system is based on multiple

on-device, backup and cloud related sub-systems

that have different purposes and protection mecha-

nisms: the always-on ﬁle-system encryption system,

the Data Protection system for ﬁles and credentials

(KeyChain), the encryption systems for iTunes/iCloud

backups, and ﬁnally the iCloud document-sharing

mechanism. Although, these systems offer a reason-

able level of protection, they still need to be deployed

and conﬁgured correctly. Mistakes made by the de-

veloper or the security ofﬁcer can easily make the sys-

tems ineffective.

In the following analysis the respective system de-

tails, the involved key derivation functions and issues

in relation to conﬁguration and development are con-

sidered for each iOS sub-system. The gained results

are summarized in Table 1.

4.1 File-system Encryption

The ﬁle-system encryption system is available since

iOS 3 and the iPhone 3GS. The encryption system re-

lies on a hardware AES 256 crypto engine (Apple,

2012) that is present on every iOS device – further re-

ferred to as secure element. This chip securely stores

a unique device (UID) key that is used to generate and

protect all further encryption keys. The ﬁle-system

Table 1: Attacks on the various encryption systems: White

indicates no or only minor problems that can be mitigated.

Dark-grey represents more critical issues that deﬁnitely

need to be considered. Black represents critical security

problems, that are not solved by the respective system and

need to be dealt with, either by deactivating the system or

relying on other systems. NA indicates that an attack is not

applicable/relevant for the respective subsystem.

Systems/Attacks

Brute-force

attacks

Jailbreak/

rooting

Poor

developer’s

choice

Poor configuration

options

On-device (iPhone, iPod, iPad)

File-system

encryption

direct access to

data

no influence/

always on

no influence/always on

Data Protection -

files

on-device

brute-force

required

file protection

class

only when passcode is set

Data Protection -

KeyChain

on-device

brute-force

required

KeyChain

protection class

only when passcode is set

Off-device (PC, Laptop)

Standard backup -

files

backup flag

unencrypted backups,

backups enabled, bad

system protection

Standard backup -

KeyChain

not possible

no influence

Encrypted backup -

Files

off-device

brute-force

backup flag

weak passwords, backups

enabled, bad system

protection

Encrypted backup -

KeyChain

off-device

brute-force

KeyChain

protection class

weak passwords, backups

enabled, bad system

protection

Cloud, Internet

iCloud backup - files

attacks on

iCloud Account

backup flag

Weak iCloud password,

cloud provider

iCloud backup -

KeyChain entries

attacks on

iCloud Account

KeyChain

protection class

Weak iCloud password,

cloud provider

iCloud document

sharing

attacks on

iCloud Account

implemented by

the developer

Weak iCloud password,

cloud provider

based encryption system is always-on and cannot be

conﬁgured neither by the developer nor the security

ofﬁcer/user. Unfortunately, not including the user’s

passcode in the protection system is a major weak-

ness that can be exploited by an attacker. Therefore,

the ﬁle-system encryption system is primarily used to

provide basic protection and to implement the quick-

remote wipe functionality. Instead of going to the

lengthy process of deleting the stored data, only the

associated encryption keys are wiped, which crypto-

graphically erases the stored data.

4.1.1 Details

An overview about the AES keys involved in this sys-

tem and their protection is provided in Figure 1. Each

iOS device has a unique AES key (UID key) that is

stored within the secure element. This key is used to

derive

the AES keys labelled as 0x89B and 0x835.

These keys are used to wrap the EMF (ﬁle-system

master encryption key) and Dkey (device key) keys,

which are stored in the effaceable storage area of the

ﬂash memory. This ﬂash memory area can be wiped

very quickly, and thus offers a robust remote-wiping

functionality which deletes the ﬁle-system encryption

keys instead of the whole ﬁle-system data. The EMF

key is used as a master key for the ﬁle-system encryp-

Both keys are generated by encrypting different con-

stants with the UID key.

iOSEncryptionSystems-DeployingiOSDevicesinSecurity-criticalEnvironments

173

tion process. The Dkey plays a role within the later

explained Data Protection system. For now, it is only

relevant that both keys are indirectly protected with

the UID key without involving the user’s passcode.

The employment of a secure element eliminates the

possibility to access the data within ﬁle-system im-

ages that are gained by cloning or directly extracting

the storage device. In other words, any attack on the

ﬁle-system must involvephysical access to the device.

UID key

key 0x89B

key 0x835

Dkey

EMF key

Effaceable

storage

Secure element

File system

File

KeyChain

Figure 1: A simpliﬁed representation of the AES encryp-

tion keys that are involved in the ﬁle-system encryption.

The most important aspect is that only the secure element

is involved in the protection of these keys.

4.1.2 Key Derivation

Strictly speaking the notation ”key derivation” is not

adequate for an description on how the system gener-

ates and protects the described keys. The reason is,

that the UID key within the secure element is used

to create the 0x89B and 0x835 keys, which are then

used to protect the EMF and Dkey keys. This pro-

tection hierarchy does not involve the user’s passcode

and its security is only based on the UID key that is

stored in the secure element and cannot be extracted.

The aspect of not including a user supplied passcode

is considered as the main weakness of the ﬁle-system

based encryption system.

4.1.3 Conﬁguration/Developer

The developers, users or administrators cannot inﬂu-

ence this encryption system, since it is activated per

default on every device and cannot be deactivated.

However, all of the involved developers, users and

administrators need to be aware of the limited level

of protection this system provides when deploying

security-critical applications.

4.1.4 Attacks

The system can easily be attacked via Jailbreak-

ing/Rooting, which concentrates on the weakest point

of the ﬁle-system based encryption system: The pro-

tection of the EMF and Dkey keys for encrypting the

ﬁle-system is not based on the passcode of the user,

but relies only on the integrated secure element. Thus,

even when a passcode is set on the device, the appli-

cation of a jailbreak enables the attacker to gain root

access to the operating system, which decrypts the

data with the EMF and Dkey keys. Thus, an attacker

gains access to all data without knowing any of the

deployed encryption keys. Jailbreaks are available for

almost all iOS versions and devices

. However, un-

der our assumption that an attacker gains access to a

passcode-locked device, only those jailbreaks that do

not rely on a task carried out by the user (e.g. access-

ing a webpage that exploits a critical security vulner-

ability in the Web browser, or installing a malicious

application), can be used for the attack

. These jail-

breaks are referred to as tethered jailbreaks and typi-

cally rely on security ﬂaws in the iOS boot process.

Since the encryption system is always-on and does

not provide any conﬁgurationoptions, it is not suscep-

tible to any misconﬁgurations made by the developer

(poor developer’s choice) or the user/administrator

(poor conﬁguration option). Any attacks on the key

derivation function itself are not considered, due to

the fact that access to the data is already gained when

a jailbreak is successfully applied to the system.

4.2 Data Protection System – Files

The Data Protection system was introduced with iOS

4 and offers an additional layer of protection for ﬁles

and KeyChain entries stored on an iOS device. The

main advantage of this system – when compared to

the ﬁle-system based encryption system – is the key

derivation function (KDF) that provides the function-

ality of deriving an encryption key based on the user’s

passcode and the UID key stored in the secure ele-

ment. The encryption keys gained by the KDF are

then used to wrap further keys that are used to protect

single ﬁles and credentials according to the protec-

tion class assigned by the developer. Although, the

system offers a quite good level of protection for the

respective application ﬁles, it is also quite complex

and requires in-depth knowledge of the developer.

This section describes the Data Protection system

in the context of ﬁle protection. The protection of cre-

dentials stored in the iOS KeyChain is another feature

of the Data Protection system. However, due to some

important differences the KeyChain protection will be

explained separately in Section 4.3.

A good overview is given here:

http://www.apfelzone.at/jailbreak-ubersicht/

Here, malware that exploits critical security ﬂaws

might play a role without the need for the attacker to have

physical access to the device.

SECRYPT2013-InternationalConferenceonSecurityandCryptography

174

4.2.1 Details

A detailed overview over the Data Protection sys-

tem is given in Figure 2. The system is based on

various protection classes that need to be deﬁned by

the developer for stored ﬁles and credentials. Each

protection class has a speciﬁc class key that is used

to encrypt/decrypt the speciﬁc ﬁle encryption keys.

Thereby, each ﬁle has a unique ﬁle-encryption key

(indicated as cprotect key in Figure 2). The protection

classes deﬁne when the class keys are kept in memory

for encrypting and decrypting the ﬁle encryption keys

and thus the respective ﬁles. Thereby, each ﬁle is pro-

tected by a unique ﬁle encryption key. The four avail-

able data (ﬁle) protection classes are NSFileProtec-

tion{None, Complete, UntilFirstUserAuthentication,

CompleteUnlessOpen}. Thereby, None indicates that

the ﬁle is only protected via the ﬁle-system based en-

cryption (keys based on the EMF key) and the Dkey

key, which acts as class key for this protection class.

Complete means that the class key and the ﬁle-

encryption keys of the protected ﬁles are removed

from memory whenever the device is locked. Until-

FirstUserAuthentication decrypts the respective class

key when the passcode is entered the ﬁrst time after

booting the device. The decrypted keys are then kept

in device memory until the next shutdown. Finally,

CompleteUnlessOpen is used to write data to ﬁles that

are open when the device is locked, and in addition of-

fers a system based on asymmetric cryptography that

is used for encrypting data which is received while the

device is locked (e.g. emails).

4.2.2 Key Derivation

The Data Protection system employs the standard-

ized Password Based Key Derivation Function 2

(PBKDF2) (Apple, 2012), which is speciﬁed in

PKCS#5 (Kaliski, 2000). The user’s passcode is tan-

gled with the UID key stored in the secure element

and combined with a salt (not shown in Figure 2).

The resulting value is then used as input for the key

derivation function with a high iteration count. The

gained key (passcode key) is used to encrypt and de-

crypt the aforementionedprotection class keys, which

are in turn used to protect the actual ﬁle encryption

keys.

4.2.3 Developer

The Data Protection system is only effective when

the developer has detailed knowledge about iOS se-

curity and carefully selects the appropriate protection

classes for the data that needs to be protected. Es-

pecially, the protection class NSFileProtectionNone

does not offer any protection beyond the standard ﬁle-

system based encryption system and thus must NOT

be considered as an option for security-critical appli-

cations.

4.2.4 Conﬁguration

The administrator’s primary inﬂuence on this system

is the enforcement of speciﬁc passcode properties that

are mandatory for the user. By setting a passcode, the

Data Protection system is activated and protects the

ﬁles marked with the appropriate protection classes.

For managed devices, there exists a wide range of

rules that deﬁne the password complexity require-

ments.

One of the major problem for expert users or ad-

ministrators is that there is no simple way to deter-

mine the protection classes that were selected by the

developer for the application ﬁles. However, this in-

formation is vital for selecting applications that are

appropriate for handling and storing security-critical

data.

4.2.5 Attacks

When Rooting/Jailbreak an iOS device, which is

protected by the Data Protection system, the attacker

still has access to the ﬁle-system. However, the ﬁles

and credentials that use the correct protection classes

(other than None for ﬁles) cannot be decrypted with-

out knowing the passcode. Under the assumption,

that this passcode is not known to the attacker the

only remaining option for the attacker is the applica-

tion of a brute-force attack. However, the presence

of the secure element and the PBKDF2 key deriva-

tion function signiﬁcantly slows down the brute-force

attack. Due to the high iteration count of PBKDF2,

the derivation of the passcode key from the passcode

takes roughly 80 ms (Apple, 2012). This delay can

be used to calculate the worst-case brute-force attack

times when choosing a password. Also, and proba-

bly even more important, the brute-force attack must

be carried out on the device, because the secure el-

ement is also involved in the key derivation process.

This eliminates the possibility to speed up the attack

by deploying an off-device attack capable of using a

high level of computational resources. The described

attack is implemented by a forensic toolkit offered by

the UK based company Elcomsoft

Although, the combination of the secure element

and the passcode for key derivation offers a reason-

able level of security, the overall level of security

strongly depends on the developer as well as the

http://www.elcomsoft.co.uk/eift.html

iOSEncryptionSystems-DeployingiOSDevicesinSecurity-criticalEnvironments

175

UID key

key 0x89B

key 0x835

passcode key

passcode

KDF

Dkey

EMF key

Effaceable storage

Secure element

Complete

per-entry-key A Entry

per-entry-key B

Entry

cprotect key A

File 1

cprotect key B

File 2

KeyChain

Files

CompleteUntilFirstUserAuthentication

CompleteUnlessOpen

None

WhenUnlockedThisDeviceOnly

AfterFirstUnlock

Always

cprotect key C

File 3

WhenUnlocked

AfterFirstUnlockThisDeviceOnly

AlwaysThisDeviceOnly

KeyChain Protection Classes

File Protection Classes

per-entry-key C

Entry

per-entry-key D

Entry

File systembag.kb

cprotect key D File 4

per-entry-key E

Entry

per-entry-key F

Entry

File system

Figure 2: iOS Data Protection system for the protection of individual ﬁles and credentials. The encryption behaviour is

deﬁned by the developer via different protection classes. The most important aspect is that the key derivation function (KDF)

that generates the Passcode key for the protection of the protection class keys depends on the UID key within the secure

element as well the Passcode of the user.

user/administrator. Poor conﬁguration options are

especially critical in the unmanaged scenario where

the user selects the passcode. In this case, the at-

tacker can base an attack on the Data Protection sys-

tem on the following assumptions: (1) Due to usabil-

ity issues related to passcode length and complexity,

the user will typically not use a passcode or select a

rather short one. (2) Since the default setting for pass-

code locks on an iOS device uses 4-character numeri-

cal PIN codes (also indicated by the type of deployed

lock-screen) a successful brute-force attack is quite

likely.

Apart from the conﬁguration issues, poor devel-

oper choices have a major inﬂuence on the security

of the application ﬁles. When the wrong classes (es-

pecially NSFileProtectionNone) are chosen by the de-

veloper, the security is reduced to that of the ﬁle-

system based encryption, which can be circumvented

by applying Jailbreaking/Rooting. This opens a crit-

ical security issue, that could easily be exploited by

an attacker. Assuming an application (e.g. the Ap-

ple mail) application uses the right protection classes,

further assuming a user opens an attachment (e.g. a

PDF ﬁle) in an external application that employs the

NSFileProtectionNone protection class for storing the

ﬁle: Then an attacker does not need to apply a brute-

force attack on the passcode in order to get access to

the email with the PDF document. Instead, the at-

tacker can simply apply a jailbreak and extract the

ﬁle form the external application that was used to

view/edit the PDF ﬁle. Unfortunately, iOS does not

provide any means for the user/administrator to in-

spect the protection classes used for the application

ﬁles.

4.3 Data Protection System – KeyChain

The Data Protection system is also available to pro-

tect data such as passwords or key material stored in

the iOS KeyChain. The main differences to the ﬁle-

based Data Protection system are the available pro-

tection classes and the possibility to use protection

classes that allow or disallow the transfer to other de-

vices.

4.3.1 Details

iOS provides the functionality of storing credentials

such as private keys, passwords and certiﬁcates in

the iOS KeyChain. The functionality of the offered

protection classes kSecAttrAccessible{Always, Whe-

nUnlocked, AfterFirstUnlock} corresponds to the ﬁrst

three ﬁle Data Protection classes (None, Complete,

UntilFirstUserAuthentication). However, there is no

class that is equivalent to the CompleteUnlessOpen

ﬁle protection class. An important difference to

the ﬁle-based classes is that the KeyChain protection

classes also exist in a ThisDeviceOnly version which

indicates that the KeyChain data cannot be transferred

off-device via iTunes or iCloud backups (covered in

detail in Sections 4.4 and 4.5).

4.3.2 Key Derivation

The KDF for the key used to protect the respective

SECRYPT2013-InternationalConferenceonSecurityandCryptography

176

class keys is based on the same function as deployed

within the ﬁle-based Data Protection system (Section

4.2.2 and Figure 2).

4.3.3 Conﬁguration/Developer

The inﬂuence of the conﬁguration options are equal

to those of the ﬁle-based protection classes. Except

for some slight differences, this also applies to the de-

veloper: For the KeyChain protection classes the Al-

ways, AlwaysThisDeviceOnly classes are considered

as dangerous, because their deployment has the same

implications as the deployment of the None protection

class. There is no class, which is equivalent to the

CompleteUnlessOpen ﬁle protection class. One dif-

ference that needs to be considered is that the devel-

oper indicates whether a protected credential is trans-

ferable to another device. This option is not avail-

able for the ﬁle protection classes. For further details

and implications the reader is referred to the backup-

related Sections 4.4 and 4.5.

4.3.4 Attacks

Regarding the attacks, very similar conclusions as for

the ﬁle-based Data Protection system can be drawn:

The classes Always and AlwaysThisDeviceOnly are

susceptible to Rooting/Jailbreaking attacks, which

corresponds to the implications of the None ﬁle pro-

tection class. The problem is extensively discussed

in (Heider and Khayari, 2012). The considerations

for attacks based on poor conﬁguration/developer

choices are equivalent to those of the ﬁle protection

classes.

4.4 Backup on iTunes

Although the backup encryption system is techni-

cally not a part of the mobile device, it still plays

an important role for the security of data and creden-

tials. On iOS, the backup can either be made via an

iTunes installation, or the Apple based iCloud solu-

tion. Thereby, the iTunes backup can either be stored

in plain text or be encrypted with a key derived from

a password. The differences are depicted in Figure 3.

4.4.1 Details – Standard Backups

The ﬁles on an iOS device, that are marked by the

developer for backup (which is the default setting),

are stored by iTunes (via USB cable or WiFi) in plain

text. Since the ﬁles on the deviceare encrypted via the

Data Protection system, the iTunes access to those

ﬁles is not possible without the respective keys. On

the iOS device the system keybag contains all the pro-

tection class keys, that are required to wrap the re-

spective ﬁle/credential encryption keys. When iTunes

is connected to the iOS device for the ﬁrst time, an es-

crow keybag is generated on the backup device. This

keybag contains the protection class keys of the sys-

tem keybag and is encrypted via a randomly gener-

ated key that is stored on the iOS device. This key

is stored in the KeyChain with the attribute kSecAt-

trAccessibleAfterFirstUnlockThisDeviceOnly, which

means that the key is only available when the pass-

code is entered correctly after system boot up, and the

ThisDeviceOnly part indicates that it cannot be trans-

ferred to other devices. Whenever iTunes copies the

ﬁles from the iOS device, this key is used to decrypt

the escrow keybag in iTunes and thereby the protec-

tion class keys. iTunes is now capable of decrypting

the ﬁles on the iOS device and transferring them to

the backup location.

The KeyChain entries of the iOS device are also

transferred to the iTunes backup. However, and this

is the important part, they remain encrypted with the

device’s protection class keys, and thus cannot be de-

crypted without physical access to the device. This

leads to the somehow confusing aspect that the Key-

Chain entries are better protected in standard iTunes

backups than they are in encrypted iTunes backups.

4.4.2 Details – Encrypted Backups

Encrypted backups require the user to deﬁne a backup

password that is used to derive an encryption key,

which is then used to encrypt the ﬁles and the iOS

KeyChain. There are two important aspects that need

to be considered here: (1) the ﬁles are stored en-

crypted, which offers a much higher protection level

than within the standard backups. (2) the system key-

bag is encrypted with the backup key that is derived

from the user’s backup password. This enables the

transfer of KeyChain entries to other devices, which

is not possible in standard backups due to the encryp-

tion with a device-bound key.

4.4.3 Key Derivation – Standard Backups

Since the ﬁles are stored in plain text on the de-

vice where iTunes is installed, there is no key deriva-

tion function involved. The KeyChain entries are en-

crypted via device-speciﬁc keys, which are not avail-

able off-device.

4.4.4 Key Derivation – Encrypted Backups

This key derivation is also based on the PBKDF2

function. However – and this is the most important

iOSEncryptionSystems-DeployingiOSDevicesinSecurity-criticalEnvironments

177

Escrow

keybag

Files

System

keybag

Device

Independent

System

keybag

Protection class keys

App-speciﬁc

KeyChain-Entries

DeviceIndependent

Escrow keybag key

ThisDeviceOnly

Application ﬁles

File system

Protection

class keys

Backup

keybag

iTunes

encryption

keys

App-speciﬁc

KeyChain-Entries

ThisDeviceOnly

Protection class

keys

App-speciﬁc

KeyChain Entries

Backup

Passwort

iTunes Backup

Backup

key

iOS device Encrypted iTunes backup

Escrow

keybag

Files

System

keybag

Device

Independent

Protection

class keys

Protection class

keys

App-speciﬁc

KeyChain Entries

iTunes Backup

Standard iTunes backup

Figure 3: iTunes backup systems: Standard backups store the ﬁles in plain on the backup device. The credentials cannot be

decrypted without physical access to the iOS device. Encrypted backups encrypt the ﬁles and the credentials with a password

derived key.

difference to the Data Protection system KDF – due

to the lack of a secure element on the PC/laptop where

iTunes is installed, the key derivation subsystem is

only based on the backup password, which allows for

faster brute-force attacks.

4.4.5 Conﬁguration

iTunes standard and encrypted backups can be ac-

tivated and conﬁgured within the iTunes conﬁgura-

tion. For managed devices, the administrator can-

not deactivate iTunes backups if the user decides to

use them. However, the administrator can enforce

encrypted iTunes backups, which forces the user to

deﬁne a backup password. Unfortunately, no rules

regarding the password complexity can be deﬁned,

which leaves the password selection to the user.

4.4.6 Development

Files that are used within applications are marked for

backup per default. The developer can exclude ﬁles

that should not be included in iTunes/iCloud back-

ups via the ﬂags NSURLIsExcludedFromBackupKey

or kCFURLIsExcludedFromBackupKey. Those ﬁles

will never be included in unencrypted/encrypted and

iTunes/iCloud backups. For security-critical data, the

developer should typically deactivate the backup of

the associates ﬁles.

4.4.7 Attacks

The backup on an iTunes device can be attacked via

different techniques. (1) The developer might chose

to include security-critical data within backups (poor

developer’s choice). If this is the case a wide range

of attacks can be derived depending on the admin-

istrator’s and user’s choices regarding the available

backup systems and their protection mechanism: (2)

When the administrator allows non-encrypted stan-

dard backups (poor conﬁguration options), the at-

tacker can just copy the whole backup and get access

to all of the ﬁles that are marked for backup by the in-

stalled iOS applications. (3) When encrypted backups

are utilized, the attacker can carry out an off-device-

brute-force attack on the encryption password. Due

to the lack of a secure element, the attacker can use

external processing resources to speed up this attack.

Unfortunately, the administrator cannot deﬁne pass-

code policies that are mandatory for the user. This

also applies for iCloud account passwords. (4) The

user/administrator also decides whether the iCloud-

based system is allowed. In case of its availability

security issues with the iCloud account can be used

for an attack path by an attacker to gain access to the

backups (poor conﬁguration options).

Two interesting aspects of the iTunes backup sys-

tem are related to the credentials backup: (1) Only

those credentials that are not marked via the ThisDe-

viceOnly protection classes are stored in the backup.

(2) The standard backup offers a better protection for

the stored credentials than the encrypted backup. In

the ﬁrst case, the encrypted iOS KeyChain is directly

stored in the backup. Thereby, the encryption keys re-

quired to decrypt the KeyChain are only available on

the iOS device itself. Thus, an attacker who has ac-

cess to the unencrypted backup, can extract the stored

SECRYPT2013-InternationalConferenceonSecurityandCryptography

178

ﬁles, but not the credentials. This also means, that

the stored credentials cannot be transferred to another

iOS device, due to the lack of the encryption keys re-

quired to decrypt the backed up KeyChain. In case

of an encrypted backup the KeyChain is encrypted

with encryption keys that are derived from the backup

password. Thus, those credentials are susceptible to

the described brute-force attacks.

4.5 iCloud

Two main iCloud features need to be considered –

iCloud backups and iCloud document sharing. While

the ﬁrst feature is strongly related to iTunes backups

and is activated by the respective backup ﬂags, the

second feature is used to share application data over

different iOS and OS X devices. In contrast to the

backup functionality, which needs to be explicitly de-

activated by the developer via speciﬁc ﬂags, the sec-

ond feature needs to be deliberately implemented by

the developer. In both cases, the security of the data

stored on iCloud highly depends on the security of the

associated iCloud/iTunes accounts. When an attacker

gains access to an iCloud account the stored backup

ﬁles and the shared documents can easily be restored

on the attacker’s device who then gains access to the

security-critical data.

It is highly recommended that the iCloud func-

tionality is deactivated by the MDM administrator.

This recommendation is based on a wide range of

security issues: A secure iCloud password needs to

be chosen by the user. Here, similar issues as for

the encrypted backups need to be considered. The

quality of the iCloud password cannot be enforced

by the administrator via MDM rules. Furthermore,

iCloud and iTunes account security has been brought

into the news in 2012, when an account of a jour-

nalist was successfully attacked by exploiting weak-

nesses in the call center policies for gaining access

to accounts where the password was lost

. In a

recent report various security issues in relation to

the transferal of iTunes/iCloud credentials over unen-

crypted HTTP connections were highlighted (Goodin,

2013). Although these ﬂaws have been ﬁxed, iCloud

and iTunes account security clearly not only depends

on the chosen password, but on a wide range of

other factors: Examples are social engineering is-

sues, phishing attacks on passwords, the tight inter-

connection of different accounts, possible security is-

sues within the iCloud service, and the issues asso-

ciated to the fact that the cloud provider has access

to the stored data (Foresman, 2012). Including these

http://www.wired.com/gadgetlab/2012/08/apple-

amazon-mat-honan-hacking/

factors within a detailed risk-analysis and their possi-

ble mitigation is not possible due to the lack of infor-

mation and the wide range of issues that need to be

considered. Therefore, iCloud backups and iCloud

document sharing should not be considered within

security-critical applications.

5 SECURITY

ANALYSIS – WORKFLOW

The presented workﬂow is designed under the as-

sumption that a thorough risk analysis within the con-

text of the deployment scenario has already been con-

ducted, and the critical assets, threats and risk fac-

tors are already known. Also the mobile device plat-

form – in this case iOS – has already been selected.

Subsequently, based on the risk analysis and the ex-

isting policies, the iOS platform needs to be con-

ﬁgured properly and the appropriate applications for

handling the critical data need to be chosen. After

selecting those applications and setting up a demon-

stration environment that already contains data to be

protected

, the proposed workﬂow is applied.

A simple example can be outlined as follows:

Given a scenario, where a certain organisation needs

to handle critical internal email communication on the

mobile device platform: Then, for processing the at-

tached ﬁles within these emails several applications

are required by the users. Examples could be various

document readers, PDF annotators or any other appli-

cation that handles those attachments or the informa-

tion contained in the emails. Based on the selection

of third-party applications or even in-house develop-

ments, the security ofﬁcer needs to analyze the overall

security of the whole setup. The then applied work-

ﬂow is shown in Figure 4, where the ﬁrst step (System

Security Analysis) is applied to the whole system and

the subsequent steps need to be considered for the in-

stalled applications

5.1 System Security Analysis

Although the overall security related conﬁguration of

the device is not covered in this workﬂow, there is

one system security related aspect that needs to be

addressed within the context of the Data Protection

system for credentials. When communication sys-

tems, such as MS Exchange connections, VPN con-

nections etc. are utilized in the deployment scenario,

Meaning, that the applications have been used on the

device and application ﬁles are already present.

The various procedures only need to be applied once to

cover all the installed applications.

iOSEncryptionSystems-DeployingiOSDevicesinSecurity-criticalEnvironments

179

Application

File protection

class analysis

KeyChain

protection

class analysis

Files with class

NsFileProtectionNone

Files with other

classes

Passcode

circumvention via

Jailbreaking/

Rooting

KeyChain entries with

Always/

AlwaysDeviceOnly

Passcode

circumvention via

Jailbreaking/

Rooting

On-device

brute-force attack

No-off device

attacks possible

KeyChain entries

with safe classes

On-device

brute-force attack

File backup

state analysis

Files in backup

No ﬁles in backup

No-off device

attacks possible

KeyChain

backup state

analysis

All credentials with

thisDeviceOnly

classes

Credentials with

transferable classes

iCloud

account

security

Standard

iTunes

backup?

iCloud

backup?

Encrypted

iTunes

backup?

Critical data

at cloud

provider

iCloud

account

security

Standard

iTunes

backup?

iCloud

Backup?

Encrypted

iTunes

backup?

Off-device

brute-force

attack

Critical data

at cloud

provider

ApplicationApplication

System

Security

Analysis

Passcode selection

based on brute-

force times

Passcode selection

based on brute-

force times

Off-device

brute-force

attack

Minor risk

Medium risk

High risk

Analysis/Tool

No access to

credentials

Direct ﬁle

access on

backup

device

Figure 4: Workﬂow for analyzing the security of application ﬁles in the context of the iOS encryption systems.

their respective KeyChain entries (private keys, pass-

words etc.) need to be considered. As described in

detail by (Heider and Khayari, 2012), several of these

entries were marked by Apple via the problematic Al-

ways, AlwaysThisDeviceOnly classes and thus can be

accessed after successfully applying a jailbreak (Sec-

tion 4.3).

5.2 File Protection Class Analysis

In the ﬁrst application-oriented step the protection

classes of all ﬁles are analyzed. This is considered as

the most important step, since the wrong selection of

protection classes (especially None) defeats the pur-

pose of the Data Protection system. Any application

using this class for storing security-critical data must

be rejected. Otherwise the Jailbreaking/Rooting

attack can be applied by an attacker to gain physical

access to the device and retrieve the desired data.

Tool – File Protection Class Analysis. To gather the

ﬁle protection class information we present a simple

Java based Data Protection tool

that analyzes the

unencrypted metadata

of standard and encrypted

iTunes backups. The protection class information

of the ﬁles within these backups can be extracted

from the gained metadata. The main limitation of the

current version is that the protection classes of ﬁles,

which are not contained in the backups, cannot be

analyzed.

Tool – Passcode Selection based on Brute-force

https://github.com/ciso/ios-dataprotection/

By using and extending parts of the source code of

the iPhoneStalker tool: http:// code.google.com/ p/ iphon-

estalker/

Times. If the application ﬁles use the appropriate

protection classes, then the passcode is highly rele-

vant for the security of the system. The length and the

complexity of this passcode can be chosen according

to the time necessary to carry out a brute-force attack.

Due to the presence of the secure element and the

high iteration count of the PBKDF2 key derivation

function, the time to derive the key from a given

password is known. Given the length of the password

and the allowed characters, which can both be

conﬁgured via various MDM policies, the worst-case

time for a brute-force attack on the password can be

calculated

. Based on these times, the risk analysis

and the deployed security policy the appropriate

password length and complexity can be selected and

modelled via the respective MDM policies.

5.3 Keychain Protection Class Analysis

The extraction of the application-speciﬁc KeyChain

entry protection classes has a similar relevance as

for the ﬁle Data Protection classes. Within the Key-

Chain context the protection classes Always and Al-

waysThisDeviceOnly need to be considered as dan-

gerous due to the jailbreaking scenario. Apart from

the classes of the third-party application credentials,

one needs to consider the pre-deﬁned classes of sys-

tem applications (Section 5.1). Furthermore, the im-

plications for iCloud and iTunes backups need to be

considered for the transferable classes and device-

only classes (ThisDeviceOnly). This will be discussed

in the backup-related sections of this workﬂow.

A simple online spreadsheet is available at http://

goo.gl/pGijv

SECRYPT2013-InternationalConferenceonSecurityandCryptography

180

Tool – KeyChain Protection Class Analysis. Similar

to the ﬁle protection classes, the protection classes

of the KeyChain entries can also be extracted from

the backups. This functionality is provided by the

iphone-dataprotection backup script

. Since only

the non-ThisDeviceOnly classes are transferred to the

backup, the other KeyChain entries store on the iOS

device cannot be analyzed with this tool.

Tool – Passcode Selection based on Brute-force

Times. The same conclusions for the brute-force

times in case of successful jailbreaking/rooting

attacks can be drawn as for the ﬁle protection classes.

5.4 File Backup State Analysis

In the next step, the backup ﬂags of the application

ﬁles are evaluated. By knowing which application

ﬁles are included in possible iTunes and iCloud

backups, conclusions about the required iTunes

device security or iCloud usage can be drawn. The

information on the ﬁles within the backup is extracted

via the aforementioned Data Protection tool.

Implications for Unencrypted iTunes Backups. An

attacker who gains access to the iTunes device that

stores the backup, can directly access all ﬁles that are

included in the backup (Direct ﬁle access on backup

device). When critical ﬁles are marked via the

backup ﬂags the unencrypted iTunes backup should

be avoided, especially when the backup device might

be exposed to non-secure environments.

Implications for Encrypted iTunes Backups. An

attacker who gains access to the iTunes device that

stores the backup cannot access the ﬁles directly due

to their encrypted nature. However, an attacker can

still mount a brute-force attack on the iTunes en-

cryption password (Off-device brute-force attack).

Since the involved key derivation function is not

bound to a device, the attacker can use arbitrary exter-

nal resources to speed up this process. Thus, a strong

password needs to be selected to adequately protect

the backup data. Although, encrypted backups can be

enforced via MDM policies, it is not possible for the

MDM administrator to deﬁne password properties,

such as length, complexity etc. As soon as the iOS

device is allowed to backup data via iTunes it is the

http://code.google.com/p/iphone-

dataprotection/source/browse/python scripts/backup tool.py.

Usage: http://stackoverﬂow.com/questions/1498342/how-

to-decrypt-an-encrypted-apple-itunes-iphone-backup

user’s responsibility to set an adequate password.

Implications for iCloud Backups. The ﬁles marked

with the backup ﬂags are also stored on iCloud back-

ups, when this functionality is enabled by the MDM

administrator. Due to a wide range of possible secu-

rity issues and the fact that the MDM administrator

cannot deﬁne security properties for the iCloud ac-

count password, it is highly recommended to deacti-

vate iCloud backups in security-critical environments

(iCloud account security, Critical data at cloud

provider).

5.5 KeyChain Backup State Analysis

In contrast to the speciﬁc backup ﬂags required

for ﬁle backups, the credentials protection classes

themselves indicate whether they can be transferred

to a different device via an iCloud or iTunes backup.

All KeyChain entry protection classes that do not

contain the ThisDeviceOnly identiﬁer, are included

in backups. The protection classes of the KeyChain

entries marked for backup can be extracted with the

aforementioned iphone-dataprotection backup script.

Implications for Standard iTunes Backups.

Credentials that are stored within standard iTunes

backups are protected by an iOS device-bound

key and thus cannot be decrypted without physical

access to this device. This implies that none of these

credentials can be transferred to other devices when

restoring a standard iTunes backup. Interestingly,

this also means that credentials in such a backup are

better protected than those stored in an encrypted

iTunes backup (No access to credentials).

Implications for Encrypted iTunes Backups.

Within an encrypted iTunes backup the non-

ThisDeviceOnly KeyChain entries are stored and

encrypted via the backup password chosen by the

user. Similar to the stored ﬁles these KeyChain entries

are susceptible to off-device brute-force attack.

Implications for iCloud Backups. The same con-

clusions as for the ﬁles can be drawn. All creden-

tials that are marked with the transferable protection

classes, are included in the iCloud backup and thus

can be accessed when the iCloud account password

is known (iCloud account security, Critical data at

cloud provider).

iOSEncryptionSystems-DeployingiOSDevicesinSecurity-criticalEnvironments

181

6 CONCLUSIONS AND FUTURE

WORK

The existing heterogeneity in mobile device platforms

and the associated security features present a chal-

lenge for administrators or security ofﬁcers that need

to deploy such devices in a security-critical context.

Thereby, the encryption systems of a mobile device

platform play a vital role in the protection of critical

data, when an attacker gains physical access to the

device. However, even under the assumption that the

encryption systems are implemented correctly, their

complexity within the high-level application creates

many pitfalls that need to be considered by develop-

ers and administrators as well. In this paper, we have

analyzed the highly sophisticated and complex iOS

encryption systems from a security ofﬁcer’s perspec-

tive. As a result of this analysis a workﬂow is pre-

sented that analyzes the different aspects of the iOS

encryption systems. To support this workﬂow vari-

ous tools are presented that help the security ofﬁcer to

gain critical information which is not available within

the standard iOS conﬁguration tools. As future work,

we intend to conduct the same analysis for the other

major mobile device platforms Android, Blackberry

and Windows Phone/RT. Furthermore, we intend to

combine the various tools into an application that can

easily be utilized and does not require root access to

the iOS devices.

REFERENCES

Apple (2012). iOS Security. Technical Report May, Apple

Inc.

Bedrune, J.-B. and Sigwald, J. (2011). iPhone data protec-

tion in depth. Technical report, Sogeti / ESEC.

Belenko, A. and Sklyarov, D. (2011). Evolution of iOS Data

Protection and iPhone Forensics : from iPhone OS to

iOS 5.

Chen, Y. C. Y. and Ku, W.-S. K. W.-S. (2009). Self-

Encryption Scheme for Data Security in Mobile De-

vices.

Foresman, C. (2012). Apple holds the master decryption

key when it comes to iCloud security, privacy,

http://arstechnica.com/apple/2012/04/apple-holds-

the-master-key-when-it-comes-to-icloud-security-

privacy/.

Goodin, D. (2013). After leaving users exposed, Ap-

ple fully HTTPS-protects iOS App Store, http://

arstechnica.com/security/2013/03/after-leaving-

users-exposed-apple-ﬁnally-https-protects-ios-app-

store/.

Heider, J. and Khayari, R. E. (2012). iOS Keychain Weak-

ness FAQ - Further Information on iOS Password Pro-

tection.

Hoog, A. and Strzempka, K. (2011). iPhone and iOS Foren-

sics: Investigation, Analysis and Mobile Security for

Apple iPhone, iPad and iOS Devices. Syngress.

Infosec Institute (2012a). Forensic analysis of iPhone back-

ups, http://www.exploit-db.com/wp-content/themes/

exploit/docs/19767.pdf. Technical report.

Infosec Institute (2012b). iPhone Forensics Analysis of

iOS 5 backups, http://resources.infosecinstitute.com/

ios-5-backups-part-1/. Technical report, Infosec Insti-

tute.

Kaliski, B. (2000). PKCS #5: Password-Based Cryptogra-

phy Speciﬁcation Version 2.0.

Pandya, V. R. (2008). IPHONE SECURITY ANALYSIS.

Journal of Information Security, 1(May):74–87.

Paul, M., Chauhan, N. S., and Saxena, A. (2011). A se-

curity analysis of smartphone data ﬂow and feasible

solutions for lawful interception.

Shurui, L. S. L., Jie, L. J. L., Ru, Z. R. Z., and Cong, W.

C. W. (2010). A Modiﬁed AES Algorithm for the Plat-

form of Smartphone.

Zovi, D. A. D. (2011). Apple iOS 4 Security Evaluation.

SECRYPT2013-InternationalConferenceonSecurityandCryptography

182