Where does disk encryption stand?


Recommended Posts

I have been watching this thread and I wonder, how is it that FreeNAS/ZFS can have encrypted drives and autostart the NAS volumes without requiring the user to supply a password or a keyfile?

 

Not trying to cause problems, just curious how it is that they can do it?

 

Thanks!

 

Edited by tuxfania
Line added
Link to comment
6 hours ago, tuxfania said:

I have been watching this thread and I wonder, how is it that FreeNAS/ZFS can have encrypted drives and autostart the NAS volumes without requiring the user to supply a password or a keyfile?

Why would you want an encrypted volume that doesn't require authentication of some kind to decrypt?

Link to comment

But autostart pretty much means that nobody has to authenticate. If it will start up automatically with all the data accessible, how is that secure?

30 minutes ago, tuxfania said:

It must do some sort of authentication, I just don't know how? :)

Authentication means that someone has to authenticate before the data is accessible, so it's unclear what you are really asking for.

Link to comment

I guess another possibility is some sort of "dongle" that can be removed and put in some secure place when the data needs to be locked. Is there anything like that going on?

 

And of course there are other hardware solutions possible, like some sort of biometrics. It would still require a person to do something before it could "autostart" though, so not really autostart as it's usually meant.

 

Keyfile, password, dongle, biometrics, etc. All types of authentication that requires somebody to intervene to unlock and/or lock the data. So not completely automatic and it couldn't be secure if it was completely automatic.

Link to comment

Answered my own question...I went back and reviewed the video I saw it in...it's basic encryption using a GELI key stored on the boot drive, not passphrase encryption which would require that be entered at boot.

 

They suggested basic encryption since it's helpful to use in the event a drive fails and you have to send it in for warranty...you don't have to worry about the data on it being read.  The basic encryption wouldn't help if your rig gets stolen.

 

Link to comment
1 hour ago, tuxfania said:

Answered my own question...I went back and reviewed the video I saw it in...it's basic encryption using a GELI key stored on the boot drive, not passphrase encryption which would require that be entered at boot.

 

They suggested basic encryption since it's helpful to use in the event a drive fails and you have to send it in for warranty...you don't have to worry about the data on it being read.  The basic encryption wouldn't help if your rig gets stolen.

 

 

This can be accomplished by saving your encryption keyfile somewhere on your USB flash boot device, maybe in 'config' directory.  Then edit your 'go' file and put this just before emhttp is started:

 

ln -s /boot/config/keyfile /root

 

Edit: be sure and make a backup of your USB flash device: Main/Flash click Flash Backup to download a zip of your USB flash contents.  Note that this zip file can be fed into our USB Creator tool if needed to migrate to a new USB flash device.

Edited by limetech
Link to comment
6 hours ago, limetech said:

 

This can be accomplished by saving your encryption keyfile somewhere on your USB flash boot device, maybe in 'config' directory.  Then edit your 'go' file and put this just before emhttp is started:

 


ln -s /boot/config/keyfile /root

 

Edit: be sure and make a backup of your USB flash device: Main/Flash click Flash Backup to download a zip of your USB flash contents.  Note that this zip file can be fed into our USB Creator tool if needed to migrate to a new USB flash device.

Thanks...this was very helpful!  :)

 

Link to comment
  • 3 weeks later...
On 9/4/2018 at 12:11 PM, limetech said:

 

This can be accomplished by saving your encryption keyfile somewhere on your USB flash boot device, maybe in 'config' directory.  Then edit your 'go' file and put this just before emhttp is started:

 


ln -s /boot/config/keyfile /root

 

Edit: be sure and make a backup of your USB flash device: Main/Flash click Flash Backup to download a zip of your USB flash contents.  Note that this zip file can be fed into our USB Creator tool if needed to migrate to a new USB flash device.

I tried this method and cannot get it to automatically start the array?

 

I copied the file I am using as the keyfile (Pic.jpg) to the config directory on the USB flash drive and editted the go file as suggested adding the line:

 

ln -s /boot/config/Pic.jpg /root

 

right in front of the emhttp line...after reboot, the system starts, but the array remains stopped.

 

Any idea what I might be doing wrong?  Should I not use an image file as the keyfile?

 

Thank you!

 

Link to comment
35 minutes ago, tuxfania said:

I tried this method and cannot get it to automatically start the array?

 

I copied the file I am using as the keyfile (Pic.jpg) to the config directory on the USB flash drive and editted the go file as suggested adding the line:

 

ln -s /boot/config/Pic.jpg /root

 

