Thank you for taking the time to respond. We were able to determine this morning that a change in the host provisioning unrelated to our TPM code caused an unintended change to one of the PCR we were locking to, causing this error.

However, upon remedying that out we were immediately hit with a new issue -- the TPM started throwing TPM_RC_VALUE when attempting to sign to sign the digests. Nothing at all changed in the code that was performing the sign operation so we end up again stumped.

Double-checking the spec it does not appear any parameters to the sign command can throw TPM_RC_VALUE for unmarshaling; the spec seems to indicate the only cause of TPM_RC_VALUE is that the digest being passed to sign does not match the signature scheme hash algorithm, which is not the case as can be seen below.

We added some debug code to dump the buffer contents immediately before transmission to the TPM, and nothing seems out of order.

The signing key:
  - is an RSA 2048-bit key
  - has a SHA256 name algorithm
  - has the fixedTPM, fixedParent, sensitiveDataOrigin, adminWithPolicy, noDA, decrypt, and sign attributes set
  - has at authPolicy matching the policy digest in effect at the time of attempting the sign
  - has a null symmetric parameter and a null signature scheme

Here is an example output of the sign command and response that we are getting:

Tpm2Sign command bytes:

00000000 : 80 02 00 00 00 49 00 00-01 5d 80 00 00 01 00 00 

00000010 : 00 09 03 00 00 00 00 00-01 00 00 00 20 bd 4f 9e 

00000020 : 98 be b6 8c 6e ad 32 43-b1 b4 c7 fe d7 5f a4 fe 

00000030 : aa b1 f8 47 95 cb d8 a9-86 76 a2 a3 75 00 14 00 

00000040 : 0b 80 24 40 00 00 07 00-00                      


Tpm2Sign response bytes:

00000000 : 80 01 00 00 00 0a 00 00-00 84                    


Nothing in the command output indicates any issue; the command correctly sets the signature scheme as RSASSA with a SHA256 hash, with a null check ticket which the spec indicates should also be OK as the signing key is not a restricted key.


As always, any insight appreciated. Thank you.



Nick Meyer

On Mon, Apr 29, 2019 at 12:50 PM Desai, Imran <imran.desai@intel.com> wrote:
Looks like the PCRs changed. If that is an expected consequence of firmware updates consider using policy authorize tool to address the PCR brittleness. Besides that I would also look into the errors from session handling including whether or not you are starting a real (non-trial) session when trying to satisfy the pcr policy.

Thanks and Regards,

Imran Desai
________________________________________
From: Roberts, William C
Sent: Monday, April 29, 2019 7:29 AM
To: Nick Meyer; tpm2@lists.01.org; Desai, Imran
Subject: RE: [tpm2] RC 0x99d TPM_RC_POLICY_FAIL causes?

That error is:
tpm:session(1):a policy check failed

Imran, any ideas?

> -----Original Message-----
> From: tpm2 [mailto:tpm2-bounces@lists.01.org] On Behalf Of Nick Meyer
> Sent: Friday, April 26, 2019 9:56 AM
> To: tpm2@lists.01.org
> Subject: [tpm2] RC 0x99d TPM_RC_POLICY_FAIL causes?
>
> Hello,
>
> We have a set of boxes that use TPM2_Sign() to sign a cryptographic challenge
> during a startup process. The signing key is protected by a PCR policy; this policy is
> the only policy in the session authorizing the sign. Occasionally, one of these
> boxes will start returning 0x99d and refuse to sign the challenge, after which it
> seems to be stuck in this inconsistent state until we generate a new signing key.
>
> We are currently in the process of investigating if the PCRs have changed in these
> cases; in the meantime, I wanted to ask here if there are any other causes
> beyond the PCRs changing that could cause this error code, so that we can
> investigate. We also believe it unlikely that the PCR update counter is an issue as
> we would be expecting a TPM_RC_PCR_CHANGED return code in this case.
>
> Appreciate any insight you may have.
>
>  <http://www.verizonmedia.com>
>
>
> Nick Meyer
>
>