TPM 2.0 supports HMAC as a primitive, whereas TPM 1.2 offered only the underlying digest API. The HMAC key is a loaded, keyed, hash TPM object. For a restricted key, the key's algorithm must be used. For an unrestricted key, the caller can override the key's algorithm. As with any key, the full complement of authorization methods is available.
As with digests, there are both simple and fully flexible APIs. TPM2_HMAC is the simpler
API. You input a key handle, a digest algorithm, and a message, and the TPM returns the HMAC. The other API again implements the usual start/update/complete pattern, using TPM2_HMAC_Start, TPM2_SequenceUpdate, and TPM2_SequenceComplete.
a typical password file stores salted hashes of passwords. Verification consists of salting and hashing a supplied password and comparing it to the stored value.
Because the calculation doesn't include a secret, it's subject to an offline attack on the password file.
this use case uses a tpM-generated hMaC key. the password file stores an hMaC of the salted password. Verification consists of salting and hMaCing the supplied password and comparing it to the stored value. Because an offline attacker doesn't have the hMaC key, the attacker can't mount an attack by performing the calculation.
here are the steps:
1. TPM2_Create, specifying an hMaC key (called a keyedHash object) that can be used with a zero-length, well-known password.
2. TPM2_Load to load the hMaC key, or optionally load and then TPM2_EvictControl to make the key persistent.
3. TPM2_HMAC to calculate an hMaC of the salted password.
Two commands offer raw RSA operations: TPM2_RSA_Encrypt and TPM2_RSA_Decrypt. Both operate on a loaded RSA key. Both permit several padding schemes: PKCS#1, OAEP, and no padding. The loaded key's padding can't be overridden. The caller can, however, specify a padding scheme if the key's scheme is null.
TPM2_RSA_Decrypt is the private key operation. The decryption key must be
authorized, and padding is validated and removed before the TPM returns the plaintext.
TPM2_RSA_Encrypt is the public key operation. A key and a message must be specified, but no authorization is required for this public key operation. Padding is added before the encryption.
a platform implements CrtM updates. the design requires that updates be signed, because compromising the CrtM subverts the entire platform. however, the CrtM is constrained in both code and data space. the CrtM would like to use the tpM to verify the signature.
the CrtM uses a hard-coded public key blob in a format ready to be loaded on the tpM. the key has a null padding scheme. the CrtM then uses the
TPM2_RSA_Encrypt command to apply the public key to the signature, specifying
no padding. Finally, the CrtM does a simply byte compare on the result against a padded digest of the update.
Symmetric Key Primitives
TPM2_EncryptDecrypt permits the TPM to perform symmetric key encryption and decryption. The function operates on a small number of blocks due to the TPM input buffer size. However, the API includes an initialization vector (IV) on input and a chaining value on output, so a larger number of blocks can be operated on in parts.
As with an HMAC key, a restricted key has a fixed mode. The caller can specify the mode when using an unrestricted key.
The key must be a symmetric cipher object. It must be authorized, and the full set of authorization options are available.
Symmetric key encryption is a sensitive subject. Although the TPM isn't very fast, its hardware-protected keys are far more secure than software keys. It thus may be subject to import controls and may draw the attention of government agencies. For this reason, the PC Client platform specifies this command as optional.
The TPM has three persistent hierarchies. The platform hierarchy is generally used by the platform OEM, as represented by early boot code. The platform OEM can depend on this hierarchy being enabled, even if the end user turns off the other hierarchies. The storage hierarchy is under the control of the user and is used for non-privacy-sensitive operations. The endorsement hierarchy, with its TPM vendor and OEM certificates, is under the control of a privacy administrator and is used for privacy-sensitive operations. The privacy-sensitive credential activation is typically performed in the endorsement hierarchy.
The NULL hierarchy is volatile. Sessions, contexts, and sequence objects are in this hierarchy, but an entire tree of volatile keys and objects can also be created here, ensuring that they're deleted on a power cycle.
Besides its secure storage features, the TPM can be used as a cryptographic coprocessor, performing cryptographic algorithms on externally generated secrets or algorithms for which no secrets are needed. Its capabilities include a random number generator, digest and HMAC algorithms, and symmetric and asymmetric key operations.