20  Review: Checks & Scenarios

20.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Analyze Security Scenarios: Apply encryption knowledge to real-world IoT situations
  • Identify Attack Vectors: Identify how encryption prevents (or fails to prevent) specific attacks
  • Evaluate Trade-offs: Balance security, performance, and cost in encryption decisions
  • Design Secure Systems: Choose appropriate encryption layers for different threat models
In 60 Seconds

Understanding-check scenarios help you apply IoT encryption concepts to real-world situations such as smart home devices, industrial sensors, and medical wearables — reinforcing when to use AES-GCM, ECC, TLS, DTLS, or certificate pinning.

20.2 For Beginners: Review: Checks & Scenarios

This chapter helps you review and consolidate your understanding of cryptography for IoT. Think of it as checking your toolkit before a job — making sure you understand each tool and when to use it. Cryptography is only effective when applied correctly, so solid understanding is essential.

20.3 Prerequisites

Required Chapters:

Estimated Time: 35 minutes

20.4 Introduction

This chapter presents scenario-based understanding checks that test your ability to apply encryption concepts to real-world IoT security challenges. Work through each scenario carefully, thinking about the security implications before reading the key insights.

20.5 Understanding Check: Multi-Layer Encryption for Medical IoT

Scenario: Hospital deploying 1,000 patient vital sign monitors. Data flows: Bedside monitor → Ward gateway → Hospital cloud → Doctor’s tablet.

Threat Model:

  • Wireless sniffing: Attacker with Wi-Fi packet capture in parking lot
  • Compromised gateway: Ransomware infects ward gateway computer
  • Insider threat: IT admin with physical access to gateway

Encryption Options:

Option A: E2 Only (Device-to-Gateway)

Monitor --[AES-256]--> Gateway --[plaintext]--> Cloud --[TLS]--> Doctor
              ✓ Protected            ✗ Vulnerable!
  • Attacker in parking lot: ✓ Blocked by E2
  • Compromised gateway: ✗ Sees plaintext (heart rate, BP, patient ID)
  • Insider admin: ✗ Accesses plaintext logs on gateway

Option B: E2 + E4 (No End-to-End)

Monitor --[AES-256]--> Gateway --[TLS]--> Cloud --[TLS]--> Doctor
              ✓                    ✓              ✓
  • Attacker in parking lot: ✓ Blocked by E2
  • Compromised gateway: ✗ Still decrypts E2, re-encrypts E4 (plaintext exposure during processing)
  • Insider admin: ✗ Dumps gateway memory, sees plaintext

Option C: E3 (Device-to-Cloud End-to-End)

Monitor --[E3: RSA pub key of cloud]--> Gateway --[E3 passthrough]--> Cloud
              ✓ Encrypted payload                  ✓ Cannot decrypt       ✓ Only cloud decrypts
  • Attacker in parking lot: ✓ Blocked (E3 encrypted)
  • Compromised gateway: ✓ Cannot decrypt (doesn’t have cloud’s private key)
  • Insider admin: ✓ Cannot decrypt (E3 payload is opaque to gateway)

Option D: Defense-in-Depth (E2 + E3 + E4)

