That's the most useful explanation of "why one might choose to have TPM" I've ever read.
On Mon, May 27, 2013 at 11:35 PM, Edward Ned Harvey (lopser) < lop...@nedharvey.com> wrote: > > 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/ >
_______________________________________________ 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/
