Key Exchange Protocol

This is the most security-critical part of LICEN. The current demo seals a dataset AES key for the Orchestrator so the app can simulate the compute lifecycle after an on-chain access grant. The production design changes the recipient: the key should be released only to an attested 0G-compatible compute node.

The underlying pattern is envelope encryption — the dataset key is encrypted for a specific recipient before it leaves the publisher's browser.

The Setup (One Time)

When the Orchestrator is deployed, it generates a secp256k1 keypair:

• Private key — stored in the Orchestrator's environment variables (ORCHESTRATOR_PRIVATE_KEY). Never shared.
• Public key — hardcoded into the Next.js app environment (NEXT_PUBLIC_ORCHESTRATOR_PUBLIC_KEY). Visible to everyone. That's intentional.

Phase 1: Publish (In the Browser)

When a publisher selects their JSONL file:

Browser generates random AES-256-GCM key
         │
         ├─► Encrypts dataset with AES key ──────────────► Upload to 0G Storage
         │         (ciphertext + auth tag)                   (datasetRoot returned)
         │
         └─► Encrypts AES key with Orchestrator's          Save to Web App DB
             public key via ECIES                   ──────► (keyed by datasetRoot)
             (= "Key Envelope")

The web app's database only ever holds the sealed envelope — the AES key encrypted with the Orchestrator's public key. Even if the database is compromised, the AES key cannot be recovered without the Orchestrator's private key.

Phase 2: Access (Current Demo)

When a researcher pays escrow and the AccessGranted event fires:

Orchestrator confirms on-chain state = Granted
         │
         ▼
Fetches sealed envelope from Web App API
         │
         ▼
Decrypts envelope with ECIES private key ──────────► AES key revealed (in memory)
         │
         ▼
Downloads encrypted dataset from 0G Storage
         │
         ▼
Decrypts dataset in memory (AES-256-GCM)
         │
         ├─► Re-uploads plaintext to 0G Storage for compute dispatch
         │
         └─► Zeros AES key bytes from memory (finally block)

This is acceptable for demonstrating policy enforcement and settlement, but it is not the final confidential-input architecture.

Phase 2: Access (Production Target)

In production, the envelope/key-release target changes from the Orchestrator to a 0G-compatible confidential compute node:

Provider TEE boots approved training container
         │
         ▼
TEE generates attestation quote + ephemeral public key
         │
         ▼
LICEN verifies hardware, image hash, code hash, and policy
         │
         ▼
AES key released encrypted to TEE public key
         │
         ▼
TEE downloads encrypted dataset from 0G Storage
         │
         ▼
TEE decrypts, trains, wipes plaintext, signs result manifest

The AES key becomes usable only inside the measured training runtime. The Orchestrator coordinates the job but does not receive plaintext dataset bytes.

Why This Is Secure

The MVP Limitation (and the Upgrade Path)

The current Orchestrator is a centralised key custodian. It is the trusted operator — equivalent to the trust the backendWallet role has in the DataPolicy contract.

This is the honest limitation: a compromised Orchestrator could theoretically decrypt any envelope it holds.

The upgrade path to decentralise key custody is straightforward because the envelope format is system-agnostic:

Upgrading requires no changes to the DataPolicy contract, the publish flow, or the frontend — only the Orchestrator's keyExchange.ts module changes.