Encryption at rest and in transit in HLD - System Design Exercise

Design: Encryption at rest and in transit

Focus on designing encryption mechanisms for data storage and communication channels. Key management and rotation included. Out of scope: detailed cryptographic algorithm design and hardware security modules.

Functional Requirements

FR1: Protect sensitive data stored on disk or in databases (encryption at rest)

FR2: Protect data while it moves between clients, servers, and services (encryption in transit)

FR3: Ensure encryption keys are securely managed and rotated

FR4: Support compliance with common security standards (e.g., GDPR, HIPAA)

FR5: Minimize performance impact on system operations

Non-Functional Requirements

NFR1: System must handle up to 100,000 concurrent users securely

NFR2: Encryption and decryption latency should not exceed 50ms per request

NFR3: Availability target of 99.9% uptime

NFR4: Key management must prevent unauthorized access and support audit logging

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Encryption libraries or services for data at rest

TLS/SSL for encryption in transit

Key Management Service (KMS)

Authentication and authorization systems

Audit logging system for key usage

Design Patterns

End-to-end encryption

Envelope encryption (data encrypted with data key, data key encrypted with master key)

Mutual TLS for client-server authentication

Key rotation and versioning

Secure key storage (e.g., Hardware Security Module or cloud KMS)

Reference Architecture

  +-------------+          +----------------+          +-------------+
  |   Client    | <------> |  Load Balancer | <------> | Application |
  +-------------+   TLS    +----------------+   TLS    +-------------+
                                      |                        |
                                      |                        |
                                +-------------+          +-------------+
                                |  Key Mgmt   |          |   Database  |
                                |   Service   |          | (Encrypted) |
                                +-------------+          +-------------+

Components

Client

Web/Mobile app with TLS support

Initiates secure connections using TLS to protect data in transit

Load Balancer

Nginx/HAProxy with TLS termination or passthrough

Distributes incoming requests securely and maintains encrypted channels

Application

Backend service with encryption libraries (e.g., OpenSSL, libsodium)

Encrypts/decrypts data at rest and communicates securely

Key Management Service (KMS)

Cloud KMS (AWS KMS, Google KMS) or on-prem HSM

Generates, stores, rotates, and audits encryption keys securely

Database

Relational or NoSQL DB with encryption support

Stores encrypted data ensuring encryption at rest

Request Flow

1. Client establishes a TLS connection to the Load Balancer to secure data in transit.

2. Load Balancer forwards the encrypted request to the Application server over TLS.

3. Application requests encryption keys from the Key Management Service to encrypt sensitive data before storing.

4. Application encrypts data using data keys and stores encrypted data in the Database.

5. When reading data, Application retrieves encrypted data from Database, requests keys from KMS, decrypts data, and sends response over TLS back to Client.

6. Key Management Service handles key rotation and audit logging transparently.

Database Schema

Entities: - EncryptedData: stores encrypted blobs with metadata (id, encrypted_content, encryption_key_version, timestamp) - KeyMetadata: stores key versions, creation date, status (active, retired) Relationships: - EncryptedData references KeyMetadata by encryption_key_version to track which key encrypted the data

Scaling Discussion

Bottlenecks

Key Management Service becoming a single point of failure or performance bottleneck

Encryption and decryption operations adding latency under high load

Database I/O overhead due to encryption increasing storage and retrieval time

TLS handshake overhead for large numbers of concurrent connections

Solutions

Use distributed and highly available KMS with caching of keys at application layer

Offload encryption/decryption to dedicated hardware or use asynchronous processing where possible

Use database encryption features optimized for performance and compress encrypted data

Implement TLS session reuse and keep-alive connections to reduce handshake overhead

Interview Tips

Time: Spend 10 minutes understanding requirements and constraints, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and security trade-offs, 5 minutes summarizing.

Explain difference and importance of encryption at rest vs in transit

Discuss secure key management and rotation strategies

Highlight use of TLS for protecting data in transit

Describe how encryption impacts system performance and how to mitigate

Mention compliance and audit logging as critical non-functional requirements

Practice

1. What is the main purpose of encryption at rest in system design?

easy

A. To protect stored data from unauthorized access

B. To speed up data transmission over the network

C. To compress data for storage efficiency

D. To authenticate users before accessing the system

Solution

1. Step 1: Understand encryption at rest

   Encryption at rest means encrypting data when it is stored on disks or databases to prevent unauthorized access.

2. Step 2: Identify the main goal

   The main goal is to protect stored data from being read by unauthorized users if the storage is compromised.

