Cryptographic Standards Policy

Document ID: CODITECT-BIO-CRYPTO-001 Version: 1.0.0 Effective Date: 2026-02-16 Classification: Internal - Restricted Owner: Chief Information Security Officer (CISO)

---

Document Control

Approval History

Role	Name	Signature	Date
Chief Information Security Officer	[Pending]	[Digital Signature]	YYYY-MM-DD
VP Quality Assurance	[Pending]	[Digital Signature]	YYYY-MM-DD
VP Engineering	[Pending]	[Digital Signature]	YYYY-MM-DD
Regulatory Affairs Director	[Pending]	[Digital Signature]	YYYY-MM-DD

Revision History

Version	Date	Author	Changes	Approval Status
1.0.0	2026-02-16	CISO Office	Initial release	Draft

Distribution List

• Executive Leadership Team
• Information Security Team
• Quality Assurance Team
• Engineering Leadership
• Compliance and Regulatory Affairs
• Internal Audit

Review Schedule

Review Type	Frequency	Next Review Date	Responsible Party
Annual Review	12 months	2027-02-16	CISO
Regulatory Update Review	As needed	N/A	Regulatory Affairs
Post-Incident Review	As needed	N/A	Security Incident Response Team
Algorithm Deprecation Review	Quarterly	2026-05-16	Cryptography Working Group

---

1. Purpose and Scope

1.1 Purpose

This Cryptographic Standards Policy establishes the mandatory cryptographic requirements for the CODITECT Biosciences Quality Management System (BIO-QMS) Platform to ensure:

1. Data Integrity - Electronic records remain trustworthy and unaltered throughout their lifecycle
2. Data Confidentiality - Protected health information (PHI) and proprietary data remain confidential
3. Non-Repudiation - Electronic signatures provide legally binding evidence of approval actions
4. Regulatory Compliance - Full conformance with FDA 21 CFR Part 11, HIPAA, SOC 2, and applicable standards
5. Security Assurance - Defense-in-depth protection against cryptographic attacks and key compromise

1.2 Scope

This policy applies to:

In Scope:

• All cryptographic operations within BIO-QMS platform services
• Key management for signing, encryption, hashing, and authentication
• Electronic signature cryptographic bindings per FDA Part 11 §11.70
• Data encryption at rest and in transit (HIPAA §164.312)
• Audit log integrity mechanisms (SOC 2 CC6.1)
• API authentication and authorization tokens
• Inter-service communication security (mTLS)
• Third-party integrations requiring cryptographic controls

Out of Scope:

• End-user device encryption (managed by separate Mobile Device Management policy)
• Physical security controls (managed by separate Physical Security policy)
• Network layer DDoS protection (managed by separate Network Security policy)

1.3 Audience

• Primary: Security Engineers, Platform Engineers, DevOps Engineers
• Secondary: QA Engineers, Compliance Officers, Auditors
• Reference: Regulatory Affairs, Legal, Executive Leadership

---

2. Regulatory Requirements Mapping

2.1 Regulatory Framework Overview

The BIO-QMS platform operates under multiple regulatory frameworks with overlapping cryptographic requirements:

Framework	Authority	Key Requirements	Applicability
FDA 21 CFR Part 11	U.S. Food and Drug Administration	§11.10(c) integrity checks §11.70 signature/record linking §11.30 controls for open systems	All electronic records and signatures in GxP workflows
HIPAA Security Rule	U.S. Department of Health and Human Services	§164.312(a)(2)(iv) encryption §164.312(e)(2)(ii) transmission security	All protected health information (PHI)
SOC 2 Type II	AICPA Trust Services Criteria	CC6.1 logical access CC6.6 encryption CC6.7 key management	All platform operations for customer trust
NIST SP 800-57	National Institute of Standards and Technology	Key management best practices Algorithm transition guidance	Key lifecycle operations
FIPS 140-2/140-3	NIST Cryptographic Module Validation Program	Level 3 HSM validation Approved algorithm implementation	Hardware security modules and cryptographic libraries

2.2 Detailed Regulatory Mapping

FDA 21 CFR Part 11 - Electronic Records and Signatures

Citation	Requirement	Cryptographic Control	Implementation
§11.10(c)	Generate accurate and complete copies of records	SHA-256 content hashing	Audit log integrity chain
§11.10(e)	Record audit trail for operator actions	SHA-256 HMAC with KMS key	Tamper-evident audit entries
§11.70	Signature/record linking	ECDSA P-256 digital signature binding approval identity to document hash	E-signature service two-phase flow
§11.200(a)(1)	Unique signature representations	ECDSA P-256 keypair per authorized signer	HSM-generated user signing keys
§11.200(a)(2)	Verification of signer identity	Password + TOTP or biometric re-authentication	AuthMethod multi-factor
§11.300	Signature manifestations in record	Signer name, timestamp, meaning, cryptographic hash	SignatureManifest embedded in PDF/audit trail

HIPAA Security Rule - 45 CFR §164.312

Citation	Requirement	Cryptographic Control	Implementation
§164.312(a)(2)(iv)	Encryption and decryption (addressable)	AES-256-GCM for data at rest	Database column encryption, file storage encryption
§164.312(e)(1)	Transmission security	TLS 1.3 with ECDSA P-256 certificates	mTLS for all service-to-service, API gateway TLS termination
§164.312(e)(2)(i)	Integrity controls (addressable)	SHA-256 checksums for file transfers	Message digest validation on upload/download
§164.312(e)(2)(ii)	Encryption (addressable)	TLS 1.3 mandatory, no fallback	Zero-trust network architecture

SOC 2 Type II Trust Service Criteria

Criterion	Control Requirement	Cryptographic Control	Implementation
CC6.1	Logical and physical access controls	RSA-2048 JWT signatures for API authentication	Auth service token signing
CC6.6	Encryption of data at rest and in transit	AES-256-GCM (rest), TLS 1.3 (transit)	KMS key hierarchy, certificate management
CC6.7	Encryption key management procedures	Annual key rotation, HSM storage, access logging	Key management lifecycle (Section 6)
CC7.2	System monitoring for anomalies	HMAC-SHA256 log integrity, alerting on key usage anomalies	CloudWatch metrics, Security Hub findings

NIST SP 800-57 - Key Management Recommendations

Requirement	Cryptographic Control	Implementation
Part 1, Section 5.3.3 - Cryptoperiod determination	90-day JWT signing keys, annual e-signature keys	Automated rotation via KMS
Part 1, Section 8.3.1 - Key generation entropy	FIPS 140-2 Level 3 HSM random number generator	AWS CloudHSM FIPS-validated
Part 1, Section 8.3.4 - Key distribution	AES-256-KW key wrapping, TLS 1.3 secure channels	KMS key import/export protocols
Part 1, Section 8.3.5 - Key storage	HSM for signing/encryption, KMS for operational, Vault for secrets	Multi-tier key storage architecture
Part 1, Section 8.3.7 - Key destruction	NIST SP 800-88 zeroization, 3-pass overwrite minimum	KMS ScheduleKeyDeletion, HSM zeroize

---

3. Approved Cryptographic Algorithms

3.1 Algorithm Selection Criteria

All cryptographic algorithms approved for use in BIO-QMS platform MUST meet the following criteria:

1. Standards Compliance - Published by NIST, ISO, or recognized standards body
2. Regulatory Acceptance - Explicitly approved or no known objections from FDA, HHS, AICPA
3. Security Margin - No practical attacks reducing security below 112-bit equivalent strength
4. Performance - Acceptable latency for real-time operations (<100ms for signature verification)
5. Implementation Quality - FIPS 140-2 validated libraries available (OpenSSL FIPS, AWS crypto libraries)
6. Forward Compatibility - No planned deprecation within 5-year lifecycle

3.2 Approved Algorithms by Category

3.2.1 Asymmetric Cryptography (Public-Key)

