Skip to main content

Secure Boot

LapEE boots a signed Unified Kernel Image at EFI/Boot/BootX64.efi. Secure Boot is optional for first evaluation, but production operators should either trust the release signing key or admit the exact release UKI hash through firmware policy.

Adding wifi.conf or config.json to the ESP changes the disk image hash. It does not change the UKI signature or the UKI hash.

Choose A Trust Path​

Use one of these paths:

  • Enroll the release signing key or hash published with the image.
  • Generate operator-owned Secure Boot keys and sign local builds.
  • Disable Secure Boot for early testing, then verify that the attestation report reflects that weaker posture.

Some firmware clears factory keys when entering Setup Mode. Treat key enrollment as a firmware-owner action, not a docs shortcut.

Operator-Owned Keys​

From the lapee source tree:

make signing-keys

This writes PK, KEK, and db material under secureboot/. Private keys are local operator material and stay out of git.

For a local source build:

make runtime-image

The signed runtime image is written to:

build/images/lapee-runtime-tme-signed.img

The TME=0 build has a different UKI and must be admitted separately:

make runtime-image TME=0

One-Shot Provisioner​

The Secure Boot provisioner image is a separate boot mode. It mounts EFI variables read-write, looks for the LapEE enrollment bundle on the USB stick, requires the operator to type I UNDERSTAND., then enrolls db, KEK, and PK.

make provisioner-write DEV=/dev/diskN

After provisioning, write the runtime image:

make runtime-write DEV=/dev/diskN

PK is enrolled last because that exits Setup Mode.

What Verifiers See​

Secure Boot state is measured into the firmware event log and interpreted by ~tpm-interpret@1.0. The verifier dashboard reports the Secure Boot policy, trusted signers, db/dbx state when available, kernel lockdown, and the measured kernel command line.

Secure Boot off is not hidden. It becomes part of the evidence.