How Encryption Actually Protects Your Phone

Pick up your phone, type your PIN, and swipe to your home screen. Between the moment you pressed the power button and the moment your apps appeared, your phone decrypted hundreds of thousands of files using an AES-256 key that exists nowhere on permanent storage, was derived in part from your PIN, in part from a secret fused into silicon at manufacture time, and in part from a key derivation function calibrated to take roughly 80 milliseconds on dedicated hardware and years on anything else. If someone stole your phone while it was powered off, they would be holding a slab of encrypted NAND flash with no practical way to read a single byte of your data without either your PIN or a vulnerability in a chip the size of a grain of rice.

That is the security model of a modern smartphone. It is not about one big lock on one big disk. It is a layered key hierarchy where hardware, software, and your passcode each contribute a piece, and where the absence of any one piece makes the whole thing computationally infeasible to break. The engineering behind it spans silicon design, cryptographic protocol design, operating system architecture, and the economics of brute-force attacks.

This article walks through every layer: the history of phone encryption, the key hierarchies on iOS and Android, the hardware security processors that enforce rate limiting, the key derivation functions that stretch a 6-digit PIN into something an attacker cannot guess, the difference between a phone that has just been powered on and one that has been unlocked once, what forensic tools like Cellebrite and GrayKey actually exploit, and why cloud backups quietly undermine the whole system.

Full Disk Encryption: How It Started

The story of phone encryption begins with full disk encryption (FDE), and FDE on phones began as a direct port of the same technology used on Linux servers.

Android introduced optional FDE in version 3.0 (Honeycomb, 2011) and made it mandatory for devices with capable hardware in Android 5.0 (Lollipop, 2014). The implementation was dm-crypt, the same block-level encryption layer used in LUKS on desktop Linux. The entire /data partition was encrypted as a single dm-crypt volume using AES-128-CBC (later AES-256-XTS on newer devices). The encryption key was derived from the user's PIN or password using PBKDF2 with a device-specific salt, and the derived key was stored in a structure called the "crypto footer" at the end of the partition, itself encrypted with the user's credentials.

iOS adopted full-device encryption earlier, starting with the iPhone 3GS in 2009, but the early implementation was hardware-only: the device had a hardware AES engine that encrypted all flash storage with a key burned into silicon (the UID key), but since the key was always available to the hardware, the encryption protected against removing the flash chips physically but not against software-based extraction on a running device. The passcode was not involved in the encryption at all. Apple fixed this progressively through iOS 4, 5, and 7, tying the passcode into the key derivation and introducing the per-file protection class system that remains the foundation of iOS data protection today.

The problem with FDE on phones was the same problem FDE has on laptops: the entire disk is either locked or unlocked. When the phone boots, before the user has entered their PIN, nothing on the encrypted partition is available. That means no alarms, no incoming calls, no emergency contact information, no accessibility services. Android worked around this for a while by showing a special pre-boot unlock screen, but the user experience was poor, and the system was fragile. If the phone rebooted overnight (say, due to an update or a crash), it would sit at the FDE unlock screen and not receive calls until the owner woke up and typed their PIN.

Both Apple and Google solved this by moving away from full disk encryption and toward file-based encryption.

File-Based Encryption: Per-File Keys And Protection Classes

File-based encryption (FBE) encrypts individual files with individual keys, and those keys are themselves encrypted with different "wrapping" keys that become available at different points in the device lifecycle. This is the system both iOS and Android use today.

iOS Data Protection Classes

Apple's implementation is called Data Protection, and it assigns every file on the device to one of four protection classes. Each class determines when the file's key is available in memory.

NSFileProtectionComplete is the strongest class. Files in this class are encrypted with a key derived from both the hardware UID key and the user's passcode. The key is discarded from memory when the device locks, and it is only re-derived when the user unlocks the device again. If the phone is locked, these files are completely inaccessible, even to the operating system itself. Apps that handle sensitive data (banking apps, password managers, health data) are supposed to use this class.

NSFileProtectionCompleteUnlessOpen is a clever middle ground. The key for these files is available while the file is open, even if the device locks. When the file is closed, the key is discarded. This class uses an asymmetric trick: the file's per-file key is wrapped with an ephemeral ECDH key pair. The public half is stored with the file metadata, and the private half is derived from the passcode. When the device is locked, new files can still be created in this class (the system generates a new ephemeral key pair and wraps the file key with the public half), but existing closed files cannot be read until the device is unlocked and the private half is available again. This is how the Mail app can receive new email attachments while the phone is locked but cannot read previously downloaded ones.

NSFileProtectionCompleteUntilFirstUserAuthentication (often abbreviated as "AfterFirstUnlock" or AFU) is the default class for most app data. The key is derived when the user first unlocks the device after a boot, and it remains in memory until the device is powered off or rebooted. Locking the screen does not discard the key. This class is a pragmatic compromise: apps can continue to access their data in the background while the phone is locked, which is necessary for things like push notifications, background fetch, VoIP, and location tracking. The tradeoff is that the key is in memory whenever the phone is on and has been unlocked at least once, which makes it vulnerable to extraction if someone can read kernel memory.

NSFileProtectionNone is the weakest class. The file is encrypted with a key that is always available after boot, regardless of whether the user has unlocked the device. This class exists for files that the system needs before any user interaction: certain system databases, some log files, and a few configuration files. Very little user data should be in this class.

Every file on the device has a unique 256-bit per-file key, generated randomly when the file is created. That per-file key is wrapped (encrypted) with the class key corresponding to the file's protection class. The class key is itself wrapped with a combination of the hardware UID key and (for the passcode-dependent classes) a key derived from the user's passcode. The per-file keys are stored in the file's metadata on the APFS filesystem.

