Key Concepts - Post-Quantum Cryptography & ANKASecure

This document serves as the entry point to understanding ANKASecure and Post-Quantum Cryptography. It introduces fundamental concepts and provides learning paths based on your role.

Table of Contents

1. The Five Pillars of Crypto Agility Orchestration
2. Learning Paths by Audience
3. Post-Quantum Cryptography Fundamentals
4. Why PQC Matters Now
5. Core PQC Algorithms
6. Multi-Tenancy Concepts
7. Crypto-Agility Principles
8. Key Management Concepts
9. ANKASecure Terminology

The Five Pillars of Crypto Agility Orchestration

ANKASecure is built on five foundational pillars that enable enterprise-grade cryptographic evolution. Understanding these pillars is essential to grasping how the platform solves the post-quantum challenge.

Key Insight: These pillars work together as an Crypto Agility Orchestration platform. Applications declare cryptographic intent ("encrypt with key X"), and the platform handles algorithm selection, policy enforcement, lifecycle management, and compliance.

Deep Dive: the CAPA framework develops each of these five pillars in its own page, with the posture model built on top of them.

Learning Paths by Audience

Choose the learning path that matches your role:

Executive / Business Leader

Goal: Understand strategic value, deployment options, and business impact

1. Start here: This document (Key Concepts) - understand the 5 Pillars
2. CAPA framework - strategic framework
3. Cryptographic Maturity Model - where an organisation stands, and what moves it
4. Deployment Organization Model - governance hierarchy

Solution Architect / Enterprise Architect

Goal: Design integration strategy, select deployment model, plan migration

1. Start here: This document (Key Concepts)
2. The Cryptographic Control Plane - the central idea
3. CAPA framework - 5 Pillars framework
4. Deployment Organization Model - hierarchy and governance
5. Tenant Isolation Model - technical isolation
6. Reference Scenarios - the model applied end to end

Developer / Integration Engineer

Goal: Integrate applications, use SDK/CLI, implement crypto operations

1. Start here: This document (Key Concepts)
2. SDK Quick Start - hands-on integration
3. SDK Overview - Java SDK usage
4. CLI Overview - command-line tools
5. Developer Hub - the operation-by-operation API reference
6. Error Reference - what each failure means and what to change

Security / Compliance Professional

Goal: Validate security posture, configure policies, ensure compliance

1. Start here: This document (Key Concepts)
2. Tenant Isolation Model - security boundaries
3. Envelope Encryption Pattern - where key material sits, and what never leaves custody
4. Algorithm Catalog - 130 algorithms (89 simple + 41 composite)
5. Regulatory Compliance Matrix - standards mapping

Post-Quantum Cryptography Fundamentals

What is Post-Quantum Cryptography?

Post-Quantum Cryptography (PQC) refers to cryptographic algorithms that are secure against attacks from both classical and quantum computers. Traditional cryptographic algorithms like RSA and Elliptic Curve Cryptography (ECC) are vulnerable to attacks by sufficiently powerful quantum computers using algorithms such as Shor's algorithm.

The Quantum Threat

Quantum Computing Timeline:

• 2030: NIST deadline for US federal agencies to transition to PQC
• 2025-2035: Quantum computers expected to break current encryption
• "Harvest Now, Decrypt Later": Adversaries are already collecting encrypted data to decrypt once quantum computers become available

NIST PQC Standardization

In 2024, NIST published the first set of Post-Quantum Cryptography standards:

• FIPS 203 (ML-KEM): Key Encapsulation Mechanism for encryption
• FIPS 204 (ML-DSA): Digital Signature Algorithm
• FIPS 205 (SLH-DSA): Stateless Hash-Based Digital Signature Algorithm

Why PQC Matters Now

Regulatory Compliance

• NSA CNSA 2.0: Mandate for PQC adoption by 2030
• Executive Order 14028: Improving the Nation's Cybersecurity
• NIST SP 800-208: Recommendations for transitioning to PQC
• European NIS2 Directive: Enhanced security requirements

Business Impact

• Data Lifespan: Data with 15+ year confidentiality requirements must be protected now
• Supply Chain: Compliance requirements flowing down to vendors
• Competitive Advantage: Early adopters gain market differentiation
• Cost of Migration: Delayed migration becomes exponentially more expensive

Technical Challenges

• Algorithm Migration: Cannot simply swap algorithms without code changes (traditional approach)
• Key Management: PQC keys are significantly larger than classical keys
• Performance: Some PQC algorithms are slower than classical equivalents
• Compatibility: Need to support hybrid classical+PQC during transition

