2

Given the uncertainty about data being left in the clear, I've hesitated to use SSDs where I need full-disk encryption. While some SSDs employ hardware encryption, they're quite expensive, and there is inadequate transparency about implementation.

I've been wondering whether RAID6 arrays of SSDs could be encrypted securely using dm-crypt/LUKS. According to Wikipedia, RAID6 "uses block-level striping with two parity blocks distributed across all member disks". Although some data might be left in the clear on each of the member SSDs, it seems unlikely that those remains could be properly assembled and decrypted. Is that a plausible assumption?

Edit: I would be encrypting the RAID6 volume, containing everything except boot, using dm-crypt/LUKS. The encrypted RAID6 volume is used for LVM2, with volumes for swap, / and home. A small (unencrypted) RAID6 volume contains boot.

Edit: In the cryptsetup FAQ, I see that the key problem with SSDs and dm-crypt/LUKS is that the SSD may move a sector holding key-slots and LUKS header to a pool of discarded sectors, and that these discarded sectors may remain indefinitely before erasure. That could moot disabling a compromised key-slot (passphrase) or making the entire volume unavailable by overwriting the LUKS header with random data.

However, there is apparently no risk of directly leaking encrypted data, because plaintext exists only in RAM. Only encrypted sectors would be discarded (except for key-slots and LUKS header, which obviously are not encrypted).

Edit: Upon reflection, I'm almost back to the original question. Given that key-slots and LUKS header reside on the RAID6 volume, only a stripe of them could remain in discarded sectors on any one member disk. Unless that occurred consistently on N-2 members, which seems unlikely, nothing would be recoverable. Right?

  • why would there be data in the clear? – Lucas Kauffman Jan 20 '14 at 6:19
  • 1
    Data would only be left in the clear if the disks contained data before they were encrypted. This is an issue with the way SSDs manage redundancy and wear levelling. The solution is to start with a new disk and encrypt it before you put anything on it. – Ben Jan 20 '14 at 8:20
  • @Ben Thanks. I've seen that recommendation. However, I've read that it's no guarantee against leakage. I'll post some cites later today. – mirimir Jan 20 '14 at 8:39
  • @Ben I've edited the question instead. – mirimir Jan 20 '14 at 22:42
1

There is no security implemented in RAID6. From what I gather in your question you are suggesting that the arrangement of data across the disks might make it difficult to get meaningful data out, but not at all impossible. If it is a healthy array then it's entirely possible.

The main misconception about encryption on SSDs is that people believe it's impossible to achieve without 'data leakage'. This comes from the fact that, unlike on HDDs, the operating system cannot usually address sectors of the SSD directly for read/writes. This is because firmware on the SSD implements a wear-levelling algorithm which chooses where to really store data based on which flash blocks have or haven't been written to, in an attempt to spread writes to all the flash blocks as evenly as possible (thus prolonging your SSDs MTBF). This is performed regardless of where the OS requests it to go by way of LBA.

Ultimately this means if you choose to encrypt an SSD after it has already had data stored in plain-text on it, you as an outsider to the SSD firmware have no way of ensuring that data stored on the raw flash blocks don't have sensitive information. But if no plaintext data is ever written to the SSD, there can never be a leakage of sensitive information because the SSD never sees plaintext. Therefore it's irrelevant that the wear-levelling algorithm abstracts true data location information, because all the data is secured.