right in front of the emhttp line...after reboot, the system starts, but the array remains stopped.

 

Any idea what I might be doing wrong?  Should I not use an image file as the keyfile?

 

Thank you!

 

Need diagnostics.zip

Link to comment
3 hours ago, trurl said:

maybe if you shared it would help others

 

Sure, glad too...

 

I wanted to encrypt my volumes so if a drive failed, I could simply pull the disk and send it in for warranty repair.  This is ideal in the event of a mechanical failure of the disk as the data has been stored encrypted...I don't have to worry about anybody at the factory reading it.  I also wanted the array to autostart on boot/reboot...

 

LimeTech gave me the following advice:

 

This can be accomplished by saving your encryption keyfile somewhere on your USB flash boot device, maybe in 'config' directory.  Then edit your 'go' file and put this just before emhttp is started:

 

ln -s /boot/config/keyfile /root

 

Edit: be sure and make a backup of your USB flash device: Main/Flash click Flash Backup to download a zip of your USB flash contents.  Note that this zip file can be fed into our USB Creator tool if needed to migrate to a new USB flash device.

 

-----

 

So, I copied the key file to the area suggested, renamed it to keyfile and editted the go file with WordPad to insert the suggested line.

 

Once I did that, the array autostarts on reboot!  :)

 

Not helpful if my hardware gets stolen, but good enough for dealing with disk failure/warranty work.

 

Edited by tuxfania
Additional Info
Link to comment

Sorry about that, I should have looked at your post more carefully, specifically this line:

 

 ln -s /boot/config/Pic.jpg /root 

 

Yeah that won't work.  You can rename "Pic.jpg" to "keyfile" or you could use this:

 

 ln -s /boot/config/Pic.jpg /root/keyfile

Maybe this provides a little more "security by obscurity".

  • Like 1
Link to comment
  • 2 months later...

I have a complicated question, but, I hope there is a simple answer. 

 

I have an array of 8x8tb drives, dual parity (6+2), ssd cache. 

 

When I had 7 drives, one of them went out of sync (cable/power bump) and I was low on space, so I bought an 8th.

I enabled encryption on the new drive, none of the others are encrypted. 

I added it to the array just fine, and, then used unbalance to move the data off the emulated drive. (incase i messed up the rebuild/re-add).

I tested (heavily) and pre-cleared the out of sync drive to be safe, and was going to re-add it, as a new drive, encrypted. (Had not gotten around to it, and was unsure how best to do so. That procrastination likely saved me more dataloss in this case.)

 

The problem came today when I had to shut down the array. Like an idjit, of course, I forgot the passphrase.

 

I have tried, methodically, over 170 passphrases in iterations I would/should have used. I will try some more tomorrow before calling it moot, but, wanted to ask the best way to minimize the loss if it doesn't work. 

 

There is only about 3-4tb data on the encrypted drive... and I think I can replace most of it easily. 

 

What is the best way to bring this back online, encryption off/lost, with the 4x8TB of existing, un-encrypted data, then add the two "new" drives, then the dual parity. 

 

I am assuming a 'new config', no parity drives, no encrypted drives, just the 4x8tb as a fresh array (with data), then add the two as encrypted, stop, and add the 2 parity, and let it calculate parity all at once. (Preserve cache+data slots? or near-blank slate new?)

 

I am aware I will lose the data on the encrypted drive, and, the emulated (empty) drive should lose nothing. I just do not want to lose the other 4x8tb (about 28tb data). I am fairly sure this can be done. And, yes, I will be using a keyfile with a backup after this. My memory is simply not sharp enough anymore. The purpose of the encryption is simply warranty snooping protection, so, I do not need to keep my tinfoil on that tight in this case. I will assume, also, that the parity drives are holding the encrypted raw bits/sums so, the parity atm would be of 0 help.

 

 

Note on system:

I was about to move the entire unraid into a new PC, as it has been in tinker-lab mode for a long time now. This is likely a good opportunity. I am just hesitant to make too many changes at once. It is currently (yes you can laugh.. but, it works..) an i5/8g low pro pc, sata ssd, 2x4port USB3 pcie cards, and 8x8tb external USB3 drives. They are a lil noisy in dual parity, and poor for heat, plus usb cables/8xpower adapters is easy to glitch/unsync.  But, it is only 50-60watts in use (all drives included.) I was about to shuck them, and put them internal to my old gaming rig, stripped for server use. (hexcore/16g, full tower, direct sata, dual ssd cache). To make the parity operation smoother/faster, I think the PC swap would be a bonus before adding the parity at least. The i5/USB setup has also been getting io loaded recently, especially with large amounts of nzb files.

 

