# Pseudocode Flow

As you may recall from Chapter 13, sessions can be one of three types: HMAC, policy, or trial policy sessions. HMAC and policy sessions can be used as decrypt or encrypt sessions; trial policy sessions cannot.

To keep things very simple, the following example uses an unbound, unsalted policy session that isn't being used for authorization. ^{[1]} The only use of this session is for decryption and encryption of command and response parameters. A separate password session is used for authorization. This means the test code doesn't need to calculate HMACs or manage the policyDigest for the encrypt and decrypt session.

When a session is started, the TPM generates a session key. To use decrypt and encrypt sessions, the caller needs to independently generate that session key, just as he had to do in order to use HMAC and policy sessions.

To unify all this into a single flow, the steps in decrypt and encrypt session lifecycles are as follows:

1. Start the session using Tpm2_StartAuthSession, and set the symmetric parameter to

• CFB mode:

// AES encryption/decryption and CFB mode. symmetric.algorithm = TPM_ALG_AES; symmetric.keyBits.aes = 128; symmetric.mode.aes = TPM_ALG_CFB;

• XOR mode:

// XOR encryption/decryption. symmetric.algorithm = TPM_ALG_XOR; symmetric.keyBits.exclusiveOr = TPM_ALG_SHA256;

2. Generate the session key, and save it.

3. For a command that has a TPM2B as the first parameter, if you desire to encrypt that parameter, do the following:

a. Generate the HMAC key for this use of the session. The session key figures into the generation of this key.

b. For CFB mode:

• Generate the encryption key and IV using the session hash algorithm, HMAC key, special label (“CFB”), nonceNewer, nonceOlder, and the number of bits to be encrypted.

• Encrypt the first parameter, using the encryption key and IV.

c. For XOR mode:

• Generate the mask using the HMAC key, the session hash algorithm, nonceNewer, nonceOlder, and the number of bytes to be encrypted.

• XOR the clear text data with the mask to generate the encrypted data.

d. Set the sessionAttributes.decrypt bit.

4. If the first response parameter is a TPM2B and you want the TPM to send that parameter in encrypted format, set the sessionAttributes.encrypt bit.

5. Send the command to the TPM.

6. Receive the response from the TPM.

7. If the first response parameter is a TPM2B and the

sessionAttributes.encrypt bit is set, do the following:

a. Generate the HMAC key for this use of the session. The session key figures into the generation of this key.

b. For CFB mode:

• Generate the encryption key and IV using the session hash algorithm, HMAC key, special label (“CFB”), nonceNewer, nonceOlder, and the number of bits to be decrypted.

• Decrypt the first parameter, using the encryption key and IV.

c. For XOR mode:

• Generate the mask using the HMAC key, the session hash algorithm, nonceNewer, nonceOlder, and the number of bytes to be decrypted.

• XOR the encrypted data with the mask to generate the clear data.

For details on CFB and Xor decryption/encryption see the “Session-based encryption” section of part 1 of the tpM 2.0 specification.

- [1] Unbound and unsalted sessions don't yield strong encryption keys and should not normally be used for decrypt or encrypt sessions. This was done to keep the example as simple as possible.