Closed tomoveu closed 3 years ago
@tomoveu : It only behaves differently when TPMA_SESSION_decrypt
or TPMA_SESSION_encrypt
flags are set in sessionAttributes
.
https://github.com/wolfSSL/wolfTPM/blob/master/src/tpm2.c#L131 https://github.com/wolfSSL/wolfTPM/blob/master/src/tpm2.c#L200
David Garske, wolfSSL
This is refactored as part of #110 The PR will be up soon and then we could close this. In nutshell, there is a helper function now to check for Parameter Encryption session. Just updating the issue, so there is a nice trace.
Solved in #122
While working on #93 I found that the TPM_SendCommandAuth() makes a check on whether the TPM_ST_SESSION tag is set or not. If set the function assumes parameter encryption is needed. And treats all commands with TPM_ST_SESSION as if they always must have encrypted parameters before sending.
However, parameter encryption depends on the existing(current) Authorization Sessions. Later, based on TPMA_SESSION sessionAttributes the TPM and the Stack determine if parameter encryption took place (for the command or the response).
According to the spec:
Also, everywhere "parameter encryption" is mentioned for a command it is specified as optional like this
I think TPM_SendCommandAuth should examine the Authorization Session before assuming parameter encryption. Currently, I am not sure there is an impact, but trying to solve the Authorization Session for GetTime I spotted this issue. We may want to remove partial parameter encryption code before it is fully implemented.
Overall, the authorization problem is one that the TPM Stack is meant to relieve from the User, so it is the right place to tackle. It is a complex topic and we could expect more issues around authorization. I have been reading the spec for the past hours and gets pretty confusion with all the terminology.