Securing FDO Credentials in the TPM

This is the first paragraph of 1–n paragraphs containing text of the kind informative comment...

This is the second paragraph of text of the kind informative comment ...

This is the nth paragraph of text of the kind informative comment ...

FIDO Device Onboard, or FDO, is a protocol for automatic onboarding of IoT and other devices. FDO is a Proposed Standard from the FIDO Alliance. This document refers to FDO version 1.1 [FDO-Specification].

The TPM [TPM] provides basic cryptographic operations that are needed for FDO functions, such as key storage and asymmetric cryptography. The TPM is an implementation aid for FDO because it implements some of the required cryptographic mechanisms, such as: key storage, digital signatures, and HMAC/crypto-hash computation.

The keys used for FDO are naturally stored in the TPM and can be locked to the TPM for added security. The TPM also provides mechanisms for providing attested, trusted storage of keys and other data, sufficient to store other FDO credentials.

EPID keys are not covered in this specification.

The compatibility of a given TPM with a given set of legal FDO keys is not covered or guaranteed by this specification.

FDO allows manufactured devices (IOT devices, servers, headless computers) to be installed without a login or local party for authorization. As such, FDO offers the promise of quick, reliable, and secure onboarding of devices on a large scale, suitable for a wide variety of IOT installations, including industrial devices, smart building installations, medical IOT, and smart retail applications.

In FDO, a manufacturer can initialize a device with FDO credentials and send it down the supply chain. At the same time, the manufacturer sends a digital object, the Ownership Voucher, along the paper-trail of the supply chain (e.g., along with ship confirm documents). The Ownership Voucher is self-securing and provides all the information needed for target server or cloud to identify itself to the device and onboard the device. In the case where all devices onboard to a single cloud-based server, the Ownership Voucher can be transmitted directly to that server, perhaps bypassing several supply chain steps.

When a device with FDO is ready to be installed, a technician physically places the device in its target location and connects it to a network that can reach the onboarding server, either in a local network or over the Internet. Then the technician powers on the device, completing his/her activity.

Depending on the network level protocol, a network-level onboarding protocol might be invoked to establish network-level connectivity. This network-level protocol is outside the scope of this document.

After network connectivity is established, the device autonomously uses FDO credentials to find the correct owner and securely onboard to the owner’s server.

FDO identifies itself to its onboarding server using device attestation techniques over HTTP (“REST-type”) protocols. The attestation is based on the Entity Attestation Token [EAT] and CBOR [RFC8949] standards from the IETF. The owner’s server attests to the device using the Ownership Voucher. The device attestations use public key signatures that can be computed in a TPM, based on keys stored in the TPM.

Once the device/server attestation is complete, the FDO device and server set up an encrypted tunnel, over which additional “FSIM” protocols (aka. FDO ServiceInfo modules) are run to download keys, certificates or other credentials and content into the device. The flexibility of this layer permits devices with built-in package upgrade (e.g., Linux RPM) to update or add software as well. This allows additional flexibility to accommodate older devices, or devices with varying capabilities.

The FSIM mechanism permits multiple credentials to be provisioned, allowing for the common case where an IOT server uses different credentials for various device functions, such as data upload, device management, and device control. For example, a server might prefer a certificate authentication for device management, a token-based authentication for data upload, yet use SSH for remote device maintenance.

As a final step, FDO onboarding updates the device credentials and stores a new ownership voucher on the server. This prevents previous credentials from being exploited by an attacker who later penetrates the supply chain. It also allows FDO to be run again, if needed.

This specification permits FDO device credentials to be provisioned into a TPM at various points in the TPM or device lifecycle.

The device credentials are described in the FDO 1.1 specification in Section 3.4.1. The FDO specification separates the device key from the device credentials (i.e., it does not appear in Section 3.4.1). However, in the TPM, the device key for FDO is one of the credentials provisioned by the TPM. This key can be provisioned as defined in this specification or can be the LDevID or IDevID [TPMIdentKeys] stored in the TPM. See the DeviceKeyType value, defined in section ‎1.1.

It is also possible for FDO credentials to be added to the computer system after manufacturing. For example, an OEM might embed FDO software, and a VAR later adds FDO credentials that the software will use. Later, when the computer system is installed in its target application environment, FDO runs.

