IamSpartacus

Where does disk encryption stand?

100 posts in this topic Last Reply

Recommended Posts

Posted (edited)

 @limetech - I'm still learning, but what you mention sounds like it might work and was something I was starting to envision. Once I learned how the key is stored temporarily, made me wonder if I could copy it over. I guess I'll have to learn a bit about how the mounts are setup in UR though so I don't botch anything with my selected mount location. What you supplied looks like a good start, I'll have to dig into testing it.

 

I think the bottom line to what you point out is, the differing degrees of security you're accepting of. One example people have supplied is the idea of encryption simply for say RMA. In this case, this scenario just makes this encryption easier since the disk is removed and key not accessible. The rationale I think of here, is the difference between the level of encryption you can gain from a "long passphrase" vs a keyfile that can be infinitely longer in length. With brute forcing and the type of compute used, a passphrase could be beat. So keyfile is a little better. The topic of being compelled to provide a key though, breaks if the "key" breaks. So my example/plan would be to break the key being used, aka the USB flash drive. Flash isn't hard to destroy in an irrecoverable fashion. Backups of the key become difficult to prove, and it becomes an argument of does it exist? It's a matter of plausible deniability. 

 

Bottom line, it's a matter of desired level of security from this method. I'm not a lawyer either so I could be crazy, but at least it's my rationale. This is a great star for me though. I'll be sure to respond on here if it works when I get around to it. 

 

One side question - when it comes to removing the key ... if I was to setup a UserScript to run at array start, would that successfully remove the key? Or does that "timing" coincide with the need of the key to "start" the array. 

Edited by 1activegeek

Share this post


Link to post
2 hours ago, 1activegeek said:

One side question - when it comes to removing the key ... if I was to setup a UserScript to run at array start, would that successfully remove the key? Or does that "timing" coincide with the need of the key to "start" the array.

 

Yes you should be able to tie to the "array_started" event and delete the keyfile then.  Note if the keyfile is missing you won't be able to later Format an encrypted device.

Share this post


Link to post
1 hour ago, limetech said:

 

Yes you should be able to tie to the "array_started" event and delete the keyfile then.  Note if the keyfile is missing you won't be able to later Format an encrypted device.

 

Perhaps it is possible to link the script to the "disks_mounted" event and make a conditional file deletion. I.e. don't delete when formatted disks exist.

Share this post


Link to post
9 hours ago, limetech said:

 

Yes you should be able to tie to the "array_started" event and delete the keyfile then.  Note if the keyfile is missing you won't be able to later Format an encrypted device.

Not sure I understand. You mean if I had a disk that I wanted to format, the keyfile needs to be supplied first? I think that would be fine, I'd only want that in rare instances. And in this case, I just want to ensure the key doesn't reside on the server itself to allow for mounting if I was to unmount the array. The idea here is if I need to set the drives encrypted - I can stop the array and destroy the USB keyfile. Or just reboot and pull the drive, pull the plug pull the drive, etc.

 

As I say this, also makes me think there is a further level of plausible deniability here. I don't believe you can tell by analyzing the LUKS headers if there is a physical file vs a passphrase present in the slots. I believe it will only indicate that x/8 slots are used/available. So theoretically, assuming nobody can prove the disk exists, it could just be a password. ^_^ 

Share this post


Link to post
4 hours ago, 1activegeek said:

The idea here is if I need to set the drives encrypted - I can stop the array and destroy the USB keyfile. Or just reboot and pull the drive, pull the plug pull the drive, etc.

Is this a real life scenario?

I think you won't have time to do those things in practice!

Either somebody grabbed all your stuff in your absence - including the USB key, or somebody knocks on your door, walks in and takes every piece of hardware with him he can find, while you're locked in place.

I fully agree, that a passphrase stored in my brain is the safest in this scenario, but it's not very comfortable for everyday use.

Share this post


Link to post
1 hour ago, Fireball3 said:

I fully agree, that a passphrase stored in my brain is the safest in this scenario, but it's not very comfortable for everyday use.

With 3-6 month uptimes before it's time to reboot for kernel updates and optional dusting it really isn't much work to manually enter some passphrases.

 

It's just important to remember that every character in a passphrase is worth about 3 bits of security. So a 40-character passphrase is around 120 bits - close to AES-128.

Share this post


