fTPM Provisioning#
A fundamental difference exists between a DTPM and fTPM. A DTPM or TPM chip has been provisioned by the TPM vendor or manufacturer with the Endorsement Key (EK) certificate, which serves as the TPM identification for attestation. Without this certificate, trust between the TPM user and services that rely on TPM cannot be established.
To create a trustworthy fTPM entity on different devices, you must provision it with a per-device unique ID and EK certificate during the device manufacturing process.
fTPM provisioning involves three main steps:
Initialization: The fTPM TA is initialized by the Trusted OS (OP-TEE) during the early secure boot stage.
Configuration: The fTPM is configured with settings such as Endorsement Primary Seed (EPS), EK certificate, owner password, and other parameters.
Key generation: The fTPM generates a unique EK and storage root key (SRK) to secure sensitive data.
Two provisioning methods are available:
Offline provisioning: The fTPM provisioning process is designed so the Jetson™ device works with the fTPM manufacturer Certificate Authority (CA) server. The fTPM manufacturer must pre-generate the EK certificates and encode them into the Encrypted Keyblob (EKB). The encoding must be completed during the device manufacturing process. When the device boots, run the provisioning tool to query the EK certificates from EKB and store them in the fTPM non-volatile (NV) memory.
Online provisioning: The online process relies on a three-way handshake protocol between the CA and the device to validate device identity, sign the EK Certificate Signing Request (CSR), and issue the EK certificate.
Note
In this release, only the offline provisioning method is supported. Online provisioning will be introduced in a future release.
Preparation Before Provisioning (Offline Method)#
Prerequisites of the fTPM Vendor#
The fTPM vendor can be an ODM/OEM who manufactures a Jetson-based device and enables fTPM, or an end-customer who deploys the product and enables fTPM. Typically, the fTPM vendor
Is the Original Design Manufacturer (ODM) of the fTPM provisioning support, with a role identical to the DTPM vendor or manufacturer.
Should be a third-party service provider with expertise in fTPM production (assuming the Jetson device builder prefers a third-party service to sign and issue fTPM EK certificates).
Must set up a secure environment for the fTPM provisioning process.
Must have a CA server acknowledged by the popular cloud service providers with which devices are designed to be enrolled.
Must meet the requirements for preparing and generating materials for fusing the devices and keeping them secure.
Should support multiple Original Equipment Manufacturers (OEMs), maintaining and isolating the materials for different OEMs.
Requirements for material preparation and generation:
Per-device
KDK0,Device_SN, Silicon_ID, and Silicon_ID public key generation.Run the
kdk_gen.pyKDK Gen tool:KDK0is a secret per-device unique 256-bit random value.SNis a per-device unique serial number.OEM_IDis an ID for a specific OEM.Device_SNis the concatenation ofOEM_IDandSN(both in big-endian form).
The public key of Silicon_ID.
This public key can be used by the fTPM provisioning tool to verify materials signed by the Silicon_ID private key.
The public key is generated by Silicon_ID:
Silicon_ID is
KDF(key=KDK0, Device_SN).The asymmetric key pair of Silicon_ID is
ECC_P256_key_gen(seed=Silicon_ID).The private key should be dropped immediately.
Note
The KDK0 should be discarded after the corresponding fuseblob, the EK, and the EK-associated certificate are generated. Not keeping it in storage avoids potential leaks.
Per-device fuseblob generation.
Run the FSKP tool (
fskp_fuseburn.py).Refer to the Fuse Configuration Templates section.
Per-device fTPM EKB generation using the
odm_ekb_gen.pyODM EKB Gen tool. The fTPM EKB properties are as follows:Device_SNEPS seed: A 256-bit random number for the EPS derivation process.
EK certificates (RSA and EC): The tool generates the EK CSR and sends it to the CA server. The certificate is issued by the CA after signing the EK CSR.
Database generated by the fTPM manufacturer:
${Device_SN}$(Silicon_ID_PUB_KEY)${EPS_Seed}${EK_Cert}
Vendor Prerequisites for fTPM Provisioning#
Signing the EK CSRs#
After the per-device EK CSR is generated, the fTPM manufacturer CA signs it and returns the EK certificate. The EK should support two algorithms: RSA and EC. During preparation, the fTPM vendor should prepare two EK CSRs and store both certificates.
The file name format is ek_${CERT_TYPE}_${KEY_TYPE}-${OEM_ID}-${SN}.der.
CERT_TYPE:csrorcert.KEY_TYPE:rsaorec.OEM_IDandSN: same as defined earlier.
Signing the EK CSRs#
EK CSR Customization#
The EK Certificate layout should conform to the TCG EK Credential Profile specification. To customize the EK CSR subject fields and key types, edit the ek_csr and tpm_attributes sections in the configuration file (conf/ftpm_provisioning.yaml) or modify lib/ftpm_ek_csr.py for structural changes to the CSR.
The following is the default layout of the EK CSR with EC key type:
Certificate Request:
Data:
Version: 1 (0x0)
Subject: C = US, O = ftpm corp, CN = 0000-0000000000000000_ftpm-ek-cert
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:45:41:66:45:ef:5e:fb:fd:a0:50:50:14:95:30:
0c:05:d2:97:71:d5:41:25:86:91:8d:52:ac:e7:f1:
60:0a:8e:b8:92:b7:29:e1:e8:20:cc:84:02:ab:bf:
24:57:db:2c:00:12:69:15:a3:cc:49:d9:69:06:35:
83:c3:77:62:56
ASN1 OID: prime256v1
NIST CURVE: P-256
Attributes:
Requested Extensions:
X509v3 Key Usage: critical
Digital Signature, Key Agreement
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Alternative Name:
DirName:/2.23.133.2.1=id:4D534654/2.23.133.2.2=SSE fTPM/2.23.133.2.3=id:20180710
Signature Algorithm: ecdsa-with-SHA256
Signature Value:
30:44:02:20:6f:40:a6:0a:d2:84:8d:45:26:2c:14:4a:be:59:
7a:30:3c:7f:1e:92:70:25:10:40:00:f2:72:2a:89:0b:0c:ba:
02:20:61:68:58:8a:21:2a:c4:8d:0b:d7:8d:76:c2:d4:c0:ee:
50:61:c1:1e:dd:a0:6b:3c:cc:f6:24:77:62:38:75:53
Field Name |
Value |
|---|---|
Subject |
Must assign a unique common name (CN). The default format of CN is |
Key Usage |
Follow the specification to define key usage according to the EK type. |
Basic Constraints |
Must be critical and set the CA property to FALSE. |
Subject Alternative Name |
This field contains the values of TPM Manufacturer, TPM Model, and TPM Version.
You must update this field according to the TCG TPM Vendor ID Registry
and rebuild the fTPM TA after updating |
Using fTPM Manufacturer CA#
The provisioning tools use a pluggable CA backend defined by the CAInterface abstract class in optee/samples/ftpm-helper/host/tool/lib/ca_signing.py. The built-in SimulatorCA implementation generates a self-signed Root CA (EC P-256) and Intermediate CA (RSA-2048) chain for development and testing. For production, subclass CAInterface and implement the following methods to connect to your HSM-backed or remote CA server:
initialize(output_path): Initialize the CA and generate or load the CA chain.sign_ek_csr(ek_csr_der, ek_type, device_sn): Sign an EK CSR and return the path to the DER-encoded certificate.sign_sid_csr(sid_csr_der, device_sn): Sign a Silicon ID CSR and return the path to the DER-encoded certificate.verify_cert_chain(cert_der_file): Verify that a certificate chains back to the CA root.get_ca_cert_pem(): Return the issuing (intermediate) CA certificate in PEM format.get_root_cert_pem(): Return the root CA certificate in PEM format.
To use your production CA for EK certificate signing, instantiate your custom CA class in place of SimulatorCA in odm_ekb_gen.py.
The following is the reference layout of the fTPM EK certificate:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
75:88:3f:e9:34:86:fb:d3:6c:fc:b2:92:23:84:c1:02:c3:8d:92:5e
Signature Algorithm: sha256WithRSAEncryption
Issuer: O = fTPM CA Sim C01, OU = fTPM Manufacturer CA Sim I01, CN = fTPM Sim Intermediate CA, C = US
Validity
Not Before: Jun 1 00:00:00 2023 GMT
Not After : Dec 31 23:59:59 2033 GMT
Subject: C = US, O = ftpm corp, CN = 0000-0000000000000000_ftpm-ek-cert
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:45:41:66:45:ef:5e:fb:fd:a0:50:50:14:95:30:
0c:05:d2:97:71:d5:41:25:86:91:8d:52:ac:e7:f1:
60:0a:8e:b8:92:b7:29:e1:e8:20:cc:84:02:ab:bf:
24:57:db:2c:00:12:69:15:a3:cc:49:d9:69:06:35:
83:c3:77:62:56
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Agreement
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Alternative Name:
DirName:/2.23.133.2.1=id:4D534654/2.23.133.2.2=SSE fTPM/2.23.133.2.3=id:20180710
X509v3 Authority Key Identifier:
9E:8C:19:9A:4D:20:6B:75:D5:87:64:86:8F:5D:96:89:7B:F1:B8:65
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
1c:0c:00:84:ec:fa:c8:29:3d:62:5c:1e:34:26:85:cf:3f:64:
41:a7:b4:0c:86:67:f6:04:a3:32:69:4d:79:b2:ed:c9:d9:0f:
b4:79:71:76:92:5e:8d:dc:d0:4f:43:bb:ef:d9:f4:aa:ab:36:
98:7d:bd:a6:ce:e7:9b:a6:8b:53:ee:7b:95:d9:10:9d:b8:02:
e6:62:58:55:b9:38:32:9c:57:7c:2d:0d:87:0f:b7:e2:11:3b:
64:ae:47:29:ca:b9:cc:b0:1c:a1:54:4c:75:4f:17:eb:aa:8c:
40:eb:31:71:a6:e8:52:ad:dd:9b:4b:f0:f7:a6:7a:27:6f:80:
e1:04:86:8b:38:e9:3f:f7:c8:a4:a8:b6:ee:38:5b:8d:c0:33:
73:10:94:92:63:25:8e:f4:ae:93:4b:d2:4a:9a:50:88:cc:ae:
47:8c:ad:f9:41:b2:a7:9d:d5:85:4a:9e:1b:70:a7:99:c2:e9:
10:b7:74:1a:df:b2:8b:c7:6f:a8:9e:37:d4:65:9f:70:ec:eb:
3d:4c:48:90:7c:73:1c:fb:cc:c1:c3:29:3c:39:7d:cd:9a:68:
29:43:47:7b:c3:8c:0f:22:1a:fb:38:23:d1:cc:1e:78:f0:ed:
e4:92:51:14:ec:d4:87:34:3f:2f:c9:df:b3:39:81:7e:af:9e:
34:74:b4:0f
Generating Per-Device EKB#
The offline provision method creates a per-device EKB image with the device’s fTPM properties:
Device_SNEPS seed
Two EK certificates (RSA and EC).
The ODM EKB Gen Tool encodes the fTPM properties into the EKB image and saves the output as an unencrypted binary file with OEM_ID and SN as the filename index.
Generating Per-Device EKB#
The EKB also contains keys defined by the device manufacturer (OEM), such as the UEFI payloads encryption key, the UEFI variable authentication key, and the disk encryption key (called user keys in general). After the per-device fTPM EKB (called fTPM_EKB) is generated in plain binary form by the fTPM manufacturer (by running odm_ekb_gen.py), the fTPM_EKB is sent to the device manufacturer so that user keys can be added by running oem_ekb_gen.py.
The final EKB that contains the fTPM_EKB and user keys is encrypted and signed by the EKB fuse key. The EKB fuse key is owned by the device manufacturer and is burned through OEM_fuseblob.
Note
The fTPM Production Flow section provides more information about fuseblob generation and burning using the FSKP tool.
Key Derivation Process#
This section lists the prerequisites for using Jetson Secure Boot loaders. The fTPM provisioning process relies on Secure Boot support on the Jetson platform. The Secure Boot function constructs Hardware Root of Trust (HROT), Root of Trust for Reporting (RTR), and Root of Trust for Measurement (RTM), which are needed for device attestation in the fTPM provisioning process.
The Trusted Computing Base (TCB) of the Jetson platform consists of the security-relevant components loaded during the Secure Boot chain.
Key Derivation Process#
The roles in the Secure Boot chain are as follows:
The hardware and ROM are the HROT of Secure Boot and also the RTR and RTM of the device.
Fuse
KDK0: A secure fuse slot on Jetson, used to deriveSilicon_ID.
ROM (includes the ROM and ROM extension code)
PSCROM and BootROM are static, fixed code stored in ROM.
PSCBL and MB1 are ROM extension code that execute the bottom half of the initial boot.
First Mutable Code (FMC)
FMC includes the ROM extension code and the bootloader.
MB2 is the bootloader that handles the construction of components for fTPM provisioning support.
Firmware
The trusted firmware includes ARM Trusted Firmware (ATF), Hafnium, OP-TEE OS with fTPM, and fTPM helper TAs.
Silicon ID Provisioning Flow in Secure Boot#
The Silicon ID provisioning flow operates along the TCBs in the Secure Boot chain, spanning three layers:
Hardware and ROM (PSCROM, BootROM, PSCBL, and MB1).
FMC (MB2).
Firmware (TOS).
The purpose of this flow is to generate a Silicon ID and fTPM seed. The security mechanism uses the TZ-SE (hardware Security Engine in the TrustZone), with a keyslot not accessible by the CPU. The fTPM seed is passed to OP-TEE using encrypted TZ memory and is used to derive the EPS during fTPM provisioning.
The Silicon ID generation flow is as follows:
In the PSCBL layer:
Silicon_IDisKDF(key=KDK0, Device_SN).Device_SNis a unique number that comprises anOEM_IDand a uniqueSN.
In the MB2 layer:
The fTPM seed is
KDF(key=Silicon_ID, constant str1).The Silicon ID key seed is
KDF(key=Silicon_ID, constant str2).The Silicon ID key pair is
f(ECC, NIST P256)(seed=Silicon ID Key Seed).
EPS Derivation Flow in the OP-TEE OS Layer#
The Endorsement Primary Seed (EPS) is the root of trust for the fTPM entity and is tied to the EK, which can be used to attest the TPM identity and the keys generated by the TPM. The EPS is derived from the TOS layer of TCB in the Jetson device. The fTPM helper PTA in the OP-TEE OS implements the EPS derivation process by using the fTPM seed from the bootloader and the fTPM property EPS_Seed in the EKB.
The EPS is injected into an fTPM TA during the TA’s first startup and is stored in NV memory.
In the fTPM helper PTA layer, the EPS derivation flow is as follows:
Device_SNisfuse_read(ODMID, ODM_INFO).The fTPM root seed is
KDF(key=fTPM_Seed, constant str).The EPS is
KDF(key=fTPM_Root_Seed, info=Device_SN, salt=EPS_Seed).
Note
The EPS seed is a random number generated by odm_ekb_gen.py and stored in EKB.
fTPM Production Flow#
The fTPM production flow provisions an EK certificate by the fTPM manufacturer who owns the CA and fTPM manufacturing server and is qualified to issue the certificate. The process must occur in a secure environment during the fTPM manufacturing process.
The requirements of the fTPM manufacturer server are as follows:
The server must be a secure environment with Hardware Secure Module (HSM) support.
The server is responsible for generating the materials for fTPM production.
The requirements of the fTPM manufacturer CA are as follows:
The CA must verify fTPM residency of a key before signing a certificate. This can be done by verifying the signature of the EK CSR.
The CA should support a standard certificate transport protocol that provides protection from replay attacks and provides confidentiality and integrity.
The fTPM Production Flow#
Note
The ODM and OEM are described as separate roles to illustrate the architectural tolerance of the design—the system supports a clean split of keys, fuseblobs, and binary blobs across two organizations. In the common case, a single entity plays both roles and can execute the ODM and OEM steps in the same environment. Refer to fTPM Production Flow When ODM and OEM Are the Same Entity.
The diagram shows the fTPM production flow. The following are the roles:
The fTPM design manufacturer (aka ODM):
Owns the fTPM manufacturer server and the fTPM manufacturer CA.
Delivers the fTPM packages to OEM.
The OEM manufacturer:
Owns the OEM-defined fuse keys.
Owns the user-defined keys in EKB.
Owns the OS bootloader (such as UEFI) and UEFI payloads (such as L4TLauncher).
Owns platform vendor (PV) keys that encrypt and sign the UEFI image.
Generates the packages for production.
The OEM manufacturer factory assembles, fuses, and flashes the devices.
The production flow steps are as follows:
ODM Fuseblob Generation: Keys and materials (KDK0, SN, PKC, SBK) owned by ODM are generated. Run the KDK Gen Tool (
kdk_gen.py) to generateODM_KDK_db; then run the fuse burn tool (fskp_fuseburn.py) withODM_KDK_dband the PKC/SBK keys. The fuseblob database contains files likeodm_fuseblob-${Device_SN}.bin. Refer to Fuse Configuration Templates.OEM Fuseblob Generation: OEM-owned fuse keys are generated. Run
fskp_fuseburn.pywith the OEM fuse configuration XML file. Refer to Fuse Configuration Templates.ODM EKB Generation Phase 1: The EPS seed and EK certificates are generated using the fTPM Gen CSR tool. The EK CSRs are signed by the CA. Run
odm_ekb_gen.pywithODM_KDK_dbto generateEKB_ftpm_db. Send to OEM.OEM EKB Generation: User-defined keys are added. Run
oem_ekb_gen.pyto mergeEKB_ftpm_dband user-defined keys, encrypted with the OEM fuse key, to produceEKB_final_db. Send to ODM for signing with the PKC key.ODM EKB Generation Phase 2: Receive and store the
EKB_final_db.ODM Packages Generation: Generate the QSPI image, sign and encrypt
EKB_final_db, and produce per-OEM packages (ODM_fuseblob_db, QSPI image, andEKB_db.signed). Send to OEM.
Note
ODM_fuseblob_dbcontains a list of encrypted and signed fuseblobs.EKB_db.signedcontains a list of PKC- and SBK-signed/encrypted EKBs. There is a one-to-one mapping betweenodm_fuseblob-<OEM_ID>-<SN>andekb-<OEM_ID>-<SN>.
OEM Packages Generation: Generate the complete QSPI and mass-storage images. Deliver to the factory.
OEM Factory: Burn the OEM fuseblob and the per-device ODM fuseblob. Flash the QSPI, mass-storage, and per-device EKB images.
fTPM Production Flow When ODM and OEM Are the Same Entity#
In the common case, a single entity plays both ODM and OEM roles—handling fTPM functional design, EK certificate signing, device image signing, and device manufacturing. The separate ODM and OEM steps detailed earlier collapse into a single workflow run in one environment, and the UEFI PV key feature can be skipped. (The PKC key used to sign low-level firmware is also used to sign the UEFI image.) For the step-by-step procedure, refer to Production Workflow.
Software Architecture for fTPM Provisioning#
Software Architecture for fTPM Provisioning#
The software components are as follows:
fTPM provisioning script: Sample script that handles the fTPM provisioning process on the Jetson device.
Queries the EK certificates from the EKB.
Stores the EK certificate in fTPM NV memory.
Takes ownership of the fTPM.
Creates EK with the default EK handles.
The provisioning process needs to be activated only once.
This script should be bundled with the fTPM support package provided by the fTPM design manufacturer (ODM).
fTPM helper TA/CA and PTA: Applications designed for fTPM provisioning support.
fTPM helper TA: Provides interfaces to support the fTPM helper CA, helping to query SN and EK certificates.
fTPM helper CA: Provides the command-line interface (CLI) for the script to query EK certificates from the EKB.
fTPM helper PTA: Gathers fTPM properties from MB2 and EKB, retrieves the Device SN from the fuse and verifies it matches the Device SN in the EKB, and executes the EPS derivation function.
fTPM TA: Supports TPM 2.0 functionalities defined by TCG. The TPM 2.0 functions in the fTPM TA are a black box—no interface other than TCG-defined should access TPM internal functions. The fTPM TA gets the EPS from the fTPM helper PTA during the first startup and stores it in NV memory.