Security Model

NØNOS implements defense-in-depth with multiple security layers.

---

Security Layers

┌───────────────────────────────────────┐
│  Layer 5: Application Sandboxing      │
├───────────────────────────────────────┤
│  Layer 4: Capability-Based Access     │
├───────────────────────────────────────┤
│  Layer 3: Memory Protection           │
├───────────────────────────────────────┤
│  Layer 2: Kernel Verification         │
├───────────────────────────────────────┤
│  Layer 1: Boot Chain Verification     │
└───────────────────────────────────────┘

---

Chain of Trust

Boot Verification

1. UEFI Secure Boot | Firmware verifies bootloader

2. Bootloader | Verifies kernel with Ed25519

3. Kernel | Verifies loaded modules

4. Modules | Capability tokens for access

Signature Verification

Kernel Binary
     │
     ├──► BLAKE3(binary) = hash
     │
     └──► Ed25519.verify(hash, signature, public_key)

Capability System

What are Capabilities?

Unforgeable tokens that grant specific permissions:

┌──────────────────────────────────┐
│         Capability Token         │
├──────────────────────────────────┤
│  Object ID      │  unique ref    │
│  Permissions    │  bitmap        │
│  Expiry         │  optional      │
│  Crypto Tag     │  MAC           │
└──────────────────────────────────┘

Permission Types

Permission	Description
READ	Read access
WRITE	Write access
EXECUTE	Execute permission
GRANT	Can delegate capability
REVOKE	Can revoke capability

Usage

Operations require presenting a valid capability:

• No capability → Access denied

• Wrong permissions → Access denied

• Expired → Access denied

---

Memory Protection

W^X Policy

Every page is either:

• Writable (RW) | Can modify, cannot execute

• Executable (RX) | Can execute, cannot modify

• Never both simultaneously

Address Space Isolation

• Kernel in higher-half (0xFFFFFFFF80000000+)

• User space isolated per-process

• Guard pages between regions

KASLR

Kernel base address randomized at boot using hardware entropy.

---

Hardware Security

Supported Features

Feature	Purpose
SMEP	Prevent kernel from executing user pages
SMAP	Prevent kernel from accessing user pages
CET	Control-flow integrity
RDRAND	Hardware random numbers
TPM 2.0	Secure key storage

CPU Mitigations

• Spectre/Meltdown mitigations

• Retpoline for indirect branches

• KPTI (Kernel Page Table Isolation)

---

Cryptographic Security

Algorithms

Use	Algorithm	Security Level
Signing	Ed25519	128-bit
Hashing	BLAKE3	256-bit
Encryption	AES-256-GCM	256-bit
Key Exchange	ML-KEM-768	Post-quantum
ZK Proofs	Groth16	128-bit

Key Storage

• Keys stored in encrypted vault

• Hardware-bound sealing (when TPM available)

• Secure key derivation (HKDF)

---

Zero-Knowledge Proofs

ZK proofs enable:

• Privacy-preserving attestation

• Proving computation without revealing inputs

• Anonymous authentication

See ZK Overview.

---

Attack Surface

Minimized Codebase

The kernel compiles to approximately 221KB. (Previously 67KB, Oct 2025) While this may seem larger than traditional microkernels, this single binary includes a complete. graphical desktop environment, TLS 1.3 networking stack, three-hop onion routing circuits, post-quantum cryptography primitives (ML-KEM-768, ML-DSA-65), a preemptive scheduler, PS/2 input drivers and a RAM-only encrypted filesystem. For comparison, a minimal Linux kernel typically starts at 5–10MB without any of these integrated features. The size reflects our design philosophy: a single, cohesive binary with no external dependencies rather than a tiny kernel that requires loading megabytes of external modules.

Component	Size
Bootloader	~300KB
Kernel	~221KB
Total	~521KB

Compare to typical OS kernels (minimal range 1-10MB).

---

Unsafe Code Audit

• 900+ audited unsafe blocks

• All in hardware access / memory management

• Zero unsafe in cryptographic code

Security Guarantees

✅ What NØNOS provides:

• Verified boot chain

• Capability-based access control

• Memory safety (Rust)

• Post-quantum crypto

• ZK attestation

⚠️ What NØNOS does NOT protect against:

• Physical access attacks (without TPM)

• Side-channel attacks (partially mitigated)

• Hardware backdoors

• User-provided malicious code (sandboxed)

---

Incident Response

If a vulnerability is discovered:

1. Security issues → [email protected] — Github

2. Responsible disclosure

3. Patch and coordinated release