Data recovery (was: Re: SETI at home (ca. 2000) servers heading to salvage)

[Warner Losh]

That's what a sanitize operation does. It forgets the key and reformats the
metadata with a new key.

Also, with SSDs, any erase block that's erased is going to not have any
data that's recoverable.
First, the erase voltage is huge, moving the cell to a negative
voltage (the only abode that's
negative is all 1's). Next, the microprocessor in the NAND dies are going
to 'pre-program' the
abodes to a uniform negative voltage that's easier to program when you
start putting data on
the ages. Finally, most (nearly all) NAND dies have randomization circuitry
that randomizes the
data after you send it to the drive (or whitens it) that you'll need the
psuedorandom seed to read
it back coherently.

The problem, though, comes with erase blocks that have broken and no longer
erase. These
retired blocks can contain data still, but given the
randomization/whitening and/or some
global encryption key, the data can be difficult or impossible to
meaningfully recover, even
when other pathologies don't degrade the block more (not least is aging: if
the block was
retired a long time ago, the NAND cells, being tiny capacitors, will bleed
the charge off to
the erased state +/-).

As with most forms of data destruction, putting a metal spike through the
NAND dies
themselves would likely suffice :) But it is a tad destructive....

Warner

On Mon, Apr 4, 2022 at 8:34 AM Chris Zach via cctalk <cctalk at classiccmp.org>
wrote:

> Good data Paul! SSD's are a different beast, if you're going to put data
> on them that you do not want recovered I would recommend encrypting the
> drive before using it, then when done delete/destroy the key. That
> should turn your drive into a useless (but format-able) chunk of silicon.
>
> C
>
> On 4/4/2022 8:28 AM, Paul Koning via cctalk wrote:
> > SSDs are a different story entirely because there you don't write over
> the actual data; instead a write updates internal metadata saying where the
> most recent version of block number xyz lives.  So, given that you tend to
> have a fair amount (10 or 20 percent if not more) of "spare space" in the
> SSD, previous data are likely to be hanging around.  I suspect if you write
> long enough you could traverse all that, but how to do that depends on the
> internals of the firmware.  That's likely to be confidential and may not
> even be reliably known.
> >
> > There are SSD SEDs.  If designed correctly those would give you
> cryptographically strong security and "instant erase".  Not all disk
> designers know how to do these designs correctly.  If I needed an SED (of
> any kind) I'd insist on a detailed disclosure of its keying and key
> management.  Prying that out of manyfacturers is hard.  I've done it, but
> it may be that my employer's name and unit volume was a factor.
>