Jump to content
IamSpartacus

Where does disk encryption stand?

123 posts in this topic Last Reply

Recommended Posts

30 minutes ago, pwm said:

I often travel with LUKS-encryted USB drives.  But such a drive will obviously not use the same passphrase as any server-mounted drives.

Yep, your use case is not quite what we have implemented at present.  But just at least it can work, and last week it didn't at all.  One step at a time...

 

My use case is for out-of-array drives to be able to be encrypted.  Preferably without needing to have the same key as the array.  So we will both benefit from further work to this.  I know @dlandon is expecting limetech to pick this plugin up and take responsibility, but it might be awhile before that happens.  So it's best for us both to be patient.

Share this post


Link to post

Integration of Unassigned Devices will come beyond unRAID 6.4 AFAIK. At that point some more alignment can be made and tighter encryption on unassigned devices is possible (though personally I would change the name "unassigned" to something different).

 

Also the encryption feature itself can be expanded (natural evolution), several ideas are already mentioned in this forum, but any good new ideas are welcome. I would recommend to put these as feature requests so they won't get lost over time.

 

Share this post


Link to post
On 1/7/2018 at 3:11 AM, bonienl said:

Integration of Unassigned Devices will come beyond unRAID 6.4 AFAIK. At that point some more alignment can be made and tighter encryption on unassigned devices is possible (though personally I would change the name "unassigned" to something different).

 

Also the encryption feature itself can be expanded (natural evolution), several ideas are already mentioned in this forum, but any good new ideas are welcome. I would recommend to put these as feature requests so they won't get lost over time.

 

Yes, makes sense.  The potential for UD far outstrips its name and its roots.  Tighter integration with the base os makes sense.

Share this post


Link to post
On 11/16/2017 at 7:38 AM, limetech said:

 

You can change the passphrase/keyfile without reformatting but you have to use the 'cryptsetup' command to do it.

First you have to add your new passphrase:


cryptsetup luksAddKey /dev/md1  # for disk1; for disk2 use 'md2', disk3 use 'md3', ...

This will ask you for existing passphrase and then prompt for another passphrase.  Note at this point you now have two passphrases that will unlock the volume.  You can leave like that or you can remove the original passphrase:


cryptsetup luksRemoveKey /dev/md1

This will ask you for the passphrase to remove.

 

Careful with this procedure.  unRAID will only normally let you enter one passphrase to be used to unlock all volumes.  If one of the devices uses a different passphrase, unRAID will not be able to open it and the array will not Start.

 

LUKS lets you create up to 8 passphrases that all will unlock the volume.  This does not change any data content on the device.  Instead, when device is formatted with LUKS header, it also creates a "master key" which is what's actually used to encrypt/decrypt data.  The master key itself is encrypted with your entered passphrase.  Meaning, if you have say 4 passphrases defined, there will be 4 copies of the encrypted master key corresponding to the 4 passphrases.  When an encrypted LUKS volume is "opened" with a specified passphrase, it tries to decrypt each master key with that passphrase.  If the entered passphrase can't decrypt any of the master keys, then the volume cannot be opened.

 

Depending on user requirements in the future, we may add this capability to manage these "key slots" within the unRAID webGui, but of course that would be in a future release.

 

 

Tom, thanks very much for you and your team integrating encryption, I've been very much anticipating this!

 

To clarify, if I'm in the middle of converting all my disks to encrypted xfs, I should specify only those that are currently encrypted for the luksAddKey command above, one at a time while the array is started, is that correct?

 

I need to change all those disks to the new passphrase, remove the old, and then any newly encrypted disks would use the new passphrase, right?  And the array will start after I enter the new passphrase in the GUI?

 

Apologies, my first passphrase was ill advised...

 

Thanks!

 

-P

Share this post


Link to post
10 minutes ago, pengrus said:

 

 

Tom, thanks very much for you and your team integrating encryption, I've been very much anticipating this!

 

To clarify, if I'm in the middle of converting all my disks to encrypted xfs, I should specify only those that are currently encrypted for the luksAddKey command above, one at a time while the array is started, is that correct?

 

I need to change all those disks to the new passphrase, remove the old, and then any newly encrypted disks would use the new passphrase, right?  And the array will start after I enter the new passphrase in the GUI?

 

Apologies, my first passphrase was ill advised...

 

Thanks!

 

-P

 

Yes that will work.  You could also add the new passphrase first to all your encrypted devices and then test that you can Start the array with either the old passphrase or the new passphrase, then remove the old passphrases.  (I guess it might be handy to add a "change passphrase" feature.)  Take care and don't lock your keys in the car!

Share this post


Link to post
On 2/1/2018 at 6:36 AM, pengrus said:

