TrustZone and Encryption¶

ARM TrustZone divides the processor into two worlds: the Secure World and the Normal World. In BCA, OP-TEE occupies the Secure World from early in the boot chain, running at Exception Level 1 in the Secure domain (S-EL1) on Cortex-A cores. Bunker OS and Open World both run in the Normal World at EL1, each in its own VM managed by the CLARE Hypervisor.

OP-TEE in the BCA Boot Chain¶

OP-TEE is not an optional component — it is loaded and verified by ATF before the hypervisor, and it provides the Secure Monitor Call (SMC) interface that the hypervisor and Bunker OS use to perform secure operations. This architecture means OP-TEE’s presence is guaranteed from first boot and does not rely on post-provisioning setup.

Once Bunker OS is running, it communicates with OP-TEE directly via the standard GlobalPlatform TEE Client API and the Linux TEE driver (/dev/tee0). Open World accesses the same OP-TEE services indirectly, through Turmux RPC over the vsock interface. Bunker OS acts as a secure proxy: it receives requests from Open World, performs the TEE operation, and returns the result. This arrangement prevents Open World from ever obtaining raw access to the TEE driver, which would represent a privilege escalation.

Secure Services Provided by OP-TEE¶

OP-TEE exposes the following services, accessible from Bunker OS and — via Turmux — from Open World:

Trusted Storage: Key-value pairs stored in OP-TEE Secure Storage are encrypted and integrity-protected using a Hardware Unique Key (HUK) derived from immutable silicon identifiers. Data stored here survives reboots but is inaccessible without the corresponding HUK, preventing extraction from a detached flash chip.
PKCS#11 Interface: OP-TEE’s PKCS#11 Trusted Application exposes a standard PKCS#11 token over the TEE, allowing cryptographic key generation and usage (RSA, ECDSA, AES, HMAC) entirely within the Secure World. Private keys never leave OP-TEE.

Data-at-Rest Encryption¶

Data-at-rest encryption in BCA is based on the Linux kernel’s dm-crypt device mapper target, which provides transparent block-level encryption. The encryption key is generated at first boot, sealed by OP-TEE (using the HUK as wrapping key), and stored in OP-TEE Trusted Storage. On subsequent boots, the sealed key blob is unsealed in the Secure World and passed to the kernel only as a transient in-memory handle — the plaintext key is never exposed to the Normal World filesystem.

Three storage backends are supported for key sealing, in order of preference:

OP-TEE + fTPM: Platforms without a TPM can use a firmware TPM implemented as an OP-TEE Trusted Application. The fTPM exposes a standard TPM 2.0 interface, allowing TPM-based key sealing/unsealing.
OP-TEE Trusted Storage only: A fallback for platforms where CAAM and fTPM are not available. The HUK is derived from SoC silicon identifiers through OP-TEE’s internal key derivation.

Enabling Encryption in a Custom Build¶

Note

Data-at-rest encryption is enabled by default in BCA reference design images. The following applies only to teams integrating meta-bunker into a custom layer stack.

Data-at-rest encryption is configured in meta-bunker via the bca-encryption BitBake class:

# In conf/local.conf
INHERIT += "bca-encryption"

# Select the key-sealing backend (auto-detected if not set)
BCA_ENCRYPT_BACKEND ?= "optee"   # or "ftpm"

# Mount point of the encrypted data partition
BCA_DATA_MOUNTPOINT ?= "/var/data"

The build system generates a first-boot service that provisions the encryption key on the first power-on and reboots into the fully encrypted system. Subsequent boots unlock the partition transparently before sysinit.target is reached.

Refer to Meta Layers Reference for the exact variable names and available backend options for each supported platform.