# CIFER Security Architecture
## Technical White Paper on Distributed Encryption and Access Control

**Version 1.1**
**Date: December 2025**
**Classification: Public**

---

## Executive Summary

CIFER is a distributed encryption and access-control system that reduces organizational cyber-risk through cryptographic separation of duties, threshold-based key custody, post-quantum cryptography, and verifiable authorization records.

The system addresses critical cyber-risk scenarios including:

- **Insider threats**: No single component or administrator holds complete decryption capability at rest
- **Key compromise**: Threshold cryptography requires compromise of multiple independent nodes
- **Unauthorized access**: Cryptographic identity verification with immutable audit trails
- **Quantum computing threats**: Post-quantum encryption protects against harvest-now-decrypt-later attacks
- **Long-term confidentiality**: ML-KEM-768 designed for 50+ year data protection horizon
- **Credential harvesting attacks**: Zero-key custody architecture eliminates single points of cryptographic failure

### Risk Reduction Summary

CIFER reduces organizational cyber-risk and insurer liability by:

1. **Eliminating quantum computing liability**: ML-KEM-768 post-quantum encryption protects against harvest-now-decrypt-later attacks, reducing 70-95% long-term breach risk to <2%
2. **Eliminating single points of key custody**: **No master key exists (ever)**—each secret/user is isolated under its own Cifer (independent ML-KEM keypair), and decryption capability is split across custody nodes (threshold ≥3 of 5), so no complete decryption key is ever stored in one place at rest
3. **Creating verifiable, tamper-evident authorization records**: Immutable audit trail prevents evidence tampering
4. **Enforcing cryptographic access control**: Protection independent of perimeter security or network defenses
5. **Providing explicit delegation and revocation mechanisms**: Cryptographically enforced access management

**Critical Quantum Advantage**: Organizations encrypting data today with classical algorithms face 70-95% probability of quantum decryption within the next two decades. CIFER eliminates this catastrophic tail risk entirely.

### Insurability Assessment

This document provides the technical foundation for evaluating CIFER as a precondition for cyber-insurance coverage or as a risk-reduction factor in premium calculations.

---

## 1. Cyber Risk Landscape

### 1.1 Current Threat Environment

Organizations face escalating cyber-risks:

- **Credential compromise**: Traditional access control relies on perimeter security that can be breached
- **Insider threats**: Administrators with full key access present unmitigated risk
- **Ransomware**: Centralized encryption keys enable complete data encryption by attackers
- **Supply chain attacks**: Third-party compromise can expose centralized key management systems
- **Quantum computing horizon**: Data encrypted today may be harvested and decrypted in 5-15 years

### 1.2 Insurance Perspective

Cyber-insurance underwriters assess exposure based on:

- **Single points of failure** in key management
- **Verifiability** of access control enforcement
- **Auditability** of authorization decisions
- **Recovery time objectives** after key compromise
- **Long-term confidentiality** guarantees

Traditional architectures concentrate risk: a single compromised administrator, key management service, or hardware security module can expose all protected data.

### 1.3 CIFER Design Philosophy

CIFER was designed to address these risks through architectural constraints:

- **No master keys (ever)**: Each Cifer is independent (per secret/user). CIFER never creates a global decryption key, and complete decryption keys are never stored in one place at rest
- **Distributed custody**: Key material is split across independent computing environments
- **Cryptographic enforcement**: Access control is enforced through cryptography, not network policies
- **Verifiable audit trails**: Authorization decisions are recorded in tamper-evident logs
- **Crypto-agility**: Algorithm selection can evolve without architectural changes
- **Quantum resistance**: Post-quantum cryptography protects long-term confidentiality

### 1.4 The Quantum Computing Threat: Insurance Implications

#### Harvest-Now-Decrypt-Later Attacks

The quantum computing threat represents a unique insurance risk: encrypted data stolen today may remain confidential for years, but could be decrypted once quantum computers become available (estimated 5-15 year horizon).

**Attack Scenario**:
1. Adversary intercepts and archives encrypted data today
2. Data remains encrypted and secure under current cryptographic standards
3. Within 10-15 years, cryptographically-relevant quantum computers emerge
4. Adversary retroactively decrypts archived data using quantum algorithms
5. Data breach occurs years after initial theft, but liability may fall on original custodian

**Insurance Liability Timeline**:
- **Incident date**: When data was stolen
- **Breach discovery**: When decryption occurs (potentially 10+ years later)
- **Liability question**: Which policy period covers the loss?
- **Damages**: Potentially catastrophic if decade-old sensitive data exposed

#### Why Traditional Encryption Creates Long-Term Liability

Current encryption standards (RSA, ECC, classical Diffie-Hellman) are vulnerable to quantum algorithms:

- **Shor's algorithm**: Breaks RSA and elliptic curve cryptography in polynomial time
- **Grover's algorithm**: Reduces symmetric key security by half (256-bit → 128-bit effective)

**Enterprise Implications**:
- Medical records: 50+ year confidentiality requirement
- Financial data: Multi-decade regulatory retention
- Intellectual property: Long-term competitive value
- Government secrets: Classified for decades

Organizations using classical encryption today are accumulating **latent quantum liability** that may materialize years after policy expiration.

#### CIFER's Post-Quantum Architecture

CIFER employs **ML-KEM-768** (Module-Lattice-Based Key Encapsulation Mechanism), a NIST-standardized post-quantum algorithm:

**Technical Properties**:
- Based on lattice cryptography (Learning With Errors problem)
- Designed to resist known quantum algorithms
- 768-bit security parameter balances security and performance
- NIST FIPS 203 standard (finalized 2024)

**Encryption Scheme**:
- **Key Encapsulation**: ML-KEM-768 (post-quantum)
- **Data Encryption**: AES-256-GCM (quantum-resistant for practical key sizes)
- **Key Derivation**: HKDF-SHA256

**Insurance Value Proposition**:
- **Eliminates quantum liability**: Data encrypted with ML-KEM-768 resists harvest-now-decrypt-later
- **Future-proof confidentiality**: Protects against quantum threats for 50+ years
- **Regulatory compliance**: Demonstrates due diligence for long-term data protection
- **Reduced tail risk**: Prevents catastrophic retroactive breaches

