Encryption at Rest and in Transit

In modern software architecture, 'secure by default' isn't just a catchphrase; it's a requirement. Encryption is the foundation of this security. Without transit encryption, any intermediary on the network—from a malicious Wi-Fi hotspot to a compromised ISP—can read your HTTP traffic in plaintext. Without rest encryption, a stolen database backup or a decommissioned hard drive exposes every user's PII (Personally Identifiable Information).

This guide moves beyond the theory. We will explore how TLS handshakes protect your packets in the wild and how to implement application-level encryption in Spring Boot to ensure that even if your database is fully compromised, your most sensitive fields remain indecipherable strings of noise. We'll also cover key management, compliance requirements, and the real production pitfalls engineers face when deploying encryption at scale.

Encryption in Transit — TLS/HTTPS

Encryption in transit ensures that data remains confidential and untampered while moving across the wire. Modern standards rely on TLS (Transport Layer Security) 1.2 or 1.3. When a client connects via HTTPS, a handshake occurs where the server proves its identity via a Certificate Authority (CA) and both parties negotiate a symmetric session key.

In a Spring Boot environment, you must ensure that your microservices don't just 'accept' HTTPS, but actively enforce it. This includes rejecting insecure algorithms (like SSLv3 or TLS 1.0) and ensuring that internal service-to-service communication is also encrypted, often managed via a Service Mesh like Istio or Linkerd.

TLS 1.3 reduces handshake latency to one round trip (0-RTT for resumption) and removes obsolete ciphers. In production, you should always prefer TLS 1.3 and enable HSTS to prevent SSL stripping attacks.

package io.thecodeforge.security;

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

/**
 * Production-grade Security Configuration for io.thecodeforge
 * Forces HTTPS and sets Strict-Transport-Security (HSTS) headers.
 */
@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .requiresChannel()
            .anyRequest()
            .requiresSecure() // Redirects all HTTP traffic to HTTPS
            .and()
            .headers()
            .httpStrictTransportSecurity()
            .includeSubDomains(true)
            .maxAgeInSeconds(31536000); // 1 Year HSTS policy
    }
}

// Pro-Tip: When using RestTemplate or WebClient to call external APIs,
// never disable SSL verification. Use a proper TrustStore if dealing with
// private CA certificates.

TLS 1.2 vs TLS 1.3 Comparison

TLS 1.3, finalized in 2018, is a major overhaul over TLS 1.2. It reduces handshake latency, removes obsolete and insecure cipher suites, and introduces 0-RTT (zero round-trip time) resumption. The following table compares key properties:

In production, you should enforce TLS 1.3 wherever possible. If legacy clients require TLS 1.2, ensure you only enable the strongest cipher suites (ECDHE with AES-GCM). Disable TLS 1.0/1.1 and SSLv3 entirely.

Encryption at Rest — Database and File Storage

Encryption at rest protects data stored on persistent media. There are two primary levels: Transparent Data Encryption (TDE) and Application-Level Encryption. TDE, offered by AWS RDS or Azure SQL, encrypts the entire database file on the disk. However, if a user gains access to the database via an SQL injection, TDE won't help because the database engine decrypts data for the authorized process.

For high-stakes data (like SSNs or API keys), we use Application-Level Encryption. Here, the data is encrypted before it ever hits the database driver. Even a root-level database admin cannot see the raw values without access to the keys stored in an external Secrets Manager like AWS KMS or HashiCorp Vault.

When implementing field-level encryption, pay attention to IV generation and key rotation. AES-GCM is the recommended mode because it provides authenticated encryption — it detects if data has been tampered with.

package io.thecodeforge.security;

import javax.crypto.Cipher;
import javax.crypto.spec.GCMParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import java.security.SecureRandom;
import java.util.Base64;

/**
 * Field-Level Encryption Utility
 * Standard: AES/GCM/NoPadding (Production recommended over ECB/CBC)
 */
public class EncryptionService {

    private static final String ALGORITHM = "AES/GCM/NoPadding";
    private static final int GCM_TAG_LENGTH = 128; // bits
    private static final int IV_LENGTH = 12; // bytes
    // In production, retrieve this key from AWS KMS or HashiCorp Vault
    private byte[] encryptionKey = System.getenv("DB_ENCRYPTION_KEY").getBytes();
    private SecureRandom secureRandom = new SecureRandom();

