[dm-crypt] SSDs & flash... and secure keyslot erase

* [dm-crypt] SSDs & flash... and secure keyslot erase
@ 2012-08-24 15:06 Milan Broz
  2012-08-24 15:23 ` Thomas Bächler
  2012-08-24 15:46 ` Arno Wagner
  0 siblings, 2 replies; 8+ messages in thread
From: Milan Broz @ 2012-08-24 15:06 UTC (permalink / raw)
  To: dm-crypt

SSDs & flash... and "secure" keyslot wiping

The storage devices are usually constructed with reliability vs cost in mind.

In LUKS we have problem of safe deletion of old key material (keyslot).
In short, on keyslot change we need delete old key material or at least
make them unusable. How this can be achieved depends on storage used...

1) Rotational devices, aka classical disks

Rotational drive today has processor which boots firmware which is "smart"
in sector/track management functions.

It surely reallocates sectors. The disk lies where it really stores data, in fact
even with rotational disk you have no idea what exactly happens.

If data is written to media, disk re-reads them and if any problem appears,
the area is marked bad and sector is written to some other area
(disk still have correct data in memory).

So even initial LUKS format can create some data copies.
Wiping data area several times is perhaps just snake oil medicine
but should not hurt here.

We can just hope that reallocated area is not the whole keyslot and LUKS
AF helps. Can we trust that this happens on all drives? I guess no.

We can use some "secure erase" functions... which can brick the whole drive.

And analyzing directly magnetic media (hidden tracks etc) is not easy, but possible.

Also there are often also management interfaces which allows access some internal drive
parameters without really opening the drive...
(Nice talk here https://events.ccc.de/congress/2010/Fahrplan/events/4231.en.html )

2) Cheap USB flash disk
Flash disk uses just different (slower) chips than SSDs but in principle it has
the same problems.

But USB disks are cheap, thus no powerful processors which run garbage collector
in the background (it cannot run some long-time processes - it is hotplug device).

Often you can open the device and see some standard controller chip there,
there are tools to reprogram parameters of these controllers.
(Anyone bought 32GB pendrive on eBay which had only 2GB chip and just
faked device size?)

Also TRIM/discard and secure discard is usually not supported here.

Rewriting LUKS keyslot many times definitely makes no sense here.
So for non-rotational device it will just try to wipe it once with random data.

(Non rotational device attribute is set by kernel driver per device.)

3) SSDs
Almost all SSDs contain powerful processor which run quite complex sw and manages
the whole disk, including many features (internal encryption etc).

You can hardly say what happens after IO is submitted.
It can return that discards is done but in reality it is just queued
and will be run later.
It can run garbage-collection process and re-arrange internal data layout
through idle time.

The SSDs firmware are buggy, a lot of drives have still stability problems and
performance problems after longer period of use. It is new technology though
and it is getting better.

For now LUKS keyslot deletion is the same as 2) but there is "secure discard"
in Linux supported already which should guarantee that data (and all its copies
inside the drive) is wiped (zeroed).

Next release of cryptsetup will try to run this erase on non-rotatinal disks
for keyslots. (But most of drives do not support it yet anyway.)

But even (non secure) discard of keyslot area (after data rewrite try)  can have some
value - at least it increases chance drive will really wipe it because it now knows
the area is not used anymore.

(Discard is write operation which instead of writing data says "this area is unused now".)

Also the situation is complicated if image is not disk, but file in filesystem or there
are more device layers (sw RAID, thin provisioning).
For disk image, we can try to use "punch hole" mechanism.

But there is no perfect solution.

m.

It is trivial to detect e.g. LUKS keyslot update according to data access pattern
("copy last write IO if following write is 4k write and data starts with LUKS in ascii")

And hacking hw firmware is not so sci-fi as it appears to be sometimes...
So to add more paranoia, targeted attack can be really fun here :)

^ permalink raw reply	[flat|nested] 8+ messages in thread