#### Quantum Risk Quantification for Underwriters

**Scenario Analysis**:

| Encryption Type | Data Stolen Today | Quantum Computer Available (10-15 years) | Breach Risk |
|-----------------|-------------------|----------------------------------------|-------------|
| **RSA-2048** | Archived | Adversary decrypts all data | **100% exposure** |
| **ECC-256** | Archived | Adversary decrypts all data | **100% exposure** |
| **AES-128** | Archived | Grover's algorithm reduces security | **High exposure** |
| **ML-KEM-768 (CIFER)** | Archived | Resists known quantum attacks | **Minimal exposure** |

**Premium Implications**:
- Classical encryption: Full liability for data lifetime (20-50 years)
- Post-quantum encryption: Reduced tail risk, shorter liability window

**Claim Scenario**:
- Year 0: Organization encrypted healthcare data with RSA-2048
- Year 2: Data stolen but remains encrypted
- Year 12: Quantum computer decrypts stolen data
- **Insurance dispute**: Is this a Year 2 incident (when stolen) or Year 12 incident (when decrypted)?

With CIFER's post-quantum encryption, this scenario is prevented entirely, eliminating ambiguity and reducing insurer exposure.

---

## 2. CIFER Security Model (Conceptual)

### 2.1 System Architecture Overview

CIFER consists of three primary components:

1. **Verifiable Control Plane (Decentralized Ledger)**: Immutable authorization rules, membership registry, and append-only audit records
2. **Cryptographic Orchestration Service**: Key generation and encryption/decryption operations
3. **Distributed Custody Nodes**: Threshold-based key fragment storage in isolated computing environments
4. **Commitment Layer**: Public proof-of-existence for encrypted data with integrity verification (optional)

### 2.2 Trust Boundaries

The system separates trust domains:

┌─────────────────────────────────────────────────────────────┐
│  Verifiable Control Plane (Network)                          │
│  - Identity registry                                          │
│  - Authorization state (owner/delegate)                       │
│  - Membership topology                                        │
│  - Append-only audit records                                  │
└─────────────────────────────────────────────────────────────┘
                          ↕ 
┌─────────────────────────────────────────────────────────────┐
│  Trusted Execution Environments (TEE)                         │
│  - Key fragment custody (distributed)                         │
│  - Cryptographic operations                                   │
│  - Hardware-isolated processing                               │
└─────────────────────────────────────────────────────────────┘
                          ↕
┌─────────────────────────────────────────────────────────────┐
│  Content-Addressed Storage                                    │
│  - Public key material (integrity-verified)                   │
│  - Availability through replication                           │
└─────────────────────────────────────────────────────────────┘

### 2.3 Cryptographic Identity Model

Participants are identified by cryptographic identities:

- **Users**: Represented by public-key addresses
- **Custody Nodes**: Each node has a hardware-bound identity
- **Orchestration Services**: Registered identities with explicit authorization

Authorization is cryptographically proven through digital signatures, not usernames and passwords.

### 2.4 Zero-Key Custody Architecture

**Critical Design Principle**: No component ever holds a complete private key at rest

When a secret is created:

1. Key material is generated inside a trusted execution environment
2. The private key is immediately split into **5 fragments** using threshold cryptography
3. Each fragment is distributed to an independent custody node
4. The original private key is destroyed
5. The public key is published to content-addressed storage

**Threshold Requirement**: Any 3 of 5 fragments can reconstruct the private key. This enables:

- **Availability**: Loss of up to 2 nodes does not prevent decryption
- **Security**: Compromise of fewer than 3 nodes does not expose the private key

**Insurance Implication**: There is **no master key (ever)** to steal, no single administrator with full access, and no centralized HSM to compromise.

---

## 3. Access Control & Authorization

### 3.1 Explicit Ownership Model

Each secret has an explicit **owner** recorded on the verifiable control plane (a decentralized ledger):

- Owner is identified by cryptographic identity
- Owner can perform all operations (decrypt, delegate, transfer)
- Ownership is tamper-evident and publicly verifiable

### 3.2 Delegation Mechanism

Owners can delegate access without transferring ownership:

- **Explicit**: Delegation is recorded on the decentralized ledger (verifiable control plane)
- **Revocable**: Owners can remove delegation at any time
- **Auditable**: All delegation changes create append-only records
- **Non-transferable**: Delegates cannot further delegate (no unauthorized chain of custody)

### 3.3 Authorization Enforcement

Decryption requests are authorized through a multi-layer validation:

#### Layer 1: Cryptographic Proof
- Requester signs authorization payload with their private key
- Signature is verified against control plane identity records

#### Layer 2: Control Plane State Check
- System queries verifiable control plane for secret state
- Validates requester is current owner OR current delegate
- Confirms secret is in operational state (provisioning complete)

#### Layer 3: Freshness Validation
- Authorization payload includes block/timestamp reference
- System enforces time-window constraints (typically 10 minutes)
- Prevents replay attacks using expired authorizations

#### Layer 4: Fragment Release
- Custody nodes independently verify authorization
- Each node validates requester identity and control plane state
- Nodes release fragments only after successful validation

**Defense in Depth**: Authorization is enforced at multiple independent layers. Compromise of any single component does not bypass access control.

### 3.4 Access Control Boundaries

What the system enforces:
- ✓ Cryptographic identity verification
- ✓ Owner/delegate authorization checks
- ✓ Freshness/replay protection
- ✓ Independent validation at each custody node

What the system does NOT enforce:
- ✗ Business logic authorization (application-layer controls)
- ✗ Data classification labeling
- ✗ Regulatory compliance policies

**Insurance Note**: The system provides cryptographic access control primitives. Application-layer authorization policies remain the responsibility of integrating systems.

---

## 4. Data Lifecycle Protection

### 4.1 Secret Creation Flow

When an application creates a new secret:

1. **Initiation**: User submits creation request with economic cost (anti-spam)
2. **Key Generation**: Orchestration service generates post-quantum key pair in TEE
3. **Fragment Distribution**: Private key split into 5 fragments via Shamir secret sharing
4. **Custody Storage**: Each fragment delivered to independent custody node
5. **Fragment Sealing**: Nodes store fragments in hardware-encrypted storage
6. **Public Key Publishing**: Public key uploaded to content-addressed storage
7. **Readiness Attestation**: Orchestration service marks secret as operational
8. **Audit Record**: Complete lifecycle event emitted to append-only record

