About
Kimbro Staken exploring creative use of technology and whatever else happens to seem interesting.
Subscribe
RSS 
Projects
Friends Links
Categories
Archives
Encrypting file systems
I’ve been looking around at ways of encrypting file systems on servers. dm-crypt seems like a good way to go, however the big question for me is how do you handle key management? It’s great to have the data encrypted, but that key still needs to be on the system somewhere or else you hang if the system restarts. That was something that always bugged me about SSL certs that required a password to decrypt them when the webserver started. In order to have a self sustaining system you had to put the key somewhere which obviously defeats the whole point of encrypting anything. So if you had to build a system with application code encrypted on the drives, how would you manage keys?
This entry was posted by Kimbro Staken on Thursday, October 5th, 2006 at 10:16 am and is filed under Programming, Ruby. You can subscribe via RSS 2.0 feed to this post's comments. You can comment below, or link to this permanent URL from your own site. Your comments will appear immediately, but I reserve the right to delete innapropriate comments.
October 8th, 2006 at 11:41 pm
That’s a feature, not a bug. If the key is on the system then it can be stolen along with the media, and your encrypting filesystem then just becomes an expensive way to burn CPU cycles with no security value whatsoever.
October 10th, 2006 at 12:50 am
dm-crypt has had security problems in the past, so I’d recommend loop-aes (http://loop-aes.sf.net).
You’re still required to enter a passphrase when you mount the encrypted file system, because as Steve Holden said, otherwise it’s not worth doing (you also have to make sure you use a secure passphrase, of course).
This is no problem with key management, but a problem of convenience. You can still build a *highly available* system by putting redundancy in the right places, though.