The document discusses encryption systems on iOS mobile devices. It describes two main iOS encryption systems: 1) device encryption that encrypts the file system with a key stored on a hardware chip, independent of passcode; and 2) data protection that encrypts individual files and credentials with keys derived from passcode and hardware key. It notes issues like developer control over file protection classes, interactions between backup and encryption systems, and risks of brute force attacks on passcodes.

1. IAIK
Mobile Device
Encryption Systems
SEC 2013
Bernd Zwattendorfer, Peter Teufl

2. IAIK
TOC
Smartphone Encryption
Encryption Scope
iOS Encryption Systems:
Device encryption (file-system)
Data Protection (files, credentials)
Backup (iTunes plain, iTunes encrypted, iCloud)
Android Encryption Systems

3. IAIK
Encryption on Smartphones
Why do we need it?
Data protection (application files and credentials)
Remote Wiping: without encryption not feasible (takes too much time)
Where to place the encryption system?
Operating system: iOS, Windows Phone, QNX, Android
Smartphone applications: container applications, BYOD!

4. IAIK
Encryption support: iOS, Blackberry OS, Android (>= 3.x), Windows Phone
Well fine, every platform supports it... Done?

5. IAIK
There is More Than Marketing
Purpose: What’s the purpose of the encryption system?
Encryption scope: Which data is encrypted, and how many keys are used?
Key details: Where is the key, and how is it derived?
Locked state: How does the encryption system behave when the phone is locked?
How does the system handle incoming data?
Implementation: Hardware? Software?
Attacks: How can the system be attacked? Where are the weak points?
MDM: Mobile Device Management: enforce encryption, manage its PINs
Security: Complex systems, many mistakes can be made, key escrow???

6. IAIK
iOS - Encryption
Two encryption systems:
Device encryption (file-system):
Introduced with IOS 3 and the iPhone 3GS, based on a chip
Data protection (individual files and credentials):
Introduced with IOS 4, is an addition to the first one, improved in IOS 5
(new classes, better keychain protection)
Backup:
iTunes, iCloud: Encrypting backups and its consequences

7. IAIK
iOS - Encryption
Secure
Element
AES Key
Filesystem
Key
File system
Operating
system
Application
1
File 1
JailBreak
Remote Wipe
PIN/Passcode
File 2
Application
2
Application
3
File 3
File 4 File 5
Data
protection
class keys
File system encryption
Not dependent on
PIN/Passcode
Data Protection
Per-file, dependent on PIN/Passcode and
Secure Element key
Key Derivation
Developer's Choice!!!
file-system encryption
Data Protection system

8. IAIK
iOS - Device Encryption
First system: file-system encryption
File-system encryption keys protected via key that is stored on hardware
chip
PIN/Passcode is NOT used for key derivation
When the phone is stolen: apply jailbreak to circumvent PIN protection,
the system decrypts the data for you
Thus: Only makes sense for fast remote wiping

9. IAIK
iOS - Data Protection - Files
Second system: Data Protection
In addition to device encryption
Protecting specific application files
(e.g. emails, the PDF files within a PDF reader application etc.)
Unique file keys, stored encrypted in the extended attributes of the file
Different protection classes defined by the developer (!)

10. IAIK
iOS - Data Protection - Files
Protection classes:
NSProtectionNone: File encryption keys protected with “Device Encryption
keys”, thus no real protection
For all the others: File encryption keys are encrypted with a key that is
derived from the UID key and from the PIN/passcode: Thus, without the PIN,
jailbreaking etc. does not reveal the encrypted data
NSProtection: Complete, UntilFirstUserAuthentication, UnlessOpen

11. IAIK
iOS - Data Protection - Files
Problem:
Protection Class choice is handled by the developer.
The user/admin does not know which apps encrypt their data
Consider:
Getting an email with a PDF (email app uses data protection), and
opening the email in an PDF reader that does not encrypt the data...

12. IAIK
iOS - Data Protection - Keychain
Keychain: used to store credentials (passwords, private keys, certificates etc.)
Protection Classes:
Always (!) (similar to NONE for files)
AfterFirstUnlock (UntilFirstUserAuthentication)
WhenUnlocked (Complete)
also in a “ThisDeviceOnly” version (not included in backups)
IOS 4: only the secret was protected, not the usernames etc.
since IOS 5: every aspect is encrypted

13. IAIK
iOS - Data Protection - Brute Force
PIN plays a vital role for Data Protection
Keys are derived from hardware chip and PIN code
Properties:
PIN length
Brute force attacks: Rely on the availability of a jailbreak
Estimated time for brute-force attacks?

