Skip to main content

Security Model

LapEE narrows a commodity laptop into one appliance node. The production path is boot, attest, serve HyperBEAM, and keep local runtime surfaces minimal.

Claims​

LapEE is designed to give verifiers evidence for:

  • The TPM that produced the quote.
  • The selected PCR values and quote digest.
  • The boot event-log context when firmware exposes it.
  • The AK policy bound to PCRs 0,1,7,10,11,14,15.
  • The runtime PCR 15 event that commits to the HyperBEAM node-message id.
  • The node key and public node policy that HyperBEAM reports.
  • Secure Boot, kernel lockdown, IOMMU, TME or SME, CPU, DMI, and TPM posture.

Production Posture​

Production init does the following:

  • Reads ESP inputs once.
  • Copies accepted operator config to tmpfs.
  • Uses WiFi credentials only to associate, never as attested secret material.
  • Starts the splash as the local status surface.
  • Brings up networking.
  • Unmounts and detaches the boot USB before HyperBEAM starts.
  • Deauthorizes USB devices and xHCI in production mode.
  • Starts HyperBEAM with stdio attached to /dev/null.

Production kernel/config intent disables local interactive and debug surfaces such as HID input, Bluetooth, sound, USB4/Thunderbolt, SysRq, debugfs, devmem, kexec, hibernation, and suspend.

Debug and Secure Boot provisioner modes are separate measured modes.

Assumptions​

Default production posture assumes:

  • UEFI measured boot.
  • TPM 2.0 with quote support.
  • EK certificate chain that can anchor to the measured root bundle or be interpreted with documented trust material.
  • A network path from verifier to node.
  • Intel TME or AMD SME on physical hardware, unless using a release that explicitly disables that gate.

QEMU is treated as a test environment and skips the physical memory-encryption gate.

Non-Claims​

LapEE does not claim:

  • Firmware is honest.
  • The Linux kernel or HyperBEAM has no bugs.
  • One LapEE OS instance is a multi-tenant isolation boundary.
  • Commodity hardware resists every physical attack.
  • The boot USB is a USB firewall.
  • A raw disk hash is stable after operator WiFi/config injection.

The boot USB is an input medium. Firmware and early kernel code still consume USB and ESP contents before init detaches the device.

Policy Consequences​

Use the verifier result as evidence, not as a slogan.

Examples:

  • Secure Boot off should be visible in the claim surface and handled by policy.
  • TME=0 should be visible in the measured command line and handled by policy.
  • Missing EK roots may be a trust-material problem, not a successful attestation.
  • PCR 15 replay failure is a core failure because it breaks the node identity binding.