Ask Slashdot: How Would You Implement Site-Wide File Encryption?

Recently-leaked CIA documents prove that encryption works, according to the Associated Press. But how should sys-admins implement site-wide file encryption? Very-long-time Slashdot reader Pig Hogger writes: If you decide to implement server-level encryption across all your servers, how do you manage the necessary keys/passwords/passphrases to insure that you have both maximum uptime (you can access your data if you need to reboot your servers), yet that the keys cannot be compromised... What are established practices to address this issue?
Keep in mind that you can't change your password once the server's been seized, bringing up the issue of how many people know that password. Or is there a better solution? Share you suggestions and experiences in the comments. How would you implement site-wide file encryption?

Comments

Virtual Private Raid

[Zemran]

I wish that someone would develop a version of raid for use with servers. Have 3 VPSs in Switzerland, Russia and Holland and each one gets only a 3rd of each file. The chances of any government seizing all 3 is zero.

LUKS

[Anonymous Coward]

- Linux servers
- LUKS full-disk encryption
- All network traffic tunneled tunneled through some form of SSL (e.g. SSH or OpenVPN) with client authentication, and a decent IDS.
- Tiny custom binary in the initramfs that loads the "password" (a random 1024 bit binary string) from a USB serial device
- BIOS boot options locked down (no removable media boot, password required to change settings)
- Arduino with 6x AA batteries for power backup, a 3-axis accelerometer/gyro, an ambient light sensor & the sensor from an optical mouse, riveted to the inside of the chassis' outer shell, with a small hole in the bottom of the case for the optical sensor.
- As long as the Arduino is undisturbed (i.e. registers no movement or sudden change in lighting level) it will provide the decryption key on request, so the server can boot up unattended.
- As soon as the Arduino registers a disturbance (e.g. somebody moves or opens the computer case to reset the BIOS) it wipes the key from RAM and for the next boot you need to fetch a non-volatile copy of the key from a safety deposit box.

You can seize the servers, but by doing so you effectively render the data inaccessible, and nobody's going to remember the random 1024-bit binary string you need to decrypt one of them.

Trying to draw the specification for this or not .

[burni2]

If you decide to implement server-level encryption across all your servers,

This is basically simple you can build a server that does all encryption in ram, meaning the OS is loaded once then the encryption key is used to have it decrypt the content for the outside.

To stop tempering you could setup such a server yourself and equip it with various sensors that detect presence of people or tempering, and if detected it could shut down not compromising the encryption key to forensics.

Firewire(because of its DMA) needs to be disabled and unkown devices need to trigger a shut down event and must otherwise be ignored

con:
However this type of server would still emit the key data as radio spectrum.

con2:
The requesters question is quite sketchy, I suggest writting a specification first with the neccessary "must haves" and possible use cases.

my iscsi-encryption approach
So I can only explain my private approach, I got a root server with big harddrives and those harddrives are exported via iscsi that iscsi-connection is tunneled through ssh.

I de-/encrypt & mount the drives only on my home server and sync the directories with rsync. The harddrives are double encrypted meaning I have two encryption devices and two dependend keys.

This sounds slow, but it isn't I get nearly the full upload bandwith of my connection.

Meaning my root server never "knows" what data is backed up on it - its a "dumb" server

I would suggest a similar approach for the requesters situation, because it solves a first step, separating the encryption key from the encrypted data.

And a second step having two encryption keys making it more difficult to get all two if separated (which is contrary to my use case)

I would expand my approach there to have a "data" server, a level1 encryption server and a level2 encryption server.

level1 decryptes the first encryption layer and level2 does it with the data provided by level1

Usecase:
If only the data server is seized, shut down at least one of the intermediate servers along with its key and the data is inaccessible. And it doesn't matter which "key keeper" server you kill, its a fail-one-fail-all system.

The drawback is however the level2 encryption server shall not be compromised, because there all pure data is accessible.

encrypted backup
With todays highspeed connectivity the servers can be backed up by just cloning the harddrives over iscsi for example, that works quite well.

another idea
Most encryption providers from linux and bsd provide the possiblity of having more than one master key.

Iscsi can also work on image files so you can provide many independed iscsi-volumes and encrpytion can be outsourced to the users computers.