Key Hierarchy

The three-tier cryptographic key architecture for sovereign agents.

Overview

SAP employs a hierarchical key structure inspired by enterprise PKI and hardware security module (HSM) best practices. This design balances security (least privilege, compromise containment) with usability (operational efficiency, recovery capability).

                    ┌─────────────────────┐
                    │  Root Identity Key  │
                    │       (RIK)         │
                    │                     │
                    │  • Highest trust    │
                    │  • Rarely used      │
                    │  • Signs rotations  │
                    └──────────┬──────────┘
                               │
              ┌────────────────┼────────────────┐
              │                │                │
              ▼                ▼                ▼
      ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
      │ Operational  │ │ Operational  │ │ Operational  │
      │   Key (OK₁)  │ │   Key (OK₂)  │ │   Key (OKₙ)  │
      │              │ │              │ │              │
      │ • Day-to-day │ │ • Day-to-day │ │ • Day-to-day │
      │ • Short-lived│ │ • Short-lived│ │ • Short-lived│
      └──────────────┘ └──────────────┘ └──────────────┘

                    ┌─────────────────────┐
                    │   Recovery Key      │
                    │       (RK)          │
                    │                     │
                    │  • Offline storage  │
                    │  • Emergency only   │
                    │  • Threshold scheme │
                    └─────────────────────┘

Key Types

Root Identity Key (RIK)

The Root Identity Key is the anchor of an agent’s cryptographic identity.

Property	Value
Trust Level	Highest
Usage Frequency	Rare (rotations, recovery)
Storage	Cold storage, HSM, or sealed backup
Compromise Impact	Total identity loss

Responsibilities:

Signs operational key rotations
Signs recovery assertions
Anchors the agent’s did:key identifier
Signs the Public Identity Document (PID)

Security Requirements:

Never used for routine operations
Protected by hardware security when possible
Backed up via Identity Sentinel

Operational Keys (OK)

Operational Keys handle day-to-day cryptographic operations.

Property	Value
Trust Level	Medium
Usage Frequency	High (every operation)
Storage	In-memory during runtime
Compromise Impact	Limited (rotation required)

Responsibilities:

Signing API requests
Authenticating sessions
Encrypting communications
Deriving task-specific subkeys

Lifecycle:

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  Generate   │────▶│   Active    │────▶│   Expired   │
│  (RIK signs)│     │  (in use)   │     │  (archived) │
└─────────────┘     └─────────────┘     └─────────────┘
                          │
                          │ compromise detected
                          ▼
                    ┌─────────────┐
                    │   Revoked   │
                    │  (invalid)  │
                    └─────────────┘

Best Practices:

Rotate regularly (weekly/monthly)
Use separate OKs for different purposes
Log all rotations in the rotation chain

Recovery Key (RK)

The Recovery Key enables emergency identity restoration.

Property	Value
Trust Level	Highest (emergency only)
Usage Frequency	Never (unless disaster)
Storage	Offline, distributed
Compromise Impact	Total if RIK also lost

Responsibilities:

Emergency RIK rotation
Identity recovery after catastrophic loss
Threshold signing for high-stakes operations

Storage Strategies:

Geographic Distribution

RK Shard 1 → Safety deposit box (City A)
RK Shard 2 → Trusted contact (City B)
RK Shard 3 → Encrypted cloud backup (Provider C)

Threshold Scheme (e.g., 2-of-3 Shamir)

Any 2 shards → Reconstruct RK
1 shard alone → Useless

Key Derivation

From RIK to OK

RIK (ed25519 or similar)
         │
         │ KDF(purpose="operational", index=n)
         ▼
       OK[n]

From OK to Task Keys

OK[current]
         │
         │ HKDF(context="task-{id}", timestamp)
         ▼
    Task Key (ephemeral)

Rotation Chain

Every key rotation is recorded in an append-only log:

{
  "rotationChain": [
    {
      "sequence": 1,
      "type": "ok_rotation",
      "timestamp": "2026-02-01T00:00:00Z",
      "oldKeyId": "ok_001",
      "newKeyId": "ok_002",
      "reason": "scheduled",
      "rikSignature": "..."
    },
    {
      "sequence": 2,
      "type": "ok_rotation",
      "timestamp": "2026-02-08T00:00:00Z",
      "oldKeyId": "ok_002",
      "newKeyId": "ok_003",
      "reason": "scheduled",
      "rikSignature": "..."
    }
  ]
}

Properties:

Immutable: Entries cannot be modified
Signed: Each entry signed by RIK
Auditable: Complete history of key changes
Verifiable: Third parties can validate the chain

DID Mapping

The key hierarchy maps to W3C DIDs:

SAP Key	DID Mapping
RIK	`did:key` identifier (stable anchor)
OK	Verification methods in PID
RK	Not published (offline only)

Example PID excerpt:

{
  "id": "did:key:z6Mk...",
  "verificationMethod": [
    {
      "id": "did:key:z6Mk...#rik",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:key:z6Mk...",
      "publicKeyMultibase": "z6Mk..."
    },
    {
      "id": "did:key:z6Mk...#ok-003",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:key:z6Mk...",
      "publicKeyMultibase": "z7Nk..."
    }
  ]
}

Security Analysis

Compromise Scenarios

Key Compromised	Impact	Recovery Action
OK only	Limited	Rotate OK, revoke old
RIK only	Severe	Use RK to rotate RIK
RK only	None (if unused)	Generate new RK
RIK + OK	Severe	Use RK to rotate both
RIK + RK	Catastrophic	Identity lost

Defense in Depth

Layer 1: Physical security (cold storage)
    ↓
Layer 2: Encryption (sealed backups)
    ↓
Layer 3: Access control (threshold schemes)
    ↓
Layer 4: Monitoring (rotation chain audit)
    ↓
Layer 5: Recovery (shadow replicas)

Implementation Guide

Initial Setup

// 1. Generate RIK (store securely!)
const rik = generateEd25519Keypair();

// 2. Generate initial OK
const ok1 = deriveOperationalKey(rik, 1);

// 3. Create RK shards
const rkShards = shamirSplit(rik.privateKey, { threshold: 2, shares: 3 });

// 4. Create sealed backup
const backup = sealIdentity(masterPassphrase, {
  rik: rik,
  currentOK: ok1,
  rotationChain: []
});

Routine Rotation

// 1. Generate new OK
const ok2 = deriveOperationalKey(rik, 2);

// 2. Sign rotation record
const rotationRecord = {
  sequence: rotationChain.length + 1,
  type: "ok_rotation",
  oldKeyId: ok1.id,
  newKeyId: ok2.id,
  timestamp: new Date().toISOString(),
  reason: "scheduled"
};
rotationRecord.rikSignature = sign(rik, rotationRecord);

// 3. Update rotation chain
rotationChain.push(rotationRecord);

// 4. Archive old OK, activate new
currentOK = ok2;

Identity Sentinel — Sealed backup system
PID Structure — Public Identity Document format
DID Integration — W3C DID mapping
TEE Deployment — Hardware-backed key storage

Key Hierarchy

Overview

Key Types

Root Identity Key (RIK)

Operational Keys (OK)

Recovery Key (RK)

Key Derivation

From RIK to OK

From OK to Task Keys

Rotation Chain

DID Mapping

Security Analysis

Compromise Scenarios

Defense in Depth

Implementation Guide

Initial Setup

Routine Rotation

Related