Field Notes

synthesis

Offline brute-force resistance of phone disk encryption

StatusStableUpdatedStands on11 sourcesSupportsnotes

Both Android and iOS gate disk encryption behind the user’s lock-screen credential, but they differ in what remains if the secure-hardware throttle is ever defeated. Android’s design leaves an offline fallback whose cost depends almost entirely on user-chosen entropy; Apple’s design is built so that no offline fallback exists. The difference is real, verified in both vendors’ own documentation, and it is the corner of the mobile-security comparison where iOS is architecturally ahead. It is also narrower than it first appears: reaching the offline regime on a Pixel requires compromising the Titan M secure element itself, and on current hardware no such compromise is public.

The two derivation architectures

flowchart TD
  subgraph Android[Android / GrapheneOS on Pixel]
    A1[LSKF: PIN or passphrase] --> A2[scrypt ~25 ms, ~2 MiB]
    A2 --> A3[Weaver key]
    A3 --> A4{Titan M2}
    A4 -->|correct key, throttled| A5[Weaver secret released]
    A5 --> A6[SoC hardware-bound KDF]
    A6 --> A7[synthetic password]
    A7 --> A8[CE keys]
  end
  subgraph iOS[iPhone]
    B1[passcode] --> B2{Secure Enclave}
    B2 --> B3[key-tangle ~80 ms with fused UID]
    B3 --> B4[class keys]
    B5[Secure Storage Component: counter lockbox] -.->|attempt limit, erase| B2
  end

On Android, LockSettingsService stretches the credential with scrypt “targeting a time of about 25 ms and a memory usage of about 2 MiB” — and AOSP’s own documentation concedes that “since LSKFs are usually short, this step usually does not provide much security. The main layer of security is the SE or TEE-enforced rate-limiting.”1 The stretched credential authenticates to Weaver, a HAL in which the secure element stores a high-entropy random secret per profile and releases it when the correct key is presented.2 The Weaver secret and the password token then feed a hardware-bound derivation in the SoC, yielding the synthetic password that unwraps the CE keys.

On iOS, the passcode is entangled with the device UID — a per-device key fused into the SoC at fabrication, generated inside the SEP, with no software, firmware, JTAG, or supplier read path — and the derivation runs inside the enclave at roughly 80 milliseconds per attempt.3 Because the UID never exists in a copyable form, the derivation cannot be taken off the device: offline brute force against an iPhone passcode is architecturally impossible, and on devices from late 2020 onward, on-device attempts are additionally bounded by counter lockboxes in the Secure Storage Component that erase the protected entropy after the attempt limit.4

What this means if the throttle falls

In the ordinary case neither number matters, because both platforms’ throttles hold: Titan M2’s Weaver delays and Apple’s SEP delays both make online guessing infeasible. The divergence appears only in the failure case.

  • If the Pixel’s secure element is compromised, the Weaver secret is a stored value that can be read. An attacker who extracts it removes the throttle from the equation and is left grinding scrypt at ~25 ms and 2 MiB per guess — cheap to parallelize, and weakly memory-hard by modern standards (the derivation is a decade-old calibration; GrapheneOS’s own roadmap notes Argon2 as the likely future replacement “when the available implementations are more mature”). A 6-digit PIN then falls in minutes to hours; only user-chosen passphrase entropy provides real protection.
  • If the iPhone’s SEP is compromised, there is no equivalent secret to extract. Brute force remains pinned to the enclave, at the enclave’s pace, against the counter lockbox.
  • Boot-chain compromise, the realized case on legacy iPhones, is weaker. checkm8 gives permanent boot-level code execution on iPhones through the X (A11 and earlier) without touching the SEP, so it changes nothing above: passcode guessing stays on the enclave at the enclave’s pace, which is why checkm8-based forensic extraction still needs the passcode for a full dump. Only pre-SEP 32-bit devices (iPhone 5c and earlier) lose the throttle entirely to a bootrom exploit.

Quarkslab demonstrated that the Android failure case is not hypothetical on the original Titan M: CVE-2022-20233, a one-byte out-of-bounds write in the Keymaster task, gave them code execution on the chip and an arbitrary memory read, with which they exfiltrated StrongBox-protected keys — “the highest level of protection of the Android Keystore.”5 Their later deep dive confirms they also extracted Weaver slots: “Weaver keys and values are stored in the flash and accessible via such a read primitive,” and the team “managed to obtain it without too many difficulties.”6 That is the full offline-attack precondition demonstrated end to end on shipping silicon.