I believe other attacks on SSDs have been written about such as the ability to retrieve data from other VM guests in virtualised environments, but again if the VM container is employing full-disk encryption (FDE) then without the decryption keys other guests will only see garbage.

  • In the question, I specify that the RAID6 array would be encrypted using dm-crypt/LUKS. So I'm not saying that RAID6 per se provides any encryption. But just to be clear, I'll edit the question to specify more fully how the RAID6 array would be encrypted. – mirimir Jan 20 '14 at 21:41
  • Even if the SSD is encrypted before writing any data, I don't get how that would encrypt any of the reserve capacity. If the reserve capacity isn't available to the OS, how could the OS encrypt it? Consider this hypothetical. I encrypt the SSD before writing any data. Subsequently, while the SSD is decrypted, some of the reserve capacity replaces damaged areas. Because the SSD is decrypted, failed capacity might be taken out of service as plaintext. Because the out-of-service capacity is no longer available to the OS, it cannot subsequently be re-encrypted with the rest of the SSD. Right? – mirimir Jan 20 '14 at 21:54
  • I find that there is arguably no risk of directly leaking encrypted data, because plaintext exists only in RAM. However, if key-slots and LUKS header leak, that can put the entire volume at risk. But even that is relevant only when removing a compromised passphrase or taking the SSDs out of service. – mirimir Jan 20 '14 at 22:59
  • I think the only very rare issue you might have would be if for some reason sensitive data, be that the master decryption key or some file, gets paged to the SSD unencrypted. I'm quite certain dm-crypt is designed to prevent this from happening, so again, the only thing you have to ensure is that sensitive data never goes on the machine until FDE is fully up and running. – deed02392 Jan 20 '14 at 23:03
0

In a sort of response to deed02392's answer, there are ways around these problems mentioned, but it largely depends on how your array is setup. I agree totally that RAID-6 on its own is in absolutely no way secure, people want to be able to add and remove drives from a RAID array and want to recover in case a drive dies, so if that's possible, you can rest assured that an adversary with physical access to the disks could get what he wants once he figures out what order the drives are in.

If I were to setup a RAID-5, RAID-6, (or 1, 10, 50, or 60 for that matter) and I valued data confidentiality, here's what I'd do.

Issue Secure Erases

Immediately upon receiving the devices, issue SATA secure erase commands on all of the drives. Don't write anything to the drives at all. If you're needlessly paranoid, dd if=/dev/zero of=/path/to/device. Remember to do this on all of your devices.

Setup the RAID Array

Your process will diverge into a number of possibilities here.

Hardware RAID

If you're using hardware RAID, you'll need to unplug all of the drives after issuing the SATA secure erase command to them (and writing zeroes, which is pretty unnecessary and only makes you feel more secure) and plug them into your RAID controller. Go into your RAID BIOS or configure the RAID setup from your operating system of choice, though usually the RAID BIOS is easier to work with than running a series of commands which seem to be designed to be confusing. Setup your RAID level, then reboot into a secure Linux, maybe Kali if you're paranoid.

Software RAID

This is more complicated and you get a number of choices here. LVM? ZFS? BTRFS? There are a number of ways to setup software RAID, so I can't be of help too much here, Google it for yourself. Just make sure that at the end of all the setup, you have a single device (virtual, probably) that you can write to which correctly spans the length of the array.

Randomize the Entire Span of the Array

This step is optional, but highly recommended. It protects against certain deniability concerns, which I'll explain below. It won't protect you if you're forced to decrypt the array for someone. The simplest way to do this is to use /dev/urandom or another secure cipher with dd to overwrite everything:

dd if=/dev/urandom of=/dev/mapper/raid6blockdevice bs=SECTOR_SIZE

Use parted /dev/mapper/raid6blockdevice print to determine SECTOR_SIZE. This could take a pretty long time to complete.

The outcome of this step is that every bit in the array as it exists on the SSD is effectively random. Someone can't tell "how full" your filesystem is, as the entire thing is random bits, as the output from a good cipher should be indistinguishable from random data.

Setup LUKS/TrueCrypt/VeraCrypt/Your Disk Encryption of Choice

Using your disk encryption weapon of choice, encrypt your block device, then install a filesystem inside.


In response to your concerns about the SSD secretly internally storing the LUKS volume header, you're right that it's possible. Buy a $5 USB flash device and store the LUKS header on there instead of on the SSD array. I believe there's a way to do that.

Without that, be aware that if you ever had to burn down the house (destroy everything!), you'd have to have physical access to get all of the SSDs out of the server, connect them to SATA, and secure erase. Even with that said, it's hard to be completely sure that everything has really been erased. Start working in the data recovery field and find a SSD which secure erases reliably, or at least ask a friend in that field. Without assurances and in a bind, I'd probably just write a loop which forever rewrites the LUKS header with random data hoping that the SSD with all that writing would eventually replace any sequestered data with new data from randomness.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.