Adding an Encryption Layer


Recommended Posts

To kick this off, following is email from forum user "doron":

 

I'm trying to add an encryption layer into unRAID (you may have seen some discussion about that on some threads in the forum). The requirement is to have some or all of the drives in the array encrypted, while still enjoying the nice features of emhttp (e.g. user shares etc.).

 

Basically, I'm trying to add an encryption layer on top of the md devices and "under" emhttp. This will be triggered upon boot to crypto-mount the drive. So far, this has not been fully successful. For example, in my last attempt I created a TrueCrypt volume on top of /dev/md1, created a ReiserFS on it, then mounted it as /mnt/disk1 . That part actually works well (so in effect I do have a protected encrypted volume), but then emhttp barfs at this setup. He doesn't like a disk that's formatted but not by him, or that's mounted but not by him. I can get the array into maintenance mode but not into operational mode.

Obviously - this is how emhttp was designed and how it works.

 

I'd be grateful if you could relate to a few questions:

 

1. Is there hope to what I'm trying to do, in the current version? Will "event" type plugin scripts help in any way? From what I've seen they won't, but I might be missing something.

 

2. Will you be open to allowing such a layer between the md drives and emhttp in a near-term upcoming version? An ideal candidate for this layer would be dm; if emhttp would be willing to accept a dm layer between its md's and it's upper-layer functions, I'd then be able to use e.g. dm-crypt and LUKS.

 

3. Another possibility is to place the dm layer *under* the md's. This is less desired (weakens the security aspect) but may still be better than nothing. Would that be an option, you think?

 

I'd be grateful for any help or insight you can extend on this one. Obviously anything I come up with would be released back into the community (could be a plugin?). For me, this feature is the single one that will cause me to put the other foot on the boat and sail with unRAID.

 

(btw, you may have seen the "top two items" thread I started on the forum - if not, might be helpful to you).

Link to comment

3. Another possibility is to place the dm layer *under* the md's. This is less desired (weakens the security aspect) but may still be better than nothing. Would that be an option, you think?

 

Why would this weaken the security?

 

Because e.g. if you encrypt disk1 (only) in this method ("under" the md), and the parity and disk2..diskn remain clear, then the clear-text data of disk1 can be computed (so encryption is compromised). If you encrypt disk1+disk2 and leave parity and disk3...diskn clear, it does become much more complex but still allows for decent cryptoanalysis. Only if you encrypt all of the drives, will you match the security of encrypting from "above" md.

 

The point is that parity is computed at the md level; and in this alternative #3, it is computed off the clear text.

 

If on the other hand crypto layer lives above md, then regardless of whether you opt to encrypt one, two or all your drives, parity is computed after encryption is done (i.e. on crypto text for encrypted drives and on plain text on non-encrypted drives), so it does not give away anything.

Link to comment

Ok, that makes sense, thank you for the clarification.

 

So, to mount, instead of doing this:

 

mount /dev/md1 /mnt/disk1

 

It needs to be:

 

truecrypt -N 1 /dev/md1
mount /dev/mapper/truecrypt1 /mnt/disk1

 

To make the file system to start with, instead of:

 

mkreiserfs /dev/md1

 

Would need to be:

 

mkreiserfs /dev/mapper/truecrypt1

 

And to check the file system, instead of:

 

reiserfsck /dev/md1

 

would need to be:

 

reiserfsck /dev/mapper/truecrypt1

 

The above correct?

 

 

 

Link to comment

Pretty much, but let me make some comments.

 

So, to mount, instead of doing this:

 

mount /dev/md1 /mnt/disk1

 

It needs to be:

 

truecrypt -N 1 /dev/md1
mount /dev/mapper/truecrypt1 /mnt/disk1

 

This is presuming you choose truecrypt as your crypto layer. See below.

 

I'm not sure what the -N option stands for. The TC version I have does not have it. Could you be referring to the TC slot number? In that case, the version I have has this as "--slot".

 

Now, this stage is a bit tricky, cuz that's where you need to provide the crypto key. This could be a keyfile, or a passphrase. The latter is often expected to be provided at time of mount (manually); the former may be kept in /boot (hence allow for automatic mount upon server boot) or also be provided manually at time of mount. The choice depends on what your threat model is (if one is concerned about the entire box being lifted and taken away, then a keyfile that's on the boot flash drive will give itself away to the thief; if you're only concerned with individual drives being readable, then an on-server keyfile might just be good enough for you).