14. IAIK
iOS - Data Protection - Brute ForceTime to derive the key from the
password (ms) 80 1
Lock-Screen Type Time to try out 100% of the possible passcodesTime to try out 100% of the possible passcodesTime to try out 100% of the possible passcodesTime to try out 100% of the possible passcodes
Standard numerical
Passcode
length
Number of
symbols
Number of
passcodes Minutes Hours Days Years
4 10 10000 13.3 0.2 0.0 0.0
Extended numerical 4 10 10000 13.3 0.2 0.0 0.0
5 10 100000 133.3 2.2 0.1 0.0
6 10 1000000 1,333.3 22.2 0.9 0.0
7 10 10000000 13,333.3 222.2 9.3 0.0
8 10 100000000 133,333.3 2,222.2 92.6 0.3
9 10 1000000000 1,333,333.3 22,222.2 925.9 2.5
10 10 1E+10 13,333,333.3 222,222.2 9,259.3 25.4
Alphanumerical 4 36 1679616 2,239.5 37.3 1.6 0.0
lowercase letters and numbers 5 36 60466176 80,621.6 1,343.7 56.0 0.2
10 numbers and 26 letters 6 36 2176782336 2,902,376.4 48,372.9 2,015.5 5.5
7 36 7.8364E+10 104,485,552.1 1,741,425.9 72,559.4 198.8
8 36 2.82111E+12 3,761,479,876.6 62,691,331.3 2,612,138.8 7,156.5
9 36 1.0156E+14 135,413,275,557.9 2,256,887,926.0 94,036,996.9 257,635.6
10 36 3.6562E+15 4,874,877,920,084.0 81,247,965,334.7 3,385,331,888.9 9,274,881.9
Alphanumerical 4 62 14776336 19,701.8 328.4 13.7 0.0
lower/uppercase letters and numbers 5 62 916132832 1,221,510.4 20,358.5 848.3 2.3
10 numbers and 52 letters 6 62 5.6800E+10 75,733,647.4 1,262,227.5 52,592.8 144.1
7 62 3.5216E+12 4,695,486,141.6 78,258,102.4 3,260,754.3 8,933.6
8 62 2.1834E+14 291,120,140,779.9 4,852,002,346.3 202,166,764.4 553,881.5
9 62 1.3537E+16 18,049,448,728,351.4 300,824,145,472.5 12,534,339,394.7 34,340,655.9
10 62 8.3930E+17 1,119,065,821,157,790.0 18,651,097,019,296.4 777,129,042,470.7 2,129,120,664.3
Complex 4 107 131079601 174,772.8 2,912.9 121.4 0.3
lower/uppercase letters and numbers 5 107 1.4026E+10 18,700,689.7 311,678.2 12,986.6 35.6
symbols 6 107 1.5007E+12 2,000,973,802.5 33,349,563.4 1,389,565.1 3,807.0
10 numbers, 52 letters and 45 symbols 7 107 1.6058E+14 214,104,196,863.8 3,568,403,281.1 148,683,470.0 407,352.0
8 107 1.7182E+16 22,909,149,064,425.6 381,819,151,073.8 15,909,131,294.7 43,586,661.1
9 107 1.8385E+18 2,451,278,949,893,540.0 40,854,649,164,892.3 1,702,277,048,537.2 4,663,772,735.7
10 107 1.9672E+20 262,286,847,638,609,000.0 4,371,447,460,643,480.0182,143,644,193,478.0499,023,682,721.9

15. IAIK
iOS - Backups
ITunes
encrypted backups, plain backups
iCloud
somehow encrypted...
How to mark a file for Backup?
Developer’s choice
Default is “yes”
Marked files are transferred to iTunes, iCloud backups when activated

16. IAIK
iTunes - Plain Backups
Files stored in plain
Credentials are also
stored encrypted!
Encryption key is stored on the iOS device
Thus: Credentials in plain backups cannot be restored on other devices
As a result: credentials are better protected in unencrypted iTunes backups
than in encrypted ones!
Files
Credentials
Encryption Key
Plain iTunes BackupiOS Device
Files
Credentials
marked for backup

17. IAIK
iTunes - Encrypted Backups
Key is derived from a password
selected by the user (no MDM
influence)
Files and credentials
in Backup are protected
via the derived key
Credentials can be restored on other iOS device (with the right protection class)
Problem:
Brute-force attack on weak passwords, when backup is stolen
Protection for keys is acutally weaker than in plain iTunes Backups (!!!)
Files
Credentials
Plain iTunes BackupiOS Device
Files
Credentials
marked for backup
Backup
Encryption Key
User
Password
Derived
Encryption Key
KDF

