Re: Windows Vista and TPM Services

Forwarded to microsoft.public.windows.vista.security newsgroup via
crosspost.
--
~Robear Dyer (PA Bear)
MS MVP-Windows (IE, OE, Security, Shell/User)

Matty wrote:
> Hi there all, I am working on a document on Windows Vista TPM Services,
> and I have several questions I'm hoping someone can answer as well as
> several thoughts I'd like some feedback on. Feel free to address any
> combination of my comments/points, but I ask that you please try to be
> informative and thoughtful in your reply- I'd like to really learn
> something after all ;-)
> 1) Is the Endorsement Key used to create the hashes of integrity
> monitoring/reporting metrics? If not, what key is used?
>
> 2) The TBB of a trusted platform is the TPM and the CRTM. The CRTM is
> either a portion of or the entire BIOS code. Both of these components
> must be trusted, and updates must be controlled. However, currently
> 3rd party BIOSes are prevalent, and anyone can update them. If this
> situation does not change then basically 1 of the 2 components of the
> TBB cannot really be trusted. How can we really ever have a trusted
> computing platform if one of the 2 TBBs can be compromised? Perhaps
> this issue is being addressed when I read the phrase "TPM-compliant
> BIOS."
>
> 3) A trusted computing platform using a 1.2 TPM, and Windows Vista can
> enable Secure Startup and BitLocker drive encryption to secure data
> cryptographically. If the drive from this trusted computing platform
> is stolen and placed into another system running another operating
> system then what is the attacker missing in order to access the data?
> The same thing they were missing before the trusted computing platform
> was around- the encryption key. Therefore, doesn't the attacker
> still have the same methods of brute force attack at their disposal for
> cracking the encryption of the volume? How does the TPM make this
> different once the drive has been removed from the system?
>
> 4) I am trying to write scripts to perform basic TPM management tasks.
> Microsoft has some documentation on the WIn32_Tpm class which is
> supposed to be used for this sort of thing, but I have not had any
> success getting scripts to work on my Windows Vista 32-bit or 64-bit
> installations. In the end I simply tried to search for the Win32_Tpm,
> and could not even find it. The method for searching for the class was
> to use the script below, and then pipe it to | findstr /I "Win32_Tpm".
>
> =======================================
> strComputer = "."
> strNamespace = "\root"
>
> Set objSWbemServices = GetObject("winmgmts:\\" & strComputer &
> strNamespace)
>
> Set colClasses = objSWbemServices.SubClassesOf()
> For Each objClass in colClasses
> Wscript.Echo objClass.Path_.Path
> Next
> =======================================
>
> I have some more questions floating around somewhere, but this is a
> good start.
>
> Thanks in advance for your replies.
>
> Matt

Thanks, I have another question to add. It is my understanding that the CRTM
and TPM are the trusted base of the system. The CRTM does not relinquish
control of the system to anotehr piece of code until it takes an integrity
measurement of the code. This measurement is stored in a PCR in the TPM, but
the PCRs are cleared upon platform reset. So if the system does not have a
prior PCR value (an SHA-1 hash) to compare the new measurement to how does it
verify that the measurement it just took indicates that the code is
trustworthy?

My thought is that since the code that is taking the measurement seems to be
measuring system or application files which do not change then perhaps
something like the NIST National Software Reference Library can be used to
verify the integrity of the code. However, I haven't seen anything about
this in any of the TCG or MS documentation. Generally the process is just
described as "each piece of code takes a measurement, writes the metrics to
the Storage Measurement Log (SML), and then creates a SHA-1 hash of it which
is stored in the PCR in the TPM."

My problem is, okay the measurement has been taken. How does the system
know whether the measurement indicates trustworthiness or not?

Thanks

"PA Bear" wrote:

> Forwarded to microsoft.public.windows.vista.security newsgroup via
> crosspost.
> --
> ~Robear Dyer (PA Bear)
> MS MVP-Windows (IE, OE, Security, Shell/User)
>
> Matty wrote:
> > Hi there all, I am working on a document on Windows Vista TPM Services,
> > and I have several questions I'm hoping someone can answer as well as
> > several thoughts I'd like some feedback on. Feel free to address any
> > combination of my comments/points, but I ask that you please try to be
> > informative and thoughtful in your reply- I'd like to really learn
> > something after all ;-)
> > 1) Is the Endorsement Key used to create the hashes of integrity
> > monitoring/reporting metrics? If not, what key is used?
> >
> > 2) The TBB of a trusted platform is the TPM and the CRTM. The CRTM is
> > either a portion of or the entire BIOS code. Both of these components
> > must be trusted, and updates must be controlled. However, currently
> > 3rd party BIOSes are prevalent, and anyone can update them. If this
> > situation does not change then basically 1 of the 2 components of the
> > TBB cannot really be trusted. How can we really ever have a trusted
> > computing platform if one of the 2 TBBs can be compromised? Perhaps
> > this issue is being addressed when I read the phrase "TPM-compliant
> > BIOS."
> >
> > 3) A trusted computing platform using a 1.2 TPM, and Windows Vista can
> > enable Secure Startup and BitLocker drive encryption to secure data
> > cryptographically. If the drive from this trusted computing platform
> > is stolen and placed into another system running another operating
> > system then what is the attacker missing in order to access the data?
> > The same thing they were missing before the trusted computing platform
> > was around- the encryption key. Therefore, doesn't the attacker
> > still have the same methods of brute force attack at their disposal for
> > cracking the encryption of the volume? How does the TPM make this
> > different once the drive has been removed from the system?
> >
> > 4) I am trying to write scripts to perform basic TPM management tasks.
> > Microsoft has some documentation on the WIn32_Tpm class which is
> > supposed to be used for this sort of thing, but I have not had any
> > success getting scripts to work on my Windows Vista 32-bit or 64-bit
> > installations. In the end I simply tried to search for the Win32_Tpm,
> > and could not even find it. The method for searching for the class was
> > to use the script below, and then pipe it to | findstr /I "Win32_Tpm".
> >
> > =======================================
> > strComputer = "."
> > strNamespace = "\root"
> >
> > Set objSWbemServices = GetObject("winmgmts:\\" & strComputer &
> > strNamespace)
> >
> > Set colClasses = objSWbemServices.SubClassesOf()
> > For Each objClass in colClasses
> > Wscript.Echo objClass.Path_.Path
> > Next
> > =======================================
> >
> > I have some more questions floating around somewhere, but this is a
> > good start.
> >
> > Thanks in advance for your replies.
> >
> > Matt
>
>