Algorithm	Key Size	Use Cases	Rationale	FIPS 186-5 Status	Expiration
ECDSA P-256	256-bit (secp256r1)	• E-signature binding • TLS certificates • API token signing • Audit log signing	NSA Suite B, ~128-bit security, excellent performance, broad library support	Approved	No planned deprecation
RSA-2048	2048-bit	• JWT signing (legacy compatibility) • Key wrapping (backup)	Industry standard, ~112-bit security, compatibility with SAML/OIDC providers	Approved	2030 (migrate to ECDSA)
ECDH P-256	256-bit (secp256r1)	• TLS 1.3 key exchange • Secure channel establishment	Ephemeral key exchange, perfect forward secrecy	Approved	No planned deprecation
X25519	256-bit (Curve25519)	• Inter-agent encrypted messaging • Secure multi-party computation	Modern elliptic curve, fast constant-time implementation	Approved (SP 800-186)	No planned deprecation

Selection Rationale:

• ECDSA P-256 chosen over RSA-4096 for e-signatures due to 10x faster signature generation (critical for high-throughput approval workflows) and smaller signature size (64 bytes vs 512 bytes).
• RSA-2048 retained for JWT signing to maintain compatibility with existing SAML/OIDC identity providers during migration period (90-day cryptoperiod limits exposure).
• X25519 selected for agent messaging due to constant-time implementation resistant to timing attacks.

3.2.2 Symmetric Cryptography (Secret-Key)

Algorithm	Key Size	Mode	Use Cases	Rationale	FIPS 197 Status	Expiration
AES-256-GCM	256-bit	Galois/Counter Mode	• Database column encryption • File storage encryption • Backup encryption • Session token encryption	Authenticated encryption (confidentiality + integrity), parallelizable, ~256-bit security	Approved	No planned deprecation
AES-256-KW	256-bit	Key Wrap (RFC 3394)	• KMS key wrapping • HSM key import/export	Specialized algorithm for cryptographic key material protection	Approved	No planned deprecation
ChaCha20-Poly1305	256-bit	AEAD	• Mobile agent apps (low-power devices) • Performance-critical paths	Constant-time, no AES-NI hardware required, IETF standard (RFC 8439)	Not FIPS (allowed for non-FIPS-required contexts)	No planned deprecation

Selection Rationale:

• AES-256-GCM mandatory for all FIPS-required encryption contexts (PHI, GxP records).
• ChaCha20-Poly1305 allowed ONLY for non-PHI mobile contexts where AES hardware acceleration unavailable.
• No CBC/CTR modes - GCM/AEAD required to prevent padding oracle and integrity attacks.

3.2.3 Cryptographic Hash Functions

Algorithm	Output Size	Use Cases	Rationale	FIPS 180-4 Status	Expiration
SHA-256	256-bit (32 bytes)	• Document content hashing (FDA §11.70) • Audit log integrity chains • Password hashing (with PBKDF2) • HMAC for message authentication	Industry standard, 128-bit collision resistance, excellent performance	Approved	No planned deprecation
SHA-512	512-bit (64 bytes)	• High-security contexts • Long-term archive integrity • HMAC-SHA512 for critical secrets	256-bit collision resistance, future-proof	Approved	No planned deprecation
SHA-3-256	256-bit (32 bytes)	• Post-quantum preparation • Diversification from SHA-2	Keccak sponge construction, different design from SHA-2	Approved (FIPS 202)	No planned deprecation

Selection Rationale:

• SHA-256 is the platform default for all integrity use cases (balance of security and performance).
• SHA-512 reserved for long-term archives (>10 year retention) and master key derivation.
• SHA-3-256 allowed for future post-quantum transition scenarios.

3.2.4 Message Authentication Codes (MAC)

Algorithm	Key Size	Output Size	Use Cases	Rationale	FIPS 198-1 Status	Expiration
HMAC-SHA256	256-bit	256-bit	• Audit log entry integrity • Inter-service authentication • Webhook signature verification	Provable security reduction to hash function, widely supported	Approved	No planned deprecation
HMAC-SHA512	512-bit	512-bit	• Agent messaging integrity • Master key derivation (HKDF)	Higher security margin for sensitive contexts	Approved	No planned deprecation

3.2.5 Key Derivation Functions (KDF)

Algorithm	Parameters	Use Cases	Rationale	NIST Status	Expiration
PBKDF2-HMAC-SHA256	600,000 iterations minimum	• Password-to-key derivation • User credential storage	FIPS-approved, OWASP recommended iteration count	NIST SP 800-132	No planned deprecation
HKDF-SHA256	Extract-and-Expand	• Master key to derived keys • Session key generation	Provably secure, efficient, IETF standard (RFC 5869)	NIST SP 800-56C Rev 2	No planned deprecation
scrypt	N=2^17, r=8, p=1	• High-security password hashing (admin accounts)	Memory-hard, ASIC-resistant	Not FIPS (allowed for non-FIPS contexts)	No planned deprecation

Selection Rationale:

• PBKDF2 used for all FIPS-required password hashing (600k iterations balances security and UX per OWASP 2023).
• scrypt allowed ONLY for administrator accounts (higher attack value justifies memory-hard function).
• Argon2id evaluated but not approved pending FIPS standardization (revisit 2027).

3.2.6 Digital Signature Schemes

Scheme	Algorithm	Use Cases	Rationale	FIPS 186-5 Status	Expiration
ECDSA-SHA256	ECDSA P-256 + SHA-256	• Electronic signatures (FDA Part 11) • Code signing • Document signing	Small signature size (64 bytes), fast verification	Approved	No planned deprecation
RSA-PSS-SHA256	RSA-2048 + PSS padding	• Legacy system integration • SAML assertions	Provable security, deterministic padding	Approved	2030 (migrate to ECDSA)

---

4. Prohibited Algorithms

The following cryptographic algorithms are STRICTLY PROHIBITED for any use in the BIO-QMS platform due to known vulnerabilities, insufficient key sizes, or regulatory deprecation:

4.1 Prohibited Hash Functions

Algorithm	Reason for Prohibition	Migration Deadline	Remediation
MD5	Collision attacks practical since 2004, NIST deprecated 2011	Immediate	Replace with SHA-256
SHA-1	Collision attacks demonstrated 2017 (SHAttered), NIST deprecated 2022	2025-12-31 (certificate use only)	Replace with SHA-256 or SHA-3
MD4	Cryptographically broken since 1995	Immediate	Replace with SHA-256

4.2 Prohibited Symmetric Ciphers

Algorithm	Reason for Prohibition	Migration Deadline	Remediation
DES	56-bit key brute-forced in 1998	Immediate	Replace with AES-256-GCM
3DES (Triple-DES)	NIST deprecated 2023, 112-bit security insufficient	2024-12-31	Replace with AES-256-GCM
RC4	Biases in keystream exploitable (NOMORE attack 2015)	Immediate	Replace with AES-256-GCM or ChaCha20
Blowfish	64-bit block size vulnerable to birthday attacks	Immediate	Replace with AES-256-GCM
AES-ECB	Mode lacks IV, identical plaintext → identical ciphertext	Immediate	Replace with AES-256-GCM
AES-CBC (without HMAC)	Padding oracle attacks (POODLE, Lucky13)	Immediate	Replace with AES-256-GCM (authenticated encryption)

4.3 Prohibited Asymmetric Algorithms

Algorithm	Reason for Prohibition	Migration Deadline	Remediation
RSA < 2048-bit	NIST deprecated 2013, <112-bit equivalent security	Immediate	Replace with RSA-2048 or ECDSA P-256
DSA < 2048-bit	NIST deprecated 2013, weak parameter generation	Immediate	Replace with ECDSA P-256
Diffie-Hellman < 2048-bit	Logjam attack 2015, export-grade DHE vulnerable	Immediate	Replace with ECDH P-256 or X25519
ElGamal	Non-standard implementation risks, superseded by ECDH	Immediate	Replace with ECDH P-256

4.4 Prohibited TLS/SSL Versions

Protocol	Reason for Prohibition	Migration Deadline	Remediation
SSL 2.0	Multiple critical vulnerabilities (DROWN attack)	Immediate	Enforce TLS 1.3 minimum
SSL 3.0	POODLE attack 2014, CBC mode vulnerabilities	Immediate	Enforce TLS 1.3 minimum
TLS 1.0	CBC vulnerabilities (BEAST attack), weak ciphers	Immediate	Enforce TLS 1.3 minimum
TLS 1.1	No AEAD cipher suites, PCI DSS prohibited 2020	Immediate	Enforce TLS 1.3 minimum
TLS 1.2	Allowed for legacy compatibility ONLY (2026-2027)	2027-12-31	Migrate to TLS 1.3