Android File-Based Encryption

Android's FBE, introduced in Android 7.0 (Nougat) and mandatory since Android 10, takes a similar approach but with different terminology.

Android FBE divides storage into two categories:

Credential Encrypted (CE) storage is encrypted with a key derived from the user's PIN, password, or pattern, combined with a hardware-bound key. CE storage is only available after the user has unlocked the device. This is where most app data, photos, messages, and user files live. Each user profile on a multi-user Android device gets its own CE key, so a guest profile cannot read the primary user's CE data even if both are logged in.

Device Encrypted (DE) storage is encrypted with a key bound to the hardware but not to the user's credentials. DE storage is available immediately after boot, before any user has unlocked. This is where the phone stores things it needs for basic functionality before unlock: the dialler (so the phone can receive calls), the alarm clock, accessibility settings, and the Direct Boot-aware apps that developers have explicitly opted into.

The encryption itself uses AES-256-XTS for file contents and AES-256-CTS (ciphertext stealing mode) for file names. Since Android 11, Adiantum (a construction based on XChaCha12 and AES-256 designed by Google) is available as an alternative for devices without hardware AES acceleration, though such devices are increasingly rare.

Android also supports per-profile keys in its multi-user system. A tablet shared between Nikos and Elena, each with their own user profile, has separate CE keys for each profile. Nikos's key is derived from Nikos's PIN and the hardware secret; Elena's from hers. The DE key is shared, because DE storage needs to be available before either user has authenticated.

The Key Hierarchy: From Silicon To Files

The key hierarchy on a modern phone is deep enough that it is worth laying out explicitly. The details differ between Apple and Google, but the architecture is similar.

On iOS, the hierarchy looks like this:

Hardware UID key (fused in Secure Enclave at manufacture)
    │
    ├── Combined with passcode via KDF ──► Class keys (Complete, AFU, etc.)
    │       │
    │       └── Wraps per-file keys ──► Individual file encryption (AES-256-XTS)
    │
    └── Device key (not passcode-dependent) ──► NoProtection class key
            │
            └── Wraps per-file keys ──► System files encrypted at rest

On Android (with a Titan M or StrongBox-equipped device):

Hardware-bound key (in Titan M / StrongBox Keymaster)
    │
    ├── Combined with user credential via KDF ──► CE master key
    │       │
    │       └── Derives per-file keys via HKDF ──► File encryption (AES-256-XTS)
    │
    └── Hardware key alone ──► DE master key
            │
            └── Derives per-file keys via HKDF ──► Direct Boot files

The critical observation is that the hardware key at the top of the hierarchy never leaves the security processor. It is not stored in flash. It is not stored in the main SoC's memory. It is fused into the silicon of the Secure Enclave (Apple) or the Titan M chip (Google Pixel), and the only way to use it is to send a request to the security processor, which performs the cryptographic operation internally and returns the result. The main application processor never sees the raw hardware key.

This means that even if an attacker has a complete memory dump of the main processor, they do not have the hardware key. They might have the derived class keys (if the phone was in AFU state), but they cannot recreate those keys on a different device, because the hardware key is unique to the original phone's security chip.

The Secure Enclave And Titan M: Dedicated Security Processors

The hardware security processor is the most important piece of the entire system, because it is the component that enforces rate limiting on PIN guesses and holds the hardware key that ties the entire key hierarchy to a specific physical device.

Apple Secure Enclave

The Secure Enclave Processor (SEP) is a separate ARM-based processor inside the Apple SoC (the A-series and M-series chips). It has its own boot ROM, its own encrypted memory (with a per-boot ephemeral key, so a cold-boot attack on the main DRAM does not reveal Secure Enclave memory), its own secure storage, and a hardware random number generator. It communicates with the main application processor through a mailbox interface: the AP sends requests ("derive the class key for this passcode attempt"), and the SEP processes them internally and returns results. The AP cannot read the SEP's memory, cannot inspect its internal state, and cannot bypass its rate-limiting logic.

The Secure Enclave enforces several things:

1. PIN attempt rate limiting. After five failed passcode attempts, the Secure Enclave enforces escalating delays: 1 minute after attempt 5, 5 minutes after attempt 6, 15 minutes after attempt 7, 1 hour after attempts 8 and 9, and the device can be configured to erase itself after attempt 10. These delays are enforced by the Secure Enclave's own timer, not by iOS. Even if an attacker patches iOS to remove the lockout UI, the Secure Enclave itself will refuse to perform the key derivation faster than the rate limit allows.

2. Hardware UID binding. The UID key is generated during manufacturing and fused into the Secure Enclave. Apple states that the UID is not recorded during manufacturing, so even Apple does not know it. The UID is entangled with the passcode during key derivation, so the correct class key can only be produced by the combination of the correct passcode and the correct Secure Enclave on the correct physical device.

3. Anti-replay. The Secure Enclave maintains a secure counter in its own non-volatile storage that prevents rolling back the state. An attacker cannot snapshot the Secure Enclave's state, try a PIN, fail, and then restore the snapshot to avoid the failure counter incrementing. The counter is monotonic and stored in tamper-resistant storage.

Google Titan M And StrongBox

Google's equivalent is the Titan M chip (Titan M2 on newer Pixel devices), a discrete security processor on the Pixel's mainboard. Titan M is not part of the main Qualcomm or Tensor SoC; it is a separate chip with its own processor, its own flash, its own boot ROM, and its own RNG. Google designed it specifically to resist hardware attacks, including glitching (voltage and clock manipulation), side-channel analysis, and physical probing.

