[Thread] How iPhone security degrades following a user's first device unlock after powering it on, leaving it more vulnerable to data exfiltration
or you need the user to have entered it. 4/ Matthew Green / @matthew_d_green : When you first unlock your iPhone after power-on, it uses your passcode to derive several sets of cryptographic keys. These stay in memory inside your phone, and are used to encrypt the file system. 9/ Matthew Green / @matthew_d_green : So the upshot of this is that, if police can capture your phone in the AFU state (yours is almost certainly in that state for 99% of its existence) *and* they have a software exploit that allows them to bypass the OS security measures, they can get most of the files. 12/ Matthew Green / @matthew_d_green : The boring answer very likely is that police *aren't* guessing suspects' passcodes. They're relying on the fact that the owner probably typed it in. Not *after* the phone is seized, in most cases. Beforehand. 7/ Alex Stamos / @alexstamos : Great work by Matt and team to figure out the current state of phone encryption, which turns out to be not so great thanks to a variety of product compromises. It's unfortunate that Apple and Google aren't more transparent about their threat models and implementations here. https://twitter.com/...
@matthew_d_greenMatthew Green
Context & Ripple Effects
Matthew Green's thread explains the mechanics behind a debate that dates back to the FBI era: once a user enters the passcode, the phone derives cryptographic keys that stay resident in memory, so the device spends nearly all of its life in the after-first-unlock state where a software exploit can reach most files without the passcode at all. That is why forensic methods — from the NAND-mirroring approaches discussed in 2016 to modern exploit chains — target the AFU window rather than brute-forcing the lock screen.
The thread also frames Apple's later consumer-facing fixes: the Stolen Device Protection beta responds to the physical-theft wave where attackers watch victims type their passcodes before stealing the phone, but Green's point is that passcode knowledge plus an exploit defeats the file system regardless of who holds the device.
First-order effects
For law enforcement and forensic vendors holding a software exploit, an iPhone captured in the AFU state yields most of the file system without needing the user's passcode — the practical protection window is only the brief before-first-unlock period after power-on.
For iPhone owners, the effective security boundary is the passcode-derived keys in memory, meaning a stolen or seized phone is far more exposed than the lock screen suggests.
Second-order effects
Apple faces pressure to shrink the AFU exposure itself — key purging, faster lockdown behaviors, and location-aware features like Stolen Device Protection — rather than only hardening the passcode entry path.
The gap Green describes keeps the comparison alive with Google, whose Android file-based encryption has been characterized as years behind iOS on lock-screen security; any iOS softening narrows that differentiation.
Third-order effects
If the pattern holds, mobile security converges on a threat model that assumes device capture plus exploit capability, pushing vendors toward minimizing in-memory key lifetimes and toward greater public transparency about what each unlock state protects — the transparency gap Alex Stamos has criticized in both Apple's and Google's encryption implementations.
The durable split is between data protected only while the device is untouched since boot and data protected at rest, and exploit markets will keep pricing that difference for police and thieves alike.
The trend: Smartphone encryption's real-world strength is set by which unlock state the device is captured in, pushing Apple and Google to shrink the window where passcode-derived keys live in memory.
This was prompted by a claim from someone knowledgeable, who claimed that forensics companies no longer had the ability to break the Apple Secure Enclave Processor, which would make it very hard to crack the password of a locked, recent iPhone. 2/
Read this whole thread, and remind people that when the DOJ, FBI, police, and random prosecutors whine about “going dark” because of encryption, and how they need magic keys, they're *lying* https://twitter.com/...
@fluffypony @phzix The second experiment is real BFU. You don't see the contact name because rebooting the phone wipes out the keys that encrypt your Contacts database, so your phone can only show you a phone number and not the person's name. Not great, Apple.
@occupy_eip @matthew_d_green It's not well-documented anywhere. Theoretically you could do some deep memory inspection to find out but we need more info on this from Apple
@matthew_d_green @maxzks In terms of AFU and BFU, do you know what the method here does in terms of encryption keys in memory? Do all the keys get evicted, or just some? https://www.phonearena.com/...
@fluffypony @phzix Second experiment: 1. Fully power down your phone and reboot. Don't enter password. 2. Have the same contact send you a text. Expected result: you'll see only a phone number, not the contact name.
Here is a version of the same text from back in 2012. Notice how it explicitly states that “Mail, App Launch images, and Location Data” are protected using the strongest type of encryption. So it seems that Apple is actually protecting *less* data now than in 2012. Yikes. 16/ htt…
This is a fascinating thread, great work @maxzks, Tushar, and @matthew_d_green. I draw two conclusions: 1/ phones are digital agents, they need to do stuff in the background, notify you, etc. We might need more advanced encryption primitives. 2/ developer defaults matter. https:/…
But whether you look at the 2012 or 2020 data, the situation sucks. The built-in apps that definitely use strong AFU protection are: Mail (which probably already exists on a server that police can subpoena, so who cares.) App launch data (🤷♂️) That's not great. 18/
You see, iPhones can be in one of two states, which are respectively known as “Before First Unlock” (BFU) and “After First Unlock” (AFU). This is pretty self-explanatory. When you turn your phone on and enter the passcode in the morning, you switch your phone from BFU->AFU. 8/
3rd party apps can opt-in to protect data using the strongest type of encryption, so this isn't necessarily the whole story. But let's list some data that *doesn't* get AFU protection: Photos Texts Notes Possibly some location data Most of what cops want. 19/
I'll focus on Apple here but Android is very similar. The top-level is that, to break encryption on an Apple phone you need to get the encryption keys. Since these are derived from the user's passcode, you either need to guess that — or you need the user to have entered it. 4/
When you first unlock your iPhone after power-on, it uses your passcode to derive several sets of cryptographic keys. These stay in memory inside your phone, and are used to encrypt the file system. 9/
So the upshot of this is that, if police can capture your phone in the AFU state (yours is almost certainly in that state for 99% of its existence) *and* they have a software exploit that allows them to bypass the OS security measures, they can get most of the files. 12/
The boring answer very likely is that police *aren't* guessing suspects' passcodes. They're relying on the fact that the owner probably typed it in. Not *after* the phone is seized, in most cases. Beforehand. 7/
Great work by Matt and team to figure out the current state of phone encryption, which turns out to be not so great thanks to a variety of product compromises. It's unfortunate that Apple and Google aren't more transparent about their threat models and implementations here. https…