# Keylime: remote attestation for machines you do not control

> Keylime is a CNCF project that turns a TPM into a way to check whether a remote machine is still the machine it was, and it does the checking with three components, a verifier, a registrar and an agent, where the agent itself has been rewritten in Rust.

**keylime/keylime** — A CNCF Project to Bootstrap & Maintain Trust on the Edge / Cloud and IoT

- Repository: https://github.com/keylime/keylime
- Website: https://keylime.dev
- Stars: 571 · Forks: 199
- Language: Python
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/keylime-keylime

## What problem Keylime is actually solving

Keylime is an open-source scalable trust system harnessing TPM technology, providing an end-to-end solution for bootstrapping hardware rooted cryptographic trust for remote machines, the provisioning of encrypted payloads, and run-time system integrity monitoring. It also provides a flexible framework for the remote attestation of any given PCR, a Platform Configuration Register, and users can create their own customised actions that trigger when a machine fails its attested measurements. The stated mission is to make TPM technology easily accessible to developers and users alike without needing a deep understanding of the lower levels of a TPM's operations. The scenario it is aimed at is specific. It is well suited to tenants who need to remotely attest machines that are not under their own full control, such as a consumer of hybrid cloud or a remote edge or IoT device in an insecure, physically tamper-prone location.

## Three components, and the job of each

Keylime consists of three main components, and it can be driven with a CLI application and a set of RESTful APIs. The Verifier continuously verifies the integrity state of the machine the agent is running on. The Registrar is a database of all agents registered with Keylime, and it hosts the public keys of the TPM vendors. The Agent is deployed to the remote machine that is to be measured or provisioned with secrets stored within an encrypted payload, which is released once trust is established. The split is the security model. The machine being checked holds no authority itself, the verifier holds the decision, and the registrar is the directory of who is allowed to talk to whom, including the vendor public keys needed to check a quote.

## The agent is Rust now, and the Python one is on its way out

The verifier, registrar and agent were all developed in Python and live in the keylime repository, and the agent was then ported to Rust, with the code in the separate rust-keylime repository. The stated reason is that Rust is a low-level performant systems language designed with security as a central tenet, and the port was done by means of the Rust compiler's ownership model. Since the 0.1.0 release of the Rust based agent, that agent has been the official one, and the project marks the Python version as deprecated and to be removed with the next major version, 7.0.0. So there is a clear direction here. A new deployment should be running the Rust agent, and a deployment still on the Python agent is on a path that ends at the next major release.

## Configuration, and the services that have to run

Keylime puts its configuration in /etc/keylime/ or /usr/etc/keylime/, and it also takes an alternate location for the config in the environment variables keylime_VERIFIER_CONFIG, keylime_REGISTRAR_CONFIG, keylime_TENANT_CONFIG, keylime_CA_CONFIG and keylime_LOGGING_CONFIG. Those files are documented with comments and are meant to be self-explanatory in most cases. Three services then run. The registrar is a simple HTTPS service that accepts TPM public keys and presents an interface to obtain those public keys for checking quotes. The verifier is the most important component, doing initial and periodic checks of system integrity and securely bootstrapping a cryptographic key with the agent, and it uses mutual TLS for its control interface. The agent is the target of the bootstrapping and the measurements, and it keeps its state under /var/lib/keylime/.

## The TLS detail that decides whether your install works

There is a paragraph in the documentation about certificates that is easy to skim past and expensive to get wrong. By default the verifier creates appropriate TLS certificates for itself in /var/lib/keylime/cv_ca/, and the registrar and tenant use this as well. If you use the generated TLS certificates, then all the processes need to run as root to allow reading of the private key files in /var/lib/keylime/. That is a real constraint on how you package the services, because a deployment that wants the verifier to run unprivileged has to supply its own certificates and give the processes another way to read the key material. The documentation also carries a separate note about the hardware requirement, that a hardware TPM should always be used when real secrets and trust is required.

## Provisioning a machine with keylime_tenant

To kick everything off you tell Keylime to provision a machine, and the tenant utility is what does it. The example command provisions a new agent at 127.0.0.1 with a given UUID and talks to a verifier at 127.0.0.1, encrypting a file called filetosend and sending it to the agent, allowing it to decrypt the file only if the configured TPM policy is satisfied.

`keylime_tenant -c add -t 127.0.0.1 -v 127.0.0.1 -u D432fbb3-d2f1-4a97-9ef7-75bd81c00000 -f filetosend`

Stopping Keylime from requesting attestations is the same utility with the delete action.

`keylime_tenant -c delete -t 127.0.0.1 -u d432fbb3-d2f1-4a97-9ef7-75bd81c00000`