Core PQC Algorithms

Key Encapsulation Mechanisms (KEM)

ML-KEM (FIPS 203) - formerly known as Kyber:

• Purpose: Key exchange and encryption
• Security Levels:
• ML-KEM-512: Equivalent to AES-128
• ML-KEM-768: Equivalent to AES-192 (RECOMMENDED)

• ML-KEM-1024: Equivalent to AES-256

• Use Case: Encrypting data, establishing session keys

Digital Signature Algorithms

ML-DSA (FIPS 204) - formerly known as Dilithium:

• Purpose: Digital signatures and authentication
• Security Levels:
• ML-DSA-44: Equivalent to AES-128
• ML-DSA-65: Equivalent to AES-192 (RECOMMENDED)

• ML-DSA-87: Equivalent to AES-256

• Use Case: Signing documents, code signing, authentication

SLH-DSA (FIPS 205) - formerly known as SPHINCS+:

• Purpose: Stateless hash-based digital signatures
• Advantage: Based on hash functions (very conservative security assumption)
• Use Case: Long-term signatures, high-security scenarios

FALCON:

• Purpose: Compact digital signatures
• Advantage: Smallest signature size among lattice-based algorithms
• Variants: FALCON-512, FALCON-1024
• Use Case: Resource-constrained environments, PKI certificates

Hybrid Encryption

Hybrid Mode: Combines classical and PQC algorithms for defense-in-depth:

• RSA + ML-KEM: Classical and quantum-resistant encryption
• ECDSA + ML-DSA: Classical and quantum-resistant signatures
• Rationale: Protection even if one algorithm is broken

Multi-Tenancy Concepts

What is Multi-Tenancy?

Multi-tenancy is an architecture where a single instance of software serves multiple customers (tenants) while keeping their data completely isolated.

AnkaSecure Multi-Tenant Architecture

Tenant Isolation:

• Separate Keystores: Each tenant has isolated cryptographic key storage
• Policy Boundaries: Per-tenant security policies and algorithm availability
• Usage Tracking: Independent license and usage tracking per tenant
• Authentication: JWT tokens with tenant claims for access control

Deployment Models:

• SaaS: Multiple tenants share infrastructure (subdomain isolation)
• Enterprise: Single tenant with dedicated deployment
• Hybrid: Mix of shared and dedicated resources

Tenant Hierarchy

Deployment (Global Policies)
  └── Tenant 1 (Tenant-specific Policies)
       ├── User A
       ├── Application A
       └── Keys/Keystores
  └── Tenant 2 (Tenant-specific Policies)
       ├── User B
       ├── Application B
       └── Keys/Keystores

Crypto-Agility Principles

What is Crypto-Agility?

Crypto-agility is the ability to rapidly change cryptographic algorithms without modifying application code. This is critical for:

• Algorithm Migration: Moving from RSA to ML-KEM
• Security Upgrades: Responding to newly discovered vulnerabilities
• Compliance: Meeting evolving regulatory requirements
• Future-Proofing: Preparing for post-quantum threats

Traditional vs. Crypto-Agile Approach

Traditional Approach (Crypto-Rigid):

Application Code → Hardcoded Algorithm → Data
Problem: Changing algorithm requires code changes everywhere

Crypto-Agile Approach (AnkaSecure):

Application Code → Policy-Driven API → Algorithm Abstraction → Data
Benefit: Change algorithm via policy without code changes

AnkaSecure Crypto-Agility Features

Algorithm Abstraction:

• Applications reference keys by alias (kid), not algorithm
• Platform selects algorithm based on policies
• Re-encryption/re-signing without plaintext exposure

Policy-Driven Selection:

• Algorithm Availability Policy: Which algorithms are allowed
• Algorithm Rotation Policy: When to migrate to new algorithms
• Key Lifecycle Policy: When keys expire and rotate

Zero-Code Migration:

• Re-encrypt from RSA to ML-KEM without decrypting to plaintext
• Re-sign from ECDSA to ML-DSA without exposing data
• Application code remains unchanged

Key Management Concepts

Key Lifecycle

Key States:

1. Generated: Key created and ready for use
2. Active: Key in normal operation
3. Rotated: New key generated, old key transitioning out
4. Deprecated: Old key maintained for decryption only (cannot encrypt)
5. Expired: Key no longer usable, retained for compliance/audit
6. Archived: Key moved to cold storage

Key Types

Symmetric Keys:

