Faux Disk Encryption ▪ Drew Suarez & Daniel Mayer ▪ Ekoparty 2015

## Overview

This talk addresses how mobile devices store sensitive data locally as apps increasingly download and cache data on phones, creating significant security challenges. Unlike traditional server-based storage with centralized access controls, mobile device data is vulnerable to theft or loss. The speakers explore the tension between security and usability: strong encryption is necessary, but requiring frequent authentication creates user friction.

## iOS Security Implementation

Daniel Mayer explains Apple's approach, which leverages control of both hardware and software. iOS features a completely signed boot chain verified in hardware, preventing code injection during startup. The Secure Enclave, a hardware root of trust, holds encryption keys and enforces hardware-level protections like preventing brute-force attacks. All files are encrypted with unique file keys, further encrypted by a filesystem key tied to the hardware key. iOS provides multiple file protection classes (NSFileProtection): None (hardware-only), Complete Until First User Authentication (locked until first unlock, then key persists in memory), and Complete (key deleted on lock, requiring re-entry of passcode). The iOS Keychain similarly offers encryption with varied protection levels. Touch ID serves primarily as a usability enhancement, requiring a passcode for setup and delegating authentication to the Secure Enclave. Jailbreaks disable code signing checks and allow unsigned code execution, but cannot bypass hardware-level keychain encryption.

## Android Encryption and Fragmentation Challenges

Drew Suarez details Android's more complex landscape. Android uses dm-crypt with AES-128 CBC, deriving encryption keys from passcodes via PBKDF2 (Jelly Bean), s-crypt (4.4+), or optional hardware-backed schemes (Lollipop+). The Device Encryption Key (DEK) encrypts data; a Key Encryption Key (KEK) wraps the DEK in an encrypted footer. However, Android's fragmentation is severe: most users run 2-year-old versions (Kitkat at talk time) compared to iOS's rapid adoption of new releases. This creates a matrix of security features available only in newer versions, forcing developers into complex conditional code to support multiple versions. Different manufacturers implement bootloaders inconsistently—some check signatures, some lock bootloaders, and others leave them permissively open, creating unpredictable security postures. The Android Keystore was historically weak, poorly documented, and unreliable, causing developers to distrust it. Marshmallow brought improvements: s-crypt hashing of passcodes, official symmetrical keystore key support, and Nexus Imprint fingerprint support with standardized OEM implementation.

## Bootloader Vulnerabilities and Rosie Demonstration

The talk demonstrates critical vulnerabilities in permissive bootloaders. Samsung's Download Mode (Odin) allows arbitrary partition writes without authentication. The open-source Heimdall tool replicates this cross-platform. Little Kernel bootloaders have published CVEs enabling arbitrary boot, signature forgery, and sparse bundle bounds overflow attacks. LG's "Laugh" bootloader backdoor existed on numerous devices including Nexus 5, allowing root shell access via Python script. The speakers developed Rosie (Evil Android Evil Maid), which exploits permissive bootloaders to flash a backdoored kernel in under 23 seconds—even on a powered-off device. After the user re-enters their decryption passcode, the kernel exfiltrates encrypted files to a remote server. Critically, full disk encryption provides no protection because the bootloader vulnerability allows kernel replacement before the encryption stack initializes.

## Recommendations and Future Direction

For end-users: employ strong passcodes, use biometric features (Touch ID, Nexus Imprint), enable remote wipe, and encrypt devices. For developers: consider data storage necessity, choose appropriate protection classes, avoid custom crypto, and account for platform fragmentation. For manufacturers: ship with security enabled by default, provide responsible bootloader unlock mechanisms, document security guarantees clearly, enforce OEM consistency, and mandate encryption. Marshmallow's forced OEM unlock requirement and Lollipop's optional hardware-backed keys are progress, but comprehensive protections remain needed.