Mobile Device Encryption Systems

IAIK

Mobile Device Encryption Systems

SEC 2013Bernd Zwattendorfer, Peter Teufl

IAIK

TOCSmartphone Encryption

Encryption Scope

iOS Encryption Systems:

Device encryption (file-system)

Data Protection (files, credentials)

Backup (iTunes plain, iTunes encrypted, iCloud)

Android Encryption Systems

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!

IAIK

Encryption support: iOS, Blackberry OS, Android (>= 3.x), Windows Phone

Well fine, every platform supports it... Done?

IAIK

There is More Than MarketingPurpose: 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???

IAIK

iOS - EncryptionTwo 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

IAIK

iOS - Encryption

Secure ElementAES 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 encryptionNot dependent on

PIN/Passcode

Data ProtectionPer-file, dependent on PIN/Passcode and

Secure Element key

Key Derivation

Developer's Choice!!!

file-system encryption

Data Protection system

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

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 (!)

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

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...

IAIK

iOS - Data Protection - KeychainKeychain: 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

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?

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 numericalPasscode 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.05 10 100000 133.3 2.2 0.1 0.06 10 1000000 1,333.3 22.2 0.9 0.07 10 10000000 13,333.3 222.2 9.3 0.08 10 100000000 133,333.3 2,222.2 92.6 0.39 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.210 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.88 36 2.82111E+12 3,761,479,876.6 62,691,331.3 2,612,138.8 7,156.59 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.310 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.68 62 2.1834E+14 291,120,140,779.9 4,852,002,346.3 202,166,764.4 553,881.59 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.6symbols 6 107 1.5007E+12 2,000,973,802.5 33,349,563.4 1,389,565.1 3,807.010 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.19 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

IAIK

iOS - BackupsITunes

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

IAIK

iTunes - Plain Backups

Files stored in plain

Credentials are alsostored 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

IAIK

iTunes - Encrypted BackupsKey is derived from a passwordselected by the user (no MDMinfluence)

Files and credentialsin Backup are protectedvia 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 KeyKDF

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.)

IAIK

iOSBackups

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!

IAIK

iOS - SummaryGood 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)

IAIK

iOS - Workflow

Application

File protectionclass analysis

KeyChain protection

class analysis

Files with classNsFileProtectionNone

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 backupNo-off device

attacks possible

KeyChain backup state

analysis

All credentials with thisDeviceOnly

classesCredentials with

transferable classes

iCloud account security

Standard iTunes

backup?iCloud

backup?Encrypted

iTunes backup?

Critical data at cloud provider

iCloudaccount 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

IAIK

iOS Encryption - Sourceshttp://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

IAIK

AndroidTwo 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

IAIK

Android - Device EncryptionAndroid 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!)

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)

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 systemencryption

KeyDerivation

Differences to iOS file-system encryption:PIN/passcode during boot processBut no hardware chip is involved

IAIK

Android - Brute Force AttacksFor 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

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 numericalPasscode 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.05 10 100000 25.6 0.4 0.0 0.06 10 1000000 256.3 4.3 0.2 0.07 10 10000000 2,563.3 42.7 1.8 0.08 10 100000000 25,633.3 427.2 17.8 0.09 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.010 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.28 36 2.82111E+12 723,144,506.3 12,052,408.4 502,183.7 1,375.89 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.410 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.58 62 2.1834E+14 55,967,847,064.9 932,797,451.1 38,866,560.5 106,483.79 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.8symbols 6 107 1.5007E+12 384,687,213.5 6,411,453.6 267,143.9 731.910 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.69 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

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

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

IAIK

AndroidProblems:

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 IOS)

IAIK

iOSstandard

iOSdata 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 ?

Issuesjailbreak dangeronly for remote

wipe

developer decides!user does not know state

manual activation

keys remain in RAM

no classes

? ?

Encryption Overview

IAIK

iOS - Data Protection - FilesKey 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

IAIK

IOS - Data Protection

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?)

IAIK

IOS - PINSPIN 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