Hi Akshay, first of all, let me say that I am very happy to see such interest in making the TPM usable throughout Linux. This has also been the main driver for me to get us going. Now on to some of your points:
Main motivation: I would love to see fixes for short comings you see to be included in the existing tpm2-tss modules instead of introducing yet another API to the eco system and ultimately leading to more fragmentation and confusion for end users. FAPI keystore: I know that the file-based storage of key (meta) data can be a bit problematic at times. Honestly, it was a restriction introduced by time a resource availability. I'd love to see alternative implementations that could be based on a system service or other means. I'd also love to see an implementation that runs on windows. We do have an internal abstraction for the keystore in FAPI and I'd invite you to please contribute with alternative implementations here. This could very much also include VARLINK or DBus based communication to a keystore service. Language agnosticity: We already have bindings for Python and Rust besides the existing C implementation. We also have a dlopen-based API for private inclusion. If there are major users beyond these languages, I'd proposal to let's add more bindings. OpenSSL: There already exists the tpm2-openssl provider that basically does what you envision. I'd love to see this being extended to using FAPI keystore as well as the FAPI policy language capabilities. So the use case you offer seems to already be implemented here. If not please let us know the specific shortcomings you see here. API (tpm_sign_payload): This looks very very similar to the Fapi_Sign() functionality. Coming back to my first point here, IMHO we are already close to what you want and I'd love to hear about specific shortcomings and then to see them being addressed in the tpm2-tss FAPI module itself, instead of creating a new "competing" service implementation. Boot-time provisioning: This is a tough one. We've though hard about adding automated provisioning but decided to postpone it until the user calls Fapi_Provision() i.e. tss2_provision. This allows configuration of preferred crypto profile and other things. Also since provisioning requires user interaction for password setting, we did not know how to do it differently. That being said, I could totally see this being integration "better" with a GUI or similar or inside the distro installers. Attestation and such: Here we still have the biggest shortcoming. There are attempts here and there but the big problem has always been the generation of reference values and the assessment of Quotes. The Fapi_Quote command already gives you the system state with all its logs, but we need network protocols and then specifically a backend service for assessing the Event logs. This is where the big work lives. All that being said, I am very open to getting stuff into tpm2-tss in order to facilitate more use cases. Maybe we can have separate discussions for some of your short comings and get a bit more into depth on each of these. Looking forward to more discussions on this topic. Cheers, Andreas -----Original Message----- From: Akshay Hendre <[email protected]> Sent: Sonntag, 10. Mai 2026 10:11 To: [email protected] Subject: Fwd: [RFC] Proposal for Centralized TPM 2.0 Userspace Management Layer: systemd-tpmd Caution: This e-mail originated outside Infineon Technologies. Please be cautious when sharing information or opening attachments especially from unknown senders. Refer to our intranet guide<https://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx> to help you identify Phishing email. I am cross-posting proposal for [RFC: systemd-tpmd] for the right audience. ---------- Forwarded message --------- From: Akshay Hendre <[email protected]> Date: Sun, 10 May 2026 at 13:31 Subject: [RFC] Proposal for Centralized TPM 2.0 Userspace Management Layer: systemd-tpmd To: <[email protected]> Hello all, I am submitting a proposal to introduce systemd-tpmd, a centralized TPM 2.0 userspace management layer designed to serve as the foundation for TPM integration on Linux. This proposal deliberately focuses on architectural design in order to reach consensus before diving into implementation details. Table of Contents ======================== 1. Problem Statement 2. Proposed Solution: systemd-tpmd Architecture 2.1 Boot-Time Provisioning and State Escrow 2.2 Application Ecosystem and Architectural Layers 2.3 Standard Interaction Sequence 3. Supported Interaction Paths: Varlink and OpenSSL 3.0 3.1 Path A: The OpenSSL 3.0 Provider 3.2 Path B: Native Varlink API (io.systemd.Tpm) 4. System Administration and Managed Environments 4.1 State Management and Daemon Recovery 4.2 Command Line Integration and Access Control 5. Security, Sandboxing, and Simulation 5.1 Hardened Service Confinement 5.2 Simulator Support and Fallback Prevention 6. Future Capabilities and Solvable Problems 6.1 Seamless Firmware Updates (Solving the LUKS / fwupd Lockout) 6.2 Standardizing TPM-Backed Passkeys for the Linux Desktop 6.3 Stabilizing Continuous Remote Attestation for Fleet Management 6.4 Secure SSH Key Protection 6.5 Confidential Computing and vTPM State Management 1. Problem Statement ======================== While the Linux kernel provides robust low-level multiplexing for the Trusted Platform Module via /dev/tpmrm0, the userspace ecosystem currently lacks a centralized, stateful broker to manage hardware cryptography. To understand these gaps, it is useful to compare the Linux landscape with the established Windows paradigm. On Windows, hardware cryptography is handled seamlessly via the Cryptography API: Next Generation (CNG) and the Platform Crypto Provider (PCP). The Windows operating system automatically takes ownership of the TPM during boot, securely escrows the owner password, and provides a unified, multi-tenant broker for all applications. Developers simply request a cryptographic operation, and the OS handles the hardware state, context swapping, and security authorizations automatically. In stark contrast, the Linux ecosystem delegates hardware state management and cryptographic session establishment directly to the applications themselves. This fragmented approach creates severe architectural gaps that impact multiple groups: * Application Developers: Enhanced System API (ESAPI) and the operational fragility of the Feature API (FAPI). While ESAPI requires expert-level hardware management—such as manually invoking TPM2_CreatePrimary for SRK provisioning—it risks locking out applications if the Owner Hierarchy is password-protected. Conversely, FAPI simplifies provisioning but introduces a fragile file-based keystore (typically /var/lib/tpm2-tss/system/keystore) that frequently triggers fatal 0x0006000b (Permission Denied) errors during concurrent access. * System Administrators: Currently, because there is no centralized daemon to automatically provision the TPM and establish a shared Storage Root Key (SRK), applications often attempt to create their own primary keys directly under the Owner hierarchy. If an administrator follows security best practices and password-protects the Owner hierarchy, core OS utilities like systemd-cryptenroll immediately fail to bind LUKS2 volumes, throwing an 0x000009a2 authorization error. Administrators are caught in a paradox: leave the TPM Owner hierarchy entirely unprotected, or break system functionality. * Managed Enterprise Fleets: In large deployments, the lack of a centralized policy broker means that standard software and kernel updates alter Platform Configuration Registers (PCRs). This arbitrarily breaks fragile local trust chains, locks users out of encrypted disks, and causes disruptive false positives in continuous remote attestation frameworks. 2. Proposed Solution: systemd-tpmd Architecture ======================== systemd-tpmd is proposed as a persistent, stateful userspace management layer acting as the absolute foundation for TPM integration on Linux. It operates as a highly privileged system daemon sitting directly between the in-kernel resource manager and the unprivileged application layer, providing unified abstraction and state escrow. 2.1 Boot-Time Provisioning and State Escrow ------------------------ Upon initialization, systemd-tpmd evaluates the hardware provisioning state. If unprovisioned, it acts based on a configuration parameter (e.g., ProvisioningMode=): * Auto (Default): It automatically takes ownership, generating high-entropy cryptographic secrets for the Owner, Endorsement, and Lockout hierarchies. It invokes TPM2_CreatePrimary to establish the Storage Root Key (SRK) and utilizes TPM2_EvictControl to lock the SRK into the TPM's persistent NVRAM at the TCG-standardized handle 0x81000001. The SRK is instantiated with an empty authorization value, allowing the daemon to utilize it as a universal parent for encrypting and decrypting application-specific child keys without needing to unlock the protected Owner hierarchy. * Deferred: To prevent conflicts with enterprise infrastructure-as-code or CI/CD pipelines that strictly manage deployment states, provisioning can be deferred. In this mode, systemd-tpmd will wait for external tooling to trigger the provisioning process via an explicit administrative command. 2.2 Application Ecosystem and Architectural Layers ------------------------ To ensure broad ecosystem compatibility, systemd-tpmd supports two primary interaction paths for applications: a native Varlink API and a fully supported OpenSSL 3.0 Provider. The architecture is defined as follows: * Layer 1: Applications (Daemons, web servers, systemd-cryptenroll) - Consumers of cryptographic operations. Applications require zero knowledge of TPM byte-marshaling and do not require membership in the tss group. * Layer 2: Interaction Interfaces (Varlink & OpenSSL 3.0) - Applications interface with the broker either transparently via standard OpenSSL EVP APIs (using the systemd-tpmd OpenSSL provider) or directly via plain-text JSON over AF_UNIX sockets (io.systemd.Tpm). Both paths provide strict process isolation, ensuring applications never possess hardware file descriptors. * Layer 3: The Broker (systemd-tpmd) - Stateful engine that securely escrows hierarchy passwords, parses incoming requests, enforces cgroup/user access controls, and evaluates PCR policies. * Layer 4: TCG Stack (tpm2-tss / ESAPI) - Embedded strictly within the daemon. Translates high-level requests into TCG-compliant byte streams and establishes encrypted HMAC bus sessions. * Layer 5: Kernel & HW (/dev/tpmrm0 & Physical TPM) - The Linux kernel resource manager that multiplexes the physical, discrete TPM 2.0 chip. 2.3 Standard Interaction Sequence ------------------------ Step 1. Request Formulation: An unprivileged application (e.g., a web server) needs to sign a TLS handshake. It reads its encrypted privateBlob and publicBlob from the standard filesystem. Step 2. Transmission: The application issues a signing request either through the OpenSSL 3.0 provider or natively via a JSON Varlink socket. Step 3. Broker Execution: systemd-tpmd receives the request, utilizes the public, empty-password SRK to load the encrypted private blob into the TPM's volatile memory, and instructs the hardware to sign the digest. Step 4. Response Delivery: The TPM outputs the signature. systemd-tpmd clears the transient context and returns the signature to the application via the chosen interface. The application successfully utilized the hardware without ever possessing permissions to the TPM device node. 3. Supported Interaction Paths: Varlink and OpenSSL 3.0 ======================== systemd-tpmd provides two robust avenues for application integration, ensuring both legacy compatibility and modern, lightweight IPC. 3.1 Path A: The OpenSSL 3.0 Provider ------------------------ To guarantee immediate, seamless integration for the vast majority of the Linux ecosystem (including web servers, VPN daemons, and SSH agents), systemd-tpmd ships with a dedicated OpenSSL 3.0 provider module. * Transparent Execution: When configured in openssl.cnf, applications utilizing standard OpenSSL EVP APIs will have their cryptographic operations transparently intercepted by the provider. * Stateless Routing: The OpenSSL provider acts as a lightweight client, packaging the OpenSSL memory buffers into Varlink payloads and routing them to the systemd-tpmd daemon. * Zero-Code Changes: Existing C/C++, Rust, and Python applications relying on OpenSSL can leverage TPM hardware-backed keys with minimal changes to application code. 3.2 Path B: Native Varlink API (io.systemd.Tpm) ------------------------ For applications desiring to communicate directly with the broker without an OpenSSL dependency (such as early-boot utilities and systemd native tools), systemd-tpmd exposes a Varlink interface utilizing JSON over AF_UNIX sockets. The methods exposed under the io.systemd.Tpm interface include: * GenerateKey: Generates a new asymmetric key pair or symmetric secret bound to the TPM. Outputs the encrypted marshaled structures for local application storage. * SignData: Loads the provided key blobs into the TPM using the SRK and signs the provided digest. * VerifySignature: Verifies a cryptographic signature against a given digest utilizing the public blob. * SealSecret: Seals a plaintext secret into the TPM, optionally binding it to the current state of specific PCRs. * UnsealSecret: Unseals a previously sealed secret from the TPM, returning the plaintext only if the PCR states match. Because the API relies on Varlink, native developers can utilize libsystemd's sd-varlink.h to request cryptographic operations synchronously: #include <stdio.h> #include <systemd/sd-varlink.h> #include <systemd/sd-json.h> int tpm_sign_payload(const char *priv_blob, const char *pub_blob, const char *digest) { sd_varlink *link = NULL; sd_json_variant *args = NULL; sd_json_variant *reply = NULL; /* 1. Connect to the systemd-tpmd Varlink socket */ sd_varlink_connect_url(&link, "unix:/run/systemd/tpmd/io.systemd.Tpm"); /* 2. Build JSON arguments */ sd_json_buildo(&args, SD_JSON_BUILD_PAIR("privateBlob", SD_JSON_BUILD_STRING(priv_blob)), SD_JSON_BUILD_PAIR("publicBlob", SD_JSON_BUILD_STRING(pub_blob)), SD_JSON_BUILD_PAIR("digest", SD_JSON_BUILD_STRING(digest)) ); /* 3. Execute the Varlink call synchronously */ sd_varlink_call(link, "io.systemd.Tpm.SignData", args, &reply, NULL); /* Cleanup */ return 0; } 4. System Administration and Managed Environments ======================== 4.1 State Management and Daemon Recovery ------------------------ Because systemd-tpmd acts as a stateful userspace layer managing active ESAPI encrypted HMAC sessions and escrowed passwords, a daemon crash must not disrupt continuous remote attestation workflows or trigger hardware lockouts. To defend against state loss, systemd-tpmd utilizes the Linux Kernel Key Retention Service. Upon successful provisioning, the highly sensitive Owner, Endorsement, and Lockout passwords are securely injected into the kernel keyring and isolated via KeyringMode=private within the systemd service unit. If the daemon restarts, it queries the kernel keyring to seamlessly to re-establish its authentication contexts and session states without requiring user intervention or causing DA lockouts. 4.2 Command Line Integration and Access Control ------------------------ Administration integrates directly into systemctl via a new top-level tpm verb: * systemctl tpm status: Reports hardware capabilities and the presence of the SRK. * systemctl tpm clear: Securely wipes the TPM and rotates the locally escrowed hierarchy passwords. * systemctl tpm reset-lockout: Submits the escrowed Owner password to clear the DA lockout counter. State-altering operations are strictly governed by polkit (PolicyKit). systemd-tpmd will query polkit to ensure that only authenticated administrators or enterprise management agents can mutate the physical hardware's ownership state. Unprivileged users are physically prevented from clearing the TPM or triggering anti-hammering lockouts. 5. Security, Sandboxing, and Simulation ======================== 5.1 Hardened Service Confinement ------------------------ systemd-tpmd leverages systemd's native sandboxing directives to enforce the principle of least privilege. The unit file (systemd-tpmd.service) incorporates: * DynamicUser=yes: Generates a dynamic, unprivileged user for the execution context. * CapabilityBoundingSet=: Drops all Linux capabilities except those strictly required for hardware communication. * DeviceAllow=/dev/tpmrm0 rw: Strictly limits hardware access to the kernel resource manager. * NoNewPrivileges=yes: Prevents privilege escalation via execve. 5.2 Simulator Support and Fallback Prevention ------------------------ To support robust CI/CD and developer testing without wearing out physical NVRAM, systemd-tpmd natively supports software emulators like swtpm. Through a systemd drop-in configuration (e.g., using systemctl edit systemd-tpmd), a developer can dynamically route the daemon's transport layer away from /dev/tpmrm0 to a local software simulator. However, falling back to a software emulator in a production environment breaks the hardware root of trust. Enforcement of this strict boundary relies on system administrators utilizing systemd's native unit file configurations and the underlying Linux kernel security modules (cgroups, namespaces, and Mandatory Access Controls like AppArmor or SELinux). Administrators enforce these protections by defining sandbox directives within the /etc/systemd/system/systemd-tpmd.service file: * Device Whitelisting (cgroups): The unit enforces DeviceAllow=/dev/tpmrm0 rw. When systemd loads the service, it configures the kernel's cgroup device controller to explicitly block access to any other device. This guarantees the daemon is blocked from interacting with virtual character devices like /dev/vtpmx used by CUSE-based emulators. * Network Sandboxing (namespaces): By applying RestrictAddressFamilies=AF_UNIX (which permits local Varlink sockets but entirely disables TCP/IP networking namespaces), systemd instructs the kernel to physically block the daemon from opening outbound network connections to a remote or local swtpm TCP port. Because these rules are enforced by systemd (acting as PID 1) and the Linux kernel itself, even a compromised systemd-tpmd process cannot bypass them. These policies guarantee the daemon will fatally error out rather than silently falling back to a compromised simulator in live deployments. 6. Future Capabilities and Solvable Problems ======================== By establishing systemd-tpmd as a persistent, centralized root of trust in userspace, several long-standing ecosystem challenges beyond basic cryptography can be elegantly resolved. 6.1 Seamless Firmware Updates (Solving the LUKS / fwupd Lockout) ------------------------ Currently, binding LUKS disk encryption to Platform Configuration Registers creates severe system fragility. When an administrator updates the system firmware using fwupd, the PCR 7 measurement changes, which permanently breaks the LUKS unlocking policy and locks the user out. systemd-tpmd will resolve this by leveraging TPM2_PolicyAuthorize. Instead of binding disk encryption to static PCR values, the disk is bound to a cryptographic ticket signed by systemd-tpmd. When fwupd schedules an update, it can communicate its intent via Varlink. systemd-tpmd can automatically generate a new authorized policy for the incoming firmware state, ensuring the disk unseals smoothly after the reboot. 6.2 Standardizing TPM-Backed Passkeys for the Linux Desktop ------------------------ The Linux desktop currently lacks a unified, hardware-backed API for modern WebAuthn/FIDO2 passkeys. systemd-tpmd could serve as the foundational backend for projects like credentialsd. By deriving keys from the TPM's primary seed and encrypting the credential blobs, systemd-tpmd would allow browsers to store highly secure, phishing-resistant passkeys that never leave the hardware in plaintext. 6.3 Stabilizing Continuous Remote Attestation for Fleet Management ------------------------ In enterprise deployments, continuous remote attestation agents (such as Keylime) are used to cryptographically prove to a central server that a machine's Linux Integrity Measurement Architecture (IMA) log has not been compromised. However, these agents frequently suffer from false alerts and access conflicts when querying the TPM simultaneously with other system updates. By acting as the sole orchestrator, systemd-tpmd could safely broker attestation quotes and IMA measurements, ensuring that fleet management tools operate reliably without resource contention on the /dev/tpmrm0 node. 6.4 Secure SSH Key Protection ------------------------ SSH private keys stored in local files are highly vulnerable to theft by malware. While the TPM can mitigate this by generating and securing the keys in hardware, configuring this currently requires end-users to manage complex PKCS#11 libraries (like tpm2-pkcs11) and manipulate paths. With systemd-tpmd, SSH agents could be rewritten to simply pass signing payloads via Varlink, natively protecting SSH access across the entire Linux ecosystem with zero configuration required from the user. Alternatively, they can leverage the OpenSSL 3.0 provider natively. 6.5 Confidential Computing and vTPM State Management ------------------------ In cloud environments leveraging AMD SEV-SNP or Intel TDX for Confidential Computing, virtual TPMs (vTPMs) are injected into the guest to provide measured boot guarantees. systemd-tpmd can easily standardize the management of these virtual TPMs from inside the guest OS. Because the daemon abstracts the underlying hardware, it can interface with a cloud provider's vTPM exactly as it would a physical chip, automatically provisioning it and simplifying the deployment of Confidential Virtual Machines (CVMs) without requiring cloud-specific user space tooling. Thanks for your time and efforts reading into thie proposal. Any thoughts, critiques, or architectural feedback are highly appreciated. Best Regards, Akshay Hendre
