ISO 27001 A.8.24: Use of Cryptography

Quick Reference: A.8.24 in 60 Seconds

🚀 Time-Constrained? Start Here

💡 Need help implementing this? Contact Singahi for a 20-minute cryptographic readiness call. We build crypto programs in 8 weeks.

What the Standard Actually Requires

The Standard Text (ISO 27001:2022)

ISO 27001:2022 Annex A 8.24 asks organizations to define and implement rules for the effective use of cryptography, including key management.

ISO 27002:2022 Implementation Guidance (Section 8.24)

ISO 27002:2022 provides 6 implementation guidance components for 8.24. Every competitor lists these. Here's what they all say, plus what they miss.

This guide covers all 6 with practical depth that no competitor reaches.

💡 Tip from Singahi: In our audits, we see that 55% of 8.24 non-conformities stem from component #2 (key management) and #4 (solution selection). Organizations enable encryption but manage keys in spreadsheets or hardcode them in source code. Every key must have a lifecycle, and every key must live in a vault or HSM.

What Changed from ISO 27001:2013

Key implication: The 2022 version demands implementation, not just documentation. Auditors now spot-check encryption configurations, key storage locations, and certificate expiry.

What Auditors Actually Check

Cryptography Fundamentals

Every competitor assumes you know cryptography. This guide doesn't. We build from first principles.

The Cryptographic Triad

Cryptography protects three properties:

Non-repudiation (proof of origin) is achieved by combining authenticity with timestamping and logging.

Symmetric vs. Asymmetric Encryption

The Hybrid Model: Modern cryptography almost always uses both. Asymmetric encryption encrypts a symmetric key ("key encapsulation"). The symmetric key encrypts the bulk data. This is how TLS 1.3 works.

Block Ciphers vs. Stream Ciphers

AEAD (Authenticated Encryption with Associated Data): The gold standard. Provides confidentiality + integrity + authenticity in one operation. Always use AEAD modes when available. AES-256-GCM and ChaCha20-Poly1305 are both AEAD.

Hashing and Digital Signatures

Public Key Infrastructure (PKI)

PKI is the system that binds public keys to identities. It consists of:

Quantum Threats and Post-Quantum Cryptography

The arrival of cryptographically relevant quantum computers (CRQCs) will break:

Timeline: NIST estimates CRQCs could emerge between 2030 and 2040. "Harvest now, decrypt later" attacks are happening today. Organizations should begin crypto-agility planning now.

📊 Singahi Insight: In 2025, we helped a fintech begin its post-quantum migration. We started with a cryptographic inventory, identified all RSA-2048 and ECDSA P-256 instances, and created a 3-year migration roadmap. The auditor called it "the most forward-looking crypto program we've seen." Start your quantum readiness assessment.

The Cryptographic Policy

A cryptographic policy is mandatory under ISO 27001:2022 A.8.24. No competitor gives a complete template. Here's one.

Cryptographic Policy Template

═══════════════════════════════════════════════════════════════
              CRYPTOGRAPHIC POLICY
         [Organization Name] — ISO 27001:2022 Annex A 8.24
═══════════════════════════════════════════════════════════════

1. PURPOSE
   This policy defines the rules, standards, and procedures for
   the use of cryptography to protect the confidentiality,
   integrity, and authenticity of organizational information.

2. SCOPE
   This policy applies to:
   • All information assets classified as Internal, Confidential,
     or Highly Confidential
   • All data at rest, in transit, and in use (where technically feasible)
   • All systems, applications, databases, and cloud services
   • All employees, contractors, and third-party suppliers
   • All cryptographic keys, certificates, and hardware security modules

3. APPROVED ALGORITHMS (2026-06-15)

   3.1 SYMMETRIC ENCRYPTION
   | Use Case | Approved Algorithm | Minimum Key Size | Notes |
   |----------|-------------------|------------------|-------|
   | General purpose | AES-256-GCM | 256 bits | AEAD mode preferred |
   | Mobile/embedded | ChaCha20-Poly1305 | 256 bits | AEAD, faster on mobile |
   | Legacy compatibility | AES-256-CBC | 256 bits | Only with HMAC-SHA-256 |

   3.2 ASYMMETRIC ENCRYPTION / KEY EXCHANGE
   | Use Case | Approved Algorithm | Minimum Key Size | Notes |
   |----------|-------------------|------------------|-------|
   | TLS, certificates | RSA | 4096 bits | Migrate to ECDSA where possible |
   | TLS, certificates | ECDSA | P-384 | Preferred over RSA for performance |
   | Modern protocols | Ed25519 | 256 bits | SSH, Git, code signing |
   | Key exchange | ECDH | P-384 | Perfect forward secrecy |
   | Key exchange | X25519 | 256 bits | Modern, fast, secure |

   3.3 HASHING
   | Use Case | Approved Algorithm | Minimum Output | Notes |
   |----------|-------------------|------------------|-------|
   | General integrity | SHA-256 | 256 bits | Default choice |
   | High security | SHA-384 | 384 bits | Government, finance |
   | Future-proof | SHA-3-256 | 256 bits | NIST standard, quantum-resistant |
   | Password hashing | Argon2id | — | Memory-hard, OWASP recommended |
   | Password hashing (legacy) | bcrypt | overhead ≥ 12 | Only if Argon2id unavailable |

   3.4 DIGITAL SIGNATURES
   | Use Case | Approved Algorithm | Notes |
   |----------|-------------------|-------|
   | Code signing | ECDSA P-384, RSA-4096 | With timestamping |
   | Document signing | ECDSA P-384, Ed25519 | Qualified e-signature where required |
   | TLS certificates | ECDSA P-384, RSA-4096 | SHA-256 or SHA-384 for certificate hash |
   | Software updates | Ed25519 | Modern, compact signatures |

4. PROHIBITED ALGORITHMS (Effective Immediately)
   • MD5 — cryptographically broken, collisions in seconds
   • SHA-1 — deprecated, collision attacks feasible
   • DES — 56-bit key, brute-forceable in hours
   • 3DES (Triple DES) — vulnerable to Sweet32 attack, deprecated by NIST
   • RC4 — broken stream cipher, biases in keystream
   • RSA-1024 — factorable with modern hardware
   • RSA-2048 — legacy, migrate to RSA-4096 or ECDSA by 2027
   • DSA — deprecated by NIST, vulnerable to parameter manipulation
   • ECDSA P-192, P-224 — too small, deprecated
   • AES-128 — minimum 256 bits for new systems
   • Custom / homegrown cryptography — NEVER
   • PKCS#1 v1.5 padding for RSA — use OAEP instead

5. KEY MANAGEMENT REQUIREMENTS
   • All keys must be generated using approved CSPRNGs (Cryptographically
     Secure Pseudo-Random Number Generators)
   • All symmetric keys ≥ 256 bits
   • All private keys must be stored in HSM or KMS
   • No private keys may be stored in source code, configuration files,
     databases, or spreadsheets
   • Key rotation: symmetric keys every 90 days; asymmetric keys every 1 year
   • Key destruction: NIST SP 800-88 Rev 1 methods (clear, purge, destroy)
   • Dual control: key generation and deletion requires 2 authorized personnel
   • Split knowledge: no single individual knows the complete key

6. CERTIFICATE MANAGEMENT
   • All production certificates must be issued by a trusted public CA
     or an internal CA with documented trust anchor distribution
   • No self-signed certificates in production
   • Certificate validity: maximum 397 days (CA/Browser Forum requirement)
   • Automated renewal: all certificates must auto-renew with ≤ 30 days
     remaining
   • Certificate Transparency: all certificates must be logged to CT logs
   • Revocation: OCSP must be enabled; OCSP stapling preferred
   • Monitoring: certificate expiry must be monitored with ≤ 14-day alerts

7. ENCRYPTION AT REST REQUIREMENTS
   • All laptops and desktops: Full Disk Encryption (BitLocker, FileVault, LUKS)
   • All mobile devices: AES-256 (built-in or enforced via MDM)
   • All databases: TDE or application-layer encryption
   • All file servers: volume-level encryption
   • All backup media: encrypted before leaving production environment
   • All cloud storage: SSE with customer-managed keys (CMK) or higher

8. ENCRYPTION IN TRANSIT REQUIREMENTS
   • TLS 1.3 is mandatory for all external-facing services
   • TLS 1.2 is the minimum for internal services (with strong cipher suites)
   • TLS 1.0 and 1.1 are prohibited
   • Weak cipher suites are prohibited (see Appendix A)
   • Certificate pinning for mobile applications
   • Mutual TLS (mTLS) for service-to-service communication in microservices
   • VPN: IPsec or WireGuard for site-to-site; WireGuard or OpenVPN for remote