Answers:

1) No the Endoresment Key is not used for this purpose. The SRK (Storage
Root Key) is used to "Seal" the VMK (Volume Master Key - an AES key). The
VMK is used to encrypt the FVEK (Full Volume Encryption Key) and used to
verify the MAC of additional metrics in logic that maintains integrity post
the unseal step.

2) BitLocker makes the assumption that at the time BitLocker is turned
on/enabled, the system is considered secure by the administrator. The VMK is
sealed at this time to the current set of PCR's that by default include the
firmware (PCR[0]/PCR[2]), MBR (PCR[4]), and Boot components
(PCR[8]-PCR[10]). A BitLocker compliant BIOS will make the correct
measurements to PCR[0]-PCR[5]. If anyone in possession of the laptop
attempts to change these values, the VMK will not be unsealed by the TPM,
and therefore the OS volume is not decryptable.

For legitimate update, an administrator is required to log into the machine,
at which time (successful boot and successful password authentication) the
BIOS can be upgraded.

One recommendation the BitLocker team has is that if boot fails because the
BIOS or boot components appear to have unexpectedly changed, then the volume
should be decrypted offline (i.e. not booting a potentially compromised BIOS
/ boot components even with the recovery key). This would suggest someone
has obtained the laptop, changed a boot component, and returned the laptop
to the owner.

3) Should the disk be removed from the machine that has the TPM to another
machine (with either another TPM, or no TPM at all, the situation is the
same in either case), then yes, you are reduced to a brute force attack.
This is as strong as the weakest key. If you use the default mode of "128
bit AES + 128 bit Diffuser", the key strength is considered effectively 128
bit AES (some good additional reading here:
http://blogs.msdn.com/si_team/archiv...5/756622.aspx). If it's
128-bit AES only, the key strength is obviously 128-bit AES. For the 256-bit
modes, the key strength of the data is 256-bit as the VMK is 256-bit. If
(and is the default case) a password recovery key is stored, the recovery
key is a 128-bit AES key passed through a stretching algorithm giving an
effective key strength of 160-bit.

So, this means...
128-bit modes: System is at least as strong as a 128-bit AES key.
256-bit modes with password recovery: System has effective strength of
160-bit AES key.
256-bit modes with external key recovery but no password recovery: System is
at least as strong as 256-bit AES key.

Presense of TPM does not effect this brute-force strength.

The value of the TPM is the following per mode:
a) TPM-only: No PIN / External key is required for boot when on intended
machine. Any changes to TPM/software will degenerate to brute-force attack
required. (Douglas MacIver did detailed analysis on strengths and weaknesses
of TPM-only at Hack In The Box, you should look at this paper, or contact
the BitLocker team directly to obtain the paper).
b) TPM+PIN: The PIN is protected by the TPM anti-hammering hardware. This
hardware makes even a 4-digit pin useful. If PIN is known, the security
degenerates to be as strong as (a). A PIN by itself without a TPM is not
very useful as it can be brute-force attacked trivially.
c) TPM+ External (USB) Key: If the machine is found with USB-key absent,
then this is as strong as USB-only. However, if the USB-key is accidentally
left with the machine, then the system is as strong as (a).

I personally recommend TPM+PIN for most scenarios.

4) I recommend looking at manage-bde.wsf that is installed on the Vista
system.

--
Jamie Hunter [MS]

"PA Bear" <PABearMVP@gmail.com> wrote in message
news:OrO4vG7KHHA.1252@TK2MSFTNGP02.phx.gbl...
> Forwarded to microsoft.public.windows.vista.security newsgroup via
> crosspost.
> --
> ~Robear Dyer (PA Bear)
> MS MVP-Windows (IE, OE, Security, Shell/User)
>
> Matty wrote:
>> Hi there all, I am working on a document on Windows Vista TPM Services,
>> and I have several questions I'm hoping someone can answer as well as
>> several thoughts I'd like some feedback on. Feel free to address any
>> combination of my comments/points, but I ask that you please try to be
>> informative and thoughtful in your reply- I'd like to really learn
>> something after all ;-)
>> 1) Is the Endorsement Key used to create the hashes of integrity
>> monitoring/reporting metrics? If not, what key is used?
>>
>> 2) The TBB of a trusted platform is the TPM and the CRTM. The CRTM is
>> either a portion of or the entire BIOS code. Both of these components
>> must be trusted, and updates must be controlled. However, currently
>> 3rd party BIOSes are prevalent, and anyone can update them. If this
>> situation does not change then basically 1 of the 2 components of the
>> TBB cannot really be trusted. How can we really ever have a trusted
>> computing platform if one of the 2 TBBs can be compromised? Perhaps
>> this issue is being addressed when I read the phrase "TPM-compliant
>> BIOS."
>>
>> 3) A trusted computing platform using a 1.2 TPM, and Windows Vista can
>> enable Secure Startup and BitLocker drive encryption to secure data
>> cryptographically. If the drive from this trusted computing platform
>> is stolen and placed into another system running another operating
>> system then what is the attacker missing in order to access the data?
>> The same thing they were missing before the trusted computing platform
>> was around- the encryption key. Therefore, doesn't the attacker
>> still have the same methods of brute force attack at their disposal for
>> cracking the encryption of the volume? How does the TPM make this
>> different once the drive has been removed from the system?
>>
>> 4) I am trying to write scripts to perform basic TPM management tasks.
>> Microsoft has some documentation on the WIn32_Tpm class which is
>> supposed to be used for this sort of thing, but I have not had any
>> success getting scripts to work on my Windows Vista 32-bit or 64-bit
>> installations. In the end I simply tried to search for the Win32_Tpm,
>> and could not even find it. The method for searching for the class was
>> to use the script below, and then pipe it to | findstr /I "Win32_Tpm".
>>
>> =======================================
>> strComputer = "."
>> strNamespace = "\root"
>>
>> Set objSWbemServices = GetObject("winmgmts:\\" & strComputer &
>> strNamespace)
>>
>> Set colClasses = objSWbemServices.SubClassesOf()
>> For Each objClass in colClasses
>> Wscript.Echo objClass.Path_.Path
>> Next
>> =======================================
>>
>> I have some more questions floating around somewhere, but this is a
>> good start.
>>
>> Thanks in advance for your replies.
>>
>> Matt
>