    public String encrypt(String data) throws Exception {
        SecretKeySpec secretKey = new SecretKeySpec(encryptionKey, "AES");
        Cipher cipher = Cipher.getInstance(ALGORITHM);
        byte[] iv = new byte[IV_LENGTH];
        secureRandom.nextBytes(iv);
        GCMParameterSpec gcmSpec = new GCMParameterSpec(GCM_TAG_LENGTH, iv);
        cipher.init(Cipher.ENCRYPT_MODE, secretKey, gcmSpec);
        byte[] cipherText = cipher.doFinal(data.getBytes());
        // Prepend IV to ciphertext for storage
        byte[] combined = new byte[IV_LENGTH + cipherText.length];
        System.arraycopy(iv, 0, combined, 0, IV_LENGTH);
        System.arraycopy(cipherText, 0, combined, IV_LENGTH, cipherText.length);
        return Base64.getEncoder().encodeToString(combined);
    }

    public String decrypt(String encryptedData) throws Exception {
        byte[] combined = Base64.getDecoder().decode(encryptedData);
        byte[] iv = new byte[IV_LENGTH];
        byte[] cipherText = new byte[combined.length - IV_LENGTH];
        System.arraycopy(combined, 0, iv, 0, IV_LENGTH);
        System.arraycopy(combined, IV_LENGTH, cipherText, 0, cipherText.length);
        SecretKeySpec secretKey = new SecretKeySpec(encryptionKey, "AES");
        Cipher cipher = Cipher.getInstance(ALGORITHM);
        GCMParameterSpec gcmSpec = new GCMParameterSpec(GCM_TAG_LENGTH, iv);
        cipher.init(Cipher.DECRYPT_MODE, secretKey, gcmSpec);
        return new String(cipher.doFinal(cipherText));
    }
}

// usage: entity.setSsn(encryptionService.encrypt(rawSsn));
// Store IV alongside ciphertext — it's not secret

AES Encryption Modes Comparison (ECB, CBC, CTR, GCM)

AES operates on 128-bit blocks and can be used in different modes. The choice of mode dramatically affects security, performance, and features. Below is a comparison of the most common modes:

GCM is the gold standard for symmetric encryption in production. It combines AES-CTR with a cryptographic hash (GHASH) to provide integrity verification. Always use GCM with a 12-byte random IV and never reuse the IV with the same key. Avoid ECB entirely. CBC can be used if authenticated separately (e.g., CBC + HMAC), but GCM is simpler and more performant.

Symmetric vs Asymmetric Encryption — Comparison

Encryption algorithms fall into two categories: symmetric (same key for encryption and decryption) and asymmetric (public/private key pair). Both are essential in modern cryptography. The table below contrasts them:

In practice, systems combine both: asymmetric encryption (RSA or ECDH) is used to exchange a symmetric session key, and then symmetric encryption (AES-GCM) is used for the actual data. This is called a hybrid cryptosystem. For example, TLS uses ECDHE for key agreement (asymmetric) and AES-GCM for bulk encryption (symmetric). For encryption at rest, we use symmetric encryption (AES) directly, but the encryption key is often wrapped (asymmetrically) using a master key in a KMS.

Key Management — The Hardest Part of Encryption

Encryption without proper key management is like locking a door and leaving the key in the lock. The security of your encrypted data ultimately rests on the secrecy and integrity of the encryption keys. This means you must never hardcode keys, never store them in the same database as the encrypted data, and never share them via email or chat.

Production-grade key management involves three principles: (1) Use a dedicated Hardware Security Module (HSM) or cloud Key Management Service (KMS) to generate, store, and rotate keys. (2) Implement key rotation policies — regularly generate new key versions and retire old ones. (3) Control access to keys with strict IAM policies and audit all usage.

Cloud providers offer managed KMS solutions (AWS KMS, Azure Key Vault, GCP Cloud KMS) that integrate seamlessly with their services. For multi-cloud or on-prem, HashiCorp Vault is a popular choice. A common pattern is envelope encryption: a master key (kept in the KMS) encrypts data keys, and the data keys encrypt your actual data. This allows efficient rotation of data keys without touching the encrypted payloads.

package io.thecodeforge.security;

