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

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/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!

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" wrote in message

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/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 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" wrote in message 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/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!

"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" wrote in message

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" wrote in message 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/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 [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" wrote in message 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" wrote in message 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/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" wrote in message

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" wrote in message 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" wrote in message 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/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 [MS]" wrote in message

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" wrote in message 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" wrote in message 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" wrote in message 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/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" wrote in message

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]" wrote in message 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" wrote in message 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" wrote in message 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" wrote in message 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/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!