Hi Dan,

Hopefully my previous reply touched on this, the system is effectively
compared to the state when BitLocker is enabled.
You may also be interested in reading this:
http://blogs.msdn.com/si_team/archiv...-Security.aspx
--
Jamie Hunter [MS]

"Dan" <Dan@discussions.microsoft.com> wrote in message
news:05F8C03A-BA00-4C91-B415-93F554656AF7@microsoft.com...
> Thanks, I have another question to add. It is my understanding that the
> CRTM
> and TPM are the trusted base of the system. The CRTM does not relinquish
> control of the system to anotehr piece of code until it takes an integrity
> measurement of the code. This measurement is stored in a PCR in the TPM,
> but
> the PCRs are cleared upon platform reset. So if the system does not have
> a
> prior PCR value (an SHA-1 hash) to compare the new measurement to how does
> it
> verify that the measurement it just took indicates that the code is
> trustworthy?
>
> My thought is that since the code that is taking the measurement seems to
> be
> measuring system or application files which do not change then perhaps
> something like the NIST National Software Reference Library can be used to
> verify the integrity of the code. However, I haven't seen anything about
> this in any of the TCG or MS documentation. Generally the process is just
> described as "each piece of code takes a measurement, writes the metrics
> to
> the Storage Measurement Log (SML), and then creates a SHA-1 hash of it
> which
> is stored in the PCR in the TPM."
>
> My problem is, okay the measurement has been taken. How does the system
> know whether the measurement indicates trustworthiness or not?
>
> Thanks
>
> "PA Bear" wrote:
>
>> Forwarded to microsoft.public.windows.vista.security newsgroup via
>> crosspost.
>> --
>> ~Robear Dyer (PA Bear)
>> MS MVP-Windows (IE, OE, Security, Shell/User)
>>
>> Matty wrote:
>> > Hi there all, I am working on a document on Windows Vista TPM Services,
>> > and I have several questions I'm hoping someone can answer as well as
>> > several thoughts I'd like some feedback on. Feel free to address any
>> > combination of my comments/points, but I ask that you please try to be
>> > informative and thoughtful in your reply- I'd like to really learn
>> > something after all ;-)
>> > 1) Is the Endorsement Key used to create the hashes of integrity
>> > monitoring/reporting metrics? If not, what key is used?
>> >
>> > 2) The TBB of a trusted platform is the TPM and the CRTM. The CRTM is
>> > either a portion of or the entire BIOS code. Both of these components
>> > must be trusted, and updates must be controlled. However, currently
>> > 3rd party BIOSes are prevalent, and anyone can update them. If this
>> > situation does not change then basically 1 of the 2 components of the
>> > TBB cannot really be trusted. How can we really ever have a trusted
>> > computing platform if one of the 2 TBBs can be compromised? Perhaps
>> > this issue is being addressed when I read the phrase "TPM-compliant
>> > BIOS."
>> >
>> > 3) A trusted computing platform using a 1.2 TPM, and Windows Vista can
>> > enable Secure Startup and BitLocker drive encryption to secure data
>> > cryptographically. If the drive from this trusted computing platform
>> > is stolen and placed into another system running another operating
>> > system then what is the attacker missing in order to access the data?
>> > The same thing they were missing before the trusted computing platform
>> > was around- the encryption key. Therefore, doesn't the attacker
>> > still have the same methods of brute force attack at their disposal for
>> > cracking the encryption of the volume? How does the TPM make this
>> > different once the drive has been removed from the system?
>> >
>> > 4) I am trying to write scripts to perform basic TPM management tasks.
>> > Microsoft has some documentation on the WIn32_Tpm class which is
>> > supposed to be used for this sort of thing, but I have not had any
>> > success getting scripts to work on my Windows Vista 32-bit or 64-bit
>> > installations. In the end I simply tried to search for the Win32_Tpm,
>> > and could not even find it. The method for searching for the class was
>> > to use the script below, and then pipe it to | findstr /I "Win32_Tpm".
>> >
>> > =======================================
>> > strComputer = "."
>> > strNamespace = "\root"
>> >
>> > Set objSWbemServices = GetObject("winmgmts:\\" & strComputer &
>> > strNamespace)
>> >
>> > Set colClasses = objSWbemServices.SubClassesOf()
>> > For Each objClass in colClasses
>> > Wscript.Echo objClass.Path_.Path
>> > Next
>> > =======================================
>> >
>> > I have some more questions floating around somewhere, but this is a
>> > good start.
>> >
>> > Thanks in advance for your replies.
>> >
>> > Matt
>>
>>

Jamie, thanks a bunch for the detailed replies. They help a lot. So does
the ppt slideshow I found of MacIver's presentation. In answering number 4
though, the topic I am supposed to be covering is TPM management
specifically, not BDE. I did get the scripts working, but I get unreliable
results. Basically, it seems that when I call the IsEnabled method of the
Win32_Tpm class that value is cached. So the next time I call it I get the
same answer even though I disabled/enabled the device in between the 2 calls,
which should result in a different answer the second time I call the method.
IUf you have any input on that- perhaps I can clear this cached value
somehow- chime, in but I'm looking through the WMI scripting library in
technet and the MSDN.

Anyway, also your answer to #2 is very helpful. Again though, I am having
trouble understanding what occurs with the TPM in the absence of Bitlocker.
IOW, you mentioned that BDE can check PCR[0-5] to determine whether the
system is in a secure state. If BDE (as the challenger here) examines the
SHA-1 digests in those PCRs, and they do not match the digest of the
pertinent SML entries (or the BIOS etc code itself if the SML is not used)
then BDE knows that there has been a manipulation that has taken place, and
the system is not secure.

However, it is my understanding that each piece of code does not transfer
control to the next until it verfies the trustworthiness of that component.
So the CRTM/BIOS will not allow the OS loader code to take over until it is
trusted. The OS loader will not allow the OS to load, and so on. Hoiw does
the CRTM determine whether the BIOS or option ROMs have been modified if the
PCRs are cleared?

