VISTA: BitLocker Blob Location & Backup

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/win...y/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!

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/win...y/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!

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!

"Mark Dietz" wrote:

> 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/win...y/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!
>

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]

"tavis" <tavis@discussions.microsoft.com> wrote in message
news:EF7BA22B-A548-450A-AE47-2C4FD4E8DE36@microsoft.com...
> 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!
>
> "Mark Dietz" wrote:
>
>> 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/win...y/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!
>>

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!


"Jamie Hunter [MS]" wrote:

> 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]
>
> "tavis" <tavis@discussions.microsoft.com> wrote in message
> news:EF7BA22B-A548-450A-AE47-2C4FD4E8DE36@microsoft.com...
> > 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!
> >
> > "Mark Dietz" wrote:
> >
> >> 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/win...y/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!
> >>
>

"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]

"tavis" <tavis@discussions.microsoft.com> wrote in message
news:87C930C8-09C6-49CB-9F05-989DE97871A0@microsoft.com...
> 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!
>
>
> "Jamie Hunter [MS]" wrote:
>
>> 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]
>>
>> "tavis" <tavis@discussions.microsoft.com> wrote in message
>> news:EF7BA22B-A548-450A-AE47-2C4FD4E8DE36@microsoft.com...
>> > 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!
>> >
>> > "Mark Dietz" wrote:
>> >
>> >> 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/win...y/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!
>> >>
>>

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!

"Jamie Hunter [MS]" wrote:

> "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]
>
> "tavis" <tavis@discussions.microsoft.com> wrote in message
> news:87C930C8-09C6-49CB-9F05-989DE97871A0@microsoft.com...
> > 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!
> >
> >
> > "Jamie Hunter [MS]" wrote:
> >
> >> 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]
> >>
> >> "tavis" <tavis@discussions.microsoft.com> wrote in message
> >> news:EF7BA22B-A548-450A-AE47-2C4FD4E8DE36@microsoft.com...
> >> > 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!
> >> >
> >> > "Mark Dietz" wrote:
> >> >
> >> >> 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/win...y/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!
> >> >>
> >>
>

Why 3 locations?

Two reasons, the first is failure tolerance. If the disk happens to crash in
one area of the disk, hopefully at least one other copy exists. The second
is for "power off during metadata update". It's easy to have a one-point
failure (power off), so we decided to make it tolerant against 1 and 2 point
failures.

How to find it?

If you look at the raw disk contents using a disk inspection tool on the
physical partitions, you will notice that the BIOS Parameter Block looks
like the NTFS BPB with 2 exceptions. The OEM[8] is different, and MFT2 field
is different...

And yes, you can distinguish metadata sectors very trivially. Even without
padding, the entropy of the data would give it away as not being encrypted.
---
Jamie Hunter [MS]

"tavis" <tavis@discussions.microsoft.com> wrote in message
news:7F9FD5FE-45E4-4873-8C77-19787FEA8F48@microsoft.com...
> 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!
>
> "Jamie Hunter [MS]" wrote:
>
>> "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]
>>
>> "tavis" <tavis@discussions.microsoft.com> wrote in message
>> news:87C930C8-09C6-49CB-9F05-989DE97871A0@microsoft.com...
>> > 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!
>> >
>> >
>> > "Jamie Hunter [MS]" wrote:
>> >
>> >> 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]
>> >>
>> >> "tavis" <tavis@discussions.microsoft.com> wrote in message
>> >> news:EF7BA22B-A548-450A-AE47-2C4FD4E8DE36@microsoft.com...
>> >> > 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!
>> >> >
>> >> > "Mark Dietz" wrote:
>> >> >
>> >> >> 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/win...y/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!
>> >> >>
>> >>
>>

How does this impact partition table information? I note that to re-image a
Vista partition back to Windows XP Pro SP2 I always have to boot to the XP
CD, delete ALL partitions on that disc, create a new active partition, quick
format it and then begin the install of XP. Once the first boot happens I
can then boot to the imaging CD and restore the XP OS.

I'm guessing that Vista/BitLocker is hiding disc area, hence removing it
from the partition table, and creating a "hidden" partition. Booting to the
XP CD and following the above procedure reallocates the partition table and
reclaims that area.

--
The personal opinion of
Gary G. Little

"Jamie Hunter [MS]" <jamiehun@nospam.microsoft.com> wrote in message
news:CEE5E5E6-D7C8-4FEC-B84C-8C044E99E79E@microsoft.com...
> Why 3 locations?
>
> Two reasons, the first is failure tolerance. If the disk happens to crash
> in one area of the disk, hopefully at least one other copy exists. The
> second is for "power off during metadata update". It's easy to have a
> one-point failure (power off), so we decided to make it tolerant against 1
> and 2 point failures.
>
> How to find it?
>
> If you look at the raw disk contents using a disk inspection tool on the
> physical partitions, you will notice that the BIOS Parameter Block looks
> like the NTFS BPB with 2 exceptions. The OEM[8] is different, and MFT2
> field is different...
>
> And yes, you can distinguish metadata sectors very trivially. Even without
> padding, the entropy of the data would give it away as not being
> encrypted.
> ---
> Jamie Hunter [MS]
>
> "tavis" <tavis@discussions.microsoft.com> wrote in message
> news:7F9FD5FE-45E4-4873-8C77-19787FEA8F48@microsoft.com...
>> 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!
>>
>> "Jamie Hunter [MS]" wrote:
>>
>>> "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]
>>>
>>> "tavis" <tavis@discussions.microsoft.com> wrote in message
>>> news:87C930C8-09C6-49CB-9F05-989DE97871A0@microsoft.com...
>>> > 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!
>>> >
>>> >
>>> > "Jamie Hunter [MS]" wrote:
>>> >
>>> >> 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
>