Embedded Security · SToESD I · Summer 2023

TPM and Disk Encryption

This page documents a project on Trusted Platform Module (TPM) and full disk encryption conducted at Deggendorf Institute of Technology. The project covered the Linux boot process, UEFI Secure Boot, LUKS block encryption, and hands-on TPM operations using tpm2-tools inside a Hyper-V virtual machine with vTPM support. The project was completed with Qais El-Yamani under the supervision of Enrico Weigelt.

View References →

Overview

A TPM chip is the hardware root of trust in modern devices. It stores cryptographic keys in shielded registers, measures the boot process through Platform Configuration Registers (PCRs), and releases secrets only when the device boots into the exact same software state that was present when the secret was sealed.

Combined with LUKS full disk encryption, TPM can automatically unlock an encrypted drive at boot — without a password — as long as the hardware and firmware have not changed. If the boot chain has been tampered with, the PCR values shift and the TPM refuses to release the key, keeping the disk locked even to an attacker with physical access.

TPM Key Hierarchies

EndorsementPrivacy-sensitive, persistent
OwnerStorage hierarchy, persistent
PlatformBIOS/SMM, persistent
NullEphemeral, lost on reboot

Key Concepts and Implementation

1. CIAAN – the five security properties+

Security in embedded systems is often evaluated against five core properties. Confidentiality protects information from unauthorised parties through encryption and access controls. Integrity ensures data has not been tampered with, using hashing or digital signatures. Availability ensures authorised users can access systems consistently. Authenticity verifies that communication originates from a trusted source. Trustworthiness (non-repudiation) ensures that a party cannot deny having sent or received a message.

Technical detail

C – Confidentiality:   access is restricted
I – Integrity:         information is unchanged
A – Availability:      service is up and running
A – Authenticity:      the source is authenticated
N – Non-repudiation:   information is reliable

These five properties form the foundation for evaluating whether a security mechanism is sufficient. TPM addresses all five simultaneously: it stores keys securely (C), detects boot changes (I), enables boot without manual input (A), certifies platform identity (A), and provides cryptographic evidence of actions (N).

2. Boot process – from power button to kernel+

When the power button is pressed, the CPU jumps to a fixed address in flash memory and reads the UEFI firmware. UEFI replaced BIOS because BIOS was too limited and vulnerable. The firmware initialises hardware, then hands off to GRUB, which loads the Linux kernel image (vmlinuz) and the initial RAM disk (initramfs). The initramfs prepares the real root file system before the full OS takes over.

Technical detail

Power on
  └─ CPU reads UEFI from EEPROM/FlashROM
       └─ UEFI initialises hardware
            └─ MBR / GPT → GRUB stage 1 (boot.img, 446 bytes)
                 └─ GRUB stage 1.5 → core.img
                      └─ GRUB stage 2 reads grub.cfg
                           └─ Loads vmlinuz + initramfs
                                └─ Kernel mounts root file system

All stages from UEFI onward read from disk partitions. Because this code is on removable storage rather than the CPU itself, an attacker with physical access and a screwdriver can replace any stage. Full disk encryption with TPM sealing addresses this attack vector.

3. initrd vs initramfs+

Two mechanisms exist for loading a temporary root file system before the real root is mounted. The older initrd (initial RAM disk) creates a fixed-size block device image in RAM, and all I/O is buffered through system memory. The newer initramfs (initial RAM file system), used since Linux kernel 2.6, is a cpio archive extracted into a tmpfs, making file access much faster and more memory-efficient.

Technical detail

initrd   (kernel ≤ 2.4):  fixed-size block device, I/O buffered
initramfs (kernel ≥ 2.6):  cpio archive → tmpfs, fast direct access

initramfs advantage: no fixed size, better memory efficiency,
  supports encrypted root partition unlock at early boot

For disk encryption with TPM, initramfs is critical because it must contain the tools and hooks to unseal the encryption key from the TPM before the encrypted root partition can be mounted.

4. UEFI Secure Boot+

Secure Boot is a UEFI feature that verifies cryptographic signatures of every piece of boot software before execution. It uses three key types: the Platform Key (PK) at the top of the trust hierarchy, the Key Exchange Key (KEK) for signing updates to the allowed database, and the Database Key (db) for verifying bootloaders and drivers. A Forbidden Signatures Database (dbx) blocks revoked binaries.

Technical detail

Key hierarchy:
  PK   – Platform Key (top-level, signed by own private counterpart)
  KEK  – Key Exchange Key (used to update db / dbx)
  db   – Database of allowed bootloaders, drivers, shells
  dbx  – Forbidden signatures database (revocation list)

Verification:
  Binary hash (SHA-256) checked against db entries
  Match in db  →  allowed to execute
  Match in dbx →  execution refused