Actually from your description it almost seems I've got it backwards. It
seems as though each component checks the component BEFORE it (so BDE during
secure startup checks the trustworthiness of the BIOS, etc). Can you clarify?

Thanks,
Dan (aka Matty on google groups)

"Jamie Hunter [MS]" wrote:

> Answers:
>
> 1) No the Endoresment Key is not used for this purpose. The SRK (Storage
> Root Key) is used to "Seal" the VMK (Volume Master Key - an AES key). The
> VMK is used to encrypt the FVEK (Full Volume Encryption Key) and used to
> verify the MAC of additional metrics in logic that maintains integrity post
> the unseal step.
>
> 2) BitLocker makes the assumption that at the time BitLocker is turned
> on/enabled, the system is considered secure by the administrator. The VMK is
> sealed at this time to the current set of PCR's that by default include the
> firmware (PCR[0]/PCR[2]), MBR (PCR[4]), and Boot components
> (PCR[8]-PCR[10]). A BitLocker compliant BIOS will make the correct
> measurements to PCR[0]-PCR[5]. If anyone in possession of the laptop
> attempts to change these values, the VMK will not be unsealed by the TPM,
> and therefore the OS volume is not decryptable.
>
> For legitimate update, an administrator is required to log into the machine,
> at which time (successful boot and successful password authentication) the
> BIOS can be upgraded.
>
> One recommendation the BitLocker team has is that if boot fails because the
> BIOS or boot components appear to have unexpectedly changed, then the volume
> should be decrypted offline (i.e. not booting a potentially compromised BIOS
> / boot components even with the recovery key). This would suggest someone
> has obtained the laptop, changed a boot component, and returned the laptop
> to the owner.
>
> 3) Should the disk be removed from the machine that has the TPM to another
> machine (with either another TPM, or no TPM at all, the situation is the
> same in either case), then yes, you are reduced to a brute force attack.
> This is as strong as the weakest key. If you use the default mode of "128
> bit AES + 128 bit Diffuser", the key strength is considered effectively 128
> bit AES (some good additional reading here:
> http://blogs.msdn.com/si_team/archiv...5/756622.aspx). If it's
> 128-bit AES only, the key strength is obviously 128-bit AES. For the 256-bit
> modes, the key strength of the data is 256-bit as the VMK is 256-bit. If
> (and is the default case) a password recovery key is stored, the recovery
> key is a 128-bit AES key passed through a stretching algorithm giving an
> effective key strength of 160-bit.
>
> So, this means...
> 128-bit modes: System is at least as strong as a 128-bit AES key.
> 256-bit modes with password recovery: System has effective strength of
> 160-bit AES key.
> 256-bit modes with external key recovery but no password recovery: System is
> at least as strong as 256-bit AES key.
>
> Presense of TPM does not effect this brute-force strength.
>
> The value of the TPM is the following per mode:
> a) TPM-only: No PIN / External key is required for boot when on intended
> machine. Any changes to TPM/software will degenerate to brute-force attack
> required. (Douglas MacIver did detailed analysis on strengths and weaknesses
> of TPM-only at Hack In The Box, you should look at this paper, or contact
> the BitLocker team directly to obtain the paper).
> b) TPM+PIN: The PIN is protected by the TPM anti-hammering hardware. This
> hardware makes even a 4-digit pin useful. If PIN is known, the security
> degenerates to be as strong as (a). A PIN by itself without a TPM is not
> very useful as it can be brute-force attacked trivially.
> c) TPM+ External (USB) Key: If the machine is found with USB-key absent,
> then this is as strong as USB-only. However, if the USB-key is accidentally
> left with the machine, then the system is as strong as (a).
>
> I personally recommend TPM+PIN for most scenarios.
>
> 4) I recommend looking at manage-bde.wsf that is installed on the Vista
> system.
>
> --
> Jamie Hunter [MS]
>
> "PA Bear" <PABearMVP@gmail.com> wrote in message
> news:OrO4vG7KHHA.1252@TK2MSFTNGP02.phx.gbl...
> > Forwarded to microsoft.public.windows.vista.security newsgroup via
> > crosspost.
> > --
> > ~Robear Dyer (PA Bear)
> > MS MVP-Windows (IE, OE, Security, Shell/User)
> >
> > Matty wrote:
> >> Hi there all, I am working on a document on Windows Vista TPM Services,
> >> and I have several questions I'm hoping someone can answer as well as
> >> several thoughts I'd like some feedback on. Feel free to address any
> >> combination of my comments/points, but I ask that you please try to be
> >> informative and thoughtful in your reply- I'd like to really learn
> >> something after all ;-)
> >> 1) Is the Endorsement Key used to create the hashes of integrity
> >> monitoring/reporting metrics? If not, what key is used?
> >>
> >> 2) The TBB of a trusted platform is the TPM and the CRTM. The CRTM is
> >> either a portion of or the entire BIOS code. Both of these components
> >> must be trusted, and updates must be controlled. However, currently
> >> 3rd party BIOSes are prevalent, and anyone can update them. If this
> >> situation does not change then basically 1 of the 2 components of the
> >> TBB cannot really be trusted. How can we really ever have a trusted
> >> computing platform if one of the 2 TBBs can be compromised? Perhaps
> >> this issue is being addressed when I read the phrase "TPM-compliant
> >> BIOS."
> >>
> >> 3) A trusted computing platform using a 1.2 TPM, and Windows Vista can
> >> enable Secure Startup and BitLocker drive encryption to secure data
> >> cryptographically. If the drive from this trusted computing platform
> >> is stolen and placed into another system running another operating
> >> system then what is the attacker missing in order to access the data?
> >> The same thing they were missing before the trusted computing platform
> >> was around- the encryption key. Therefore, doesn't the attacker
> >> still have the same methods of brute force attack at their disposal for
> >> cracking the encryption of the volume? How does the TPM make this
> >> different once the drive has been removed from the system?
> >>
> >> 4) I am trying to write scripts to perform basic TPM management tasks.
> >> Microsoft has some documentation on the WIn32_Tpm class which is
> >> supposed to be used for this sort of thing, but I have not had any
> >> success getting scripts to work on my Windows Vista 32-bit or 64-bit
> >> installations. In the end I simply tried to search for the Win32_Tpm,
> >> and could not even find it. The method for searching for the class was
> >> to use the script below, and then pipe it to | findstr /I "Win32_Tpm".
> >>
> >> =======================================
> >> strComputer = "."
> >> strNamespace = "\root"
> >>
> >> Set objSWbemServices = GetObject("winmgmts:\\" & strComputer &
> >> strNamespace)
> >>
> >> Set colClasses = objSWbemServices.SubClassesOf()
> >> For Each objClass in colClasses
> >> Wscript.Echo objClass.Path_.Path
> >> Next
> >> =======================================
> >>
> >> I have some more questions floating around somewhere, but this is a
> >> good start.
> >>
> >> Thanks in advance for your replies.
> >>
> >> Matt
> >
>

