Speaker
Description
Linux has no standard model for provisioning and unlocking encrypted persistent storage at boot in environments where the underlying platform cannot be fully trusted. Today, every deployment stack solves this independently: custom boot agents, post-provisioning scripts, and platform-specific unlock logic. The mechanism exists — LUKS2 tokens and the cryptsetup plugin interface — but the workflow around it does not. Every team that wants attestation-backed storage unlocking ends up writing the same three things from scratch: a script to register token metadata at provisioning time, a plugin to perform attestation and key retrieval at boot, and custom logic to handle failure cases. None of this is reusable across platforms or deployable through standard Linux tooling.
This session proposes that the LUKS2 token mechanism and the cryptsetup plugin interface should become the standard interoperability contract between Linux storage tooling and external attestation-aware key services. In this model, a Key Broker Service holds encryption keys and releases them only after the system proves its identity through remote attestation. The LUKS2 header carries the token metadata that tells systemd-cryptsetup which plugin to invoke at boot, making the storage layer independent of any specific attestation technology, hardware platform, or key service implementation. The provisioning side is handled by systemd-repart, which registers the token metadata in the LUKS2 header at first-boot — no separate import step, no custom scripts.
For this model to work reliably end-to-end, three specific gaps need to close. First, the cryptsetup plugin error contract is undefined: today systemd-cryptsetup silently falls through to passphrase unlock when a plugin fails, with no distinction between permanent attestation failure and transient network unavailability. A KBS plugin that fails because attestation was rejected should behave very differently from one that timed out waiting for the network — but there is currently no standard way to express that. Second, the LUKS2 token JSON schema beyond type and keyslots is unspecified: KBS-specific metadata such as service endpoint URLs is stored in private fields with no agreed naming, making provisioning tools and unlock plugins non-interoperable without bilateral coordination. Third, there are no packaging or initrd inclusion guidelines for token plugins, leaving distributions without a clear answer on how to ship and discover them at boot.
The session will walk through the current state of the code in systemd-cryptsetup and systemd-repart, identify precisely where these gaps exist today, and open a discussion on what standardisation is needed. The goal is agreement on reusable, upstream building blocks for attestation-driven storage provisioning — so that every platform and deployment stack building on Linux does not have to solve this problem independently.