VISTA: BitLocker Blob Location & Backup

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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!
 
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.
 
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!
 
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]
 
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 said:
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 said:
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!
 
"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 said:
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 said:
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 said:
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!
 
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 said:
"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 said:
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 said:
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!
 
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 said:
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 said:
"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 said:
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!
 
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 said:
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 said:
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 said:
"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!
 
Hi Gary,

For a number of reasons including the concerns you have, we do not hide the
disk area(s) that form the encrypted volume. They are partitions in the
tranditional sense. Recall from my other posting, that BitLocker works on
the logical volume level.

We identify ourselves by the different BPB, which is neither recognized as a
valid FAT32 BPB, nor a valid NTFS BPB. If you're interested in the inner
workings, I highly recommend getting a forensics tool to inspect the
encrypted partition.

One unavoidable concern though with an XP CD is that it sees the partition -
that does not have an XP recognized file system - as being RAW, and will
offer to reformat the partition. The partition however is correctly
allocated. This is a trade-off we needed to make to stop XP and other
operating systems falling over an encrypted volume.
-
Jamie Hunter [MS]

Gary G. Little said:
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 said:
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 said:
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!
 
Back
Top