3. Final Answer:

   To protect stored data from unauthorized access -> Option A

4. Quick Check:

   Encryption at rest = Protect stored data [OK]

Hint: Encryption at rest means securing stored data only [OK]

Common Mistakes:

• Confusing encryption at rest with encryption in transit
• Thinking encryption at rest speeds up data
• Mixing encryption with user authentication

2. Which of the following is the correct protocol used for encryption in transit?

easy

A. AES-256

B. TLS (Transport Layer Security)

C. SHA-256

D. RSA key exchange

Solution

1. Step 1: Identify encryption in transit protocols

   Encryption in transit protects data moving over networks. TLS is the standard protocol for this purpose.

2. Step 2: Differentiate options

   AES-256 is a symmetric encryption algorithm (used for data at rest), SHA-256 is a hash function, RSA is an encryption algorithm but not a protocol for transit encryption.

3. Final Answer:

   TLS (Transport Layer Security) -> Option B

4. Quick Check:

   Encryption in transit = TLS protocol [OK]

Hint: TLS is the standard for encrypting data in transit [OK]

Common Mistakes:

• Confusing encryption algorithms with protocols
• Choosing AES or RSA as transit protocols
• Mixing hash functions with encryption

3. Consider a system where data is encrypted with AES-256 before storage and TLS is used for network communication. What is the main benefit of this design?

medium

A. Data transmission speed is maximized

B. Only stored data is protected, transmission is not

C. Data is protected both when stored and when transmitted

D. Encryption is only applied to user passwords

Solution

1. Step 1: Analyze encryption at rest with AES-256

   AES-256 encrypts data stored on disk, protecting it from unauthorized access.

2. Step 2: Analyze encryption in transit with TLS

   TLS encrypts data moving over the network, preventing interception or tampering.

3. Step 3: Combine both protections

   Using both means data is secure when stored and when sent, covering both attack surfaces.

4. Final Answer:

   Data is protected both when stored and when transmitted -> Option C

5. Quick Check:

   AES-256 + TLS = Full data protection [OK]

Hint: AES for storage + TLS for network = full data protection [OK]

Common Mistakes:

• Assuming TLS speeds up transmission
• Thinking encryption only protects passwords
• Ignoring encryption in transit

4. A developer implemented encryption in transit using HTTP instead of HTTPS. What is the main issue with this approach?

medium

A. Data is not encrypted during transmission

B. Data is encrypted but stored insecurely

C. Encryption keys are exposed in the database

D. Data is encrypted only at rest, not in transit

Solution

1. Step 1: Understand difference between HTTP and HTTPS

   HTTP transmits data in plain text, while HTTPS uses TLS to encrypt data in transit.

2. Step 2: Identify the problem with using HTTP

   Using HTTP means data is sent unencrypted, vulnerable to interception and attacks.

3. Final Answer:

   Data is not encrypted during transmission -> Option A

4. Quick Check:

   HTTP = no encryption in transit [OK]

Hint: HTTP sends data unencrypted; HTTPS encrypts it [OK]

Common Mistakes:

• Confusing encryption at rest with in transit
• Assuming HTTP encrypts data
• Thinking keys are exposed due to HTTP

5. You are designing a cloud storage system that must comply with strict security standards. Which combination best ensures data confidentiality both when stored and when accessed remotely?

hard

A. Encrypt data only during transmission using SSL 2.0

B. Use SHA-256 hashing for stored data and HTTP for data transfer

C. Store data unencrypted and rely on VPN for secure access

D. Encrypt data at rest with AES-256 and use TLS 1.3 for all client-server communication

Solution

1. Step 1: Identify strong encryption for data at rest

   AES-256 is a widely accepted strong encryption standard for stored data.

2. Step 2: Choose secure protocol for data in transit

   TLS 1.3 is the latest secure protocol for encrypting data during transmission, better than older SSL versions.

3. Step 3: Evaluate other options

   SHA-256 is a hash, not encryption; HTTP is unencrypted; VPN alone does not encrypt stored data; SSL 2.0 is outdated and insecure.

4. Final Answer:

   Encrypt data at rest with AES-256 and use TLS 1.3 for all client-server communication -> Option D

5. Quick Check:

   AES-256 + TLS 1.3 = Best practice for confidentiality [OK]

Hint: Use AES-256 for storage and TLS 1.3 for transmission [OK]

Common Mistakes:

• Using outdated SSL instead of TLS
• Confusing hashing with encryption
• Relying only on VPN without encryption