[liberationtech] CryptoParty Handbook

[Andy Isaacson]

On Fri, Oct 05, 2012 at 05:43:46AM +0200, Maxim Kammerer wrote:
> Did anyone try this with devices that are supposed to be resistant to
> file shredding due to wear leveling? I tried the following on two USB
> keys, one ~12 years old, another ~6 years old, both formatted as
> FAT32:
> 
> echo test_string_123 > x
> for i in $(seq 20); do cat x x > x1; mv x1 x; done
> cp x /media/... && sync
> shred -u /media/... && sync
> cp /dev/sd... image
> LC_ALL=C grep -wc test_string_123 image
> 
> The result was 0 in both cases.

That's expected, because you're still going through the translation
layer.  If you had instead hooked up a microcontroller to the data pins
of the flash chips on the circuitboard, you'd find that much of the data
you'd written is still on the flash chips; it's simply in pages that
aren't referenced by the current FTL state.

Think of flash as a series of 6 whiteboards with 4 post-it notes
tracking which "page" of notes is which.  You start out writing to the
board with "1" on it; when you fill that up you go to "2", then "3",
then "4".  Since you only have 4 post-it notes (4GB of memory) but the
board with "1" on it is full of crud, you move the "1" post-it to a new
board and continue writing.  A gnome comes along and starts erasing the
old "1" board because it doesn't have a post-it.  Before the gnome
finishes erasing old-"1", you move "2" to a new whiteboard and keep
writing.

Now, what happened when you ran shred?  The 4 post-it notes (the FTL)
got moved to fresh boards, which got filled with random writing.  But
the original board with test_string_123 on it doesn't have a post-it
note and the gnome got tired, so the board isn't erased and there's no
way to read it (because you can only read boards with post-it notes).

In fact, one of the boards got used so much that its stand broke, and
the gnome wheeled it into the corner without erasing it.

Both of these gnome problems are real problems with FTL based systems;
erase blocks can wear out and fail to erase, and the background erase
process can fail to erase data as expected.

Neither problem is very likely for any particular write, nor for any
particular data, but just to be safe I always recommend using full-disk
encryption when using SSDs, and physically destroying any removable
flash-based media that have critically important data on them.  PGP can
be used to symmetrically encrypt data before putting it on an SD
card/USB drive, too.

-andy