12

One day, while Alice is downloading some photos from Bobs server, the alarm goes off. Trudy came to steal all the data.

Fortunately, the server is setup to shutdown upon server room alarm and has full disk exncryption. Unfortunately, the shutdown is happening rather slowly because the server is busy with Alice. Whats worse, Trudy brought some liquid nitrogen.

Now Trudy is back in the lab and extracts the encryption keys from the stolen servers RAM. Soon Trudy will know about Alice and Bobs secret activities.

Q: Cryptsetup is not meant to close the device containing system root. Are there other solutions which, faster than just echo b > /proc/sysrq-trigger increase cost of forensic efforts on a linux system?

EDIT: Yes, this question is intentionally limited to assuming a finite preparation time and implementation details involved in managing LUKS containers via cryptsetup- other, more general questions exist.

Improve this question
1
  • 2
    if your server were shaped like say, a tablet in a lock box, it would be practically difficult to quickly remove mobo power and freeze the soldered-on ram...
    – dandavis
    Jun 13, 2016 at 9:06

2 Answers 2

Reset to default
10

Wiping the LUKS header would make the data completely irrecoverable, even if the password/encryption key is later discovered, since the passwords/keys used by LUKS merely encrypt a master key stored in the header and that master key actually encrypts the data.

So first, deleting the first 2MBs of the device where the LUKS volume resides should make further decryption impossble even if the password is later obtained (through rubberhose cryptanalysis for example). Make sure to overwrite the header synchronously so that the writes don't end up buffered and discarded because you then restart the computer without waiting for the buffers to be flushed.

Then, the RAM must be wiped. Shutting down the computer is one possibility but the data may remain in the RAM long enough for someone to soak it in liquid nitrogen and further extend the data remanence period. Another approach which is used by Tails is to erase the RAM from software by kexec'ing a special kernel that overwrites the RAM. That should defeat the cold boot attack.

Improve this answer
6
  • Securely erasing 2mb doesn't seem particularly quick. Do you know how fast this would be? How would you even accomplish this? Would you need to modify the device driver? Unmount the drive and then do something?
    – Neil Smithline
    Jun 13, 2016 at 0:45
  • 2
    @NeilSmithline securely erasing 2mb is actually quite quick. The real question is whether it is actually erased. On a conventional HDD I would be confident after a few overwrites it is gone for good. On an SSD on the other hand I'm not so sure given the wear-leveling algorithms in them. No driver modification necessary, you simply use dd on the drive device node. No unmounting needed either as in an emergency we don't really care if all buffers get flushed.
    – André Borie
    Jun 13, 2016 at 0:57
  • keeping the SSD almost full in general and then deleting the small secret, refilling with trash, deleting some trash, and once more refilling with new trash should make recovery very very difficult (read expensive). also, superglue or solder is a cheap defence to the old freezer trick, buying critical time.
    – dandavis
    Jun 13, 2016 at 9:02
  • 2
    @AndréBorie, when we are talking about magnetic hard disks, overwriting the header once should be sufficient. There isn't scientific evidence that it is possible (on a modern magnetic disk drive) to read out the previous content of a disk block after it was overwritten once.
    – maxschlepzig
    Dec 18, 2017 at 13:26
  • @dandavis: That doesn't work on SSD as an SSD is practically always over provisioned. A 100 GB SSD may actually contain enough physical memory cells to contain 128 GB of data. Filling the SSD to 100 GB, the device will start complaining that it's full, but when you overwrite the header, your overwrite will actually be remapped to one of the 28 GB of spare space with the original data left out in hidden memory cells.
    – Lie Ryan
    Aug 22, 2019 at 13:19
4

There are two ways to approach this, depending on just how inaccessible you want to make the data.

If you simply want to require knowledge of the LUKS passphrase to regain access to the data (more or less the normal case, but expediated), then you can use cryptsetup luksSuspend on the dm-crypt device name. According to the man page, this:

Suspends an active device (all IO operations will blocked and accesses to the device will wait indefinitely) and wipes the encryption key from kernel memory.

To recover from a luksSuspend, do a luksResume.

NOTE: The below assumes the LUKS 1 format. The newer LUKS 2 format is different.

If you want to ensure that Trudy cannot gain access to the data, then you need something more drastic. In the easy case, we assume that Trudy does not have a LUKS header backup, in which case overwriting the LUKS header is sufficient. You can either overwrite exactly the header and nothing else (the size of the header is "payload offset" (as reported by cryptsetup luksDump) times 512 bytes, and it starts right at the beginning of the device), or you can play it safe and overwrite some more. Overwriting the first 100 MB of a rotational HDD will take somewhere around 1-3 seconds, depending mainly on the rotational speed of the drive (7200 rpm drives tend to be able to attain 100-120 MB/s, with slower drives obviously being slower):

WARNING: DO NOT DO THIS UNLESS YOU KNOW YOU WANT TO

dd if=/dev/urandom of=/dev/sdb1 bs=1M count=100 conv=sync

WARNING: DANGEROUS COMMAND ABOVE

After overwriting the header, make sure to wipe the key from kernel memory to ensure that the remaining data cannot be decrypted. This is as simple as cryptsetup luksSuspend dm-name or cryptsetup remove dm-name. After doing that, the container contains only random-looking data which (short of breaking the encryption algorithm used) cannot be decrypted. The output of any good encryption algorithm, absent the decryption key, will be statistically indistinguishable from random noise.

In the latter case, if you really want to make Trudy's life difficult, you can then issue a ATA Secure Erase to the underlying storage device. Assuming Secure Erase is implemented properly on the drive, once it finishes (which can take several hours on non-self-encrypting rotational HDDs, but normally cannot be interrupted once started), no previously stored data will be accessible. For most threat models, though, that is likely to be overkill; overwriting the LUKS header and clearing the key in RAM will almost certainly be sufficient to prevent access to the data by any reasonable adversary. The Secure Erase may however be needed to ensure that there are no remnants of key material on a SSD, due to wear leveling.

Improve this answer
3
  • ATA secure erase on modern drives are often implemented using hardware encryption, this means that the drive would simply forget the encryption key and the erase would be done in seconds, but the memory blocks aren't actually erased. Which brings us back to square zero.
    – Lie Ryan
    Aug 22, 2019 at 13:24
  • Why are you suggesting to overwrite 100 MiB? The header is 2 MiB.
    – forest
    Aug 23, 2019 at 1:19
  • @LieRyan By memory blocks, are you talking about kernel memory or drive cache?
    – forest
    Aug 23, 2019 at 1:21

You must log in to answer this question.