In this project, Secure Boot was disabled on the Hyper-V VM because initramfs hooks for LUKS decryption may not carry the required signatures. Secure Boot compatibility with full disk encryption requires custom key enrolment, which adds complexity beyond the scope of this project.

5. TPM – Trusted Platform Module+

TPM is a cryptographic co-processor attached to the motherboard. It can generate key pairs, store them, perform hashing and signing, encrypt and decrypt data, and generate random numbers. Keys belong to one of four hierarchies: Endorsement (privacy-sensitive), Owner (storage, used by platform owner), Platform (used by BIOS and SMM), and Null (ephemeral, lost on reboot). Keys in the Endorsement, Owner, and Platform hierarchies survive reboots; Null hierarchy keys do not.

Technical detail

TPM capabilities:
  tpm2_createprimary   – create primary key under a hierarchy
  tpm2_create          – create child key (public + private parts)
  tpm2_load            – load key into TPM
  tpm2_evictcontrol    – persist key to a permanent handle (e.g. 0x81010001)
  tpm2_unseal          – retrieve sealed secret using stored key
  tpm2_rsaencrypt      – encrypt with RSA key
  tpm2_rsadecrypt      – decrypt with RSA key
  tpm2_getrandom       – generate random bytes
  tpm2_getcap          – query TPM capabilities

The Seed inside the TPM is the root phrase from which all keys are derived. It is never exposed outside the chip, which means keys cannot be extracted even by software with root access.

6. PCR – Platform Configuration Registers+

TPM contains 24 Platform Configuration Registers (PCRs) that hold cryptographic hash measurements of the system at boot time. Each PCR covers a specific part of the boot chain. When hardware, firmware, or bootloader changes, the PCR values change. This chain of trust allows TPM to detect tampering and refuse to unseal an encryption key if the boot state has changed.

Technical detail

PCR 0  – CRTM, BIOS code, Host Platform Extensions
PCR 1  – Host Platform Configuration (CPU, RAM replacements)
PCR 2  – Option ROM Code
PCR 3  – Option ROM Configuration and Data
PCR 4  – IPL Code (MBR)
PCR 5  – IPL Configuration and Data (partition changes)
PCR 6  – State Transition and Wake Events
PCR 7  – Secure Boot state (PK, KEK, db, dbx)

Hash algorithms supported: SHA1, SHA256, SHA384

A TPM policy can bind a sealed secret to specific PCR values. If the machine boots with the same software stack, PCRs match and the key is released automatically. If anything changes – even a BIOS update – the seal breaks and the key will not be released.

7. LUKS – Linux Unified Key Setup+

LUKS is a disk encryption specification for block device encryption on Linux. It maintains a header with an encryption key table, allowing multiple passphrases or key slots. Each slot can hold a different key that unlocks the same encrypted volume. LUKS works at the block device level, so the file system inside is completely unaware of the encryption.

Technical detail

Partition layout in lab:
  /dev/sda1  – 512 MB  EFI (vfat, unencrypted)
  /dev/sda2  – 49.5 GB root filesystem target for LUKS

Encryption setup (cryptsetup):
  cryptsetup luksFormat --type=luks2 /dev/sda2
  cryptsetup open --type=luks2 --tpm2-policy=0:... /dev/sda2 encrypted_disk
  mkfs.ext4 /dev/mapper/encrypted_disk
  mount /dev/mapper/encrypted_disk /mnt/encrypted

TPM and LUKS are complementary. TPM provides hardware-level key storage and PCR-based boot measurement. LUKS provides the encrypted container. Together they allow automatic decryption at boot only when the correct hardware and software configuration is present.

8. Hyper-V vs VirtualBox vs QEMU – hypervisor choice+

Three virtualisation options were evaluated. Hyper-V is a Type 1 hypervisor that runs directly on hardware and supports vTPM (virtualised TPM) for Generation 2 VMs. Oracle VirtualBox is a Type 2 hypervisor that runs on the host OS with broader OS support but no native vTPM without plugins. QEMU is an open-source full-system emulator that can emulate a TPM chip in software but requires more manual script-based configuration.

Technical detail

Hyper-V:      Type 1, hardware-level, vTPM in Gen2 VMs  ✓ chosen
VirtualBox:   Type 2, host OS dependent, no native vTPM
QEMU:         Full emulation, TPM emulatable but setup complex

Note: Hyper-V not available on Windows 10 Home.
Workaround: batch script to enable via DISM:
  Dism /online /enable-feature /featurename:Microsoft-Hyper-V-All

Generation 2 was selected in Hyper-V specifically for vTPM support. After creating the VM and installing Ubuntu, Secure Boot was disabled from the Security section and TPM was enabled before first boot.

9. First steps with TPM – key creation and sealing+