Monitor --[E2+E3 nested]--> Gateway --[E3 inside E4]--> Cloud
    E3: Patient vitals (AES-256-GCM, cloud's key)
    E2: Link-layer protection (WPA2)
    E4: Transport security (TLS 1.3)

The Decision: Option D (Defense-in-Depth)

Why layer all three?

  • E2 (Link-layer): Prevents casual Wi-Fi sniffing (free with WPA2)
  • E3 (End-to-end): Guarantees even compromised gateway can’t read vitals
  • E4 (Transport): Protects E3 packets during internet transit

Real-World Impact:

Incident: Hospital gateway compromised (2021)

  • Ransomware infected ward computer (gateway)
  • E2-only design: 500 patient records exposed (PHI breach)
  • HIPAA fine: $1.2 million
  • With E3: Encrypted payload unreadable to ransomware ✓

Cost Analysis:

E2 only: Free (WPA2 hardware)
E3 implementation:
  - Firmware update (40 hours dev time = $6k)
  - Cloud PKI infrastructure ($500/year)
  - Per-device RSA key pair (negligible)

HIPAA breach fine: $1.2M
E3 cost: $6.5k

ROI: $6.5k to prevent $1.2M fine = 185× return

Key Lesson: Medical IoT (HIPAA), financial IoT, and critical infrastructure should never trust intermediaries. E3 end-to-end encryption ensures that even if gateway is compromised, patient data remains confidential.

Implementation Notes:

  • E3 uses cloud’s RSA public key (embedded in device firmware at manufacturing)
  • Gateway forwards encrypted blobs (no decryption capability)
  • Cloud decrypts with private key (never leaves secure HSM)
  • Doctor’s tablet gets data via TLS from cloud (separate encryption)

When to Skip E3:

  • Non-sensitive data (soil moisture for agriculture)
  • Fully trusted gateway (your own edge server, physical security)
  • Gateway needs to process data locally (anomaly detection requires plaintext)

20.6 Understanding Check: Securing Smart Factory OTA Updates

Scenario: You’re deploying firmware updates to 5,000 industrial robots on a factory floor. Each robot runs safety-critical motion control code. Updates must be delivered through potentially compromised edge gateways (factory Wi-Fi APs can be physically accessed by contractors).

Attack Risk: Attacker compromises gateway, injects malicious firmware update that disables safety limits, causing robot to harm workers.

Think about:

  1. If you encrypt firmware using E2 (device-to-gateway AES-256), the gateway decrypts it and re-encrypts with E4 for cloud transmission. Can the compromised gateway inject malicious code?
  2. What encryption architecture ensures the gateway cannot tamper with firmware even if fully compromised?

Key Insight: E3 (Device-to-Cloud end-to-end encryption) is mandatory. The firmware update is encrypted with the robot’s public key (or cloud’s key) before leaving the server. The compromised gateway can only forward the encrypted blob—it cannot decrypt, modify, or inject code. Only the robot’s secure bootloader with the matching private key can decrypt and verify the firmware signature. This costs ~$0.15/device for secure element (ATECC608) but prevents $50M liability from unsafe robot operation.

Verify Your Understanding:

  • Why can’t the robot verify firmware authenticity using just E2 encryption? (Hint: Compromised gateway has the E2 decryption key and can re-encrypt malicious payload)
  • What happens if you use E2+E4 without E3? (Gateway sees plaintext firmware during decryption→re-encryption, can inject backdoors)

20.7 Understanding Check: Link-Layer Encryption for Battery Life

Scenario: Deploying 10,000 LoRaWAN soil moisture sensors in agriculture fields. Each sensor transmits 24 bytes every 15 minutes. Target battery life: 10 years on 2× AA batteries.

Encryption Options:

  • Software AES-128 (E2 layer): MCU encrypts, consumes 12mA for 40ms = 480µJ per transmission
  • Hardware AES-128 (E1 layer): Radio chip encrypts, consumes 8mA for 2ms = 16µJ per transmission

Think about:

  1. Which encryption approach uses 30× less energy per transmission?
  2. Over 10 years (350,400 transmissions), how much total energy is saved?

Key Insight: E1 hardware encryption extends battery life significantly. Over 10 years (~350,640 transmissions), software AES consumes ~168 J total versus ~5.6 J for hardware AES — a 30x energy saving that translates to months of additional battery life. The LoRa radio chip already has an AES-128 accelerator (SX1276/1278) — using it costs zero additional hardware. But E1 alone is insufficient for security (shared network key). Best practice: E1 for energy savings + E2 for per-device security = defense-in-depth without battery penalty (E2 encrypts payload, E1 encrypts frame).

Verify Your Understanding:

  • Why does hardware encryption consume 30× less power? (No CPU cycles, dedicated silicon, no context switching)
  • Can you skip E2 and use only E1 to save even more power? (No! E1 uses shared network key—one compromised sensor exposes all 10,000 devices)

20.8 Understanding Check: Replay Attack Prevention in Smart Grid

Scenario: Smart meter sends encrypted power consumption readings every 5 minutes to utility company. Attacker records 100 encrypted messages from January (low usage, $80 bill) and replays them in July (high A/C usage should be $280 bill).

Without Sequence Numbers:

Attacker replays old encrypted messages:
Meter → Gateway: [AES-encrypted: "150 kWh used"]  (actually 450 kWh used now)
Gateway accepts it (encryption is valid!)
Utility bills customer $80 instead of $280

Think about:

  1. The encryption is correct, the AES key hasn’t changed. Why doesn’t encryption prevent this attack?
  2. What additional security property beyond confidentiality is needed?

Key Insight: E2 sequence numbers provide freshness. Each transmission includes monotonically increasing counter encrypted with payload:

January msg #1000: AES-encrypt("150 kWh | sequence: 1000")
July msg #10000: AES-encrypt("450 kWh | sequence: 10000")

Gateway tracks highest sequence number received (10,000). When attacker replays January message (sequence 1000), gateway rejects: “1000 < 10,000 = replay attack!” This costs 4 bytes per message but prevents $200/month theft × 1M meters = $2.4B annual fraud prevention. Implementation: nonce or timestamp works too, but counter is simplest for embedded devices.

Verify Your Understanding:

  • Why doesn’t encryption alone prevent replay attacks? (Valid ciphertext is valid ciphertext, regardless of when it was created)
  • What happens if the sequence counter overflows at 2^32? (Plan for rollover: accept small backward window, or force key renewal before overflow)

20.9 Understanding Check: RSA Key Distribution at Manufacturing Scale

Scenario: Manufacturing 1 million smart door locks. Each lock needs unique AES-256 encryption key for cloud communication. How do you securely deliver these keys?

Option A: Pre-shared Keys Hardcoded in Firmware

firmware.bin contains:
  AES_KEY = "6B5A8C92E4..." (same for all 1M locks!)

Risk: Attacker extracts firmware from one lock → decrypts ALL 1M locks’ communications → unlocks every door remotely.

Option B: Generate Keys On-Device, Upload to Cloud

Lock generates AES key on first boot:
  Lock → Cloud: [PLAINTEXT] "My key is 6B5A..."

Risk: Attacker sniffs Wi-Fi during provisioning → captures all keys → owns the lock forever.

Think about:

  1. How can lock and cloud establish a shared secret without ever transmitting the secret itself?
  2. What’s the role of RSA public-private key pairs?

Key Insight: E5 uses RSA asymmetric encryption for secure key establishment: 1. Manufacturing: Each lock gets unique RSA key pair generated by HSM, public key uploaded to cloud database, private key burned to lock’s secure element (never leaves device) 2. First boot: Cloud generates random AES-256 session key, encrypts with lock’s public key (from database), sends encrypted key to lock 3. Lock decrypts: Uses its private key (only it possesses) to decrypt session key 4. Secure channel established: Both sides have AES key, but it was never transmitted in plaintext

Cost Analysis:

  • RSA key generation at scale: $0.02/device (HSM amortized cost)
  • ATECC608 secure element: $0.50/device
  • Alternative cost: Recalled 1M locks due to master key compromise = $18M

ROI: $520,000 investment prevents $18M recall = 35× return

Verify Your Understanding:

  • Why can’t you just use AES for key exchange? (Chicken-and-egg: Need a shared key to encrypt the shared key!)
  • Why is RSA slower than AES but used anyway? (Solves key distribution—only used once for handshake, then fast AES takes over)

20.10 Understanding Check: Brute Force Attack Timeline

Scenario: Attacker steals encrypted medical IoT device data (patient vital signs from 1,000 ICU patients). Data is encrypted with AES-128. Attacker rents AWS compute to brute-force the key.

Computing Power Available:

  • AWS EC2 p3.16xlarge: $24.48/hour, 10^9 keys/second tested
  • Total possible AES-128 keys: 2^128 = 3.4 × 10^38 keys

Think about:

  1. How long would it take to test all possible keys?
  2. Is this attack practical?

Key Insight: 2^128 operations = 5.4 × 10^21 years to test half the keyspace (statistically find key). That’s 392 billion times the age of the universe (13.8 billion years). Even with every computer on Earth working together (10^18 operations/second globally), it would still take 5.4 million years.

Cost Analysis:

AWS cost to break AES-128:
Time: 5.4 × 10^21 years
Rate: $24.48/hour = $214,406/year
Total: $1.16 × 10^27 dollars

For reference: World GDP = $100 trillion = 10^14 dollars
Cost is 10 trillion times greater than all money on Earth

Why AES-128 is “computationally infeasible” to break. The work factor 2^128 means the universe will end before a single key is cracked. This is why we use 128-bit keys—not because it’s impossible, but because the energy required exceeds the total energy output of the sun over its entire lifetime.

Comparing AES-128 vs AES-256 Quantum Resistance:

For a medical IoT system storing patient data encrypted with AES, evaluate the quantum threat timeline and whether upgrading from AES-128 to AES-256 is justified.

Classical Brute Force (Current Computers):

AES-128 keyspace: \[ \text{Possible keys} = 2^{128} = 3.4 \times 10^{38} \]

\[ \text{Operations to find key (average)} = \frac{2^{128}}{2} = 2^{127} = 1.7 \times 10^{38} \]

At \(10^9\) keys/second (AWS GPU): \[ \text{Time to crack} = \frac{1.7 \times 10^{38}}{10^9} = 1.7 \times 10^{29} \text{ seconds} = 5.4 \times 10^{21} \text{ years} \]

AES-256 keyspace: \[ \text{Possible keys} = 2^{256} = 1.16 \times 10^{77} \]

\[ \text{Time to crack} = 5.4 \times 10^{21} \times 2^{128} = 1.8 \times 10^{60} \text{ years} \]

Quantum Attack (Grover’s Algorithm):

Grover’s algorithm reduces effective keyspace by \(\sqrt{N}\):

AES-128 with quantum computer: \[ \text{Effective security} = \sqrt{2^{128}} = 2^{64} \text{ operations} \]

\[ \text{Time to crack (quantum)} = \frac{2^{64}}{10^{15}} = \frac{1.84 \times 10^{19}}{10^{15}} = 18,400 \text{ seconds} = 5.1 \text{ hours} \]

AES-256 with quantum computer: \[ \text{Effective security} = \sqrt{2^{256}} = 2^{128} \text{ operations} \]

\[ \text{Time to crack (quantum)} = \frac{2^{128}}{10^{15}} = 3.4 \times 10^{23} \text{ seconds} = 10.8 \times 10^{15} \text{ years} \]

Timeline Assessment:

Conservative quantum computer timeline (NIST estimates): - 2030: First quantum computers with 1,000 logical qubits (insufficient for Grover’s on AES) - 2040: Quantum computers with \(10^6\) logical qubits (can run Grover’s on small problems) - 2050+: Large-scale quantum computers capable of breaking AES-128 in hours

Decision Framework:

For medical data with 30-year retention requirement: \[ \text{Vulnerability window} = \text{Data creation (2026)} + \text{30 years retention} - \text{Quantum threat (2050)} = 6 \text{ years exposed} \]

Cost-Benefit Analysis:

AES-256 performance penalty on ESP32: \[ \text{Encryption slowdown} = \frac{0.9 \text{ MB/s (AES-256)}}{1.2 \text{ MB/s (AES-128)}} = 0.75 \times \text{ speed} \]

\[ \text{Power increase} = \frac{24 \text{ mA (AES-256)}}{18 \text{ mA (AES-128)}} - 1 = 33\% \text{ more power} \]

For 10,000 medical devices running 24/7 for 30 years: \[ \text{Extra power cost} = 10,000 \times 0.006 \text{ W} \times 24 \times 365 \times 30 \times \$0.12/\text{kWh} = \$5,700 \]

Recommendation: Use AES-256 for medical IoT. The $5,700 power cost over 30 years is negligible compared to HIPAA breach fines ($50,000/record), and quantum computers may become viable before 2050.

Verify Your Understanding:

  • Why use AES-256 if AES-128 is already unbreakable? (Future-proofing against quantum computers; AES-128 → 2^64 quantum, AES-256 → 2^128 quantum, both still safe)
  • What’s the actual vulnerability if AES-128 gets “broken”? (Not brute force, but cryptographic weaknesses reducing effective key strength—hasn’t happened in 20+ years)

20.11 Understanding Check: Authenticated Encryption for Medical Devices

Scenario: Insulin pump receives encrypted dosage commands from smartphone app. Attacker intercepts encrypted command: [AES-encrypted: "Inject 5 units insulin"]

Without Authentication (Encryption-Only):

Attacker modifies ciphertext bits (bit-flipping attack):
Original ciphertext: 0x6B 0x5A 0x8C ...
Flipped ciphertext:  0x6B 0x5A 0x9C ... (changed one bit)

Pump decrypts modified ciphertext:
Result: "Inject 50 units insulin" (lethal overdose!)

Think about:

  1. The attacker doesn’t know the decryption key. How can they modify the message?
  2. What cryptographic property prevents tampering detection?

Key Insight: AES-GCM provides authenticated encryption (confidentiality + integrity). It computes GMAC tag over ciphertext:

Encrypt: ciphertext = AES-GCM-encrypt(key, "Inject 5 units")
         auth_tag = GMAC(key, ciphertext)
Transmit: [ciphertext | auth_tag]

Decrypt: computed_tag = GMAC(key, received_ciphertext)
         if computed_tag != received_auth_tag:
             REJECT! Tampering detected!

When attacker flips bits, the auth tag verification fails. Pump detects tampering and refuses to inject rather than executing corrupted command.

Real-World Impact:

  • FDA Recall 2019: 465,000 insulin pumps recalled due to lack of encryption authentication
  • Vulnerability: Attacker could trigger hypoglycemia (low blood sugar) by replaying old high-dose commands
  • Fix: Upgrade to AES-GCM (encryption + authentication) in firmware

Cost: GCM adds 16-byte tag per message (3% overhead) but prevents life-threatening tampering.

Verify Your Understanding:

  • Why doesn’t encryption alone prevent bit-flipping attacks? (Encryption hides content but doesn’t prove integrity—random bit changes produce random decryption, which might be valid!)
  • How is GCM different from “encrypt then HMAC”? (GCM combines both in single operation, faster and harder to misuse than manual HMAC)

20.12 Understanding Check: Diffie-Hellman Key Exchange Over Wi-Fi

Scenario: Two smart thermostats need to establish encrypted communication over home Wi-Fi network. Attacker has Wi-Fi packet capture running (can see all network traffic).

The Challenge: How can thermostats agree on shared encryption key without transmitting the key?

Diffie-Hellman Process:

Public parameters (known to attacker): g=5, p=23

Thermostat A:                        Thermostat B:
Choose secret: a=6                   Choose secret: b=15
Compute: A = 5^6 mod 23 = 8         Compute: B = 5^15 mod 23 = 19

─────────────────> Send A=8 ──────────────────>
                  (attacker sees 8)
<──────────────── Send B=19 ────────────────────
                  (attacker sees 19)

Compute shared key:                  Compute shared key:
K = 19^6 mod 23 = 2                 K = 8^15 mod 23 = 2

Both have K=2, attacker knows g=5, p=23, A=8, B=19 but cannot compute K!

Think about:

  1. Attacker knows g, p, A, B. Why can’t they compute K = 5^(6×15) mod 23 = 2?
  2. What mathematical problem makes this hard?

Key Insight: Discrete logarithm problem: Given A = g^a mod p, computing ‘a’ from A is computationally infeasible for large primes (2048-bit p). Attacker would need to solve: “What exponent ‘a’ makes 5^a mod 23 = 8?” Easy for small numbers (try all 23 values), impossible for 2048-bit primes (2^2048 possibilities).

Real-World Scale:

  • Home Wi-Fi (above): 23 is tiny, breaks in milliseconds
  • Production IoT: p = 2048-bit prime, a & b = 256-bit random → K = 2048-bit shared secret
  • Attack time: 10^600 years with all computers on Earth

Modern variant: ECDH (Elliptic Curve Diffie-Hellman) uses smaller keys (256-bit) with same security as 2048-bit DH, saving bandwidth on constrained IoT devices.

Verify Your Understanding:

  • Why do both sides arrive at the same K? (Math: A^b = (ga)b = g^(ab) = (gb)a = B^a)
  • Can attacker perform man-in-the-middle attack? (Yes! DH provides no authentication—need to combine with digital signatures or pre-shared device certificates)

20.12.1 Interactive: Diffie-Hellman Key Exchange Explorer

Experiment with different secret values to see how Diffie-Hellman works. Change the secret exponents and observe how both sides arrive at the same shared key.

20.12.2 Interactive: Brute Force Attack Timeline Calculator

Explore how key length affects brute force attack feasibility. Adjust the key size and computing power to see the impact.

20.12.3 Interactive: Encryption Energy Comparison

Compare the energy cost of software versus hardware encryption for battery-powered IoT devices over their expected lifetime.

20.13 Scenario Summary Table

Scenario Key Threat Solution Cost/Benefit
Medical IoT Compromised gateway E3 end-to-end $6.5k prevents $1.2M fine
OTA Updates Malicious firmware E3 + signatures $0.15/device prevents liability
Battery Life Power consumption E1 hardware crypto +18 months battery
Replay Attacks Reused messages Sequence numbers 4 bytes prevents $2.4B fraud
Manufacturing Key distribution RSA key exchange $0.52/device prevents recall
Brute Force Key cracking AES-128+ Computationally infeasible
Bit Flipping Message tampering AES-GCM 16 bytes prevents harm
Key Exchange Eavesdropping Diffie-Hellman Mathematical impossibility

Scenario: A hospital deploys 200 patient vital sign monitors (heart rate, blood oxygen, temperature) that transmit data through ward gateways to a cloud analytics platform. HIPAA regulations require that patient data never be visible in plaintext to gateway administrators or network operators.

Architecture Choice: E3 (Device-to-Cloud) end-to-end encryption

Implementation Steps:

  1. Key Provisioning During Manufacturing:

    For each monitor (device):
- Generate unique ECC P-256 key pair (device_private_key, device_public_key)
- Store device_private_key in secure element (ATECC608)
- Upload device_public_key to cloud HSM, indexed by device_serial_number
- Burn device_serial_number into monitor's OTP (one-time programmable) memory

  2. Session Establishment (First connection):

    Monitor → Cloud:
  - Send: device_serial_number (plaintext, used to look up public key)
  - Generate ephemeral ECDH key pair (monitor_ephemeral_key)
  - Send: monitor_ephemeral_public

Cloud → Monitor:
  - Generate ephemeral ECDH key pair (cloud_ephemeral_key)
  - Send: cloud_ephemeral_public

Both sides compute shared secret:
  - shared_secret = ECDH(monitor_ephemeral_private, cloud_ephemeral_public)
  - Derive AES-256-GCM session key: session_key = HKDF-SHA256(shared_secret)

  3. Encrypting Vitals Data (on ESP32 monitor):

    // Patient vitals payload (56 bytes)
struct PatientVitals {
  uint64_t timestamp_ms;
  char patient_id[16];       // Anonymized patient ID
  uint8_t heart_rate_bpm;
  uint8_t blood_oxygen_pct;
  float temperature_celsius;
  uint16_t sequence_number;
} vitals;

// Encrypt with AES-256-GCM
uint8_t nonce[12];
generate_random_nonce(nonce);  // Crypto-safe random

uint8_t ciphertext[56];
uint8_t auth_tag[16];

aes_gcm_encrypt(
  session_key,           // Derived from ECDH
  nonce, 12,
  (uint8_t*)&vitals, 56,
  ciphertext,
  auth_tag
);

// Transmit: nonce || ciphertext || auth_tag (total: 84 bytes)
mqtt_publish("patient/vitals/encrypted", nonce + ciphertext + auth_tag);

  4. Gateway Behavior (E3 passthrough):

    Gateway receives:  nonce (12 bytes) || ciphertext (56 bytes) || tag (16 bytes)
Gateway forwards:  Exact same 84 bytes to cloud (no decryption capability)
Gateway logs:      "Encrypted vitals forwarded, device_serial=MON-00142, size=84"

  5. Cloud Decryption:

    # Cloud receives encrypted blob from gateway
encrypted_payload = mqtt_message.payload  # 84 bytes

nonce = encrypted_payload[:12]
ciphertext = encrypted_payload[12:68]
auth_tag = encrypted_payload[68:84]

# Decrypt with session key
vitals = aes_gcm_decrypt(
  session_key,
  nonce,
  ciphertext,
  auth_tag
)

# Now cloud has plaintext vitals for analytics
patient_db.store(vitals.patient_id, vitals.heart_rate_bpm, vitals.timestamp_ms)

Security Analysis:

Attack Scenario E2 (Gateway Decrypts) E3 (End-to-End)
Gateway admin runs tcpdump Admin sees plaintext vitals Admin sees 84-byte encrypted blobs
Ransomware infects gateway Malware exfiltrates patient data Malware sees only ciphertext
Network operator eavesdrops Requires TLS to protect Ciphertext even without TLS
Gateway memory dump Plaintext vitals in RAM Only ciphertext in RAM
HIPAA Breach Notification Required (PHI exposed) NOT required (encrypted data)

Performance Measurements (ESP32 @ 240 MHz): - ECDH session key establishment: 8 ms (once per connection) - AES-256-GCM encryption per vitals packet: 1.2 ms - Transmission frequency: Every 5 seconds - CPU utilization: (1.2 ms / 5000 ms) × 100 = 0.024% - Battery impact: <0.1 mAh per day

Cost-Benefit:

  • Implementation cost: ~$0.50 per monitor (ATECC608 secure element)
  • HIPAA breach fine avoidance: $50,000 per patient record × 200 patients = $10M
  • ROI: $10M saved / ($0.50 × 200) = 100,000× return

Result: E3 encryption ensures that even if the gateway is fully compromised (ransomware, malicious admin, physical theft), patient vitals remain cryptographically protected. The 1.2 ms encryption overhead is negligible compared to the 5-second transmission interval.

Encryption Layer Comparison (E1 through E5):

Layer What It Protects Typical Technology Attack It Prevents Attack It Doesn’t Prevent When to Use
E1 (Link-layer) Wireless frames between device and AP/gateway WPA3-Enterprise, Zigbee AES-128-CCM Wi-Fi eavesdropping, rogue APs Compromised gateway sees plaintext Always use (free with WPA3)
E2 (Device-to-Gateway) Application data between device and edge gateway MQTT over TLS, CoAP over DTLS Network eavesdropping between device and gateway Gateway processes plaintext (can be compromised) Trusted gateway scenario
E3 (Device-to-Cloud) End-to-end payload encryption Device encrypts with cloud’s public key Compromised gateway, network eavesdropping Endpoint compromise (device or cloud) Untrusted intermediate nodes
E4 (Gateway-to-Cloud) Data between gateway and cloud TLS 1.3, VPN (WireGuard, IPsec) Internet eavesdropping, ISP monitoring Compromised gateway or cloud Standard cloud connection
E5 (Key Renewal) Session keys rotated periodically ECDHE with ephemeral keys, TLS session resumption Long-term key compromise, cryptanalysis Real-time attacks within key rotation window High-security, long-lived deployments

Decision Tree:

  1. Is the data regulated or safety-critical? (HIPAA, PCI-DSS, FDA-regulated medical, critical infrastructure)
    • YES → Mandatory E3 (end-to-end encryption, bypassing gateway)
    • NO → Proceed to question 2
  2. Do you trust the gateway/edge node?
    • Fully trusted (you own it, physical security, hardened OS) → E2 + E4 sufficient
    • Partially trusted (managed by partner, shared infrastructure) → E3 required
    • Untrusted (third-party ISP gateway, public Wi-Fi) → E3 required
  3. What is the deployment scale?
    • <100 devices → E2 + E4 (simplest to manage)
    • 100-10,000 devices → E2 + E4 + E5 (add key rotation)
    • >10,000 devices → E3 + E4 + E5 (per-device keys, frequent rotation)
  4. What is the device battery constraint?
    • Mains-powered → Any encryption layer acceptable
    • Battery: >1 year → E1 + E2 + E4 (hardware AES acceleration)
    • Battery: <1 year (energy harvesting) → E1 only (minimize overhead)
  5. What is the attack risk level?
    • Low (internal sensors, non-sensitive data) → E1 + E4
    • Medium (customer data, business intelligence) → E1 + E2 + E4
    • High (financial, medical, government) → E1 + E2 + E3 + E4 + E5 (defense-in-depth)

Practical Examples:

IoT Scenario Recommended Layers Rationale
Smart home temperature sensors (trusted home network) E1 (WPA3) + E4 (TLS to cloud) Gateway is homeowner’s router (trusted); E2 adds overhead without security benefit
Industrial vibration sensors (factory floor, IT-managed gateway) E1 + E2 + E4 Gateway is company-managed (semi-trusted); E2 protects factory floor wireless segment
Medical patient monitors (hospital gateways in shared facilities) E1 + E3 + E4 + E5 HIPAA compliance requires E3; hospital IT cannot access patient data; E5 for key rotation
Smart meters (utility company gateways, 15-year lifespan) E1 + E3 + E5 Utility gateways are untrusted (third-party contractors access them); long lifespan requires key rotation
Fleet vehicle trackers (cellular connection, no gateway) E4 only (DTLS to cloud) No intermediate gateway; cellular provider is untrusted but E3 not applicable (direct cloud connection)

Best Practice Summary:

  • Always use E1: Free with WPA3, blocks casual eavesdropping
  • Add E3 for sensitive data: Medical, financial, government
  • Add E5 for long deployments: >5 year lifespan requires key rotation
  • Never rely on E1 alone: Link-layer encryption is easily bypassed
Common Mistake: Assuming HTTPS/TLS Provides Complete End-to-End Protection

What Developers Assume: “My IoT devices use HTTPS to send data to the cloud, so the data is end-to-end encrypted and secure.” Many developers believe that TLS (Transport Layer Security) provides comprehensive protection from the device all the way to the cloud application.

Why This Assumption is Dangerously Wrong:

  1. TLS Terminates at Load Balancers:

    Actual data flow:
Device --[TLS]-- Load Balancer --[Plaintext]-- Web Server --[Plaintext]-- Database

TLS-encrypted segment:  Only from device to load balancer
Plaintext exposure:     Load balancer, web server, database, logs, backups

  2. TLS is Point-to-Point, Not End-to-End:

    • TLS protects: Network transmission between two endpoints (device ↔︎ load balancer)
    • TLS does NOT protect: Data at rest, data in server memory, data in logs, data in backups, data processed by cloud functions

  3. Cloud Service Intermediate Processing:

    IoT Device → [TLS] → API Gateway → [Plaintext] → Lambda Function → [Plaintext] → S3 Bucket

TLS session ends at API Gateway.
Lambda processes plaintext.
S3 stores plaintext (unless explicitly encrypted with KMS).

  4. Certificate Trust Anchors:

    • Most IoT devices trust 100+ root CAs (operating system default trust store)
    • A compromised CA can issue a fake certificate for your cloud endpoint
    • Device trusts the fake certificate, establishes TLS with attacker’s MITM proxy
    • Attacker decrypts, reads, re-encrypts, forwards to real cloud (invisible to device)

Real-World Example: In 2022, a smart home company advertised “bank-grade 256-bit encryption” because their devices used HTTPS to communicate with AWS. A security researcher discovered:

  • IoT device → TLS 1.2 → AWS ALB (Application Load Balancer)
  • ALB terminated TLS, forwarded plaintext HTTP to EC2 instances
  • EC2 instances processed data, stored in RDS database (plaintext)
  • RDS automated backups stored in S3 (plaintext)
  • CloudWatch logs captured API requests with sensor data (plaintext)
  • Attacker compromised an EC2 instance via unpatched vulnerability
  • Attacker accessed RDS database → extracted 500,000 customer homes’ sensor data (temperature, occupancy patterns, door lock states)
  • TLS provided ZERO protection once data reached the cloud

Consequences:

  • FTC investigation for “deceptive security claims”
  • $1.8M settlement
  • Mandatory 20 years of third-party security audits
  • Customer class-action lawsuit (ongoing)

Correct Approach: Application-Layer End-to-End Encryption (E3)

// On IoT Device: Encrypt BEFORE sending via HTTPS
uint8_t plaintext[] = "temperature=25.5,humidity=60%";
uint8_t ciphertext[64];
uint8_t tag[16];

// Encrypt with cloud's public key (only cloud's private key can decrypt)
aes_gcm_encrypt(
  cloud_session_key,  // Derived via ECDH with cloud's public key
  plaintext,
  ciphertext,
  tag
);

// Send encrypted payload via HTTPS
// TLS protects the ciphertext in transit
// Load balancer, web server, logs see only ciphertext
// Only cloud backend (with private key) can decrypt
https_post("https://api.cloud.com/sensor/data", ciphertext + tag);

The Correct Understanding:

Security Layer What TLS Protects What TLS Does NOT Protect
In Transit Network eavesdropping between device and TLS termination point Data after TLS termination (load balancers, app servers, databases)
At Rest Nothing Data in databases, S3 buckets, backups (needs separate encryption)
In Use Nothing Data in server memory, logs, error messages, debug dumps
Metadata Partially (SNI is plaintext) Source IP, destination IP, packet timing, message sizes

Key Takeaway: TLS/HTTPS is transport encryption, not end-to-end encryption. For true end-to-end protection: 1. Encrypt data at the APPLICATION LAYER (before HTTPS) 2. Use cloud-side key management (AWS KMS, Azure Key Vault) 3. Ensure only the final application endpoint (not intermediate load balancers/proxies) has the decryption key 4. Never assume “we use HTTPS” means “data is protected end-to-end”

The $1.8M lesson: “HTTPS” on the marketing page does not equal “encrypted end-to-end.” Application-layer encryption (E3) is required for true end-to-end protection.

Concept Relationships
Concept Builds On Enables Related To
E3 End-to-End Asymmetric key establishment HIPAA compliance, untrusted gateways Medical IoT, E2E privacy
Sequence Numbers Monotonic counters Replay attack prevention E2 freshness, smart meters
AES-GCM Authentication Authenticated encryption Tamper detection Medical device safety, insulin pumps
RSA Key Distribution Asymmetric encryption Manufacturing-scale key provisioning E5 renewal, IoT platform onboarding
Hardware AES Dedicated crypto accelerators Battery life optimization LoRaWAN, Zigbee, BLE link layer

Key Dependencies: E3 solves the untrusted gateway problem. Sequence numbers prevent replay attacks without complex synchronization. AES-GCM’s built-in authentication prevents bit-flipping attacks. RSA/ECC enables secure key distribution at manufacturing scale. Hardware acceleration makes encryption practical for battery-powered devices.

Common Pitfalls

Familiarity with a topic does not guarantee accurate understanding — especially for cryptography where subtle details matter. Complete every understanding check even on topics you feel confident about.

Understanding that ‘IV reuse breaks CTR mode’ at a conceptual level but not knowing how to prevent it in code creates a security gap. For each concept checked, identify the specific code pattern that correctly implements it.

A ‘wrong’ answer on an understanding check indicates a learning opportunity, not failure. Re-read the relevant section and the explanation before continuing.

:

20.14 What’s Next

If you want to… Read this
Complete the full quiz review Quiz & Review
Practice with encryption labs Encryption Labs
Explore interactive cryptography tools Interactive Cryptography Tools
Review the multilayer encryption architecture Multilayer Architecture Review

{#sec-enc-checks-next}

Now that you’ve worked through practical scenarios, test your comprehensive understanding with the Encryption Quiz containing multiple-choice questions covering all encryption concepts with detailed explanations.

Continue to Encryption Comprehensive Quiz →

20.15 See Also