Unable to execute attest-tool in some windows systems about go-attestation HOT 7 OPEN

A little bit of googling indicates that 0x80090030 is NTE_DEVICE_NOT_READY. I don't really know what that indicates. What kind of TPM are you running against? Do any commands work?

from go-attestation.

Thanks for the reply.

Here is the TPM information :
PS C:\Windows\system32> Get-Tpm

TpmPresent : True
TpmReady : True
ManufacturerId : 1229346816
ManufacturerIdTxt : IFX
ManufacturerVersion : 7.40
ManufacturerVersionFull20 : 7.40.8.12800
ManagedAuthLevel : Full
OwnerAuth :
OwnerClearDisabled : False
AutoProvisioning : Enabled
LockedOut : False
LockoutHealTime : 10 minutes
LockoutCount : 0
LockoutMax : 31
SelfTest : {}

I also searched for the error code. So, i tried update the TPM firmware. But it is already uptodate.
In Two systems, I got this error.
Other system which I have also has similar configuration of TPM, there I am able to run the tool.

from go-attestation.

I am facing the same issue. It's a permission thing.
ActivateCredential() (the pcp_windows version) makes 2 calls:

1. https://docs.microsoft.com/en-us/windows/win32/api/ncrypt/nf-ncrypt-ncryptsetproperty
2. https://docs.microsoft.com/en-us/windows/win32/api/ncrypt/nf-ncrypt-ncryptgetproperty

The call to the second method fails. I was able to find out that the current user was denied read access to the EK in the registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement

But even after I granted read permission to the user the command failed, this time claiming (0x80280400) The command was blocked.

If you run it with elevated rights it works as expected. I think it could work with the correct dwflags in the NCryptSetProperty() call but all this security stuff surpasses my intellect.

from go-attestation.

@buhtig0815 Thanks you for the response. I am running in all the systems as administrator.
Even then it is not working in some systems.

Can you please tell me how to check and add permission or endorsement ?
Thanks.

from go-attestation.

Mmmh, that's weird.

Check:
MS's Sysinternals Procmon is your friend here: https://live.sysinternals.com/Procmon.exe
Run it as admin and Add a filter: path contains tpm

Now run your tool/command that is causing the 0x80090030 error.

Then look for ACCESS DENIED results.
Ignore the Telemetry entries

Add permission
In the registry right click on HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement key.
Click Permissions...
Click Add..
Click Locations...
Select the computer, click OK
Enter everyone in the object names field, click Check Names
Click OK
The add window should be closed now.
Select Everyone from the list.
Click on the read checkbox in the Allow column.
Click OK

from go-attestation.

@buhtig0815 Thank you. This looks like a great way to check for permissions.
Tried the same. I ran the tool in admin mode :
Now, I am getting the same error code but different error statement ,
FAIL
Error: credential activation failed: EKs() failed: could not read ek public key from tpm: could not read ekpub: NCryptGetProperty returned 0,80090030 (The operation completed successfully.) for key "PCP_EKPUB" on size read.

from go-attestation.

I am facing the same issue. The ProcMon tool is very helpful, thank you! It seems like I had to allow access for "everyone" for registries "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement" and HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin" and another one for telemetry. However, it looks like it still get's blocked somewhere in TBS and I continue receiving the same error always.

PS C:\Users\vnkts\go-attestation\attest\attest-tool> .\attest.exe self-test
FAIL
Error: credential activation failed: failed to generate activate credential: NCryptGetProperty returned 80280400 (tpm or subsystem failure: TPM_E_COMMAND_BLOCKED) for key activation

I tried to compare the Process Monitor results with and without admin, and they literally look the same. So I have no idea where it ends up being blocked.

from go-attestation.