Designing Trustworthy Layered Attestations

This paper proposes a framework for designing trustworthy layered attestations that overcome the limitations of shallow verification by structuring systems to isolate critical components and layer evidence across them, achieving reliable security against strong adversaries with negligible performance overhead using widely available hardware and software.

The Gist

Imagine you are a bank manager. You need to send a very sensitive, top-secret file to a remote branch. Before you send it, you need to be absolutely sure that the remote branch's computer hasn't been hacked, that it's running the right software, and that no one has slipped a "spy" program into it to steal your data.

This process of checking if a remote computer is trustworthy is called Attestation.

The paper you provided, "Designing Trustworthy Layered Attestations," is like a blueprint for building a foolproof security check system. The authors argue that most current security checks are too "shallow"—like checking if a car's engine is running but ignoring if the brakes have been cut. A clever hacker could trick a shallow check.

To fix this, the authors propose Layered Attestation. Think of it like a Russian nesting doll or a multi-layered cake. You don't just check the outside; you check the layers inside, one by one, ensuring each layer protects the one below it.

Here is the paper broken down into simple concepts, analogies, and the "rules" they discovered.

1. The Problem: The "Shallow" Check

Imagine a hacker breaks into a computer. They install a "rootkit" (a super-stealthy virus) that hides itself from antivirus software.

• The Old Way: The computer says, "I am clean!" because the antivirus didn't find anything. The bank manager sends the secret file. The hacker steals it.
• The Problem: The computer is lying (or rather, the software checking it is being tricked). You can't trust a computer to check itself if the computer is already compromised.

2. The Solution: The "Layered" Cake

The authors suggest building a system where trust is built from the bottom up, like a pyramid.

• Layer 1: The Hardware Foundation (The Concrete Slab)
  This is the physical chip inside the computer (like a TPM or a special secure processor). It's like the concrete foundation of a house. You can't easily change the concrete once it's poured. This chip has a special "signature key" that it keeps locked inside. It can only sign a document if the house above it is built exactly as planned.
• Layer 2: The Boot Process (The Blueprint)
  When the computer turns on, it loads software in a specific order. The hardware foundation checks: "Did the bootloader load the right software? Did that software load the right kernel?" If anyone tried to swap a file, the foundation refuses to sign the document.
• Layer 3: The Rules (The Security Guard)
  Once the computer is running, it uses a strict rulebook (like SELinux). This is like a security guard who says, "Only the 'Email Process' can touch the 'Email Folder.' The 'Web Browser' cannot touch it." Even if a hacker gets into the system, the rules stop them from moving around.
• Layer 4: The Runtime Check (The Live Inspection)
  This is the tricky part. The computer needs to check itself while it's running.
  • Short-lived tasks: If a process handles one email and then dies, it's hard for a hacker to corrupt it permanently. It's like a temporary worker who leaves before they can steal anything.
  • Long-lived tasks: The computer's core (the Kernel) runs forever. This is like a building manager who never leaves. If they get corrupted, it's a disaster. The authors use a special tool (LKIM) that constantly re-measures the manager's brain to make sure they haven't been brainwashed.

3. The 5 Golden Rules (Maxims)

The authors distilled their complex research into five simple rules (Maxims) for building these systems:

1. Limit the Scope: Don't try to check the whole universe. Only check the specific parts that matter. Analogy: If you are checking a bridge, you only need to inspect the steel beams, not the paint on the guardrails.
2. Short Lives are Safer: If a program handles untrusted data (like an email), make it short-lived. Start a new one for every job. Analogy: If you hire a stranger to carry a package, don't let them stay in your house. Let them drop it off and leave immediately.
3. No Secrets in Memory: Don't store your master keys in the computer's RAM (memory). If the computer gets hacked, the RAM is the first thing they steal. Analogy: Don't keep your house key under the doormat. Keep it in a safe that only opens if the house is built correctly.
4. Prove You Are You: The signature proving the computer is clean must come from a source that couldn't exist if the computer were hacked. Analogy: A security guard's badge must be issued by a headquarters that only issues badges to people who passed a background check.
5. Check the Foundation First: You must check the lower layers (hardware, boot) before you check the upper layers (apps). Analogy: You can't trust the furniture in a house if the foundation is cracked. Check the foundation first.

4. The Real-World Test: The "Cross-Domain" Box