18. IAIK
iCloud - Backups
iCloud backups and iCloud sync
Protection via passcode selected by the user (no MDM influence, except for
deactivating iCloud backups and sync)
If attacker gains access to this account, the backup can be restored
Details about the iCloud encryption process are not known
Data on iCloud: similar to security considerations required as for other cloud
providers (DropBox etc.)

19. IAIK
iOS
Backups
Tool:
https://github.com/ciso/ios-dataprotection/
Analyzes the iTunes backup (encrypted and plain) and lists all the contained files and...
...the protection classes of the application files
Allows to decide whether the right protection class was chosen by a developer!

20. IAIK
iOS - Summary
Good protection by iOS encryption systems
However:
interactions of the systems is manifold
implications for deployments in security-criticial deployment scenarios: In-
depth knowledge of the involved systems is required!
Developer influence!
Outlook: Paper at SECRYPT 2013 (Workflow for Deploying iOS devices)

21. IAIK
iOS - Workflow
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 backupNo files 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 file
access on
backup
device

22. IAIK
iOS Encryption - Sources
http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords-faq.pdf
http://esec-lab.sogeti.com/post/iOS-5-data-protection-updates
http://esec-lab.sogeti.com/dotclear/public/publications/11-
hitbamsterdam-iphonedataprotection.pdf
https://media.blackhat.com/bh-us-11/DaiZovi/
BH_US_11_DaiZovi_iOS_Security_WP.pdf
http://trailofbits.files.wordpress.com/2011/08/ios-security-
evaluation.pdf
http://www.elcomsoft.com/eift.html

23. IAIK
Android
Two systems:
DM-Crypt based file-system encryption system
On SD card: depends on version, platform
Android KeyChain - for storing credentials:
Same PIN/Passcode and key derivation function as for the file-
system
Stores as file in the file-system

24. IAIK
Android - Device Encryption
Android versions:
Tablets: Since Android 3.x
Smartphones: Since Android ICS (4.x)
Even if 4.x, not supported on every platform
Not activated by default
Uses dm-crypt (Linux) as an encryption layer
when data is written/read to the storage device
No hardware module used (brute-force attacks!)

25. IAIK
Android - Device Encryption
PIN entry before system boot-up, key derivation based on PIN and
salt stored in the dm-crypt meta-data
When device is booted, system can access every file (no protection
classes...)
Pattern/Face lock systems deactivated...
Passcode for file-encryption is same as used for locking the phone
(shoulder surfing)

26. IAIK
Android - Device Encryption
Filesystem
Key
File system
Operating
system
Application
1
File 1
Remote Wipe
PIN/Passcode
File 2
Application
2
Application
3
File 3
File 4 File 5
File system
encryption
Key
Derivation
Differences to iOS file-system encryption:
PIN/passcode during boot process
But no hardware chip is involved

27. IAIK
Android - Brute Force Attacks
For KeyChain and Device-Encryption System
Basic steps:
Extract file-system meta-information from encrypted device
Run Brute-force tool
No hardware chip involved: speed-up by using multiple instances (e.g., in
the cloud)
https://santoku-linux.com/howto/mobile-forensics/how-to-brute-force-
android-encryption

