Encryption and auto-start


Recommended Posts

unRAID 6.4 introduces encrypted volumes and allows individual disks to be protected by encryption.

image.png.6f7646e6c6fa9f4c5e814fa268bc82ba.png

The passphrase or keyfile which is used to unlock encryption is not permanently stored on the system itself, this means that upon a system start one has to re-enter the passphrase or re-select the keyfile. Until then the array can not start and the GUI will report a "missing key".

 

But what if we want to auto-start the array and not keep a local copy on the system itself? It kind of defeats the protection scheme to store a local copy, i.e. when your system get stolen, you don't want to include the keys to allow access.

 

The solution I have come up is to download the keyfile during startup from a different system in my local network which is in a different part of the house. In my case I am using an arbitrary .png file, but you could also store a passphrase and have this copied over. In my go file I added the following lines to download the keyfile from a remote SMB share before starting emhttp.

# auto unlock array
mkdir -p /unlock
mount -t cifs -o user=name,password=password,iocharset=utf8 //192.168.1.123/index /unlock
cp -f /unlock/#/some.png /root/keyfile
umount /unlock
rm -r /unlock

Of course the remote share must be accessible when the system starts and surely this approach can be cracked, but it is definitely safer than just keeping a local copy of the keyfile on the unRAID server itself.

 

Remember that once the array is started, the local keyfile may be deleted if you really don't want to keep the key while the system is operational.

 

Perhaps my idea is useful for others wanting to do something similar :)

 

  • Like 3
  • Upvote 1
Link to comment
  • 1 month later...

What a great suggestion.  I think I am going to try this on my next build.   I am going to use an inexpensive Raspberry Pi Zero W loaded with DietPi OS as my remote server. It's non-obtrusive  size can be placed anywhere within wi-fi distance. Technically my "DietKeyLimePi"   only needs to be available at boot up time.

 

DietPI is an extremely lightweight Debian Jessie OS. It can be configured to be a headless samba server and have SSH capability.  Power consumption is under a watt at idle.

Link to comment
  • 2 months later...

A small variation if you want the key to be not locally present on the system when operational, the key is only needed during startup of the array.

 

In the go file the following is included before starting emhttp.

# auto unlock array
install -D /boot/custom/bin/fetch_key /usr/local/emhttp/webGui/event/starting/fetch_key
install -D /boot/custom/bin/delete_key /usr/local/emhttp/webGui/event/started/delete_key
install -D /boot/custom/bin/fetch_key /usr/local/emhttp/webGui/event/stopped/fetch_key

# start webGUI
/usr/local/sbin/emhttp &

The above makes use of the built-in event system of unRAID. These events are created:

starting : this event is called before the array is started and is used to fetch the key from a remote source

started :  this event is called after the array is fully operational and is used to delete the key locally.

stopped : this event is called after the array is stopped and is used to fetch the key again from a remote source

 

The script "fetch_key"  can be any method to obtain the key remotely, e.g. using a mount method or a FTP (wget) method as explained in the video of @gridrunner

The script "delete_key" is a simple file to delete the key locally.

 

fetch_key

#!/bin/bash

if [[ ! -e /root/keyfile ]]; then
  mkdir -p /unlock
  mount -t cifs -o user=name,password=password,iocharset=utf8 //192.168.1.99/index /unlock
  cp -f /unlock/somefile.png /root/keyfile
  umount /unlock
  rm -r /unlock
fi

delete_key

#!/bin/bash

rm -f /root/keyfile

You can start and stop the array as usual, and the key will be automatically fetched each time, provided that the remote service is up and running.

 

The files "fetch_key" and "delete_key" need to be stored on your flash device. I've created the folder /custom/bin to hold my custom scripts, but one is free to choose their own source folder, please update the lines in the go file accordingly.

  • Like 1
Link to comment
On 4/2/2018 at 8:01 AM, bonienl said:

A small variation if you want the key to be not locally present on the system when operational, the key is only needed during startup of the array.

 

In the go file the following is included before starting emhttp.


# auto unlock array
mkdir -p /usr/local/emhttp/webGui/event/starting
mkdir -p /usr/local/emhttp/webGui/event/started
mkdir -p /usr/local/emhttp/webGui/event/stopped
cp -f /boot/custom/bin/fetch_key /usr/local/emhttp/webGui/event/starting
cp -f /boot/custom/bin/delete_key /usr/local/emhttp/webGui/event/started
cp -f /boot/custom/bin/fetch_key /usr/local/emhttp/webGui/event/stopped