TLS 1.2 Exception Process: Legacy integrations requiring TLS 1.2 MUST obtain written CISO approval, document in exception register, and enforce cipher suite restrictions:

• ALLOWED: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• PROHIBITED: All CBC-mode ciphers, all RSA key exchange (no forward secrecy)

---

5. TLS Configuration Standards

5.1 TLS 1.3 Mandatory Configuration

Scope: All HTTPS endpoints, API gateways, inter-service mTLS, database connections (where supported).

Cipher Suite Priority Order:

1. TLS_AES_256_GCM_SHA384 (ECDHE-ECDSA implied in TLS 1.3)
2. TLS_CHACHA20_POLY1305_SHA256 (mobile/low-power clients only)
3. TLS_AES_128_GCM_SHA256 (NOT RECOMMENDED, allowed for compatibility)

Certificate Requirements:

• Algorithm: ECDSA P-256 (preferred) or RSA-2048 (legacy compatibility)
• Signature: ECDSA-SHA256 or RSA-PSS-SHA256
• Validity Period: 397 days maximum (per CA/Browser Forum Baseline Requirements)
• Subject Alternative Names (SAN): All DNS names and service identities
• OCSP Stapling: MUST be enabled for certificate revocation checking

TLS Session Parameters:

• Session Tickets: Disabled (no stateful session resumption to enforce perfect forward secrecy)
• Session Cache: Disabled
• Renegotiation: Disabled
• Compression: Disabled (CRIME attack mitigation)

5.2 mTLS (Mutual TLS) Requirements

Scope: All inter-service communication in zero-trust network architecture.

Client Certificate Validation:

• Client MUST present valid certificate signed by internal CA
• Certificate MUST contain service identity in SAN (e.g., service-name.coditect-bio-qms.internal)
• OCSP/CRL check MUST pass (allow 5-second grace period for OCSP responder latency)
• Certificate MUST NOT be within 30 days of expiration (automated renewal warning)

Example Nginx Configuration:

ssl_protocols TLSv1.3;
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256';
ssl_prefer_server_ciphers on;
ssl_session_cache off;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;

# mTLS client verification
ssl_verify_client on;
ssl_client_certificate /etc/ssl/certs/internal-ca.pem;
ssl_verify_depth 2;
ssl_crl /etc/ssl/certs/internal-crl.pem;

---

6. Key Management Lifecycle

6.1 Key Lifecycle Phases

All cryptographic keys used in the BIO-QMS platform MUST follow a standardized lifecycle:

[Generation] → [Storage] → [Distribution] → [Active Use] → [Rotation] → [Archival] → [Destruction]
     ↓              ↓            ↓               ↓             ↓            ↓             ↓
   Entropy     HSM/KMS/Vault  Encrypted    Audit Logging  Automated   Immutable    Zeroization
   Validation   Segregation   Channels     Access Control  Renewal     Retention    3-pass overwrite

6.2 Key Generation Requirements

6.2.1 Entropy Sources

All key generation MUST use cryptographically secure random number generators (CSRNG):

Key Type	Entropy Source	Validation	Backup Entropy
HSM-generated keys (e-signature, TLS CA)	AWS CloudHSM FIPS 140-2 Level 3 TRNG	NIST SP 800-90B compliance certificate	N/A (hardware failure triggers HSM replacement)
KMS-generated keys (data encryption, JWT signing)	AWS KMS FIPS 140-2 Level 3 validated	AWS KMS service SLA	N/A (service-managed)
Application-generated keys (session tokens, TOTP secrets)	/dev/urandom (Linux kernel CSPRNG)	getrandom(2) syscall with GRND_RANDOM flag	Fallback to OpenSSL RAND_bytes() FIPS module

Entropy Testing: HSM and KMS entropy sources MUST pass NIST SP 800-90B health tests on monthly basis (automated CloudWatch alarm on failure).

6.2.2 Key Size Requirements

Algorithm	Minimum Key Size	Recommended Key Size	Rationale
ECDSA	256-bit (P-256)	256-bit	NSA Suite B, ~128-bit security, no benefit to P-384 for current threat model
RSA	2048-bit	2048-bit	NIST minimum through 2030, 4096-bit offers marginal security at 4x performance cost
AES	128-bit	256-bit	256-bit provides safety margin for long-lived encrypted data (>10 years)
HMAC	256-bit (SHA-256)	256-bit	Match underlying hash function output size per NIST SP 800-107

6.3 Key Storage Architecture

6.3.1 Storage Tier Classification

Tier	Technology	Key Types	Access Control	Backup Strategy
Tier 1: HSM	AWS CloudHSM (FIPS 140-2 Level 3)	• E-signature user keys • TLS CA root key • Master audit signing key	Hardware authentication, quorum approval (3-of-5 for root CA)	Encrypted HSM backup to S3 with KMS envelope encryption, cross-region replication
Tier 2: KMS	AWS KMS (FIPS 140-2 Level 3)	• JWT signing keys • Data encryption keys • Audit log HMAC keys • Database column keys	IAM policy + key policy, service-to-service grants	Automatic multi-region replication, 30-day deletion waiting period
Tier 3: Vault	HashiCorp Vault (encrypted backend)	• API secrets • Agent messaging keys • Third-party credentials • TOTP seeds	Namespace-scoped tokens, policy-based ACLs	Automated snapshots to S3, encrypted with KMS, 7-day retention
Tier 4: Application	Encrypted PostgreSQL columns	• User password hashes (PBKDF2) • Session tokens (encrypted with KMS DEK)	Row-level security (RLS), application-layer authorization	Standard database backup, encrypted at rest with KMS

6.3.2 Key Storage Security Controls

HSM Security Controls:

• Physical tamper-evident seals on HSM hardware
• Dual-control activation (2 administrator smart cards required)
• Quorum approval for root CA operations (3-of-5 key custodians)
• Audit logging to immutable S3 bucket (CloudTrail + HSM internal log)
• HSM firmware updates require FIPS re-validation

KMS Security Controls:

• Automatic key rotation enabled for customer-managed keys (CMK)
• Key policies enforcing least-privilege access (no kms:* wildcards)
• VPC endpoint for KMS API (no internet egress for key material)
• CloudTrail logging of all key operations to dedicated S3 bucket
• SCPs preventing KMS key deletion by non-security-team principals

Vault Security Controls:

• TLS 1.3 for all Vault API connections
• AppRole authentication with secret rotation
• Dynamic secrets with 1-hour TTL for database credentials
• Seal/unseal keys split across 5 key shares (3 required to unseal)
• Audit device writing to CloudWatch Logs for SIEM ingestion

6.4 Key Distribution

Secure Distribution Channels:

Scenario	Distribution Method	Encryption	Authentication
HSM to service	KMS ImportKeyMaterial API with wrapping key	AES-256-KW key wrapping with KMS public wrapping key	TLS 1.3 mTLS with service identity certificate
KMS to application	Envelope encryption (KMS encrypts DEK, application decrypts)	AES-256-GCM data key encrypted by KMS CMK	IAM role credentials, KMS grant for specific service
Vault to service	Dynamic secret generation, API response	TLS 1.3 encrypted response body	AppRole secret_id (single-use token)
Service to service	JWT with asymmetric signature	N/A (public key cryptography)	ECDSA P-256 signature verification

Prohibited Distribution Methods:

• Email (plaintext or encrypted) - NO EXCEPTIONS
• Shared file systems (NFS, SMB) without additional encryption
• Environment variables (risk of exposure in logs/core dumps)
• Configuration management systems (Ansible, Chef) without Vault integration

6.5 Key Rotation Schedule

6.5.1 Automated Rotation

