Encryption at rest and in transit

crypts an encrypted blob.

• Requires access to KMS to unwrap the DEK. */ async decrypt(blob: EncryptedBlob): Promise<string> { // 1. Unwrap DEK using KEK from KMS const encryptedKeyBuffer = Buffer.from(blob.encryptedKey, 'base64'); const dek = await this.unwrapKeyWithKMS(encryptedKeyBuffer);

// 2. Decrypt data with DEK

const iv = Buffer.from(blob.iv, 'base64');
const tag = Buffer.from(blob.tag, 'base64');
const decipher = crypto.createDecipheriv(ALGORITHM, dek, iv);
decipher.setAuthTag(tag);

let plaintext = decipher.update(blob.ciphertext, 'base64', 'utf8');
plaintext += decipher.final('utf8');

return plaintext;

}

// Mock KMS operations. Replace with actual SDK calls. private async wrapKeyWithKMS(key: Buffer): Promise<Buffer> { const command = new EncryptCommand({ KeyId: this.keyId, Plaintext: key, }); const response = await this.kms.send(command); return response.CiphertextBlob as Buffer; }

private async unwrapKeyWithKMS(encryptedKey: Buffer): Promise<Buffer> { const command = new DecryptCommand({ CiphertextBlob: encryptedKey, }); const response = await this.kms.send(command); return response.Plaintext as Buffer; } }

### Architecture Decisions and Rationale

*   **Per-Item DEK vs. Shared DEK:** Generate a unique DEK for each sensitive record. This limits the blast radius. If a DEK is compromised, only one record is exposed. If you use a shared DEK for a table, the entire dataset is at risk. The storage overhead is minimal (the encrypted DEK is ~256 bytes per record).
*   **KMS Integration:** Use a managed KMS rather than self-managed HSMs unless regulatory requirements dictate physical control. Managed KMS provides high availability, automated rotation, and detailed audit logs via CloudTrail or equivalent.
*   **TLS Termination:** Terminate TLS as close to the application as possible. Avoid terminating at the CDN or load balancer unless the internal network is fully trusted and encrypted via mTLS. Ideally, use mTLS between the load balancer and backend services.
*   **Key Rotation:** Implement "Graceful Rotation." When a KEK rotates, existing data encrypted with old DEKs remains valid. New data uses the new KEK. The KMS handles the versioning transparently during decryption.

## Pitfall Guide

### 1. Hardcoding Keys in Source Code
**Mistake:** Developers embed encryption keys in environment variables checked into version control or hardcoded in binary assets.
**Impact:** Any developer with repository access can decrypt production data. Automated scanners will flag this, but human error persists.
**Fix:** Keys must never exist in source code. Use KMS, HashiCorp Vault, or cloud secret managers. Access keys via runtime IAM roles, not static credentials.

### 2. Reusing Initialization Vectors (IVs)
**Mistake:** Using a static IV or reusing an IV with the same key in AES-GCM or AES-CBC.
**Impact:** In GCM, IV reuse destroys confidentiality and integrity, allowing attackers to recover the keystream and forge messages. In CBC, IV reuse enables pattern analysis.
**Fix:** Always generate a cryptographically random IV for every encryption operation. The IV does not need to be secret but must be unique per key.

### 3. Neglecting Key Rotation Policies
**Mistake:** Creating a KMS key and never rotating it.
**Impact:** Long-lived keys increase the window of exposure if a key is leaked. Compliance frameworks (PCI-DSS, SOC2) mandate rotation.
**Fix:** Enable automatic key rotation in KMS. For application-layer keys, implement rotation logic that re-encrypts data or marks old keys for decryption-only access.

### 4. Logging Encrypted Data with Keys
**Mistake:** Logging the plaintext key alongside the encrypted payload for debugging, or logging the decrypted value in error messages.
**Impact:** Log aggregation systems become a high-value target. SIEM tools may inadvertently store secrets.
**Fix:** Implement strict log filtering. Never log keys. If debugging is required, use tokenization or masking. Ensure log storage is encrypted and access-controlled.

### 5. Relying Solely on Infrastructure Encryption
**Mistake:** Assuming AWS S3 SSE-S3 protects data from the cloud provider or insider threats.
**Impact:** The provider holds the keys. A malicious insider at the provider or a compromised admin account can access data.
**Fix:** Use Customer Managed Keys (CMK) or Client-Side Encryption for high-sensitivity data. This ensures the provider cannot access data without explicit customer authorization.

### 6. TLS Downgrade Attacks
**Mistake:** Allowing TLS 1.0/1.1 or weak cipher suites for backward compatibility.
**Impact:** Attackers can force a connection to use a vulnerable protocol version, enabling POODLE or BEAST attacks.
**Fix:** Configure servers to enforce TLS 1.2 minimum, preferably TLS 1.3. Use tools like `testssl.sh` to validate configurations. Disable weak ciphers like RC4, 3DES, and CBC modes in TLS.

