Jump to content
IamSpartacus

Where does disk encryption stand?

123 posts in this topic Last Reply

Recommended Posts

1 minute ago, uldise said:

As far as i know, with cryptsetup you can use keyfile and passphrase at the same time.. am i not true? or this is just an unRAID limitation? 

 

LUKS lets you create up to 8 encrypted copies of the Master Key (which itself is auto-created the first time you create a LUKS header).  Each of these copies is called a "key slot".

 

Each key slot is decrypted using either a passphrase or a file, that is, on the command line to open a LUKS volume you have cryptsetup prompt for a passphrase or you specify an option naming the file to use.

 

For unRAID we just use one of the key slots.

Share this post


Link to post
2 minutes ago, limetech said:

For unRAID we just use one of the key slots.

Thanks for clarifying this.. you already wrote earlier how to add more key slots. just for a safe, i will add passphrase on the second slot if i decide to go with a key file..  

Share this post


Link to post
13 minutes ago, uldise said:

Thanks for clarifying this.. you already wrote earlier how to add more key slots. just for a safe, i will add passphrase on the second slot if i decide to go with a key file..  

 

I've seen exactly that recommended on places like stack exchange: if you use a file, also add a verrrry long passphrase as backup.  I think that feature might be easy to add to unRAID, we'll look into it.

Share this post


Link to post
3 hours ago, limetech said:

 

Not exactly.  When you initially decide to use encryption you have to decide, "Am I going to use a passphrase or a file as my encryption/decryption method?".

 

If you use passphrase, this is a string you have to type correctly each time you reboot your server.  The longer the string, the harder it will be for someone to crack.  Make it long enough and it's supposedly impossible to crack, but then you have to type it exactly - no fat fingers.

 

Alternately you can use a file, that is, you can pick a file and upload instead of using a passphrase.  The advantage of this approach is that you can use a relatively large file that is filled with random text or even binary data.  The file content is what's used as the encryption/decryption key.  For example, you can use maybe a random image file, or create one with random data.  Of course now you have the problem of keeping a safe copy of that file somewhere.

 

Regardless of which method you use, unRAID will store the encryption key in a file called "/root/keyfile".  (If you use passphrase, we just store the passphrase in this file in plain text just as you entered it.  If you upload key file, we save its content in this file.)

 

Saving the passphrase in /root/keyfile may seem insecure (and it can be), but realize this is RAM and when server powers off, the file is gone.  Also, as stated earlier, you can explicitly delete the file once the array has been Started - actually you can delete any time.  Perhaps in future we may change code so that every time the array is Started we auto-delete the /root/keyfile - we'll see.

OH! I think I (finally) had the lightbulb moment.  

 

I was thinking the key would remain on Unraid (somewhere on the USB stick); I didn't consider that it would be uploaded from another secured machine each time.  This now makes a lot more sense, as does your initial comment about deleting it.  

 

Thank you very much for the clear explanation, I hope it helps more people than just me.  :)

Share this post


Link to post

One final question: is there any reason to not delete the key from memory once the drives are unlocked?  I've recently begun formatting and encrypting and I'm trying to understand if there's a scenario where I would want that key to remain in memory.

 

Thanks!

Share this post


Link to post

When you delete the key from memory, it requires to re-enter the key each time the array is restarted. Keeping the key in memory makes stopping and starting the array more convenient.

 

Remember that once the system is shutdown or power is unplugged the key will be gone anyway.

 

Share this post


Link to post
23 minutes ago, bonienl said:

When you delete the key from memory, it requires to re-enter the key each time the array is restarted. Keeping the key in memory makes stopping and starting the array more convenient.

 

Remember that once the system is shutdown or power is unplugged the key will be gone anyway.

 

It's a balance of security vs convenience, so I think if it's not too much work you should give the user the option of what level of persistence is ok for their needs.

 

The most secure scenario would automatically umount the encrypted volumes at user defined events or intervals, with no local key storage possible. That way if you forget to "log out" of the secure volume, you would be sure that it would be locked for you after a reasonable interval.

 

If you go to spy movie level paranoia, I can think of a way to box up a running system while transferring power to keep it alive while it's transported to another location for forensic analysis.

Share this post


Link to post
On 11/19/2017 at 5:24 PM, mattyx said:

Doesn't that undo the protection of FDE in the first place, since the key is sitting unencrypted on the box?  It seems to me that if your threat model includes physical theft of the server, this might not be a good idea.

 