Key Type	Algorithm	Rotation Period	Automation	Rollover Strategy
JWT signing key	RSA-2048	90 days	KMS automatic rotation + Lambda update to auth service	Overlapping validity: new key signs, old key verifies for 24h grace period
Data encryption key (DEK)	AES-256-GCM	Annual	KMS automatic rotation	Envelope encryption: re-encrypt DEK, data remains encrypted with original DEK
Agent messaging key	HMAC-SHA256	30 days	Vault dynamic secret TTL	New secret generation, 5-minute overlap for in-flight messages
Database credentials	N/A (not cryptographic key)	24 hours	Vault database secrets engine	Username rotation, connection pool refresh
TLS leaf certificates	ECDSA P-256	90 days	cert-manager (Kubernetes) + ACME protocol	30-day pre-expiration renewal, zero-downtime pod rotation

Automation Implementation:

# Example: KMS JWT key rotation Lambda function
import boto3
import json
from datetime import datetime, timedelta

kms = boto3.client('kms')
ssm = boto3.client('ssm')

def lambda_handler(event, context):
    """Rotate JWT signing key every 90 days"""

    # Create new KMS key
    new_key = kms.create_key(
        Description=f'JWT signing key - {datetime.utcnow().isoformat()}',
        KeyUsage='SIGN_VERIFY',
        KeySpec='RSA_2048',
        Origin='AWS_KMS',
        Tags=[
            {'TagKey': 'Purpose', 'TagValue': 'JWT-Signing'},
            {'TagKey': 'Rotation', 'TagValue': 'Automated'}
        ]
    )

    new_key_id = new_key['KeyMetadata']['KeyId']

    # Store new key ID in Parameter Store
    ssm.put_parameter(
        Name='/bio-qms/auth/jwt-signing-key-id',
        Value=new_key_id,
        Type='String',
        Overwrite=True
    )

    # Schedule old key deletion (30-day waiting period)
    old_key_id = ssm.get_parameter(Name='/bio-qms/auth/jwt-signing-key-id-previous')['Parameter']['Value']
    kms.schedule_key_deletion(KeyId=old_key_id, PendingWindowInDays=30)

    # Update previous key pointer
    ssm.put_parameter(
        Name='/bio-qms/auth/jwt-signing-key-id-previous',
        Value=old_key_id,
        Type='String',
        Overwrite=True
    )

    return {
        'statusCode': 200,
        'body': json.dumps({
            'message': 'JWT signing key rotated successfully',
            'new_key_id': new_key_id,
            'old_key_scheduled_deletion': old_key_id
        })
    }

6.5.2 Manual Rotation (High-Security Keys)

Key Type	Algorithm	Rotation Period	Approval Required	Process
E-signature user keys	ECDSA P-256	Annual	QA Manager approval	1. Generate new keypair in HSM 2. User re-authentication (password + TOTP) 3. Old key archived with 7-year retention 4. New key activated in user_signing_keys table
Audit log master signing key	HMAC-SHA256	Annual	CISO approval	1. Generate new KMS key 2. Dual-administrator approval in change management 3. Integrity chain includes key rotation event 4. Old key retained for historical verification (10-year retention)
TLS CA root key	ECDSA P-256	5 years	Executive approval (CEO/CTO/CISO)	1. Quorum ceremony (3-of-5 key custodians present) 2. Generate new root CA in air-gapped HSM 3. Cross-sign old and new root (1-year overlap) 4. Gradual certificate re-issuance (12-month migration)

Manual Rotation Procedure (E-Signature Example):

1. Notification (T-30 days): Email user that key rotation required, schedule rotation window
2. Pre-Rotation Validation (T-7 days): Verify user has valid MFA device, no pending signatures
3. Rotation Execution (T-0):
   • User logs in, prompted for key rotation
   • User re-authenticates with password + TOTP (6-digit code)
   • System generates new ECDSA P-256 keypair in HSM partition for user
   • Old keypair archived to user_signing_keys_archive table with archived_at timestamp
   • New keypair activated with created_at timestamp
   • Audit log entry created: USER_SIGNING_KEY_ROTATED event
4. Post-Rotation Verification (T+1 day): User performs test signature, verification against new public key succeeds

6.6 Key Revocation

6.6.1 Revocation Triggers

Trigger	Response Time	Procedure	Notification
User termination	Immediate (within 1 hour)	Disable user account, archive signing key, revoke certificates	Security team, manager
Key compromise suspected	Immediate (within 15 minutes)	Incident response plan activated, key disabled, forensic investigation	CISO, incident response team, affected users
HSM tamper event	Immediate (automatic)	HSM zeroizes all keys, backup restoration from encrypted S3	Security team, CISO, vendor support
Certificate private key exposure	Immediate (within 1 hour)	Revoke certificate via CRL/OCSP, re-issue new certificate	Certificate owner, security team
Routine key rotation	Scheduled (see §6.5)	Graceful transition with overlap period	Key owner (automated notification)

6.6.2 Revocation Mechanisms

Certificate Revocation:

• CRL (Certificate Revocation List): Published hourly to https://crl.coditect-bio-qms.internal/root-ca.crl, 7-day validity
• OCSP (Online Certificate Status Protocol): Real-time responder at https://ocsp.coditect-bio-qms.internal, 1-hour response cache
• OCSP Stapling: Enabled on all TLS endpoints (server fetches OCSP response, includes in handshake)

Key Revocation:

• HSM Keys: Immediate deletion command (cloudhsm-cli key delete), audit log entry, backup retention for legal hold only
• KMS Keys: DisableKey API call (immediate), ScheduleKeyDeletion after incident investigation complete (30-day minimum)
• Vault Keys: vault lease revoke (dynamic secrets), vault delete (static secrets)

Example Incident Response Playbook (Key Compromise):

# IR-CRYPTO-001: Suspected Key Compromise Response
trigger: Security alert indicating possible key exposure (e.g., key material in log file)
severity: CRITICAL
response_time: 15 minutes

steps:
  1_assess:
    action: Determine key type and scope of exposure
    owner: Security Engineer On-Call
    duration: 5 minutes

  2_contain:
    action: Disable compromised key immediately
    owner: Security Engineer
    tools:
      - HSM: cloudhsm-cli key disable --key-id <KEY_ID>
      - KMS: aws kms disable-key --key-id <KEY_ID>
      - Vault: vault lease revoke -prefix secret/
    duration: 5 minutes

  3_investigate:
    action: Forensic analysis of exposure vector
    owner: Security Incident Response Team
    artifacts:
      - CloudTrail logs (90-day retention)
      - Application logs (1-year retention)
      - HSM audit logs (7-year retention)
    duration: 4 hours

  4_rotate:
    action: Generate new key, migrate services
    owner: Platform Engineering + Security
    validation:
      - New key generated with fresh entropy
      - No reuse of key material
      - All dependent services updated
    duration: 8 hours

  5_notify:
    action: Breach notification (if PHI/PII exposure confirmed)
    owner: Legal + Compliance
    regulatory:
      - HIPAA: 60-day notification to HHS if PHI exposed
      - State breach laws: Notification to affected individuals
    duration: 24-72 hours

  6_postmortem:
    action: Root cause analysis and remediation
    owner: CISO
    deliverable: Incident report with lessons learned
    timeline: 7 days post-incident

6.7 Key Archival and Retention

6.7.1 Retention Requirements by Key Type

Key Type	Retention Period	Regulatory Driver	Storage Location	Access Control
E-signature user keys	7 years post-signature	FDA Part 11 (record retention)	HSM backup encrypted with KMS, S3 Glacier Deep Archive	CISO approval required, audit logged
Audit log signing keys	10 years	SOC 2 (log integrity verification)	KMS with deletion protection, cross-region replication	Security team read-only, CISO delete-only
Data encryption keys	Life of encrypted data + 1 year	HIPAA (data recovery)	KMS automatic retention, no manual deletion	Service role access via key policy grants
TLS certificates (revoked)	7 years	CA/Browser Forum Baseline Requirements	S3 with versioning, encrypted at rest	Certificate management team read-only
Revoked credentials	3 years	Incident investigation	Vault encrypted backend, automated snapshot	Security incident response team

6.7.2 Archival Procedures

HSM Key Backup to S3:

#!/bin/bash
# HSM backup script (executed quarterly)

BACKUP_DATE=$(date +%Y%m%d)
HSM_CLUSTER_ID="cluster-abc123"
S3_BUCKET="coditect-bio-qms-hsm-backups"
KMS_KEY_ID="arn:aws:kms:us-east-1:123456789012:key/xyz"