Titan M implements the Android StrongBox Keymaster HAL, which is the interface through which Android's key derivation and credential verification happen. Like the Secure Enclave, Titan M enforces rate limiting on credential attempts in hardware: the chip itself refuses to perform key derivation operations faster than the configured rate, regardless of what the Android OS is doing.

On non-Pixel Android devices, the equivalent is typically a Trusted Execution Environment (TEE) running inside the main SoC (ARM TrustZone), with an optional discrete secure element. TrustZone provides isolation between a "secure world" and a "normal world" on the same processor, which is weaker than a discrete chip because it shares the CPU, cache, and memory bus with the application processor, but it is still a significant barrier. Samsung's Knox platform uses both TrustZone and a discrete Secure Element for credential storage on Galaxy devices.

The key difference between a discrete chip (Secure Enclave, Titan M) and a TEE (TrustZone) is the attack surface for hardware attacks. A discrete chip has its own power supply filtering, its own clock, and its own memory, which makes glitching and side-channel attacks harder. A TEE on the main SoC shares power and clock with the application processor, which makes it more susceptible to fault injection. This distinction matters when your threat model includes nation-state attackers with physical access and a well-equipped laboratory.

Key Derivation: Stretching A PIN Into An Encryption Key

A 6-digit numeric PIN has 1,000,000 possible values. That is roughly 20 bits of entropy, which is catastrophically weak by any cryptographic standard. A 4-digit PIN has only 10,000 possibilities (about 13.3 bits). Even a complex alphanumeric passcode with 10 characters drawn from a 72-character set (lowercase, uppercase, digits, some symbols) has only about 62 bits of entropy. None of these are strong enough to serve as an encryption key directly.

The solution is key derivation: combining the weak passcode with a strong hardware-bound secret through a key derivation function (KDF) that is deliberately slow and resource-intensive. The output of the KDF is the key (or a key-encrypting key) used in the encryption hierarchy. The KDF serves two purposes: it mixes the passcode entropy with the hardware entropy so that both are needed, and it makes each passcode guess expensive in time and resources.

PBKDF2

The earliest phone encryption systems used PBKDF2 (Password-Based Key Derivation Function 2), which iterates HMAC-SHA-1 or HMAC-SHA-256 many thousands of times. Android's original FDE used PBKDF2 with 2,000 iterations, later increased to higher counts. Apple used PBKDF2 in early iOS versions before switching to a custom construction inside the Secure Enclave.

PBKDF2's weakness is that it is trivially parallelisable on GPUs. Each iteration is a single HMAC operation with a tiny memory footprint, so an attacker with a rack of GPUs can run millions of PBKDF2 chains simultaneously. For a 6-digit PIN with 1,000,000 possibilities and PBKDF2 with 10,000 iterations of HMAC-SHA-256, a single modern GPU can exhaust the entire keyspace in seconds to minutes, depending on the iteration count.

scrypt

scrypt, designed by Colin Percival in 2009, was the first widely deployed memory-hard KDF. It forces the computation to allocate a large block of memory (configurable, but typically megabytes) and access it in a pseudorandom pattern, so that an attacker who wants to run N parallel instances needs N times the memory. GPUs have limited memory per core, and ASICs would need to include large SRAM arrays, both of which dramatically increase the cost per guess. Android adopted scrypt for its key derivation in later FDE implementations and early FBE.

Argon2

Argon2, the winner of the 2015 Password Hashing Competition, is the current state of the art. It comes in three variants: Argon2d (data-dependent memory access, resistant to GPU/ASIC attacks but vulnerable to side-channel attacks), Argon2i (data-independent access, resistant to side channels but slightly less resistant to GPU/ASIC), and Argon2id (a hybrid that starts with Argon2i passes and finishes with Argon2d, recommended for most uses). Argon2 is tuneable in three dimensions: time cost (number of iterations), memory cost (how much RAM to allocate), and parallelism (how many threads to use).

Neither Apple nor Google has publicly confirmed using Argon2 in their current on-device KDF; both use proprietary constructions inside their respective security processors. Apple's Secure Enclave uses a custom KDF that Apple describes as taking approximately 80 milliseconds per attempt on the Secure Enclave hardware, which translates to about 80 milliseconds per guess for an attacker (since the KDF can only run on the Secure Enclave). Google's Titan M enforces a similar per-attempt cost in hardware.

Why 6 Digits Takes Years On-Device

Here is the arithmetic that makes phone encryption work despite the weakness of a 6-digit PIN.