On the other extreme, a TPM vendor might embed FDO credentials in the TPM before the TPM is integrated into a computer system. FDO credentials are accessed, and when a computer system boot with all these conditions are met:

• A TPM is integrated into a completed computer system

• The computer system FDO software is installed

• Credentials for FDO are integrated into the TPM

In different situations, the order in which these conditions are met can vary.

This specification supports these use cases through features:

• Ability to preserve the Device Key (e.g., as IDevID) and reinitialize all other FDO parameters

• Ability to remove or reinitialize all FDO parameters

• Ability to update FDO parameters according to the FDO TO2 protocol specification

In this flow, a TPM is embedded in a computer system. The device manufacturer (computer system manufacturer) stores FDO credentials into the TPM as part of the manufacturing process. The device is provisioned with software that includes FDO. The device is shipped (via a supply chain) to a customer site, where the device is first powered up. Then FDO runs to onboard the device.

The TPM vendor can provision a TPM with FDO credentials while the TPM is being manufactured. In this case, the Ownership Voucher is also created at the TPM manufacturer. The TPM vendor endorses the Ownership Voucher to the device manufacturer; the device manufacturer re-endorses the Ownership Voucher with the device containing the TPM.

A supply chain entity can provision a TPM with FDO credentials:

• By onboarding the device and updating the device credentials within the FDO TO2 protocol. This does not replace all the device credentials

• By installing device credentials into a TPM that does not have them, either because it never had FDO credentials or because it was reset.

• By replacing the device credentials in a TPM with new credentials

In all these cases, the supply chain entity obtains a corresponding Ownership Voucher, which it passes on to allow the device to be onboarded. If the device previously had FDO credentials, the previous Ownership Voucher is nullified by all the above operations and cannot be used to onboard any device. It is possible that other supply chain entities still have copies of this Ownership Voucher, but these copies are also nullified.

FDO requires a set of FDO device credentials to be stored on a device. As mentioned above, we include the FDO device key in the TPM device credentials. When the device boots, the device operating environment (e.g., the OS start up scripting) discovers the FDO credentials and determines that onboarding is needed. In this case, the operating environment runs FDO onboarding before normal system bring-up, allowing an automated onboarding to happen. Afterwards, the credentials are updated to allow the system to boot into normal operation with the additional service information that has been supplied by FDO.

Some FDO credentials are protected with confidentiality, availability and integrity. FDO also requires other credentials to be stored with availability and integrity. In this specification, the TPM provides both these conditions for storage of credentials.

It is convenient to store all the FDO parameters in one place, so that FDO software can find all the parameters, and that all the parameters are protected with a similar mechanism. Since the FDO keys belong in the TPM, this suggests that other FDO parameters also be stored in the NVRAM of the TPM. There are also some advantages to storing all FDO parameters in the TPM, rather than just the keys:

• Storage of FDO parameters in a TPM makes it easy for system providers to guarantee the storage requirements needed by FDO.

• FDO implementations for different operating systems can use the same credentials stored within a TPM. This includes a mechanism for determining whether there are FDO credentials present, and whether the system needs to boot into FDO or normal operation.

• The FDO parameters can be installed before a final decision on the operating system is determined, then used in whichever operating system is running as the system is brought up for the first time.

• FDO parameters might be installed in a hardware TPM implementation before it is installed into a computer system.

This specification does not explain how to store some FDO credentials in the TPM and some outside the TPM, although this is permitted in the FDO specification.

The FDO 1.1 specification indicates that FDO be run in a Restricted Operating Environment (ROE). In this document, the ROE must have access to the FDO parameters within the TPM. Ideally, no other system code has access to the FDO parameters.

This document provides for various implementations of the ROE:

• If the processor supports a ROE mode directly, the TPM can be accessible only during this mode of operation

• A co-processor can act as a ROE for another processor.

• The operating system can support a ROE mode using OS protections, and protect the TPM’s stored FDO parameters so that they are only accessible in this mode

• The operating system startup can implement a ROE mode where FDO parameters are accessible in the TPM, then the parameters are made inaccessible until the system reboots. Since FDO is normally run shortly after system boot, this mechanism can be used to protect FDO parameters from most programs that run on the operating system.

