OpenFactory · Cryptographic Attestation

Runtime Attestation on OpenFactory

Dual-source kernel + systemd verification that proves your Linux fleet is enforcing the security policy your auditors signed off on — not just claiming to.

Heads up. OpenFactory at openfactory.tech is the AI-driven custom-Linux build and fleet platform. There is a separate industrial-IoT project also called OpenFactory; it is unrelated. This page covers runtime attestation in our platform.

What runtime attestation means on OpenFactory

Traditional runtime monitoring trusts a single source of truth — usually systemd or a monitoring agent. If systemd reports a service is running with MemoryMax=4G, the monitoring system records "memory limited to 4 GB" and moves on. But systemd is a userspace orchestrator. It configures the kernel; it does not verify that the kernel actually enforced the configuration. A kernel bug, a race condition, or a deliberate rootkit can cause the kernel's actual state to diverge from what systemd believes it set.

That divergence is invisible to single-source monitoring. If an attacker rewrites cgroup limits directly through /sys/fs/cgroup, systemd still reports the original values. If a kernel module disables SELinux enforcement after systemd set it to enforcing, systemctl still shows enforcing. The orchestrator marks its own homework.

Runtime attestation on OpenFactory closes that gap. An agent running inside each deployed VM independently queries both the orchestrator (systemd) and the kernel (procfs / sysfs / cgroupfs) for the same state, then signs a cross-referenced report. Configuration evidence and enforcement evidence — both captured, both paired, both signed.

The dual-source verification model

OpenFactory layers attestation in fourteen verification levels (V1–V14). The early layers cover what you booted; the later layers cover what is actually running right now.

  • V1–V3 — signed-build verification (live today). Every OpenFactory ISO ships with a signed manifest. Each file's hash is recorded at build time and chained to the build's attestation document. dm-verity enforces the chain at runtime so a modified base image fails to mount.
  • V4–V14 — live-runtime kernel + systemd cross-check (rolling out). Periodic paired-observation reports for resource limits, security policies, namespaces, capabilities, SELinux / AppArmor enforcement, and listening sockets. Every report is signed with a key sealed to the same TPM PCR set the boot chain uses.

The agent collects paired observations across six domains: resource limits (systemd MemoryMax / CPUQuota vs. kernel memory.max / cpu.max), security policies (ProtectSystem, NoNewPrivileges vs. kernel mount flags and prctl), network state (systemd socket activation vs. ss / netstat), file permissions, SELinux / AppArmor context, and capabilities.

Why it matters for GxP, financial, and defense fleets

Regulations like 21 CFR Part 11 (FDA, GxP) and DORA (EU digital operational resilience) require proof that security controls are enforced, not just configured. A systemd journal entry saying "MemoryMax set to 4G" is configuration evidence. A kernel cgroup file showing "memory.max = 4294967296" is enforcement evidence. Most auditors want both, and they want them signed and paired.

For defense and financial-trading deployments the exposure is even sharper: a single-source monitoring chain can be silently subverted by a rootkit that lies to the orchestrator. Dual-source runtime attestation makes the silence into noise — any divergence is captured, signed, and surfaced.

How it works, end to end

  1. Build time. OpenFactory generates the ISO and signs a manifest with a build_id and per-file hashes. The manifest goes into the image's measured-boot chain.
  2. Boot. dm-verity verifies the base image against the manifest. The TPM extends PCRs as each layer loads. Boot-time attestation is now anchored to a TPM quote.
  3. Runtime. A 5-minute systemd timer triggers the dual-attestation agent. It queries systemd for the expected state, queries the kernel for the actual state, and writes a paired JSON report.
  4. Signing. The report is signed with a key sealed to the same PCR set the boot chain extended. A tampered runtime cannot produce a valid report.
  5. Surface. OpenFactory's CTO GUI shows the report on the VM details panel: orchestrator view on the left, kernel view on the right, discrepancies in red with an explanation of the security implication.

Enabling it on your fleet

Runtime attestation is opt-in per recipe. Add dual-attestation to the feature list:

{
  "name": "gxp-medtech-station",
  "base_image": "ubuntu-24.04",
  "features": [
    "dm-verity-verification",
    "dual-attestation",
    "gxp-ssh-hardening"
  ]
}

The hook installs the attestation agent at /opt/openfactory/attestation-agent/ and configures the systemd timer. Reports land in /var/lib/openfactory/attestation/reports/ and stream to the CTO GUI in near real time.

Frequently asked questions

What is runtime attestation on OpenFactory?

Runtime attestation on OpenFactory is a dual-source verification system that independently queries the kernel and systemd for the same security-relevant state on a deployed Linux VM, then cross-checks that what systemd says it configured matches what the kernel actually enforces. Discrepancies are signed and surfaced as attestation findings.

How is runtime attestation different from boot-time or measured boot?

Boot-time attestation (measured boot, dm-verity) proves the image you booted is the image you signed. Runtime attestation proves the running system is still configured and enforced the way you intended — minutes or hours after boot, after services start, after operators log in. The two complement each other: boot-time covers the image, runtime covers the live state.

Does OpenFactory support TPM-backed runtime attestation?

Yes. The signed-build verification layer (V1–V3) chains to TPM PCRs through measured boot. The dual-source runtime layer (V4–V14) signs its periodic reports with a key sealed to the same PCR set, so a tampered runtime cannot produce a valid report.

Which compliance regimes does runtime attestation address?

21 CFR Part 11 (FDA, GxP), DORA (EU financial resilience), and most defense-deployment standards require proof that security controls are actually enforced, not just configured. Single-source monitoring records configuration; runtime attestation records both configuration and enforcement, paired and signed.

How often does the attestation agent report?

By default, every 5 minutes via a systemd timer. The interval is configurable per recipe. Each report is a JSON document covering resource limits, security policies, network state, file permissions, SELinux/AppArmor enforcement, and capabilities — paired observations from systemd and the kernel.

Is runtime attestation enabled by default?

No. It is opt-in per recipe. Most deployments do not need the audit overhead. Add the dual-attestation feature to your recipe to install the agent and configure periodic reporting; it is intended for regulated environments where auditors demand dual-verification evidence.

Where can I see attestation results?

OpenFactory's CTO GUI surfaces attestation results in a dedicated tab on the VM details panel: a dual-column comparison view with the orchestrator's view on the left, the kernel's view on the right. Matches are green; discrepancies are highlighted in red with an explanation of the security implication.

Is this the same OpenFactory as the industrial-IoT project?

No. OpenFactory at openfactory.tech is the AI-driven custom-Linux build and fleet platform. The industrial-IoT project at openfactory-doc.readthedocs.io is a separate, unrelated project that shares the name.

Related