# AEGIS — Cryptographic Identity Model

- **Document ID:** ARCH-09
- **Phase:** B.1 — Structural Foundations
- **Status:** Draft for review (post independent architecture review)
- **Version:** 0.1
- **Date:** 2026-07-10
- **Owner:** Chief Security Architect
- **Depends on:** ARCH-01 through ARCH-08, CLAUDE.md
- **Consumed by:** ARCH-10 through ARCH-16

---

## 1. Purpose

Specify how every component and message in AEGIS is cryptographically identified, mutually authenticated, and independently verifiable. Constitutional constraint #5 requires: every component has its own crypto identity; every communication is mutually authenticated; every message is signed; every critical artifact is verifiable; trust is cryptographically established.

Constitutional constraint #12 (Future Readiness) requires this design to accept post-quantum cryptography, confidential computing, TEEs, hardware root of trust, passkeys, FIDO2, and confidential AI without architectural redesign.

## 2. Identity Model Overview

Two axes of identity in AEGIS:

- **Workload identity** — every engine instance, Kernel replica, plugin sandbox, and model runtime has its own short-lived certificate bound to a stable **workload DID** (Decentralized Identifier–style URI).
- **Principal identity** — humans, service accounts, agents; long-lived identities backed by IdP or by the Identity Engine's issuance.

Both feed into the Capability Model (ARCH-08) via the Kernel.

Identity substrate is **SPIFFE-compatible** in shape (workload IDs, X.509 SVIDs, JWT-SVIDs) — allowing AEGIS to plug into existing SPIRE deployments or run its own equivalent within the Identity Engine.

## 3. Key Hierarchy

```
Z0 Root of Trust (offline HSM, air-gapped)
    │
    ├── Kernel Signing Root  (signs Kernel intermediate CA)
    │       │
    │       └── Kernel Intermediate CA (operated by Kernel; issues short-lived workload SVIDs)
    │               │
    │               ├── Engine SVIDs (per-instance, hours-TTL)
    │               ├── Plugin Sandbox SVIDs (per-launch, minutes-TTL)
    │               └── Model Runtime SVIDs (per-launch, minutes-TTL)
    │
    ├── Audit Signing Root (signs Layer-A key + Layer-B batch key)
    │       │
    │       ├── Layer-A Chain-Signing Key (Kernel-instance-scoped)
    │       └── Layer-B Batch-Signing Key (Audit Engine)
    │
    ├── Evidence Bundle Signing Root (signs export bundles)
    │       │
    │       └── Case Engine Export-Signing Keys
    │
    ├── Update / Release Signing Root (signs binaries + config bundles)
    │       │
    │       └── Release-Signing Key (per release channel)
    │
    ├── Tenant KEK Root (wraps per-tenant DEKs via KMS)
    │       │
    │       └── Per-tenant KEKs
    │               │
    │               └── Per-tenant DEKs (envelope-encrypted rows/blobs)
    │
    └── Backup KEK Root (separate hierarchy for backup keys per D-04-2)
```

Design invariants:
- **Z0 only signs down; never encrypts.** Signing keys are separate from encryption keys at every level.
- **Every leaf key is short-lived.** SVIDs measured in hours; per-op signing keys measured in minutes; long-lived keys are only the roots.
- **Roots live in HSM/KMS**; leaves may live in memory of the process using them.
- **Every hierarchy has a documented rotation ceremony** (ARCH-11).

## 4. Workload Identity Lifecycle

### 4.1 First-boot Attestation
- Engine presents attestation evidence to the Kernel (per ARCH-06 §7.3):
  - **Kubernetes:** ServiceAccount token + node identity + attested pod identity.
  - **VPS:** TPM quote if available; otherwise, deployment-time enrollment token exchanged once.
  - **TEE / Enclave (Future Readiness):** hardware attestation (SGX/TDX quote, AMD SEV attestation, ARM CCA).
- Kernel verifies evidence and issues an X.509 SVID (workload cert) bound to the engine's DID.
- Cert TTL: default 8 hours; renewable while engine remains attested.

### 4.2 Renewal
- Automatic before expiry; failure to renew triggers alert and graceful drain of the engine instance.
- Renewal does not require re-attestation until a policy-defined re-attestation interval (e.g., every 24 hours).

### 4.3 Revocation
- Immediate revocation via Kernel; propagated over NATS.
- CRL/OCSP-like structure kept small and consumable by all engines.

### 4.4 Rotation
- Scheduled rotation ceremonies for intermediate CAs; documented (ARCH-11).
- Emergency rotation for compromise; drills conducted at least yearly.

## 5. Principal Identity Lifecycle