### 7. Ignoring Metadata Encryption
**Mistake:** Encrypting the payload but leaving metadata (headers, filenames, database indexes) in plaintext.
**Impact:** Metadata can reveal sensitive information. For example, an index on an encrypted email field might allow frequency analysis to infer content.
**Fix:** Encrypt metadata where possible. Use deterministic encryption or searchable encryption techniques if indexing is required, understanding the trade-offs in security strength.

## Production Bundle

### Action Checklist

- [ ] **Audit Data Flows:** Map all data persistence points and network paths. Identify where data is unencrypted.
- [ ] **Enforce TLS 1.3:** Update all ingress controllers, load balancers, and service configs to require TLS 1.3 with strong cipher suites.
- [ ] **Implement Envelope Encryption:** Refactor storage layers to use DEK/KEK pattern. Ensure unique DEKs per sensitive record.
- [ ] **Configure KMS Policies:** Review IAM policies for KMS keys. Ensure only necessary services have `kms:Decrypt` permissions. Enable key rotation.
- [ ] **Rotate Static Secrets:** Audit for hardcoded keys. Migrate all secrets to a vault or KMS. Rotate all existing credentials.
- [ ] **Validate IV Uniqueness:** Review codebases for IV generation. Ensure `crypto.randomBytes` is used and IVs are never static.
- [ ] **Test Decryption Failures:** Simulate KMS outages or key deletion. Verify that applications handle decryption errors gracefully without exposing sensitive stack traces.
- [ ] **Enable Audit Logging:** Ensure all KMS key usage is logged to CloudTrail/Stackdriver. Set up alerts for anomalous decryption patterns.

### Decision Matrix

| Scenario | Recommended Approach | Why | Cost Impact |
|----------|---------------------|-----|-------------|
| **SaaS Multi-Tenant App** | Envelope Encryption with Tenant-Specific DEKs | Isolates tenant data mathematically. Compromise of one tenant's key does not affect others. | Moderate (KMS API calls per operation) |
| **Internal Analytics Dashboard** | Infrastructure Encryption (SSE-KMS) | Sufficient for internal trust boundaries. Lower operational overhead. | Low |
| **HIPAA/GDPR Regulated Data** | Envelope Encryption + mTLS | Meets strict confidentiality and integrity requirements. Provides audit trail for key access. | High (Development effort + KMS costs) |
| **High-Throughput IoT Stream** | TLS 1.3 + Batch Encryption at Edge | Reduces per-message overhead. Data encrypted in batches before cloud ingestion. | Low (Edge compute cost) |
| **Legacy System Migration** | Transparent Data Encryption (TDE) + TLS | Minimizes code changes. Encrypts storage volumes and connections without app refactoring. | Low (Infrastructure only) |

### Configuration Template

**Terraform: AWS KMS Key and S3 Bucket with Envelope Encryption Support**

```hcl
resource "aws_kms_key" "app_data_key" {
  description             = "Key for envelope encryption of application data"
  deletion_window_in_days = 30
  enable_key_rotation     = true

  policy = jsonencode({
    Version = "2012-10-17"
    Id      = "key-policy"
    Statement = [
      {
        Sid    = "EnableRootAccount"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"
        }
        Action   = "kms:*"
        Resource = "*"
      },
      {
        Sid    = "AllowAppRole"
        Effect = "Allow"
        Principal = {
          AWS = aws_iam_role.app_role.arn
        }
        Action = [
          "kms:Encrypt",
          "kms:Decrypt",
          "kms:GenerateDataKey",
          "kms:DescribeKey"
        ]
        Resource = "*"
      }
    ]
  })

  tags = {
    Environment = "production"
    Purpose     = "envelope-encryption"
  }
}

resource "aws_kms_alias" "app_data_key_alias" {
  name          = "alias/app-data-key"
  target_key_id = aws_kms_key.app_data_key.key_id
}

resource "aws_s3_bucket" "secure_data" {
  bucket = "my-secure-data-bucket"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "secure_data" {
  bucket = aws_s3_bucket.secure_data.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.app_data_key.arn
    }
    bucket_key_enabled = true
  }
}

resource "aws_s3_bucket_policy" "secure_data" {
  bucket = aws_s3_bucket.secure_data.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "DenyUnencryptedUploads"
        Effect = "Deny"
        Principal = "*"
        Action   = "s3:PutObject"
        Resource = "${aws_s3_bucket.secure_data.arn}/*"
        Condition = {
          StringNotEquals = {
            "s3:x-amz-server-side-encryption" = "aws:kms"
          }
        }
      }
    ]
  })
}

Quick Start Guide

1. Create KMS Key: In your cloud console, create a Customer Managed Key. Enable automatic rotation. Note the Key ID.
2. Update Storage Config: Configure your database or object storage to use the KMS Key for server-side encryption. Enforce encryption via bucket/database policies.
3. Integrate SDK: Add the KMS SDK to your application. Implement the envelope encryption helper class (as shown in Core Solution). Replace direct storage writes with encrypted blobs.
4. Verify: Write a test record. Confirm the stored data is ciphertext. Attempt to read the record; verify decryption works. Check KMS audit logs to confirm key usage is recorded.
5. Enforce Transit: Update application connection strings to use ?sslmode=require or equivalent. Validate TLS configuration using openssl s_client or browser developer tools.