Page cover

Why Zero-Trust Matters

Zero-trust isn't just a buzzword, it's a fundamental shift in how we think about system security.

The Problem with Trust

Traditional operating systems are built on layers of trust:

Application
    ↓ trusts
  Kernel
    ↓ trusts
Bootloader
    ↓ trusts
 Firmware
    ↓ trusts
 Hardware

Each layer trusts the layer below it. If any layer is compromised, everything above it is compromised too.

Real-World Consequences

Bootkit Attacks: Malware that infects the bootloader runs before the OS, invisible to antivirus.

Kernel Rootkits: Once in the kernel, malware has complete control and is nearly impossible to detect.

Supply Chain Attacks: A compromised build system can inject malware that passes all software checks.

Firmware Implants: Nation-state attackers target firmware because it persists across OS reinstalls.

The Zero-Trust Approach

NØNOS inverts the trust model:

Nothing is trusted. Everything is verified.

Overview of the Verification Process

1. Hardware Root of Trust

The verification process begins at the hardware level:

  • TPM 2.0 (if available)

  • UEFI Secure Boot

  • CPU security features (SMEP, SMAP, CET)

2. Bootloader Verification

The UEFI Secure Boot checks the NØNOS bootloader:

  • Bootloader must be signed with a trusted key.

  • Firmware rejects any unsigned or modified bootloaders.

3. Kernel Verification

The bootloader validates the kernel:

  • Computes a BLAKE3 hash of the kernel binary.

  • Verifies the Ed25519 signature against embedded keys.

  • Supports multiple keys (primary, backup, recovery).

4. Module Verification

The kernel checks all loaded modules:

  • Each module needs to be signed.

  • Capabilities are cryptographically linked.

  • No execution of unsigned code.

5. Runtime Verification

Continuous verification during runtime:

  • Capability tokens are checked with every operation.

  • Hardware verifies memory access.

  • Enforces control flow integrity.

What Zero-Trust Prevents

Boot-Time Attacks

Attack
Traditional OS
NØNOS

Evil Maid (bootloader replacement)

Vulnerable

Signature verification fails

Bootkit

Vulnerable

Cannot produce valid signature

Cold Boot

Vulnerable

Memory encryption (future)

Runtime Attacks

Attack
Traditional OS
NØNOS

Privilege escalation

Root bypasses controls

No bypass—need valid capability

Buffer overflow

Can corrupt kernel

W^X + CFI + capability check

Code injection

Execute arbitrary code

Signature required for all code

Supply Chain Attacks

Attack
Traditional OS
NØNOS

Compromised build

Undetectable

Signature won't match

Malicious update

Trusted if signed by vendor

Only trusted keys accepted

Backdoored binary

Runs normally

Hash mismatch detected

The Verification Chain

Beyond Boot: Runtime Zero-Trust

Zero-trust doesn't end at boot. NØNOS maintains verification throughout runtime:

Capability Enforcement

Every system call requires a capability token:

Memory Protection

  • W^X: Memory is either writable OR executable, never both

  • SMEP: Kernel cannot execute user-space code

  • SMAP: Kernel cannot access user-space data

  • Guard pages: Detect buffer overflows

Control Flow Integrity

  • Hardware CET support

  • Indirect branch tracking

  • Shadow stack protection

The Cost of Zero-Trust

Zero-trust isn't free:

Aspect
Cost
Benefit

Boot time

+0.5s for verification

Guaranteed authentic boot

Code size

Crypto libraries needed

Small overall (~521KB)

Complexity

Key management required

Formal security guarantees

Flexibility

Can't run unsigned code

Attack surface eliminated

For security-critical applications, these costs are negligible compared to the guarantees provided.

PreviousWhat is NØNOS?NextSecurity Model

Last updated

Was this helpful?