# Why Zero-Trust Matters

***

### 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.