Link to post
1 hour ago, pwm said:

With 3-6 month uptime

Well, true, in your specific case that might be an affordable expense. But that may be different for others and the solution can't be to have the rig running 24/7.

Share this post


Link to post
Posted (edited)

I'll just add, I wasn't meaning to bring into question a debate around the utility of the function. As mentioned, different levels of risk are acceptable for different folks. So apologies if this has derailed some of the conversations around the purpose or intended use. For me, flexibility in this capability is key because of it's inherent risks/reward setups. 

 

The infrequency of use could also be problematic if you use a long phrase and forget it, vs a file being supplied locally. For key strength - yes this is my main point. The encryption is only as strong as the key used. In this case my key is a 4k keyfile - stronger than any long password you're likely to remember or even want to enter to start an array. It also has the advantage of using random data vs strict alphanumeric characters. Keyfiles also remove the ability of any type of MITM attack on a browser locally or malware on a device monitoring keystrokes. Because it can be supplied directly on the system, the only attack vector is direct attachment to the host.

Edited by 1activegeek

Share this post


Link to post

An idea I had was to have the motherboard speaker beep out a tune when server is up but not Started due to missing encryption key.  Then have automounter detect when MYKEYS usb flash is plugged in, mount flash, create symlink, Start array, then play another tune.  When you hear the second tune, you yank the flash.  A lot of newer motherboards don't have speakers anymore though :(

  • Like 1

Share this post


Link to post

I hear you there! We've gradually lost the basic things that enabled SOOO MUCH! :-\  I think if there would at least be an option similar to that (and I think there is via script) I should be in good shape for my desired workflow. Hopefully this weekend I can finally get into testing it out. I'll be sure to report back/share my findings. 

Share this post


Link to post

Just FYI, I've been quietly monitoring the thread (thanks to Fireball3 and jonathanm for pinging me on this) ... 

 

I haven't played around with unRAID encryption yet ... long before it was available, I created truecrypt volumes and stored them in a /storage share on my array.

 

To be honest, I don't quite grasp yet the need for a remote encryption 'unlock' (from an app such as a ControlR), but I'm willing to invest time into figuring this out.

 

Having said that, right now I'm actively looking into the GDPR implications for the ControlR app and consider it as my primary concern for the time being.

Share this post


Link to post
1 hour ago, jbrodriguez said:

To be honest, I don't quite grasp yet the need for a remote encryption 'unlock' (from an app such as a ControlR)

It makes sense from a paranoid high security viewpoint. You can lock your smart device with a passcode which you are not by USA law compelled to reveal to incriminate yourself, unlike a fingerprint or physical key, be it mechanical or USB. Your smart device can store the much higher security key file which is only transmitted over a high security communication channel. It's easy to replicate to a second smart device for a backup secure method of unlocking the array. Combined with proper implementations like dead man switch timeouts and re-authentication, it's a very difficult scheme to bypass.

Share this post


Link to post
On Samstag, 3. März 2018 at 1:56 AM, jonathanm said:

It makes sense from a paranoid high security viewpoint.

I don't think it needs such a "high paranoia" to walk the path of encryption.

I tried to explain my paranoia here. You're welcome to explain your reason of encrypting your data.

The "remote encryption unlock" just adds a lot more flexibility for the users not having their

server running 24/7 (locked away in the basement or so, maybe even on a remote location).

It's not necessarily about the higher security key strength that is possible via this method, but once implemented,

this is another goodie.

Share this post


Link to post

For a huge number of years, I have never been able to send in any broken disk on warranty - no way to sanitize the drive to make sure I will not break any NDA. Encryption solves that problem in a great way. So encryption isn't just for people worrying about the police.

Share this post


Link to post

High all. Not new to Unraid but Kinda New to Encryption.

 

I would like to know if there is a limit on the size of the passphrase possible to unlock the encrypted discs? (Most likely 64 is the max)

 

I have a regular array and a backup array. I have been doing some investigating on backing up the regular array to the backup array. Both systems are fully encrypted using different passphrases. I would like to script a WoL signal to a shutdown Backup array, Unlock the backup array and start an rsync procedure for my shares. After all this is done, shutdown the backup array again. I would try to Cron Job this script for once a week. I have a direct connection between the two arrays with a 10Gb Fibre. Is there any way to accomplish what i have described currently?

 