import software.amazon.awssdk.core.SdkBytes;
import software.amazon.awssdk.services.kms.KmsClient;
import software.amazon.awssdk.services.kms.model.*;

public class KmsService {

    private final KmsClient kmsClient;
    private final String keyId = System.getenv("KMS_KEY_ID");

    public KmsService() {
        this.kmsClient = KmsClient.builder().build();
    }

    public byte[] encryptData(byte[] plaintext) {
        EncryptRequest request = EncryptRequest.builder()
                .keyId(keyId)
                .plaintext(SdkBytes.fromByteArray(plaintext))
                .encryptionAlgorithm(EncryptionAlgorithmSpec.SYMMETRIC_DEFAULT)
                .build();
        EncryptResponse response = kmsClient.encrypt(request);
        return response.ciphertextBlob().asByteArray();
    }

    public byte[] decryptData(byte[] ciphertext) {
        DecryptRequest request = DecryptRequest.builder()
                .keyId(keyId)
                .ciphertextBlob(SdkBytes.fromByteArray(ciphertext))
                .encryptionAlgorithm(EncryptionAlgorithmSpec.SYMMETRIC_DEFAULT)
                .build();
        DecryptResponse response = kmsClient.decrypt(request);
        return response.plaintext().asByteArray();
    }
}

// Usage: KMS encrypts/decrypts app-level data keys, not the raw payload.
// Store encrypted data keys alongside ciphertext for envelope encryption.

End-to-End Encryption (E2EE)

End-to-End Encryption ensures that data is encrypted on the sender's device and can only be decrypted on the intended recipient's device. No intermediary — including the server that facilitates the communication — can read the plaintext. This is different from TLS, which only protects data between the client and server; the server sees plaintext.

E2EE typically uses asymmetric encryption: each user has a public-private key pair. The sender encrypts the message with the recipient's public key, which can only be decrypted with the recipient's private key. In practice, for performance, a hybrid approach is used: a random symmetric key is encrypted with the recipient's public key, and the message is encrypted with that symmetric key.

