[Windows] Guidance around access management for key-attestation on TPMs via the Windows PCP library

[venkyg-sec]

hey folks, I have some questions around access management for admins/non-admins to the TPMs on windows via Microsoft's PCP (Platform crypto provider). This may or may not be an attestation issue, but since we use PCP for windows attestation in this project, I thought of asking here.

I noticed that some of the ncrypt properties are not exposed by PCP in the non-administrator context. Some examples of such properties are PCP_RSA_EKNVCERT, PCP_ECC_EKNVCERT, PCP_EKNVCERT. The way I noticed this is by running "attest-tool.exe list-eks" with and without adminstrator on a Windows powershell. While running as adminstrator, it correctly finds and returns the EK certificates. While running without adminstrator privileges, it only returns the EK public key via ncrypt propert PCP_EKPUB.

Looking at some other microsoft docs, https://github.com/microsoft/TSS.MSR/tree/master/PCPTool.v11 (Check "Using the Windows 8 Platform Crypto provider and assocaited TPM functionality PDF" ), it seems that admin access is needed for most of the TPM commands. This also aligns with Microsoft's Windows cmdlet to get the Endorsement key Info https://learn.microsoft.com/th-th/powershell/module/trustedplatformmodule/Get-TpmEndorsementKeyInfo?view=windowsserver2022-ps.

I'm looking for general guidance around how key-attestation should be structued for systems where non-admins need access to a TPM key for operational use, but still have that key go through the attestation process. The options I see is to 1) either have a admin based process manage all TPM keys and selectively inject user-keys onto Windows user certificate stores (or) 2) find a way to expose these PCP properties to non-admins. Does the go-attestation team have any guidance on this ?

[venkyg-sec]

cc: @mjg59

[venkyg-sec]

The issue i'm facing is very similar to the one in #251 (comment)

[brandonweeks]

Not to suggest that it is the correct approach at all, we've gone with 1) internally.

[venkyg-sec]

Not to suggest that it is the correct approach at all, we've gone with 1) internally.

thanks for confirming. do you think it'll be useful to add that support to go-attestation ? We might be even able to use https://learn.microsoft.com/en-us/windows/win32/api/ncrypt/nf-ncrypt-ncryptexportkey to export from admin and import from non-admin.

Also, on another note, I've reached out to Microsoft to ask if it's feasible to allow-list specific key attestation commands for (2).