# Encrypted storage on a server

## pa4wdh

Hi All,

I'm setting up a home server and i want to protect some data by using disk encryption on some logical volumes, but i'm a bit in doubt on how to do that.

As far as i can find there are two methods:

1) Make cryptsetup ask for a password. Seems safe, but i don't want my server to halt during the boot process asking me for the password on console

2) I found something about keyfiles which allows automount, but then i'll have to store the keyfile on the same disk which in my opinion doesn't make sense since everybody will be able to mount the encrypted parts.

How did others solve this problem ?

Thanks in advance.

----------

## Hu

There is no way to ensure that the system can automatically access those volumes without human intervention and simultaneously guarantee that the volumes are only accessible when you want them to be accessible.  You could have a volume which is accessible only after a user logs in and runs cryptsetup to unlock it, but if you want an unattended boot and boot time access to your data, then you cannot avoid others being able to boot the machine and access the data without your consent.

You might be able to use a TPM, if you have one, to ensure that the system can access the data only when it boots an approved configuration.  However, if the approved configuration is not hardened to resist unwanted access, this does not help you.

----------

## pa4wdh

Thanks for your answer.

I understand what you're saying, that's exactly the problem i'm seeing.

TPM is not available in my system, and i also think it wouldn't help. The system i have is quite small, if someone would steal it they'll take the whole thing instead of the hard drives only.

After thinking a bit further, maybe there is a possible solution with the keyfiles. For example, if it is stored at a removable device i could make it mount the encrypted stuff only when the removable device is present. An other option could be to make sure networking is started before mounting the encrypted volumes so the keyfiles can be scp'ed from an other host. In that case i can still control the keyfiles when the system is stolen and i can remove them, disable the scp access or change the keyfile to make the data unreadable.

----------

## cach0rr0

 *pa4wdh wrote:*   

> 
> 
> 2) I found something about keyfiles which allows automount, but then i'll have to store the keyfile on the same disk which in my opinion doesn't make sense since everybody will be able to mount the encrypted parts.
> 
> 

 

use a keyfile on removable media

take the removable media with you

once the volume is unlocked you can take the media out even when the system is running

that would be my solution

----------

## Hu

Using a TPM would allow you to ensure that the automatic mount of the volumes succeeded only when booting an approved configuration.  This would preclude an attacker booting with a custom environment, such as a LiveCD, and accessing the keys.  An attacker who tried this would find that the TPM would refuse to yield the keys.

The removable media idea works well if you are willing to accept the need to return to it when you want to boot it.  In my opinion, there is little difference between going to the machine to give it the removable media versus going to the machine to type in the password.  Both are inconvenient and prevent a truly unattended boot.

----------

## pa4wdh

@Hu:

Since the server is in my home there is a big difference: I'll have to type a password via the (serial) console to which i don't have remote access. In case of a keyfile on removable media if i foresee a remote initiated reboot i can choose to leave the removable media in the server for that day, taking the risk that if the server is stolen that specific day that they have access to my data.

I'm still trying think of a way to make the scp idea working.

For example:

Mount a tmpfs at /tmp/keys

scp keys from remote server (at physically different location) to /tmp/keys

mount encrypted fs's

umount /tmp/keys so there is no copy of the keyfiles left

Maybe i'll need some way to make sure that the memory which was in use by the tmpfs gets erased so the keys can't be recovered from memory.

In this way the keys will only be available during mount, which will be very short. The risk that the keys copied during that time is very small i think.

----------

## tuber

I have a similar topic at Entering Password on a System with Full Disk Encryption

----------

## luckylinux

Not sure if this helps but I thought I'd say what my current solution is.

(Currently using FreeBSD but with Gentoo it should be even easier)

I have my root on two encrypted disks which I unlock via IPMI at boot. In your case I'd just leave them unencrypted so that the boot process wouldn't be stopped.

Then I have all my data on another volume (6 HDDs RAID6) which I unlock via passphrase. You could simply create a bash script that asks you for the volume password once and then unlocks all of the HDDs or just use LVM.