FDO contains a set of information elements, called the device credentials. with different access privileges for the different FDO on device roles that need to be stored on the FDO device:

• Active: This flag states whether the FDO protocols shall be executed by the ROE. It is initialized to true during device or TPM manufacturing. It is readable by the ROE. The ROE can set it to false and the OS/App can set it to true / false (for execution of the FDO resale protocol).

• ProtVer: This field describes the supported FDO protocol version. It is initialized during device or TPM manufacturing. It can be read by the ROE and OS/App.

• DeviceInfo: This field describes the device. It is initialized during device or TPM manufacturing. This value can be also be used to identify the particular TPM device before it is associated with a computer system. For example, the DeviceInfo value can correspond to a bar code on the TPM part manifest, box or container that can be scanned during computer system manufacturing. Then this code can be replicated on the box of the computer system containing this TPM. The DeviceInfo can also contain information that identifies the TPM or the device to the FDO Owner. If part of all of the DeviceInfo is intended to describe the device itself, but the TPM is initialized before the device is known, the string “TPM” should be used for this purpose.

  The value of devmod:device can be used to describe the device during FDO ServiceInfo.

• GUID: This describes a unique id for the device for this instance of the FDO credentials. It can be read and written by the ROE and cannot be accessed by the OS/App.

• RVInfo: This describes the information on the Rendezvous server. It can be read and written by the ROE and cannot be accessed by the OS/App.

• PubKeyHash: This references the public key of the initial ownership voucher’s signature. It is initialized during device or TPM manufacturing. It can be read and written by the ROE and cannot be accessed by the OS/App.

• HMAC Secret: This is used to calculate the HMAC of the FDO information. The resulting HMAC is used in the ownership voucher. It is created during device or TPM manufacturing. The ROE can use it for HMAC calculation and can request the TPM to change to a new HMAC Secret. The HMAC Secret is shielded and cannot be read or written by any role.

• Device Key: This is used to identify the FDO device. It is created during device or TPM manufacturing. The ROE and OS/APP can read the public key and use it for signing. The private key cannot be read, written, altered or recreated by any role. A key provisioned in accord with another specification can be used, especially that the IDevID or an LDevID be used for FDO. This specification only applies to device keys that are present in the TPM.

See also FDO 1.1 specification, section 3.4.1.

The FDO specifications defines the following components and roles to be implemented on the device:

• Device ROE: A Restricted Operating Environment; See section ‎4.5

• Device ROE App: The application that is installed in the ROE; for FDO this is the FIDO Device Onboard Device software

• Management Agent: The entity on the device that uses the FIDO Device Onboard Device software

• Device OS/App (not part of FDO description): The regular OS and Application running the Device’s functional software.

For a TPM-enabled device, this specification will support two different kinds of mapping these components.

Devices with a logical separation between ROE and Application:

• TPM: The secure storage and cryptographic operations with authorizations parts of the Device ROE / ROE App.

• Device ROE App: A process running on the device that is logically separated from the main Device OS/App. The ROE App requires a secure storage for authentication credentials (against the TPM) that are not accessible from the Device OS/App.

• The Device OS/App original functional application.

Note: This separation might be implemented using hardware separation, virtualization, containers or user and process isolation features of an underlying hypervisor or kernel.

For purposes of FDO, a time-based separation of ROE and Application mode is possible. This is because FDO only needs to run during early system operation, and then does not need to run again until the Device is rebooted. The TPM provides secure storage for FDO parameters and helps the FDO implementation with cryptographic operations. Examples include:

• The BIOS or other early-boot firmware acts as ROE to run FDO

• ROE runs during system pre-boot (e.g., ‘initrd’) and never runs co-resident with the OS

• ROE runs during system boot, as an early process in the OS initialization (e.g., /etc/rc or systemd). In this case, the ROE runs as soon as other required subsystems are initialized, such as the networking services required by FDO.

  In such Devices, FDO software terminates the ROE “phase of operation” on every system boot, whether or not FDO has run. This requires that some FDO support code always be part of the operating system boot procedure. For example, in Linux systems, an FDO script can run in “systemd”.

