Mustafa ERBAY

Posted on Oct 16 Originally published at mustafaerbay.com.tr

If Encryption Came Later, a Factory Reset Isn't Enough

#security #mahremiyet #cihaz #macos

While trying to rescue a decommissioned tablet for a child, after exhausting all
the clever routes, it came back to the most ordinary option on the list: the
"erase everything" line in the recovery menu. It worked — the corporate windows
that had been flooding the screen went quiet. But the sentence noted
at the end of that evening
was this: the factory reset and the ROM reinstall had silenced the apps, and
the files were still there. The permanent fix only came from removing them from the filesystem.

That sentence stuck, because it marks the gap between "erased" and "gone." When
we hand a device to someone, sell it, or throw it out, we all lean on one single
gesture: reset to factory settings. So what exactly does that gesture take away?

One afternoon that question got taken seriously. What turned up while chasing the
answer was a surprise: NIST and Apple, independently of each other, write down
the same condition. And that condition almost never comes up in everyday life.

Three words: Clear, Purge, Destroy

There is a vocabulary for this work, and it is sharper than the words we use.
NIST's media sanitization guide (SP 800-88 Rev. 1) defines three levels:

Clear — logical techniques that protect "against simple non-invasive data recovery techniques," typically applied through the device's standard read and write commands.
Purge — physical or logical techniques that render target data recovery "infeasible using state of the art laboratory techniques."
Destroy — the same assurance, but it also leaves the media unusable for storing data afterwards.

Now look closely: the definition of Clear explicitly names one of the ways it can
be applied — "using a menu option to reset the device to the factory state (where
rewriting is not supported)."

So the gesture we assume settles everything sits at the lowest level of the
guide's classification. For a home user it is often enough, yes. But "enough" and
"unrecoverable" are not the same sentence, and the difference depends entirely on
who is willing to do the work.

The guide is generous about its audience, by the way: it states that protecting
the confidentiality of information should be a concern "for everyone, from
federal agencies and businesses to home users." This document is not only for institutions.

Destroying the key: the shortcut itself

Modern devices have a trick that makes erasing fast, and it has a name:
Cryptographic Erase (CE). NIST's definition is precise — it sanitizes the
target data by sanitizing that data's encryption key, leaving only ciphertext on
the media and preventing read access.

The appeal is speed. In the guide's own words, CE can typically be executed "in a
fraction of a second." Instead of filling terabytes with zeros, you destroy a key
a few hundred bits long; what remains behind is ciphertext with no key.

Apple builds the same mechanism for the same reason. In its platform security
guide, one of the four goals of the FileVault key hierarchy is written out
exactly like this: to "provide a swift and secure method for wiping content via
deletion of necessary cryptographic material."

So if "Erase All Content and Settings" on your phone finishes in a couple of
minutes, that isn't the job being skimped. Destroying the key is the whole job.

The condition everyone skips

So far the story is reassuring. Now for the condition.

NIST lists, under its own heading, when you should not use CE, and the first
item is this: do not use CE to purge media if the encryption was enabled after
sensitive data was stored on the device without having been sanitized first. The
second item is broader still: do not use it if it is unknown whether sensitive
data was stored on the device, without being sanitized, prior to encryption.

Once you see the logic you can't unsee it. Destroying the key only takes away
what was written with that key. A file written to the disk in the clear before
encryption was turned on, then deleted, sits outside the key hierarchy —
destroying the key does nothing to it.

The second source confirming this is the manufacturer itself. On Apple's FileVault
page, the same idea appears in almost the same sentence: after FileVault is turned
on, all existing files and any further data written are encrypted; data that was
added and then deleted before turning on FileVault isn't encrypted and may be
recoverable with forensic data recovery tools.

Two independent primary sources, a standards body and a vendor, describing the
same trap. A warning that overlapping is hard to ignore.

What the state of my own devices is

A question stays useless while it stays abstract. So here is the machine in front
of me.

$ fdesetup status
FileVault is On.

One line, reassuring. But volume by volume the picture gets more detailed:

$ diskutil apfs list        # abridged to the relevant lines
   APFS Volume Disk (Role):   disk3s1 (System)
   FileVault:                 Yes (Unlocked)
   Encrypted:                 No
   APFS Volume Disk (Role):   disk3s5 (Data)
   FileVault:                 Yes (Unlocked)
   APFS Volume Disk (Role):   disk3s6 (VM)
   FileVault:                 No

At first glance it looks inconsistent: the system volume says both "FileVault:
Yes" and "Encrypted: No," while the virtual memory volume flatly says "No."
Before panicking, go to the documentation — and the documentation explains it: in
macOS 11 or later the system volume is protected by the signed system volume
(SSV) feature, while the data volume remains protected by encryption. The system
volume looks that way not because it is unprotected, but because it was handed to
a different mechanism. Personal data lives on the Data volume, and that one is
covered.

