Fwd: [RFC] Proposal for Centralized TPM 2.0 Userspace Management Layer: systemd-tpmd

Fwd: [RFC] Proposal for Centralized TPM 2.0 Userspace Management Layer: systemd-tpmd

[Akshay Hendre]

I am cross-posting proposal for [RFC: systemd-tpmd] for the right audience.

---------- Forwarded message ---------
From: Akshay Hendre <ahendre2010@gmail.com>
Date: Sun, 10 May 2026 at 13:31
Subject: [RFC] Proposal for Centralized TPM 2.0 Userspace Management
Layer: systemd-tpmd
To: <systemd-devel@lists.freedesktop.org>


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

RE: [RFC] Proposal for Centralized TPM 2.0 Userspace Management Layer: systemd-tpmd

[Andreas.Fuchs]

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 <ahendre2010@gmail.com> 
Sent: Sonntag, 10. Mai 2026 10:11
To: tpm2@lists.linux.dev
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 <ahendre2010@gmail.com>
Date: Sun, 10 May 2026 at 13:31
Subject: [RFC] Proposal for Centralized TPM 2.0 Userspace Management
Layer: systemd-tpmd
To: <systemd-devel@lists.freedesktop.org>


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

Re: [RFC] Proposal for Centralized TPM 2.0 Userspace Management Layer: systemd-tpmd

[Akshay Hendre]

Hi Andreas,

Thanks for the welcome and the highly constructive feedback. I took
some time over the past couple of weeks to dig into the specific
modules you mentioned, and I definitely came away knowing a lot more
about the current capabilities of the stack. I'm very glad we share
the same ultimate goal of making the TPM a seamless part of the Linux
ecosystem.

My primary motivation was absolutely not to fragment the ecosystem.
Instead, systemd-tpmd was born out of some steep learning curves and
architectural friction I encountered while trying to build concurrent,
TPM-backed applications that works on Windows and Linux systems. I am
highly open to pivoting these ideas into the existing tpm2-tss stack
where it makes sense.

To address your points directly:

1. FAPI, ESAPI, and the Keystore
The main friction point I hit was wanting to manage TPM blobs within
my own application's custom file format/database to that natively
handles concurrent access.

    FAPI abstracted the cryptography, but it forced the use of its own
file-based keystore, which was causing the 0x0006000b permission and
concurrency errors I mentioned. FAPI didn't expose an easy way for me
to just pass it my own raw blobs, I now understand the blockers.

    Moving down to ESAPI allowed me to handle the blobs, but the
learning curve spiked. Suddenly I had to manually manage the SRK, deal
with protected Owner hierarchies, and establish HMAC sessions. (I was
actually unaware of the standardized persistent handle approach for
the SRK until diving deeper recently).

Regarding your point on the FAPI keystore abstraction, I am definitely
interested in exploring alternative implementations here.

2. OpenSSL Provider
I was actually unaware of the full capabilities of tpm2-openssl.
Having looked into it based on your recommendation, it essentially
solves the application-layer integration exactly as I envisioned.
Rather than reinventing the wheel with a new provider.

3. Boot-Time Provisioning & Passwords
My concept here was heavily inspired by the Windows CNG paradigm,
aiming for "zero-touch" infrastructure while avoiding hardcoded
secrets. My thought was to auto-generate high-entropy passwords during
boot and escrow them securely within the Linux Kernel Key Retention
Service (keyctl), completely removing the user from the
password-setting loop while protecting against DA lockouts.

Has the tpm2-tss team evaluated using the kernel keyring for
state/password escrow? I would be very curious to know if there were
blockers that ruled this out.

4. Attestation and Event Logs
I would be very interested in dedicating my time to helping build out
the backend service and network protocols required to assess Event
logs and handle Quotes reliably.

What is the best way to kick off discussions on the attestation
service requirements?

Best Regards,
Akshay Hendre

On Mon, 11 May 2026 at 19:17, <Andreas.Fuchs@infineon.com> wrote:
>
> 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 <ahendre2010@gmail.com>
> Sent: Sonntag, 10. Mai 2026 10:11
> To: tpm2@lists.linux.dev
> 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 <ahendre2010@gmail.com>
> Date: Sun, 10 May 2026 at 13:31
> Subject: [RFC] Proposal for Centralized TPM 2.0 Userspace Management
> Layer: systemd-tpmd
> To: <systemd-devel@lists.freedesktop.org>
>
>
> 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
>