3

I've setup a dual boot so I have windows 10 and ubuntu.

Following steps on this page I'm able to retrieve the lockout password and the owner password of my TPM in the windows 10 registry. Result looks like this :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin
OwnerAuthStatus    REG_DWORD    0x1
LastAuthLevel    REG_DWORD    0x4
OwnerAuthFull    REG_SZ    iTcW8t1B+tIKmP/uxXPL94QF2Jw=
LockoutHash    REG_SZ    Ki1RiIu8d+eqeDoEFYcAqIoi1n4=
SRKPub    REG_BINARY    A3FEFDE6DBAA425D24717422C46C7E9C85C433CB
StorageOwnerAuth    REG_SZ
TPMCleared    REG_DWORD    0x0

OwnerAuthFull and LockoutHash are both base64 encoded so I can decode them using this link for instance (it give 893716F2DD41FAD20A98FFEEC573CBF78405D89C in hexa for the owner password).

After that booting on the ubuntu I'm trying to interact with the TPM using these passwords. I'm using tpm2-tools to interact with the TPM under ubuntu. Tpm2-tools works pretty well when the linux controls the TPM and sets up these passwords. But here I'm trying to let Windows have control of the TPM and still be able to communicate with it under Ubuntu. For instance when I run these commands (which works when ubuntu controls the TPM).

$ tpm2_createprimary --hierarchy e -g sha256 -G rsa -C primary.ctx
attributes:
  value: fixedtpm|fixedparent|sensitivedataorigin|userwithauth|restricted|decrypt
  raw: 0x30072
$ tpm2_create -g sha256 -G rsa -u key.pub -r key.priv  -c primary.ctx
algorithm:
  value: sha256
  raw: 0xb
attributes:
  value: fixedtpm|fixedparent|sensitivedataorigin|userwithauth|decrypt|sign
  raw: 0x60072
type:
  value: rsa
  raw: 0x1
  rsa: d14e5b7473972e4430b780dff0ec31a3a021fa0049ea1bafc17e2de4e232cba3afcdd8504c9f7dc2fa57df04ec1f64759f6bb0d8563c1ac53a7ce8d563ab7437f1f4b760960acfde7c414355c371ac8c94bba0e004bb08b499f115ba5e8efd655174c87309d64a23e198f6fce8e5451a851b7e96f7c172ba3d4be8e339176d136752e5d038ad9979585008e35bdedfdabe3236b92c60d5c4eabcafaabc8c65401aab5b479d8471d20ca18631c31404b38f3d373b5612ca906599914865cf281e550a748685fed4d60a7aa9c955d374c1d0852bb36ce9d39209e66fada20e4c473765160988470e93b63d81361613e3f5b918da167048ff8afe5e74768544fe03
$ tpm2_load -c primary.ctx  -u key.pub  -r key.priv -n key.name -C key.ctx

Load succ.
LoadedHandle: 0x80000100

$ tpm2_evictcontrol --auth o -c key.ctx --persistent 0x81010003 -P hex:893716F2DD41FAD20A98FFEEC573CBF78405D89C
persistentHandle: 0x81010003
ERROR: Tss2_Sys_EvictControl(0x9A2) - tpm:session(1):authorization failure without DA implications

I get 

 ERROR: Tss2_Sys_EvictControl(0x9A2) - tpm:session(1):authorization failure without DA implications
.

Does anybody knows why I get this error / why this password doesn't work? Where could I get the right password ? Well any pointer on how to solve this problem is appreciated! Thx!

b3nj1
  • 667
  • 1
  • 6
  • 17

2 Answers2

2

I think I got my answer, in fact Windows make a sha1 hash of the password then converts it to base64 and then stores it in the registry if gpedit is configured like so : https://msdn.microsoft.com/en-us/library/windows/desktop/aa376421(v=vs.85).aspx

b3nj1
  • 667
  • 1
  • 6
  • 17
  • This is no longer true. The windows does not store any owner password from v1607. https://learn.microsoft.com/en-us/windows/security/information-protection/tpm/change-the-tpm-owner-password – Wang Jun 25 '19 at 10:50
  • 1 TPM can only be owned by 1 OS. Thus what you are trying to achieve seems not possible at all. If you are not boot into the OS owning TPM. The difference of the boot chains upset the TPM. Thus if won't give out any key. No matter what you do with it. – Wang Jun 25 '19 at 10:54
0

b3nj1's answer is incorrect. Using the --auth o option for tpm2_evictcontrol means you're selecting the TPM's owner control domain (note that is true in Feb 2018 when the question was posted, --auth means something else now) which requires owner authorization. OwnerAuthFull and LockoutHash are indeed generated as described in b3nj1's answer, but OwnerAuthFull stores the TPM's lockout authorization, while LockoutHash's purpose is unknown.

The base64-decoded value of OwnerAuthFull is the lockout authorization value. This can be verified using tpm2-tools' tpm2_changeauth - the base64-decoded value enables one to successfully change the lockout authorization. You can use the following powershell command to do base64 decoding to hex string:

([System.BitConverter]::ToString([System.Convert]::FromBase64String('stringToConvert'))).Replace('-','')

So what is the owner authorization value in Windows? As per this page: https://learn.microsoft.com/en-us/windows/security/information-protection/tpm/trusted-platform-module-services-group-policy-settings, it is StorageOwnerAuth for b3nj1. From the result quoted in the question, it is just an empty string, meaning the owner authorization value is just a 0-byte buffer. This is the default value. Again, you can verify this using tpm2_changeauth.

Note that the link claims that the lockout authorization for TPM 2.0 is stored in LockoutAuth. This is incorrect. As seen in b3nj1's results above (as well as in my computers), there is StorageOwnerAuth, so it must be a TPM 2.0, but there is no LockoutAuth. Instead there is LockoutHash, but the article makes no mention of this value. Trying to use tpm2_changeauth with LockoutHash to modify any of the owner, endorsement, and lockout authorizations fails, so it is unclear what this value is for.

For the link in Wang's comment to b3nj1's answer, it is incorrect. One can use tpm2_changeauth to verify that the owner and endorsement authorization values in Windows are both empty strings, and lockout authorization is stored in OwnerAuthFull. This means that none of the authorization values controlled by Windows are unknown and/or discarded.

I've raised these issues with the documentation on GitHub and will update if there are any developments.

wmjdgla
  • 335
  • 2
  • 10