The initial exercises followed a clear sequence: clear the TPM state, create a primary key under a hierarchy, generate random bytes as a secret input, create a sealed object (public and private parts) bound to that secret, load both parts into the TPM, and persist the loaded object to a permanent handle. The sealed object can only be unsealed using the correct key handle, producing the original secret as output.

Technical detail

# Step-by-step (ECC primary, sha256, seal secret bytes):
tpm2_clear
tpm2_createprimary --quiet --hierarchy=o --key-algorithm=ecc \
  --hash-algorithm=sha256 --key-context=prim.ctx

dd if=/dev/urandom bs=1 count=32 status=none > KEY_IN

tpm2_create --hash-algorithm=sha256 --public=seal.pub \
  --private=seal.priv --parent-context=prim.ctx -i- < KEY_IN

tpm2_load --parent-context=prim.ctx --public=seal.pub \
  --private=seal.priv --name=seal.name --key-context=seal.ctx

tpm2_evictcontrol --hierarchy=o --object-context=seal.ctx 0x81010001

tpm2_unseal -c 0x81010001 > KEY_OUT
sha256sum KEY_IN KEY_OUT   # must match

The tpm2_evictcontrol command moves the key context from a session-local handle to a permanent NV handle. This allows the same key to be used across reboots without recreating the primary and child keys each time.

10. Simple file encryption with RSA key+

A practical file encryption exercise created an RSA-2048 key pair, loaded both parts into the TPM, encrypted a text message using the public key, and decrypted it using the private key held in the TPM context. The encrypted binary file is unreadable without the TPM, while the decrypted plaintext file can be read normally. This exercise demonstrated the fundamental difference between hardware-backed and software-backed encryption.

Technical detail

# Create RSA primary
tpm2_createprimary -c primary.ctx

# Create RSA child key pair
tpm2_create -C primary.ctx -G rsa2048 -u key.pub -r key.priv

# Load into TPM
tpm2_load -C primary.ctx -u key.pub -r key.priv -c key.ctx

# Encrypt a message
echo "Ich bin extra dip-sauce" > mesg.dat
tpm2_rsaencrypt -c key.ctx -o mesg.enc mesg.dat

# Decrypt
tpm2_rsadecrypt -c key.ctx -o mesg.ptext mesg.enc
cat mesg.ptext   # → "Ich bin extra dip-sauce"

The mesg.enc file contents are binary and unreadable. The mesg.ptext file is the recovered plaintext. This confirms that encryption and decryption work correctly through the TPM context, with the private key never leaving the chip.

11. Disk encryption script – combining TPM policy with LUKS+

The full disk encryption script combined TPM key creation with a PCR policy and LUKS formatting. After creating a primary key and binding it to PCR values 0 through 7 with sha256, the script checked for root privileges and confirmed the TPM handle was available before formatting the target partition. The encrypted container was then opened with the TPM-derived key and mounted.

Technical detail

#!/bin/bash
disk=/dev/sda2
tpm_handle=0x81010040

# Verify handle exists
tpm2_readpublic -c $tpm_handle &>/dev/null || exit 1

# Create PCR-bound policy (covers PCR 0–7)
tpm2_createpolicy --policy-pcr -l sha256:0,1,2,3 \
  -L pcr0.policy -L policy.digest

# Warn and format
cryptsetup luksFormat --type=luks2 $disk

# Open with TPM policy
cryptsetup open --type=luks2 \
  --tpm2-policy=0:$PWD/policy.digest $disk encrypted_disk

mkfs.ext4 /dev/mapper/encrypted_disk
mount /dev/mapper/encrypted_disk /mnt/encrypted

Failures in the final script were caused by the disk being mounted during the format attempt and incorrect cryptsetup policy argument syntax. The logical structure was correct and the project identified the precise fix needed for a production-ready implementation.

Tools and Libraries

  • tpm2-tools – command-line TPM 2.0 utilities
  • cryptsetup – LUKS disk encryption management
  • Hyper-V – Type 1 hypervisor with vTPM support
  • OpenSSL – software-based comparison for key operations
  • tpm2-tss, FAPI, ESAPI, SAPI – TPM software stack layers
  • Ubuntu 20.04 LTS – guest OS running inside the VM

Key Challenges

  • Finding useful, consistent documentation and guides online was difficult.
  • Disk must be unmounted before LUKS formatting – mounting state caused errors.
  • PCR policy arguments for cryptsetup open required precise syntax.
  • Secure Boot conflicts with unsigned initramfs hooks for LUKS.
  • Hyper-V requires Windows 10 Pro or Enterprise for native access.

References and Materials

These sources were used while preparing the TPM background theory, hypervisor comparison, Secure Boot explanation, and practical tpm2-tools exercises.

ACPI – Wikipedia

Advanced Configuration and Power Interface standard used by operating systems to discover and configure hardware components.

https://en.wikipedia.org/wiki/ACPI
© 2026 Atam Oguz Erkara