# Create encrypted backup
aws cloudhsmv2 create-backup \
  --cluster-id $HSM_CLUSTER_ID \
  --description "Quarterly backup $BACKUP_DATE" \
  --tags Key=BackupType,Value=Quarterly

# Wait for backup completion
BACKUP_ID=$(aws cloudhsmv2 describe-backups --filters clusterIds=$HSM_CLUSTER_ID \
  --query 'Backups[0].BackupId' --output text)

# Export backup to S3 with KMS envelope encryption
aws s3 cp $BACKUP_ID s3://$S3_BUCKET/backups/$BACKUP_DATE/ \
  --sse aws:kms \
  --sse-kms-key-id $KMS_KEY_ID \
  --storage-class GLACIER

# Verify backup integrity
aws s3api head-object --bucket $S3_BUCKET --key backups/$BACKUP_DATE/

Restoration Testing:

• Quarterly disaster recovery drill: Restore HSM from backup to test cluster, verify key import
• Annual full restoration: Complete platform rebuild from backups (RTO target: 4 hours)

6.8 Key Destruction

6.8.1 Destruction Standards

All key destruction MUST follow NIST SP 800-88 Rev 1 guidelines for media sanitization.

Key Storage Medium	Destruction Method	Validation	Timeframe
HSM (hardware)	Cryptographic zeroization (FIPS 140-2 requirement)	HSM audit log entry KEY_DESTROYED, tamper seal verification	Immediate on revocation
KMS (service-managed)	ScheduleKeyDeletion with 30-day minimum waiting period	CloudTrail log entry, key state = PendingDeletion	30 days post-disable (configurable 7-365 days)
Volatile memory (RAM)	Explicit memset to zero, followed by free	Static analysis (no compiler optimization of memset_s)	Immediate on key scope exit
Persistent storage (disk)	3-pass overwrite: 0x00, 0xFF, random bytes	shred -vfz -n 3 verification output	Within 24 hours of archival period end
Backup media (S3 Glacier)	S3 object deletion with MFA delete enabled	S3 delete marker + version purge, CloudTrail log	Within 30 days of retention expiration

6.8.2 Secure Memory Handling (Application Code)

Example: Secure key material handling in Python:

import ctypes
import os
from typing import Union

class SecureBytes:
    """
    Memory-safe byte array for cryptographic key material.
    Zeroes memory on deletion per NIST SP 800-88.
    """

    def __init__(self, data: Union[bytes, bytearray]):
        self._data = bytearray(data)
        self._ptr = (ctypes.c_char * len(self._data)).from_buffer(self._data)

    def __del__(self):
        """Explicit zeroization on garbage collection"""
        if hasattr(self, '_data'):
            # Use ctypes.memset to prevent compiler optimization
            ctypes.memset(self._ptr, 0, len(self._data))
            # Overwrite with random bytes (defense in depth)
            self._data[:] = os.urandom(len(self._data))
            # Final zero pass
            ctypes.memset(self._ptr, 0, len(self._data))

    def get(self) -> bytes:
        """Return immutable copy (caller responsible for zeroization)"""
        return bytes(self._data)

# Usage example
def decrypt_sensitive_data(ciphertext: bytes, kms_key_id: str) -> bytes:
    import boto3
    kms = boto3.client('kms')

    # Decrypt data encryption key
    response = kms.decrypt(
        CiphertextBlob=ciphertext[:256],  # First 256 bytes = encrypted DEK
        KeyId=kms_key_id
    )

    # Store DEK in secure memory
    dek = SecureBytes(response['Plaintext'])

    try:
        # Use DEK for decryption (AES-256-GCM)
        from cryptography.hazmat.primitives.ciphers.aead import AESGCM
        aesgcm = AESGCM(dek.get())
        plaintext = aesgcm.decrypt(
            nonce=ciphertext[256:268],  # 12-byte nonce
            data=ciphertext[268:],       # Ciphertext + tag
            associated_data=b'bio-qms'
        )
        return plaintext
    finally:
        # DEK automatically zeroized when `dek` goes out of scope
        del dek

---

7. Key Types and Purposes

7.1 Key Inventory

The following table documents all cryptographic keys used in the BIO-QMS platform:

Key Name	Purpose	Algorithm	Key Size	Storage Tier	Rotation Period	Owner	Status
root-ca-key	Root certificate authority for internal PKI	ECDSA P-256	256-bit	HSM (Tier 1)	5 years (manual)	Security Team	Active
issuing-ca-key	Intermediate CA for service certificates	ECDSA P-256	256-bit	HSM (Tier 1)	2 years (manual)	Security Team	Active
user-signing-key-{user_id}	E-signature binding per FDA Part 11 §11.70	ECDSA P-256	256-bit	HSM (Tier 1)	Annual (manual)	Individual Users	Active
jwt-signing-key	API access token signatures	RSA-2048	2048-bit	KMS (Tier 2)	90 days (auto)	Auth Service	Active
jwt-signing-key-next	Overlapping JWT key during rotation	RSA-2048	2048-bit	KMS (Tier 2)	90 days (auto)	Auth Service	Rotating
audit-log-hmac-key	Audit log integrity chain	HMAC-SHA256	256-bit	KMS (Tier 2)	Annual (manual)	Audit Service	Active
data-encryption-key-{service}	Database column encryption	AES-256-GCM	256-bit	KMS (Tier 2)	Annual (auto)	Platform Services	Active
file-storage-encryption-key	S3 object encryption (envelope)	AES-256-GCM	256-bit	KMS (Tier 2)	Annual (auto)	Storage Service	Active
agent-messaging-key	Inter-agent HMAC authentication	HMAC-SHA256	256-bit	Vault (Tier 3)	30 days (auto)	Agent Orchestration	Active
webhook-signature-key-{tenant}	Outbound webhook HMAC	HMAC-SHA256	256-bit	Vault (Tier 3)	Annual (manual)	Integration Service	Active
backup-encryption-key	Database backup encryption	AES-256-GCM	256-bit	KMS (Tier 2)	Annual (auto)	Backup Service	Active
session-token-encryption-key	Encrypted session cookies	AES-256-GCM	256-bit	KMS (Tier 2)	Annual (auto)	Auth Service	Active
totp-seed-{user_id}	TOTP MFA secret (RFC 6238)	HMAC-SHA1 (TOTP standard)	160-bit	Vault (Tier 3)	Never (user re-enrollment)	Individual Users	Active
database-credential-{service}	Dynamic database passwords	N/A (not crypto key)	N/A	Vault (Tier 3)	24 hours (auto)	Database Services	Active

7.2 Key Usage Restrictions

Role-Based Key Access Control:

Key Type	Authorized Services	Prohibited Uses	Audit Logging
E-signature keys	Approval Service (signature creation), Verification Service (signature validation)	NEVER for encryption, NEVER exported from HSM	All signature operations logged with user ID, document hash, timestamp
JWT signing keys	Auth Service (token issuance), API Gateway (token verification)	NEVER for long-lived credentials (max 1-hour token TTL)	Token issuance rate monitored (anomaly detection at >1000/min per user)
Data encryption keys	Service-specific grants (1 KMS key per microservice)	NEVER shared across services, NEVER for signing	KMS CloudTrail logs all encrypt/decrypt calls with service identity
Audit log keys	Audit Service (write-only), Compliance Reporting (read-only)	NEVER for application data integrity (separate concern)	Key usage monitored, alert on >1000 HMAC/sec (DDoS indicator)

---

8. Compliance Mapping Matrix

8.1 FDA 21 CFR Part 11 Compliance Controls

