To establish a trusted cryptographic foundation for remote attestation in RHEL, you rely on the Keylime architecture. Its core components, the verifier, registrar, tenant, and agent, interact with Trusted Platform Module (TPM) technology to dynamically build and maintain a continuous chain of trust.

A TPM acts as the root of this trust. It is a hardware, firmware, or virtual component with integrated cryptographic keys.

To achieve your system security goals, you can configure agents to perform the following monitoring actions:

Verify system state at boot

Keylime measured boot verifies the system state when the system boots.

Continuously monitor runtime integrity

Keylime runtime integrity monitoring continuously monitors the system where the agent is deployed and measures the integrity of the files included in the allowlist and not included in the excludelist.

To perform these actions, the system relies on three main components:

Verifier

Initially and continuously verifies the integrity of the systems that run the agent. You can deploy the verifier from a package, as a container, or by using the keylime_server RHEL system role.

Registrar

Serves as a secure database that stores the unique TPM identity data for all registered agents, including their Endorsement Key (EK), Attestation Key (AK), and related identification certificates. You can deploy the registrar from a package, as a container, or by using the keylime_server RHEL system role.

Agent

Deployed to the remote systems that are measured by the verifier.

In addition, you can use the keylime_tenant utility for many functions, including provisioning the agents on your target systems.

To establish a trusted remote monitoring strategy for your infrastructure, you use either the pull or push attestation model. You achieve the same goal of system integrity validation with either option, although they operate by using different network mechanics and scaling behaviors.

The pull model

Traditional Keylime attestation uses the pull model, where the verifier service initiates the attestation process by periodically polling remote systems. The verifier establishes an inbound network connection to the Keylime agent to retrieve Trusted Platform Module (TPM) quotes, Integrity Measurement Architecture (IMA) logs, and the UEFI event log. The pull model uses mutual TLS (mTLS) authentication to ensure secure communication between Keylime components. The verifier holds the connection open while retrieving and evaluating the measurements. It validates the TPM quote by checking its cryptographic signature against the agent’s registered attestation key, which confirms that the reported PCR values are authentic and untampered. It then replays each event log to reconstruct expected PCR values and compares them against the values reported in the quote. During UEFI event log evaluation, the verifier validates the boot sequence by checking each boot component measurement against a reference state. When evaluating the IMA log, it detects unauthorized or modified software by comparing recorded file measurements against the runtime policy. If any reconstructed PCR value does not match the quote, or if any measurement fails a policy check, the attestation fails.

The pull model provides almost instant detection of network or Keylime agent failures, but it requires each monitored node to be reachable and have the necessary inbound ports open. By using this model, you can also deploy secure payloads to send encrypted information or configuration files to agents as soon as they are verified.

Keylime ensures the integrity of the monitored systems in a chain of trust by using keys and certificates exchanged between the components and the tenant. For a secure foundation of this chain, use a certificate authority (CA) that you can trust.

Note

If the agent receives no key and certificate, it generates a key and a self-signed certificate with no involvement from the CA.

The push model

In push model attestation, the Keylime verifier operates as a passive validator. The Keylime agent service initiates the attestation process by sending measurements to the verifier at a defined interval. The agent establishes an outbound connection to the verifier to provide the necessary TPM quotes, IMA logs, and the UEFI event log. The push model uses a TPM challenge-and-response process, Proof of Possession (PoP), to verify agent authenticity. Unlike in the pull model, the verifier acknowledges receipt of the data immediately and processes attestation results independently. It validates the TPM quote by checking its cryptographic signature against the agent’s registered attestation key, which confirms that the reported PCR values are authentic and untampered. It then replays each event log to reconstruct expected PCR values and compares them against the values reported in the quote. During UEFI event log evaluation, the verifier validates the boot sequence by checking each boot component measurement against a reference state. When evaluating the IMA log, it detects unauthorized or modified software by comparing recorded file measurements against the runtime policy. If any reconstructed PCR value does not match the quote, or if any measurement fails a policy check, the attestation fails.

The verifier never connects to the agent, which makes the push model suitable specifically for edge computing and NAT-protected environments where the verifier service cannot directly reach the remote systems. Although the push model increases security by removing inbound ports, it does not support the delivery of secure payloads.

The technical specifications for each model detail their operational differences.

To determine the best fit for your architecture, from stable data centers to edge deployments, you can assess how specific network use cases and environmental factors align with each Keylime attestation model. This choice directly affects how you configure the verifier and agents.

The pull model is best suited for environments where the network is managed, stable, and transparent.

• Corporate data centers: Best for servers on a flat, internal network where the verifier has direct access to every node.
• Isolated air-gapped networks: Ideal for high-security environments where the verifier strictly controls all communication.
• Secret and script delivery (secure payloads): Required if the verifier must deliver sensitive configuration files, keys, or scripts to the agent immediately after a successful attestation.
• Centralized monitoring architecture: Preferred when integrating with existing infrastructure management tools that rely on a central server to poll or ping clients for status updates.
• Real-time failure forensics: Used when the verifier must immediately detect a network drop or an agent service failure, which is critical for high-availability systems.

The push model is designed for distributed, restricted, or dynamic network architectures.

• Edge and Internet of Things (IoT) deployments: Ideal for devices in remote branches or field locations that must connect to the verifier through external gateways.
• Cloud instances behind NAT: Used for virtual machines in public clouds that have outbound internet access but lack a public IP address for inbound connections.
• Zero trust device onboarding: Best for environments where devices must prove their integrity to a central service before receiving access to network resources.
• Hardened stealth nodes: Used when security policies forbid any listening services or open inbound ports on the monitored system to minimize the attack surface.
• Massively scalable fleets: Preferred for environments with tens of thousands of agents, because it offloads the scheduling and timing tasks from the verifier to the individual nodes.
• Dynamic network environments: Ideal for mobile devices or systems with frequently changing IP addresses, because the agent initiates the connection regardless of its current network location.

The following factors determine whether to use the pull or push attestation model: