[BBLISA] Looking for FDE single system windows 8

[Edward Ned Harvey (bblisa4)]

> From: Jurvis LaSalle [mailto:jurvis at gmail.com]
> 
>> As long as you don't need the system to boot unattended.
> 
> erm wouldn't unattended boot require the system to decrypt the hdd itself
> and thus hold the keys itself? the req seems antithetical to FDE unless i'm
> missing something...

No.  That's one of the many things I love about BitLocker.  I have toured, giving talks on whole disk encryption.  Here is a super abbreviated summary on the bitlocker segment of the talk:

I once had a job, where the CEO instructed me to put padlocks on all the systems in the company, and to fill all the USB ports with hot glue (no kidding), disable all the CD burners, take away all the users' admin privileges, lock down the firewall.  Shut off the wifi.  Misguided though he may be, it brings up an interesting point:  Why can't you rely on the users' OS login and OS data restriction controls for security?  Simple:  Because the hard drive could always be removed from that system and put into another system, or booted from an optical or USB drive, in order to bypass the OS security.

So imagine, what if you had a laptop, and the entire chassis was filled with hot glue or concrete?  (Ignore heat problems)  It would be very difficult for somebody to get the storage out of there physically intact.  Suddenly it wouldn't be unreasonable for you to lock down the OS software and expect the system to remain secure.

The TPM is a chip on the motherboard, with its own CPU, its own nonvolatile storage, its own ram.  It's essentially a tiny little laptop, all filled with concrete, sitting on the motherboard, and the only way anything can interact with it is via a locked down secure communication bus.

An OS such as windows can encrypt its whole drive contents using some securely randomly generated key - but then the obvious problem is, how to get the key entered at boot?  The OS instructs the TPM, "Take a snapshot of the way I look now.  Checksum the boot record, the following disk blocks, the fact that I'm booting from the following HDD, etc.  Here, store this key for me, and don't let anybody other than me retrieve it."  During POST, the TPM is aware of which device has been booted from, and it checksums all the pre-boot blocks and other stuff, to determine that the boot sequence has not been tampered.  If and only if all those tests pass, then the TPM releases the key to the OS.

So, if the drive is attached to another computer, or if in any way, the TPM with the key in it is not available on a system trying to decrypt the drive, then decryption fails and recovery key must be typed in manually.  If somebody replaces the BIOS with a malicious version, then the TPM won't release the key.  If you boot from a CD or USB drive, TPM won't release the key.  Yes you can remove the drive and attach to another system - but then you'll have to manually type in the recovery key.

The three sticky points are:  By guaranteeing that the drive will only decrypt if it is booted from and untampered, you have moved the responsibility for security to the OS.  This means, if you use idiotic passwords or automatic login, or blatantly outdated OS lacking known security patches, you've got bad security.  If your motherboard fails and gets replaced, you just lost your TPM, so you'll need to enter recovery key and re-initialize the new TPM.  If you flash your BIOS, your pre-boot signature will fail and you'll need to enter recovery key.  If you know you're about to do either of these, you can temporarily disable bitlocker, do the needful, and then re-enable bitlocker (which rekeys the TPM).

For this reason, it's important to make sure the recovery key is stored somewhere safe and reliable.  (But you should have good backups anyway.)  Active Directory supports automatic enabling of Bitlocker, and automatic storage of recovery keys, via group policy.  But if you're not on AD, then you can just do whatever you need to do, in order to make sure your bum is covered - the bitlocker wizard requires that you save your recovery key off the C: drive before it will start encrypting.