[BBLISA] whole disk encryption
Edward Ned Harvey
bblisa4 at nedharvey.com
Mon Aug 23 10:36:05 EDT 2010
I had a compatibility problem with Acronis TrueImage, and TrueCrypt.
Supposedly, however, there is no problem with BitLocker. I won't be able to
actually *test* that until later today, or tonight. I'm starting BitLocker
now, and thought I'd share ...
Bitlocker is different than I expected, in a kinda cool way. The cool part
is not so much BitLocker, but the TPM. My expectation, which seems to be
pretty consistent with everything else, is that you have to type in a
password to decrypt your encrypted drive. But the TPM does a much cooler
job... making it so you don't need to do anything at all, and still the
system is trusted secure. Although BitLocker uses the TPM, it's not the
*only* thing that can use it. AFAIK, there's nothing preventing other
encryption tools from using it too. Here's a useful article, and my summary
of the important points:
http://windows.microsoft.com/en-US/windows-vista/BitLocker-Drive-Encryption-
Overview
TPM is a piece of hardware, kind of like a BIOS-level usb boot disk. It's
disabled by default in BIOS. If enabled, during power-on, it will read
certain blocks of the hard disk, compute a hash and compare against
previously computed values, to verify the OS hasn't been tampered with. If
successful, it will then make itself readable one-time, so the OS can fetch
the encryption keys. And then the OS is able to decrypt the hard drive.
You are relying on the OS to provide login security. An attacker can't read
your drive by removing it from the computer. The only way to read your
drive is to boot from it, untampered, with TPM enabled, on the same computer
where it was first enabled.
The obvious fears are: (a) What if I intentionally reinstall or change my
OS? and (b) What if my laptop dies and I need to read that hard disk in
another computer?
(a) If the TPM checksum fails, the TPM simply doesn't release the keys. If
you're intentionally running some other OS, it will still work, as long as
it has no need for your encryption keys. But if you intentionally tamper
with your OS ... like ... install a custom MBR or change the boot partition,
or something like that ... You better carefully consider whether it will
cause a problem, and how to handle it. I don't know that level of detail
right now. You can always avoid every problem by decrypting your drive
before making such changes, and then re-encrypting your drive afterward.
But there may be faster or better ways to handle such situations when they
occur.
(b) If the hard drive is removed from the computer, it's not readable,
because the encryption keys are not known. But during the process of
enabling the TPM, you had the option of saving your keys to a file, which
your IT person has surely done, and saved in a secure location. ;-) So
your IT person can attach the drive to another computer and read it, but an
attacker would have a hard time.
If desired, you can deploy BitLocker via Group Policy. I don't know how to
do that, and I don't know what implications it may have.
If desired, you can do all sorts of other cool stuff, like require a
password or PIN or a smartcard, in addition to the untampered OS, to unlock
TPM.
If desired, you can use things like PIN or smartcard or biometrics as a
windows authentication augmentation. Configuration of such features, at
least on my system, are pretty brainless and simple. I'm sure this can be
deployed by Group Policy too, but there's a simple software tool under the
start menu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.bblisa.org/pipermail/bblisa/attachments/20100823/f223141f/attachment.html
More information about the bblisa
mailing list