I need to change all those disks to the new passphrase, remove the old, and then any newly encrypted disks would use the new passphrase, right?  And the array will start after I enter the new passphrase in the GUI?

You don't need to remove the old - LUKS can store multiple passphrases.

Share this post


Link to post
1 hour ago, pwm said:

You don't need to remove the old - LUKS can store multiple passphrases.

 

True, LUKS can store up to 8, but any one of the 8 will unlock the volume.  If your goal is to increase the strength of your passphrase (for example, maybe you used '123456' as your initial passphrase) you probably want to delete the old one.

Share this post


Link to post

Due to recent enterprises in the field of empowerment of state authorities with regard to supervision, I'm seriously considering encrypting my data.
I want to make sure nobody can access the data if the server is taken away.
As far as I could follow the discussions here, the current implementation would drastically reduce usability, because we use the server on demand via WoL. The server sits in the basement and typing the passphrase each time is not an option.
Storing a keyfile on the USB is not very reasonably by obvious reasons.

 

I was thinking of integrating the authentication into an app e.g. controlR?
We already have the smartphone in hand to WoL the server, so why not unlock via some sort of app?
Any thoughts? Or are there any alternative solutions in the pipe that could cover this specific scenario?

 

Also of interest, is there a timeline when the "inplace encryption" will be available?

 

  • Like 1

Share this post


Link to post

Entering a passphrase or keyfile is required upon start up of the system and starting the array. Once the array is started it will keep using the selected passphrase/keyfile. The system can be put asleep without the need to re-enter the passphrase/keyfile.

 

Share this post


Link to post

Thanks, that could be an option if the sleep works O.o

Unfortunately S3 sleep is sort of "casual" so I decided to use "power off".

Have to test how S3 is working in my case.

Share this post


Link to post

Install the s3_sleep plugin and press the Sleep button on the main page to put the system to sleep immediately. It allows you to test sleep and WOL.

Share this post


Link to post

Yes, I'm using that plugin already but with the option to power off instead of sleep.

How is the status of the array during sleep?

Mounted or unmounted? A power outage during sleep will trigger parity check?

Share this post


Link to post

Sleep puts the system into sleep mode without changing the array or disk status.

 

If a power outage occurs while in sleep mode, it is seen the same as a power outage when the system is active. A parity check will start if the array was online during the outage.

Share this post


Link to post
5 hours ago, bonienl said:

Sleep puts the system into sleep mode without changing the array or disk status.

 

If a power outage occurs while in sleep mode, it is seen the same as a power outage when the system is active. A parity check will start if the array was online during the outage.

Is there any way to configure a system to wake up when the UPS signals a power outage so it can be shut down safely?

Share this post


Link to post
14 hours ago, bonienl said:

Sleep puts the system into sleep mode without changing the array or disk status.

Wouldn't it make sense to unmount the array before sending to sleep?

Share this post


Link to post
4 hours ago, Fireball3 said:

Wouldn't it make sense to unmount the array before sending to sleep?

If you do that, it makes more sense to simply shut down, as there is nothing meaningful left running after the array is unmounted.

 

A hibernate type action that saves RAM state to non-volatile storage and then powers off makes more sense in this instance, but I don''t know if that's currently possible.

Share this post


Link to post
31 minutes ago, jonathanm said:

If you do that, it makes more sense to simply shut down, as there is nothing meaningful left running after the array is unmounted.

 

A hibernate type action that saves RAM state to non-volatile storage and then powers off makes more sense in this instance, but I don''t know if that's currently possible.

 

A hibernate that saves RAM state to unencrypted non-volatile memory while having the LUKS key in RAM would mean it would be easy to steal the key and get around the disk encryption.

 

And if the hibernate state is written to LUKS-encrypted disk storage then the passphrase needs to be entered to return back from hibernate - so no much difference from turning off the unit.

 

With sleep a thief at least needs to enter a UPS to maintain RAM when carrying away the computer - or add some hardware to the unit that allows a JTAG debugger or some DMA-capable hardware to read out the RAM. So sleep is a slightly safer way to allow the device to return back to full operation remotely while trying to protect the LUKS keys. But it would be preferable if the unit unmounted the RAID before going to sleep so a power loss doesn't result in a need to resynchronize parity.

Share this post


Link to post
47 minutes ago, jonathanm said:

If you do that, it makes more sense to simply shut down, as there is nothing meaningful left running after the array is unmounted.

Well, that brings us back to topic...

It keeps the encryption key memorized and reduces the risk of an unscheduled parity check due to power outage while in s3 sleep.

 

I would also opt for a full shutdown but unlocking the server without a remote solution is impracticable.

Not sure if linux supports S4 sleep (hibernate). Edit: @pwm's reasoning is also very sound

