Asterisk
Work

Ngome

A fail-closed secure desktop appliance: the default state is Locked.

What it is
A concept, on invented data
Platform
Desktop (Tauri / Linux)
Ngome's unlocked workspace: a signed message board on the left, and a rail on the right showing all five check lamps green, mesh health at 92/100, and the stable update channel.

The problem

A kiosk that handles sensitive work needs a device that stays closed unless every check passes — FIDO2 key, Secure Boot, LUKS2 disk encryption, file integrity, and a live I2P mesh — and locks itself the moment any one of them fails.

The idea

Ngome (Swahili for fortress) is a hardened Debian image running a Tauri v2 app. Five posture and network checks run in sequence; any failure, timeout or panic goes to Lockdown. The only path to the workspace is FIDO2 → posture → mesh, in order, every time.

What it does.

  • Runs a fail-closed state machine: starts Locked, advances only when every check passes in order
  • Verifies a USB FIDO2 security key natively in Rust over HID, with independent P-256 signature checking
  • Checks Secure Boot, LUKS2 disk encryption and a signed file-integrity manifest before allowing access
  • Reaches peers and the update channel only through I2P; nftables blocks all other egress
Ngome locked state: 'Press Unlock with key, then tap your key when it blinks' with an Unlock button and a custom key illustration showing 'Key detected'.
Ngome checking state: the five-lamp annunciator strip at the bottom shows Security key green, Secure Boot spinning, and Disk encryption, Integrity and Mesh waiting.
Ngome lockdown state: 'Secure Boot check failed', reason code SECURE_BOOT_DISABLED, 'What happened' and 'What to do' fields, with the Security key lamp green and Secure Boot lamp solid red.

What’s underneath.

The decisions that make it work, most of which no one sees.

  1. The state machine only advances in order

    Out-of-order passes are silently discarded. A result from a superseded attempt can't advance the state. The only path to Unlocked is FIDO2, then posture, then mesh — every time.

  2. FIDO2 is verified in Rust, not in the WebView

    WebKitGTK's WebAuthn is unreliable on Linux. The Rust backend reads the key over HID directly and verifies the P-256 signature independently, with no dependency on the browser stack. The WebView is treated as untrusted.

  3. The app only stages updates; root re-verifies before installing

    The unprivileged app stages a signed update package, and a root systemd path unit runs the same Minisign verifier again before calling dpkg. The app can't install anything, and the signature must name the exact file it covers.

What it shows

This concept is built from this service. Each is something we can do for you.

Tell us what you’re building.

A 30-minute call is the quickest way to see if we’re the right fit. Or send us a message, whichever suits you.