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:

Application
    ↑ verified by
  Kernel
    ↑ verified by
Bootloader
    ↑ verified by
 Firmware (Secure Boot)
    ↑ verified by
 Hardware Root of Trust

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

┌─────────────────────────────────────────────────────────────┐
│                    BOOT VERIFICATION                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   Kernel Binary                                             │
│        │                                                    │
│        ├──────► BLAKE3(kernel) = hash                       │
│        │                                                    │
│        │        ┌─────────────────────────────────┐         │
│        │        │     Embedded Public Keys        │         │
│        │        │  ┌─────┐ ┌─────┐ ┌─────┐        │         │
│        │        │  │ PK1 │ │ PK2 │ │ PK3 │        │         │
│        │        │  └─────┘ └─────┘ └─────┘        │         │
│        │        └─────────────────────────────────┘         │
│        │                     │                              │
│        └──► Ed25519.verify(hash, signature, PKn) ────────── │
│                              │                              │
│                              ▼                              │
│                    ┌─────────────────┐                      │
│                    │  PASS  │  FAIL  │                      │
│                    │   ↓    │   ↓    │                      │
│                    │  Boot  │  Halt  │                      │
│                    └─────────────────┘                      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

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:

Process: "I want to read /etc/passwd"

Kernel: "Show me your capability token"

Process: [presents token]

Kernel:
  1. Verify token signature
  2. Check token grants READ on /etc/passwd
  3. Check token not expired
  4. If all pass → allow
  5. If any fail → deny

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.