This might be a question for another section. I would like to Isolate my Backup array shares completely from the network attached to the internet. So i would like to compartmentalize Unraid and the shares. I like the idea of being able to update the unraid server but but leaving the shares on the backup isolated from the network and only able to use the dedicated 10Gbe for backups. Does this sound possible? Like i said this question might be better suited to another section.

Share this post


Link to post
13 minutes ago, sentein said:

I would like to know if there is a limit on the size of the passphrase possible to unlock the encrypted discs? (Most likely 64 is the max)

 

Max. is 512 characters.

Share this post


Link to post

Ha well if nothing else i guess i am upping my passphrase! Thanks bonienl.

 

Anything on the other 2 questions is still welcome.

Share this post


Link to post
18 minutes ago, sentein said:

Ha well if nothing else i guess i am upping my passphrase! Thanks bonienl.

 

Anything on the other 2 questions is still welcome.

If it's a sentence, then consider each character to be worth about 3 bits. So at around 80 characters the passphrase has about the same strength as AES-256.

Share this post


Link to post
52 minutes ago, bonienl said:

 

Max. is 512 characters.

 

If you use an uploaded keyfile max length is 8192K.  Note you can use a larger file, and cryptsetup will accept it, but will only use the first 8192K.

Share this post


Link to post

I will most likely max out the 512 char. limit. Key files can be nice but i would only use one if it were in conjunction with a passphrase not in place of. Good information on the keyfile though. Thank you very much.

Share this post


Link to post
14 hours ago, sentein said:

I will most likely max out the 512 char. limit. Key files can be nice but i would only use one if it were in conjunction with a passphrase not in place of. Good information on the keyfile though. Thank you very much.

But you realize that no chain is stronger than the weakest link and having a huge passphrase or key file can't give you more security than what you can expect from AES-256 encryption? Maxing out the character limit doesn't strengthen your system. The passphrase isn't used to encrypt the disk - it is used to encrypt the symmetric disk crypto key stored in the Luks header data. That is also why Luks supports multiple passphrases that all can decrypt the same disk encrypt/decrypt key.

Share this post


Link to post
5 hours ago, pwm said:

But you realize that no chain is stronger than the weakest link and having a huge passphrase or key file can't give you more security than what you can expect from AES-256 encryption? Maxing out the character limit doesn't strengthen your system. The passphrase isn't used to encrypt the disk - it is used to encrypt the symmetric disk crypto key stored in the Luks header data. That is also why Luks supports multiple passphrases that all can decrypt the same disk encrypt/decrypt key.

 

Makes sense. I only have 64 Char.s right now so there is a little room for improvement either way. Basically i like to max out any passphrase size whenever i can. More of a, If i can go this high why not.  Sorry for making sound like i thought otherwise. If the passphrase was used to encrypt the disks every change of a passphrase would mean re-encryption of the disks. Yeah I do understand that.

Share this post


Link to post
On 3/1/2018 at 3:31 AM, limetech said:

 

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

 

Just wanted to followup as I said I would. Took a little longer to get back to this as I had a few more things going on that took precedence. I did setup the basics of what you outlined here, I'm glad it was this simple! It did work out perfectly fine. So now I've validated that with the array set to automatically start on boot, the USB inserted, the array will start up perfectly without issue. I've not validated startup without the USB, but I'm fairly confident the result will be a failure to boot as it has been before creating this Go file entry. 

 

Thanks for the help! I was going to look into options for removing the key after startup now as a secondary effort. But as I thought about the method described here, there is a symbolic link created for the keyfile, vs copying over the keyfile. So outside of a reboot, the key should persist for subsequent mounts. But as soon as the USB device backing the link is gone, the file should/would be gone correct? So in this fashion, simply removing the USB should nullify the valid key's existence, correct? 

Share this post


Link to post
6 minutes ago, 1activegeek said:

So in this fashion, simply removing the USB should nullify the valid key's existence, correct? 

 

Correct.

  • Like 1

Share this post


Link to post

Excellent! So no further setup needed. This is great. Thanks again for the help. This gives me that warm and fuzzy accomplished feeling for today! ;) 

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


Copyright © 2005-2018 Lime Technology, Inc.
unRAID® is a registered trademark of Lime Technology, Inc.