How do I implement encryption for PHI at rest and in transit?

Introduction

Encrypting PHI isn’t optional—it’s mandated and critical for trust. Below is a deep dive into the algorithms, key-management strategies, TLS configurations, and hardware security modules (HSMs) you need to secure PHI both at rest and in transit.

Data at Rest Encryption

1. Algorithm Selection

   • AES-256-GCM is the gold standard. It provides confidentiality plus built-in integrity via authenticated encryption.

   • Avoid legacy modes (CBC without HMAC) that are vulnerable to padding oracles.

2. Key Management

   • HSM-Backed KMS: Store and rotate keys in a managed service (AWS KMS, Azure Key Vault, GCP Cloud KMS).

   • Automated Rotation: Enforce a 90-day rotation schedule with no human access to raw key material.

   • Access Controls: Grant applications only the least-privilege IAM roles needed to decrypt—use short-lived tokens (e.g., AWS STS).

3. Storage Configuration

   • Database Encryption: Enable transparent data encryption (TDE) tied to your KMS.

   • Object Storage: Configure S3 buckets or Blob storage to use server-side encryption with customer-managed keys.

   • Full-Disk Encryption: Enforce LUKS or BitLocker on any VM or physical server holding PHI.

Data in Transit Encryption

1. TLS Version & Ciphers

   • TLS 1.3 Only: Disable TLS 1.2 and earlier to eliminate weak handshakes.

   • Cipher Suites: Rely on AEAD suites (e.g., TLS_AES_256_GCM_SHA384). No RSA key-exchange or CBC.

2. Certificate Management

   • Public PKI: Use certificates issued by a trusted CA; automate renewals via ACME/Let’s Encrypt or your enterprise CA.

   • Hardened Config: Enforce HSTS with a long max-age and includeSubDomains; disable renegotiation and compression.

3. Mutual TLS (mTLS)

   • Where applicable, require client-side certificates to authenticate service-to-service calls handling PHI.

   • Manage cert lifecycles via your internal PKI or a service mesh (Istio, Linkerd).

Hardware Security Modules (HSMs)

1. Purpose of HSMs

   • Provide tamper-resistant key storage and cryptographic operations in a dedicated appliance or cloud managed module.

2. Integration Patterns

   • Envelope Encryption: Use the HSM to encrypt a data-encryption key (DEK), then use the DEK in your application for bulk encryption.

   • Asymmetric Operations: Offload signing or key-wrapping tasks to the HSM, never exporting private key material.

3. Cloud vs. On-Prem

   • Cloud HSM (AWS CloudHSM, Azure Dedicated HSM): Lower operational overhead, integrated with KMS.

   • On-Prem HSM: For ultra-sensitive environments, deploy FIPS 140-2 Level 3 modules in your data center.

Putting It All Together: Reference Workflow

1. Encrypt Before Persisting

   • Application fetches a fresh DEK from KMS → encrypts PHI with AES-256-GCM → discards plaintext DEK.

2. Store Encrypted Payloads

   • Save the ciphertext and authentication tag alongside metadata (key ID, IV).

3. TLS-Secured Transport

   • All API calls to fetch or store PHI use HTTPS with TLS 1.3 and HSTS.

4. Decrypt on Read

   • Upon request, application retrieves the DEK via an authenticated KMS API → decrypts data in memory → serves to authorized user.

5. Audit & Monitoring

   • Log all key-usage events in your SIEM; alert on anomalous KMS calls or TLS handshake failures.

Conclusion

By standardizing on AES-256-GCM, HSM-backed key management, strict TLS 1.3 configurations, and automated certificate handling, you’ll not only satisfy HIPAA’s “addressable” encryption requirements—you’ll exceed them, turning encryption into a competitive advantage rather than a compliance checkbox.