A 6-digit PIN has 1,000,000 possible values. If each attempt takes 80 milliseconds on the Secure Enclave (Apple's published figure), exhausting the full keyspace takes:

1,000,000 × 0.08 seconds = 80,000 seconds ≈ 22.2 hours

That is the lower bound if you could try PINs at the hardware-limited rate without any delays. But the Secure Enclave also enforces escalating lockout delays, and on many configurations, a wipe after 10 failed attempts. Even without the wipe, the escalating delays push the wall-clock time for a brute-force attack to weeks.

The critical point is the phrase "on-device". The 80 ms per attempt figure only applies if the attacker is running the KDF on the target phone's Secure Enclave, because the hardware UID key never leaves the Secure Enclave. If the attacker could somehow extract the hardware UID key (which would require a physical attack on the silicon, decapping the chip and probing internal buses), they could run the KDF on their own hardware. On a GPU cluster, 1,000,000 PBKDF2 operations would take seconds. On a cluster running scrypt or Argon2 with the same parameters, it might take minutes to hours. But without the hardware key, the attacker must use the phone itself as the oracle, and the phone's security processor dictates the pace.

This gap between on-device and off-device cracking speed is the entire security model. It is the reason a 6-digit PIN, which would be worthless as a password on a website, provides meaningful security on a phone. The hardware key turns a weak secret into a strong one by binding the cost of guessing to a specific piece of silicon.

BFU Vs AFU: The Two States Of A Phone

Every conversation about phone security eventually comes down to two acronyms: BFU (Before First Unlock) and AFU (After First Unlock). The difference between these two states is the difference between a phone that is genuinely locked down and a phone that is vulnerable to sophisticated extraction.

Before First Unlock

A phone in the BFU state has been powered on (or rebooted) but the user has not yet entered their PIN. In this state:

• The CE (Credential Encrypted) keys have not been derived, because the passcode has not been provided to the security processor.
• On iOS, the Complete and AfterFirstUnlock class keys are both unavailable. Only the NoProtection class is accessible.
• On Android, only DE (Device Encrypted) storage is mounted. CE storage is inaccessible.
• The phone can receive calls (because the dialler is in DE/NoProtection), display the lock screen, and run Direct Boot services, but almost no user data is available.
• The phone's NAND flash, if imaged, is encrypted with keys that cannot be derived without the passcode and the hardware UID key working together.

BFU is the state that phone encryption is designed for. A phone seized in BFU state by law enforcement or a thief is, for practical purposes, a brick. The only path to the data is to guess the PIN on-device (subject to rate limiting and possible wipe) or to find a vulnerability in the security processor itself.

After First Unlock

A phone in the AFU state has been unlocked at least once since boot. The user may have locked the screen since then, but the critical transition has already happened: the security processor has derived the CE keys, and those keys are now resident in memory.

On iOS, the AfterFirstUnlock class key is in memory. This class is the default for most app data, which means most of the user's messages, app databases, photos metadata, and similar data can be decrypted by anything that can read kernel memory. The Complete class key is discarded when the screen locks, so files in that class are still protected.

On Android, the CE key is in memory and stays there until reboot. All CE-encrypted files are accessible to the kernel.

The practical implication is stark: a phone in AFU state with a kernel vulnerability can be fully extracted. The attacker does not need to guess the PIN; the keys are already in memory. They need an exploit that lets them read kernel memory or execute code with kernel privileges, and then they can extract the CE/AFU class keys and decrypt the storage.

This is why rebooting your phone before handing it to border agents or before entering a situation where it might be seized is meaningful security advice. A reboot puts the phone back into BFU state, which forces the attacker through the full key derivation path, including the rate-limited security processor. A phone that is merely screen-locked is in AFU state and is dramatically weaker.

What Cellebrite And GrayKey Actually Exploit

Cellebrite and GrayKey (now GrayShift, acquired by Magnet Forensics) are the two most prominent commercial forensic extraction tools. They are sold to law enforcement agencies worldwide, and their capabilities are a closely guarded commercial secret. But enough has leaked through court documents, security research, and vendor marketing materials to build a reasonable picture of what they do.

AFU Extraction

The most common capability of these tools is AFU extraction: they exploit a vulnerability in the phone's operating system (typically a kernel or bootloader bug) to gain code execution while the phone is in AFU state, then read the decryption keys from memory and extract the full filesystem. This works because, as discussed above, the AFU class keys are in memory. The tools do not need to break the encryption or guess the PIN; they exploit the fact that the phone has already decrypted itself.

Cellebrite's UFED and GrayKey both maintain libraries of exploits for specific device models and OS versions. When a new iOS or Android version ships, there is a window (sometimes weeks, sometimes months) before the forensic vendors find and weaponise a new exploit for that version. During that window, devices on the latest OS version may be resistant to extraction. After the vendors catch up, the devices are vulnerable again until the next OS update. This is an ongoing cat-and-mouse game.

The exploits used are typically the same class of bugs used by jailbreak developers and security researchers: use-after-free bugs in the kernel, type confusion in IOKit drivers (on iOS), sandbox escapes, bootloader vulnerabilities that allow unsigned code execution, and occasionally baseband (cellular modem) bugs that provide an entry point.

BFU Extraction (Partial)

Against phones in BFU state, the tools are much more limited. They can extract the small amount of data available without the user's credentials: DE-encrypted data on Android, NoProtection-class data on iOS. This typically includes things like Wi-Fi MAC addresses, serial numbers, installed app lists (on some Android versions), and some system logs. It does not include messages, photos, contacts, or app data.

Some forensic tools claim "BFU unlock" capabilities for specific, older device models. These typically exploit vulnerabilities in the Secure Enclave or Titan M firmware that allow bypassing the rate limit on PIN guesses. Once the rate limit is bypassed, the tool can brute-force the PIN at the speed of the KDF (80 ms per attempt on Apple devices), which makes a 4-digit PIN crackable in about 13 minutes and a 6-digit PIN in about 22 hours. These bypasses are rare, because vulnerabilities in the security processor firmware are harder to find than vulnerabilities in the main OS, and both Apple and Google patch them aggressively.

Bootloader And Secure Enclave Bypasses

The most valuable exploits in the forensic world are Secure Enclave or Titan M bypasses that allow either extracting the hardware UID key or disabling the rate limiter on PIN attempts.

In 2020, the checkm8 exploit (a hardware vulnerability in the USB DFU mode of Apple's A5 through A11 chips) gave researchers and forensic tools the ability to run unsigned code on iPhones from the 5s through the X. checkm8 is a boot ROM bug, which means Apple cannot patch it with a software update; the vulnerability is in read-only silicon. However, checkm8 alone does not defeat the Secure Enclave: it gives code execution on the application processor, but the Secure Enclave is a separate processor with its own boot ROM. On A11 and older devices, researchers found ways to use checkm8 as a stepping stone to exploit the Secure Enclave's communication interface, but on newer chips (A12 and later), the Secure Enclave boot ROM is separate and the checkm8 vulnerability does not exist.

GrayKey made headlines in 2018 for reportedly being able to brute-force any iPhone PIN regardless of the rate limit. The exact mechanism was never publicly confirmed, but security researchers believe it involved a Secure Enclave exploit that disabled or bypassed the attempt counter. Apple responded with USB Restricted Mode in iOS 11.4.1, which disables the Lightning port's data lines after one hour of inactivity, making it harder for forensic tools that rely on USB-based exploits to connect to a locked phone.

The Economics

It is worth noting that Cellebrite's UFED Premium costs law enforcement agencies upwards of €15,000 to €30,000 per year, and GrayKey devices cost between €12,000 and €25,000. These are not consumer tools. The exploits they contain are worth millions on the vulnerability market, and the vendors amortise that cost across thousands of law enforcement customers. The result is that phone encryption protects against casual theft absolutely, protects against well-resourced attackers in BFU state usually, and protects against well-resourced attackers in AFU state only if the phone is running an OS version for which no current exploit exists.

The Apple Vs FBI Case: What The FBI Actually Wanted

In December 2015, Syed Rizwan Farook and Tashfeen Malik carried out a mass shooting in San Bernardino, California. Farook's work iPhone, a 5c running iOS 9, was recovered by the FBI. The phone was locked with a 4-digit PIN and had the auto-erase feature enabled (wipe after 10 failed attempts).

The technical specifics of the case are instructive. The iPhone 5c uses an A6 chip, which does not have a Secure Enclave. On this device, the PIN attempt counter and the auto-erase logic are enforced by software (iOS itself), not by a separate hardware security processor. The key derivation uses the hardware UID key fused into the A6, but the rate limiting is done by the OS.

The FBI asked Apple to create a modified version of iOS that would:

1. Disable the auto-erase feature (so the phone would not wipe after 10 failed attempts).
2. Remove the escalating time delays between PIN attempts.
3. Allow PIN entry electronically over the Lightning port or Wi-Fi, rather than through the touchscreen, so the FBI could script the brute force.

With these three modifications, the FBI could have brute-forced all 10,000 possible 4-digit PINs in minutes. The request was not to break AES-256 or to extract the UID key; it was to remove the software-enforced rate limiting that made brute force impractical.

Apple refused, arguing that creating such a tool (sometimes called "GovtOS" in the press) would set a precedent that would undermine the security of all iPhones, because the same tool could be used on any device, and the existence of the tool would itself be a target for theft or compelled disclosure.

The case became moot when the FBI announced it had purchased an exploit from a third party (widely reported to be the Australian firm Azimuth Security) that allowed them to bypass the PIN lockout without Apple's help. The exploit reportedly used a vulnerability in the iPhone 5c's USB stack to gain code execution and disable the attempt counter.

The case highlighted two things. First, the iPhone 5c was an older design without a Secure Enclave, which made the software-based rate limiting the only barrier, and software-based barriers can be bypassed by software. Second, on newer iPhones with a Secure Enclave, the FBI's request would have been technically meaningless: the rate limiting is enforced by the Secure Enclave hardware, and Apple cannot create a software update that modifies the Secure Enclave's rate-limiting behaviour (because the Secure Enclave has its own firmware signing and update process, which is independent of iOS).

This is why Apple invested so heavily in the Secure Enclave for newer devices. The architectural lesson from San Bernardino was that any security property enforced only by software on the main application processor can be undermined by a sufficiently motivated adversary who can get the vendor to write (or a researcher to find) modified software. Hardware enforcement, where the rate limiting runs on a separate processor that the main OS cannot control, is categorically stronger.

AES-256-XTS: The Encryption On The Wire

Both iOS and Android use AES-256-XTS for encrypting file contents on storage. XTS (XEX-based Tweaked-codebook mode with ciphertext Stealing) is a block cipher mode specifically designed for storage encryption, and it is worth understanding why this particular mode was chosen.

Storage encryption has a specific constraint that network encryption does not: you cannot expand the ciphertext. A 4096-byte disk sector must encrypt to exactly 4096 bytes of ciphertext, because the storage layer expects fixed-size blocks. Stream cipher modes like AES-GCM add an authentication tag (typically 16 bytes), which would mean a 4096-byte plaintext becomes 4112 bytes of ciphertext, and that does not fit in a 4096-byte sector. You could shrink the plaintext to 4080 bytes and waste 16 bytes per sector on the tag, but this would require reformatting the entire storage layout and would waste roughly 0.4% of disk capacity, which was considered unacceptable when these standards were written.

XTS mode works by encrypting each block with AES-ECB, but tweaking each block's encryption with a value derived from the sector number and the block's position within the sector. The tweak ensures that identical plaintext blocks at different locations produce different ciphertext blocks (unlike raw ECB mode, which would produce identical ciphertext for identical plaintext). The construction is:

C_j = AES_K1(P_j XOR T_j) XOR T_j
T_j = AES_K2(sector_number) * alpha^j    (in GF(2^128))

where K1 and K2 are two independent AES keys (hence AES-256-XTS uses a 512-bit key, split into two 256-bit AES keys), P_j is plaintext block j, C_j is ciphertext block j, and alpha^j is a multiplication in the Galois field GF(2^128) that shifts the tweak for each block within the sector.

The "ciphertext stealing" part handles the case where the data is not a multiple of the AES block size (16 bytes). It borrows ciphertext from the previous block to pad the final partial block, ensuring the output is always the same size as the input.

XTS does not provide authentication. An attacker who can modify the ciphertext on the storage can flip bits in the plaintext in a somewhat predictable way (each modified ciphertext block produces a garbled plaintext block, but the corruption is confined to that block). This is a known limitation; the assumption is that storage-level authentication is handled at a higher layer (filesystem checksums, verified boot, or dm-verity for system partitions). For user data, the lack of per-block authentication means a sophisticated attacker with write access to the encrypted storage could corrupt specific files, but they cannot read the plaintext without the key, and the corruption would likely be detected by the application layer.

Android's implementation of AES-256-XTS for FBE is done in the Linux kernel's fscrypt subsystem. iOS uses a hardware AES engine in the SoC that operates inline on the path between the flash controller and the memory bus, so all flash I/O is encrypted and decrypted in hardware without software intervention. This inline encryption engine is separate from the Secure Enclave; it is an AES accelerator on the data path that receives its keys from the Secure Enclave but performs the bulk encryption at wire speed.

The Secure Boot Chain: Trusting The Software That Holds The Keys

Encryption keys are only as trustworthy as the software that manages them. If an attacker can modify the bootloader or the kernel, they can intercept keys as the security processor releases them during a legitimate unlock. This is why both iOS and Android implement a secure boot chain that verifies every piece of software from the boot ROM to the final application.

On iOS, the chain is:

1. Boot ROM (read-only, in silicon): verifies the signature of the Low-Level Bootloader (LLB) or iBoot (depending on the generation) against Apple's root certificate. The Boot ROM is immutable; it is hardcoded into the chip at manufacture time.
2. iBoot: verifies the kernel's signature.
3. Kernel: verifies the integrity of the root filesystem (which is mounted read-only on modern iOS) and verifies the signatures of all kernel extensions.
4. The Secure Enclave has its own parallel boot chain: the main boot ROM loads and verifies the Secure Enclave's firmware (sepOS) separately.

If any verification fails, the device enters DFU (Device Firmware Upgrade) mode and refuses to boot. There is no "boot anyway" option.

On Android (Pixel devices with Titan M):

1. Titan M boot ROM: verifies Titan M firmware.
2. Main SoC boot ROM: verifies the bootloader.
3. Bootloader (ABL): verifies the boot image (kernel + ramdisk) using Android Verified Boot (AVB). The bootloader checks the VBMeta structure, which contains hashes or hashtree descriptors for every partition (system, vendor, boot, dtbo).
4. dm-verity: the kernel uses a Merkle tree (stored in the vbmeta partition) to verify every block of the system partition on access, so a single modified byte in any system file causes a read error.

Android's Verified Boot has an important nuance: it supports an "unlocked" state where the user has explicitly unlocked the bootloader (typically through a developer option and a fastboot command). In the unlocked state, the bootloader shows a warning but does not enforce signature verification. This is by design, to allow developers and custom ROM users to run modified software. However, unlocking the bootloader triggers a factory reset (wiping all user data) and sets a flag visible to the Titan M, which causes the hardware to refuse to release any keys that were sealed to the locked state. An attacker cannot silently unlock the bootloader, install a modified kernel, and then access the existing encrypted data; the data is wiped as part of the unlock process.

Samsung's Knox platform adds an additional wrinkle: a hardware fuse (the "Knox warranty bit") that is permanently blown when the bootloader is unlocked. Once blown, it cannot be reset, and it permanently disables access to certain secure storage features (like Samsung Pay credentials and some enterprise MDM-managed data). This is controversial among the custom ROM community but is an effective anti-rollback mechanism.

Cloud Backups: The Quiet Weakness

All of the encryption described above protects data on the device. It says nothing about copies of that data stored in the cloud. And for years, cloud backups were the easiest way to access a target's data without touching the phone at all.

iCloud Backups (Before Advanced Data Protection)

Until late 2022, iCloud backups were encrypted in transit and at rest on Apple's servers, but Apple held the encryption keys. This meant that Apple could (and did, in response to valid legal process) decrypt and hand over iCloud backup data to law enforcement. Since iCloud backups include messages, photos, app data, health data, keychain items (with some exceptions), and most of the same data that is on the phone, this was effectively a backdoor around on-device encryption.

The irony was pointed out repeatedly by security researchers: Apple invested billions of euros in Secure Enclave hardware, made the device itself nearly impenetrable, and then shipped a backup system that stored an unencrypted copy of everything on their servers. A law enforcement agency that could not break into a locked iPhone 14 could simply serve Apple with a court order for the iCloud backup and get most of the same data.

The reason Apple gave for this design was key recovery: if a user forgot their Apple ID password, Apple could still recover their backup data. End-to-end encryption of backups would mean that a forgotten password results in permanent data loss, which is a support nightmare for a company with over a billion active devices.

Advanced Data Protection

In December 2022, Apple introduced Advanced Data Protection (ADP), an opt-in feature that extends end-to-end encryption to most iCloud data categories, including backups, photos, notes, reminders, Safari bookmarks, voice memos, Wallet passes, and more. With ADP enabled, the encryption keys for these categories are held only on the user's devices. Apple's servers store the encrypted data but cannot decrypt it. If the user loses all their trusted devices and their recovery key (or recovery contact), the data is gone permanently.

ADP does not cover everything. iCloud Mail, Contacts, and Calendar are still encrypted with Apple-managed keys, because these services need to interoperate with third-party mail and calendar servers that do not support end-to-end encryption. Health data shared with a doctor, and some other interoperable data types, are similarly excluded.

With ADP enabled, a law enforcement request to Apple for iCloud backup data will return encrypted blobs that Apple cannot decrypt. The agency would need to obtain the keys from one of the user's trusted devices, which brings the problem back to device encryption and all the protections discussed earlier.

Google Cloud Backups

Google's approach to backup encryption has been less publicised but has followed a similar trajectory. Since Android 9 (Pie), Android cloud backups to Google Drive are encrypted with a key stored in the user's device's Titan M or TEE, and Google states it cannot decrypt the backup without the device. The backup encryption key is wrapped with the user's lock-screen credential through the security processor, and the wrapped key is stored on Google's servers. Decryption requires the original device (or a device that can recreate the same hardware-bound key, which in practice means the same physical phone).

However, not all Google data is covered by this. Google Photos, if synced to the cloud, are encrypted at rest on Google's servers but with Google-held keys (similar to pre-ADP iCloud). Gmail, Google Drive documents, and other Google services are encrypted at rest with Google-managed keys. End-to-end encryption for Google services beyond backups remains limited as of 2026.

SIM PIN And Network-Level Protections

The SIM card (or eSIM) in your phone has its own encryption and authentication system, separate from the device encryption discussed above. The SIM's security is relevant because it protects your phone number, your cellular identity (IMSI), and your ability to authenticate to the mobile network.

A SIM card contains a small secure element (a JavaCard-based processor) that stores a long-term secret key, Ki, shared between the SIM and the carrier's Authentication Centre (AuC). When the phone connects to the network, the AuC sends a random challenge, the SIM computes a response using Ki and the MILENAGE algorithm (or its predecessor, COMP128), and the network verifies the response. Ki never leaves the SIM; the authentication is a zero-knowledge-style challenge-response.

The SIM PIN is a 4- to 8-digit code that locks the SIM itself. If enabled, the SIM will not perform authentication (and thus the phone cannot connect to the network) until the SIM PIN is entered. After three failed SIM PIN attempts, the SIM locks and requires a PUK (PIN Unlock Key) from the carrier. After ten failed PUK attempts, the SIM is permanently bricked.

SIM PIN protects against a specific attack: someone takes your SIM card out of your phone, puts it in their own phone, and uses your phone number to receive calls, SMS messages (including two-factor authentication codes), and impersonate you on the network. With SIM PIN enabled, the stolen SIM is useless without the PIN.

eSIMs complicate this slightly because they cannot be physically removed, but the eSIM profile can potentially be transferred through social engineering at the carrier ("SIM swap" attacks). The defence against SIM swap is carrier-side authentication (account PINs, identity verification), which is outside the scope of device encryption but worth mentioning because it is a common vector for compromising phone-based authentication.

Network-level encryption (the encryption between your phone and the cell tower) is a separate layer. 4G LTE uses AES-128 or SNOW 3G for the radio link, and 5G NR adds 256-bit encryption and integrity protection. But network-level encryption is between the phone and the tower; it does not protect data stored on the phone, and it does not protect against the network operator itself (who terminates the encryption at the tower and can access the traffic in plaintext). Device encryption and network encryption solve different problems and operate at different layers.

Cryptographic Erase: What Happens When You Factory Reset

When you perform a factory reset on a modern phone, the phone does not overwrite every byte of NAND flash with zeros. On a 256 GB phone, that would take minutes to hours and would wear out the flash cells unnecessarily. Instead, the phone performs a cryptographic erase: it destroys the encryption keys, leaving the encrypted data on the flash but making it permanently unreadable.

On iOS, a factory reset (called "Erase All Content and Settings") instructs the Secure Enclave to destroy the "effaceable storage" region, which holds the wrapped class keys and the file system key. Once these keys are gone, every file on the device is encrypted with a key that no longer exists. The data is still physically present on the NAND flash, but it is AES-256-encrypted data with no known key, which is indistinguishable from random noise.

On Android, a factory reset destroys the CE and DE master keys in the Titan M (or TEE), then performs a BLKDISCARD (TRIM) on the /data partition, which tells the flash controller that all blocks are free. The flash controller's garbage collection will eventually recycle those blocks, but even before that happens, the data is encrypted with destroyed keys.

Cryptographic erase is remarkably fast: it takes seconds, because all you need to destroy is a few hundred bytes of key material. It is also remarkably thorough: assuming the encryption was implemented correctly and the keys were truly destroyed (not just marked as free but still recoverable from flash), the data is gone in an information-theoretic sense. No amount of flash forensics can recover data encrypted with a destroyed AES-256 key.

There are edge cases. If the phone used an older FDE implementation with a known vulnerability, or if the key storage had a bug where keys were written to a location that was not properly erased, forensic recovery might be possible. Some very early Android devices with eMMC flash (before UFS) had issues where the TRIM command was not reliably implemented by the flash controller, and old key material could persist. Modern devices with UFS storage and hardware inline encryption do not have this issue.

The speed and reliability of cryptographic erase is also why "remote wipe" features (Find My iPhone, Google Find My Device) work: the remote wipe command triggers a cryptographic erase, which completes in seconds. An attacker who steals a phone and puts it in aeroplane mode (to block the remote wipe) can delay the erase, but they still face the full device encryption. The remote wipe is a defence against the scenario where the phone is stolen while unlocked and the attacker wants to keep it in AFU state to extract data later.

Limitations: When Encryption Cannot Save You

Phone encryption is strong, but it is not absolute. There are several scenarios where it fails or is irrelevant.

The phone is in AFU state when seized. As discussed earlier, most of the encryption keys are in memory in AFU state. If the adversary has a kernel exploit for the phone's current OS version, they can extract the keys without the PIN. This is the most common forensic scenario, because most phones that are seized by law enforcement are either powered on in the owner's pocket or were recently used.

Biometrics can be compelled. In many jurisdictions (including several EU member states and the United States), courts have ruled that biometric authentication (fingerprint, face) can be compelled, while PIN/password knowledge cannot, under the principle that a biometric is something you are, not something you know, and therefore not protected by the privilege against self-incrimination. The legal landscape varies: German courts have generally been more protective of biometric data, while courts in some other jurisdictions have allowed compelled fingerprint unlocks. The practical defence is to disable biometrics before entering a situation where the phone might be seized (on both iOS and Android, pressing the power button five times triggers an SOS mode that requires the PIN for the next unlock).

Shoulder surfing and coerced disclosure. If someone watches you type your PIN, or if you are physically compelled to reveal it, no amount of cryptographic engineering helps. This is the "rubber hose cryptanalysis" problem, and it is outside the scope of what technology can solve. Some phones offer a "duress PIN" feature (or apps that provide one) that unlocks a decoy profile or triggers a wipe, but these are not standard.

Vulnerabilities in the security processor. The Secure Enclave and Titan M are small, purpose-built processors with minimal firmware, and they are designed to be hard to attack. But they are not invulnerable. Bugs have been found in the Secure Enclave (including the 2020 "unpatchable" SEP vulnerability on A11 and older chips reported by the Pangu Team) and in various TrustZone implementations. These bugs are rare and valuable (worth millions of euros on the exploit market), but they exist, and nation-state adversaries can be assumed to stockpile them.

Backup and sync services. As discussed in the cloud backup section, any data that leaves the phone for a cloud service is only as protected as that service's encryption model. End-to-end encrypted messaging (Signal, WhatsApp) protects message content, but metadata (who you talked to, when, and how often) is often available to the service provider or the carrier. iMessage is end-to-end encrypted, but if iCloud backup is enabled without Advanced Data Protection, the iMessage decryption keys are included in the backup, which Apple can access.

Baseband vulnerabilities. The cellular modem (baseband processor) in every phone runs its own real-time operating system, which is separate from iOS or Android. Baseband processors have historically been poorly audited and have had serious vulnerabilities. A compromised baseband can potentially access shared memory or DMA regions that contain sensitive data. Apple moved to an in-house baseband design starting with the iPhone 16, partly for security reasons; previously, all iPhones used Qualcomm or Intel baseband chips with proprietary firmware that Apple could not fully audit.

Physical attacks on silicon. If an attacker has the resources to decap the SoC and probe the Secure Enclave's internal buses with a focused ion beam (FIB) or similar tool, they might be able to extract the hardware UID key. This is a multi-million-euro attack that requires specialised equipment and expertise, and the latest Secure Enclave designs include countermeasures (active mesh layers, randomised layout, voltage glitch detection) that make it harder but not impossible. For context, this is the kind of attack that intelligence agencies budget for; it is not a realistic threat for the vast majority of phone users.

Putting It All Together

The security of a modern smartphone's encryption is not a single lock. It is a system of interlocking mechanisms where the failure of any one component is mitigated by the others.

The hardware UID key ensures that the encryption is bound to a specific physical device. The key derivation function ensures that the user's PIN is stretched into a strong key that takes 80+ milliseconds per guess on the security processor. The security processor's rate limiting ensures that even 80 ms per guess is optimistic; real-world brute force against a locked device takes hours to days for a 6-digit PIN, with escalating delays and optional auto-wipe. The file-based encryption with protection classes ensures that different data has different availability windows, so a phone that is locked (but in AFU state) still protects its most sensitive files. The secure boot chain ensures that the software managing the keys has not been tampered with. And cryptographic erase ensures that destroying a phone's data is as simple and reliable as destroying a few hundred bytes of key material.

The weak points are real: AFU state exposes most keys to kernel-level attackers, cloud backups (without end-to-end encryption) expose everything to the cloud provider and anyone who can serve them legal process, biometrics can be compelled in many jurisdictions, and vulnerabilities in the security processor, while rare, do exist.

For Katerina in Helsinki, who is worried about her phone being stolen from a cafe table, the encryption is more than sufficient: a thief who grabs the phone and powers it off has a BFU brick. For Dimitris in Athens, who is a journalist with a credible threat model that includes state-level adversaries, the calculus is more nuanced: he needs to keep his phone in BFU state when crossing borders, use a strong alphanumeric passcode instead of a 6-digit PIN, enable Advanced Data Protection (or avoid iCloud entirely), use Signal for messaging, and accept that a sufficiently motivated and well-funded adversary may still prevail if they have physical access and an up-to-date exploit chain.

The engineering community's direction is clear: push more security properties into hardware, reduce the trust placed in the main application processor's software, and close the gap between BFU and AFU security. Apple's Lockdown Mode (which disables a significant amount of attack surface, including JIT compilation, most message attachment types, and USB connectivity when locked) is one step. Android's upcoming per-app encryption classes (where individual apps can request Complete-equivalent protection for their data, rather than relying on the system default of AfterFirstUnlock) are another. The goal is a phone where even an AFU-state kernel compromise exposes as little data as possible.

We are not there yet. But the gap between a phone from 2012 (no encryption, or FDE with a software-only PIN lockout) and a phone from 2026 (file-based encryption, hardware-bound keys, dedicated security processor, rate-limited KDF, verified boot, optional end-to-end encrypted backups) is enormous. The amount of engineering, silicon design, and cryptographic protocol work that went into closing that gap is one of the more impressive security achievements of the past decade.