9. IMPLEMENTATION GUIDE
   • All new systems must use approved algorithms from day one
   • All legacy systems must be inventoried and migrated within 12 months
   • Cryptographic implementations must use validated libraries only
     (OpenSSL 3.x, BoringSSL, libsodium, AWS Encryption SDK, Tink)
   • All code must be reviewed for hardcoded keys and weak algorithms
   • Annual cryptographic review by qualified cryptographer or third party
   • Post-quantum readiness assessment by 2027

10. COMPLIANCE AND GOVERNANCE
    • CISO owns this policy
    • Crypto Council reviews annually (Security, Engineering, Compliance, Architecture)
    • Violations are treated as security incidents
    • Non-compliance blocks production deployment

11. APPENDIX A: APPROVED TLS 1.3 CIPHER SUITES
    • TLS_AES_256_GCM_SHA384
    • TLS_CHACHA20_POLY1305_SHA256
    • TLS_AES_128_GCM_SHA256 (legacy compatibility only)

12. APPENDIX B: APPROVED TLS 1.2 CIPHER SUITES (Internal Only)
    • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
    • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
    • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (legacy)
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (legacy)

13. APPENDIX C: KEY LIFECYCLE
    [See Section 8: Key Management]

Approved by: _________________________ Date: _______________
Review Date: _________________________ Version: _______________

Approved vs. Prohibited Algorithms

This is the most important section for audit readiness. Get this wrong, and you fail.

Approved Algorithm Reference Table

Prohibited Algorithm Reference Table

Algorithm Selection Decision Tree

What do you need to protect?
├── Data at rest (files, databases, disks)
│   ├── General purpose → AES-256-GCM
│   ├── Mobile/embedded → ChaCha20-Poly1305
│   └── Legacy system → AES-256-CBC + HMAC-SHA-256 (migrate plan)
├── Data in transit (network, TLS, VPN)
│   ├── TLS 1.3 → AES-256-GCM or ChaCha20-Poly1305
│   ├── TLS 1.2 (legacy) → AES-256-GCM + ECDHE
│   └── VPN → ChaCha20-Poly1305 (WireGuard) or AES-256-GCM (IPsec)
├── Digital signatures
│   ├── General purpose → ECDSA P-384 or Ed25519
│   ├── Legacy compatibility → RSA-4096 + SHA-384
│   └── Code signing → Ed25519 or ECDSA P-384 + timestamping
├── Key exchange
│   ├── Modern → X25519 or ECDH P-384
│   └── Legacy → RSA-4096 (no forward secrecy — avoid)
├── Password hashing
│   ├── Modern → Argon2id (memory ≥ 64MB, iterations ≥ 3, parallelism ≥ 1)
│   ├── Legacy FIPS → PBKDF2-SHA-256 (600,000+ iterations)
│   └── Compatibility → bcrypt (overhead ≥ 12)
├── Hashing / integrity
│   ├── General → SHA-256
│   ├── High security → SHA-384 or SHA-512
│   └── Quantum readiness → SHA-3-256 or SHA-3-512
└── Random numbers
    ├── Linux → getrandom or /dev/urandom
    ├── Modern app → libsodium randombytes_buf
    └── Legacy → OpenSSL RAND_bytes

💡 Singahi Tip: We audit 50+ companies per year. The most common algorithm violation is SHA-1 in certificate chains and MD5 in legacy file integrity checks. Run openssl s_client -connect your-site:443 | openssl x509 -text | grep Signature Algorithm today. If you see sha1WithRSAEncryption, you have an audit finding.

Encryption at Rest

Encryption at rest protects data when storage media is compromised: stolen laptop, breached database, exposed S3 bucket. It is the control of last resort.

Full Disk Encryption (FDE)

BitLocker Deep Configuration:

## Require TPM + PIN + Recovery Key
## Computer Configuration > Policies > Windows Components > BitLocker

## Enable BitLocker with TPM + PIN
manage-bde -on C: -recoverypassword -tpmandpin

## Set minimum PIN length to 6 digits
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\FVE" -Name "MinimumPIN" -Value 6

## Require startup PIN with TPM
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\FVE" -Name "UseTPMPIN" -Value 1
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\FVE" -Name "UseAdvancedStartup" -Value 1

## Escrow recovery key to Active Directory / Entra ID
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\FVE" -Name "OSRecovery" -Value 1
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\FVE" -Name "OSActiveDirectoryBackup" -Value 1

## Encrypt data drives too
manage-bde -on D: -recoverypassword -password

## Verify status
manage-bde -status C:

LUKS Deep Configuration (Linux):

## Create LUKS container with AES-256-XTS
sudo cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 \
  --key-size 512 --hash sha512 --pbkdf argon2id \
  --iter-time 5000 /dev/nvme0n1p2

## Open the container
sudo cryptsetup open /dev/nvme0n1p2 cryptroot

## Create filesystem
sudo mkfs.ext4 /dev/mapper/cryptroot

## Backup LUKS header (CRITICAL — without this, data is unrecoverable if header corrupts)
sudo cryptsetup luksHeaderBackup /dev/nvme0n1p2 \

## Store backup in HSM-protected storage or offline secure vault
## Verify encryption status
lsblk -f
## Should show: crypto_LUKS type

## Add a secondary key slot (for key escrow / dual control)
sudo cryptsetup luksAddKey /dev/nvme0n1p2

Database Encryption

SQL Server TDE Implementation:

-- Step 1: Create master key (protected by password — store in vault)
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongPasswordFromVault';

-- Step 2: Create certificate for TDE
CREATE CERTIFICATE TDE_Certificate
WITH SUBJECT = 'TDE Certificate for Production DBs';

-- Step 3: Create database encryption key
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TDE_Certificate;

-- Step 4: Enable TDE on database
ALTER DATABASE ProductionDB
SET ENCRYPTION ON;

-- Step 5: Verify encryption status
SELECT db.name, db.is_encrypted, dm.encryption_state, dm.percent_complete
FROM sys.databases db
LEFT JOIN sys.dm_database_encryption_keys dm
ON db.database_id = dm.database_id
WHERE db.name = 'ProductionDB';
-- encryption_state: 0 = No database encryption key present
--                   1 = Unencrypted
--                   2 = Encryption in progress
--                   3 = Encrypted
--                   4 = Key change in progress
--                   5 = Decryption in progress
--                   6 = Protection change in progress

MongoDB Encryption at Rest:

## mongod.conf for encryption at rest
security:
  enableEncryption: true
  encryptionCipherMode: AES256-GCM
  encryptionKeyFile: /etc/mongodb-keyfile
  # Or use KMIP for external KMS:
  kmip:
    serverName: kmip.
    port: 5696
    clientCertificateFile: /etc/mongodb-kmip-client.pem
    serverCAFile: /etc/mongodb-kmip-ca.pem

File Encryption

Cloud Storage Encryption

AWS S3 Encryption Configuration:

{
  "Rules": [
    {
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012"
      },
      "BucketKeyEnabled": true
    }
  ]
}

Key Management for At-Rest Encryption:

📊 Singahi Insight: We audited a healthcare company in 2025 that had TDE enabled on SQL Server but the TDE certificate was stored in a shared network folder with no access controls. The encryption was technically "on" but the key was trivially accessible. Encryption without key protection is theater. Always store keys in HSM or KMS, never alongside the data.

Encryption in Transit

Encryption in transit protects data as it moves across networks. The standard is TLS 1.3. Everything else is legacy.

TLS 1.3 Deep Dive

TLS 1.3 (RFC 8446) is a radical simplification of TLS 1.2. It removes obsolete features and mandates modern cryptography.

TLS 1.3 Cipher Suites (Approved Only):

TLS 1.3 Configuration (nginx):

server {
    listen 443 ssl http2;
    server_name singahi.com;

    ssl_certificate /etc/ssl/certs/singahi.crt;
    ssl_certificate_key /etc/ssl/private/singahi.key;

    # TLS 1.3 only (production)
    ssl_protocols TLSv1.3;

    # If legacy compatibility needed, add TLS 1.2 with strict cipher list
    # ssl_protocols TLSv1.3 TLSv1.2;

    # TLS 1.3 cipher suites (order matters)
    ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    # For TLS 1.2 compatibility (if enabled)
    ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

    # Prefer server cipher order
    ssl_prefer_server_ciphers on;

    # Elliptic curves
    ssl_ecdh_curve X25519:P-384:P-256;

    # Session configuration
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;  # Disable for forward secrecy

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/ssl/certs/chain.crt;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # HSTS (preload recommended)
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    # Certificate Transparency
    add_header Expect-CT "max-age=86400, enforce" always;
}

