Skip to content

Security Architecture

Nanorix uses a defense-in-depth approach with six layers of Linux isolation. Every capsule runs in a sealed environment with no persistent storage, no network access, and no host filesystem visibility.

Design Principles

Ephemeral by construction. Capsules exist in volatile memory only. There is no persistent disk, no database storage of customer data, and no log capture of capsule content. When a capsule is destroyed, the data is destroyed and unrecoverable through any interface Nanorix controls.

Zero trust in ourselves. The AuditProof is designed so that verification does not require trusting Nanorix. The hash chain algorithm is public, the Ed25519 public key is embedded in the AuditProof, 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 capsule.

Six-Layer Isolation

Each capsule is wrapped in six layers of Linux kernel isolation, applied in order during capsule creation. These layers enforce process isolation, filesystem isolation, network isolation, resource limits, system call filtering, and cryptographic attestation.

For detailed layer specifications, request the Security Whitepaper via the contact form.

Destruction Sequence

When a capsule is destroyed (by customer request, TTL expiry, or system event), a multi-step destruction sequence executes. Each step covers a different aspect of destruction: environment teardown, filesystem clearing, memory overwriting, key zeroization, forensic verification, and chain sealing.

Each step generates evidence. The evidence is cryptographically hash-chained (SHA-512) and the complete chain is signed with an ephemeral Ed25519 key.

See AuditProof specification for the chain format.

Cryptographic Guarantees

The AuditProof uses SHA-512 for hash chaining and Ed25519 for attestation signatures. Each capsule gets a fresh ephemeral Ed25519 keypair — the private key signs exactly one message (the final chain hash) and is immediately zeroized from memory. The public key is embedded in the AuditProof for independent verification.

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 capsule is destroyed, the following do not exist anywhere in Nanorix infrastructure:

  • Customer data (input, output, intermediate computation)
  • Capsule filesystem contents
  • Command output or stderr (returned to customer in the destroy response, then discarded)
  • Private signing keys
  • Memory contents of the capsule

What is stored:

  • The AuditProof (hash chain + signature + metadata)
  • The Ed25519 public key (for provenance verification)
  • Customer account data (email, tier, API key hash, jurisdiction)
  • Capsule 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

Written in Rust (memory-safe, no garbage collector). Database stores only account data and AuditProofs, never customer content. TLS-encrypted. For infrastructure details, request the Security Whitepaper via the contact form.

Threat Model

What we defend against

  • Data persistence after processing — All six isolation layers plus the multi-step destruction sequence ensure no data survives capsule termination.
  • Cross-capsule contamination — Each capsule has its own namespace, filesystem, network stack, and cgroup. Capsules cannot observe each other.
  • AuditProof forgery — Ed25519 signatures are computationally infeasible to forge. Tampering with any chain step invalidates the hash chain.
  • Insider access — Even Nanorix operators cannot access capsule content. Data exists only in volatile memory within an isolated namespace. There is no debug endpoint, no log capture, and no persistent storage of capsule content.

What we do NOT defend against

  • Verification of physical destruction — AuditProofs prove that the multi-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 — jurisdiction and data_classification are customer-declared. Nanorix does not verify these declarations.
  • Host compromise — If the underlying Cloud Run infrastructure is compromised at the hypervisor level, capsule isolation could theoretically be broken. This is mitigated by Google's infrastructure security but is not cryptographically provable without confidential computing (future roadmap).