Honest question; apologies if I am missing something obvious.

Key files really should be avoided. Anything that stores the passphrase in clear text as a file will reduce the protection - even if that file is later deleted, the file delete will not be very safe and protect from file recovery attempts even if the file contents is first overwritten before the file is deleted.

 

Best is a solution where you must manually enter a passphrase when unlocking.

 

Second best is probably a manually inserted USB thumb drive that is removed after the system has booted - there will still be a thumb drive with sensitive data but that data can't be recreated on the running and online machine.

 

The above is also the reason why the world invented the Trusted Platform Module (TPM) to store sensitive information, even if it has later been found out that lots of the TPM are more or less worthless because of design mistakes.

Share this post


Link to post
7 hours ago, mattyx said:

One final question: is there any reason to not delete the key from memory once the drives are unlocked?  I've recently begun formatting and encrypting and I'm trying to understand if there's a scenario where I would want that key to remain in memory.

 

Thanks!

Standard best practices for cryptographic material is that secretes stored in RAM gets overwritten as soon as they aren't needed any more. What isn't stored anywhere can't be captured by a debugger or hardware with DMA capabilities.

Share this post


Link to post
6 hours ago, jonathanm said:

If you go to spy movie level paranoia, I can think of a way to box up a running system while transferring power to keep it alive while it's transported to another location for forensic analysis.

Even the police in several countries are starting to learn this trick for more high-profile cases.

Share this post


Link to post
5 hours ago, pwm said:

Best is a solution where you must manually enter a passphrase when unlocking.

 

Second best is probably a manually inserted USB thumb drive that is removed after the system has booted - there will still be a thumb drive with sensitive data but that data can't be recreated on the running and online machine.

Be careful here. In the USA at least, the courts can punish you for not providing a physical item which grants access, even if that item is your body. They can NOT, however, force you to disclose a passphrase known only in your head, because you can't be forced to testify against yourself. Cell phone fingerprint unlock = bad, passcode = good.

 

This is not a comment on the technical security of the different methods, only the lengths to which USA law compels you to comply.

 

In the context of unraid encryption, I suppose that any physical equivalent to a key should be regarded as possibly technically sound but not secure against government intrusion. A passphrase such as "correct horse battery staple" is a much better option.

Share this post


Link to post
31 minutes ago, jonathanm said:

Be careful here. In the USA at least, the courts can punish you for not providing a physical item which grants access, even if that item is your body. They can NOT, however, force you to disclose a passphrase known only in your head, because you can't be forced to testify against yourself. Cell phone fingerprint unlock = bad, passcode = good.

 

This is not a comment on the technical security of the different methods, only the lengths to which USA law compels you to comply.

 

In the context of unraid encryption, I suppose that any physical equivalent to a key should be regarded as possibly technically sound but not secure against government intrusion. A passphrase such as "correct horse battery staple" is a much better option.

The actual key for LUKS is encrypted in the LUKS header.

 

So what is supplied is the encryption key data needed to decode the LUKS header. A file on a USB thumb drive would be the equivalent of a pass phrase. How well to protect this information obviously depends on who the user needs to protect against. The majority don't have problems with the government and don't expect the government to come making physical visits, so having an offline USB key is good enough compared to having to remember a long passphrase.

 

What is important is to think twice about having the key data potentially online given the fact that a potential hacker has already gone through one or two security layers to gain access to the machine, and so can be assumed to be competent enough to figure out where to start looking for the key data. No hacker can manage to extract data from an unpowered USB key physically disconnected from the network.

 

The really important thing to remember is that LUKS encryption is only safe in a powered device if that powered device has a powerful shell protection. Any user that manages to get access to a running unRAID can access all the data on all file systems that are unlocked and mounted. That's also why LUKS generates a new, unique, encryption key for every encrypted partition - even if the passphrase may be the same for multiple disks it isn't possible to lift the encryption key for an opened LUKS container and use this key to get access to other LUKS paritions on the same machine.

 

But in the end, LUKS encryption works best for either short-time-mounted volumes, or for machines that has a commercial grade firewall protecting the machine from accesses from all other local machines and from VM and Docker containers.

Share this post


Link to post
3 hours ago, pwm said:

No hacker can manage to extract data from an unpowered USB key physically disconnected from the network.

