OutLayer Documentation

Secrets

Enterprise-Grade Security with CKD & MPC Network

Secrets are protected using Confidential Key Derivation (CKD) - a cutting-edge primitive that leverages the NEAR MPC Network to provide deterministic secrets for TEE applications. Each app gets cryptographically isolated keys that persist across TEE restarts, derived through distributed computation where no single node knows the final secret.

What are Secrets?#

Secrets are encrypted API keys, tokens, or sensitive data stored on-chain. They are automatically decrypted and injected as environment variables when your WASM code executes. The keystore service running in TEE handles all encryption/decryption operations.

Creating Secrets#

Use the Secrets page to create encrypted secrets. Specify repository, branch (optional), and profile name. Secrets are encrypted client-side before being stored on-chain.

Two Ways to Create Secrets:

1. Manual Secrets

Provide key-value pairs directly (e.g., API keys you already have)

  • Encrypted client-side with ChaCha20-Poly1305
  • Example: {"OPENAI_KEY": "sk-..."}
  • Cannot use PROTECTED_* prefix (reserved for auto-generated)

2. Auto-Generated Secrets

Generate cryptographically secure secrets in TEE without seeing their values

  • Generated inside TEE (nobody ever sees the value)
  • Perfect for derivation keys, signing keys, encryption keys
  • Must start with PROTECTED_* prefix (proves TEE generation)
  • Example: PROTECTED_MASTER_KEY
  • Types: hex32/64, ED25519, password:N

Naming Convention for Trust

The PROTECTED_* prefix proves a secret was generated in TEE and never seen by anyone (including developers). Manual secrets cannot use this prefix - enforced by keystore validation.

Secrets Binding Types#

Secrets can be bound to different identifiers depending on your use case:

Repository-based (GitHub)

Bind secrets to a GitHub repository and optional branch

  • Key: repo + branch + profile + owner
  • Example: github.com/user/repo:main:production
  • Best for: Development, CI/CD workflows, version-specific secrets

WASM Hash-based

Bind secrets to a specific compiled WASM binary (SHA256 hash)

  • Key: wasm_hash + profile + owner
  • Example: cbf80ed0...2f8:production
  • Best for: Pre-compiled WASM from FastFS/IPFS, immutable deployments
  • Guarantees: Only this exact binary can access the secrets

Project-based

Bind secrets to a Project - accessible by all versions

  • Key: project_id + profile + owner
  • Example: alice.near/my-app:production
  • Best for: Long-running projects with multiple versions
  • Benefit: Secrets persist across version updates - no re-creation needed

Project Binding Recommendation

For most use cases, Project binding is recommended. It allows you to update your WASM code without re-creating secrets. Create a project in the Projects dashboard, then bind your secrets to that project.

WASM Hash Binding Security

When using WASM hash binding, secrets are cryptographically tied to the exact binary. Any modification to the code produces a different hash, preventing unauthorized access. This is ideal for production deployments where code immutability is required.

Access Control#

Control who can decrypt your secrets using flexible access conditions:

  • AllowAll: Anyone can use (suitable for public data)
  • Whitelist: Specific NEAR accounts only
  • NEAR Balance: Accounts with minimum NEAR balance
  • FT/NFT Balance: Token holders only
  • Account Pattern: Regex-based account filtering
  • Logic: Complex AND/OR/NOT conditions

Using Secrets in Code#

Access secrets in your WASM code using standard environment variable functions. In Rust:std::env::var("API_KEY")

Storage Costs#

Secrets storage costs are proportional to data size plus indexing overhead (~64 bytes). Storage fees are refunded when you delete secrets.

Security Model#

Secrets are encrypted with ChaCha20-Poly1305 AEAD (authenticated encryption with associated data). Decryption happens in TEE workers with attestation verification. Your secrets never leave the secure enclave.

Confidential Key Derivation (CKD)#

How Keystore Gets Its Derivation Key via MPC

