Thanks again Jamie. Your responses are very helpful!
Why is the metadata stored in various locations? Is this some kind of
failure tolerance? Or a way to hide the metadata itself?
Curious, how does the BootMgr (or recovery dvd) know where the metadata
is
stored? Are there pointers stored somewhere, unencrypted?
It would also seem I should be able to distinguish metadata sectors from
the
encrypted ones, since the metadata wouldn't necessarily use the entire
sector, and the rest would have to be noticably padded somehow...
Thanks!
:
"Where is metadata stored?"
This may vary from volume to volume. A copy is stored, approximately,
at
0/3, 1/3 and 2/3 of the volume, but depends where free space exists on
the
volume at the time the volume is encrypted. It is also possible as part
of
the self-repair process that the metadata may move (not copied, old
copies
are erased) over the lifetime of the volume.
"What about repartitioning?"
We've improved OS Shrink/Expand support with BitLocker enabled (RC1),
but
you cannot shrink to a size before the last block of metadata. We'll
try and
improve this in the next version. You cannot (of course) shrink/expand
a
volume that is currently 'locked', as any form of repartitioning
requires
modification to file-system tables. Offline tools will by default not
recognize the "file system" on an encrypted volume until they become
BitLocker aware.
"Decommisioning"
This comes down to policy. Obviously, nothing can beat the sequence of
writing over the data 100 times, drilling holes through the disks,
smashing
it with a jack hammer, placing the remains in a furnace, and sending
the
contents of the furnace on a one-way journey to the sun on a secure
transporter.
However...
At some point, a company has to make a trade-off between cost of
decommissioning vs risk of recovery vs value of data. This will vary
from
organization to organization. There is also an associated cost of the
person
who wishes to recover the data that reduces risk of recovery. Suffice
to
say, many people don't perform even a single-pass erase of raw data on
the
hard disk today. Raising the bar is always a good thing
-
Jamie Hunter [MS]
Thanks Jamie,
The main perception is that the featured WMI commands make it
exquisitely
easy to either cast doubt on the effectiveness of the decommission
process
or
perform a massive denial of service.
For clarity, where exactly is the metadata stored on the protected
volume?
Is it always in the same reserved location, say, before or after the
actual
encrypted data? (Come to think of it, I'm guessing repartitioning
software
could really screw up an encrypted volume...)
Per (1), I agree that acquiring the TPM's metadata alone for gain is
mute,
since the level of access required means you can get anything. It's
the
recovery key or startup key (sans TPM) metadata I'm more concerned
about.
During the lifecycle of a laptop, the recovery key is stored in
Active
Directory, and perhaps extracted a few times for technicians working
on
laptop issues. The startup key is on the user's USB drive, and
perhaps on
a
backup on a spare USB drive. It is simply a hidden file, after all,
easily
copied. When the lifecycle is over, all metadata blobs are removed,
the
startup key deleted from the USB flash, recovey key deleted from AD,
and
drive "safely" dumped in the trash. (I know, what follows is a bit
paranoid...) Later, a security assessor finds out that extra startup
keys
and
recovery keys may be floating around, and realizes that since AD is
backed
up, recovery keys exist somewhere on tape. Also, he learns that the
company
exercised an option to backup the metadata as well, or learns that
some
laptops became infected during their lifecycle by viruses that may
have
executed commands to harvest metadata information, or that a fired
domain
admin had been suspected of harvesting information from the
enterprise.
Worse still, he finds that the GUID for some company drives is listed
on a
hacker website of harvested startup keys. This casts serious doubt
as to
whether the data could "never" be recovered. Hence, all company
encrypted
drives are destroyed or wiped anyway at the end of their lifecycle.
Per (2), I think accessing the WMI commands to delete localized
metadata
is
a bit easier than deleting the $MFT, which, if I understand
correctly, is
not
directly accessible via the OS, is mirrored, actively reconstituted
by the
OS, and scattered all over the drive. For someone wanting an
extremely
quick
and deadly denial of service method across an enterprise, the WMI
decommissioning commands seem like a superb way to do it.
I'm not sure why an organization would need these particular
decommission
commands via WMI across the network. I think most would want to
remove
these
commands from the general enterprise tools, and use them only at the
end
of
lifecycle back in the IT support room. Can these commands be
removed,
without completely disabling WMI, as a mitigating control?
Thanks again!
:
There's some interesting thoughts and questions you've raised below.
I'll
also try to get to your other questions on your other threads.
(1) Decommissioning & Viruses/Trojans
If a Virus or Trojan has a level of access to the system to get the
backup
material via the WMI interfaces (or internal interfaces), the same
Virus/Trojan already has the ability to acquire the confidential
documents
off the disk before decommissioning, so the ability to get the key
material
becomes mute.
Also on the subject of decommissioning, just conviniently losing the
keys
(and clearing the TPM) is cryptographically enough. Any act of
erasing
metadata off the disk is overkill as the weakest point of attack is
the
AES
key strength used to encrypt bulk data, which is more then strong
enough.
(2) Backup & data loss
BitLocker in a domain environment does provide a policy for backing
up
the
metadata onto a domain. It also would be extremely difficult (read,
the
virus/trojan would need to install a driver to do this) to erase the
metadata. However we provide this backup option just in case
. The
same
virus/trojan could more easily erase the MFT and cause other data
loss
havoc
on the disk.
That said, I pose the following observation (I've been planning to
get a
blog entry on
http://blogs.msdn.com/si_team/ on this subject)...
Consider the scenario that BitLocker is being turned on for. It is
in
anticipation of the (hopefully unlikely) event of the laptop being
lost
or
stolen. There is also always the possibility of hardware failure, or
a
general disk crash. In these scenarios, any form of metadata backup
would
be
mute. It is therefore VITAL that regular backups of data are
maintained.
Backing up metadata is not enough.
-
Jamie Hunter [MS]
Its not the recovery key I'm concerned about, its the loss of the
resultant
blob encrypting the VMK, which is located somewhere on the
protected
volume,
that I"m concerned may be deleted, by malicious code or direct
tampering.
Think of it as an "involuntary decommissioning" of the drive.
Conversely, how can I know that if I delete the blobs when I'm
ready to
decommission the drive that an image of the entire volume,
blobs-n-all,
isn't
somewhere in backup at the company, or that at some point in the
machine's
life-cycle malicious code hadn't silently made a copy of the blobs
somewhere
else on the drive? If you can't trust the decommissioning method
being
proposed, you'll have to destroy the drive in more vigorous ways
anyway...
Thanks!
:
When going through the whole BitLocker thing the first time I
tried
it,
it tells
you (somewhat forces you) to back up the encryption key for
recovery
purposes
several times. I don't know if it is like that in Beta 2, but I'm
guessing it
is, that would prevent a large scale problem if this got deleted
inadvertently.
----------
Mark Dietz
PROnetworks <
http://www.pro-networks.org>
tavis wrote:
In BitLocker for Vista, is it known, exactly, where the
encrypted
blobs
used
to secure the encryption keys are stored on the protected
volume?
The concerns:
1. According to the Technical Overview at
http://www.microsoft.com/technet/windowsvista/security/bittech.mspx,
secure
decommissioning can be accomplished by using commands to delete
the
encrypted
blobs, including the recovery blob. If there is ever any doubt
that
these
blobs could be read or copied off of the drive, the
thoroughness of
the
decommissioning may be questioned.
2. On the other hand, some customers may be concerned about a
denial
of
service should someone/something delete these blobs (especially
if a
virus
affects a domain admin's system, and accesses the WMI commands
to
"decommission" the volume!). The customer may want some way to
backup
these
blobs, and restore them if deleted. I know this begs the
question -
"why
would one ever embark on volume encryption without a good file
backup
solution in place?", but it would be faster to restore the
blobs
than
restore
all data from tape for an enterprise of laptops.
They're probably not regular files, or maybe I missed something
using
WinHex...
Thanks!