Similarly, no hacker can possibly extract a well constructed passphrase from your brain, but a thief may well decide to abscond with every bit of tech on the premise, USB key included. Whether they can figure out what to DO with said tech is another matter entirely.

 

3 hours ago, pwm said:

The majority don't have problems with the government and don't expect the government to come making physical visits

If you expect problems with the government, you need to reevaluate your life choices. I'm speaking in broad generalities of what protections you have in the face of false accusations and circumstances outside of your direct control. Preparing a good legal defence doesn't assume guilt.

Share this post


Link to post
On 11/15/2017 at 8:16 AM, limetech said:

To add on what bonienl said...

If you want to open your LUKS volume as created by unRAID on another linux system, you can provide your passphrase/keyfile, or, you can use the 'cryptsetup' command to define another passphrase to open your volume.  For example, suppose your unRAID passphrase is "ffj3i2948423.a84" but you want to attach one of the devices to an unbuntu system (for example), and you don't want to reveal that passphrase.  With array Started you could type this at the unRAID command line:


cryptsetup luksAddKey /dev/md1   [e.g., for disk1]

This command will prompt for your existing passphrase, and then it will prompt for another, new passphrase (and confirmation).  Now you can Stop array, yank device out and give to someone and tell them your "new" passphrase to use to open the device.

 

I have set up a test server with a keyfile for a passphrase.  Now I want to add an additional key

But "cryptsetup luksAddKey /dev/md1" seems to only work with a passphrase.  I can't seem to get it do recognize my keyfile to verify the existing security.  Is this a known limitation of keyfiles at present?

 

 

Edited by tr0910

Share this post


Link to post
1 hour ago, tr0910 said:

I have set up a test server with a keyfile for a passphrase.  Now I want to add an additional key

But "cryptsetup luksAddKey /dev/md1" seems to only work with a passphrase.  I can't seem to get it do recognize my keyfile to verify the existing security.  Is this a known limitation of keyfiles at present?

 

 

 

Try this:

cryptsetup luksAddKey /dev/md1 --key-file /root/keyfile   [e.g., for disk1]

Where you have uploaded your encryption key file to /root/keyfile.

Share this post


Link to post
1 hour ago, limetech said:

 

Try this:


cryptsetup luksAddKey /dev/md1 --key-file /root/keyfile   [e.g., for disk1]

Where you have uploaded your encryption key file to /root/keyfile.

Works like a charm, and I also used the luksRemovekey via the same --key-file option and deleted the initial keyfile successfully and converted to a passphrase.

 

The testing I did briefly seems to suggest that there is minimal system slowdown resulting from the implementation of the XFS_Encryption on this Xeon 2670 based system.   See the benchmarks below.

 

Based on the ability to change keys on the fly and use some encrypted and some non-encrypted disks, I cannot think of any reason not to use this configuration immediately.  

 

Does anyone have any bad news to share with encrypted file systems that we should consider before implementing on a production system?  My use case is for a small number of personal files.  Likely only one disk on the server.

 

cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       606113 iterations per second for 256-bit key
PBKDF2-sha256    1014096 iterations per second for 256-bit key
PBKDF2-sha512     661979 iterations per second for 256-bit key
PBKDF2-ripemd160  489988 iterations per second for 256-bit key
PBKDF2-whirlpool  430449 iterations per second for 256-bit key
#     Algorithm | Key |  Encryption |  Decryption
        aes-cbc   128b   554.6 MiB/s  1857.8 MiB/s
    serpent-cbc   128b    64.8 MiB/s   275.1 MiB/s
    twofish-cbc   128b   152.6 MiB/s   300.1 MiB/s
        aes-cbc   256b   410.4 MiB/s  1428.9 MiB/s
    serpent-cbc   256b    69.2 MiB/s   275.3 MiB/s
    twofish-cbc   256b   158.2 MiB/s   299.1 MiB/s
        aes-xts   256b  1601.9 MiB/s  1607.9 MiB/s
    serpent-xts   256b   283.2 MiB/s   270.5 MiB/s
    twofish-xts   256b   292.5 MiB/s   295.0 MiB/s
        aes-xts   512b  1261.9 MiB/s  1257.0 MiB/s
    serpent-xts   512b   283.8 MiB/s   270.5 MiB/s
    twofish-xts   512b   292.8 MiB/s   293.8 MiB/s

 

Edited by tr0910

Share this post


Link to post
5 hours ago, tr0910 said:

