3 lecture embedded system security a.-r. sadeghi, @tu ... · -r. sadeghi, @tu darmstadt, 2011-2012...

Application Layer

System Apps Third party Apps

Browser SMS Facebook Skype

Cocoa Touch Layer

Media Layer

Core Services Layer

Core OS Layer (iOS kernel)

Objective-C User Interface Frameworks

Graphics Audio Video

Drivers File

System TrustedBSD MAC

Framework

Objective-C Runtime

Objective-C Private Frameworks

Objective-C Public Frameworks

SMS Phone Calender …

Contacts Location … Images

3rd party

Sandboxing Profiles (pre-defined by Apple)

Safari Network

Lecture Embedded System Security A.-R. Sadeghi, @TU Darmstadt, 2011-2012 Overview on iOS 2

4

Source: http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf

Device Key (Device UID) Group Key (Group GID) Apple Root Certificate

Encrypted File System

Crypto Engine

Kernel

OS Partition

User Partition

App Sandbox

Data Protection Class

Software

Hardware and Firmware

Lecture Embedded System Security A.-R. Sadeghi, @TU Darmstadt, 2011-2012 Overview on iOS

http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf



iOS enforces Secure Boot Each component that is part of the boot-process is signed by

Apple (to ensure integrity) If one component of the boot process cannot be correctly

loaded or verified, boot-up is stopped In case boot-up is stopped, iOS will either try to connect to

iTunes or return into DFU (Device Firmware Upgrade) mode

Boot Chain Sequenze 1. Boot ROM

Immutable code (stored in read-only memory during chip fabrication) Contains Apple Root CA public key, which is used during the boot

process to verify each involved component

2. Low-Level Bootloader 3. Next-Stage Bootloader (iBoot) 4. iOS Kernel

5 Lecture Embedded System Security A.-R. Sadeghi, @TU Darmstadt, 2011-2012 Overview on iOS

Each iOS device has a dedicated AES-256 crypto engine Crypto Engine is provided as a Hardware Module (due to

performance and power efficiency reasons) Along with the AES engine, Apple also provides a

SHA-1 hardware module

Manufacture Keys Apple provides the Device ID (UID) and the device group ID

(GID) as AES 256 Bit keys While the UID is unique to each device, the GID represents a

processor class (e.g., Apple A5 processor) The UID and GID keys are directly burned into the silicon and

can only be accessed by the Crypto Engine

Other Cryptographic Keys All other keys are generated by the system‘s random number

generator (RNG)


The iOS file system is encrypted by default The encryption key for the file system is referred to as File System

Key This key is created when iOS is first installed and is protected by the

Device UID

Effectiveness If the device gets stolen, a remote wipe command can be set up

which simply wipes the File System Key rendering the entire file system unreadable

However, an adversary can use the device itself to decrypt the file system before the remote wipe command is delivered


Encrypted File System

File System Key Device UID

Every file is encrypted with a unique File Key, that is generated when the file created

The file key is wrapped with a Class Key (because each file is associated to a specific protection class) and stored in the file‘s metadata

The metadata is encrypted with the File System Key The Class key is protected by the Device UID and (if

configured for some files) the User Passcode

8

File Contents

File Metadata

File Key Class Key

File System Key

Device UID

User Passcode

Lecture Embedded System Security A.-R. Sadeghi, @TU Darmstadt, 2011-2012 Overview on iOS

User-Defined Passcode Prevents unauthorized access to the device‘s UI By default, the passcode is defined as a 4-digit PIN

However, more complex passcodes can be configured

Influence on File Data Encryption If a passcode is set, several files are also encrypted by using the passcode Whether a passcode is involved in the encryption process depends on the

class of the file iOS provides 4 basic protection classes: Complete Protection, Protected Unless Open,

Protected Until First User Authentication, No Protection More Details on Protection Classes can be found at


Effectiveness The standard 4-digit passcode is vulnerable to brute-force attacks

(6 minutes) see Fraunhofer Study: sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords-

faq.pdf



http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords-faq.pdf







The iOS Keychain provides a secure way to store keys and passwords

It also provides an API that allows apps to retrieve and store keys/passwords


iOS will refuse to execute unsigned code Specifically, all executable code (System Apps and Third-Party

Apps) has to be signed using an Apple-issued certificate

In addition, Apple enforces Mandatory Code Signing Third-Party Apps are not allowed to load unsigned code

resources at runtime or using self-modifying code

Code Signing Enforcement (CSE) At runtime, iOS enforces code signature checks on executable

memory pages to ensure that an app has not been modified while it is executing

Exception: Safari and Webapps Since CSE would restrict any code generation, iOS added an execption to

web applications so that they can use just-in-time (JIT) code generation


All iOS apps share one user ID (”mobile“) Recall: In contrast, each Android App has a unique user ID

App Sandboxing by TrustedBSD MAC kernel allows the definition of sandboxing profiles, while profiles can

be attached at process-level

sandboxing profiles contain access control rules based on system call and file-system level

Rule Examples:

file-read ^/private/var/mobile/Media/Photos/Thumbs$ ALLOW

Action Resource (Filepath) Decision

file-read ^/private/var/logs(/|$) DENY


Apple provides pre-defined sandboxing profiles

iOS includes 35 pre-defined sandboxing profiles [Zovi, Blackhat 2011]

Specific sandboxing profiles for system (built-in) apps

MobileSafari

MobileSMS

MobileMail

…

One 3rd-party app profile, called Container

access control to app directories

generic profile applied to all 3rd-party apps!


Each 3rd party app can freely access the entire address book

Location information

Device information (e.g., IMSI, phone number)

E-Mail account configurations

WiFi configurations

Recent browser searches

Keyboard cache

Personal photos


Around 700 to 800 apps are submitted each day to the (iOS) App Store

News underline that Apple does not enforce a security analysis

Moreover, runtime attacks may exploit the sandboxing profile of bengin apps to steal private data


Goal PiOS aims to detect privacy leaks in iOS apps

Description Extracts the unencrpyted iOS application by using process dumping

(i.e., create memory snapshots with a debugger) Derives control-flow graph (CFG) of the application (complicated due

to Objective-C language characteristics) Applies data flow analysis on CFG to detect if an app leaks private

data

Result Evaluation of around 1400 iOS apps revealed that many apps leak the

device ID

Shortcomings of PiOS PiOS is a static tool → apps may leverage obfuscation techniques PiOS cannot deal with runtime attacks → stealing private data by

exploiting a benign or malicious app


Apple Inc. iOS Security. May 2012 http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf

Dino A. Dai Zovi, Apple iOS 4 Security Evaluation, Blackhat USA 2011

Manuel Egele, Christopher Kruegel, Engin Kirda, and Giovanni Vigna. PiOS: Detecting Privacy Leaks in iOS Applications. NDSS 2011





3 lecture embedded system security a.-r. sadeghi, @tu ... · -r. sadeghi, @tu darmstadt, 2011-2012...

Documents