It is possible that a device is provisioned with FDO credentials, and a subsequent decision is made not to use FDO. For example, the device can be manufactured to support FDO, then re-imaged with an operating system that does not support FDO. The “left over” FDO credentials represent a vulnerability to the device, as follows:

• The ownership voucher for the device, that is cryptographically linked to FDO parameters in the device TPM, might not be protected well, since it is not intended to be used. It is more likely to come into the possession of a potential attacker

• The OS of the device is likely to be upgraded over time. Eventually, a version of the OS might support FDO in TPM. This will “re-activate” any lingering credentials and the ownership voucher that corresponds to them

• FDO implementations are designed to give the FDO Owner (server) supervisory or root access to the device. An attacker who has an ownership voucher for the device can take over arbitrary control of the device when it reboots with FDO active.

Therefore, it is a best security practice to destroy the Device-resident FDO credentials in this case. This also applies to the Ownership Voucher, but destroying it is impractical if it has been previously distributed in the supply chain. So long as the device credentials are destroyed, no damage can be done using a left-over Ownership Voucher.

The exception is if FDO credentials are planned to be used, but the operating system support is not yet present. This can occur when a standard operating system image is applied to the device.

The authorization requirement for FDO keys are:

• During ROE: no restriction on usage

  FIDO Device Onboard is performed at the beginning of a device’s lifetime, when the operating system of a new device starts for the first time. At this point, the device has only generic content and functions (these are installed only at the end of the onboarding process). The system of the device trusts the TPM on first use. As a consequence, no authorization or a simple authorization (to prevent mistakes) is used.

• During device operation (in the field):

  The OS can extract and delete the Ownership Voucher as well as change the Active flag.

  Furthermore, if an IDevID or LDevID is used for the FDO Device Identity key, the access rights of these keys persist. If an FDO Device Identity key is used then it is not accessible from the OS.

The policies and template used to enforce this behavior are defined in Section 7.

FDO keys	FDO Device key	FDO HMAC key
Store	Primary object in Endorsement hierarchy (optionally persistent)	Primary object in Endorsement hierarchy (optionally persistent)
Create	TPM2_CreatePrimary w/ Endorsement authorization using DeviceKey Unique String NV Index	TPM2_CreatePrimary w/ Endorsement authorization using HMAC Unique String NV Index
Persist / Unpersist (optional)	TPM2_EvictControl w/ Owner authorization	TPM2_EvictControl w/ Owner authorization
Use	TPM2_Sign w/ Object authPolicy	TPM2_HMAC w/ Object authPolicy
Change	TPM2_NV_Write of the Unique String NV Index	TPM2_NV_Write of the Unique String NV Index
Delete	TPM2_Clear w/ Platform or Lockout authorization TPM2_UndefinSpace of the Unique String NV Index (Same key can be recreated as long as EPS does not change and same Nonce NV Index is populated)	TPM2_Clear w/ Platform or Lockout authorization TPM2_UndefinSpace of the Unique String NV Index (Same key can be recreated as long as EPS does not change and same Nonce NV Index is populated)

Table 6 – Authorization for FDO keys (created with default Template)

FDO data	Unique String for DCKey.*	DCActive.*	DCTPM.*
Store	Populated as NV Index	Populated as NV Index	Populated as NV Index
Create	TPM2_NV_DefineSpace w/ Platform or Owner authorization	TPM2_NV_DefineSpace w/ Platform or Owner authorization	TPM2_NV_DefineSpace w/ Platform or Owner authorization
Read	TPM2_NV_Read w/ Authorization NV Index authValue Before TPM2_NV_ReadLock	TPM2_NV_Read w/o Authorization (empty) NV Index authValue	TPM2_NV_Read w/ Authorization NV Index authValue Before TPM2_NV_ReadLock
Write	TPM2_NV_Write w/ Authorization NV Index authValue TPM2_NV_WriteLock	TPM2_NV_Write w/o Authorization (empty) NV Index authValue	TPM2_NV_Write w/ Authorization NV Index authValue TPM2_NV_WriteLock
Delete	TPM2_UndefineSpace w/ Platform or Owner authorization	TPM2_UndefineSpace w/ Platform or Owner authorization	TPM2_UndefineSpace w/ Platform or Owner authorization