So bottom line, we should allow for an optional dialog at that point, if the user so chooses. Keyfile or passphrase can be provided on the command line, if obtained via GUI.

 

Next, to run this way, unRAID kernel and bzroot will need to contain the device mapper modules and tools. (To work around this, I used "-m nokernelcrypto" on the truecrypt command line.)

 

And last, truecrypt is but one option. A second one, maybe even a bit more convenient for us, would be dm-crypt. Towards that end, the mount command will look something like:

 

cryptsetup luksOpen /dev/md1 crdisk1
mount /dev/mapper/crdisk1 /mnt/disk1

 

Here too, the first line carries the keying process, so passphrase and/or keyfile are provided at that time. Either server-resident (so no manual intervention) or manually.

 

To make the file system to start with, instead of:

 

mkreiserfs /dev/md1

 

Would need to be:

 

mkreiserfs /dev/mapper/truecrypt1

 

Yep. Or its equivalent with dm-crypt (/dev/mapper/crdisk1 in the above example).

 

And to check the file system, instead of:

 

reiserfsck /dev/md1

 

would need to be:

 

reiserfsck /dev/mapper/truecrypt1

 

Yes, with same alternatives.

Link to comment

Adding Encryption Layer would be very nice features but I would like to see Encryption Layer for specific share instead of whole disk.

 

This actually makes a lot of sense as well. To implement this on unRAID user shares, block-level encryption layer will not be suitable (as user shares can span several drives, so you might end up with partially encrypted shares).

This would be better achieved with a file-level encryption system, such as eCryptfs or EncFS. Having such a filesystem under emhttp's share system could also be very nice.

Link to comment

+1 for an encryption layer

This (or rather the lack thereof) was the reason to retire my two licenses in the past.

 

I would like to encourage you to think of using LUKS/dmcrypt as that layer, not truecrypt.

LUKS is standard for all linux distros and recognized by enterprise organisations as an acceptable and proven standard.

 

Edit: ..not to want to start another wishlist here, but I'd also encourage you to enable more that reiserfs ...preferably zfs here (yes, one disk would make an individual zfs-pool and zfs-folder (fs) for unraid)

Link to comment

One thought.

 

An important aspect of unRAID (to me) is the ability in a disaster to remove and mount the drives in another system and read the data.... something impossible with striped RAID.

 

I am all for implementing an encryption layer (hell I really want it!), but it can't make the drives unusable for disaster recovery.

 

Link to comment

I would like to encourage you to think of using LUKS/dmcrypt as that layer, not truecrypt.

LUKS is standard for all linux distros and recognized by enterprise organisations as an acceptable and proven standard.

 

I agree.

 

Edit: ..not to want to start another wishlist here, but I'd also encourage you to enable more that reiserfs ...preferably zfs here (yes, one disk would make an individual zfs-pool and zfs-folder (fs) for unraid)

 

Might as well run FreeNAS / NAS4Free / SmartOS / OmniOS / etc. at that point.

 

A one man developer isn't going to be able to compete with 10,000+ developers working on the ZFS code / those Distros.

 

Once BTRFS Raid 5/6 is marked stable... That would be a better option if you ask me.

 

You get all the benefits of ZFS (Compression, Encryption, Efficient Incremental Backup, Online filesystem defragmentation, Dynamic inode allocation, Copy on Write, Snapshots, Subvolumes, Deduplication, single / double parity, etc). Not to mention, expanding / shrinking / adding drives / removing drives is simple without all the headaches that ZFS has.

Link to comment

One thought.

 

An important aspect of unRAID (to me) is the ability in a disaster to remove and mount the drives in another system and read the data.... something impossible with striped RAID.

 

I am all for implementing an encryption layer (hell I really want it!), but it can't make the drives unusable for disaster recovery.

 

I totally aggree.

However LUKS/dmcrypt is working on individual drives, so not an issue there.

With using ZFS you will simply use the Filesystem features (like copy-on-write, snapshoting without overhead, ..) and not the raid features of zfs, forming pools out of single disks, hence.

Link to comment