# start webGUI
/usr/local/sbin/emhttp &

The above makes use of the built-in event system of unRAID. These events are created:

starting : this event is called before the array is started and is used to fetch the key from a remote source

started :  this event is called after the array is fully operational and is used to delete the key locally.

stopped : this event is called after the array is stopped and is used to fetch the key again from a remote source

 

The script "fetch_key"  can be any method to obtain the key remotely, e.g. using a mount method or a FTP (wget) method as explained in the video of @gridrunner

The script "delete_key" is a simple file to delete the key locally.

 

fetch_key


#!/bin/bash

if [[ ! -e /root/keyfile ]]; then
  mkdir -p /unlock
  mount -t cifs -o user=name,password=password,iocharset=utf8 //192.168.1.99/index /unlock
  cp -f /unlock/somefile.png /root/keyfile
  umount /unlock
  rm -r /unlock
fi

delete_key


#!/bin/bash

rm -f /root/keyfile

You can start and stop the array as usual, and the key will be automatically fetched each time, provided that the remote service is up and running.

 

attaching my fetch_key, using ftps (redacted ftp ip)

 

 

fetch_key.bash

Edited by ijuarez
example
Link to comment

Although bonienl doesn't mention it, and it was what I was actually asking for (which I failed to properly express), you can scp to a remote server if you have a public key and get the passphrase key, so the deterrent would be to have the remote server down (so you can't get the private from a remote location) .. but I'd defer that to more cryptographic minded guys

Edited by jbrodriguez
Link to comment

Change your fetch_key file to this

#!/bin/bash

if [[ ! -e /root/keyfile ]]; then
  wget --ftps-implicit --user=<name> --password='<password>' ftp://<url or IP>/files/keyfile -O /root/keyfile
fi

Replace <name>, <password> and <url or ip> with your actual username, password and ftp server address

Link to comment
On 4/7/2018 at 4:29 AM, bonienl said:

Change your fetch_key file to this


#!/bin/bash

if [[ ! -e /root/keyfile ]]; then
  wget --ftps-implicit --user=<name> --password='<password>' ftp://<url or IP>/files/keyfile -O /root/keyfile
fi

Replace <name>, <password> and <url or ip> with your actual username, password and ftp server address

 

Thanks for the help

Link to comment
  • 4 weeks later...