Another quick question-
I've got my vbscript, WMI scripts working. I'm not sure what Win32_Tpm
methods need to be used to initialize the TPM. I know that initialization
turns the TPM on and takes ownership, but can I can't seem to just call the
following 2 methods and get the thing initialized:
Enable
TakeOwnership

Any help is greatly appreciated.

Thanks

"Jamie Hunter [MS]" wrote:

> Answers:
>
> 1) No the Endoresment Key is not used for this purpose. The SRK (Storage
> Root Key) is used to "Seal" the VMK (Volume Master Key - an AES key). The
> VMK is used to encrypt the FVEK (Full Volume Encryption Key) and used to
> verify the MAC of additional metrics in logic that maintains integrity post
> the unseal step.
>
> 2) BitLocker makes the assumption that at the time BitLocker is turned
> on/enabled, the system is considered secure by the administrator. The VMK is
> sealed at this time to the current set of PCR's that by default include the
> firmware (PCR[0]/PCR[2]), MBR (PCR[4]), and Boot components
> (PCR[8]-PCR[10]). A BitLocker compliant BIOS will make the correct
> measurements to PCR[0]-PCR[5]. If anyone in possession of the laptop
> attempts to change these values, the VMK will not be unsealed by the TPM,
> and therefore the OS volume is not decryptable.
>
> For legitimate update, an administrator is required to log into the machine,
> at which time (successful boot and successful password authentication) the
> BIOS can be upgraded.
>
> One recommendation the BitLocker team has is that if boot fails because the
> BIOS or boot components appear to have unexpectedly changed, then the volume
> should be decrypted offline (i.e. not booting a potentially compromised BIOS
> / boot components even with the recovery key). This would suggest someone
> has obtained the laptop, changed a boot component, and returned the laptop
> to the owner.
>
> 3) Should the disk be removed from the machine that has the TPM to another
> machine (with either another TPM, or no TPM at all, the situation is the
> same in either case), then yes, you are reduced to a brute force attack.
> This is as strong as the weakest key. If you use the default mode of "128
> bit AES + 128 bit Diffuser", the key strength is considered effectively 128
> bit AES (some good additional reading here:
> http://blogs.msdn.com/si_team/archiv...5/756622.aspx). If it's
> 128-bit AES only, the key strength is obviously 128-bit AES. For the 256-bit
> modes, the key strength of the data is 256-bit as the VMK is 256-bit. If
> (and is the default case) a password recovery key is stored, the recovery
> key is a 128-bit AES key passed through a stretching algorithm giving an
> effective key strength of 160-bit.
>
> So, this means...
> 128-bit modes: System is at least as strong as a 128-bit AES key.
> 256-bit modes with password recovery: System has effective strength of
> 160-bit AES key.
> 256-bit modes with external key recovery but no password recovery: System is
> at least as strong as 256-bit AES key.
>
> Presense of TPM does not effect this brute-force strength.
>
> The value of the TPM is the following per mode:
> a) TPM-only: No PIN / External key is required for boot when on intended
> machine. Any changes to TPM/software will degenerate to brute-force attack
> required. (Douglas MacIver did detailed analysis on strengths and weaknesses
> of TPM-only at Hack In The Box, you should look at this paper, or contact
> the BitLocker team directly to obtain the paper).
> b) TPM+PIN: The PIN is protected by the TPM anti-hammering hardware. This
> hardware makes even a 4-digit pin useful. If PIN is known, the security
> degenerates to be as strong as (a). A PIN by itself without a TPM is not
> very useful as it can be brute-force attacked trivially.
> c) TPM+ External (USB) Key: If the machine is found with USB-key absent,
> then this is as strong as USB-only. However, if the USB-key is accidentally
> left with the machine, then the system is as strong as (a).
>
> I personally recommend TPM+PIN for most scenarios.
>
> 4) I recommend looking at manage-bde.wsf that is installed on the Vista
> system.
>
> --
> Jamie Hunter [MS]
>
> "PA Bear" <PABearMVP@gmail.com> wrote in message
> news:OrO4vG7KHHA.1252@TK2MSFTNGP02.phx.gbl...
> > Forwarded to microsoft.public.windows.vista.security newsgroup via
> > crosspost.
> > --
> > ~Robear Dyer (PA Bear)
> > MS MVP-Windows (IE, OE, Security, Shell/User)
> >
> > Matty wrote:
> >> Hi there all, I am working on a document on Windows Vista TPM Services,
> >> and I have several questions I'm hoping someone can answer as well as
> >> several thoughts I'd like some feedback on. Feel free to address any
> >> combination of my comments/points, but I ask that you please try to be
> >> informative and thoughtful in your reply- I'd like to really learn
> >> something after all ;-)
> >> 1) Is the Endorsement Key used to create the hashes of integrity
> >> monitoring/reporting metrics? If not, what key is used?
> >>
> >> 2) The TBB of a trusted platform is the TPM and the CRTM. The CRTM is
> >> either a portion of or the entire BIOS code. Both of these components
> >> must be trusted, and updates must be controlled. However, currently
> >> 3rd party BIOSes are prevalent, and anyone can update them. If this
> >> situation does not change then basically 1 of the 2 components of the
> >> TBB cannot really be trusted. How can we really ever have a trusted
> >> computing platform if one of the 2 TBBs can be compromised? Perhaps
> >> this issue is being addressed when I read the phrase "TPM-compliant
> >> BIOS."
> >>
> >> 3) A trusted computing platform using a 1.2 TPM, and Windows Vista can
> >> enable Secure Startup and BitLocker drive encryption to secure data
> >> cryptographically. If the drive from this trusted computing platform
> >> is stolen and placed into another system running another operating
> >> system then what is the attacker missing in order to access the data?
> >> The same thing they were missing before the trusted computing platform
> >> was around- the encryption key. Therefore, doesn't the attacker
> >> still have the same methods of brute force attack at their disposal for
> >> cracking the encryption of the volume? How does the TPM make this
> >> different once the drive has been removed from the system?
> >>
> >> 4) I am trying to write scripts to perform basic TPM management tasks.
> >> Microsoft has some documentation on the WIn32_Tpm class which is
> >> supposed to be used for this sort of thing, but I have not had any
> >> success getting scripts to work on my Windows Vista 32-bit or 64-bit
> >> installations. In the end I simply tried to search for the Win32_Tpm,
> >> and could not even find it. The method for searching for the class was
> >> to use the script below, and then pipe it to | findstr /I "Win32_Tpm".
> >>
> >> =======================================
> >> strComputer = "."
> >> strNamespace = "\root"
> >>
> >> Set objSWbemServices = GetObject("winmgmts:\\" & strComputer &
> >> strNamespace)
> >>
> >> Set colClasses = objSWbemServices.SubClassesOf()
> >> For Each objClass in colClasses
> >> Wscript.Echo objClass.Path_.Path
> >> Next
> >> =======================================
> >>
> >> I have some more questions floating around somewhere, but this is a
> >> good start.
> >>
> >> Thanks in advance for your replies.
> >>
> >> Matt
> >
>