The keystore worker itself is a TEE application that obtains its derivation key through NEAR MPC Network via DAO governance.Critically, the keystore uses a functional key (not a full access key) that can ONLY call the MPC signer through the DAO contract's request_key method. This architectural decision ensures the keystore cannot directly access the MPC network - it must go through DAO governance, making all operations auditable on-chain. Once authorized by the DAO, the keystore requests a deterministic derivation key from MPC nodes using Confidential Key Derivation. This derivation key is then used to decrypt secrets for other applications, ensuring all cryptographic operations stay within the TEE.

Phase 1: Registration (One-time)

┌──────────┐
│ Keystore │
│   TEE    │
│          │
│• Generate│
│  keypair │
│• RTMR3   │
│ 0x2641.. │
└────┬─────┘
     │
     │ 1. Submit
     │ attestation
     ▼
┌──────────┐
│   DAO    │
│ Contract │
│          │
│• Verify  │
│  attest. │
│• Create  │
│ proposal │
└────┬─────┘
     │
     │ 2. Send
     │ proposal
     ▼
┌──────────┐
│   DAO    │
│ Members  │
│          │
│• Review  │
│  RTMR3   │
│• Vote    │
│  (>50%)  │
└────┬─────┘
     │
     │ 3. Approve
     ▼
┌──────────┐
│    ✓     │
│APPROVED  │
│          │
│Functional│
│key added │
│ to DAO   │
└──────────┘

Phase 2: CKD Flow (Repeatable)

┌──────────┐
│ Keystore │
│   TEE    │
│          │
│✓ Has     │
│  func key│
│• Needs   │
│  CKD     │
└────┬─────┘
     │
     │ 1. Request
     │ CKD with
     │ func key
     ▼
┌──────────┐
│   DAO    │
│ Contract │
│(Gateway) │
│          │
│Only func │
│key can   │
│call      │
└────┬─────┘
     │
     │ 2. Forward
     │ request_key()
     ▼
┌──────────┐
│   MPC    │
│ Contract │
│          │
│v1.signer-│
│   prod   │
│          │
│Coordinate│
│derivation│
└────┬─────┘
     │
     │ 3. Distribute
     │ to nodes
     ▼
┌──────────┐
│   MPC    │
│  Nodes   │
│          │
│  ● ● ●   │
│   ● ●    │
│  ● ● ●   │
│          │
│ Compute  │
│BLS12-381 │
└────┬─────┘
     │
     │ 4. Return
     │ encrypted
     │ derivation key
     ▼
┌──────────┐
│ Keystore │
│ receives │
│encrypted │
│   key    │
│          │
│ Only TEE │
│   can    │
│ decrypt  │
└──────────┘

Key Properties

✓Deterministic
✓Persistent
✓Survives restarts
✓No single point of failure

Two-Level Architecture:

  • Level 1: Keystore obtains derivation key from NEAR MPC via CKD protocol through DAO contract
  • Level 2: Keystore uses derivation key to decrypt app secrets
  • All operations happen inside TEE - keys never leave the enclave
  • DAO governance ensures only legitimate keystores get derivation keys
  • Functional keys restrict keystore operations through DAO contract
  • All key derivation requests are logged on-chain for auditability
  • MPC Network ensures no single entity controls the derivation key generation

Key Properties

  • • Deterministic: Same app_id always gets same secret
  • • Private: Secret known only to TEE app
  • • Distributed: No single MPC node has the secret
  • • Persistent: Works across TEE restarts

Security Guarantees

  • • BLS signatures on BLS12-381 curves
  • • ElGamal encryption for transport
  • • TEE attestation verification
  • • Threshold cryptography (t-of-n)

Why MPC-based CKD is Revolutionary

Traditional approaches either store keys (security risk) or lose them on restart (no persistence). NEAR's MPC-based CKD is unique: it provides deterministic secrets through distributed computation where no single entity ever has the complete key. This combines the benefits of persistence, security, and decentralization - a combination not available in other systems.

DAO Governance & Keystore Authorization#

DAO Controls Keystore Access to MPC

The DAO governs which keystore workers can receive derivation keys from the NEAR MPC Network. Only TEE-verified keystores that pass DAO voting can request CKD from MPC nodes. This ensures that derivation keys are only given to legitimate, attestation-verified keystores running in secure enclaves, preventing any unauthorized access to user secrets.