The authors built a real system called a Cross-Domain Solution (CDS). Imagine a secure mailroom that sits between a "Top Secret" network and a "Public" network.

• It takes a message from the Secret side.
• It scrubs it (removes dangerous parts).
• It sends it to the Public side.
• The Goal: Ensure no secret data leaks out and no public data gets in.

They tested their layered system against a "Super Hacker" who could:

• Log in as the boss (Root).
• Change files.
• Reboot the computer.
• But: The hacker couldn't break the physical hardware or the boot process.

The Result: The system caught the hacker every time. Even if the hacker tried to hide, the "Layered" checks (Hardware -> Boot -> Rules -> Runtime) exposed the corruption.
The Cost: The security check slowed the system down by only 1.3%. That's like adding a tiny speed bump to a highway; you barely notice it, but it keeps everyone safe.

5. The Future: "Confidential Computing"

The paper also looks at the future. New technology (like AMD SEV-SNP) allows a computer to create a "secret room" (a Virtual Machine) that even the computer's own operating system can't peek into.

• The Analogy: Instead of checking the whole house, you put the sensitive data in a glass box inside the house. The glass box is locked by the hardware. Even if the house burns down, the glass box stays safe.
• The authors show that their 5 Rules still work perfectly with this new technology, making it even harder for hackers to trick the system.

Summary

This paper teaches us that to trust a remote computer, we can't just ask, "Are you good?" We have to build a system where:

1. The hardware is the unchangeable judge.
2. The software is built in layers, checking each other.
3. Secrets are kept safe from the software itself.
4. We check the foundation before the roof.

By following these rules, we can create systems that are so trustworthy that even a clever hacker cannot fool them, all without slowing down the computer much. It's about building a trustworthy chain of evidence rather than just hoping for the best.

Technical Summary

Here is a detailed technical summary of the paper "Designing Trustworthy Layered Attestations" by Will Thomas et al.

1. Problem Statement

Remote attestation is the process of providing evidence that a remote system is trustworthy enough to handle sensitive interactions. While existing attestation mechanisms are used in network access control and trusted execution environments (TEEs), they often suffer from critical flaws:

• Shallow Attestation: They often measure only a few components (e.g., userspace binaries) while ignoring deeper layers (e.g., the kernel or boot process), allowing adversaries to hide rootkits or manipulate kernel mechanisms to evade detection.
• Untimely Attestation: Many systems only measure state at boot time, failing to detect runtime attacks that occur after the system has been running for a while.
• Fragility: Attempts to be comprehensive often result in opaque, monolithic values that are difficult to update or appraise as system components change piecemeal.
• The Trust Gap: A relying party cannot trust runtime evidence if the infrastructure generating that evidence (the OS kernel, measurement tools) is itself compromised.

The core challenge is designing an attestation system that can reliably detect adversarial corruption across multiple system layers (hardware, kernel, userspace) against a sophisticated adversary, without introducing significant performance overhead.

2. Methodology

The authors propose a Layered Attestation approach, combining hardware roots of trust with software security mechanisms, guided by a top-down adversarial reasoning process.

A. The Adversary Model

The authors define a strong but realistic adversary model for a Linux system equipped with SELinux and the Integrity Measurement Architecture (IMA):

• Capabilities: The adversary can log in as root, modify files, inject processes, and corrupt the kernel. They can also boot the system into arbitrary states.
• Limitations: The adversary cannot modify the hardware or UEFI firmware (supply chain attacks are out of scope). Crucially, the adversary is not a "fast attestation-triggered adversary" (they cannot corrupt and repair the system faster than the attestation cycle) and is not "attestation-attuned" (they cannot specifically craft attacks to bypass the specific measurement tools like LKIM or IMA in the current architecture).

B. The Five Design Maxims

To construct a trustworthy system, the authors derived five guiding principles (maxims):

1. Constrain Interactions: Limit system interactions so that attested properties depend only on a small, predictable, and measurable set of components (enforced via SELinux).
2. Short-lived vs. Long-lived: Short-lived processes handling untrusted inputs do not need runtime remeasurement (they are replaced per task). Long-lived services (like the kernel) do require runtime remeasurement to check state invariants.
3. Independence from Transient Secrets: Attestation mechanisms must not rely on secrets (like signing keys) stored in memory that could be exposed by transient corruptions.
4. Origin Verification: Evidence must prove it originated from uncorrupted software running under a trustworthy boot (enforced via TPM policies).
5. Acyclic Dependencies: Measurement layers must be ordered such that lower layers (e.g., kernel) are measured before or independently of upper layers (e.g., apps) to prevent a corrupted lower layer from falsifying upper-layer measurements.