• AES: 128, 192, 256-bit keys for encryption
• Use Case: Bulk data encryption, session encryption

Asymmetric Keys:

• Public Key: Can be distributed freely, used for encryption/verification
• Private Key: Must be kept secret, used for decryption/signing
• Use Case: Key exchange, digital signatures, authentication

Key Rotation

Why Rotate Keys?

• Limit Exposure: Reduce data at risk if key is compromised
• Compliance: Regulatory requirements for periodic rotation
• Crypto-Agility: Migrate to stronger algorithms

Rotation Strategies:

• Time-Based: Rotate every N days/months
• Usage-Based: Rotate after N operations
• Event-Based: Rotate after security incident
• Algorithm Migration: Rotate to upgrade algorithm

Hardware Security Modules (HSM)

HSM Integration:

• Key Protection: Private keys never leave HSM
• Envelope Encryption: Data encrypted with KEK (Key Encryption Key) stored in HSM
• FIPS 140 validation: comes from the hardware HSM vendor (Thales Luna, AWS CloudHSM, nShield each hold their own CMVP certificate); SoftHSM, used in dev/test, is not validated, and the platform software itself is not FIPS 140 validated
• Supported Providers: SoftHSM, Thales Luna, AWS CloudHSM, nShield

AnkaSecure Terminology

Core Concepts

KID (Key Identifier):

• Unique identifier for a cryptographic key (e.g., 12345678-1234-1234-1234-123456789abc)
• Used to reference keys in API calls
• Internally mapped to tenant and algorithm via UUID system

Tenant:

• Isolated customer environment with separate keystores and policies
• Identified by UUID (e.g., tenant-a, tenant-b)
• Multi-tenant SaaS: subdomain routing (tenant-a.ankasecure.com)

Policy:

• Configuration rules governing cryptographic operations
• Types: Algorithm Availability, Algorithm Rotation, Key Lifecycle
• Hierarchy: Deployment-level (global) + Tenant-level (override)

Keystore:

• Secure storage for cryptographic keys
• Per-tenant isolation in /srv/anka-secure/environments/{env}/volumes/keystores/{tenant-id}/
• PKCS#12 format or HSM-backed

Service Components

Core API:

• Main cryptographic operations service (encryption, signatures, key management)
• Port: 8443 (default)

Admin API:

• Tenant, user, and application management
• Port: 8442 (default)

Auth API:

• Authentication and JWT token issuance
• Port: 8445 (default)

License Server:

• Usage tracking and license validation
• Port: 7090 (default)

PQC Handshake API:

• Quantum-resistant session establishment
• Port: 8441 (default)

Authentication Terms

JWT (JSON Web Token):

• Self-contained token with tenant, user, and permission claims
• Validates identity and authorizes operations
• Issued by Auth API, validated by all services

mTLS (Mutual TLS):

• Service-to-service authentication using client certificates
• Used for internal API communication

Client Credentials:

• clientId + clientSecret for application authentication
• Used by CLI, SDK, and automated systems

API Standards & Interoperability

ANKASecure implements industry-standard JOSE (JSON Object Signing and Encryption) for all cryptographic operations, ensuring interoperability with modern cloud platforms and identity providers.

Key formats:

• JWS (JSON Web Signature): Digital signatures with detached content support
• JWE (JSON Web Encryption): Encrypted data containers
• JWT (JSON Web Token): Authentication tokens with standard claims

For technical details on JOSE formats, see JOSE Technical Reference.

For interoperability and standards compliance, see Interoperability & Standards.

Quick Reference

PQC Algorithm Cheat Sheet

Algorithm Catalog: ANKASecure supports 130 cryptographic algorithms (89 simple + 41 composite combinations). See Complete Algorithm Catalog.

Key Terms Glossary

Related Documentation

Prerequisites

• None - this is the entry point document

Read after this document

• Foundational Concepts - the section index, and what each page answers
• CAPA framework - the 5 Pillars, one page each (canonical)
• Deployment Organization Model - Hierarchy and governance (canonical)
• The Cryptographic Control Plane - why cryptography is a governed plane

Implementation

• Tenant Isolation Model - Technical isolation details
• Envelope Encryption Pattern - The DEK/KEK structure behind every operation
• Key Identifier (KID) System - How a ciphertext names the key that made it

Getting Started

• Platform Overview - Quick orientation, architecture at a glance, reading paths by role
• FAQ - Frequently asked questions across architecture, capabilities, compliance, deployment
• SDK Quick Start - Hands-on integration

Document Status: Entry point document for all audiences