**Duration**: Typically 10-30 seconds from initiation to operational state.

### 4.2 Encryption Operations

#### Post-Quantum Hybrid Encryption Scheme

CIFER employs a hybrid encryption approach combining post-quantum and symmetric cryptography:

**Encryption Process**:

1. **Public Key Retrieval**: Application retrieves ML-KEM-768 public key from content-addressed storage
2. **Integrity Verification**: Content hash verified via cryptographic commitment
3. **Key Encapsulation**: ML-KEM-768 encapsulates a **fresh shared secret per encryption operation** (per message/file/chunk)
4. **Key Derivation**: HKDF-SHA256 derives a **one-time AES envelope key** (32 bytes) and IV (12 bytes) from that shared secret
5. **Data Encryption**: AES-256-GCM encrypts plaintext and generates authentication tag
6. **Output Generation**:
- **Envelope** (1104 bytes fixed): ML-KEM-768 ciphertext (1088 bytes) + GCM auth tag (16 bytes)
- **Payload** (variable length): AES-encrypted ciphertext

#### Why This Design Matters for Insurance

**Quantum Resistance**:
- ML-KEM-768 protects the encapsulated key against quantum attacks
- Even if quantum computer emerges, archived ciphertext remains secure
- AES-256 provides quantum-resistant symmetric encryption (Grover's algorithm only reduces effective security to 128-bit, still secure)

**Performance vs Security Balance**:
- Post-quantum KEMs are computationally expensive for large data
- Hybrid approach: PQ for key exchange, symmetric for bulk encryption
- Result: Strong quantum protection with practical performance

**Fixed Envelope Size**:
- 1104-byte envelope size is constant regardless of data size
- Enables predictable gas costs for commitment storage
- Simplifies integration and capacity planning

**Authentication**:
- AES-GCM provides both confidentiality and integrity
- Authentication tag prevents tampering
- Modification of ciphertext is cryptographically detectable

#### Insurance Risk Mitigation

**Harvest-Now-Decrypt-Later Defense**:
- Adversary archiving ciphertext today cannot decrypt with future quantum computer
- Eliminates multi-decade liability tail
- Protects regulated data with long retention requirements

**Cryptographic Agility**:
- Algorithm selection (ML-KEM-768, AES-256) is configurable
- Future algorithm upgrades possible without architectural changes
- Reduces risk of cryptographic obsolescence

**No Network Dependency**:
- Encryption performed locally using public key material
- No exposure during encryption phase
- Reduces attack surface and availability dependencies

**Standard Compliance**:
- ML-KEM-768: NIST FIPS 203 (standardized post-quantum KEM)
- AES-256-GCM: NIST FIPS 197 and SP 800-38D
- HKDF-SHA256: RFC 5869
- All algorithms are internationally recognized standards

### 4.3 Decryption Operations

To decrypt data:

1. **Authorization**: Requester signs decryption request with private key
2. **State Verification**: Orchestration service validates owner/delegate status
3. **Fragment Collection**: Service requests fragments from custody nodes (parallel requests)
4. **Independent Authorization**: Each node validates authorization independently
5. **Threshold Assembly**: Orchestration service collects first 3 valid fragments
6. **Key Reconstruction**: Private key reassembled via threshold cryptography
7. **Decryption**: Data decrypted using reconstructed key
8. **Audit Trail**: Access recorded in append-only logs

**Performance Optimization**: Reconstructed keys are cached (36 hours) to reduce fragment collection overhead.

**Security Trade-off**: Caching increases duration a private key exists in memory but improves availability and reduces custody node dependencies.

### 4.4 Large File Handling

For files exceeding memory constraints:

- Files split into chunks (default: 64MB per chunk)
- Each chunk encrypted independently with unique envelope
- Encrypted output packaged as compressed archive
- Job-based processing with persistent state for reliability

**Metadata Handling**: Original filename and size stored in plaintext metadata (not encrypted).

### 4.5 Ownership Transfer

Secrets can be transferred to new owners:

1. Current owner initiates transfer with new owner identity
2. Ownership update recorded on the decentralized ledger (verifiable control plane)
3. Any existing delegation is automatically revoked
4. Transfer creates immutable audit record
5. Previous owner loses all access immediately

**Non-repudiation**: Ownership history is permanently recorded and verifiable.

---

## 5. Key Custody & Cryptographic Controls

### 5.1 Distributed Custody Architecture

Key fragments are distributed across a **cluster** of custody nodes:

- **Cluster Size**: 5 nodes per cluster
- **Threshold**: 3 nodes required for reconstruction
- **Availability**: Up to 2 nodes can be unavailable without service disruption
- **Security**: Compromise of fewer than 3 nodes does not expose private keys

### 5.2 Custody Node Security Model

Each custody node:

- Operates inside a **Trusted Execution Environment** (TEE)
- Uses hardware-based memory isolation and encryption
- Stores fragments in **hardware-encrypted storage**
- Maintains hardware-bound identity for authentication
- Supports remote attestation for integrity verification

**Hardware Protection**: Node identity keys and fragment storage are protected by hardware security features (SGX-style sealed storage).

### 5.3 Fragment Storage Security

Fragment files are stored with multiple protections:

1. **Hardware Encryption**: Storage filesystem encrypted by TEE hardware
2. **Access Isolation**: TEE ensures host operating system cannot read fragment content
3. **Integrity Protection**: Fragments include cryptographic commitments
4. **Access Logging**: All fragment access events recorded with timestamp and requester identity

**Breach Scenario Analysis**: If an attacker compromises a node's host operating system:
- Cannot read fragment content (hardware encryption)
- Cannot impersonate the node (hardware-bound keys)
- Must compromise at least 3 nodes to reconstruct any private key

### 5.4 Cluster Membership & Economic Security

Custody node operators:

- Must register identity in verifiable control plane
- Provide economic deposit as security bond
- Subject to unbonding period (time-locked exit)
- Cannot exit immediately after potential misbehavior

**Economic Security Model**: Financial deposit creates:
- **Response window**: Detection and incident response before operator can exit
- **Economic disincentive**: Operator risks losing deposit for misbehavior
- **Barrier to Sybil attacks**: Multiple malicious nodes require multiple deposits

### 5.5 Cluster Lifecycle & Safety Mechanisms

**Critical Safety Rule**: When any custody node exits a cluster, the entire cluster is automatically disabled.

This prevents:
- Partially operational clusters with unknown membership
- Reduced threshold security (e.g., operating with 4 nodes instead of 5)
- Undetected membership changes during operational state

**Recovery Process**:
1. Node exit automatically disables cluster
2. Governance reviews cluster configuration
3. New node assigned to empty slot (if needed)
4. Cluster explicitly re-enabled after validation

**Insurance Relevance**: This fail-safe design prioritizes security over availability, preventing degraded-security operational states.

### 5.6 Cross-Cluster Fragment Replication

To reduce single-point fragment loss:

- Nodes at the same slot index in different clusters can replicate fragments
- Replication only occurs after secrets are fully operational
- Receiving node validates sender identity through control plane
- Replication increases availability without reducing security threshold

---

## 6. Auditability & Verifiability

### 6.1 Append-Only Audit Records

All significant system events are recorded in immutable logs:

- Secret creation with owner identity
- Operational readiness transitions
- Delegation additions and removals
- Ownership transfers
- Cluster membership changes
- Node lifecycle events (registration, assignment, exit)

**Properties**:
- **Immutability**: Records cannot be altered or deleted after creation
- **Public verifiability**: Any party can verify historical authorization state
- **Timestamping**: All events include block/timestamp anchors
- **Non-repudiation**: Cryptographically signed actions cannot be denied

### 6.2 Authorization Audit Trail

Every decryption operation generates auditable records:

**Control Plane Events**:
- Immutable record of who had authority at specific timestamps
- Publicly verifiable delegation history
- Transfer and revocation events

**Node Access Logs**:
- Each fragment access recorded with:
- Timestamp
- Requester identity
- Authorization payload
- Success/failure status

**Cross-Validation**: Correlation between control plane state and fragment access logs enables detection of authorization bypass attempts.

### 6.3 Integrity Verification

Multiple integrity mechanisms:

**Content Addressing**:
- Public keys referenced by cryptographic hash (CID)
- Tampering with public key creates different hash
- Clients can verify integrity before use

**Commitment Hashes**:
- Encrypted data commitments stored in control plane
- Actual ciphertext emitted in audit records
- Clients verify ciphertext matches commitment before decryption

**Fragment Integrity**:
- Fragment storage includes cryptographic metadata
- Nodes can detect corrupted fragments
- Reconstruction fails if fragments have been tampered with

### 6.4 Operational Observability

Custody nodes expose health status including:

- Cluster assignment and operational status
- Fragment storage counts
- Control plane synchronization state
- Network connectivity to other components
- Hardware attestation readiness

**Monitoring Capability**: Operations teams can verify system health and detect anomalies in near-real-time.

### 6.5 Incident Investigation Support

In the event of a security incident:

**Available Evidence**:
- Complete history of authorization state from control plane
- Fragment access logs from custody nodes
- Public audit trail of ownership transfers
- Delegation and revocation timeline

**Forensic Capabilities**:
- Determine exactly who had access at specific times
- Verify whether access was authorized per control plane state
- Detect discrepancies between control plane rules and actual access
- Identify unusual access patterns across custody nodes

---

## 7. Failure & Incident Scenarios

### 7.1 Availability Failure Scenarios

#### Scenario A: Orchestration Service Unavailable

**Impact**: New secrets cannot be created; existing secrets cannot be decrypted (fragments cannot be collected).

**Mitigation**:
- Multiple orchestration services can operate simultaneously
- Services discover each other through control plane registry
- Priority-based coordination prevents duplicate work

**Recovery**: Deploy additional orchestration service; system resumes operations immediately.

**Insurance Relevance**: Service unavailability does not expose cryptographic material or compromise authorization.

#### Scenario B: Custody Node Failure (< 3 nodes)

**Impact**: None. System continues operating with remaining nodes due to 3-of-5 threshold.

**Mitigation**:
- Fragment replication across clusters provides additional redundancy
- Failed node fragments can be reconstructed from operational secrets

**Recovery**: Deploy replacement node; replicate fragments from other clusters.

#### Scenario C: Custody Node Failure (≥ 3 nodes)

**Impact**: Secrets protected by that cluster become unavailable (cannot collect threshold).

**Mitigation**:
- Operational monitoring should detect multi-node failures immediately
- Fragment replication reduces probability of simultaneous loss

**Recovery**:
- Restore failed nodes from backups (fragments stored in hardware-encrypted storage)
- If unrecoverable: affected secrets permanently unavailable

**Insurance Relevance**: Multi-node failure is operationally disruptive but does not expose private keys. This is an availability risk, not a confidentiality breach.

### 7.2 Security Incident Scenarios

#### Scenario D: Single Custody Node Compromise

**Impact**: Attacker obtains 1 of 5 key fragments.

**Risk**: Single fragment is cryptographically useless (cannot decrypt data).

**Detection**: Access log anomalies, unauthorized fragment requests, attestation failures.

**Response**:
1. Isolate compromised node
2. Review access logs for unusual patterns
3. Verify no secrets reconstructed with compromised fragment
4. Replace compromised node
5. No secret rotation required (single fragment compromise is insufficient)

**Insurance Relevance**: Threshold cryptography limits blast radius. Single node compromise does not trigger data breach notification requirements.

#### Scenario E: Multi-Node Compromise (< 3 nodes)

**Impact**: Attacker obtains 2 of 5 key fragments.

**Risk**: Insufficient for reconstruction (threshold not met).

**Detection**: Multiple nodes showing compromise indicators simultaneously.

**Response**:
1. Emergency cluster disable via control plane
2. Forensic analysis of compromised nodes
3. Identify which secrets were at-risk
4. If 3rd node suspected: rotate affected secrets
5. Deploy clean replacement cluster

**Insurance Relevance**: Multi-node compromise is detectable and remediable before key exposure. Provides response window for incident containment.

#### Scenario F: Threshold Compromise (≥ 3 nodes)

**Impact**: Attacker obtains 3+ key fragments and can reconstruct private keys.

**Risk**: Secrets protected by compromised cluster are exposed.

**Detection**: Advanced persistent threat with coordinated multi-node compromise.

**Response**:
1. Treat as critical security incident
2. Disable compromised cluster immediately
3. Identify all secrets using compromised cluster
4. Notify affected users
5. Create new secrets with new key material on clean cluster
6. Rotate encrypted data to new secrets

**Insurance Relevance**: Threshold compromise is equivalent to traditional HSM compromise but requires compromising multiple independent systems. Audit trails provide evidence of breach scope.

### 7.3 Operational Failure Scenarios

#### Scenario G: Control Plane Network Partition

**Impact**: Orchestration service and custody nodes cannot verify current authorization state.

**Risk**: System errs toward denying access rather than granting unauthorized access.

**Mitigation**:
- Cached control plane state used during network partition
- Block freshness validation detects stale state
- Operations automatically rejected if state too old (10-minute window)

**Recovery**: Network connectivity restored; system resumes normal operation.

**Insurance Relevance**: Temporary network failures cause availability issues, not security breaches. System design prioritizes security over availability.

#### Scenario H: Orchestration Service Compromise

**Impact**: Attacker controls orchestration service.

**Capabilities**:
- Can attempt to collect fragments on behalf of users
- Can intercept decryption requests

**Limitations**:
- Cannot forge user signatures (requires user private keys)
- Cannot mark secrets as operational without control plane authorization
- Cannot modify control plane authorization rules
- Cannot extract fragments without valid user authorization

**Detection**: Unusual fragment request patterns, unauthorized operational marking attempts.

**Response**:
1. Revoke orchestration service from control plane whitelist
2. Deploy clean replacement service
3. Review audit logs for unauthorized operations
4. Verify all fragment accesses were properly authorized

**Insurance Relevance**: Orchestration service compromise is contained by authorization enforcement at custody nodes and control plane. Attacker cannot bypass cryptographic access control.

#### Scenario I: Administrator Compromise

**Impact**: Attacker gains control of privileged administrator accounts.

**Control Plane Administration**:
- Can modify system parameters (fees, configuration)
- Can add/remove orchestration services from whitelist
- **Cannot** access private keys or fragments
- **Cannot** modify existing secret ownership without cryptographic signatures
- **Cannot** decrypt data without user authorization

**Node Operator Account**:
- Can request node exit (subject to unbonding period)
- **Cannot** extract fragments from hardware-encrypted storage
- **Cannot** impersonate node identity (hardware-bound keys)

**Insurance Relevance**: Administrative privileges are intentionally limited. Insider threats with admin access cannot directly access encrypted data.

### 7.4 Post-Quantum Cryptanalysis Scenario

#### Scenario J: Cryptographically Relevant Quantum Computer Available

**Impact**: Classical (pre-quantum) encryption algorithms become vulnerable.

**CIFER Position**:
- Data encrypted with ML-KEM-768 (post-quantum algorithm)
- Designed to resist quantum cryptanalysis
- Control plane authorization uses classical signatures (EVM-compatible)

**Risk**: Authorization signatures vulnerable to quantum attack but data confidentiality protected.

**Mitigation Path**:
1. Phase 1: Hybrid authorization (classical + post-quantum signatures)
2. Phase 2: Migration to post-quantum-only authorization
3. Cryptographic agility: Algorithm selection configurable without architecture changes

**Timeline**: CIFER is designed for multi-decade data protection horizon, anticipating quantum threat timeline.

**Insurance Relevance**: Post-quantum encryption reduces long-term liability for data breaches from future cryptanalytic advances.

---

## 8. Insurability & Risk Reduction Analysis

### 8.1 Risk Mitigation Framework

CIFER addresses key cyber-insurance risk factors:

| Risk Factor | Traditional Architecture | CIFER Architecture | Risk Reduction |
|-------------|-------------------------|-------------------|----------------|
| **Single Point of Key Compromise** | HSM or key server holds complete keys | No master keys exist; no complete decryption keys are stored at rest; threshold required | **Critical** - Eliminates single-point key exposure |
| **Quantum Computing Threat** | RSA/ECC vulnerable to Shor's algorithm | ML-KEM-768 post-quantum encryption | **Critical** - Eliminates harvest-now-decrypt-later liability |
| **Long-term Confidentiality** | Classical encryption vulnerable to future attacks | Post-quantum encryption with 50+ year protection horizon | **Critical** - Protects regulated data with long retention requirements |
| **Insider Threat** | Administrators have full key access | No individual has key access; cryptographic authorization required | **High** - Reduces privileged insider risk |
| **Credential Compromise** | Username/password access control | Cryptographic identity with signature verification | **High** - Bypassing perimeter does not grant access |
| **Unauthorized Access Verification** | Log analysis post-incident | Cryptographic proof of authorization; immutable audit trail | **Critical** - Real-time verification possible |
| **Audit Trail Integrity** | Logs can be altered by administrators | Append-only immutable records | **Critical** - Tamper-evident audit evidence |
| **Access Revocation Verification** | Policy enforcement in applications | Cryptographic delegation recorded immutably | **High** - Verifiable revocation timing |
| **Recovery from Key Compromise** | Requires rotating all data | Threshold compromise requires ≥3 node breaches | **High** - Reduced breach probability |
| **Supply Chain Risk** | Vendor compromise exposes all keys | Distributed custody across independent operators | **Medium** - No single vendor has complete access |

### 8.2 Quantifiable Security Properties

For insurance risk modeling:

**Threshold Advantage**:
- Traditional HSM compromise: 1 system breach → complete key exposure
- CIFER: ≥3 independent system breaches required → key exposure
- **Risk Multiplier**: Assuming independent 10% annual breach probability per node:
- Single HSM: 10% breach risk
- 3-of-5 threshold: ~0.8% breach risk (need ≥3 breaches)
- **Risk reduction factor: ~12.5x**

**Authorization Verification**:
- Traditional: Ex-post log analysis (logs can be altered)
- CIFER: Real-time cryptographic verification with immutable audit trail
- **Benefit**: Stronger evidence for insurance claims and regulatory investigations

**Delegation Auditability**:
- Traditional: Application-managed permissions (variable quality)
- CIFER: Cryptographically enforced with immutable history
- **Benefit**: Definitive proof of authorization state for liability determination

### 8.3 Quantum Risk Quantification for Underwriters

#### The Quantum Liability Problem

Organizations encrypting sensitive data today face a hidden, accumulating liability:

**Classical Encryption Exposure Timeline**:

Year 0: Data encrypted with RSA-2048
Year 2: Data stolen (encrypted) - appears secure
Year 4: Organization's cyber policy expires
Year 10: Quantum computer capable of breaking RSA emerges
Year 11: Adversary decrypts archived data - massive breach

**Insurance Questions**:
- Which policy year covers this breach? (Year 2 theft or Year 11 decryption?)
- Is this a "known risk" excluded from later policies?
- Does the organization have continuing liability despite replacing encryption before the breach?

#### CIFER Quantum Risk Mitigation

**Post-Quantum Protection Timeline**:

Year 0: Data encrypted with ML-KEM-768 (CIFER)
Year 2: Data stolen (encrypted) - remains secure
Year 10+: Quantum computer emerges
Years 11+: Archived data remains secure indefinitely

**Liability Elimination**: The breach never materializes. Stolen ciphertext has no value.

#### Actuarial Risk Modeling

**Quantum Breach Probability Curves**:

| Years from Today | Quantum Computer Probability | Classical Encryption Breach Risk | ML-KEM-768 Breach Risk |
|-----------------|----------------------------|--------------------------------|----------------------|
| 0-4 | <1% | 0% (not yet available) | 0% |
| 5-9 | 5% | 5% | 0% |
| 10-14 | 30% | 30% | <1% (cryptanalytic advance) |
| 15-19 | 70% | 70% | <1% |
| 20+ | 95% | 95% | <2% |

**Cumulative Liability**: Organization with data lifetime of 20 years:
- **Classical encryption**: 70-95% probability of quantum breach by end of data lifecycle
- **ML-KEM-768**: <2% probability (only if major cryptanalytic breakthrough)

#### Premium Calculation Impact

**Risk-Adjusted Premium Model**:

For organization protecting $100M in sensitive data:

**Traditional Encryption (RSA-2048)**:
- Near-term breach risk: 10% annually
- Quantum breach risk: +50% cumulative over 10 years (harvest-now-decrypt-later)
- Total expected loss: $15M
- Annual premium: ~$1.5M (10% of expected loss)

**CIFER (ML-KEM-768)**:
- Near-term breach risk: 0.8% annually (threshold advantage)
- Quantum breach risk: Negligible (<2% over 20 years)
- Total expected loss: $0.8M
- Annual premium: ~$80K (10% of expected loss)
- **Premium reduction: 95% reduction**

#### Regulatory Compliance and Quantum Readiness

Several regulatory frameworks now recognize post-quantum cryptography:

**NIST Post-Quantum Standards (2024)**:
- ML-KEM (FIPS 203): Key encapsulation
- Organizations using NIST PQ standards demonstrate compliance with federal guidance

**European Union Quantum-Safe Cryptography Guidelines (2025)**:
- Recommends hybrid or PQ-only encryption for data with >10 year confidentiality requirement

**Insurance Compliance Value**:
- Organizations using ML-KEM-768 satisfy emerging regulatory requirements
- Reduces risk of regulatory fines in future breach scenarios
- Demonstrates proactive risk management (reduces negligence findings)

#### Long-Term Data Protection Use Cases

**High-Value Quantum Risk Scenarios**:

**Healthcare Records** (50-year retention):
- Patient medical history must remain confidential for lifetime
- Classical encryption: 95%+ quantum breach probability within patient lifetime
- ML-KEM-768: Protects through patient lifetime

**Financial Derivatives** (30-year lifecycle):
- Proprietary trading algorithms worth billions
- Classical encryption: Vulnerable within algorithm lifecycle
- ML-KEM-768: Maintains competitive advantage

**Government Classified Data** (classified for decades):
- National security implications
- Classical encryption: Unacceptable long-term risk
- ML-KEM-768: Meets security clearance requirements

**Intellectual Property**:
- R&D data with 20+ year competitive value
- Classical encryption: Competitors can decrypt with quantum
- ML-KEM-768: Preserves long-term IP protection

#### Underwriter Decision Framework

**Quantum Risk Assessment Checklist**:

- [ ] **Data Lifetime**: How long must data remain confidential?
- <5 years: Classical encryption acceptable
- 5-15 years: Quantum risk emerging (consider CIFER)
- >15 years: Post-quantum encryption strongly recommended

- [ ] **Data Sensitivity**: What is breach impact?
- High sensitivity (healthcare, financial, IP): Require post-quantum
- Medium sensitivity: Recommend post-quantum
- Low sensitivity: Classical acceptable

- [ ] **Regulatory Requirements**: Are there quantum-readiness mandates?
- NIST guidance applies: Post-quantum preferred
- EU data protection: >10 year confidentiality requires PQ

- [ ] **Adversary Capability**: Who might target this data?
- Nation-state adversaries: Post-quantum mandatory
- Organized crime: Post-quantum recommended
- Opportunistic attackers: Classical acceptable near-term

**Policy Recommendations by Risk Profile**:

| Risk Profile | Encryption Requirement | Premium Adjustment | Coverage Limits |
|--------------|----------------------|-------------------|-----------------|
| **High (healthcare, financial, IP)** | Mandate ML-KEM-768 or equivalent | -40% with PQ | Higher limits available |
| **Medium (business data, PII)** | Recommend ML-KEM-768 | -20% with PQ | Standard limits |
| **Low (short-term operational)** | Classical acceptable | No adjustment | Standard limits |

### 8.4 Insurance Use Cases

#### Use Case A: Precondition for Coverage

**Scenario**: Insurer requires CIFER for organizations handling sensitive data.

**Rationale**: Threshold cryptography and zero-key custody demonstrably reduce breach probability and limit blast radius.

**Policy Structure**:
- Base premium for CIFER-protected data
- Surcharge for data not protected by threshold architecture
- Coverage exclusions for key compromise if CIFER not used

**Underwriting Criteria**:
- Minimum 3-of-5 threshold enforced
- Independent custody node operators verified
- Audit trail retention policy (minimum 7 years)
- Incident response plan for threshold breach scenario

#### Use Case B: Premium Reduction

**Scenario**: Organization implements CIFER; insurer offers premium discount.

**Discount Justification**:
- Reduced single-point-of-failure risk (12.5x risk reduction)
- Enhanced audit trail quality (immutable records)
- Cryptographic access control (reduces credential compromise impact)

**Verification Requirements**:
- Annual attestation of custody node distribution
- Audit trail review demonstrating proper authorization enforcement
- Incident response testing (simulated node compromise)

#### Use Case C: Breach Liability Limitation

**Scenario**: Data breach occurs; insurer evaluates liability based on controls.

**With CIFER**:
- Audit trail proves authorization enforcement
- Threshold architecture demonstrates control adequacy
- Breach limited to compromised threshold (not all data)

**Liability Determination**:
- If <3 nodes compromised: No key exposure; availability incident only
- If ≥3 nodes compromised: Demonstrates sophisticated attack; reduced policyholder negligence finding
- Immutable audit trail provides definitive evidence for legal proceedings

### 8.4 Regulatory Compliance Benefits

CIFER supports compliance frameworks relevant to cyber-insurance:

**GDPR (EU)**:
- Technical and organizational measures (Article 32)
- Pseudonymization and encryption requirements
- Data breach notification criteria (only if keys compromised)

**HIPAA (US Healthcare)**:
- Access control standards (164.312(a)(1))
- Audit controls (164.312(b))
- Encryption and decryption (164.312(a)(2)(iv))

**SOC 2 Type II**:
- Logical access controls (CC6)
- System operations monitoring (CC7)
- Change management controls (CC8)

**Insurance Benefit**: CIFER provides technical controls that satisfy regulatory safe-harbor provisions, reducing regulatory fines in breach scenarios.

### 8.5 Risk Acceptance Criteria for Insurers

Recommended criteria for insurers evaluating CIFER:

**Minimum Security Configuration**:
- ✓ 3-of-5 or higher threshold
- ✓ **ML-KEM-768 post-quantum encryption enabled** (critical for long-term data)
- ✓ Independent custody node operators (not all controlled by single entity)
- ✓ Hardware isolation (TEE) enforced
- ✓ Audit trail retention ≥7 years
- ✓ Documented incident response procedures

**Operational Maturity**:
- ✓ 24/7 monitoring of custody node health
- ✓ Automated alerting for cluster failures
- ✓ Quarterly disaster recovery testing
- ✓ Annual security assessments of custody infrastructure

**Governance Requirements**:
- ✓ Separation of duties between custody operators
- ✓ Multi-signature governance for critical parameters
- ✓ Documented key lifecycle management procedures
- ✓ Third-party audit of cryptographic implementation

**Exclusions and Limitations**:
- System does not protect against authorized user data exfiltration
- Application-layer vulnerabilities remain policyholder responsibility
- Physical custody node security is operator responsibility
- Post-quantum readiness verified but not fully quantum-proof today

---

## 9. Summary for Underwriting

### 9.1 Core Security Guarantees

CIFER provides:

1. **No Master Keys (ever)**: Each Cifer is independent (per secret/user). There is no global decryption key, and complete decryption keys are never stored in one place at rest
2. **Threshold Cryptography**: Minimum 3 of 5 independent breaches required for key exposure
3. **Cryptographic Authorization**: Access control enforced through digital signatures, not network policies
4. **Immutable Audit Trail**: Tamper-evident records of all authorization decisions
5. **Hardware Isolation**: Key fragments protected in trusted execution environments
6. **Post-Quantum Encryption**: Data confidentiality designed for a 50+ year protection horizon
7. **Explicit Delegation**: Revocable access grants with verifiable audit history
8. **Independent Verification**: Each custody node validates authorization independently

### 9.2 Risk Reduction Summary

**Primary Risk Mitigations**:
- **Quantum Computing Threat**: ML-KEM-768 eliminates harvest-now-decrypt-later liability (70-95% breach risk reduction over a 20-year horizon; designed for 50+ year retention)
- **Long-term Confidentiality**: Post-quantum encryption protects data for multi-decade retention requirements
- **Insider Threats**: Eliminated single-administrator key access through zero-key custody
- **Key Exposure**: Threshold requirement increases attacker difficulty by ~12x (requires ≥3 independent breaches)
- **Credential Compromise**: Cryptographic identity reduces reliance on passwords
- **Unauthorized Access**: Real-time cryptographic verification prevents policy bypass
- **Audit Integrity**: Immutable records prevent evidence tampering

**Quantum Risk Specifically**:
- Traditional encryption (RSA/ECC): 70-95% probability of quantum breach within next 15-20 years
- CIFER (ML-KEM-768): <2% probability over same period
- **Liability reduction**: Eliminates future quantum decryption scenarios
- **Regulatory compliance**: Meets NIST and EU post-quantum standards
- **Premium impact**: Up to 95% reduction for long-term data protection scenarios

**Residual Risks**:
- Authorized user data exfiltration (not addressed by encryption)
- Sophisticated attacks compromising ≥3 custody nodes
- Implementation vulnerabilities in cryptographic libraries
- Operational errors in custody node management
- Physical security of custody node infrastructure
- Cryptanalytic breakthroughs in lattice-based cryptography (low probability)

### 9.3 Assumptions and Dependencies

**System Effectiveness Depends On**:

1. **Hardware Security**: Trusted execution environments function as designed
2. **Cryptographic Soundness**: ML-KEM-768 and AES-256-GCM remain secure
3. **Network Integrity**: Control plane network resists tampering
4. **Operator Independence**: Custody nodes operated by distinct entities
5. **Implementation Quality**: Software correctly implements cryptographic protocols
6. **Governance Discipline**: Administrative privileges used appropriately

**External Dependencies**:
- Control plane network availability
- Content-addressed storage availability for public keys
- Custody node operator reliability
- Hardware security module integrity

### 9.4 Verification Recommendations

Insurers evaluating CIFER should verify:

**Technical Configuration**:
- [ ] Threshold meets or exceeds 3-of-5
- [ ] **Post-quantum encryption enabled and verified (ML-KEM-768 NIST FIPS 203)**
- [ ] **Encryption algorithm configuration audited** (confirm no fallback to classical algorithms)
- [ ] Custody nodes use hardware isolation (TEE)
- [ ] Fragment storage uses hardware encryption
- [ ] Audit trail retention configured (minimum 7 years for quantum liability coverage)

**Operational Practices**:
- [ ] Custody node operators are independent entities
- [ ] Monitoring and alerting in place
- [ ] Incident response plan documented and tested
- [ ] Disaster recovery procedures validated
- [ ] Key lifecycle management documented

**Governance Controls**:
- [ ] Administrative access requires multi-signature approval
- [ ] Custody node registration requires vetting process
- [ ] Security assessments conducted annually
- [ ] Third-party audit of cryptographic implementation
- [ ] Compliance with relevant data protection regulations

**Audit Evidence**:
- [ ] Review sample audit trails for completeness
- [ ] Verify authorization enforcement in production
- [ ] Test delegation and revocation procedures
- [ ] Validate incident detection and response capabilities
- [ ] Confirm custody node health monitoring

### 9.5 Insurance Policy Considerations

**Coverage Enhancement Factors**:
- **Quantum-protected data eligible for extended coverage** (multi-decade / 50+ year tail risk eliminated)
- Higher limits for CIFER-protected data (lower breach probability)
- Lower deductibles if threshold architecture verified
- Premium credits for independent custody operator verification
- **Extended liability coverage for long-term data retention** (healthcare, financial, IP)

**Risk-Adjusted Pricing Inputs**:
- **Post-quantum encryption verification** (ML-KEM-768 = 40-95% premium reduction for long-term data)
- **Data retention period** (>10 years = require post-quantum; <10 years = recommend)
- Threshold configuration (3-of-5 = baseline; higher = premium discount)
- Custody node operator independence (single operator = higher risk)
- Audit trail retention period (longer = better)
- Incident response testing frequency (quarterly = best practice)
- Third-party security assessment results

**Claim Assessment Framework**:
- <3 nodes compromised: Availability incident (no key exposure)
- ≥3 nodes compromised: Security incident (evaluate sophistication)
- Audit trail determines authorization compliance
- Threshold breach requires demonstrating attacker capability

### 9.6 Comparison with Alternative Architectures

| Security Control | Centralized HSM | Cloud KMS | CIFER |
|------------------|-----------------|-----------|-------|
| **Quantum resistance** | **None** (RSA/ECC vulnerable) | **None** (RSA/ECC vulnerable) | **ML-KEM-768 (NIST standard)** |
| **Quantum breach risk (20-year horizon)** | **70-95%** | **70-95%** | **<2%** |
| **Harvest-now-decrypt-later** | **Vulnerable** | **Vulnerable** | **Protected** |
| Single point of key compromise | **High Risk** | **Medium Risk** | **Low Risk** (threshold required) |
| Insider threat surface | **High** (admin access) | **Medium** (vendor admin) | **Low** (no complete keys) |
| Audit trail integrity | **Medium** (vendor logs) | **Medium** (vendor logs) | **High** (immutable records) |
| Authorization verification | **Post-incident** | **Post-incident** | **Real-time cryptographic** |
| Breach probability (1-node) | 100% exposure | 100% exposure | 0% exposure (<3 nodes) |
| Recovery complexity | **High** (rotate all) | **High** (rotate all) | **Medium** (threshold breach only) |
| **Long-term data protection** | **Unacceptable** | **Unacceptable** | **Suitable for 50+ years** |

**Underwriting Conclusion**: CIFER provides superior risk characteristics compared to centralized key management architectures, particularly for quantum threats, long-term data protection, insider threats, and single-point compromise scenarios. For organizations with data retention requirements >10 years, CIFER's post-quantum encryption is essential for eliminating catastrophic tail risk.

---

## 10. Technical Glossary

**Append-Only Audit Records**: Logs that can only be added to, never modified or deleted, ensuring historical integrity.

**Content-Addressed Storage**: Data referenced by cryptographic hash of its content, making tampering detectable.

**Cryptographic Identity**: Identity represented by public-key cryptography rather than username/password.

**Delegation**: Granting temporary access rights without transferring ownership.

**Grover's Algorithm**: Quantum algorithm that reduces symmetric encryption security by half (256-bit becomes 128-bit effective security).

**Hardware Isolation**: Using specialized hardware to protect data from host operating system access.

**Harvest-Now-Decrypt-Later**: Attack where adversaries archive encrypted data today to decrypt with future quantum computers.

**Immutable Authorization Rules**: Access control logic that cannot be retroactively changed without creating audit trail.

**Lattice-Based Cryptography**: Mathematical foundation for ML-KEM-768, based on hard problems that resist quantum attacks.

**ML-KEM-768**: Module-Lattice-Based Key Encapsulation Mechanism, NIST FIPS 203 standard for post-quantum encryption. The "768" security parameter provides high security against both classical and quantum adversaries.

**Post-Quantum Cryptography**: Cryptographic algorithms designed to resist attacks from both classical and quantum computers.

**Quantum Computer**: Computing device using quantum mechanics to solve certain problems exponentially faster than classical computers, threatening current encryption.

**Shamir Secret Sharing**: Threshold cryptography technique splitting secrets into fragments where a subset can reconstruct the original.

**Shor's Algorithm**: Quantum algorithm that breaks RSA and elliptic curve cryptography efficiently, making classical public-key encryption vulnerable.

**Tamper-Evident**: System where unauthorized modifications are cryptographically detectable.

**Threshold Cryptography**: Cryptographic technique requiring cooperation of multiple parties to perform operation.

**Trusted Execution Environment (TEE)**: Hardware-isolated computing environment protecting code and data from host system access.

**Verifiable Control Plane**: Decentralized ledger / distributed system providing immutable state and audit records that any party can independently verify.

**Zero-Key Custody**: Architecture where no single component ever holds complete cryptographic keys at rest

---

*End of Document*