After it is stable, I'll need to follow the remove-a-drive, replace with encrypted drive, one-by-one dance. I'm fairly sure each drive I do that to will be yet another fun parity/rebuild too. A dual parity check on the current system was about 26hours.

 

Moral/Lesson of the story.. encrypt first, and don't lose your flipping passcode.

serverinfo.PNG

Link to comment

I don't get why this problem was posted to the deprecated and now 3.5 months dead prerelease thread.

 

52 minutes ago, johnnie.black said:

Yep, but you can't add a new disk and rebuild a disable disk at the same time, and there's still bug where you get a nonsensical error when you try to do that.

I assume you couldn't begin the rebuild until Unraid clears the new disk. Just never heard of anyone attempting to do an ADD with a disabled disk in the array, and it never would have occurred to me to even try it.

 

And of course I always discourage this sort of approach:

2 hours ago, whitewlf said:

used unbalance to move the data off the emulated drive. (incase i messed up the rebuild/re-add)

since it is a tremendous amount of disk activity in addition to parity being written on a compromised array. Would have been better just to do the rebuild in my opinion.

 

And since we didn't get a diagnostic maybe nothing wrong with the disabled disk anyway and it could have been used as another source for the data in the event of a rebuild problem.

 

@whitewlf,

 

Moving/copying data from an emulated disk to other disks in the array has to read all the disks to get the emulated data, write destination + parity, then write parity again if it was a move in order to delete the data from the emulated disk.

 

Link to comment
3 hours ago, whitewlf said:

After it is stable, I'll need to follow the remove-a-drive, replace with encrypted drive, one-by-one dance. I'm fairly sure each drive I do that to will be yet another fun parity/rebuild too. A dual parity check on the current system was about 26hours.

Encrypting your data shouldn't be any more difficult than converting filesystems. Rather than point you to that extremely long thread, I'll just summarize the basic idea.

 

Once you get a disk reformatted to encrypted, it can become the destination for moving data off another disk. Then when that disk is empty it can be reformatted as encrypted, and become a destination for more moving. And so on. Many people have done this sort of conversion without ever needing to rebuild parity.

Link to comment
4 minutes ago, johnnie.black said:

No, you can't start the array, you get an error similar to "can't add and remove disks at the same time"

You can't start the array after assigning a disk to a new slot? That is sort of what I would expect and seems reasonable to me.

 

Or do you mean it will let you start the array after adding a disk, but then won't let you start it after replacing the emulated disk?

Link to comment
4 minutes ago, trurl said:

Or do you mean it will let you start the array after adding a disk, but then won't let you start it after replacing the emulated disk?

It lets you add a new disk and start the array with a disable disk (using the emulated disk, without rebuilding), it won't let you start the array if you try to rebuild a disable disk and also assign a new disk, that's expected, juts the error is wrong, since you're not removing any disks.

Edited by johnnie.black
Link to comment
  • 1 month later...

Ive bought a rasp pi and will set it up somewhere in my wlan area (and with power). Servicing a SFTP server on a non standard port.

 

Then i will encrypt all via keyfile and will load it via sftp on startup of unraid (into RAM). Good thing is, if someone takes the equipment away.. he cant start it. He knows there must be some sort of pc somewhere... but they wont find it... :D


PS: you can even put it in the earth... :)


PSS: If you complete paranoid about the keyfile stay in ram, you can just install a switch to make your breaker go incase of emergency.

Edited by nuhll
Link to comment
  • 2 months later...

So I am having some issues here with trying to change my encryption passphrase...I simply wanted to change my passphrase to something longer as my current one is too short to really be considered secure.  As far as I can tell, I can create passphrase up to 512 characters long and so I did via "cryptsetup luksAddKey /dev/md#" for all 13 of my HDDs(1 parity and 12 data drives).  I have confirmed that my new passphrase unlocks each individual drive by opening them in verbose mode and confirming that slot1(slot0 being the original passphrase) is unlocking the drives.  However when I reboot my unRAID server and try to unlock my array with the same new passphrase, it fails to start and says I have the wrong passphrase.  Am I missing something here?  I have a total of 13 HDDs for data and parity and 2 SSDs as cache drives.  Not sure if I need to add the same key for my cache SSDs but I dont know what path to use(/dev/?).  Can anyone point me in the right direction please?

I am running unRAID Version: 6.7.0-rc7 

Edited by Aegisnir
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.