In my case since even the root volume is encrypted, I still feel it's a bit safer than your solution. On the other hand if you don't put any sensible informations in say /var and /etc you should be safe. It's also a matter of cost: an IPMI-equipped motherboard + CPU + ECC RAM may cost almost twice of the average Home server build's cost. Are you willing to do this? Encrypt everything like I did (and put the passphrase in at boot). You don't? Leave root unencrypted and encrypt only your data's disk(s). If the home server does only NAS encrypting "only" your data (which is what the NAS is for) should be enough. If you also store some account / password information / wireless authentication / VPN / ... (/etc mostly, some /var - mostly for logs) then full disks encryption may be the only solution.

Hope it helped. And as Hu said, there is no perfect solution to the problem. I'm also beginning to doubt the use of disk encryption if you leave the home server 24/7 (unless someone tries to physically steal your hardware) because your data may still be accessed via internet if you didn't setup security as it should.

----------

## pa4wdh

Thanks for sharing your experience luckylinux.

Switching to new hardware isn't really an option since the hardware i have is brand new and bought for this purpose  :Smile: 

I'm indeed trying to prevent against theft (so that they don't have access to my data if they steal the hardware).

I'm currently thinking this:

Let the server boot into the default runlevel with a minimal setup which includes remote access. This should be able to boot unattended.

Then create an additional runlevel (called server or whatever fancy name) which mounts the encrypted storage and starts everything which depends on that. This may be interactive since there is remote access. In this way when booted i can just switch runlevel to get everything up and running.

----------

## luckylinux

 *pa4wdh wrote:*   

> Thanks for sharing your experience luckylinux.
> 
> Switching to new hardware isn't really an option since the hardware i have is brand new and bought for this purpose 
> 
> 

 

Got it   :Smile: 

 *pa4wdh wrote:*   

> 
> 
> I'm currently thinking this:
> 
> Let the server boot into the default runlevel with a minimal setup which includes remote access. This should be able to boot unattended.
> ...

 

You didn't specify number of disks, RAID solution (if any), disk space, etc

Your solution with a custom runlevel seems somehow a little bit strange or kind of "out of the box" anyway. Since I'm not an expert, I'll leave others to comment your idea.

You didn't mention what you want to encrypt. If this is a NAS, a custom /data mountpoint might suffice. If this is a webserver then /var and possibly /tmp should be encrypted as well, which may pose some problem: your server may not function at all (except SSH) until you descrypt those mount points? A solution may be to move your services data to some unencrypted place for those services that are vital (but not critical for privacy purposes) to be started.

You can't do full disk encryption with what you described. You have to define exactly what you'd like to encrypt and start from there.

Start by listing which services your server will be running (Apache, MySQL, Samba, NFS, ...) and/or which functions your server should perform.

----------

## pa4wdh

 *Quote:*   

> 
> 
> You didn't specify number of disks, RAID solution (if any), disk space, etc 
> 
> 

 

Basically the setup is:

Two physical drives, each 1TB in size.

On this there are multiple software RAID-1 partitions:

md0 for /boot, no crypto needed

md1 for /, no crypto needed

md5 upto md9 for use with LVM for storage, some crypto needed

Within LVM i now have vg0 with a few LV's in it, one for swap, one for /usr/portage and one for /var/tmp/portage

swap is already encrypted because the keyfile can be just /dev/urandom because i don't need a static key for that.

Further need for encryption will be decided per LV.

One of the server functions will be NFS for my /home and maybe other stuff, this is where i want encryption. Since this is more of a hobby home server this list will grow for sure  :Smile: 

Of course server processes depending on the encrypted storage will not be able to start, i accept that and don't really care  :Smile:  As long as ssh works i can log in and do whatever necessary to get it up and running. To make that as simple as possible i thought an additional runlevel may help  :Smile: 

For my runlevel idea the dmcrypt init script seems to be able to do what i need since it allows to have multiple instances. So now i have dmcrypt.boot for the encrypted swap, and my server runlevel will have more entries for other encrypted LV's.

----------