FDO data	Unique string for DCKey.*	DCOV.*	FDO Device cert
Store	Populated as NV Index	Populated as NV Index	Populated as NV Index
Create	TPM2_NV_DefineSpace w/ Platform or Owner authorization	TPM2_NV_DefineSpace w/ Owner authorization	TPM2_NV_DefineSpace w/ Platform or Owner authorization
Read	TPM2_NV_Read w/ Authorization NV Index authValue Before TPM2_NV_ReadLock	TPM2_NV_Read w/ Owner authorization	TPM2_NV_Read w/ Authorization NV Index authValue Before TPM2_NV_ReadLock
Write	TPM2_NV_Write w/ Authorization NV Index authValue TPM2_NV_WriteLock	TPM2_NV_Write w/ Owner authorization	TPM2_NV_Write w/ Authorization NV Index authValue TPM2_NV_WriteLock
Delete	TPM2_UndefineSpace w/ Platform or Owner authorization	TPM2_UndefineSpace w/ Owner authorization	TPM2_UndefineSpace w/ Platform or Owner authorization

Table 7 – Authorization for FDO data

DCTPM = [
    DCProtVer:    protver,
    DCDeviceInfo: tstr,
    DCGuid:       Guid
    DCRVInfo:     RendezvousInfo,
    DCPubKeyHash: Hash
    DeviceKeyType: uint
    DeviceKeyHandle: uint
]

As stated above, the IDevID or an LDevID key can be used as the Device key. The creation and maintainance of such a key is outside the scope of this document.

This specification also defines a Device key, stored in the TPM, used only for FDO. This section defines such a Device key.

The Device key is created and stored in the TPM as Object.

Lifetime:

Depending on the device’s intended use or application, there are two potential policies for the lifetime of the Device Key:

Case 1: The Device key serves as permanent identity of the device (following IEEE 802.1AR [802.1AR-2018]), in this case, the Device key must not change. The reader can consider if it is more appropriate to use the IDevID as the Device key in this case.

Case 2: In cases where Privacy is of concern, the Device key must be replaced (and a new Device certificate must be issued) when the device is reinitialized. However, it might be necessary to persist the Device key across several invocations of FDO to completely initialize the device.

TPM key type:

The Device key is created as Primary Key in the Endorsement hierarchy. This ensures that the Device key can be recreated as long as the Endorsement Primary Unique String (EPS) does not change.

To allow the Device key to be replaced during ownership transfer (without changing the EPS), the creation of the Device key involves a nonce (random value), which is stored in an NV Index. The nonce is provided to the TPM during Device key creation in the inSensitive.data field of the TPM2_CreatePrimary command.

During device reinitialization, if the device key should be replaced, the nonce in the NV Index is updated with a new random value (this new nonce is then used in the creation of the new device key). This ensures that a new device key is chosen.

Note: Primary keys are derived in a deterministic way from a Primary Unique String, which allows the same Primary key to be recreated as long as the Primary Unique String does not change and the same Template and unique string is used.

Note: The EPS does typically not change during the lifetime of the TPM since this would invalidate the EK certificate issued by the TPM manufacturer.

Storage:

The Device key can be stored persistently in the TPM or recreated when needed.

• Option 1: Persist Device key

  The Device key is persisted in the TPM during provisioning by the (TPM or device) manufacturer (for the persistent object handle, refer to § 4.2 Handles for FDO Credentials).

  Note: If the persistent Device key is deleted using TPM2_EvictControl or TPM2_Clear with Owner authorization, it can still be recreated as long as the EPS does not change.

• Option 2: Recreate Device key

  The Device key is not persisted in the TPM, but recreated with TPM2_CreatePrimary (after a TPM Reset) when needed using Endorsement authorization and the same Template.

  Note: The Endorsement authorization is initialized to Empty Buffer when the TPM is in factory state or cleared. That means, when FIDO Device Onboard is performed, the Device key might be created with a NULL Password. During later operations of the device, the Privacy Administrator might choose to populate the Endorsement authorization. Thus, the ROE would not be able to recreate the Device key unless it knows the Endorsement authorization or the TPM is cleared.

The HMAC secret, which is part of the FDO Secret Device Credentials (defined in ), is created in the TPM as a Primary Object based on a Unique String stored in NV. Optionally, it can be stored persistently.