And the tenant has further options behind its own help flag.

`keylime_tenant -h`

The documentation on creating runtime and measured boot policies is in the Keylime User Guide, and that is where the interesting part is, because a policy is what defines which measurements are acceptable and therefore when a secret is released.

## The software TPM, and why it is fine for development

Keylime supports TPM version 2.0, and it can be used with a hardware TPM or with a software TPM emulator for development, testing or demonstration purposes. The warning is emphatic and worth repeating exactly in substance. Do not use Keylime in production with a TPM emulator, because a software TPM emulator does not provide a hardware root of trust and dramatically lowers the security benefits of using Keylime. A hardware TPM should always be used when real secrets and trust is required. That is the whole point of the project, so an emulator installation is a way to try the system out, and the project ships a demo directory with an agent monitor, an autorun script, a setup script, IMA policies, a keyfile, an encrypted payload and a payload directory to make that possible.

## Services, dependencies and the project around the code

The services/ directory includes systemd service files for the verifier, agent and registrar, and they are installed with a script, after which the keylime_verifier and keylime_registrar services can be run and inspected with systemctl, and the Rust agent repository also carries a systemd service file for the agent. The Python dependencies are a working list of what Keylime pulls in, and the file itself carries a policy note. Changes to the requirements file first require that an enhancement be raised to ensure the new packages are maintained and available in the major distributions, currently Fedora and Debian, and once the enhancement is merged the package has to be added to the installer, the CI Docker images, and the RPM, DEB and ansible installer issues.

```
cryptography>=3.3.2 # BSD/Apache-2.0
tornado>=5.0.2 # Apache-2.0
pyzmq>=14.4 # LGPL+BSD
pyyaml>=3.11 # MIT
sqlalchemy>=2.0.39 # MIT; 2.0.39+ required for Python 3.13 support
alembic>=1.1.0 # MIT
```

Beyond that, the project is organised like a CNCF project should be, with a GOVERNANCE.md, a CODE_OF_CONDUCT.md, a MAINTAINERS.md, a ROADMAP.md, a RELEASE.md, a TESTING.md, a CODEOWNERS file, a pre-commit configuration and a packit configuration for distribution builds. Feature requests are tracked as enhancements in a separate enhancements repository, so that the impact of a significant change can be reviewed before it is written, and security vulnerabilities are reported by contacting the team directly.

## Conclusion

Keylime fits a platform team that hands out machines to tenants it does not fully control, whether a hybrid cloud customer or a device in a tamper-prone location, because the verifier can check a machine's PCR values remotely and release a secret only when the policy is satisfied. It does not fit a production deployment that runs on a software TPM emulator, since the project states plainly that an emulator provides no hardware root of trust and dramatically lowers the security benefit, and it does not fit a team still on the Python agent, because the Python version is deprecated and will be removed with the next major version, 7.0.0. Before you deploy, decide whether the machines have a real TPM 2.0, read the runtime and measured boot policy documentation before you provision, and plan for the mutual TLS control interface, since the verifier creates its own certificates under /var/lib/keylime/cv_ca/ and the processes need the rights to read the private key files.

## FAQ

### What is Keylime and what does it do?

It is an open-source scalable trust system harnessing TPM technology, providing an end-to-end solution for bootstrapping hardware rooted cryptographic trust for remote machines, provisioning encrypted payloads and run-time system integrity monitoring, with a framework for the remote attestation of any PCR and custom actions when measurements fail.

### What are the three components of Keylime?

The Verifier continuously verifies the integrity state of the machine the agent runs on, the Registrar is a database of registered agents and hosts the TPM vendor public keys, and the Agent is deployed to the remote machine being measured or provisioned with secrets in an encrypted payload released once trust is established.

### Can I use Keylime with a software TPM emulator?

Only for development, testing or demonstration. The project states that do not use Keylime in production with a TPM emulator, because a software emulator provides no hardware root of trust and dramatically lowers the security benefits, and that a hardware TPM should always be used when real secrets and trust are required.

### How do I provision a machine with keylime_tenant?

Use keylime_tenant with the add action, giving the target address with -t, the verifier address with -v, the agent UUID with -u and the file to encrypt with -f. The agent can decrypt the payload only if the configured TPM policy is satisfied, and the same utility with the delete action stops attestation requests.

## Sources

- [keylime/keylime on GitHub](https://github.com/keylime/keylime)
- [License: Apache-2.0](https://github.com/keylime/keylime/blob/master/LICENSE)
- [Project website](https://keylime.dev)
- [README](https://github.com/keylime/keylime/blob/master/README.md)
- [Releases](https://github.com/keylime/keylime/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/keylime-keylime