Hi again Jamie. I read your post here:
http://blogs.msdn.com/si_team/archiv...-Security.aspx

and I really felt like I'm missing something with regard to these PCR values
and integrity measurements. Then I found this PPT slide show here:
http://download.microsoft.com/downlo...38,14,Platform Configuration Register (PCR)

On page 14 there is a note that PCR values 0 through 15 are not reset- only
extended. It seems that there is also more NV storage in the 1.2 TPMs, and
there is a very good discussion of the PCRs after page 14. Wish I'd found
that early on in my research, but later is better than never.

So these base properties upon which all other trust measurements are built
are NOT cleared on every reset. Now it makes sense. I think I'd been
confused by finding some documents that pertained to version 1.1 but made no
mention of a version, and also by the fact that the TCG specs take a while to
digest.

Anyway, thanks.

"Jamie Hunter [MS]" wrote:

> Answers:
>
> 1) No the Endoresment Key is not used for this purpose. The SRK (Storage
> Root Key) is used to "Seal" the VMK (Volume Master Key - an AES key). The
> VMK is used to encrypt the FVEK (Full Volume Encryption Key) and used to
> verify the MAC of additional metrics in logic that maintains integrity post
> the unseal step.
>
> 2) BitLocker makes the assumption that at the time BitLocker is turned
> on/enabled, the system is considered secure by the administrator. The VMK is
> sealed at this time to the current set of PCR's that by default include the
> firmware (PCR[0]/PCR[2]), MBR (PCR[4]), and Boot components
> (PCR[8]-PCR[10]). A BitLocker compliant BIOS will make the correct
> measurements to PCR[0]-PCR[5]. If anyone in possession of the laptop
> attempts to change these values, the VMK will not be unsealed by the TPM,
> and therefore the OS volume is not decryptable.
>
> For legitimate update, an administrator is required to log into the machine,
> at which time (successful boot and successful password authentication) the
> BIOS can be upgraded.
>
> One recommendation the BitLocker team has is that if boot fails because the
> BIOS or boot components appear to have unexpectedly changed, then the volume
> should be decrypted offline (i.e. not booting a potentially compromised BIOS
> / boot components even with the recovery key). This would suggest someone
> has obtained the laptop, changed a boot component, and returned the laptop
> to the owner.
>
> 3) Should the disk be removed from the machine that has the TPM to another
> machine (with either another TPM, or no TPM at all, the situation is the
> same in either case), then yes, you are reduced to a brute force attack.
> This is as strong as the weakest key. If you use the default mode of "128
> bit AES + 128 bit Diffuser", the key strength is considered effectively 128
> bit AES (some good additional reading here:
> http://blogs.msdn.com/si_team/archiv...5/756622.aspx). If it's
> 128-bit AES only, the key strength is obviously 128-bit AES. For the 256-bit
> modes, the key strength of the data is 256-bit as the VMK is 256-bit. If
> (and is the default case) a password recovery key is stored, the recovery
> key is a 128-bit AES key passed through a stretching algorithm giving an
> effective key strength of 160-bit.
>
> So, this means...
> 128-bit modes: System is at least as strong as a 128-bit AES key.
> 256-bit modes with password recovery: System has effective strength of
> 160-bit AES key.
> 256-bit modes with external key recovery but no password recovery: System is
> at least as strong as 256-bit AES key.
>
> Presense of TPM does not effect this brute-force strength.
>
> The value of the TPM is the following per mode:
> a) TPM-only: No PIN / External key is required for boot when on intended
> machine. Any changes to TPM/software will degenerate to brute-force attack
> required. (Douglas MacIver did detailed analysis on strengths and weaknesses
> of TPM-only at Hack In The Box, you should look at this paper, or contact
> the BitLocker team directly to obtain the paper).
> b) TPM+PIN: The PIN is protected by the TPM anti-hammering hardware. This
> hardware makes even a 4-digit pin useful. If PIN is known, the security
> degenerates to be as strong as (a). A PIN by itself without a TPM is not
> very useful as it can be brute-force attacked trivially.
> c) TPM+ External (USB) Key: If the machine is found with USB-key absent,
> then this is as strong as USB-only. However, if the USB-key is accidentally
> left with the machine, then the system is as strong as (a).
>
> I personally recommend TPM+PIN for most scenarios.
>
> 4) I recommend looking at manage-bde.wsf that is installed on the Vista
> system.
>
> --
> Jamie Hunter [MS]
>
> "PA Bear" <PABearMVP@gmail.com> wrote in message
> news:OrO4vG7KHHA.1252@TK2MSFTNGP02.phx.gbl...
> > Forwarded to microsoft.public.windows.vista.security newsgroup via
> > crosspost.
> > --
> > ~Robear Dyer (PA Bear)
> > MS MVP-Windows (IE, OE, Security, Shell/User)
> >
> > Matty wrote:
> >> Hi there all, I am working on a document on Windows Vista TPM Services,
> >> and I have several questions I'm hoping someone can answer as well as
> >> several thoughts I'd like some feedback on. Feel free to address any
> >> combination of my comments/points, but I ask that you please try to be
> >> informative and thoughtful in your reply- I'd like to really learn
> >> something after all ;-)
> >> 1) Is the Endorsement Key used to create the hashes of integrity
> >> monitoring/reporting metrics? If not, what key is used?
> >>
> >> 2) The TBB of a trusted platform is the TPM and the CRTM. The CRTM is
> >> either a portion of or the entire BIOS code. Both of these components
> >> must be trusted, and updates must be controlled. However, currently
> >> 3rd party BIOSes are prevalent, and anyone can update them. If this
> >> situation does not change then basically 1 of the 2 components of the
> >> TBB cannot really be trusted. How can we really ever have a trusted
> >> computing platform if one of the 2 TBBs can be compromised? Perhaps
> >> this issue is being addressed when I read the phrase "TPM-compliant
> >> BIOS."
> >>
> >> 3) A trusted computing platform using a 1.2 TPM, and Windows Vista can
> >> enable Secure Startup and BitLocker drive encryption to secure data
> >> cryptographically. If the drive from this trusted computing platform
> >> is stolen and placed into another system running another operating
> >> system then what is the attacker missing in order to access the data?
> >> The same thing they were missing before the trusted computing platform
> >> was around- the encryption key. Therefore, doesn't the attacker
> >> still have the same methods of brute force attack at their disposal for
> >> cracking the encryption of the volume? How does the TPM make this
> >> different once the drive has been removed from the system?
> >>
> >> 4) I am trying to write scripts to perform basic TPM management tasks.
> >> Microsoft has some documentation on the WIn32_Tpm class which is
> >> supposed to be used for this sort of thing, but I have not had any
> >> success getting scripts to work on my Windows Vista 32-bit or 64-bit
> >> installations. In the end I simply tried to search for the Win32_Tpm,
> >> and could not even find it. The method for searching for the class was
> >> to use the script below, and then pipe it to | findstr /I "Win32_Tpm".
> >>
> >> =======================================
> >> strComputer = "."
> >> strNamespace = "\root"
> >>
> >> Set objSWbemServices = GetObject("winmgmts:\\" & strComputer &
> >> strNamespace)
> >>
> >> Set colClasses = objSWbemServices.SubClassesOf()
> >> For Each objClass in colClasses
> >> Wscript.Echo objClass.Path_.Path
> >> Next
> >> =======================================
> >>
> >> I have some more questions floating around somewhere, but this is a
> >> good start.
> >>
> >> Thanks in advance for your replies.
> >>
> >> Matt
> >
>