Lifetime:

The HMAC secret is changed when the FDO Public Device Credentials change.

The same HMAC secret can still be used after a TPM2_Clear was issued (which removes all persistent as well as RNG-created keys) such as to preserve the FDO credentials over a resale when user data is usually deleted.

Note: When the FDO Public Device Credentials are updated during the TO2 protocol, a new HMAC value is computed over the credentials for the new Ownership Voucher.

Storage:

The HMAC secret’s unique string is stored in an NV index under the Platform hierarchy. The HMAC secret itself can be stored persistently in the TPM for improved performance or to remain usable in case the Endorsement Hierarchy password is set.

Note: Primary keys are derived in a deterministic way from a Primary Unique String, which allows the same Primary key to be recreated as long as the Primary Unique String does not change and the same Template and unique string is used.

This mechanism only applies to situations where the TPM manufacturer can target specific TPM chips to a specific Device manufacturer (e.g., it might require a large batch of TPM’s).

The Ownership Voucher is protected by a signature of the TPM manufacturer, so this mechanism is equivalent to sending the Ownership Voucher out of band, from a security point of view.

Were the DC.Active flag set to True before the Ownership Voucher is extracted, the Device would hang in FDO waiting for an Owner that will never arrive.

The following commands can be used:

• TPM2_GetCapability (capability = TPM_CAP_HANDLES, property = TPM_HT_NV_INDEX) returns a list of NV Index handles present in the TPM.

• TPM2_GetCapability (capability = TPM_CAP_HANDLES, property = TPM_HT_PERSISTENT) returns a list of persistent object handles present in the TPM.

TPM initialization for FDO can happen any time after the TPM manufacture, including:

• As part of manufacture of the TPM part

• As part of manufacture of the board-level computer using the TPM

• After completion of the board-level computer, but before operating system installation

• After operating system installation, during the supply chain

• After device has been in operation

• Use of SHOULD rather than MUST: A legacy OS that pre-dates this specification might not restrict access to the FDO credentials during runtime.

• NV Indices can be created ahead, but not populated. This is assumed in the discussion of "empty" NV indices.

• Related to items [5] and [6], below: A successful run of FDO causes the credentials to beupdated, so that FDO can run again. In some situations, the product does not wish ever to run FDO again. In this case, the FDO credentials can be deleted from the TPM by the FDO implementation after the successful run of the protocol. In addition, the startup code that checks the FDO credentials is also able to delete these credentials, as a “belt and suspenders” security check.

• As per FDO specification, FDO completes successfully in the Device when the message TO2.Done is transmitted. To ensure that this message is received, the FDO device waits (“dallies”) for a TO2.Done2 message to be received, so it can retransmit the TO2.Done message.

It is legal for a device to store FDO credentials in a device-specific manner, outside the TPM. In this case, it is device-dependent whether the TPM is queried for credentials.

The FDO keys can change at different stages of the FDO protocol. The HMAC secret changes during every TO2 interaction and the Device ID key can be changed as well.

However, the same keys can still be used after a TPM2_Clear was issued (which removes all persistent as well as RNG-created keys) such as to preserve the FDO credentials over a resale when user data is usually deleted.

In order to preserve the keys over a TPM2_Clear, the HMAC secret as well as the Device ID key are implemented as primary keys derived from the Endorsement Primary Unique String as well as a unique string value that is stored in an NV index. In order to generate a new key, the unique string is regenerated causing the keys to be recreated based on the new unique strings.

The unique strings are stored in an NV index under the Platform hierarchy in order to not be deleted during a TPM2_Clear. The keys themselves can be stored persistently in the TPM for improved performance or to remain usable in case the Endorsement Hierarchy password is set.

Note: More details on the function of the unique string is presented in the TPM Library Specification “Part 1 – Architecture” Section 27.2.7 “unique”.

The Object attributes define the properties of an Object and are described in the TPM Library specification [TPM2LIB-2019], Part 2. A short description of the meaning of the attribute settings defined in this section is provided below.

Protection:

• To have assurance that the key material is generated by the TPM and is not be duplicated for use outside of the TPM, fixedTPM, fixedParent and sensitiveDataOrigin are SET

  • As the key is not permitted to be duplicated, encryptedDuplication is CLEAR