Common applications include messaging apps (Signal, WhatsApp), email (PGP), and file sharing. Implementing E2EE in a web application is complex because the server never has access to the private keys — they must be stored client-side (e.g., in the browser's IndexedDB) and derived from a user password. This makes features like server-side search or server-side key rotation impossible without additional cryptographic techniques.

Application-Level Encryption Patterns in Spring Boot

Spring Boot applications often handle sensitive data that must be encrypted before persistence. A common approach is to create a JPA AttributeConverter that transparently encrypts and decrypts entity fields. This keeps encryption logic out of business code and ensures every read/write goes through encryption.

However, AttributeConverter has a significant gotcha: it runs inside the JPA transaction context. If encryption fails (e.g., KMS is unreachable), the entire transaction may roll back. Always handle encryption failures gracefully — consider storing an error marker or retrying with a fallback key. Also, note that AttributeConverter encrypts the column value, so any direct database queries or reports will see the ciphertext — you cannot query by plaintext directly without deterministic encryption.

For searchable encrypted fields, use deterministic encryption (AES-SIV) or a separate search index. Never use ECB mode. And remember: encrypting a field prevents indexing in most databases, so only encrypt fields that truly need it.

package io.thecodeforge.security;

import javax.persistence.AttributeConverter;
import javax.persistence.Converter;

@Converter
public class SsnAttributeConverter implements AttributeConverter<String, String> {

    private final EncryptionService encryptionService; // inject via Spring

    public SsnAttributeConverter(EncryptionService encryptionService) {
        this.encryptionService = encryptionService;
    }

    @Override
    public String convertToDatabaseColumn(String plainSsn) {
        if (plainSsn == null) return null;
        try {
            return encryptionService.encrypt(plainSsn);
        } catch (Exception e) {
            // Log error and rethrow as runtime exception to rollback transaction
            throw new RuntimeException("Encryption failed for SSN", e);
        }
    }

    @Override
    public String convertToEntityAttribute(String encryptedSsn) {
        if (encryptedSsn == null) return null;
        try {
            return encryptionService.decrypt(encryptedSsn);
        } catch (Exception e) {
            // Log error and return a placeholder or throw based on business needs
            throw new RuntimeException("Decryption failed for SSN", e);
        }
    }
}

// Usage in entity:
// @Convert(converter = SsnAttributeConverter.class)
// @Column(name = "ssn")
// private String ssn;

Encryption Performance Considerations

Encryption adds CPU overhead and latency, but modern hardware mitigates most of the impact. Key factors:

AES-NI Hardware Acceleration Most modern x86-64 processors (Intel Core i5/i7, Xeon, AMD Ryzen) include AES-NI instructions that accelerate AES encryption. With AES-NI, AES-256-GCM encryption/decryption runs at line rate (~1GB/s per core) with negligible CPU cost. Without AES-NI, software-based AES is still fast but can be 5-10x slower. Always verify AES-NI is enabled in your cloud instance type (e.g., AWS C5/m5 series have AES-NI; T2/t3.micro may not).

TLS Handshake Cost Establishing a new TLS connection involves asymmetric cryptography (key exchange) which is CPU-intensive. TLS 1.3 reduces the handshake from 2-RTT to 1-RTT (full handshake) and supports 0-RTT for resumption. The actual CPU cost of a full TLS 1.3 handshake is around 0.5-1ms on modern hardware (ECDHE key exchange). However, network round trips dominate latency — typically 5-30ms for a full handshake. Connection reuse (keep-alive, session resumption) eliminates this overhead.

Application-Level Encryption Overhead Encrypting a single database field with AES-GCM takes roughly 0.5-1µs per 1KB on a modern CPU with AES-NI. For a single API call encrypting 10 fields, total latency is <10µs — negligible compared to database round trips. The bigger cost is network round trips to KMS if you decrypt every time. Caching decrypted data keys locally (with proper expiry) reduces this.

Performance Best Practices 1. Enable AES-NI: ensure your deployment uses instances with AES-NI support (check /proc/cpuinfo or sysctl machdep.cpu.features on macOS). 2. Use TLS 1.3 and session resumption to minimize handshake overhead. 3. Cache KMS-decrypted data keys in local memory (with TTL). 4. For bulk encryption, use streaming encryption (e.g., CipherInputStream) to avoid large memory allocations. 5. Profile encryption overhead before optimizing — often encryption is not the bottleneck.

Compliance and Standards — PCI DSS, HIPAA, GDPR

Encryption isn't just a technical decision — it's a compliance requirement. Regulations like PCI DSS, HIPAA, and GDPR mandate encryption of specific data types. For example, PCI DSS Requirement 3.4 requires rendering PAN (Primary Account Number) unreadable anywhere it is stored, which typically means encryption, truncation, or tokenization. HIPAA's Security Rule requires encryption of ePHI (electronic Protected Health Information) at rest and in transit.

Meeting compliance requires more than just turning on encryption. You must demonstrate control over key management, prove that encryption is properly configured, and maintain audit logs of all encryption operations. Many compliance frameworks also require annual penetration testing and vulnerability scans that verify encryption configurations.

The key takeaway: encryption for compliance is often about process as much as technology. You need documented policies, access controls, and regular reviews. Tools like AWS Artifact and Azure Compliance Manager help maintain documentation, but the implementation must be correct at the code level.

# Example AWS Config rule to check that S3 buckets enforce encryption at rest
Resources:
  S3BucketEncryption:
    Type: AWS::Config::ConfigRule
    Properties:
      Source:
        Owner: AWS
        SourceIdentifier: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED
      Scope:
        ComplianceResourceTypes:
          - AWS::S3::Bucket
      InputParameters:
        # Enforce SSE-KMS with specific KMS key
        # allowedEncryptionOptions: SSE-KMS

# Azure Policy to require encryption at rest for storage accounts
# https://docs.microsoft.com/en-us/azure/governance/policy/samples/require-storage-account-encryption

Compliance Requirements Comparison Table

Regulations have specific but sometimes overlapping encryption requirements. The following table compares PCI DSS, HIPAA, and GDPR:

Practical implications: If you store credit card data, you must comply with PCI DSS — this means using AES-256 for rest, enforcing TLS 1.2+ for transit, and implementing strict key management with rotation. For healthcare, HIPAA's addressable encryption means you must evaluate and decide; in practice, all covered entities encrypt ePHI. GDPR does not prescribe specific algorithms but expects encryption as part of 'data protection by design'.