### 5.1 Humans
- Authenticated via OIDC in v0 (ARCH-02 D-02-4). Session established by Identity Engine; session carries an internal principal ID.
- **Passkey/FIDO2 (Future Readiness):** Identity Engine's login flow is designed to accept WebAuthn assertions in addition to OIDC; no redesign needed to add passkeys, only front-end and IdP configuration.
- MFA required per policy for privileged roles.
- Session TTL and refresh independent of the workload SVID lifecycle.

### 5.2 Service accounts
- Long-lived identity; short-lived credentials (token exchange from a stored secret to a short-TTL JWT-SVID).
- Rotation managed by Identity Engine + Kernel.

### 5.3 Agents (AI agent identities)
- Each AI Engine instance has its own workload SVID; per-agent identity is a scoped principal minted by Identity Engine for a bounded task (e.g., "AI-agent for case #C-123, expires in 15 minutes").
- Agent identity is what capabilities attach to (not the AI Engine's workload SVID directly), ensuring capability grant granularity per task.

## 6. Communication Authentication

### 6.1 mTLS Everywhere
- All engine ↔ Kernel and engine ↔ engine (via Kernel-mediated topics or Kernel-mediated calls) communication uses **mTLS 1.3** with:
  - Ed25519 (or ECDSA P-256 fallback) leaf keys.
  - Certificate pinning by CA + optional SPKI pinning on hot paths.
  - Session resumption disabled where forensics require per-connection audit; enabled with logging elsewhere.
- **External TLS** endpoints use TLS 1.3 with a hardened cipher profile (ARCH-11).

### 6.2 Message Signing (defense in depth)
mTLS proves the transport peer; **message signing** proves the message content and origin end-to-end even across intermediaries. AEGIS signs:

- **Capability tokens** (Kernel).
- **Audit records** (Kernel Layer-A + Audit Engine Layer-B).
- **Findings, cases, timelines, exports** (producers sign; consumers verify).
- **Policy corpus** (Policy Engine signs; Kernel verifies before consulting).
- **Model prompts + redaction manifests** (AI Engine signs; Safety Layer verifies).
- **Release bundles and configuration snapshots** (release-signing key).

Signature algorithm baseline: **Ed25519** for compact and fast operation. Hash algorithm baseline: **SHA-256** (v0). Detailed choice and rotation policy in ARCH-11.

### 6.3 Header propagation
Every request across boundary crosses carries:
- `trace_id` (OpenTelemetry-compatible).
- `caller_did` (from mTLS).
- `capability_id` (from the presented token).
- `tenant_id` (verified against `caller_did` + policy).
- `classification` (data classification of the payload).
- `boundary_label` (e.g., `B-30`).

## 7. Post-Quantum Readiness

### 7.1 Constraints
- v0 uses **classical Ed25519 + X25519 + AES-256-GCM + SHA-256**.
- v1+ prepares for hybrid signatures and hybrid KEMs.
- v2+ (or when NIST standards reach broad support) transitions to PQC primary with classical hybrid retained during migration.

### 7.2 Design accommodations
- Signature and key wire formats are **algorithm-agile**: an `alg` field at every signature site allows adding `Ed25519+Dilithium` (hybrid) or `Dilithium3` alone in-place.
- KEM negotiation in TLS is out of AEGIS's direct control but is transparent when TLS libraries add hybrid KEMs (Kyber/ML-KEM already available in some stacks in 2026).
- Long-lived signatures (audit archival) SHOULD adopt hybrid earlier because their verification lifetime extends beyond classical algorithms' safe horizon.

### 7.3 PQC-Ready Storage Format
- Every signed artifact is stored with algorithm identifiers so verification tools can pick the right verifier.
- Verification tools accept multiple algorithms and log which one succeeded.

## 8. Hardware Root of Trust and TEEs (Future Readiness)

- **HRoT.** Deployments with TPM, HSM, or cloud-KMS-backed root of trust MUST use it for the Kernel's identity and root-signing operations. Software fallback exists but is documented as a lower-trust posture.
- **TEEs / Enclaves.** The workload attestation path is designed to accept TEE quotes (SGX, TDX, SEV-SNP, ARM CCA) as attestation evidence with no changes to the Kernel API — only the verifier module is added.
- **Confidential Computing.** Data-in-use protection is a v2+ goal; the engine boundary contract makes it feasible to run selected engines (AI, Audit, Kernel) in confidential compute pools without changing peer engines.
- **Confidential AI.** L2/L3 running inside TEEs (either self-hosted TEE inference or hosted providers that offer confidential inference) is a Future Readiness target; the AI Engine's provider adapter contract accepts an "attested compute" attribute.

## 9. Passkeys, FIDO2, and Modern Human Authn (Future Readiness)

- Identity Engine's login flow is designed as a set of pluggable "credential providers" — OIDC is one, WebAuthn/passkey is another.
- Session binding uses the resulting principal ID, independent of the credential type.
- Adoption path: enable WebAuthn provider without changing capability grants or downstream engines.

## 10. Zero-Knowledge Proofs (Future Readiness)

Anticipated uses:
- **Consent proofs** for L3 hosted-AI calls that a specific policy (e.g., "no data of subject X shared") was honored, without disclosing the data.
- **Audit-verifier ZKPs** so external auditors can verify integrity of a batch without needing raw content.
- **Threshold-signing ZKPs** for Z0 root operations.

Architectural preparation:
- Signed artifacts include structured commitments (Merkle roots) so ZKPs over them can be generated later.
- No v0 implementation; wire format compatible with future ZKP additions.

## 11. Independent Architecture Review

### 11.1 Hidden Assumptions

| Assumption | Handling |
|---|---|
| SPIFFE-style workload identity is broadly deployable. | Yes today in K8s; software equivalents available for VPS; documented per topology in ARCH-16. |
| Ed25519 remains safe through v0/v1. | Yes classical horizon; hybrid path prepared for v1+. |
| Every engine can hold an HSM-backed key. | For roots, yes; for leaves, in-memory is acceptable. Documented boundaries. |
| WebAuthn browser support is universal for our operator profile. | Yes in 2026 for modern browsers; fallback to OIDC/TOTP for edge cases. |

### 11.2 SPOFs

| Finding | Response |
|---|---|
| **F-1.** *Z0 root private key is the ultimate SPOF.* | HSM-backed; multi-party procedural access; documented recovery ceremony; threshold cryptography on Future Readiness roadmap. |
| **F-2.** *Kernel intermediate CA is a SPOF for engine identity.* | Compromise runbook: revoke intermediate at Z0; reissue; force re-attestation; drilled yearly. |
| **F-3.** *Certificate lifetime clock skew renders identities invalid across the fleet.* | Monotonic clock with NTP anchor; alert on skew; lenient renewal window. |
| **F-4.** *KMS provider outage prevents signing.* | Multi-provider viable per ARCH-11; local short-lived cached signing keys for hot paths (audit chain uses local key); graceful degrade documented. |

### 11.3 Privilege Escalation

| Finding | Response |
|---|---|
| **F-5.** *A compromised engine presents another engine's DID.* | mTLS binds cert to key; forgery requires key theft; SVID keys are per-instance and rotated. Detected by attestation cross-checks. |
| **F-6.** *Attacker steals a leaf key from process memory.* | Leaf keys are short-lived (hours); rotation limits exposure; hardware-anchored options in Future Readiness path. |
| **F-7.** *Attacker replays an old audit signature to alter history.* | Signatures include monotonic sequence numbers + previous-hash link (Layer-A) + batch sequence (Layer-B); replay is detectable at verification. |
| **F-8.** *Attacker convinces a human to approve a break-glass with a spoofed request.* | 4-eyes approver sees signed request from the requester's principal identity; UI displays verified details; approver has an independent verification tool for high-risk grants. |

### 11.4 Trust-Boundary Violations

| Finding | Response |
|---|---|
| **F-9.** *Non-mTLS side channel opens between engines (metrics, debug).* | Policy: all inter-engine channels are mTLS. Telemetry Engine consumes on separately-scoped identities. SAST rule + integration test coverage. |
| **F-10.** *A dev tool exports raw cert material for debugging.* | Debug endpoints disabled in production builds; guarded by a build-time constant; SAST rule bans key material in logs. |

### 11.5 Bottlenecks

| Finding | Response |
|---|---|
| **F-11.** *Signature verification cost dominates hot paths.* | Ed25519 verify is ~30μs per signature on commodity hardware; batched verification for high-throughput sites (e.g., audit chain reads); caching valid-until-expiry per token. |
| **F-12.** *Cert renewal storm from many engines.* | Randomized renewal windows (jitter) + Kernel-side rate limits; documented sizing. |
| **F-13.** *NTP outage causes mass expiry.* | Grace window on TTL when NTP is unhealthy; alert; monotonic clocks used for internal comparisons. |

### 11.6 Supply Chain

| Finding | Response |
|---|---|
| **F-14.** *A crypto library dependency has a vulnerability.* | Small set of vendored libraries; hash-pinned; SCA continuous; a *cryptography-critical-path* subset gets extra review (ARCH-12). |
| **F-15.** *TLS terminator (proxy) mishandles cert validation.* | Prefer terminate-in-process for engine-to-engine; if a proxy is used, integration tests verify cert chain validation and cipher restrictions. |

### 11.7 AI-Specific Risks

| Finding | Response |
|---|---|
| **F-16.** *L3 provider is unable to attest its own compute.* | Provider adapter records "not-attested" attribute; policy for HR disallows non-attested compute; today's providers may not offer attestation — logged risk. |
| **F-17.** *Local model runtime tampered with; signs prompts with a stolen key.* | Model runtime has its own SVID; loading a tampered runtime fails attestation; runtime SVID is per-launch and short-lived; model weights hash-verified before load. |
| **F-18.** *Prompt/manifest signatures used to bypass Safety Layer.* | Safety Layer is the gate; it verifies signatures *and* runs its own validators (ARCH-14). Signature is a necessary, not sufficient, condition. |

### 11.8 Operational Risks

| Finding | Response |
|---|---|
| **F-19.** *Cert lifecycle management too complex to operate.* | Automated by design; single-command "attestation status" tool; runbooks; alerts. |
| **F-20.** *Rotation ceremonies for roots are error-prone.* | Documented, rehearsed, multi-party, video-recorded ceremonies; dry-run in staging; scripted actions where safe. |
| **F-21.** *Engineers accidentally commit private keys.* | Pre-commit hooks + secret scanning in CI; keys never leave HSM/KMS in production; dev environments use ephemeral test roots. |

## 12. Decisions

### D-09-1. SPIFFE-shape workload identity + X.509 SVIDs + Ed25519 baseline

- **Advantages.** Industry-standard shape; broad tooling; compatibility with SPIRE for customers who already run it; strong performance profile.
- **Disadvantages.** X.509 tooling has some historical footguns; SPIFFE is an evolving standard.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** *Positive* — Ed25519 verify is fast.
- **Operational Complexity.** *Moderate* — automated rotation is well-supported.
- **Maintainability.** *Positive* — standards align.
- **Scalability.** *Positive.*
- **Alternative Designs.** *(a) Macaroons-only.* Great for capability tokens; not standard for workload identity. Used inside as capability format, not as workload identity. *(b) Nostr-style DIDs.* Interesting but immature ecosystem. Rejected. *(c) Custom identity model.* Rejected; not-invented-here is a security risk in identity.
- **Reason.** SPIFFE + X.509 provides the best combination of standards conformance, tooling maturity, and future evolvability.

### D-09-2. Message signing beyond mTLS on durable artifacts

- **Advantages.** End-to-end integrity across intermediaries (bus, storage, exports); enables independent verification; audit history is verifiable without needing the original transport.
- **Disadvantages.** Extra signature bytes; some CPU cost.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** *Small.*
- **Operational Complexity.** *Moderate.*
- **Maintainability.** *Positive.*
- **Scalability.** *Positive.*
- **Alternatives.** *mTLS only.* Loses provenance once data crosses a bus or storage. Rejected for durable artifacts.
- **Reason.** Immutable Event Sourcing + Evidence Chain require it.

### D-09-3. Algorithm-agility built into every signature site

- **Advantages.** Future readiness for PQC without redesign; smooth migration.
- **Disadvantages.** Slight metadata overhead.
- **Security Impact.** *Strongly positive* long-term.
- **Performance Impact.** Negligible.
- **Operational Complexity.** *Moderate* — verifiers need to accept multiple algorithms.
- **Maintainability.** *Positive.*
- **Scalability.** N/A.
- **Alternatives.** *Fix Ed25519 forever.* Poor long-horizon; rejected.
- **Reason.** Constitutional constraint #12.

### D-09-4. Ceremony-driven root-signing, monthly-signed intermediate lifecycle

- **Advantages.** Bounds intermediate compromise exposure; forces rehearsal.
- **Disadvantages.** Ceremony logistics.
- **Security Impact.** *Strongly positive.*
- **Performance Impact.** N/A.
- **Operational Complexity.** *Higher* than a static PKI; but documented and rehearsed.
- **Maintainability.** *Positive* long-term.
- **Scalability.** N/A.
- **Alternatives.** *Long-lived intermediates.* Larger blast radius; rejected.
- **Reason.** Enterprise trust posture; matches regulatory expectations.

## 13. Open Questions

- Q-09-1. HSM/KMS strategy per topology (cloud KMS in cloud, YubiHSM for VPS, software HSM for air-gap dev). Resolved in ARCH-11.
- Q-09-2. Concrete PQC pilot timeline; hybrid signature format details. Resolved in ARCH-11.
- Q-09-3. Adoption timing for Confidential Compute pools for the Kernel and Audit Engine. Resolved in ARCH-16 / ARCH-18.
- Q-09-4. Passkey rollout timing (v1 vs. v1.x). Resolved in ARCH-10 / ARCH-18.

## 14. Change Log

- **0.1 (2026-07-10)** — Initial draft after independent architecture review.