Not sure if I understood all your questions/comments, but here goes...

manage-bde.wsf has TPM management in the script as well as BDE management,
so still worth looking at. See "manage-bde -tpm -TurnOn" and
"manage-bde -tpm -TakeOwnership".

I need to follow up with the BitLocker team regards the potential on/off
state chaching (I didn't work on the TPM management code, and I'm now on a
different team).

Now, onto using PCR's for measuring. When Windows boots, the only thing that
is measured by the TPM is the boot sequence through to and including
BOOTMGR. After that point, things get too crazy that a meaningful
measurement cannot be made. BitLocker uses alternative techniques after this
point, described in my blog entry.

The mechanisms used by BitLocker for boot through BOOTMGR validation (also
used elsewhere) is to seal a required secret to a set of PCR's (which are
either calculated, or snapshot from a good state). This can be stored in any
non volatile storage including hard disk. In general, it's good to stay away
from using the TPM non-volatile memory as it is a very limited resource.
At the start of each boot, the PCR's are reset by the hardware ("Platform
Reset" in the TPM docs).
The boot code (starting at CRTM and through the SRTM sequence, ending at
BOOTMGR for Windows) measures the boot state into PCR[0]-PCR[5] and
PCR[8]-PCR[10]. (PCR[6] is used for power management state measurements,
PCR[7] is reserved for OEM use).
At some point during the boot, or post boot, if a secret is required, it
must be "unsealed"; at which point, the TPM compares the current set of
PCR's against the set of PCR's at the time the Seal function occured. If the
PCR's match, the TPM returns the secret. if the PCR's mismatch, the TPM does
not return the secret. The PCR validation data is encoded in the sealed blog
(refer to TPM docs).

One of the tricks then is to make sure that the code absolutely has to
depend upon the secret. If not, then the security check is trivially
bypassed.
For example, if the code does either:
'if PCR[0]==x && PCR[1]==y ... then print("secure") else print("insecure")'
or
'if unsealed_secret == known_constant then print("secure") else
print("insecure")'
then the code can be trivially bypassed by editing the code.
My blog entry explains this a bit more.

An alternative technique is a "trusted party" query. I can't remember the
details of this, but uses what I think is called "PCR Quote". In this case,
some code (either in a trusted hypervisor, or by a trusted computer across a
network) performs a challenge-response query to the TPM on a machine running
pontentially untrusted code. The trusted party can then determine if the
PCR's match some pre-determined value even if intermediate mediums (such as
the OS on the same system as the TPM being queried) have been compromised.

To re-iterate:
* A system that is potentially comprimised can never tell if it has been
compromised or not.
* A system can be blocked from correct behavior by holding a secret randsom
using the "Seal" and "Unseal" functions but can never meaningfully report
that it has not been compromised. It can however meaningfully report that it
cannot access a required secret (subtle difference here).
* A trusted system can query a target (potentially compromised) system using
"PCR Quote" mechanism.
* You should avoid using the TPM NV memory and use other storage instead if
any storage is required.
-
Jamie Hunter [MS]

