Protection of classified data in HSM databases

Architectural Solutions for Securing Sensitive Data in Databases

Sensitive data like payment card numbers (PAN) and personal information (PII) needs robust protection against leaks via database backups and admin access. Key challenges include storing encrypted data while enabling searches, secure key management, and minimizing breach risks. Analysis reveals a split: PCI DSS for PAN and laws like 152-FZ/GDPR for PII due to differing requirements, such as full data deletion on request.

A card number isn't a total secret: the first 6–8 digits are the bank's BIN, the last is a checksum, leaving 7–9 digits to brute-force (10–1000 million combos per BIN). Storing salted PAN hashes in the database is vulnerable to GPU attacks if the salt is exposed.

Data Encryption and HSM Options

HSM (Hardware Security Module) is a device for safely storing keys and performing crypto operations. Hardware HSMs physically protect keys from extraction; software ones rely on access controls.

Software HSMs use Shamir's Secret Sharing: the master key is split into N shares, with K out of N needed to reconstruct (K < N). Example: 5 shares, 3 to activate. It's a trade-off—shifts risk to your organization but cuts costs.

Options for searching encrypted data:

• TDE (Transparent Data Encryption): Encrypts files on disk, but data is plaintext in memory. Guards against stolen drives, not DBAs.
• Salted hash: Stores hash of PAN + salt from HSM, indexed by hash. Salt stays out of the DB to block brute-forcing.
• Deterministic encryption: No IV, same plaintext yields same ciphertext. Allows indexing but risky if keys leak.

Best approach: DB holds encrypted PAN, crypto-hash, and key ID (for rotation). Search by hash; services only see hashes. PCI DSS limits hashes in the cardholder data environment—use tokens in a separate store instead.

Key Management: Vault and Its Limits

Tools like HashiCorp Vault, Azure Key Vault, and AWS Secrets Manager handle secrets well but fall short for crypto keys. They protect against:

• Secrets committed to git.
• Env var leaks.
• Unauthorized reads.

They don't protect against:

• Vault admins.
• Server admins (memory dumps).
• mTLS cert owners.

Strengthen with mTLS using hardware keys, rate limits, and auditing. Vault isn't an HSM. Azure Key Vault Premium leverages Microsoft datacenter HSMs with non-exportable keys and API ops.

Kubernetes Secrets: Containerization Risks

Kubernetes Secrets are base64-encoded in etcd (not encrypted). API server access exposes all secrets. Containers are vulnerable to:

• Root host reading container FS.
• nsenter into processes.
• Memory dumps.
• Network traffic sniffing.

Unacceptable for crypto services. Mitigations like gVisor, Kata Containers, or Confidential Computing help but add complexity.

Cloud Solutions and Shared Responsibility

Clouds like AWS and Azure are PCI DSS certified for infrastructure (data centers, disk encryption), but you're on the hook for keys and access. Cloud traffic runs over virtual networks—provider admins could snoop. Recommendation: Dedicated crypto service with physical isolation (separate cabling); in cloud, use isolated HSMs.

Consensus Architecture

• Dedicated crypto service outside containers, minimal interfaces.
• Non-extractable keys in HSM (hardware/software/cloud).
• Shamir's scheme without hardware HSM.
• Crypto-hash for searches, salt from HSM.
• Separate PAN/PII handling.
• Full auditing.
• Key rotation.

Key takeaways:

• Keep salts/keys out of the DB—use HSM.
• Search via crypto-hashes or tokens; skip deterministic encryption.
• Organizational trade-offs (Shamir) save money.
• Vault for secrets, HSM for keys.
• Split PCI DSS and PII by regulations.

— Editorial Team