Edited by Fireball3

Share this post


Link to post

Ah yes, I lost track of the actual reason for the thread, and got lost in the weeds of supporting sleep on a server.

 

In the context of encryption, sleep with the option to unmount and stop services makes sense. It seems like a niche that would be useful.

 

52 minutes ago, Fireball3 said:

I would also opt for a full shutdown but unlocking the server without a remote solution is impracticable

 

So, why not focus on the remote unlock portion of the issue? It seems there are multiple valid reasons to want encryption, and some needs could be met with the ability to keep a key on a remote device like a phone. I can see a use case for @jbrodriguez remote control app being able to supply a key file, obviously with another layer of protection in place on the remote device itself.

Share this post


Link to post
22 minutes ago, jonathanm said:

Ah yes, I lost track of the actual reason for the thread, and got lost in the weeds of supporting sleep on a server.

 

In the context of encryption, sleep with the option to unmount and stop services makes sense. It seems like a niche that would be useful.

 

 

So, why not focus on the remote unlock portion of the issue? It seems there are multiple valid reasons to want encryption, and some needs could be met with the ability to keep a key on a remote device like a phone. I can see a use case for @jbrodriguez remote control app being able to supply a key file, obviously with another layer of protection in place on the remote device itself.

A normal SSH tunnel would be a safe way to remote-supply a passphrase to the system.

Share this post


Link to post
2 hours ago, pwm said:

A hibernate that saves RAM state to unencrypted non-volatile memory while having the LUKS key in RAM would mean it would be easy to steal the key and get around the disk encryption.

 

After the array is started, the keyfile can be deleted from RAM, this is an option available in the Main page, consequently it needs to be re-entered each time the array is stopped and restarted.

Share this post


Link to post

I have some dumb questions but first I want to thank Limetech and the folks who made this possible! I asked for this feature years ago, literally, and am very happy to see it realized! Long ago it didn't seem like this would ever happen and I appreciate the effort and work that went into it! My needs are fairly simple, if someone kicks in my door and attempts to haul away my server I wish them to not be able to retrieve anything of value. While powered up my local clients need unauthenticated access (I might yet force authentication down the line). Using a physical FOB to allow boot that could be removed afterwards is of interest but simply booting and entering a passphrase for now is fine.

 

That said, dumb question time! :)

 

I have managed to encrypt one new drive and have made sure it's not shared. My intent is to copy RFS files over, encrypt those drives, and copy back. I'll be doing my best to make sure no files get written while this is done <ahem>. I'll do this with rsync using the /mnt/disk directories and I believe it will maintain parity. Currently my new disk is formatted eXFS. 

 

1) For bulk storage of media and backups is there a practical difference between Btrfs and XFS? Recommendation for either? I don't expect to need snapshot capability but would like to understand it better FWIW. My sense is that XFS is generally what's been recommended but I can easily be convinced otherwise if there are good reasons to use BTRFS.

 

How solid are either of these encrypted file systems to say a stray bit flipping or a touch of corruption when filled with encrypted content? I've had a bad experience or two with NTFS (aka EFS) and disk crypto that's lead to loss of data :o 

 

Lastly, upon bootup it's my understanding that the unRAID OS will come up and I'll be expected to enter a passphrase or provide a file at the web GUI, yes? My onboard video has gone braindead recently and I want to be positive I won't be needing to enter passwords at the console since I cannot see it!

 