Edit: ..not to want to start another wishlist here, but I'd also encourage you to enable more that reiserfs ...preferably zfs here (yes, one disk would make an individual zfs-pool and zfs-folder (fs) for unraid)

 

Might as well run FreeNAS / NAS4Free / SmartOS / OmniOS / etc. at that point.

 

Yes, I've been there, done that when I retired my unRAID sticks.

Currently I am on Debian Wheezy with ZoL...works like a charm.

 

A one man developer isn't going to be able to compete with 10,000+ developers working on the ZFS code / those Distros.

 

Agreed...my thought was that it's all about employing the different layers/components in the right order...then enable emhttp to work with the disk-nodes  and to run the corresponding FS commands.

I did not mean to create a new technology...just use what is there.

 

Link to comment

Maybe you should have a look at encFS.

Although it doesn't look like it is under active developement (look in the SVN).

Maybe because it is a FUSE FS it creates less problems than solutions like DMCrypt etc.

 

Also it work on per file basis, so that means easier desaster recovery. You can just pull out the datadrive, hook it up to another Linux PC or Mac (or even Windows PC althought a bit buggy) and than decrypt your files.

Link to comment

Just wanting to throw my hat in the ring as desiring encryption. In my picture perfect world unRAID, upon bootup, would require a password input at the console, and then afterwards behave as it does now to the end user. My specific desire is to prevent someone from stealing my drives and being able to do something with them and I would be willing to accept that if they access them while powered on and the password entered by me at boot that they would see data. Walking off with my drives will almost certainly require a power cycle and allow the crypto to kick in :-) I don't want my PC endpoints to have to fiddle with the crypto.

 

I'm not particularly picky about which crypto is used so long as it's standards based and reasonably supported. I agree that being able to access individual drives pulled from the array would be desirable and I'd like to keep that with the understanding that I'd be required to provide a password to decrypt and access.

 

I've asked about this before and not gotten very far, I'm very happy to see others pushing this forward as I do not have the skill to nor the time. I admit that encrypting my drives makes me a little nervous as I realize a burp could render them bricks but I feel fairly comfortable with it and would probably test on a separate system until comfortable just in case.

Link to comment

I definitely do NOT want the PW to have to be entered at the console.  unRAID itself should boot w/o PW, and then the array simply will not autostart... you must enter the PW in the GUI.

 

I agree with this as I think there must be a simple, convenient  interface for the User.

Also, it is common that the disks are encrypted individually.

No-One really wants to enter the PW once per disk (assuming you have used the same PW for all of course  ;) ) for a larger array.

 

The beauty is that with LUKS/dm-crypt this can be done easily.

Link to comment

I definitely do NOT want the PW to have to be entered at the console.  unRAID itself should boot w/o PW, and then the array simply will not autostart... you must enter the PW in the GUI.

Additionally, it would be nice if the connection from the GUI on the browser to the server would be https:// as that would allow startup on a less secure LAN without broadcasting the password in the clear on the LAN.
Link to comment

I definitely do NOT want the PW to have to be entered at the console.  unRAID itself should boot w/o PW, and then the array simply will not autostart... you must enter the PW in the GUI.

 

I could go with that as an easier alternative. At the end of the day I don't want a thief to have usable data and so long as the volume is encrypted that serves my goals. What *I* do not want is to have to apply crypto keys or push past password prompts at each of my end points. Computers attaching to the array when credentials have been offered to it at boot system start shouldn't have to be aware of the encryption. No mounting of special file volumes etc.

Link to comment
  • 3 weeks later...

I agree with this as I think there must be a simple, convenient  interface for the User.

Also, it is common that the disks are encrypted individually.

No-One really wants to enter the PW once per disk (assuming you have used the same PW for all of course  ;) ) for a larger array.

 

The beauty is that with LUKS/dm-crypt this can be done easily.

 

I agree and tested it in Arch / CentOS with unRAID "baked" in (with some changes to the Linux Kernel). It works as advertised.

 

emhttp would need to be updated to accommodate it and make it seemless / user friendly. GUI Interface, use /dev/mapper, pass-phrases, key-files, truecrypt, etc.

 

Someone should probably add this "feature request" in the unRAID CentOS 64 Bit Edition thread.

Link to comment
  • 5 weeks later...
  • 3 months later...
  • 7 months later...
  • 4 weeks later...
  • 6 months later...

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.