"Dan" <Dan@discussions.microsoft.com> wrote in message
news:5C7EDEAB-5302-43CC-ABBA-E51003982779@microsoft.com...
> Hi again Jamie. I read your post here:
> http://blogs.msdn.com/si_team/archiv...-Security.aspx
>
> and I really felt like I'm missing something with regard to these PCR
> values
> and integrity measurements. Then I found this PPT slide show here:
> http://download.microsoft.com/downlo...38,14,Platform
> Configuration Register (PCR)
>
> On page 14 there is a note that PCR values 0 through 15 are not reset-
> only
> extended. It seems that there is also more NV storage in the 1.2 TPMs,
> and
> there is a very good discussion of the PCRs after page 14. Wish I'd found
> that early on in my research, but later is better than never.
>
> So these base properties upon which all other trust measurements are built
> are NOT cleared on every reset. Now it makes sense. I think I'd been
> confused by finding some documents that pertained to version 1.1 but made
> no
> mention of a version, and also by the fact that the TCG specs take a while
> to
> digest.
>
> Anyway, thanks.
>

So, let me see if I have this straight.

During a trusted state- right after manufacture perhaps- the TBB is used to
take measurements of the initial code running on the system. It writes the
values to PCR[0] through PCR[4], then hashes those PCRs and writes this value
to storage outside of the TPM. The values in PCR[0] - PCR[24] are reset upon
each boot of the platform. The TBB again takes the measurements of the
initial code, writes it to PCR[0] through PCR[4], then hashes those PCRs and
writes this value to storage outside of the TPM. If the hash of the PCRs
that was just written to external storage does not match the last one then it
indicates that the platform is no lonnger trustworthy.

Is that about right?

Also, you mention that things get too crazy to take measurements after that
point. I understand what you are saying in the blog about the VMK. So I'll
leave that aside. However, once inside Windows, isn't Windows taking trust
measurements of third-party apps before executing code? Or am I mistaken? I
was under the impression that you could fingerprint an application, write the
hash to the SML, and then each time the app runs it must produce this same
hash. This would be a valid way to protect against rootkits, trojans and the
like as long as legitimate changes to the application (such as a vendor
update) would re-baseline the app.

Thanks as usual.

"Jamie Hunter [MS]" wrote:

> Not sure if I understood all your questions/comments, but here goes...
>
> manage-bde.wsf has TPM management in the script as well as BDE management,
> so still worth looking at. See "manage-bde -tpm -TurnOn" and
> "manage-bde -tpm -TakeOwnership".
>
> I need to follow up with the BitLocker team regards the potential on/off
> state chaching (I didn't work on the TPM management code, and I'm now on a
> different team).
>
> Now, onto using PCR's for measuring. When Windows boots, the only thing that
> is measured by the TPM is the boot sequence through to and including
> BOOTMGR. After that point, things get too crazy that a meaningful
> measurement cannot be made. BitLocker uses alternative techniques after this
> point, described in my blog entry.
>
> The mechanisms used by BitLocker for boot through BOOTMGR validation (also
> used elsewhere) is to seal a required secret to a set of PCR's (which are
> either calculated, or snapshot from a good state). This can be stored in any
> non volatile storage including hard disk. In general, it's good to stay away
> from using the TPM non-volatile memory as it is a very limited resource.
> At the start of each boot, the PCR's are reset by the hardware ("Platform
> Reset" in the TPM docs).
> The boot code (starting at CRTM and through the SRTM sequence, ending at
> BOOTMGR for Windows) measures the boot state into PCR[0]-PCR[5] and
> PCR[8]-PCR[10]. (PCR[6] is used for power management state measurements,
> PCR[7] is reserved for OEM use).
> At some point during the boot, or post boot, if a secret is required, it
> must be "unsealed"; at which point, the TPM compares the current set of
> PCR's against the set of PCR's at the time the Seal function occured. If the
> PCR's match, the TPM returns the secret. if the PCR's mismatch, the TPM does
> not return the secret. The PCR validation data is encoded in the sealed blog
> (refer to TPM docs).
>
> One of the tricks then is to make sure that the code absolutely has to
> depend upon the secret. If not, then the security check is trivially
> bypassed.
> For example, if the code does either:
> 'if PCR[0]==x && PCR[1]==y ... then print("secure") else print("insecure")'
> or
> 'if unsealed_secret == known_constant then print("secure") else
> print("insecure")'
> then the code can be trivially bypassed by editing the code.
> My blog entry explains this a bit more.
>
> An alternative technique is a "trusted party" query. I can't remember the
> details of this, but uses what I think is called "PCR Quote". In this case,
> some code (either in a trusted hypervisor, or by a trusted computer across a
> network) performs a challenge-response query to the TPM on a machine running
> pontentially untrusted code. The trusted party can then determine if the
> PCR's match some pre-determined value even if intermediate mediums (such as
> the OS on the same system as the TPM being queried) have been compromised.
>
> To re-iterate:
> * A system that is potentially comprimised can never tell if it has been
> compromised or not.
> * A system can be blocked from correct behavior by holding a secret randsom
> using the "Seal" and "Unseal" functions but can never meaningfully report
> that it has not been compromised. It can however meaningfully report that it
> cannot access a required secret (subtle difference here).
> * A trusted system can query a target (potentially compromised) system using
> "PCR Quote" mechanism.
> * You should avoid using the TPM NV memory and use other storage instead if
> any storage is required.
> -
> Jamie Hunter [MS]
>
> "Dan" <Dan@discussions.microsoft.com> wrote in message
> news:5C7EDEAB-5302-43CC-ABBA-E51003982779@microsoft.com...
> > Hi again Jamie. I read your post here:
> > http://blogs.msdn.com/si_team/archiv...-Security.aspx
> >
> > and I really felt like I'm missing something with regard to these PCR
> > values
> > and integrity measurements. Then I found this PPT slide show here:
> > http://download.microsoft.com/downlo...38,14,Platform
> > Configuration Register (PCR)
> >
> > On page 14 there is a note that PCR values 0 through 15 are not reset-
> > only
> > extended. It seems that there is also more NV storage in the 1.2 TPMs,
> > and
> > there is a very good discussion of the PCRs after page 14. Wish I'd found
> > that early on in my research, but later is better than never.
> >
> > So these base properties upon which all other trust measurements are built
> > are NOT cleared on every reset. Now it makes sense. I think I'd been
> > confused by finding some documents that pertained to version 1.1 but made
> > no
> > mention of a version, and also by the fact that the TCG specs take a while
> > to
> > digest.
> >
> > Anyway, thanks.
> >
>