BUG? Shouldn't passing a pcr value file as an auth policy argument raise an error?

[SharkOverBite]

Hi folks,

I just opened nokia/TPMCourse#22, because I think the example they include of sealing data in nvram with a PCR policy is misleading. I'm opening a related issue here, because it seems to me their example functions as expected only because the tpm2_nvwrite/tpm2_nvwrite simply ignore what I think should actually be an invalid argument value.

Here is the command sequence they use:

$ tpm2_pcrread -o srtm.pcrvalues sha256:0,1,2,3
$ tpm2_createpolicy --policy-pcr -l sha256:0,1,2,3 -f srtm.pcrvalues -L srtm.policy
$ tpm2_nvdefine 0x1500019 -C o -s 32 -L srtm.policy -a "policyread|policywrite"
$ tpm2_nvwrite 0x1500019 -C 0x1500019 -P pcr:sha256:0,1,2,3=srtm.pcrvalues -i testfile
$ tpm2_nvread 0x1500019 -C 0x1500019 -P pcr:sha256:0,1,2,3=srtm.pcrvalues 

Clearly, there's no reason for =srtm.pcrvalues to be passed in for the last two lines. The PCR values for the policy
protecting the NVRAM location is based on the device's current PCR values, not on any "PCR Values" the user hands the PCR.

Shouldn't the commands complain about this instead of simply ignoring it?

Also, as an unrelated question, can you confirm that the metadata for the PCRs used for a policy (i.e. "sha256:0,1,2,3") isn't actually stored with the policy itself? the caller really has to tell the device which bank/PCRs to compare against?

[JuergenReppSIT]

Clearly, there's no reason for =srtm.pcrvalues to be passed in for the last two lines. The PCR values for the policy protecting the NVRAM location is based on the device's current PCR values, not on any "PCR Values" the user hands the PCR.

Shouldn't the commands complain about this instead of simply ignoring it?

The option is not ignored. The values from the file are used for the policy pcr commands which have to be executed. If srtm.pcrvalues is not passed the values have to be read a second time during command execution.

Also, as an unrelated question, can you confirm that the metadata for the PCRs used for a policy (i.e. "sha256:0,1,2,3") isn't actually stored with the policy itself? the caller really has to tell the device which bank/PCRs to compare against?

yes, no meta data is stored in srtm.policy. This file only contains the binary policy digest.

[SharkOverBite]

Clearly, there's no reason for =srtm.pcrvalues to be passed in for the last two lines. The PCR values for the policy protecting the NVRAM location is based on the device's current PCR values, not on any "PCR Values" the user hands the PCR.
Shouldn't the commands complain about this instead of simply ignoring it?

The option is not ignored. The values from the file are used for the policy pcr commands which have to be executed. If srtm.pcrvalues is not passed the values have to be read a second time during command execution.

Thank you for responding. Which values are you referring to specifically? the PCR register values (the result of previous PCR_Extend ops) themselves, must obviously come from the current state of the TPM, not caller-provided data. The selection (which bank, which PCRS) is explicitly specified on the command line and not taken from the file. What other values are there??

Perhaps I'm thinking about this wrong. Is srtm.pcrvalues actually more like a context object (encrypted/validated/trusted by the TPM)?, I thought it was merely a convenience for tpm2-tools command invocation. There really is a counterpart for this blob in the spec itself? Can you really access a PCRPolicy protected location, when the current PCR values themselves do not have the correct value, as long as you previously got your hands on a srtm.pcrvalues blob at the right moment? that seems impossible. What am I missing?