Requirement	Citation	Control	Implementation	Evidence	Status
Validation of systems	§11.10(a)	Cryptographic library validation	OpenSSL FIPS 140-2 module, AWS crypto SDK validation certificates	docs/validation/openssl-fips-validation-certificate.pdf	✅ Ready
Audit trail	§11.10(e)	Tamper-evident audit log with HMAC-SHA256 integrity chain	Each audit entry includes previous_entry_hash HMAC, merkle tree root	services/audit/integrity_chain.py	✅ Ready
Operational checks	§11.10(c)	Document hash verification on retrieval	SHA-256 hash stored at signature time, verified on document access	services/approval/verification.py	✅ Ready
Authority checks	§11.10(d)	Role-based signing key provisioning	User granted signing key only after QA manager approval, stored in user_roles	services/approval/authorization.py	✅ Ready
Device checks	§11.10(h)	MFA re-authentication before signature	TOTP or biometric verification within 5 minutes of signature action	services/auth/mfa_verification.py	✅ Ready
Uniqueness of signatures	§11.200(a)(1)	One ECDSA P-256 keypair per user	user_signing_keys table enforces unique constraint on user_id	Database schema migration V012__user_signing_keys.sql	✅ Ready
Signature verification	§11.200(a)(2)	Multi-factor authentication (password + TOTP)	AuthMethod requires 2 factors, logged in auth_events table	services/auth/two_factor.py	✅ Ready
Signature/record linking	§11.70	ECDSA signature binds user identity to document hash	SignedApproval stores document_hash (SHA-256) + signature (ECDSA-SHA256)	services/approval/e_signature.py	🟡 Partial (crypto implemented, binding validation in testing)
Signature manifestations	§11.300	Printed records display signer, timestamp, meaning	PDF rendering includes SignatureManifest with all required fields	services/document/pdf_renderer.py	✅ Ready
Copies of records	§11.10(c)	Hash-based integrity verification for exports	Export includes SHA-256 manifest file for all documents	services/export/integrity_manifest.py	✅ Ready

Gap Analysis:

• §11.70 Binding - Status: 🟡 Partial (2 days effort remaining)
  • Current: Signature cryptographically binds to document hash
  • Gap: Validation logic to enforce signature re-verification on every document access
  • Remediation: Implement verify_signature_on_retrieval() middleware (tracked in Track D.1.2)

8.2 HIPAA Security Rule Compliance Controls

Requirement	Citation	Control	Implementation	Evidence	Status
Access control	§164.312(a)(1)	Unique user identification via ECDSA signing keys	Each user assigned unique user_id and signing keypair	user_signing_keys table	✅ Ready
Encryption at rest	§164.312(a)(2)(iv)	AES-256-GCM for all PHI database columns	EncryptedTextField Django model field, KMS-managed keys	models/encrypted_fields.py	✅ Ready
Encryption in transit	§164.312(e)(2)(ii)	TLS 1.3 mandatory for all HTTP/gRPC traffic	mTLS between services, API gateway TLS termination	Nginx config ssl_protocols TLSv1.3;	✅ Ready
Integrity controls	§164.312(e)(2)(i)	SHA-256 checksums for PHI file transfers	S3 object metadata includes x-amz-meta-sha256 header	services/storage/integrity_check.py	✅ Ready
Audit controls	§164.312(b)	HMAC-SHA256 audit log integrity chain	Tamper-evident log prevents silent modification of PHI access records	services/audit/integrity_chain.py	✅ Ready
Automatic logoff	§164.312(a)(2)(iii)	Session token expiration (1-hour TTL)	JWT exp claim enforced, refresh token rotation	services/auth/session_management.py	✅ Ready
Emergency access	§164.312(a)(2)(ii)	Break-glass admin access with CISO approval	EmergencyAccess model logs all break-glass events	services/auth/emergency_access.py	✅ Ready

HIPAA Compliance Summary:

• Encryption (Addressable) - IMPLEMENTED as required controls (TLS 1.3 + AES-256-GCM)
• Integrity (Addressable) - IMPLEMENTED with SHA-256 hashing
• Audit Controls (Required) - IMPLEMENTED with tamper-evident log
• Overall Status: 100% compliant (7/7 controls ready)

8.3 SOC 2 Type II Trust Service Criteria

Criterion	Control Objective	Cryptographic Control	Test Procedure	Evidence	Status
CC6.1	Logical access - authentication	RSA-2048 JWT signatures for API tokens	Penetration test: attempt token forgery	JWT signature verification unit tests, 100% pass rate	✅ Ready
CC6.6	Encryption of confidential data	AES-256-GCM for all data at rest, TLS 1.3 for data in transit	Configuration audit: verify no plaintext PHI storage	KMS encryption configuration, S3 bucket policies	✅ Ready
CC6.7	Encryption key management	Annual key rotation, HSM/KMS storage, access logging	Key rotation audit: verify rotation timestamps, access logs	KMS CloudTrail logs, key metadata CreationDate	✅ Ready
CC6.8	Restriction of access to sensitive data	Service-scoped KMS key policies, no wildcard grants	IAM policy review: no kms:* or s3:*	Automated IAM policy scanner (runs weekly)	✅ Ready
CC7.2	System monitoring	CloudWatch alarms on anomalous key usage (>1000 ops/min)	Simulate key abuse, verify alarm triggers	CloudWatch alarm test results, PagerDuty incident log	✅ Ready
CC7.4	Response to security incidents	Key revocation playbook (15-minute response time)	Tabletop exercise: simulate key compromise	Incident response plan IR-CRYPTO-001, drill results	✅ Ready

SOC 2 Readiness:

• Type I (design): 6/6 controls designed and documented
• Type II (operating effectiveness): 6/6 controls operating for 12+ months (evidence: CloudTrail logs Jan 2025 - Feb 2026)
• Audit Readiness: 100% (all evidence artifacts in docs/soc2/evidence/)

8.4 Compliance Status Summary

Framework	Total Requirements	Ready	Partial	Not Started	Coverage %
FDA 21 CFR Part 11	10	9	1	0	90%
HIPAA §164.312	7	7	0	0	100%
SOC 2 Type II	6	6	0	0	100%
NIST SP 800-57	5	5	0	0	100%
FIPS 140-2	2	2	0	0	100%
TOTAL	30	29	1	0	96.7%

Critical Path to 100% Compliance:

1. D.1.2 - FDA §11.70 Signature Binding Validation (2 days)
   • Implement verify_signature_on_retrieval() middleware
   • Add integration test for signature re-verification on document access
   • Update validation documentation with test results

---

9. Exception Process

9.1 Exception Request Procedure

Requests to deviate from this Cryptographic Standards Policy MUST follow a formal exception process:

9.1.1 Exception Categories

Category	Examples	Approval Authority	Maximum Duration
Temporary Compatibility	Legacy system requires TLS 1.2, older cipher suite	CISO	12 months (renewable once)
Performance Optimization	Use ChaCha20-Poly1305 instead of AES-GCM for mobile	Security Architect	24 months
Algorithm Transition	Extend RSA-2048 past 2030 deprecation	CISO + CTO	Until replacement deployed
Vendor Limitation	Third-party HSM only supports RSA-3072 (not P-256)	CISO	Until vendor upgrade available

9.1.2 Exception Request Template

# Cryptographic Standards Policy Exception Request

**Request ID:** CRYPTO-EXC-YYYY-NNN
**Requestor:** [Name, Title, Department]
**Date Submitted:** YYYY-MM-DD

## Business Justification

[Describe why exception is necessary, impact if not granted]

## Technical Details

- **Affected System/Service:** [Service name, architecture component]
- **Prohibited Algorithm/Practice:** [What policy requirement cannot be met]
- **Proposed Alternative:** [What will be used instead]
- **Risk Assessment:** [Security implications, mitigating controls]
- **Affected Data:** [PHI, PII, GxP records, or non-sensitive]

## Compensating Controls

[List additional security measures to reduce risk]

1. Enhanced monitoring: [CloudWatch alarms, SIEM rules]
2. Network segmentation: [VPC isolation, firewall rules]
3. Access restrictions: [IAM policies, service authentication]
4. Audit logging: [What additional logging will be captured]

## Duration

- **Start Date:** YYYY-MM-DD
- **End Date:** YYYY-MM-DD (maximum per approval authority)
- **Renewal Plan:** [How will permanent solution be achieved]

## Regulatory Impact

- **FDA Part 11:** [Any impact on e-signature compliance]
- **HIPAA:** [Any impact on PHI protection]
- **SOC 2:** [Any impact on trust service criteria]

## Approval

| Role | Name | Signature | Date |
|------|------|-----------|------|
| Requestor Manager | | | |
| Security Architect | | | |
| CISO (if required) | | | |
| CTO (if required) | | | |

