> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org] > On Behalf Of David Lang > > Full disk encryption of local drives on the servers would theoretically give > you > similar protection, except that people are very reluctant to have servers that > cannot boot up without human intervention, and for most servers, it's easier > to > steal (or dispose of) the entire server, and the drives have everything on
I've given a few talks on this subject, and it's always fun - but your comment about human intervention suggests I haven't given that talk to you. ;-) There are many ways to implement non-interactive whole disk encryption, but the one I talk about is bitlocker. It goes like this: Years ago, when I was working at an IT consulting gig for a semiconductor company, the CEO of the company asked me to lockdown the development environment. Disable CD burning, restrict access to the internet, funnel everything through a proxy, log it all, fill the USB ports with hot glue. Seriously, fill the usb ports with glue. And put locks on the chassis so users can't easily open them up to access non-USB ports. Etc. The problem has always been physical security. If somebody steals your laptop and takes out the hard drive, then they get to bypass all the security you might have enabled in your OS. But if you similarly take your laptop and fill the *whole chassis* with hot glue, then you sort-of eliminate the problem. Not really, cuz of course, people can use cutting tools to extract the HD from the glue, etc. But it becomes more difficult to implement this type of attack vector. Enter the concept of the TPM. The TPM is basically a teeny tiny computer, sitting on your motherboard, which is its own separate, entirely isolated and filled with concrete little computer. It has its own cpu, memory, and nonvolatile storage. The only way to interact with it is via a bus on your motherboard. The TPM is all contained within a single chip. Virtually all systems nowadays have them. (Not apple). Your OS tells the TPM, "I have a secret key I want you to store, and don't release it to anybody except me." The TPM takes your fingerprint, in the form of some black magic - A checksum of your bios, which device you boot from, all the non-encrypted blocks at the beginning of the hard drive, and some of the encrypted blocks. So if the hard drive is moved to a different computer, of course, the new TPM doesn't know the key. So that attack vector fails. If you boot from a different device in the right computer, then the fingerprint checksum fails, and the key is not released. If you hack the BIOS, or hack the OS, or basically do anything to modify the boot process, then the system fingerprint fails, and the TPM won't release the key. The end result is: Now you can trust your security as much as you trust your OS. If you have a hardened OS with strong password policy, etc, suddenly those features *matter* even when the system is physically in a hostile environment. You get to boot your system without human interaction. Strong keys, strong encryption all around. It's a very good solution. The most obvious drawback: What happens if your motherboard dies and you get the motherboard replaced? Well, your system won't boot. So whenever the TPM fails to release the proper key, the OS handles it by prompting you to type in a key. This is a 40-digit long random string of digits. I didn't mention before, that part of the process to enable bitlocker includes saving a copy of the decryption key somewhere. You have a few choices - the best one in any sort of scale environment is to store all the bitlocker keys in AD automatically so the helpdesk folks can take support calls from users with locked laptops and read the key to them over the phone. You have to be careful about applying BIOS updates. Because that will invalidate the checksum and lock the system. You need to know, before applying the bios update, you go into control panel and toggle bitlocker off (temporarily disabled, by storing the key in plaintext on disk). Then apply bios update, and after successful reboot, re-enable bitlocker. (Which re-keys so you don't have to worry about the previously unencrypted one being compromised by reading free blocks of the unencrypted disk.) But of course, *during* the period of time when you have bitlocker disabled, you're vulnerable. The whole idea is, that should be a matter of minutes, during which, you personally keep the system physically secure. I've been, step by step, very impressed with the implementation of bitlocker. Even when you disable and re-enable bitlocker, requiring re-keying... They don't actually store the *key* on disk. They just store a key that can be used to decrypt the real key. So when you re-key, it's a near-instantaneous operation. They select a new key1, re-encrypt key2 using the new key1, so even if somebody were to later discover the plaintext key that was formerly written on disk, it would be irrelevant. Because the ciphertext that the key was able to unlock no longer exists. There's only a new ciphertext, and a new key, which was never written to disk. And in fact, your TPM doesn't know your key either. The TPM only knows the key that can be used to unlock the real key. So once again, re-keying your TPM is near instant. Doesn't require re-encrypting the whole disk. Just a tiny block. _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
