4.1 KiB
TPM2_MakeCredential()
TPM2_MakeCredential()
and
TPM2_ActivateCredential()
provide a
mechanism by which an application can send secrets to a TPM-using
application. This mechanism is asymmetric encryption/decryption with
support for an authorization policy of the sender's choice.
TPM2_MakeCredential()
takes an a public key (typically the endorsement
key's public key), the cryptographic name of an
object in a TPM
identified by that the given public key, and a small secret called a
credential
, and it encrypts {name, credential}
to the given public
key.
The object name input parameter, being a name, binds an optional
authorization policy that
TPM2_ActivateCredential()
will enforce.
TPM2_MakeCredential()
can be implemented entirely in software, as it
uses no secret, TPM-resident key material. All the interesting
semantics are on the
TPM2_ActivateCredential()
side.
Together with TPM2_Quote()
and
TPM2_ActivateCredential()
, this function
can be used to implement attestation protocols.
A typical use is to encrypt an AES key to an EKpub
, then encrypt a
large secret payload in the AES key, then sending the outputs of
TPM2_MakeCredential()
and the encrypted large secret payload. The
peer receives these items and calls
TPM2_ActivateCredential()
to recover the
AES key, then decrypts the large ciphertext payload to recover the large
cleartext secret.
NOTE: The
objectName
input names a key object that must present on the destination TPM, and theobjectName
is included in the plaintext that is encrypted to the public key identified byhandle
, but none of the key material ofobjectName
is used to key any cryptographic operations inTPM2_MakeCredential()
, and therefore neither is the private area ofobjectName
on the destination TPM used in any cryptographic operations inTPM2_ActivateCredential()
.This means that the key named by
objectName
can even be a universally-well-known key. The only part of that key that truly matters is the policy digest named in the public area ofobjectName
.
Authorization
TPM2_ActivateCredential()
checks the
authorization of the caller to perform this operation by enforcing the
sender's policy named by the sender's objectName
. See
here for details.
Some possible authorization policies to enforce include:
-
that some non-resettable PCR has not been extended since boot
This allows the recipient to extend that PCR immediately after activating the credential to prevent the attestation protocol from being used again without rebooting.
-
user authentication / attended boot
The policy could require physical presence, authentication of a user with biometrics and/or a smartcard and/or a password.
-
locality
Inputs
TPMI_DH_OBJECT handle
(public key to encrypt to, typically a remote TPM's EKpub)TPM2B_DIGEST credential
(not necessarily a digest, but a small [digest-sized] secret)TPM2B_NAME objectName
(name of object resident on the same TPM ashandle
thatTPM2_ActivateCredential()
will check)
Outputs
TPM2B_ID_OBJECT credentialBlob
(ciphertext of encryption ofcredential
with a secret "seed" [see below])TPM2B_ENCRYPTED_SECRET secret
(ciphertext of encryption of a "seed" tohandle
)