Thanks for the info! I have been toying around with running 2 unRAID servers (One on a Dell R710, one on my primary Desktop w/ VM's getting passed hardware) and I took what you did and built upon it. We will call these servers U1 and U2. Both have a static IP and are plugged into a switch. U2 has a share named U1-key and U1 has a share named U2-key. Both have corresponding secure accounts. If both are on and I reboot U1, upon boot it reaches out to U2 and gets its key. If both are on and I reboot U2, it reaches out to U1 and gets its key. If both are off, I boot both and manually start the array on U2 (much faster boot time) and by the time U1 is up, it pulls its key from U2. Seems to be working well for me so far. Best of all, with this setup, if both are off (as would happen if someone walked off with my server rack), both keys are on encrypted drives, so the neither of them should be able to be booted without my key.

Link to comment
47 minutes ago, bamhm182 said:

Thanks for the info! I have been toying around with running 2 unRAID servers (One on a Dell R710, one on my primary Desktop w/ VM's getting passed hardware) and I took what you did and built upon it. We will call these servers U1 and U2. Both have a static IP and are plugged into a switch. U2 has a share named U1-key and U1 has a share named U2-key. Both have corresponding secure accounts. If both are on and I reboot U1, upon boot it reaches out to U2 and gets its key. If both are on and I reboot U2, it reaches out to U1 and gets its key. If both are off, I boot both and manually start the array on U2 (much faster boot time) and by the time U1 is up, it pulls its key from U2. Seems to be working well for me so far. Best of all, with this setup, if both are off (as would happen if someone walked off with my server rack), both keys are on encrypted drives, so the neither of them should be able to be booted without my key.

 

Very thoughtful solution, but I am wondering if there is a security flaw. ?

 

If somebody takes steals both the servers U1 and U2. Next connect and power them up on some local network then key exchange/unlock would take place as normal?

 

Link to comment
4 minutes ago, bonienl said:

 

Very thoughtful solution, but I am wondering if there is a security flaw. ?

 

If somebody takes steals both the servers U1 and U2. Next connect and power them up on some local network then key exchange/unlock would take place as normal?

 

Chicken and egg. Take a closer look at his scenario, it requires one of the servers to be fully started with the key before the other will auto start.

 

The only exploit this is vulnerable to is a high level government type exploit that keeps the servers running seamlessly with synchronized switchover power while they are being transported.

Link to comment
7 minutes ago, jonathanm said:

The only exploit this is vulnerable to is a high level government type exploit that keeps the servers running seamlessly with synchronized switchover power while they are being transported.

 

I guess we are not talking about the average unRAID user when such an extensive operation is required by the government :)

 

Link to comment

 

14 minutes ago, jonathanm said:

The only exploit this is vulnerable to is a high level government type exploit that keeps the servers running seamlessly with synchronized switchover power while they are being transported

You'd be surprised. A well prepared team of three can do this and transfer the entire Rack (still powered up running on batteries) across the block between buildings. We did something similar before, but decided to power down in the end lessen the risk of corrupting data.

The trick is that most high end server deployments have redundant power inputs at the rack level, so you can unplug one input, move the rack, plug it in and unplug the remaining one, rinse and repeat. This will also let you swap UPS/batteries while keeping the system running. :D

.

Link to comment
32 minutes ago, ken-ji said:

This will also let you swap UPS/batteries while keeping the system running.

 

I have been moving servers between rooms using this trick. Very useful to have redundant PSU on machines.

 

Next step up in security is to have the machine geo-locked - have it listen for BluTooth, WiFi or similar and unmount if the geofence test fails.

Link to comment
1 hour ago, bonienl said:

 

What about a motion detector in the case?

 

Could work, but not easily. If you use IR movement sensors and have a glass side panel, you are likely to trig it yourself. And if you haven't, then the IR detector wouldn't notice anything until you open the case.

 

So it would then have to be some kind of orientation/vibration sensor that detects that the case is lifted up. Mercury switches are easy to use, but forbidden in most parts of the world. So next step then would be either switches with a rolling ball, or stepping up to semiconductor sensors - 3D compass or 3D accelerometers or similar. But it would still take a bit of work to make the sensor trig if the computer is carried away but not trig if you just want to dust the machine or replace a HDD.

Link to comment
7 hours ago, ken-ji said:

You probably want a GPS/Cell tower sensor instead. It won't trip in the same locality (adjacent room, up from the basement, etc) but still be able workout that its being moved a bit of a distance away. :D

 

 

A Bluetooth beacon works quite well, since it's usable on both laptop and desktop machines - it's easy to add a USB receiver for machines that hasn't BT built in.

 

Right now, I can have my Linux machines lock down if I walk outside range with phone or headset. And with a fixed BT beacon at home/office, a laptop that is moved outside the range of the beacon will lock down. I haven't figured out how to get the same functionality on my Windows machines yet.

 

The advantage with BT is that I can walk around to a neighbor room with a laptop without it activating the lock screen.

Link to comment

Upon reading through the rest of the posts, I decided it wasn't NEARLY secure enough. Now I just need to figure out the steps to have my cellphone's presence on the LAN prompt the server to request that I insert and touch my YubiKey U2F. If my phone is not present, the server wouldn't care about the YubiKey. Only after the YubiKey is inserted and verified, will the server care about its attached retinal and finger printer scanners, which are the final key to decrypting the first server. Now the only way to get anything off of there is to... Steal me as well? God forbid I need to ask someone to boot my servers while I'm out of town because of a power outage. Haha

Link to comment
On 5/4/2018 at 6:42 AM, bamhm182 said:

attached retinal and finger printer scanners, which are the final key to decrypting the first server.

Just an FYI, in the USA, you can be compelled by a court to provide biometrics, you CANNOT be compelled to reveal a password, as fifth amendment protection is applied to things you know, vs. things you possess such as keys or fingerprints. It would be best to add a passphrase to your well rounded security protocols. A fully formed sentence is good, lots of characters so little chance of brute force, and it can be quite memorable to yourself as well. "Twelve purple elephants dancing in the moonlight."

  • Like 1
Link to comment

I think the optimum would be if ControlR or similar would support handing over parts of the required secret - so the phone could be used to manually enter a partial sign-on to acknowledge the startup of the server. A bit similar to how you use phone apps when doing two-factor login to banks etc.

 

I'm not worrying about any police - but I'm constantly wary of the almost infinite number of security holes constantly being found, and I don't want some two-bit hacker being able to retrieve full key material just by a bit of luck and some hole in some software module. And it's too easy to sneak in keyboard loggers.


The only way to ever get reasonable security is by designing systems with multi-factor login - it's way harder for someone to be able to listen to both a PC keyboard and a mobile phone.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.