C. System Architecture (Case Study: Cross-Domain Solution)

The authors implemented a Cross-Domain Solution (CDS) to test these principles. The CDS filters messages between a restricted network and an open network.

• Hardware Root: Trusted Platform Module (TPM) for storage and reporting.
• Boot Chain: UEFI $\to$ Shim $\to$ GRUB $\to$ Kernel/Initramfs. Each stage extends TPM Platform Configuration Registers (PCRs) with hashes of the next stage.
• Kernel Security:
  • SELinux: Enforces strict isolation of the CDS pipeline processes and configuration files.
  • IMA: Ensures only authorized executables are launched.
  • LKIM (Linux Kernel Integrity Measurement): Periodically re-measures the running kernel's control flow and data structures to detect rootkits.
• Attestation Manager (AM): Orchestrates the collection of evidence from various Attestation Service Providers (ASPs) and requests signatures from the TPM.
• Key Management: The Attestation Signing Key (ASK) is stored in the TPM. The TPM only signs evidence if PCRs reflect a compliant boot state (including active SELinux/IMA policies).

3. Key Contributions

1. Adversary Model: A formalized, realistic adversary model for Linux systems with SELinux/IMA, derived from the design process itself.
2. Empirical & Formal Validation: A combination of empirical testing and formal analysis (using the Copland language and Rocq proof assistant) demonstrating that the proposed mechanisms successfully detect corruptions defined in the adversary model.
3. Five Reusable Maxims: A set of design principles that guide the construction of layered attestation systems, applicable beyond the specific CDS example.
4. System Variants: Demonstrated the applicability of the maxims in two different contexts:
   • Distributed Document Control: Applying the principles to a multi-node environment.
   • Confidential Computing (AMD SEV-SNP): Replacing the TPM with a TEE-based root of trust, showing how the maxims adapt to new hardware architectures (e.g., using privilege levels to break measurement cycles).
5. Recommendations for Improvement: Identified two architectural shortcomings in current Linux/TPM implementations and proposed specific kernel enhancements to fully satisfy the maxims (detailed below).

4. Results

• Performance Overhead: The implementation showed negligible performance impact. The CDS throughput decreased by only 1.3% when the Attestation Manager was active with a 15-second interval. The average time for a full attestation cycle was 5.48 seconds (92% of which was spent on LKIM kernel remeasurement).
• Security Efficacy:
  • Empirical Testing: The system successfully detected attacks including boot script modification, kernel module insertion, and user-space binary replacement. It rejected replayed evidence via nonces.
  • Formal Analysis: The analysis confirmed that under the defined adversary model, no sequence of corruption and repair could allow a compromised system to pass attestation undetected.
• Limitations Identified: The current implementation requires a "stopgap" strategy for key management (storing a wrapped key blob in the filesystem) because the Linux kernel lacks native support for TPM localities. This violates Maxim 3 (independence from transient secrets) if the kernel is temporarily compromised.

5. Significance and Recommendations

The paper provides a blueprint for building robust, layered attestation systems that bridge the gap between hardware roots of trust and complex software stacks. It moves beyond simple "hash checking" to a holistic view of system integrity.

The authors propose two critical recommendations to eliminate current architectural compromises:

1. Recommendation 1 (Virtualization for LKIM): Future versions of LKIM should run as a separate virtual machine on a hypervisor with read-only access to the target kernel. This would break the cyclic dependency where the kernel (which LKIM measures) provides the data LKIM needs, preventing a rootkit from lying to the measurer.
2. Recommendation 2 (TPM Localities in SELinux): The Linux kernel and SELinux should be extended to support TPM localities (specifically extended localities 32–255). This would allow the kernel to enforce that only specific, verified processes (like the tpm sign ASP) can request signatures from the TPM, eliminating the need to store key blobs in the filesystem and fully satisfying Maxim 3.

By adhering to these maxims and implementing the recommendations, future systems could achieve trustworthy attestation even against stronger, "attestation-attuned" adversaries.