$ openssl list -digest-algorithms

Cryptography

What is it?

The cryptography used at each step of the Hardware page: authentication, signature, hash and cipher, and what each guarantees.

// three questions

Hash, authentication, signature

Hash

Has it changed?

SHA-256, SHA-384, SHA-512

Authentication

Does the sender hold our secret key?

HMAC, AES-GCM and AES-CCM tags. Key from ECDH or ECDHE, or a hardware key (HUK).

Signature

Did the key owner produce it?

RSA (PSS or PKCS#1 v1.5), ECDSA

What each step can guarantee

Authenticity: who produced it
Integrity: it was not modified
Confidentiality: unreadable without the key
Freshness: not a replay or a rollback
Binding: tied to one device or one boot state

// shared-secret tags

HMAC, AES-GCM and AES-CCM

All three produce a tag: a short value that only a holder of the secret key can compute. The receiver recomputes it and compares. A match proves the data was not modified and that the sender holds the key, but not which key holder sent it.

HMAC: a tag from a hash

HMAC(K, m) = H((K ⊕ opad) || H((K ⊕ ipad) || m)), where opad and ipad are two fixed padding constants and H is a hash such as SHA-256.

The double hash is what makes it safe. With the naive H(K || m), an attacker who sees one tag can append data to a SHA-256 message and compute a valid tag without the key (a length-extension attack). HMAC only authenticates: the data stays readable. On this page it authenticates TPM session commands and RPMB frames, and serves as a key derivation function (OP-TEE's SSK and TSK, the HKDF of TLS 1.3).

AES-GCM and AES-CCM: encrypt and tag in one mode

Both are authenticated encryption (AEAD). AES in counter mode (CTR) encrypts, and the tag covers the ciphertext plus optional header data that stays in clear. They differ in how the tag is computed:

	AES-GCMGalois/Counter Mode	AES-CCMCounter with CBC-MAC
Tag	GHASH: a polynomial over the ciphertext, evaluated in GF(2^128) at a key H = AES(K, 0). Encrypt, then authenticate.	CBC-MAC: AES chained over the plaintext, then the tag itself is encrypted. Authenticate, then encrypt.
Cost	One AES call per block, parallel. Fast with carry-less multiply instructions (x86 PCLMULQDQ, Arm PMULL).	Two AES calls per block, and the CBC-MAC part is sequential.
Streaming	Yes: the message length is only needed at the end.	No: the message length goes into the first CBC-MAC block, so it must be known before starting.
Hardware	An AES core plus a GF(2^128) multiplier.	Only an AES encryption core, which is why small microcontrollers like it.
Nonce and tag	96-bit nonce recommended; 128-bit tag typical.	7 to 13-byte nonce (a longer nonce caps the message length); 4 to 16-byte tag.
Nonce reused	Leaks the XOR of the two plaintexts and lets an attacker recover H, then forge tags.	Leaks the XOR of the two plaintexts.
Seen in	TLS 1.3, TF-A encrypted firmware (aes_gcm), OP-TEE REE FS and encrypted TAs.	Wi-Fi WPA2 (CCMP), Bluetooth LE, Zigbee and IEEE 802.15.4, TF-A (aes_ccm).

Sources: RFC 2104 (HMAC), NIST SP 800-38D (GCM), NIST SP 800-38C and RFC 3610 (CCM).

// how they work together

One step: loading an encrypted image

The cipher gives confidentiality only. The image sits in flash as ciphertext; hash and signature decide whether it may run. BL2 loading an encrypted BL31 in TF-A:

Sources: bl_common.c, auth_mod.c, io_encrypted.c.

What each one gives

Signature: Authenticity: only the vendor's private key can make the certificate that carries H.
Hash: Integrity: D equal to H ties the decrypted bytes to the signed value.
Cipher: Confidentiality: flash content is unreadable without the key. The GCM tag detects modified ciphertext but does not prove who built it.

// per boot step

Cryptography at each boot step

Badges match the steps on the Hardware page. An empty cell means none.

Step	Authenticationshared secret	Signaturekey pair	Hashwhat, compared with what	Cipherwhat, with which key	Guarantees
Secure bootverify: may this code run?
2 BL1 verifies BL2Boot ROM, the root of trustTF-A TBB, build options, auth_mod.c	none	RSA (PKCS#1 v2.1, 2048-bit default) or ECDSA P-256 / P-384, on an X.509 certificate with an NV counter against rollback	SHA-256 by default. The hash of the certificate's public key is compared with the ROTPK hash in OTP The hash of the loaded BL2 image is compared with the hash inside the signed certificate	none	AuthenticityIntegrityFreshness
3 BL2 verifies BL31, BL32, BL33One key per level of the certificate chainTF-A TBB, auth framework	none	Same RSA or ECDSA: ROT key, then trusted-world and non-trusted-world keys, then one key per image	The hash of each loaded image and config file is compared with the hash inside its signed content certificate	none	AuthenticityIntegrityFreshness
3 BL2 decrypts BL31, BL32, BL33Optional encrypted firmware, off by defaultbuild options, io_encrypted.c	AES-GCM or AES-CCM tag stored in the image header, verified during decryption	none	none	AES-256 decrypts the image in place, right after it is read from flash Key from the platform: SSK shared by a device class, or BSSK unique per device. IV and tag come from the image header	ConfidentialityIntegrity
4 BL31 runsEL3 runtimeTF-A measured boot	none	none	none	none	none
5 BL32 loads trusted applicationsOP-TEEOP-TEE TAs	none	RSA on a signed header: PKCS#1 v1.5 with SHA-256 by default, PSS also accepted; subkeys can delegate signing	SHA-256 typical. The TA is hashed and compared with the hash in the signed header	Optional encrypted TAs: AES-GCM by default, with a device-specific or class-wide key	AuthenticityIntegrityConfidentiality
6 BL33 loads the OSU-Boot FIT or UEFI Secure BootU-Boot FIT, Secure Boot keys	none	U-Boot: signed FIT hash, for example sha256 with rsa2048, or sha512 with ecdsa256 UEFI: Authenticode (PKCS#7) checked against db; RSA-2048 with SHA-256 is the usual choice	U-Boot hashes each FIT image and compares it with the hash covered by the signature UEFI: the Authenticode digest of the binary is what gets signed; dbx can also ban specific digests	none	AuthenticityIntegrity
PC firmware verifies itselfIntel Boot Guard, AMD Platform Secure BootIntel key usage, Boot Guard chain, AMD PSB	none	Intel: the CPU checks Intel's signature on the ACM. The ACM checks the OEM Key Manifest against the OEM key hash fused in the chipset, then the Boot Policy Manifest AMD: the PSP boot ROM checks the PSP firmware, which checks the OEM-signed BIOS; fuses bind the CPU to the OEM key	The Boot Policy Manifest holds the hash of the Initial Boot Block (IBB), compared with the IBB in flash The IBB then compares the hash of the rest of the firmware (OBB)	none	AuthenticityIntegrity
Updating the Secure Boot keysUEFI authenticated variables: PK, KEK, db, dbxSecure Boot keys, UEFI on U-Boot	none	Each update is a signed variable: the PK signs KEK changes, a KEK signs db and dbx changes. RSA-2048 with SHA-256 is the recommended minimum	db and dbx can list SHA-256 digests of single binaries, not only certificates	none	AuthenticityIntegrity
7 shim verifies GRUB and the kernelLinux on a Secure Boot PCshim, SBAT	none	Firmware checks shim against Microsoft's UEFI CA in db shim checks GRUB and the kernel against its built-in distribution certificate, or an enrolled Machine Owner Key (MOK) SBAT: generation numbers in signed metadata revoke old versions without growing dbx	Authenticode digest of each PE image, also checked against dbx and the MOK deny list	none	AuthenticityIntegrity
Boot loader and kernel verify the OSWindows trusted bootWindows boot process	none	Digital signatures (Authenticode): the boot loader checks the kernel, then the kernel checks the boot drivers, startup files and the ELAM driver	The loader hashes each kernel or driver file (Authenticode digest) and checks it against the signature	none	AuthenticityIntegrity
8 Kernel verifies its modulesLinux module signing, lockdownmodule signing, kernel_lockdown(7)	none	Signature appended to each module: RSA, NIST P-384 ECDSA or ML-DSA, checked against the kernel's built-in trusted keys With lockdown on, unsigned modules and unsigned kexec images are refused	SHA-2 or SHA-3 (256, 384 or 512 bits) of the module, chosen by the signature	none	AuthenticityIntegrity
9 Kernel verifies the root filesystemdm-verity (Linux, Android)dm-verity	none	Optional PKCS#7 signature on the root hash, checked against the kernel keyring	Each disk block is hashed when read. The hashes form a Merkle tree whose root hash must match (SHA-256 for example)	none	IntegrityAuthenticity
Measured bootrecord: what code did run?
2, 3 BL1 and BL2 measure what they loadExtend a PCR in a TPM or RSE, or write the event logTF-A measured boot, bl_common.c, TPM 2.0 Part 1	none	none	The loaded image is hashed (SHA-256 or SHA-384) The digest is extended: PCRnew = H(PCRold \|\| digest), one-way and extend-only Verified public keys can be measured too The event log is plain data: replaying it must give the PCR value	none	Integrity
UEFI firmware and Linux measurePC: fixed PCR numbers per componentLinux TPM PCR registry	none	none	Firmware code into PCR 0, option ROMs into PCR 2, boot loaders (and a kernel run as an EFI binary) into PCR 4 Secure Boot state and the PK, KEK, db, dbx contents into PCR 7 Linux: IMA measures files into PCR 10; systemd-stub measures unified kernel images into PCR 11	none	Integrity
Talking to the TPMFirmware or OS sends commandsTPM 2.0 Part 1	HMAC session: an HMAC over each command and response, with nonces Salted session: the salt is encrypted to a TPM key, often the EK or SRK, with RSA-OAEP or ECDH	none	none	AES-CFB encrypts sensitive command parameters, such as new authorization values. The key comes from the session	AuthenticityIntegrityConfidentialityFreshness
Sealing a key to the boot stateThe TPM releases it only if the PCRs matchTPM 2.0 Part 1, BitLocker FAQ	Policy session on the PCRs; optional PIN as authValue A blob stored outside the TPM carries an HMAC integrity value	Optional PolicyAuthorize: an authority, often the OS vendor, signs the allowed PCR policies, so firmware updates do not lock you out	The selected PCR values are hashed into a policy digest. The TPM releases the key only if it matches BitLocker: SHA-256 of the PIN, first 160 bits used as the authorization value	AES-CFB encrypts the sealed blob stored outside the TPM, under a key derived from the TPM storage parent	ConfidentialityIntegrityBinding
Quote: evidence for a verifierThe TPM signs selected PCRs and a nonceTPM 2.0 Part 1, RFC 9683	AK enrolment: the CA wraps a secret to the EK (RSA-OAEP or ECDH), so only that TPM can recover it	Attestation key (a restricted signing key) signs the quote: RSA or ECDSA	The selected PCRs are hashed into one digest, placed in the quote with the verifier's nonce The quote is hashed and that hash is signed	none	AuthenticityIntegrityFreshness
Channel to the verifierUsually TLS; the quote is signed either wayRFC 8446	TLS 1.3: ECDHE key exchange sets up the keys, and the GCM tag authenticates every record TLS_AES_128_GCM_SHA256 is the mandatory-to-implement suite	Certificate signatures in the handshake (ECDSA or RSA-PSS)	The handshake transcript is hashed (SHA-256) and fed to HKDF, which derives the traffic keys	AES-128-GCM encrypts every record after the ServerHello, including the rest of the handshake	AuthenticityIntegrityConfidentiality
Runtime and OSkeep data safe after boot
5 OP-TEE secure storageTrusted storage on the REE file system, or on RPMBOP-TEE secure storage	REE FS: AES-GCM tag on each block, plus a hash tree Key chain: HMAC-SHA256(HUK, chip ID \|\| string) gives the SSK, HMAC-SHA256(SSK, TA UUID) gives the TSK RPMB: HMAC-SHA256 on every eMMC frame, with a write counter. This is what gives rollback protection: REE FS alone has none	none	SHA-256 hash tree over the blocks: any change shows up in the root RPMB: SHA-256 of the file key seeds the ESSIV	AES-GCM encrypts file blocks and metadata (REE FS); AES-CBC with ESSIV in RPMB A random file key (FEK) per file is encrypted with the TA storage key (TSK)	ConfidentialityIntegrityBindingFreshness
Full-disk encryptionBitLocker OS volumeBitLocker, BitLocker FAQ	none	none	none	XTS-AES encrypts every sector with the FVEK (128-bit by default); XTS adds no authentication tag The FVEK is wrapped by the VMK; with Secure Boot set up, the TPM seals the VMK to PCR 7 and 11 by default	ConfidentialityBinding

Common mix-up. AES-GCM is not part of measured boot, which only hashes into a PCR. It appears next to it: encrypted firmware, OP-TEE secure storage, TLS to the verifier.

// build options

TF-A options that choose the algorithms

Option	Values	Used for
KEY_ALG	rsa (default), rsa_1_5, ecdsa, ecdsa-brainpool-regular, ecdsa-brainpool-twisted	Certificate signatures. rsa_1_5 is legacy and not TBBR compliant.
KEY_SIZE	rsa: 1024, 2048 (default), 3072, 4096. ecdsa: 256 (default), 384	Key size for the chosen algorithm.
HASH_ALG	sha256 (default), sha384, sha512	Image and key hashes in the certificates.
MBOOT_TPM_HASH_ALG	sha256, sha384	Digests extended into the TPM by measured boot.
DECRYPTION_SUPPORT	none (default), aes_gcm, aes_ccm	Authenticated decryption of encrypted firmware.
ENC_KEY, ENC_NONCE	256-bit key, 96-bit nonce	Encrypt firmware at build time. The nonce is stored in clear in the image header: it must be unique, not secret.

Source: TF-A build options.