Keystore Authorization Flow

  1. On-Chain TEE Verification: Keystore submits Intel TDX/SGX attestation directly to DAO contract. The contract cryptographically verifies the Intel certificate and TEE environment hash (RTMR3/MRENCLAVE) on-chain. This ensures submissions can only come from genuine TEE with verified binary.
  2. Automated Validation: DAO contract automatically rejects any submission that:
    • Doesn't have valid Intel signature
    • Comes from unverified RTMR3/MRENCLAVE
    • Attempts to bypass TEE requirements
  3. DAO Voting: Only after passing on-chain TEE verification, DAO members vote to authorize keystore based on operator reputation, stake, and network capacity needs
  4. MPC Key Request: Once approved, keystore requests derivation key from MPC Network using CKD protocol with its unique keystore_id
  5. Derivation Key Receipt: Keystore receives encrypted derivation key, decrypts it in TEE, and can now decrypt user secrets while keeping all keys inside the enclave

Cryptographic Properties

The CKD protocol ensures strong security through:

  • BLS signatures on pairing-friendly BLS12-381 curves
  • Threshold cryptography - requires t-of-n nodes to cooperate
  • ElGamal encryption for secure transport
  • HKDF for key derivation from BLS signatures

This combination ensures that secrets are deterministic yet unpredictable, persistent yet secure, distributed yet accessible only to authorized TEE apps.

Security Properties

  • • No single point of failure: Distributed MPC nodes
  • • Forward secrecy: Fresh key pair for each request
  • • TEE isolation: Secrets computed inside enclave
  • • Threshold security: Requires multiple nodes

Trust Model

  • • Intel TDX attestation verification
  • • MPC network consensus
  • • Smart contract enforcement
  • • Cryptographic correctness proofs

Example: CKD Request

How a TEE app requests a deterministic secret:

// TEE app generates key pair
let (a, A) = generate_elgamal_keypair();

// Include A in attestation report_data
let attestation = get_tdx_attestation(A);

// Call developer contract
developer_contract.get_key(attestation, A);

// Developer contract validates and calls MPC
mpc_contract.gen_app_private_key(A);

// Receive encrypted secret (Y, C)
// Decrypt: sig = C - a·Y
// Derive: secret = HKDF(sig)

The final secret is deterministic for app_id but known only to the TEE app.

CKD & MPC FAQ#

What happens if the keystore restarts?

The keystore can request the same derivation key again from NEAR MPC using its keystore_id. Since CKD is deterministic, it will receive the same derivation key. This allows the keystore to continue decrypting user secrets after restarts without storing keys on disk.

Can MPC nodes or DAO see my secrets?

No. MPC nodes only generate the derivation key for the keystore when requested by the DAO contract - they never see user secrets. Importantly, MPC Network only responds to requests that come through the DAO contract transaction, not direct requests. The DAO governs which keystores can receive derivation keys but has no access to the keys themselves. User secrets are encrypted and only the keystore (running in TEE) can decrypt them. No entity outside the TEE ever has access to plaintext secrets.

How is this different from regular key storage?

Traditional systems either store keys (security risk) or generate random keys that are lost on restart. CKD provides deterministic secrets through distributed computation - persistent yet secure, distributed yet accessible, a unique combination enabled by MPC and TEE technologies.

What prevents unauthorized access to secrets?

Multiple layers: (1) DAO governance controls which keystores can receive derivation keys, (2) TEE attestation verification ensures only genuine TEE apps run the keystore, (3) MPC Network only responds to requests from DAO contract (not direct requests), (4) Threshold cryptography requires multiple MPC nodes to cooperate, (5) All cryptographic operations happen inside TEE enclave.

Why use BLS signatures on BLS12-381 curves?

BLS signatures provide unique properties: deterministic, aggregatable, and efficient verification. BLS12-381 is a pairing-friendly curve specifically designed for cryptographic protocols, offering 128-bit security with optimal performance for threshold cryptography and MPC operations.