Sovra Sovra

Core Concepts

Overview

Sovra uses several key concepts to enable federated sovereign key management.

Organization

An organization is an independent entity that runs its own Sovra control plane.

Examples:

Each organization has:

Customer Root Key (CRK)

The CRK is the cryptographic root of trust for an organization.

Properties:

Example:

# Generate CRK
sovra crk generate --org-id eth-zurich

Output:
  CRK created successfully
  Public key: sovra:crk:pub:abc123...
  
  Shares (store separately):
    Share 1/5: sovra:crk:share:1:xyz...
    Share 2/5: sovra:crk:share:2:def...
    Share 3/5: sovra:crk:share:3:ghi...
    Share 4/5: sovra:crk:share:4:jkl...
    Share 5/5: sovra:crk:share:5:mno...

Usage:

# Sign operation (requires 3 shares)
sovra workspace create \
  --crk-sign crk-shares.json \
  ...

Important: See CRK Management Guide for comprehensive information on:

Control Plane

The control plane is the central management system for an organization.

Components:

Deployment:

Single organization: One control plane per organization.

Federated organizations: Each org runs its own control plane, connected via mTLS.

Edge Node

An edge node is where cryptographic operations actually happen.

Components:

Deployment options:

One organization can have multiple edge nodes:

Organization A
├── Control Plane (Switzerland)
└── Edge Nodes
    ├── Node 1 (AWS eu-central-1)
    ├── Node 2 (AWS us-east-1)
    └── Node 3 (On-premises data center)

Federation

Federation is the connection between two or more organizations’ control planes.

Establishment:

  1. Generate federation certificates
  2. Exchange certificates (out-of-band)
  3. Sign with CRK
  4. Establish mTLS connection
  5. Exchange capabilities

Example:

ETH Zurich ↔ EPFL ↔ University of Geneva

Properties:

Workspace

A workspace is a shared cryptographic domain for multi-organization data sharing.

Components:

Example:

Workspace: cancer-research
├── Participants: [eth-zurich, epfl, ...]
├── DEK: Wrapped for each participant
├── Classification: CONFIDENTIAL
└── Purpose: "Oncology research collaboration"

Admission tiers:

Tier Requirement
CONFIDENTIAL Group membership (auto-admit)
SECRET Group membership + explicit admission
CRK-protected Explicit admission only

Operations:

# Any admitted participant can encrypt
sovra workspace encrypt --workspace cancer-research ...

# Any admitted participant can decrypt (subject to policies)
sovra workspace decrypt --workspace cancer-research ...

Audit: ALL participants see ALL operations.

Policy

Policies control access to keys and workspaces using OPA (Open Policy Agent).

Example policy:

package workspace.cancer_research

# Default deny
default allow = false

# Allow researchers during business hours
allow {
    input.role == "researcher"
    input.purpose == "analysis"
    is_business_hours(input.time)
}

is_business_hours(time) {
    # 08:00-18:00 CET
    hour := time.hour
    hour >= 8
    hour < 18
}

Policy levels:

Audit Log

Audit logs provide immutable record of all operations.

Properties:

Example audit event:

{
  "id": "audit-123456",
  "timestamp": "2026-01-29T14:30:00Z",
  "org": "eth-zurich",
  "workspace": "cancer-research",
  "operation": "decrypt",
  "actor": "researcher@ethz.ch",
  "purpose": "data analysis",
  "result": "success",
  "data_hash": "sha256:abc123..."
}

Queries:

# All operations in workspace
sovra audit query --workspace cancer-research

# Failed operations
sovra audit query --result error

# Specific user
sovra audit query --actor researcher@ethz.ch

Deployment Models

Connected Mode (CONFIDENTIAL)

Use case: Research, commercial

Characteristics:

Network:

Control Plane (Switzerland) ←→ Edge Nodes (Global)
          ↕
    Partner Control Planes

Air-Gap Mode (SECRET)

Use case: Military, intelligence

Characteristics:

Network:

[Offline Network]
Control Plane ← USB → Edge Nodes

Hybrid Mode

Use case: Multi-level security

Characteristics:

mTLS (Mutual TLS)

mTLS is how all Sovra components authenticate.

Certificate hierarchy:

Root CA (offline)
└── Intermediate CA (Vault PKI)
    ├── Control Plane Certs
    ├── Edge Node Certs
    └── Federation Certs

Properties:

Data Flow Example

Encryption Flow

1. Application requests encryption
   ↓
2. Control plane authenticates (mTLS)
   ↓
3. Policy engine checks authorization
   ↓
4. Edge node Vault encrypts with DEK
   ↓
5. Ciphertext returned to application
   ↓
6. Audit logged (all participants)

Cross-Org Decryption

1. Org B requests decryption
   ↓
2. Org B control plane checks local policy
   ↓
3. Request forwarded to Org A workspace Vault
   ↓
4. Org A validates Org B certificate
   ↓
5. Org A Vault decrypts with DEK
   ↓
6. Plaintext returned to Org B
   ↓
7. Audit logged (BOTH organizations)

Security Model

Zero-Knowledge

Control plane never sees:

Defense in Depth

Layer 1: Network (mTLS)
Layer 2: Authentication (CRK, certificates)
Layer 3: Authorization (OPA policies)
Layer 4: Encryption (AES-256, TLS 1.3)
Layer 5: Audit (immutable logs)
Layer 6: Monitoring (anomaly detection)