Samsung flagships land on the Android side of this analysis: Samsung Weaver runs on the Knox Vault Processor with the same release-on-correct-key design and the same scrypt pre-stretch, so a Knox Vault compromise opens the same offline regime. On Samsung the failure case is not merely theoretical in the way it currently is on Titan M2: Cellebrite advertises BFU extraction for the Galaxy S24 series on both chipsets, and Osservatorio Nessuno’s matrix analysis notes that a TEE exploit against these devices yields offline brute force against any numeric PIN shorter than ten digits.

Three calibrations the claim needs

The exploit was on Titan M, not Titan M2. Quarkslab’s work (2021–2022) targeted the Pixel 3-era chip. Titan M2 is a redesign with independent lab validation against glitching and laser fault injection, and no public code-execution exploit exists against it. Cellebrite’s leaked matrices list Titan M2 brute force as unsupported. The demonstrated extraction proves the structural property — Titan M secrets exist in extractable form — not that current Pixels are practically extractable.

The Weaver secret alone is not sufficient. The synthetic password is additionally wrapped by SoC hardware-bound key derivation using a hard-wired key inaccessible to software and firmware, and the offline attacker must also defeat the Keystore layer that is bound to verified-boot state. A complete offline attack therefore needs both the Titan M secret and the SoC hardware key, the latter requiring an expensive silicon-level attack. The accurate statement is that Android’s design permits an offline regime because its throttle secret is stored and released, while Apple’s precludes one because its derivation key is fused and never released — a difference in what must go wrong, not a one-step attack.

The attack required application-processor root first. Quarkslab’s path runs SPI commands from a rooted AP (or direct bus access). That is an after-first-unlock, already-compromised scenario, which is precisely why BFU-state devices remain safe against this class: the exploit chain to reach the chip has to get through the OS first, and on GrapheneOS that is the layer no forensic vendor has publicly broken.

The third difference: key eviction on lock

Even short of any offline attack, the platforms differ in what the locked-AFU state exposes. Apple’s Data Protection discards the Complete Protection class key about ten seconds after the device locks (when a passcode is required immediately), making that class of data cryptographically inaccessible regardless of what an exploit can do.7 Android FBE has only two coarse states: CE keys are derived at first unlock and cached as wrapped keys in the kernel keyring for the entire session until reboot. There is no evict-on-lock class.

GrapheneOS’s answers are the configurable auto-reboot (returning the whole device to BFU) and per-profile end-session, which purges a secondary profile’s keys and puts it back at rest. The first is coarser than Apple’s design and leaves the phone-in-hand window exposed; the second is actually finer-grained than anything iOS offers, but only for data placed in secondary profiles — the owner profile cannot be put at rest without a reboot. A user who keeps sensitive material in a dedicated GrapheneOS profile they end when idle gets a stronger locked-state posture than either stock platform; a user who lives in the owner profile gets a weaker one than an iPhone’s.

Google’s underinvestment, not Android’s ceiling

None of these three weaknesses is forced by the ecosystem. Android already branches its implementation on whether a secure element is present, so a Pixel-specific stronger path fits the existing code shape. The Titan M2 is Google’s own silicon, FBE is Google’s own software, and the 25 ms scrypt calibration dates from an era of much weaker phones. AOSP’s documentation admits the stretching step “usually does not provide much security” — the platform knows the floor is thin and relies on the throttle instead. That a security-marketed flagship line keeps the commodity design is a choice about engineering allocation, not a technical inevitability, and it is a choice GrapheneOS cannot unmake from userspace: closing the gap properly requires changes in the Titan M2’s firmware and Google’s FBE design. What GrapheneOS can and does do is compensate: a faster-ramping Weaver throttle than stock, auto-reboot, profile end-session, long-passphrase support, and the standing recommendation of at least six random digits.

Where this leaves the comparison

These weaknesses are ceilings, not the floor. Against the tools that exist today — the Cellebrite matrices analyzed in Cellebrite — a properly configured GrapheneOS Pixel remains the strongest documented consumer platform, because reaching its offline regime requires defeating a secure element no forensic vendor has publicly defeated, and its mitigation layer has so far prevented that. The forward-looking risk is that the mitigation layer is exactly what AI-assisted vulnerability discovery (see Does AI-assisted vulnerability discovery erode mitigation-based security) makes cheaper to defeat, while the cryptographic floor is the layer such capabilities cannot touch. That asymmetry is what elevates a theoretical design difference into a strategic one.

  1. File-based encryption, AOSP documentation. ↩

  2. Weaver HAL, AOSP documentation. ↩

  3. Passcodes and passwords, Apple Platform Security. ↩

  4. The Secure Enclave, Apple Platform Security. ↩

  5. Attacking Titan M with Only One Byte, Quarkslab, August 2022. ↩

  6. Android Data Encryption in depth, Quarkslab, 2023. ↩

  7. Data Protection classes, Apple Platform Security. ↩

Built on 11 sources (11 external).

Working out connections…