Now the real question: is this machine inside the trap? That is, was encryption
turned on later?

This output alone doesn't answer that — but a few paragraphs further down the same
Apple page does, and reading the answer shows the question is the wrong one for
this machine. The document first states the base rule: all APFS volumes are
created with a volume encryption key by default, and volume and metadata
contents are encrypted with that key. What FileVault adds is binding the key that
wraps it to the user's password and the hardware ID.

What follows closes the question outright: on a Mac with Apple silicon or a T2
chip, if FileVault wasn't turned on during initial setup, the volume is still
encrypted — the key is simply protected by the hardware UID in the Secure
Enclave alone. And when FileVault is turned on later, the document calls it "a
process that's immediate because the data has already been encrypted."

So on machines in this class, when encryption was turned on is beside the
point. The data was encrypted from day one; even if FileVault arrived later, there
is no plaintext written before it. That is also why Apple scopes its warning to
three cases: Macs from before the T2 chip, internal storage that didn't originally
ship with the Mac, and attached external storage. All three are situations
that don't benefit from the Secure Enclave's encryption at the base — the document
says so separately for removable storage.

The lesson here is broader than my machine being clean: what decides whether the
trap applies isn't your habits, it's whether the device does encryption in the
hardware foundation or as a layer bolted on afterwards.

That is good news here, but it is also the point of this piece: the trap isn't
in your modern laptop, it's in everything else you own.

Where things go well on a phone

Having set the condition, the good news deserves airtime too, because some devices
satisfy that condition from birth.

In NIST's mobile device table, iPhone and iPad sit somewhere interesting: the
"Erase All Content and Settings" option is listed under both Clear and Purge.
The same menu item can satisfy the guide's lowest level and its highest practical
level. The reason is in the parentheses: the operation takes only minutes because
Cryptographic Erase is supported — "this assumes that encryption is on and that
all data has been encrypted."

That assumption is not satisfied by accident. The note in the same table is
explicit: current iPhones have hardware encryption, turned on by default.
Because encryption was there before the first byte of data, destroying the key
really does cover everything. On a device that meets the condition, the shortcut
is legitimate.

A currency note belongs here. The guide is from 2014 and gives the menu path as
"Settings > General > Reset > Erase All Content and Settings." That path has since
moved: Apple's own hand-off page says Settings > General > Transfer or Reset
[device] > Erase All Content and Settings. The mechanism stayed, the menu moved
— a decent reminder to check the publication date when reading standards.

A remote wipe is not the same thing

There is one more distinction, and it concerns the button that is our only hope
when a device goes missing. The guide says, in that same table, that sanitization
performed via a remote wipe should be treated as a Clear operation, and that
it is not possible to verify the results.

Which makes sense: you send the command, but you cannot see that the device
received it, completed it, or behaved as expected. An erase you perform with the
device in your hand and an erase you send to a lost device do not carry the same
assurance. When handing a device over, do it by hand; remote wipe is the best
thing available for a device you've lost, and being the best available does not
make it sufficient.

Sign the account out before you hand it over

Finally, a step that is less about data security and more about the other
person's day. Apple's hand-off page walks through signing out of the Apple
Account and removing the device from your trusted devices list, in order, before
erasing. Google's reset document opens from the same place: before resetting, make
sure you know the username and password of the Google Account on the phone,
because that information can be requested after the reset.

The reason on both sides is theft deterrence. But the side effect is this: a
device handed over without signing out can turn into a brick the new owner cannot
open.

Where the risk actually sits

Look at this list from inside your own home:

Old Android devices. The tablet from the opening is exactly this class. The
the factory reset — together with reinstalling the official ROM — silenced the
corporate apps while leaving the files in place; they had to be removed by hand. When encryption was turned on for that tablet — or
whether it ever was — is unknown to me, and the guide's second item is written for
exactly this case: if it is unknown whether sensitive data was stored, without
being sanitized, before encryption, don't treat destroying the key as assurance. "I reset it" does not
close that gap.

That "I deleted it but it stayed" feeling isn't unique to letting a device go, by
the way; the same gap
shows up when you
uninstall apps on a machine you're still using. Those leftovers sit in your home
directory; these sit on the media itself.

USB sticks and memory cards. No encryption layer on top, and usually no
"secure erase" command either. The only honest options here are to use them
encrypted from the start, or to destroy them. NIST's own note points the same way:
if a device has removable storage, first check for encryption and decrypt if so,
then remove that storage before sanitization.

External drives. The third item on Apple's list is precisely these. That backup
drive that has been sitting on your desk for years — do you remember when you
turned FileVault on for it?