TLS 1.3 Configuration (Apache):

<VirtualHost *:443>
    ServerName singahi.com

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/singahi.crt
    SSLCertificateKeyFile /etc/ssl/private/singahi.key
    SSLCertificateChainFile /etc/ssl/certs/chain.crt

    # TLS 1.3 only
    SSLProtocol -all +TLSv1.3

    # TLS 1.3 cipher suites
    SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

    # For TLS 1.2 compatibility
    # SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305

    SSLHonorCipherOrder on

    # OCSP Stapling
    SSLUseStapling on
    SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

    # HSTS
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"

    # Certificate Transparency
    Header always set Expect-CT "max-age=86400, enforce"
</VirtualHost>

Certificate Pinning

Certificate pinning binds an application to a specific certificate or public key, preventing MITM attacks even if a rogue CA issues a fraudulent certificate.

Mobile App Certificate Pinning (Android, okhttp):

val certificatePinner = CertificatePinner.Builder
    .add("singahi.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
    .add("singahi.com", "sha256/BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=")
    .build

val client = OkHttpClient.Builder
    .certificatePinner(certificatePinner)
    .build

Mobile App Certificate Pinning (iOS, Alamofire):

let serverTrustManager = ServerTrustManager(evaluators: [
    "singahi.com": PinnedCertificatesTrustEvaluator(
        certificates: [certData],
        acceptSelfSignedCertificates: false,
        performDefaultValidation: true,
        validateHost: true
    )
])

Mutual TLS (mTLS)

mTLS authenticates both client and server. Essential for microservices, APIs, and Zero Trust architectures.

mTLS Configuration (nginx):

server {
    listen 443 ssl;
    server_name api.singahi.com;

    ssl_certificate /etc/ssl/certs/api.crt;
    ssl_certificate_key /etc/ssl/private/api.key;

    # Require client certificate
    ssl_client_certificate /etc/ssl/certs/ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;

    location / {
        # Pass client certificate info to upstream
        proxy_pass http://backend;
    }
}

VPN Protocols

WireGuard Configuration:

## /etc/wireguard/wg0.conf — Server
[Interface]
PrivateKey = <server-private-key>
Address = 10.0.0.1/24
ListenPort = 51820

## Firewall rules
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
## Client 1
PublicKey = <client1-public-key>
AllowedIPs = 10.0.0.2/32

[Peer]
## Client 2
PublicKey = <client2-public-key>
AllowedIPs = 10.0.0.3/32

SSH Hardening

SSH is the most common remote administration protocol. Weak SSH configuration is a major audit finding.

## /etc/ssh/sshd_config — Hardened Configuration

## Protocol and algorithms
Protocol 2
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp384
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

## Authentication
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitRootLogin no
MaxAuthTries 3
MaxSessions 2
LoginGraceTime 30

## Host keys
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_ecdsa_key

## Key requirements
PubkeyAcceptedAlgorithms ssh-ed25519,ecdsa-sha2-nistp384,rsa-sha2-512

## Connection hardening
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive no
AllowUsers admin@10.0.0.* deploy@10.0.0.*
AllowGroups ssh-users

## Logging
LogLevel VERBOSE
SyslogFacility AUTH

Email Encryption: S/MIME and PGP

💡 Singahi Tip: We see organizations enable TLS 1.3 on their web servers but forget about internal APIs, database connections, and message queues. Every network connection that carries data must be encrypted. Run nmap --script ssl-enum-ciphers -p 443,636,993,995,8443 your-domain to find weak TLS across all ports.

Key Management

Key management is the most critical and most failed aspect of cryptography. A stolen key renders all encryption useless. ISO 27001:2022 A.8.24 auditors spend more time on key management than on any other crypto topic.

The Key Lifecycle

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  GENERATION │───▶│  REGISTRATION│───▶│   STORAGE   │───▶│    USE      │───▶│  ROTATION   │───▶│  DESTRUCTION│
│             │    │              │    │             │    │             │    │             │    │             │
│ CSPRNG      │    │ KMS catalog  │    │ HSM / KMS   │    │ Encryption│    │ New key     │    │ NIST 800-88 │
│ HSM ceremony│    │ Metadata     │    │ Vault       │    │ Decryption│    │ Re-encrypt  │    │ Purge       │
│ Dual control│    │ Access rules │    │ Offline backup│   │ Signing   │    │ Old key     │    │ Audit log   │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘

Key Generation

Key Generation Best Practices:

• Generate all keys in HSM or secure enclave when possible
• Use dual control: two authorized personnel present for key generation
• Record key generation in tamper-evident log
• Generate key and backup key simultaneously (for escrow)
• Test key immediately after generation (encrypt/decrypt round-trip)
• Never generate keys on shared or multi-tenant infrastructure without isolation
• Use hardware RNG (HRNG) when available, not software RNG alone

Key Storage

Hardware Security Modules (HSMs)

HSMs are tamper-resistant hardware devices that generate, store, and manage cryptographic keys. They are the gold standard for key protection.

AWS CloudHSM Setup:

## Create CloudHSM cluster
aws cloudhsm create-cluster --backup-retention-days 90 \
  --hsm-type hsm1.medium --subnet-ids subnet-12345 subnet-67890

## Initialize the first HSM
aws cloudhsm create-hsm --cluster-id cluster-12345678 \
  --availability-zone us-east-1a --ip-address 10.0.0.10

## Initialize with crypto officer (CO) and crypto user (CU) credentials
## This requires the CloudHSM client software installed locally
/opt/cloudhsm/bin/cloudhsm_mgmt_util /opt/cloudhsm/etc/cloudhsm_mgmt_util.cfg

## Create a crypto user (for application key usage)
aws-cloudhsm > createUser CU app_user <password>

## Generate a key in the HSM (never leaves the HSM)
/opt/cloudhsm/bin/key_mgmt_util
Command: genSymKey -t 31 -s 32 -l aes256-data-encryption-key

## Verify key is in HSM (no export possible)
Command: getKeyInfo -handle 7

Key Management Systems (KMS)

KMS provides centralized key management with APIs for encryption, decryption, and key lifecycle operations.

AWS KMS Envelope Encryption:

import boto3
from botocore.exceptions import ClientError

kms = boto3.client('kms')

## Generate a data key (DEK) encrypted by KMS key (KEK)
def generate_data_key(key_id):
    response = kms.generate_data_key(
        KeyId=key_id,
        KeySpec='AES_256'
    )
    # Plaintext DEK — use for encryption, then discard from memory
    plaintext_dek = response['Plaintext']
    # Encrypted DEK — store alongside ciphertext
    encrypted_dek = response['CiphertextBlob']
    return plaintext_dek, encrypted_dek

## Encrypt data using DEK (local encryption — fast)
from cryptography.fernet import Fernet
import base64

def encrypt_data(data, plaintext_dek):
    # Use DEK for AES-256 encryption
    f = Fernet(base64.urlsafe_b64encode(plaintext_dek[:32]))
    ciphertext = f.encrypt(data.encode)
    # Clear DEK from memory immediately
    import ctypes; ctypes.memset(id(plaintext_dek), 0, len(plaintext_dek))
    return ciphertext

## Decrypt data
def decrypt_data(ciphertext, encrypted_dek, kms_key_id):
    # Decrypt DEK using KMS (KEK)
    response = kms.decrypt(CiphertextBlob=encrypted_dek, KeyId=kms_key_id)
    plaintext_dek = response['Plaintext']
    # Use DEK for decryption
    f = Fernet(base64.urlsafe_b64encode(plaintext_dek[:32]))
    data = f.decrypt(ciphertext).decode
    # Clear DEK from memory
    import ctypes; ctypes.memset(id(plaintext_dek), 0, len(plaintext_dek))
    return data

Key Rotation

Key Archival and Destruction

Key Archival:

• Archive keys before destruction for legal/regulatory hold periods
• Encrypt archived keys with a separate archival key
• Store archived keys in offline, physically secure location
• Maintain archival index with key metadata (creation date, purpose, destruction date)
• Retention period: minimum 7 years for financial data, per jurisdiction

Key Destruction (NIST SP 800-88 Rev 1):

Key Destruction Checklist:

• Verify no data is encrypted with the key (or re-encrypt first)
• Verify no signatures depend on the key (or re-sign first)
• Remove key from all active systems (HSM, KMS, applications, config files)
• Remove key from all backups (or re-encrypt backups)
• Remove key from all caches and memory
• Destroy key material using NIST 800-88 method appropriate for medium
• Record destruction in tamper-evident log with witness signatures
• Notify all stakeholders of key destruction
• Update CMDB and cryptographic inventory

Dual Control and Split Knowledge

Shamir's Secret Sharing (Conceptual):

## Using a library like secretsharing or implementing SSS
from secretsharing import SecretSharer

## Split a 256-bit key into 5 shares, requiring 3 to reconstruct
shares = SecretSharer.split_secret('a' * 64, threshold=3, shares=5)
## shares = ['1-...', '2-...', '3-...', '4-...', '5-...']

## Store each share in a separate physical location / HSM / vault
## Reconstruct with any 3 shares
reconstructed = SecretSharer.recover_secret(shares[:3])

📊 Singahi Insight: The worst key management failure we saw in 2025: a fintech stored their AWS KMS customer master key in a plaintext file on an unencrypted S3 bucket, publicly accessible. The key was labeled production-master-key.pem. Key storage is more important than algorithm choice. A weak algorithm with strong key management is better than a strong algorithm with weak key management. Always use HSM or KMS. Never store keys with data.

Certificate Management

Certificate management is the operational backbone of encryption in transit. Expired certificates cause outages. Self-signed certificates cause audit failures. Rogue certificates enable MITM attacks.

PKI Architecture

Two-Tier PKI Architecture:

┌─────────────────────────────────────────────────────────────┐
│                    ROOT CA (Offline)                         │
│  • HSM-protected, air-gapped, physical security              │
│  • Signs intermediate CA certificates only                   │
│  • Activated only for intermediate renewal (every 5-10 years)│
└──────────────────────────┬────────────────────────────────────┘
                           │ Signs intermediate cert
                           ▼
┌─────────────────────────────────────────────────────────────┐
│                 INTERMEDIATE CA (Online)                     │
│  • HSM-protected, online, automated issuance                 │
│  • Issues end-entity certificates (TLS, code signing, email)│
│  • CRL and OCSP distribution                                 │
│  • Renewed every 3-5 years                                   │
└──────────────────────────┬────────────────────────────────────┘
                           │ Signs end-entity certs
                           ▼
┌─────────────────────────────────────────────────────────────┐
│              END-ENTITY CERTIFICATES                         │
│  • TLS certificates (397-day max)                              │
│  • Code signing certificates (1-3 years)                     │
│  • Email/S/MIME certificates (1-3 years)                     │
│  • Client certificates (1-3 years)                             │
└─────────────────────────────────────────────────────────────┘

Certificate Lifecycle Management

Let's Encrypt and ACME

Let's Encrypt is a free, automated, open CA. It issues 90-day certificates via the ACME protocol. ACME is the standard for automated certificate management.

cert-manager (Kubernetes) + Let's Encrypt:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: security@singahi.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: singahi-tls
  namespace: production
spec:
  secretName: singahi-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - singahi.com
  - www.singahi.com
  - api.singahi.com

ACME Client (certbot), Standalone Server:

## Install certbot
sudo apt install certbot

## Obtain certificate
sudo certbot certonly --standalone -d singahi.com -d www.singahi.com

## Auto-renewal (cron or systemd timer)
sudo certbot renew --dry-run

## Post-renewal hook (restart services)
echo '#!/bin/bash
systemctl reload nginx
systemctl reload postfix' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh

Certificate Transparency (CT)

Certificate Transparency logs all issued certificates in public, append-only logs. This prevents rogue CAs from issuing certificates for your domain without detection.

CT Monitoring Alert Setup:

## Using Cert Spotter (SSLMate) to monitor for unauthorized certificates
curl -s "https://api.certspotter.com/v1/issuances?domain=singahi.com&include_subdomains=true&expand=dns_names&expand=issuer&expand=cert" | \
  jq '.[] | {id: .id, dns_names: .dns_names, issuer: .issuer.name, not_before: .not_before}'

## Set up automated alerts with a cron job:
## 1. Query Cert Spotter daily
## 2. Compare against approved certificate list
## 3. Alert if unauthorized certificate found

CA Selection Criteria

Certificate Monitoring and Expiry Alerts

Prometheus blackbox_exporter Certificate Expiry Alert:

## prometheus.yml
scrape_configs:
  - job_name: 'ssl_cert_check'
    metrics_path: /probe
    params:
      module: [tcp_connect]
      target: ['singahi.com:443']
    static_configs:
      - targets:
        - /
        - https://api.singahi.com
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - target_label: __address__
        replacement: blackbox_exporter:9115

## Alert rule
- alert: SSLCertificateExpiringSoon
  expr: (
    probe_ssl_earliest_cert_expiry - time
  ) / 86400 < 30
  for: 1h
  labels:
    severity: warning
  annotations:

💡 Singahi Tip: The most common certificate failure we see is not expiry, it's intermediate certificate chain misconfiguration. A server sends only the leaf certificate without the intermediate, causing "certificate not trusted" errors on some clients but not others. Always test with openssl s_client -connect your-site:443 -showcerts and verify the full chain.

Database Encryption

Database encryption protects data where it is most concentrated. A breached database without encryption is a catastrophic data breach. With encryption, it's a security incident.

Transparent Data Encryption (TDE) by Database

TDE encrypts data at the storage layer. It is transparent to applications, no code changes required.

MySQL 8.0 TDE:

-- Step 1: Install keyring plugin (file-based for testing, KMS for production)
INSTALL PLUGIN keyring_file SONAME 'keyring_file.so';

-- For production, use AWS KMS keyring:
-- INSTALL PLUGIN keyring_aws SONAME 'keyring_aws.so';

-- Step 2: Configure keyring in my.cnf
-- [mysqld]
-- early-plugin-load=keyring_file.so
-- keyring_file_data=/var/lib/mysql-keyring/keyring

-- Step 3: Create tablespace encryption
ALTER TABLESPACE innodb_system ENCRYPTION='Y';

-- Step 4: Encrypt specific tables
ALTER TABLE customers ENCRYPTION='Y';
ALTER TABLE payments ENCRYPTION='Y';

-- Step 5: Verify encryption
SELECT TABLE_NAME, TABLE_SCHEMA, ENCRYPTION FROM INFORMATION_SCHEMA.INNODB_TABLESPACES
WHERE ENCRYPTION='Y';

PostgreSQL (CloudNativePG TDE):

## Cluster spec with TDE
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: production-db
spec:
  instances: 3
  storage:
    size: 100Gi
  walStorage:
    size: 50Gi
  # TDE configuration
  postgresql:
    parameters:
      ssl: 'on'
      ssl_cert_file: '/etc/ssl/certs/server.crt'
      ssl_key_file: '/etc/ssl/private/server.key'
  # Encryption at rest via storage class encryption
  # (e.g., AWS EBS encryption with KMS key)

Oracle TDE:

-- Step 1: Create wallet
ALTER SYSTEM SET TDE_KEYSTORE=KEYSTORE IDENTIFIED BY wallet_password;

-- Step 2: Open wallet
ALTER SYSTEM SET TDE_KEYSTORE=OPEN IDENTIFIED BY wallet_password;

-- Step 3: Create master encryption key
ALTER SYSTEM SET TDE_KEYSTORE=CREATE KEY IDENTIFIED BY wallet_password
WITH BACKUP USING 'backup_identifier';

-- Step 4: Create tablespace with encryption
CREATE TABLESPACE encrypted_ts
DATAFILE '/u01/app/oracle/oradata/encrypted_ts01.dbf' SIZE 100M
ENCRYPTION USING 'AES256'
DEFAULT STORAGE(ENCRYPT);

-- Step 5: Move table to encrypted tablespace
ALTER TABLE customers MOVE TABLESPACE encrypted_ts;

MongoDB Encryption at Rest:

// Enable encryption at rest during mongod startup
// mongod.conf:
// security:
//   enableEncryption: true
//   encryptionKeyFile: /etc/mongodb-keyfile
//   encryptionCipherMode: AES256-GCM

// Verify encryption status
db.adminCommand({ getParameter: 1, enableEncryption: 1 })
// { "enableEncryption" : true, "ok" : 1 }

// Enable encryption for specific collections (Enterprise)
db.createCollection("encrypted_coll", {
  encryptedFields: {
    fields: [
      { path: "ssn", bsonType: "string", queries: { queryType: "equality" } },
      { path: "dob", bsonType: "date" }
    ]
  }
})

Column-Level Encryption

Column-level encryption encrypts specific sensitive columns. It requires application changes but provides granular protection.

SQL Server Always Encrypted:

-- Step 1: Create column master key (CMK) in Azure Key Vault
CREATE COLUMN MASTER KEY CMK_AKV
WITH (
  KEY_STORE_PROVIDER_NAME = 'AZURE_KEY_VAULT',
  KEY_PATH = 'https://singahi-vault.vault.azure.net/keys/CMK1/abc123'
);

-- Step 2: Create column encryption key (CEK) encrypted by CMK
CREATE COLUMN ENCRYPTION KEY CEK1
WITH VALUES (
  COLUMN_MASTER_KEY = CMK_AKV,
  ALGORITHM = 'RSA_OAEP',
  ENCRYPTED_VALUE = 0x016E000001...
);

-- Step 3: Create table with encrypted columns
CREATE TABLE Customers (
  CustomerID int,
  FirstName nvarchar(50),
  LastName nvarchar(50),
  SSN nvarchar(11) ENCRYPTED WITH (
    COLUMN_ENCRYPTION_KEY = CEK1,
    ENCRYPTION_TYPE = DETERMINISTIC,
    ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
  ),
  CreditCard nvarchar(19) ENCRYPTED WITH (
    COLUMN_ENCRYPTION_KEY = CEK1,
    ENCRYPTION_TYPE = RANDOMIZED,
    ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
  )
);

MySQL Column-Level Encryption (Application Layer):

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

## Generate or retrieve key from KMS
key = os.urandom(32)  # In production: retrieve from AWS KMS / HashiCorp Vault
aesgcm = AESGCM(key)

## Encrypt column value
def encrypt_column(plaintext: str) -> bytes:
    nonce = os.urandom(12)
    ciphertext = aesgcm.encrypt(nonce, plaintext.encode, None)
    return nonce + ciphertext  # Store nonce + ciphertext together

## Decrypt column value
def decrypt_column(encrypted: bytes) -> str:
    nonce = encrypted[:12]
    ciphertext = encrypted[12:]
    return aesgcm.decrypt(nonce, ciphertext, None).decode

## Usage: store encrypted data in database
encrypted_ssn = encrypt_column("123-45-6789")
## INSERT INTO customers (ssn) VALUES (%s)
## Store encrypted_ssn as BLOB

Application-Layer Encryption

Application-layer encryption encrypts data before it reaches the database. The database never sees plaintext.

📊 Singahi Insight: We audited a SaaS company in 2025 that had TDE enabled on PostgreSQL but the application cached decrypted data in Redis with no encryption. The database was "encrypted" but the cache was plaintext. Encryption must cover the entire data lifecycle: database, cache, backup, log, and analytics. Map every place data lives and encrypt every one.

Application Encryption

Application encryption gives developers control over what gets encrypted and how. It is the most flexible but most complex approach.

Client-Side Encryption

Client-side encryption encrypts data in the browser or mobile app before sending it to the server. The server never sees plaintext.

Browser Client-Side Encryption (Web Crypto API):

// Generate a wrapping key in the browser (or derive from user password)
async function generateKey {
  return await window.crypto.subtle.generateKey(
    { name: 'AES-GCM', length: 256 },
    true,  // extractable (for backup/escrow)
    ['encrypt', 'decrypt']
  );
}

// Encrypt file before upload
async function encryptFile(file, key) {
  const iv = window.crypto.getRandomValues(new Uint8Array(12));
  const fileData = await file.arrayBuffer;
  const ciphertext = await window.crypto.subtle.encrypt(
    { name: 'AES-GCM', iv: iv },
    key,
    fileData
  );
  // Send iv + ciphertext to server
  return { iv: Array.from(iv), ciphertext: Array.from(new Uint8Array(ciphertext)) };
}

// Derive key from user password using PBKDF2 (or Argon2 via WebAssembly)
async function deriveKeyFromPassword(password, salt) {
  const keyMaterial = await window.crypto.subtle.importKey(
    'raw',
    new TextEncoder.encode(password),
    'PBKDF2',
    false,
    ['deriveKey']
  );
  return await window.crypto.subtle.deriveKey(
    { name: 'PBKDF2', salt: salt, iterations: 600000, hash: 'SHA-256' },
    keyMaterial,
    { name: 'AES-GCM', length: 256 },
    false,
    ['encrypt', 'decrypt']
  );
}

Field-Level Encryption

Field-level encryption encrypts individual fields in a data structure. Useful for APIs and structured data.

from aws_encryption_sdk import EncryptionSDKClient
import aws_encryption_sdk.identities

client = EncryptionSDKClient

## Encrypt specific fields in a JSON document
def encrypt_sensitive_fields(data, key_arn):
    sensitive_fields = ['ssn', 'credit_card', 'dob', 'salary']
    encrypted_data = data.copy
    
    for field in sensitive_fields:
        if field in data:
            plaintext = str(data[field]).encode
            ciphertext, _ = client.encrypt(
                source=plaintext,
                key_provider=aws_encryption_sdk.identities.KMSKeyProvider(key_arn)
            )
            encrypted_data[field] = ciphertext.hex
    
    return encrypted_data

## Usage
encrypted_record = encrypt_sensitive_fields({
    'name': 'John Smith',
    'ssn': '123-45-6789',
    'credit_card': '4111111111111111'
}, 'arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012')

Tokenization

Tokenization replaces sensitive data with a non-sensitive token. The token has no mathematical relationship to the original data.

Tokenization Example (PCI DSS PAN):

import uuid
from cryptography.fernet import Fernet

class TokenVault:
    def __init__(self, key):
        self.cipher = Fernet(key)
        self.vault = {}  # In production: database or HSM-backed vault
    
    def tokenize(self, pan):
        # Generate random token
        token = str(uuid.uuid4).replace('-', '')[:16]
        # Encrypt PAN and store in vault
        self.vault[token] = self.cipher.encrypt(pan.encode).decode
        return token
    
    def detokenize(self, token):
        encrypted_pan = self.vault.get(token)
        if encrypted_pan:
            return self.cipher.decrypt(encrypted_pan.encode).decode
        return None

## Usage
vault = TokenVault(key_from_kms)
token = vault.tokenize("4111111111111111")
## Store token in database; PAN is never in database

Format-Preserving Encryption (FPE)

FPE encrypts data while preserving its format. A 16-digit credit card number encrypts to a 16-digit number.

FPE Example (FF1 with Python):

from pycryptodome.Cipher import AES
from pycryptodome.Util.Padding import pad

## Note: Real FPE requires NIST SP 800-38G compliant implementation
## Use libraries like `mysto-fpe` or vendor FPE solutions
from mystofpe import FF1

fpe = FF1(key=32_byte_key, tweak=b'singahi_tweak', radix=10)

## Encrypt 16-digit PAN
encrypted_pan = fpe.encrypt("4111111111111111")
## Result: "9823746510293847" (16 digits, different value)

## Decrypt
decrypted_pan = fpe.decrypt(encrypted_pan)
## Result: "4111111111111111"

Searchable Encryption

Searchable encryption allows searching encrypted data without decryption.

Homomorphic Encryption

Homomorphic encryption allows computation on encrypted data without decryption. It is the holy grail of cryptography but remains computationally premium-tier.

Practical note: Homomorphic encryption is not yet practical for general-purpose production use. Monitor developments from IBM (HELayers), Microsoft (SEAL), and Duality Technologies.

💡 Singahi Tip: The most common application encryption mistake is encrypting the wrong things. Don't encrypt user_id or created_at, these need indexing and searching. Do encrypt ssn, credit_card, medical_record_number, salary. Use a data classification matrix to decide what gets encrypted, tokenized, or left plaintext.

Cloud Cryptography

Cloud cryptography introduces new models: provider-managed keys, customer-managed keys, bring your own key, and hold your own key. Understanding these models is essential for ISO 27001:2022 compliance in cloud environments.

Cloud Encryption Models

Cloud KMS Deep Dive

AWS KMS:

Azure Key Vault:

GCP Cloud KMS:

Envelope Encryption

Envelope encryption is the cloud-native pattern for encrypting large data with a data key, while the data key is encrypted by a master key.

┌─────────────────────────────────────────────────────────────┐
│                    PLAINTEXT DATA                           │
│  (Large file, database, backup)                             │
└──────────────────────────┬────────────────────────────────────┘
                           │ Encrypt with Data Encryption Key (DEK)
                           ▼
┌─────────────────────────────────────────────────────────────┐
│                    CIPHERTEXT DATA                          │
│  (Encrypted file, stored in S3 / Blob / GCS)               │
└─────────────────────────────────────────────────────────────┘
                           │ Store alongside:
                           ▼
┌─────────────────────────────────────────────────────────────┐
│              ENCRYPTED DATA ENCRYPTION KEY (EDEK)           │
│  (DEK encrypted by Key Encryption Key — KEK)                │
│  KEK is stored in AWS KMS / Azure Key Vault / GCP KMS       │
└─────────────────────────────────────────────────────────────┘

AWS Encryption SDK (Python):

from aws_encryption_sdk import EncryptionSDKClient
from aws_encryption_sdk.identities import KMSKeyProvider

client = EncryptionSDKClient

## Master key provider (KMS)
key_provider = KMSKeyProvider(
    key_id='arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012'
)

## Encrypt a large file using envelope encryption
with open('sensitive_data.bin', 'rb') as plaintext_file, \
     open('sensitive_data.encrypted', 'wb') as ciphertext_file:
    
    ciphertext, header = client.encrypt(
        source=plaintext_file,
        key_provider=key_provider
    )
    ciphertext_file.write(ciphertext)

## Decrypt
with open('sensitive_data.encrypted', 'rb') as ciphertext_file, \
     open('sensitive_data_decrypted.bin', 'wb') as plaintext_file:
    
    plaintext, header = client.decrypt(
        source=ciphertext_file,
        key_provider=key_provider
    )
    plaintext_file.write(plaintext)

Confidential Computing

Confidential computing encrypts data in use, while it is being processed in memory. This is the third pillar of encryption (at rest, in transit, in use).

AWS Nitro Enclaves Example:

## Enclave application (runs in isolated environment)
import json
import boto3
from aws_nitro_enclaves_sdk import KMS

def decrypt_data(encrypted_data, encrypted_key):
    # Decrypt data key using KMS from within enclave
    kms = KMS
    decrypted_key = kms.decrypt(
        CiphertextBlob=encrypted_key,
        EncryptionAlgorithm='SYMMETRIC_DEFAULT'
    )['Plaintext']
    
    # Use decrypted key to decrypt data
    from cryptography.hazmat.primitives.ciphers.aead import AESGCM
    aesgcm = AESGCM(decrypted_key)
    nonce = encrypted_data[:12]
    ciphertext = encrypted_data[12:]
    return aesgcm.decrypt(nonce, ciphertext, None)

📊 Singahi Insight: In 2025, we helped a healthcare SaaS implement AWS Nitro Enclaves for PHI processing. The architecture: application runs in standard EC2, enclave processes PHI with attestation, decryption keys never leave the enclave. The auditor's comment: "This is the strongest data protection architecture we've seen in a cloud-native environment." Explore confidential computing for your workload.

Container & Kubernetes Encryption

Container and Kubernetes environments have unique cryptographic challenges: secrets in etcd, pod-to-pod communication, and service mesh encryption.

Secrets Management in Kubernetes

Sealed Secrets (GitOps):

## Install Sealed Secrets controller
kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.24.0/controller.yaml

## Encrypt a secret for Git storage
kubectl create secret generic db-credentials \
  --from-literal=password=supersecret \
  --dry-run=client -o yaml | \
  kubeseal --controller-namespace=kube-system --controller-name=sealed-secrets \
  --format yaml > sealed-db-credentials.yaml

## Commit sealed-db-credentials.yaml to Git — it's safe to share
## Only the cluster controller can decrypt it
kubectl apply -f sealed-db-credentials.yaml

External Secrets Operator (ESO):

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secrets-manager
  namespace: production
spec:
  provider:
    aws:
      service: SecretsManager
      region: us-east-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: SecretStore
  target:
    name: db-credentials
    creationPolicy: Owner
  data:
  - secretKey: password
    remoteRef:
      key: production/db-password
      property: password

etcd Encryption

etcd stores all Kubernetes secrets. By default, etcd is not encrypted at rest. This is a critical audit finding.

## /etc/kubernetes/manifests/kube-apiserver.yaml
## Add encryption provider configuration:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}  # Fallback (do not use in production)

Better: Use KMS v2 provider for etcd encryption:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      - kms:
          name: myKMSPlugin
          endpoint: unix:///var/run/k8s-kms-plugin/socket.sock
          cachesize: 1000
          timeout: 3s
      - identity: {}  # Fallback

Pod-to-Pod Encryption with Service Mesh mTLS

Service mesh provides automatic mTLS between all pods. This is the easiest way to achieve encryption in transit for microservices.

Istio Strict mTLS Configuration:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT  # Require mTLS for all services
---
## Verify mTLS is working
## kubectl exec -it deploy/sleep -n foo -- curl -v http://httpbin:8000/ip
## Look for: "SSL connection using TLSv1.3"

Linkerd mTLS (Automatic):

## Install Linkerd with identity (automatic mTLS)
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -

## Verify mTLS
linkerd viz tap deploy/frontend -n production | grep tls
## Shows: tls=true for all connections

## Enforce mTLS with authorization policy
kubectl apply -f - <<EOF
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
  name: backend-allow
  namespace: production
spec:
  server:
    name: backend
  requiredAuthenticationRefs:
    - name: backend
      kind: ServiceAccount
EOF

Cilium with WireGuard (eBPF-based):

## Cilium ConfigMap for WireGuard encryption
apiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-config
  namespace: kube-system
data:
  enable-wireguard: "true"
  enable-wireguard-userspace-fallback: "false"
  # WireGuard uses ChaCha20-Poly1305 for pod-to-pod encryption

cert-manager for Kubernetes Certificates

cert-manager automates certificate issuance and renewal in Kubernetes.

## ClusterIssuer for Let's Encrypt
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: security@singahi.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx
---
## Certificate for ingress
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: singahi-tls
  namespace: production
spec:
  secretName: singahi-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - singahi.com
  - www.singahi.com
  - api.singahi.com
  - app.singahi.com

💡 Singahi Tip: Kubernetes secrets are base64-encoded, not encrypted. Anyone with etcd access can read all secrets. Enable etcd encryption immediately. This is a guaranteed audit finding if not enabled. We verify etcd encryption in every Kubernetes audit using etcdctl get /registry/secrets/default/my-secret and confirming the value is encrypted, not plaintext JSON.

Quantum-Resistant Cryptography

Quantum computers will break RSA, ECDSA, and Diffie-Hellman. Organizations must prepare now. NIST has published its first post-quantum standards.

NIST Post-Quantum Cryptography Standards (2024)

Migration Planning

Phase 1: Inventory (Now, 2026)

• Catalog all cryptographic implementations (algorithms, key sizes, libraries)
• Identify all RSA, ECDSA, DH, and ECDH usage
• Map data sensitivity and retention periods
• Identify systems that must remain secure for >10 years
• Assess crypto-agility of existing systems (can algorithms be swapped?)

Phase 2: Crypto-Agility (2026, 2028)

• Implement algorithm negotiation in all protocols
• Design systems to support multiple signature algorithms simultaneously
• Add hybrid (classical + post-quantum) key exchange to TLS (experimental)
• Update cryptographic libraries to support ML-KEM and ML-DSA
• Train developers on post-quantum algorithms and key sizes

Phase 3: Hybrid Deployment (2028, 2030)

• Deploy hybrid certificates (classical + post-quantum signatures)
• Enable ML-KEM in key exchange protocols
• Update HSM firmware to support post-quantum algorithms
• Begin post-quantum code signing for software updates
• Update PKI infrastructure to issue post-quantum certificates

Phase 4: Full Migration (2030, 2035)

• Replace all classical-only key exchange with ML-KEM
• Replace all classical signatures with ML-DSA or Falcon
• Deprecate RSA and ECDSA for new systems
• Maintain classical algorithms only for legacy interoperability
• Complete migration of all long-term sensitive data encryption

Hybrid Approaches

Hybrid cryptography combines classical and post-quantum algorithms. If the post-quantum algorithm has a flaw, the classical algorithm still provides security.

TLS 1.3 Hybrid Key Exchange (Conceptual):
├── Classical: X25519 or ECDH P-384
├── Post-quantum: ML-KEM-768 or ML-KEM-1024
└── Combined: Concatenate shared secrets from both
    Result: Secure even if one algorithm is broken

Open Quantum Safe (OQS), Experimental:

## Build OpenSSL with OQS support (experimental, not production)
git clone https://github.com/open-quantum-safe/openssl.git
git clone https://github.com/open-quantum-safe/liboqs.git
cd liboqs && mkdir build && cd build && cmake .. -DBUILD_SHARED_LIBS=ON && make && sudo make install
cd ../../openssl && ./config --with-liboqs && make && sudo make install

## Generate hybrid certificate
apps/openssl req -x509 -new -newkey dilithium3 -extensions v3_ca \
  -keyout hybrid-ca.key -out hybrid-ca.crt -nodes -subj "/CN=Hybrid CA" -days 365

Cryptographic Implementation

Cryptographic implementation is where theory meets practice. A correct algorithm with a buggy implementation is still broken.

Approved Libraries

libsodium Example (Modern, Secure by Default):

#include <sodium.h>

// Initialize libsodium
if (sodium_init < 0) {
    panic("libsodium initialization failed");
}

// Generate a symmetric key
unsigned char key[crypto_secretbox_KEYBYTES];
randombytes_buf(key, sizeof(key));

// Encrypt a message
unsigned char nonce[crypto_secretbox_NONCEBYTES];
randombytes_buf(nonce, sizeof(nonce));

unsigned char ciphertext[crypto_secretbox_MACBYTES + message_len];
crypto_secretbox_easy(ciphertext, message, message_len, nonce, key);

// Decrypt
unsigned char decrypted[message_len];
if (crypto_secretbox_open_easy(decrypted, ciphertext, sizeof(ciphertext), nonce, key) != 0) {
    // Verification failed — message forged or corrupted
}

Common Implementation Mistakes

Side-Channel Attacks

Side-channel attacks exploit implementation characteristics rather than algorithm weaknesses.

Constant-Time Comparison (C):

#include <sodium.h>

// NEVER use memcmp for secrets
// Use sodium_memcmp which is constant-time
if (sodium_memcmp(provided_password, stored_hash, hash_len) == 0) {
    // Authentication successful
}

// For clearing memory securely
sodium_memzero(secret_key, sizeof(secret_key));

Constant-Time Comparison (Python):

import hmac

## NEVER use '==' for secret comparison
## Use hmac.compare_digest which is constant-time
if hmac.compare_digest(provided_signature, expected_signature):
    # Verification successful
    pass

💡 Singahi Tip: We find side-channel vulnerabilities in ~30% of custom cryptographic implementations. Never implement custom cryptography. Use libsodium, OpenSSL 3.x, AWS Encryption SDK, or Tink. These libraries have been audited by experts and include constant-time implementations. If you must implement crypto, hire a cryptographer to review it.

Cryptographic Audit & Validation

Figure · Tiers

Maturity levels for use of cryptography

Cryptographic audit and validation ensures that your implementation meets recognized standards and is free from known vulnerabilities.

FIPS 140-2 / FIPS 140-3

FIPS 140-2 and FIPS 140-3 are NIST standards for cryptographic modules. They define four security levels.

FIPS 140-3 Improvements over FIPS 140-2:

Common Criteria (ISO/IEC 15408)

Common Criteria evaluates IT security products against security targets.

Cryptographic Module Validation Program (CMVP)

Penetration Testing Cryptography

testssl.sh, Complete TLS Scan:

## Install testssl.sh
git clone https://github.com/drwetter/testssl.sh.git
cd testssl.sh

## Full scan of a target
./testssl.sh --full --wide singahi.com

## Check for specific vulnerabilities
./testssl.sh --heartbleed --ccs --ticketbleed --robot --breach --poodle --freak --logjam --drown --sweet32 singahi.com

## Output to JSON for automated processing
./testssl.sh --json --logfile singahi_scan.json singahi.com

Cryptographic Audit Checklist

Metrics & KPIs

Cryptographic metrics demonstrate control effectiveness to auditors and management.

Cryptographic Metrics Dashboard (Conceptual):

┌─────────────────────────────────────────────────────────────┐
│              CRYPTOGRAPHIC HEALTH DASHBOARD                 │
├─────────────────────────────────────────────────────────────┤
│  Encryption Coverage:    ████████████████████ 100%        │
│  TLS 1.3 Adoption:       █████████████████░░░░  85%         │
│  Key Rotation (90d):     ████████████████████ 100%        │
│  Cert Expiry > 30d:      ████████████████████ 100%        │
│  Algorithm Compliance:   ████████████████████ 100%        │
│  HSM Availability:       ████████████████████ 99.99%      │
│  Hardcoded Keys:         ████████████████████ 0             │
│  PQ Readiness:           ██████████████░░░░░░  60%        │
├─────────────────────────────────────────────────────────────┤
│  Alerts: 1 certificate expires in 14 days (api-staging)       │
│  Actions: Rotate staging API certificate by 2026-06-25       │
└─────────────────────────────────────────────────────────────┘

Tool Comparison

KMS Comparison

Certificate Management Comparison

Encryption Library Comparison

Implementation Roadmap: 12 Weeks

💡 Singahi Implementation: We execute this 12-week roadmap for clients with 2-3 Singahi consultants embedded in your team. We bring the templates, tools, and automation. You bring the systems and access. Book a 12-week crypto transformation.

Common Audit Failures & Fixes

Illustrative Scenarios: Real Breaches from Weak Crypto

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: The RSA-1024 Factorization (2010, Multiple Organizations)

What happened: Researchers demonstrated that RSA-1024 could be factored with a few thousand dollars of cloud computing. Organizations using RSA-1024 for TLS or VPNs were vulnerable to passive decryption.

Impact: Any data encrypted with RSA-1024 and intercepted by an attacker was decryptable. This included old TLS sessions, encrypted emails, and VPN traffic.

Root cause: RSA-1024 was deprecated by NIST in 2010 but many organizations never upgraded. It was the "default" in many systems.

Fix: Upgrade to RSA-4096 or ECDSA P-384. Re-issue all certificates. Re-encrypt all archived data with new keys.

Audit lesson: A.8.24 requires not just "using cryptography" but using cryptography that meets current standards. RSA-1024 is an automatic audit failure in 2026.

Illustrative Scenario 2: The 3DES Sweet32 Attack (2016, VPN Providers, Banks)

What happened: The Sweet32 attack exploited the small 64-bit block size of 3DES. After 32GB of data encrypted with the same key, an attacker could recover plaintext.

Impact: VPN connections using 3DES were vulnerable to plaintext recovery after sustained traffic. Banking systems using 3DES for transaction encryption were at risk.

Root cause: 3DES was a legacy fallback in many TLS and VPN configurations. It was enabled "just in case" an old client needed it.

Fix: Remove 3DES from all configurations. Use AES-256-GCM or ChaCha20-Poly1305. Monitor for downgrade attacks.

Audit lesson: Legacy algorithm support is a liability. If you support weak algorithms, attackers will force them. A.8.24 requires proactive algorithm deprecation.

Illustrative Scenario 3: The SHA-1 Collision (2017, CAs, Code Signing)

What happened: The SHAttered attack demonstrated practical SHA-1 collisions. Google and CWI Amsterdam generated two different PDFs with the same SHA-1 hash.

Impact: Code signing certificates using SHA-1 could be forged. An attacker could create a malicious file with the same hash as a legitimate file, making it appear signed.

Root cause: SHA-1 was still widely used in certificate chains, Git signatures, and code signing despite known weaknesses.

Fix: Replace all SHA-1 with SHA-256 or SHA-3. Re-sign all code and documents. Update all certificate chains.

Audit lesson: A.8.24 requires not just having a policy but actively enforcing it. SHA-1 in any certificate chain is an automatic non-conformity.

Illustrative Scenario 4: The Hardcoded Key Exposure (2023, SaaS Startup)

What happened: A SaaS startup had hardcoded AWS API keys in their public GitHub repository. An attacker found the keys, accessed their AWS account, and exfiltrated their entire customer database.

Root cause: Developers used hardcoded keys for local testing and accidentally committed them. No secrets scanning in CI/CD. No KMS in use.

Fix: Implement TruffleHog in CI/CD. Rotate all keys immediately. Deploy HashiCorp Vault or AWS Secrets Manager. Train developers on secure credential management.

Audit lesson: A.8.24 key management requires that keys never be stored in code, config files, or databases. HSM or KMS is mandatory for production keys.

Illustrative Scenario 5: The etcd Plaintext Exposure (2022, Kubernetes Cluster)

What happened: A security researcher gained access to a Kubernetes etcd backup and found all secrets stored in plaintext JSON. The cluster had not enabled etcd encryption.

Impact: All database passwords, API keys, and TLS private keys were exposed. Complete cluster compromise.

Root cause: Kubernetes does not enable etcd encryption by default. The operations team was unaware of the requirement.

Fix: Enable EncryptionConfiguration with KMS provider. Rotate all secrets after enabling encryption. Implement etcd backup encryption.

Audit lesson: A.8.24 applies to all data stores, including Kubernetes etcd. Default configurations are not secure configurations.

Multi-Framework Mapping

Annex A 8.24 Across Major Frameworks

Mapping: ISO 27001 A.8.24 → SOC 2 CC6.7

Mapping: ISO 27001 A.8.24 → PCI DSS v4.0

FAQ

General Questions

Q: Does ISO 27001:2022 A.8.24 require encryption for all data? A: No. It requires that rules for cryptography be defined and implemented based on risk assessment. Not all data needs encryption. Data classified as Public may not need encryption. Data classified as Confidential or Highly Confidential must be encrypted at rest and in transit. A.5.12 (Information classification) determines what gets encrypted.

Q: Is AES-128 sufficient for ISO 27001 compliance? A: AES-128 is not prohibited, but it is not recommended for new systems. Our policy mandates AES-256 for all new implementations. AES-128 may be acceptable for legacy systems with a documented migration plan. Auditors will ask about your rationale if you use AES-128.

Q: Do we need a HSM for ISO 27001? A: Not strictly required by ISO 27001 alone. However, if you handle PCI DSS, financial data, or government data, HSM is mandatory. For general ISO 27001, a KMS (AWS KMS, Azure Key Vault) is sufficient for most organizations. HSM is recommended for root CA keys and signing keys.

Q: Can we use Let's Encrypt for production certificates? A: Yes, for web servers and APIs. Let's Encrypt is a trusted public CA with WebTrust audit. However, it only issues DV certificates. For EV or code signing, you need a commercial CA like DigiCert or Sectigo. For internal services, consider an internal CA or Smallstep.

Q: What is the difference between BYOK and HYOK? A: BYOK (Bring Your Own Key) means you generate key material and import it into the cloud provider's KMS. The provider still holds the key. HYOK (Hold Your Own Key) means you keep the key in your own HSM and the cloud provider never has access. HYOK provides maximum control but requires dedicated HSM infrastructure.

Technical Questions

Q: Should we disable TLS 1.2 entirely? A: For external-facing services, TLS 1.3 only is ideal. For internal services, TLS 1.2 with strong cipher suites may be needed for legacy compatibility. TLS 1.0 and 1.1 must be disabled everywhere. Have a migration plan to move internal services to TLS 1.3.

Q: How do we handle encryption for legacy systems that can't be upgraded? A: Isolate them in a network segment with strict controls. Use a proxy or gateway to terminate TLS 1.3 externally and translate to the legacy protocol internally. Document the risk. Plan for replacement. This is a compensating control, not a permanent solution.

Q: What is the best approach for encrypting data in a microservices architecture? A: Use a service mesh (Istio, Linkerd, Cilium) for automatic mTLS between services. Use envelope encryption with a KMS for application-layer encryption. Store secrets in HashiCorp Vault or cloud-native secret stores. Enable etcd encryption for Kubernetes secrets.

Q: How often should we rotate encryption keys? A: Symmetric data keys: every 90 days. Asymmetric keys (signing, TLS): every 1 year. Root CA keys: every 5-10 years. Enable automatic rotation in your KMS where available. The key is not just rotation but also re-encryption of data with the new key.

Q: Can we use the same key for encryption and signing? A: No. Never use the same RSA key for both encryption and signing. This violates cryptographic separation of duties and can lead to attacks. Use separate keys for each purpose. ECDSA keys are only for signing; use ECDH for key exchange.

Q: How do we protect against quantum computers? A: Start with a cryptographic inventory. Identify all RSA, ECDSA, and DH usage. Draft a migration plan to adopt NIST post-quantum standards (ML-KEM, ML-DSA) by 2030. Consider hybrid approaches for critical systems. Monitor NIST and vendor roadmaps.

Audit Questions

Q: What evidence do auditors typically request for A.8.24? A: Signed cryptographic policy, algorithm inventory, key inventory, KMS/HSM configuration, TLS scan reports, certificate inventory, key rotation logs, HSM certificate, FIPS validation certificate (if applicable), code scan results (no hardcoded keys), and training records.

Q: How do we demonstrate key management compliance? A: Show key generation logs, key storage location (HSM/KMS), access control lists, rotation schedules, rotation completion logs, archival procedures, and destruction certificates. Dual control and split knowledge evidence is highly valued.

Q: Is open-source cryptography acceptable? A: Yes, if it is widely used and audited. OpenSSL, libsodium, BoringSSL, and Tink are all acceptable. The key is not whether it's open-source but whether it's validated, maintained, and uses approved algorithms. Avoid obscure or unmaintained libraries.

Q: What happens if we have a non-conformity in A.8.24? A: A minor non-conformity requires a corrective action plan with a timeline. A major non-conformity (e.g., no encryption on sensitive data, no key management) can block certification. Our clients achieve zero non-conformities in A.8.24 by following this guide.

Q: Do we need a dedicated cryptographer on staff? A: Not for most organizations. A security engineer with cryptographic training is sufficient. For fintech, healthtech, or government, a dedicated cryptographer or consultant is recommended. Singahi provides cryptographic expertise as a service.

Indian Regulatory Context and Illustrative Scenario for A.8.24

India has explicit expectations for cryptography in regulated sectors. RBI mandates that banks and NBFCs use strong encryption for data at rest and in transit, with key management governed by approved policies. SEBI requires market infrastructure institutions to encrypt sensitive trading and client data and to use HSMs for key protection. The DPDP Act 2023 does not prescribe specific algorithms, but Section 8(5) requires "reasonable security safeguards," which Indian auditors interpret as industry-standard encryption (AES-256, TLS 1.2+, RSA-2048+) and proper key management. CERT-In and MeitY guidelines encourage domestic encryption deployment for critical sectors, and some government projects require FIPS 140-2/3 or Common Criteria-certified modules.

Illustrative Scenario, Indian Payment Gateway Key Exposure (2023): A Bengaluru payment gateway discovered hard-coded API keys in a public GitHub repository. The keys granted access to a staging environment that contained production-clone transaction data, including card tokens and UPI handles. Although no fraud occurred, the exposure triggered a PCI DSS investigation, a CERT-In self-report and customer notifications. Root causes included no secrets-scanning in CI/CD, no centralized key management, and developers sharing keys over Slack. Remediation involved deploying HashiCorp Vault, rotating all keys, adding TruffleHog to the CI pipeline, and prohibiting long-lived API keys. The incident became the catalyst for an enterprise-wide cryptographic key management program.

Lessons:

• Never hard-code keys; use a secrets manager or HSM with programmatic rotation.
• Scan every commit for secrets; block merges that contain high-entropy strings.
• Segregate staging and production keys; assume staging data has production sensitivity.
• Maintain a cryptographic inventory and review it quarterly for weak or expiring keys.

📋 Summary Checklist: 48-Hour Quick Start

• Download the Cryptographic Policy Template (Hour 1)
• Customize with your organization name and approved algorithms (Hour 2-4)
• Run testssl.sh on all public domains, document findings (Hour 5-8)
• Scan all code repositories with TruffleHog, rotate any found keys (Hour 9-16)
• Inventory all certificates, check expiry, chain, signature algorithm (Hour 17-20)
• Check all databases for TDE, enable if missing (Hour 21-24)
• Sign the policy and publish to the ISMS (Hour 25-28)
• Schedule quarterly cryptographic review (Hour 29-32)
• Enable etcd encryption if running Kubernetes (Hour 33-36)
• Configure KMS auto-rotation for all symmetric keys (Hour 37-40)
• Set up certificate expiry monitoring (Hour 41-44)
• Brief the team on prohibited algorithms (Hour 45-48)
• Done. You have a working ISO 27001-compliant cryptographic program.

💡 Need help implementing this? Contact Singahi for a 20-minute readiness call. We build cryptographic programs in 12 weeks.