Security Architecture¶
Nanorix uses a defense-in-depth approach with six layers of Linux isolation. Every session runs in a sealed environment with no persistent storage, no network access, and no host filesystem visibility.
Design Principles¶
Ephemeral by construction. Sessions exist in volatile memory only. There is no persistent disk, no database storage of customer data, and no log capture of session content. When a session is destroyed, the data is gone — physically, not just logically.
Zero trust in ourselves. The CDP is designed so that verification does not require trusting Nanorix. The hash chain algorithm is public, the Ed25519 public key is embedded in the CDP, and any standard cryptography library can verify the proof independently.
Defense in depth. No single layer is sufficient. All six layers operate simultaneously on every session.
Six-Layer Isolation¶
Each session is wrapped in six layers of Linux kernel isolation, applied in order during session creation:
Layer 1 — User Namespace¶
Unprivileged isolation using unshare(2). The session process runs as an unprivileged user with UID mapping, preventing escalation to host root.
Layer 2 — Mount Namespace¶
Private mount namespace with a volatile tmpfs filesystem. The session has no visibility into the host filesystem. All writes go to tmpfs (RAM-backed) and are destroyed with the namespace.
Layer 3 — UTS Namespace¶
Randomized hostname per session. Prevents session-to-session identification via hostname leakage.
Layer 4 — Network Namespace¶
Isolated network stack per session. Each session has its own network namespace with no routes to the host network or other sessions. No outbound network access.
Layer 5 — Cgroup v2¶
Per-session memory limits enforced via cgroup v2. Memory is capped per tier (Free: 256MB, Starter: 1GB, Business: 4GB). Swap is disabled (memory.swap.max = 0). OOM events terminate the session, triggering full destruction with CDP generation.
Layer 6 — Seccomp-BPF¶
Deny-by-default system call filter. Approximately 70 syscalls are allowed (those needed for computation). Blocked syscalls include: ptrace, mount, socket, reboot, kernel module operations, keyring operations, and all administrative calls. The filter survives execve — child processes inherit the restriction.
Destruction Sequence¶
When a session is destroyed (by customer request, TTL expiry, or system event), an 8-step destruction sequence executes:
| Step | Subsystem | What Happens |
|---|---|---|
| 1 | Namespace teardown | Linux namespace isolation verified and marked for destruction |
| 2 | Filesystem destruction | tmpfs unmounted and all volatile storage freed |
| 3 | Memory overwrite | Multi-pass overwrite (DoD 5220.22-M) of allocated memory regions |
| 4 | Key zeroization | All cryptographic keys zeroized from memory using zeroize crate |
| 5 | Credential incineration | Session credentials and identity material destroyed |
| 6 | Forensic verification | Merkle tree verification confirms zero residual data |
| 7 | Chain integrity seal | Hash chain validated and sealed |
| 8 | Lifecycle completion | Session resources freed, CDP assembled and signed |
Each step generates evidence. The evidence is cryptographically hash-chained (SHA-256) and the complete chain is signed with an ephemeral Ed25519 key.
See CDP Specification for the detailed chain format and hash computation.
Cryptographic Primitives¶
| Primitive | Algorithm | Usage |
|---|---|---|
| Hash chain | SHA-256 | Links destruction steps into a tamper-evident sequence |
| Attestation | Ed25519 | Signs the final chain hash — one key per session, destroyed after signing |
| Key zeroization | zeroize crate |
Overwrites key material in memory before deallocation |
| Encryption (at rest) | AES-256-GCM | Encrypts session metadata in transit; no customer data is stored |
Ed25519 Key Lifecycle¶
- Generation — A fresh Ed25519 keypair is generated when destruction begins.
- Single use — The private key signs exactly one message: the final chain hash.
- Zeroization — The private key is immediately zeroized from memory after signing.
- Public key storage — The public key is embedded in the CDP and stored in the key database for optional provenance verification via
GET /v1/keys/:id.
The private key never exists outside of a single function scope. It cannot be extracted, replayed, or reused.
What Nanorix Does NOT Store¶
After a session is destroyed, the following do not exist anywhere in Nanorix infrastructure:
- Customer data (input, output, intermediate computation)
- Session filesystem contents
- Command output or stderr (returned to customer in the destroy response, then discarded)
- Private signing keys
- Memory contents of the session
What is stored:
- The CDP (hash chain + signature + metadata)
- The Ed25519 public key (for provenance verification)
- Customer account data (email, tier, API key hash, jurisdiction)
- Session metadata (ID, status, timestamps, data classification declaration)
API Key Security¶
API keys are hashed with SHA-256 before storage. Nanorix does not store plaintext API keys. The key is shown exactly once at signup and cannot be retrieved afterward.
Rate limiting is applied per API key (authenticated endpoints) and per IP address (public endpoints like /v1/verify and /v1/signup).
Infrastructure¶
| Component | Details |
|---|---|
| Runtime | Rust (memory-safe, no garbage collector, no runtime) |
| Framework | Axum + Tokio (async, non-blocking) |
| Database | PostgreSQL (Neon) — stores only account data and CDPs, never customer content |
| Hosting | Google Cloud Run gen2 (US: us-central1, EU: europe-west1) |
| TLS | Google-managed TLS certificates |
| Billing | Stripe (metered billing, webhook-verified) |
Threat Model¶
What we defend against¶
- Data persistence after processing — All six isolation layers plus the 8-step destruction sequence ensure no data survives session termination.
- Cross-session contamination — Each session has its own namespace, filesystem, network stack, and cgroup. Sessions cannot observe each other.
- CDP forgery — Ed25519 signatures are computationally infeasible to forge. Tampering with any chain step invalidates the hash chain.
- Insider access — Even Nanorix operators cannot access session content. Data exists only in volatile memory within an isolated namespace. There is no debug endpoint, no log capture, and no persistent storage of session content.
What we do NOT defend against¶
- Verification of physical destruction — CDPs prove that the 8-step destruction sequence executed and that the proof artifact is intact. They do not independently prove that the physical memory was overwritten (this requires hardware attestation, which is a future capability).
- Customer-declared metadata accuracy —
jurisdictionanddata_classificationare customer-declared. Nanorix does not verify these declarations. - Host compromise — If the underlying Cloud Run infrastructure is compromised at the hypervisor level, session isolation could theoretically be broken. This is mitigated by Google's infrastructure security but is not cryptographically provable without confidential computing (future roadmap).