Based on the ability to change keys on the fly and use some encrypted and some non-encrypted disks, I cannot think of any reason not to use this configuration immediately.  

Only issue I see that makes me want to wait to implement this is that unassigned devices is not ready to mount encrypted drives.  (I couldn't get it to work via the GUI.  Unassigned devices would recognize the FS as crypto_LUKS but was unable to mount the encrypted device.)

@limetech is this something where you have to pass the keyfile to unassigned devices, or is this something that is only fixable inside unassigned devices.

 

Having unassigned devices able to work with encrypted drives would complete the encryption feature for me.

 

Edited by tr0910

Share this post


Link to post
On 24.12.2017 at 11:17 PM, zin105 said:

Is in-place encryption planned for 6.4 release btw?

second this question. I remember devs being positive about adding this somewhere down the line.

 

For me its a killer feature, as building a second 40 tb rig just for the transfer is no option for me.. even though duplicati has me covered.

Share this post


Link to post

So I successfully formatted my array to encrypted BTRFS and have a passphrase and a keyfile saved in my USB stick. Is there a way to auto-decrypt using my existing keyfile on my USB key? I don't need very high security -- just want to make sure that my system is safe once I pull my USB out. I found on these 2 links how to auto-decrypt and mount using a keyfile:

 

https://blog.tinned-software.net/automount-a-luks-encrypted-volume-on-system-start/

https://access.redhat.com/solutions/230993

 

However, I'm not sure if the last part applies to unRAID array disks. Is there a way to have it auto-decrypt w/o mounting since unRAID will take care of it when I boot into the server anyways? Many thanks!

Share this post


Link to post
On 12/29/2017 at 1:38 AM, rix said:

For me its a killer feature, as building a second 40 tb rig just for the transfer is no option for me.. even though duplicati has me covered.

 

Hm, I am wondering what takes more time. Copying data over or developing, testing and implementing a 100% solid-proof in-place encryption with the many different scenarios we have...

  • Upvote 1

Share this post


Link to post
9 minutes ago, ipreferpie said:

So I successfully formatted my array to encrypted BTRFS and have a passphrase and a keyfile saved in my USB stick

 

I am not sure if I understand your way of working.

 

1. unRAID uses either a passphrase or keyfile. Not both.

2. Passphrase or keyfile is stored as a file under /root in RAM

3. There is no need to keep a keyfile on the USB stick, even more it will jeapordize the solution as the key becomes readily available with the system.

 

Share this post


Link to post
On 12/24/2017 at 10:43 PM, tr0910 said:

Only issue I see that makes me want to wait to implement this is that unassigned devices is not ready to mount encrypted drives.  (I couldn't get it to work via the GUI.  Unassigned devices would recognize the FS as crypto_LUKS but was unable to mount the encrypted device.)

@limetech is this something where you have to pass the keyfile to unassigned devices, or is this something that is only fixable inside unassigned devices.

 

Having unassigned devices able to work with encrypted drives would complete the encryption feature for me.

 

@dlandon has updated unassigned devices so that it is able to mount an encrypted drive with the following conditions.

 

  • The array disk passphrase has to be defined. You cannot enter the passphrase for the disk in UD.
  • The disk can only be mounted if the current array passphrase is the same as the encrypted disk.
  • An array encrypted disk cannot be created with UD.

(above from dlandon) but let me make the following clarification...

 

You must have one drive in your array encrypted with the same password or keyfile that you want to use with an unassigned device.  This is only because without that, unRaid won't even ask for any encryption credentials, and unassigned devices needs the ones from unRaid before it can mount an encrypted device.

Share this post


Link to post
4 hours ago, tr0910 said:

You must have one drive in your array encrypted with the same password or keyfile that you want to use with an unassigned device.  This is only because without that, unRaid won't even ask for any encryption credentials, and unassigned devices needs the ones from unRaid before it can mount an encrypted device.

Correct.  The passphrase has to be entered for a disk drive in the array.

Share this post


Link to post
1 minute ago, dlandon said:

Correct.  The passphrase has to be entered for a disk drive in the array.

In a long run, this is something that needs to be changed, so that drives outside of the array can have individual passphrases.

 

I often travel with LUKS-encryted USB drives.

 

But such a drive will obviously not use the same passphrase as any server-mounted drives. The normal thing when I bring the drive home is to connect the drive to a machine and synchronize the data.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now