Usage:

• To define the key as unrestricted signing key, sign is SET and restricted is CLEAR

  • The key is used to sign externally provided data and not TPM internal states

  • To disallow the key to be used for any other purpose, i.e., encryption or signing X.509 certificates, decrypt and signX509 are CLEAR

DA (Dictionary Attack):

• To disable dictionary attack protection for the Object, noDA is SET

Persistence:

• To enable the key to be made persistent, stClear is CLEAR

As per TPM specification, the Policy for the objects is stored in a digest representation, as follows:

Digest ( Digest (PolicyNV) || Digest (PolicySecret ))

Note: TODO: We intend to include actual digest values in the table below. These are not available at the time of this writing.

The below table summarizes the cryptographic operations that are performed during FDO and the corresponding TPM commands that are used.

Category	Algorithm	Cryptographic primitive	TPM commands
Device HMAC	HMAC-SHA256 HMAC-SHA384	HMAC key generation (for FDO provisioning) HMAC signature	TPM2_Create, TPM2_Load, TPM2_EvictControl (to persist key) TPM2_HMAC or HMAC sequence commands
Owner key Hash	SHA-256, SHA-384	Hash	TPM2_Hash or Hash sequence commands
Owner attestation, RSA	RSA 2048, RSA 3072 PSS, PKCS v1.5 SHA-256, SHA-384	RSA signature verification	TPM2_LoadExternal (to load public key), TPM2_VerifySignature
Owner attestation, ECC	NIST P-256, NIST P-384 SHA-256, SHA-384	ECDSA signature verification	TPM2_LoadExternal (to load public key), TPM2_VerifySignature
Device attestation, DAA	Intel® EPID: EPID1.0, 1.1	Intel® EPID signature generation.	Not supported by TPM. TPM ECDAA and EPID 2.0 are not part of the FDO 1.1 Proposed Standard.
Device attestation, ECDSA	NIST P-256, NIST P-384 SHA-256, SHA-384	ECC key generation (for FDO provisioning) ECDSA signature generation	TPM2_CreatePrimary, TPM2_EvictControl (to persist key) TPM2_Sign
Key exchange, RSA	RSA 2048, RSA 3072 OAEP SHA-256	RSA key transport	TPM2_LoadExternal (to load public key), TPM2_RSA_Encrypt
Key exchange, ECC	NIST P-256, NIST P-384	ECDH key agreement (with 2 ephemeral keys)	TPM2_LoadExternal (to load public key), TPM2_ECDH_KeyGen (TPM2_ECDH_ZGen)
Key derivation	KDF in CTR mode using HMAC-SHA256, HMAC-SHA384 (SP800-108)	Key derivation function	No direct support by TPM via KDF command, TPM2_HMAC or HMAC sequence commands can be used for processor derivation. (*)
Session, encryption	AES-128, AES-256 CTR, CBC	Encryption/decryption	TPM2_EncryptDecrypt2 (not included in PC-Client TPM Profile (PTP))
Session, HMAC	HMAC-SHA256 HMAC-SHA384	HMAC signature	TPM2_HMAC or HMAC sequence commands
Session, AEAD	AES-128, AES-256 GCM, CCM	Authenticated encryption	TPM2_EncryptDecrypt2 supports this function in the TPM library specification, but not as a mandatory part of the PC Client TPM Profile Specification

Table 13 – Cryptographic operations used for FDO

*) Both FDO and TPM refer to NIST SP-800-108 section 5.1 “KDF in Counter Mode.” In the algorithm, the ‘L’ value indicates the number of bits of KDF being created. The FDO spec uses the actual number of bits needed, and the TPM specification (Part 1, section 28, “Object Derivation”) pegs this value at 8192. Since the algorithm includes abs(L) in the hash, the resultant key will be different between the two specifications. The TPM supports the current FDO specification using hash commands, but the key results in system memory, and must be subsequently copied to the TPM.

In order to deploy FDO credentials to the TPM and assert correct and unique deployment, several TPM functionalities surrounding TPM2_ActivateCredential(), TPM2_Certify(), TPM2_CertifyCreation(), Authentication or Audit sessions can be used.