Key Management Policy
| Field | Value |
|---|---|
| Document ID | POL-004 |
| Version | 1.0 |
| Effective Date | 2026-04-08 |
| Next Review Date | 2027-04-08 |
| Classification | Internal |
| Owner | Information Security Officer |
| Approved By | CEO, Paylithix Inc. |
| Parent Policy | Information Security Policy (POL-001) |
1. Purpose
This policy defines the lifecycle management of cryptographic keys used to protect cardholder data in the Gatelithix Gateway. It governs key generation, storage, rotation, destruction, and custodianship, in compliance with PCI DSS 4.0.1 Requirements 3.5, 3.6, and 3.7.
2. Scope
This policy applies to all cryptographic keys used within the Gatelithix Gateway CDE:
- PAN Encryption Keys — Cloud KMS HSM-backed keys used to encrypt/decrypt PANs via AES-256-GCM
- Cloud SQL Encryption Keys — CMEK (Customer-Managed Encryption Keys) for database encryption at rest
- TLS Certificates — Managed by Cloudflare (public endpoints) and GCP (internal service-to-service)
- API Key Signing Material — Used for generating and validating merchant API keys
- HMAC Webhook Signing Keys — Used for signing outbound webhook payloads to merchants
This policy does not cover: Auth0-managed session tokens (Auth0’s responsibility per their PCI AOC), Stripe API keys (Stripe’s responsibility), or GCP-managed infrastructure encryption (GCP’s responsibility per their PCI AOC).
3. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Information Security Officer | Key custodian; approves key creation and destruction; leads annual crypto review |
| Engineering Lead | Secondary key custodian; implements key rotation; manages Cloud KMS IAM bindings |
| Vault Service Account | Sole automated consumer of PAN encryption keys (encrypt/decrypt operations) |
| All Engineers | Do not export, copy, or locally store any cryptographic key material |
3.1 Split Knowledge and Dual Control
- No single individual shall have the ability to reconstitute or export complete key material for PAN encryption keys.
- Cloud KMS HSM-backed keys cannot be exported by design — the key material never leaves the HSM boundary.
- Key creation and destruction require approval from both the ISO and the Engineering Lead (dual control).
- IAM changes granting
cloudkms.cryptoKeyEncrypterDecrypterrequire approval from the ISO.
4. Policy Statements
4.1 Approved Cryptographic Algorithms
| Use Case | Algorithm | Key Length | Mode | Provider |
|---|---|---|---|---|
| PAN encryption at rest | AES | 256-bit | GCM | Cloud KMS HSM |
| Database CMEK | AES | 256-bit | GCM | Cloud KMS |
| Data in transit | TLS | 1.2+ (ECDHE + AES-256-GCM preferred) | — | Cloud Run / Cloudflare |
| Webhook HMAC signing | HMAC-SHA256 | 256-bit | — | Application (key from Secret Manager) |
| API key hashing | bcrypt | cost factor 12 | — | Application |
Prohibited algorithms: DES, 3DES, RC4, MD5 (for any cryptographic purpose), SHA-1 (for signing/HMAC).
4.2 Key Generation
- All keys protecting cardholder data shall be generated within Cloud KMS using HSM-backed key rings (protection level
HSM). - Key generation uses the cryptographic random number generator provided by the Cloud HSM hardware — no application-generated keys for PAN encryption.
- Each key is created with:
- A descriptive name indicating its purpose (e.g.,
pan-encryption-primary) - The
ENCRYPT_DECRYPTpurpose for symmetric keys - The
GOOGLE_SYMMETRIC_ENCRYPTIONalgorithm (AES-256-GCM) - HSM protection level
- Automatic rotation enabled
- A descriptive name indicating its purpose (e.g.,
- Key creation is logged in Cloud Audit Logs (Admin Activity).
4.3 Key Storage
- PAN encryption keys are stored exclusively within Cloud KMS HSM. Key material never leaves the HSM boundary and cannot be exported.
- Webhook signing secrets are stored in Google Secret Manager with IAM-restricted access.
- No cryptographic key material shall be stored in:
- Application source code or configuration files
- Environment variables containing raw key material (references to Cloud KMS key names are acceptable)
- Local developer machines
- Cloud SQL databases
- Log files or error messages
- Key references (Cloud KMS key resource names) may be stored in Terraform state and application configuration.
4.4 Key Rotation
- PAN encryption keys shall be rotated automatically every 90 days via Cloud KMS automatic rotation.
- Cloud KMS automatic rotation creates a new key version while keeping previous versions available for decryption of data encrypted under older versions.
- After rotation, new encryption operations use the latest key version. Decryption automatically selects the correct key version based on the ciphertext metadata.
- Webhook signing secrets shall be rotated at least annually, with a grace period during which both old and new secrets are valid.
- API key signing material rotates implicitly when merchants generate new API keys.
- TLS certificates are rotated automatically by Cloudflare (public) and GCP (internal).
4.5 Cryptoperiod Policy
| Key Type | Maximum Cryptoperiod | Rotation Method | Grace Period |
|---|---|---|---|
| PAN encryption (Cloud KMS) | 90 days per version | Automatic (Cloud KMS) | Previous versions remain for decrypt only |
| Cloud SQL CMEK | 365 days | Automatic (Cloud KMS) | Previous versions remain active |
| Webhook HMAC secrets | 365 days | Manual (Secret Manager) | 7 days dual-validity |
| TLS certificates | 90 days (Cloudflare) | Automatic | Overlap during renewal |
4.6 Key Access Control
- Access to perform encrypt/decrypt operations on PAN encryption keys is restricted to the vault Cloud Run service account only.
- IAM bindings for
cloudkms.cryptoKeyEncrypterDecryptershall include only the vault service account identity. - No human user account shall have
cryptoKeyEncrypterDecrypterpermission on PAN encryption keys in production. cloudkms.adminrole (key management, not encrypt/decrypt) is restricted to the ISO and Engineering Lead accounts.- Key access is audited via Cloud KMS Data Access Audit Logs (enabled for all read and write operations).
4.7 Key Destruction
- Key versions shall not be destroyed unless:
- All data encrypted under that key version has been re-encrypted under a newer version, or
- The data protected by that key version has been securely deleted
- Key destruction requires written approval from both the ISO and Engineering Lead.
- Cloud KMS enforces a 24-hour scheduled destruction delay — destruction can be cancelled during this period.
- Before scheduling destruction, the Engineering Lead shall verify that no ciphertext in the vault database references the key version being destroyed.
- Key destruction events are logged in Cloud Audit Logs and recorded in the key management log.
4.8 Key Compromise Response
- If a key is suspected or confirmed to be compromised:
- Immediately invoke the Incident Response Plan
- Create a new key version in Cloud KMS
- Re-encrypt all data protected by the compromised key version
- Schedule destruction of the compromised key version (after re-encryption is verified)
- Notify affected merchants if cardholder data may have been exposed
- Document the incident, response actions, and lessons learned
4.9 Annual Cryptographic Review
- The ISO shall conduct an annual review of all cryptographic controls (PCI DSS 12.3.3). The review shall cover:
- Inventory of all cryptographic keys and their purposes
- Verification that rotation schedules are being followed (Cloud KMS rotation history)
- Verification that IAM bindings on key rings match policy
- Review of TLS versions and cipher suites in use across all connections
- Confirmation that no prohibited algorithms are in use
- Review of key access audit logs for anomalous access patterns
- The review shall produce a dated report with findings and any required remediation.
- Review schedule: April of each year (aligned with policy review cycle).
5. Compliance and Enforcement
- Any attempt to export, copy, or locally store cryptographic key material used for PAN encryption is a critical policy violation and shall be escalated immediately.
- Unauthorized changes to Cloud KMS IAM bindings are detectable via Cloud Audit Logs and treated as security incidents.
- Violations shall be handled per the Incident Response Plan.
6. Related Documents
- Information Security Policy (POL-001) — Parent policy
- Data Classification Policy (POL-007) — Data categories requiring encryption
- Network Security Policy (POL-003) — Encryption in transit requirements
- Incident Response Plan (POL-005) — Key compromise response
- Cloud KMS Documentation (cloud.google.com/kms/docs)
- PCI DSS 4.0.1 Requirements 3.5, 3.6, 3.7
7. Document History
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | 2026-04-08 | Information Security Officer | Initial policy creation |