Lastly, I do backup my system using rclone so losing data is less of an issue than it could otherwise be. However if a drive isn't mounted and rclone kicks off is it likely to delete files it's not been able to find? My spidey sense says yes :( Any chance my moving of data and encrypting it will trigger rclone to recopy the data? I'm thinking not since size shouldn't change, RC5 shouldn't change, but time\date stamp might? I'll be using rsync and attempting to preserve that just in case but I welcome inputs on the subject as it's likely something others will run into too.

 

I think that's it. VERY excited to try this but am being cautious as I've got a great deal of data and don't want to step in anything nasty by being hasty! :o 

Share this post


Link to post

SO I just wanted to chime in here as I was a long time OpenMediaVault user. A bunch of folks recently convinced me to think about switching over to UnRAID. I see lots of similarities in functionality etc, but UnRAID just manages it all for me vs the manual level effort I need to do. In the process of copying my data over to XFS Encrypted array. A few points/questions I wanted to point out:

  • USB key with keyfiles - is not a bad approach. I know many people speak of the idea that then the keyfile exists to be stolen from, and the idea of physical media to decrypt that needs to be handed over to authorities for US. This isn't necessarily the case. The mentality I had in my OMV box, I have a USB always plugged in and available, so keys can always be read as needed (more on that below) - but if something happens and I need to destroy it - it's simply a matter of destroying the USB key. Backups have been "shared" with select persons to enable access to data again if we recover the drives later. Access to the keys is removed from the system by removal of the drive. If you have higher level paranoia, then remove the USB. There are obviously levels of risk vs convenience as mentioned - this is totally true and will vary based on your goal - for me, this methodology works fine and has been flawless thus far.
  • Auto-Mounting - I don't know much about how UnRAID operates, but I'll leave this link here to help the devs. The way it was setup in OMV, was that I had the key mounted in the system at boot, it would have a mapping to the keyfiles, and then it would allow me to expedite the process with crypt setup. If I line this up with the though in UnRAID - instead of having to supply the keyfiles at start of array, I can just supply keyfiles with a mapping, and then unRAID can just start the array as normal since the disks will be in an unlocked state.
    • LUKS AutoMount
    • I would love to see a similar mechanism become available so that disks could be auto-unlocked with a key in this fashion.
  • Individual Disk Keys - I think this is just an enhancement I would love to see. I'll be sure to go find the appropriate location to share enhancement requests. Personally again this goes to the risk vs convenience levels. I see great value in making it more difficult to decrypt multiple different disks with different keys for each disk, vs having the same key for all disks. If someone does get the single key, they have all the data. If there are different keys, then if someone gets 1 key, they only get 1 disk, not ALL disks. It seems the underly functionality/tech is there (crypsetup) since I can manually manage keys. The place where I think there needs a slight alteration/enhancement - is the handling of LUKS encrypted disks. I know in the OMV world - there was a separate tab for handling Encryption, then a second location like unRAID for handling the Disks/Volumes being mounted (aka the array). Perhaps it could simply become a new tab/setting where this extended configuration could be managed - insert short note near array indicating if using Secured disks, hey go to the settings and unlock them via the GUI tool. 
  • Header Backup - another in the feature request area - I'll post where appropriate - but it would be great if there was an option for backing up the headers. Again some may see this as a horrible idea, but what organizations in the world don't backup their data. This does the same with your security key to decrypt the drive later if something goes wrong. I believe this is already built in (cryptsetup) - but just needs to be implemented in the GUI. This is something I'd like to backup and store offsite somewhere else in case catastrophe strikes and somehow the header is ruined.

Happy to share any other experiences or sample config files if it would help from my OMV box. It's still up and running for a bit while I get things up and running on the new unRAID system. Liking what I see so far, and the introduction of the LUKS option was one thing barring me from entry lately. Now that it's hear I'm happy to make my way and start to learn more about unRAID. 

Edited by 1activegeek

Share this post


Link to post

Side note to also add - I would be interested to see the in place upgrade to LUKS. But honestly, for users holding out - I would suggest using alternate methods. When using LUKS, it essentially requires wiping the disk, there is no alternative. When using WDE solutions, all blocks essentially need to be re-written into encrypted versions. There are also headers on the disk that need to be re-written for the key. So the only way I see this functionally happening inside unRAID:

  1. Vacate a disk in the array (meaning you need enough free space in the ARRAY to match your largest DISK) - by moving all data to other disks
  2. Wipe the vacated disk
  3. Setup LUKS encrypted FS and supply the new passphrase/key for the disk
  4. Move data back onto the disk to re-balance the array
  5. Rinse/repeat for EACH unencrypted disk

It may in many cases be simpler/faster to just copy to external drives, then copy back. As long as you have an external as large as you internal disk, you'l be good. Copy all out, then copy back in after setting up LUKS. The array would also have to likely be taken offline though, so this is possibly the biggest bump in the process. Not sure how Parity would go, that may actually need to be redone as well. Depends if parity is looking at device level or FS level. 

Edited by 1activegeek

Share this post


Link to post
On 2/17/2018 at 11:33 AM, 1activegeek said:

USB key with keyfiles - is not a bad approach.

 

Thank you for all the suggestions.  re: above, a way you could implement this could be something like this:

 

- prepare a usb flash device and give it a unique label, eg, MYKEYS

- create your keyfile and save on the device

- inside 'go' file add some lines to mount the device and  create a symlink to your keyfile, eg

 

mkdir /key

mount /dev/disk/by-label/MYKEYS /key

ln -s /key/keyfile /root

 

Now when array starts it will see the keyfile.

 

Of course if someone physically makes off with your server and keyfile device, well encryption doesn't do much good right?  Or if someone on the "inside" copies your keyfile, same problem.  At first i thought this would be a valid use case, but not so much anymore.  Bear in mind, in US at least, you cannot be compelled to give up a passphrase stored entirely in your own brain.  But if you have it written down on something or stored electronically on something you can be compelled to give that up.  (That's my understanding but IANAL).

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