Routers, printers, smart home devices. We don't think of any of them as "a
device that stores data," yet Wi-Fi passwords, email credentials and scanned
documents live in there. It is no accident that NIST's appendix has a separate
table for networking devices.

Here is what strikes me: nothing on that list is expensive or new. The devices
carrying the risk are exactly the ones we don't care about — the ones we let go of
with a shrug, saying they were old anyway.

Why "I'll write zeros over it" falls short

The old reflex says: fill the disk with zeros and you're done. On spinning disks
that was a reasonable approach. On flash it is not.

In NIST's table for flash-based storage, the note beside the Clear method says
that overwriting flash-based media may significantly reduce the effective lifetime
of the media and may not sanitize the data in unmapped physical media — that
is, the old data may still remain.

The cause is how an SSD works inside. The address space you see does not map
one-to-one onto physical cells; the controller spreads writes across cells and
keeps spare areas the user never sees. While you are saying "I wrote zeros
everywhere," old content can survive in blocks one layer down that you cannot
reach.

That is why the guide recommends, at Purge level for flash, not overwriting but
the device's own commands: the ATA sanitize command, block erase, or cryptographic
erase where the device supports it. Translated into practice: make the drive's
controller do the work, rather than doing it from outside by writing files.

A practical frame before letting go

To avoid reasoning this through from scratch for every device, four questions, in
order:

What is on this device? NIST's whole decision flow starts here: determine the confidentiality of the information first, then pick a method based on the media type. An e-reader holds what it holds; a phone holds your life.
Was encryption on from the start? If the answer is yes, a factory reset genuinely destroys the key. If it's "I don't know" — and on most older devices that is the answer — the guide's rule says don't treat this path as assurance.
Does the device have its own secure erase command? Phones and modern Macs do. USB sticks, memory cards and very old tablets do not.
If not, what's left? Either don't let the device go, or physically destroy the media. Don't invent a third option.

On the Mac side, the answer to the third question may be worth spelling out: Macs
with Apple silicon or a T2 chip have the exact counterpart of the phone's feature.
From the same menu — System Settings > General > Transfer or Reset > Erase All
Content and Settings — all data, settings and apps are erased while the operating
system stays in place.

And what if your answer came back as "encryption was turned on later"? The first
fix that comes to mind is: encrypt now, then reset. That covers the files you
currently have, but not the thing Apple's warning points at — remnants written
and then deleted before encryption, sitting in free space, never enter the key
hierarchy at all. So the move improves the situation without providing assurance.
At that point the remaining route is the one the guide writes down: the device's
own Purge command, and failing that, destruction.

Before you erase, and after

The notes in the guide's mobile device table are shorter than the technical
sections and at least as useful. Two of them:

Back up first. "Before sanitizing the device, ensure that the data is backed
up to a safe place." That sentence can look odd in a security guide, but it
belongs: a photo archive lost in the rush of handing a device over is a more
frequent disaster than leaked data.

Then verify by eye. After the Clear or Purge operation, manually navigate
around the device — browser history, files, photos — and confirm that no personal
information has been retained.

The second one feels especially valuable, because it suggests setting the theory
aside and looking at the result. That five-minute check will save more people than
the entire vocabulary above. It is also what worked on the tablet at the start:
looking at what remained on the device rather than at what the screen claimed.

As for the third level, Destroy, the guide describes that too: shred,
disintegrate, pulverize, or incinerate in a licensed facility. For a home user
this is less extreme than it sounds; physically breaking a memory card really is
the most certain route. But there is an honest tension here: you are choosing
between generating e-waste and accepting data risk. The right trade, to me,
depends on the class of device — destroying a working tablet is waste, while
keeping a five-lira memory card is needless risk. That the tablet could be made
usable again is exactly why it was worth the effort.

What's left

This piece started with a tablet and a sentence: the factory reset and the ROM
reinstall had silenced the apps, and the files were still there. Going to the sources, that sentence
turned out to be no accident — in the standard's vocabulary, that operation is
already defined as the weakest level.

What kept me thinking is this. The "erase" button is presented to us as an
action, when underneath it there is a condition: did the key come before
the data? If the condition holds, the button really is powerful. If it doesn't,
the button looks identical, takes the same amount of time, shows the same
confirmation screen, and does far less. The interface does not distinguish between
the two.

That is also what showed up while going through my own devices: the laptop that
got measured sits on the safe side, because encryption comes built into its
hardware from day one — and the guide's note points the same way for phones. The
risk has been piling up where I never paid attention, and those places never got
measured at all: USB sticks in a drawer, the old external drive on a shelf, the
tablet handed to a child. The attention needs to move from protecting the
expensive thing to the things I forgot.

The question for the next device I hand to someone is no longer "did I erase it?"
It is "when was encryption turned on?"

DEV Community