28. IAIK
Android - Brute Force Times (1 ECU)
Time to derive the key from the
password (ms) 15.38 1
Lock-Screen Type Time to try out 100% of the possible passcodesTime to try out 100% of the possible passcodesTime to try out 100% of the possible passcodesTime to try out 100% of the possible passcodes
Standard numerical
Passcode
length
Number of
symbols
Number of
passcodes Minutes Hours Days Years
4 10 10000 2.6 0.0 0.0 0.0
Extended numerical 4 10 10000 2.6 0.0 0.0 0.0
5 10 100000 25.6 0.4 0.0 0.0
6 10 1000000 256.3 4.3 0.2 0.0
7 10 10000000 2,563.3 42.7 1.8 0.0
8 10 100000000 25,633.3 427.2 17.8 0.0
9 10 1000000000 256,333.3 4,272.2 178.0 0.5
10 10 1E+10 2,563,333.3 42,722.2 1,780.1 4.9
Alphanumerical 4 36 1679616 430.5 7.2 0.3 0.0
lowercase letters and numbers 5 36 60466176 15,499.5 258.3 10.8 0.0
10 numbers and 26 letters 6 36 2176782336 557,981.9 9,299.7 387.5 1.1
7 36 7.8364E+10 20,087,347.4 334,789.1 13,949.5 38.2
8 36 2.82111E+12 723,144,506.3 12,052,408.4 502,183.7 1,375.8
9 36 1.0156E+14 26,033,202,226.0 433,886,703.8 18,078,612.7 49,530.4
10 36 3.6562E+15 937,195,280,136.1 15,619,921,335.6 650,830,055.7 1,783,096.0
Alphanumerical 4 62 14776336 3,787.7 63.1 2.6 0.0
lower/uppercase letters and numbers 5 62 916132832 234,835.4 3,913.9 163.1 0.4
10 numbers and 52 letters 6 62 5.6800E+10 14,559,793.7 242,663.2 10,111.0 27.7
7 62 3.5216E+12 902,707,210.7 15,045,120.2 626,880.0 1,717.5
8 62 2.1834E+14 55,967,847,064.9 932,797,451.1 38,866,560.5 106,483.7
9 62 1.3537E+16 3,470,006,518,025.6 57,833,441,967.1 2,409,726,748.6 6,601,991.1
10 62 8.3930E+17 215,140,404,117,585.0 3,585,673,401,959.7 149,403,058,415.0 409,323,447.7
Complex 4 107 131079601 33,600.1 560.0 23.3 0.1
lower/uppercase letters and numbers 5 107 1.4026E+10 3,595,207.6 59,920.1 2,496.7 6.8
symbols 6 107 1.5007E+12 384,687,213.5 6,411,453.6 267,143.9 731.9
10 numbers, 52 letters and 45 symbols 7 107 1.6058E+14 41,161,531,847.1 686,025,530.8 28,584,397.1 78,313.4
8 107 1.7182E+16 4,404,283,907,635.8 73,404,731,793.9 3,058,530,491.4 8,379,535.6
9 107 1.8385E+18 471,258,378,117,033.0 7,854,306,301,950.6 327,262,762,581.3 896,610,308.4
10 107 1.9672E+20 50,424,646,458,522,500.0 840,410,774,308,709.0 35,017,115,596,196.2 95,937,303,003.3

29. IAIK
Backup, SD-Card
Backup:
Depends on Android version, proprietery platform extentions
Mobile Device Management: Fragmentation: Google, Samsung etc.
SD card:
not supported on every device
encryption also depends on the platform

30. IAIK
Summary
Heteregeneous Mobile Device Encryption Systems
Different systems, scope etc. require many security related considerations
Worflows for Security Officers
iOS worflow published
Now we are working on all the details of the Android system

31. IAIK
Android
Problems:
external brute force: extract salt, something that is encrypted, use a
cluster...
no protection classes, nor file based encryption, data is accessible
even when device is locked (malicious apps in background???)
Android is so nice to tell us the complexity of the PIN (no permission
required)
Advantage (in comparison to IOS):
The device level encryption key is based on the PIN, does the PIN is
needed to access the data (compare with device-level protection on

32. IAIK
iOS
standard
iOS
data protection
Android
> 3.x
Blackberry Windows Phone
Purpose? remote wipe data, credentials prot. data, cred. pr. data cred. pr. ?
Scope? filesystem files filesystem ? WP7: files WP8: file-system
Key storage? SE, RAM SE, RAM disk, RAM disk, RAM (?) ? (no)
Encrytion keys
available during lock?
yes no yes no ?
Key derivation? SE SE, PIN PIN PIN (?) ?
Brute-Force? - on device off device off device ?
Activated by? always developer/user (PIN) user (settings) policies, user developer ?
User/admin? - no yes yes ?
Issues
jailbreak danger
only for remote
wipe
developer decides!
user does not know state
manual
activation
keys remain in
RAM
no classes
? ?
Encryption Overview

33. IAIK
iOS - Data Protection - Files
Key handling when locked/unlocked
NSProtectionComplete: Keys are removed from memory when device is
locked, thus the files are not available in the locked state
NSFileProtectionCompleteUntilFirstUserAuthentication: files are available
after first unlock
NSFileProtectionCompleteUnlessOpen: symmetric keys are not available
when the device is locked. How to encrypt incoming data? e.g. emails? by
using asymmetric encryption (in this case: based on elliptic curves),
private key is not available when locked

34. IAIK
IOS - Data Protection

35. IAIK
IOS - PINS
Key derivation includes many iteration and requires the HSM key
Further: brute forcing must be done on the device!!! The HSM key is only on
the chip on the device...
A real HSM: why doesn’t the chip implement some kind of exponential back-
off, or even wipe the key when using the wrong PIN to often?
After talking to some hardware experts at the IAIK: an HSM is quite complex,
e.g. implementing the counter is quite difficult (where to store that?)

36. IAIK
IOS - PINS
PIN length: typically: numerical PINs with length 4: 10000 possible
PINs... not much
Brute force:
not possible via GUI: option to wipe the device after several wrong
entries
however who is attacking this via the GUI :-) ?
Jail breaking: access to API, brute forcing the PINs
BUT: key derivation based on PIN and the key in the HSM