## Exception Registry Entry

[Entered by Security Team upon approval]

- Exception ID: CRYPTO-EXC-YYYY-NNN
- Status: Approved / Denied / Expired
- Review Date: [Quarterly review for active exceptions]

9.1.3 Exception Review and Monitoring

Active Exception Monitoring:

• Quarterly review of all active exceptions by Security Architect
• Monthly report to CISO on exception utilization (CloudWatch metrics)
• Annual audit of exception register for SOC 2 compliance

Exception Registry Location: internal/security/exception-register/crypto-exceptions.md

Example Exception Entry:

exception_id: CRYPTO-EXC-2026-001
status: active
approved: 2026-02-15
expires: 2027-02-15
renewal_count: 0
requestor: Platform Engineering
system: Legacy API Gateway
deviation: TLS 1.2 with restricted cipher suites (ECDHE-ECDSA-AES256-GCM-SHA384 only)
justification: Third-party ERP integration requires TLS 1.2, vendor upgrade planned Q3 2026
compensating_controls:
  - Network isolation (dedicated VPC subnet)
  - IP allowlist (only ERP vendor IPs)
  - Enhanced logging (all TLS handshakes logged to SIEM)
  - Monthly vulnerability scanning
regulatory_impact: none (no PHI transmitted over this API)
review_date: 2026-05-15

---

10. Audit and Monitoring

10.1 Key Usage Logging

All cryptographic operations MUST be logged for audit and anomaly detection:

10.1.1 Logged Events

Event Type	Logged Attributes	Destination	Retention
Key generation	Key ID, algorithm, key size, requestor, timestamp	CloudTrail + SIEM	7 years
Key usage (encrypt/decrypt)	Key ID, service identity, operation type, data size, timestamp	CloudTrail (sampled at 10%)	90 days
Key rotation	Old key ID, new key ID, rotation type (auto/manual), timestamp	CloudTrail + Security Hub	7 years
Key revocation	Key ID, revocation reason, requestor, timestamp	CloudTrail + SIEM	10 years
Signature creation	Key ID, user ID, document hash, timestamp	Audit service integrity chain	10 years
Signature verification	Key ID, document hash, verification result (pass/fail), timestamp	Application logs + SIEM	1 year
Failed crypto operations	Key ID, error code, service identity, timestamp	SIEM (immediate alert)	1 year
HSM access	HSM cluster ID, operation, user/service identity, timestamp	HSM audit log + CloudTrail	10 years

10.1.2 Log Integrity Protection

Audit Logs MUST be tamper-evident:

• Method: HMAC-SHA256 integrity chain (each log entry includes hash of previous entry)
• Key Storage: KMS-managed audit-log-hmac-key with 10-year retention
• Verification: Automated daily integrity check (services/audit/integrity_verification.py)
• Immutability: S3 bucket with Object Lock enabled (WORM - Write Once Read Many)

Example Audit Log Entry:

{
  "entry_id": "AE-2026-02-16-00001234",
  "timestamp": "2026-02-16T14:32:18.123456Z",
  "event_type": "SIGNATURE_CREATED",
  "user_id": "U-8472",
  "service": "approval-service",
  "key_id": "user-signing-key-8472",
  "document_hash": "a3c5f8d2e1b4c9a7f3e8d2b1a5c7f9e3d8b2a4c6f1e9d3b7a2c5f8e4d1b9a6c3",
  "signature": "3045022100e5b2c8f9a3d7e1b4c6a8f2d9e3b5c7a1f8e2d4b6c9a3f5e7d1b8c2a4f6e9d3022034f7a2e9d1b6c8a3f5e2d7b9c4a1f8e6d3b2a5c9f7e4d1b3a8c6f2e5d9b7a4c1",
  "previous_entry_hash": "b7e9f3a1d8c2b5e4a6f9d1c3b8e2a7f5d9c4b1e6a3f8d2c7b9e5a1f4d8c3b6e2",
  "current_entry_hash": "c8f2a9e5d3b1c6a4f7e2d9b8c5a3f1e6d4b7a2c9f8e5d1b3a6c4f9e7d2b5a8c1"
}

10.2 Anomaly Detection Rules

10.2.1 CloudWatch Alarms

Alarm Name	Condition	Threshold	Action
crypto-key-usage-spike	KMS Decrypt API calls	>1000/minute per key	PagerDuty alert to Security On-Call
crypto-failed-decrypt	KMS Decrypt failures	>10/minute	PagerDuty alert + auto-disable key
crypto-unauthorized-access	KMS AccessDenied errors	>5/minute	SIEM alert + IP blocklist
crypto-key-deletion-attempt	KMS ScheduleKeyDeletion or DisableKey	Any occurrence	PagerDuty alert to CISO + Security Team
crypto-hsm-tamper	HSM tamper event	Any occurrence	Immediate HSM zeroization + incident response
crypto-signature-rate-anomaly	E-signature creation rate	>100/minute per user	Suspend user account + security review

10.2.2 SIEM Correlation Rules

AWS Security Hub + Splunk SIEM Integration:

# Example SIEM correlation rule (Splunk SPL)
index=cloudtrail sourcetype=aws:cloudtrail eventName=Decrypt
| stats count by requestParameters.keyId user
| where count > 1000
| eval severity="CRITICAL"
| eval alert_message="Potential key compromise or DDoS attack detected"
| sendalert pagerduty

Suspicious Patterns:

1. Key usage from unexpected geography - KMS API calls from IPs outside approved AWS regions
2. Off-hours key access - HSM operations between 10 PM - 6 AM local time (except automated rotation)
3. Privilege escalation attempts - Failed KMS CreateGrant or PutKeyPolicy operations
4. Signature forgery attempts - High rate of signature verification failures

10.3 Compliance Reporting

10.3.1 Automated Compliance Reports

Report Name	Frequency	Audience	Content	Format
Key Rotation Status	Monthly	Security Team, Compliance	All keys with next rotation date, overdue rotations	PDF + Excel
Algorithm Usage Inventory	Quarterly	CISO, Auditors	Breakdown of algorithms in use, deprecated algorithm usage	PDF
Access Control Audit	Monthly	Security Team	KMS key policy changes, new key grants, revoked access	PDF
Incident Summary	Monthly	CISO, Executive Team	Failed crypto operations, key compromise events, response times	PDF + Splunk dashboard
Regulatory Compliance Status	Quarterly	QA, Regulatory Affairs	FDA/HIPAA/SOC2 control status, evidence artifacts	PDF with hyperlinks

10.3.2 Report Generation

Automated Report Script:

#!/usr/bin/env python3
"""
Generate monthly key rotation status report.
Location: scripts/compliance/key-rotation-report.py
"""

import boto3
from datetime import datetime, timedelta
from openpyxl import Workbook
import smtplib
from email.mime.multipart import MIMEMultipart
from email.mime.application import MIMEApplication

def generate_key_rotation_report():
    kms = boto3.client('kms')
    wb = Workbook()
    ws = wb.active
    ws.title = "Key Rotation Status"

    # Header row
    headers = ['Key ID', 'Alias', 'Algorithm', 'Creation Date', 'Rotation Period', 'Next Rotation', 'Status']
    ws.append(headers)

    # Fetch all KMS keys
    keys = kms.list_keys()['Keys']

    for key in keys:
        key_id = key['KeyId']
        metadata = kms.describe_key(KeyId=key_id)['KeyMetadata']

        # Get key alias
        aliases = kms.list_aliases(KeyId=key_id).get('Aliases', [])
        alias = aliases[0]['AliasName'] if aliases else 'N/A'

        # Calculate next rotation
        creation_date = metadata['CreationDate']
        rotation_period_days = get_rotation_period(alias)  # From key inventory
        next_rotation = creation_date + timedelta(days=rotation_period_days)

        # Determine status
        if next_rotation < datetime.now(next_rotation.tzinfo):
            status = '🔴 OVERDUE'
        elif next_rotation < datetime.now(next_rotation.tzinfo) + timedelta(days=30):
            status = '🟡 DUE SOON'
        else:
            status = '✅ CURRENT'

        ws.append([
            key_id,
            alias,
            metadata.get('KeySpec', 'SYMMETRIC_DEFAULT'),
            creation_date.strftime('%Y-%m-%d'),
            f'{rotation_period_days} days',
            next_rotation.strftime('%Y-%m-%d'),
            status
        ])

    # Save report
    report_path = f'/tmp/key-rotation-report-{datetime.now().strftime("%Y-%m")}.xlsx'
    wb.save(report_path)

    # Email to stakeholders
    send_email(
        to=['security-team@coditect.ai', 'compliance@coditect.ai'],
        subject=f'Key Rotation Status Report - {datetime.now().strftime("%B %Y")}',
        body='Attached is the monthly key rotation status report.',
        attachment=report_path
    )

if __name__ == '__main__':
    generate_key_rotation_report()

Report Distribution:

• Monthly reports: Auto-generated first Monday of each month, emailed to stakeholders
• Quarterly reports: Compiled into compliance package for SOC 2 auditors
• On-demand reports: Available via Splunk dashboard (/app/security/crypto-compliance)

---

11. Appendices

Appendix A: Glossary

Term	Definition
AEAD	Authenticated Encryption with Associated Data - encryption mode providing confidentiality and integrity (e.g., AES-GCM)
CloudHSM	AWS Hardware Security Module service (FIPS 140-2 Level 3 validated)
CMK	Customer-Managed Key - KMS key controlled by customer (vs. AWS-managed key)
CRL	Certificate Revocation List - list of revoked certificates published by CA
CSRNG	Cryptographically Secure Random Number Generator - entropy source for key generation
DEK	Data Encryption Key - symmetric key used to encrypt data (wrapped by KEK)
ECDH	Elliptic Curve Diffie-Hellman - key exchange protocol providing forward secrecy
ECDSA	Elliptic Curve Digital Signature Algorithm - asymmetric signature scheme (NSA Suite B)
Envelope Encryption	Two-tier encryption: DEK encrypts data, KEK encrypts DEK
FIPS 140-2	Federal Information Processing Standard for cryptographic module validation (Levels 1-4)
GCM	Galois/Counter Mode - AEAD mode for AES providing confidentiality and integrity
HKDF	HMAC-based Key Derivation Function - extract-and-expand KDF per RFC 5869
HMAC	Hash-based Message Authentication Code - keyed hash for integrity/authentication
HSM	Hardware Security Module - tamper-resistant device for cryptographic key storage
KEK	Key Encryption Key - key used to wrap/unwrap other keys (KMS CMK is a KEK)
KMS	AWS Key Management Service - managed cryptographic key storage and operations
mTLS	Mutual TLS - both client and server authenticate with certificates
OCSP	Online Certificate Status Protocol - real-time certificate revocation checking
PBKDF2	Password-Based Key Derivation Function 2 - KDF for password hashing per NIST SP 800-132
Perfect Forward Secrecy	Property where compromise of long-term keys does not compromise past session keys (via ECDHE)
PSS	Probabilistic Signature Scheme - RSA signature padding with provable security
P-256	NIST P-256 elliptic curve (secp256r1) - 256-bit curve providing ~128-bit security
TOTP	Time-Based One-Time Password - MFA algorithm per RFC 6238 (6-digit codes)
TLS 1.3	Transport Layer Security version 1.3 - latest TLS standard (IETF RFC 8446)
X25519	Curve25519 for ECDH key exchange - modern elliptic curve by Daniel J. Bernstein
Zeroization	Overwriting cryptographic key material in memory/storage per NIST SP 800-88

Appendix B: References

Regulatory Standards

1. FDA 21 CFR Part 11 - Electronic Records; Electronic Signatures URL: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11

2. HIPAA Security Rule (45 CFR §164.312) - Technical Safeguards URL: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C

3. SOC 2 Trust Service Criteria - AICPA URL: https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/aicpasoc2report.html

Cryptographic Standards

4. NIST FIPS 140-2 - Security Requirements for Cryptographic Modules URL: https://csrc.nist.gov/publications/detail/fips/140/2/final

5. NIST FIPS 186-5 - Digital Signature Standard (DSS) URL: https://csrc.nist.gov/publications/detail/fips/186/5/final

6. NIST FIPS 197 - Advanced Encryption Standard (AES) URL: https://csrc.nist.gov/publications/detail/fips/197/final

7. NIST SP 800-57 Part 1 - Recommendation for Key Management URL: https://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final

8. NIST SP 800-88 Rev 1 - Guidelines for Media Sanitization URL: https://csrc.nist.gov/publications/detail/sp/800-88/rev-1/final

9. NIST SP 800-132 - Recommendation for Password-Based Key Derivation URL: https://csrc.nist.gov/publications/detail/sp/800-132/final

Industry Best Practices

10. OWASP Password Storage Cheat Sheet - PBKDF2 iteration count recommendations URL: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

11. CA/Browser Forum Baseline Requirements - Certificate validity periods URL: https://cabforum.org/baseline-requirements-documents/

12. IETF RFC 8446 - The Transport Layer Security (TLS) Protocol Version 1.3 URL: https://datatracker.ietf.org/doc/html/rfc8446

13. IETF RFC 5869 - HMAC-based Extract-and-Expand Key Derivation Function (HKDF) URL: https://datatracker.ietf.org/doc/html/rfc5869

14. IETF RFC 6238 - TOTP: Time-Based One-Time Password Algorithm URL: https://datatracker.ietf.org/doc/html/rfc6238

Appendix C: Related Documentation

Document	Location	Purpose
Security Architecture Overview	docs/architecture/security-architecture.md	5-layer authorization, mTLS design, zero-trust network
E-Signature Technical Design	docs/architecture/e-signature-architecture.md	Two-phase signature flow, AuthMethod types, FDA Part 11 binding
Regulatory Compliance Matrix	docs/compliance/regulatory-compliance-matrix.md	FDA/HIPAA/SOC2 requirement tracking, gap analysis
Key Management Procedures	docs/procedures/key-management-procedures.md	Step-by-step operational procedures for key rotation, revocation
Incident Response Plan	docs/security/incident-response-plan.md	IR-CRYPTO-001 key compromise playbook
KMS Key Policy Templates	infrastructure/kms/key-policies/	Terraform templates for service-specific key policies
HSM Backup Procedures	docs/procedures/hsm-backup-recovery.md	Quarterly backup, disaster recovery testing
Audit Log Integrity Verification	services/audit/README.md	Integrity chain implementation, verification algorithms

Appendix D: Change Log

Version	Date	Author	Changes	Approval
0.1.0	2026-01-15	Security Architect	Initial draft	N/A (draft)
0.2.0	2026-01-28	Security Team	Added TLS 1.3 requirements, key rotation schedule	N/A (draft)
0.3.0	2026-02-05	Compliance Officer	FDA Part 11 compliance mapping, gap analysis	N/A (draft)
0.4.0	2026-02-10	CISO	Exception process, audit/monitoring section	N/A (draft)
1.0.0	2026-02-16	Security Team	Final review, approved for publication	Pending executive approval

Appendix E: Approval Workflow

Document Approval Process:

1. Draft Circulation (2 weeks) - Security Team, Platform Engineering, QA review
2. Stakeholder Feedback (1 week) - Incorporate comments from Legal, Compliance, Regulatory Affairs
3. Executive Review (3 days) - CISO, VP Engineering, VP QA review
4. Final Approval (1 day) - CISO signature, publish to policy repository
5. Communication (1 day) - Email all engineering teams, add to onboarding materials

Effective Date: This policy becomes effective upon CISO approval signature.

Training Requirement: All Platform Engineers and Security Engineers MUST complete Cryptographic Standards Policy training within 30 days of policy effective date.

---

Document Control Footer

Document ID: CODITECT-BIO-CRYPTO-001 Version: 1.0.0 Classification: Internal - Restricted Next Review Date: 2027-02-16 Policy Owner: Chief Information Security Officer Document Location: docs/compliance/crypto-standards-policy.md Approval Status: Draft (pending executive signature)

Confidentiality Notice: This document contains proprietary information and is intended solely for authorized personnel of CODITECT Biosciences. Unauthorized distribution is prohibited.

---

END OF DOCUMENT