1445 Encryption Review: Comprehensive Quiz
1445.1 Learning Objectives
By the end of this chapter, you will be able to:
- Demonstrate Mastery: Test comprehensive understanding of IoT encryption concepts
- Apply Knowledge: Answer scenario-based questions about encryption implementation
- Identify Best Practices: Recognize correct and incorrect encryption approaches
- Explain Trade-offs: Articulate why certain encryption choices are preferred
1445.2 Prerequisites
Required Chapters: - Encryption Fundamentals Review - Symmetric vs asymmetric - Multi-Layer Architecture - E1-E5 layers - Understanding Checks - Scenario-based exercises
Estimated Time: 25 minutes
1445.3 Quiz Instructions
This comprehensive quiz tests your understanding of IoT encryption concepts. Each question includes a detailed explanation to reinforce learning.
Topics Covered: - Symmetric vs asymmetric encryption selection - Multi-layer encryption architecture (E1-E5) - Key management and distribution - Authentication and integrity protection - Forward secrecy and key rotation - Block cipher modes - Hardware security modules - Random number generation
This chapter connects to multiple learning resources:
Quiz Practice: - Quiz Navigator - Test your encryption knowledge with interactive quizzes on AES modes, RSA key exchange, and Diffie-Hellman
Knowledge Gaps: - Knowledge Gaps - Common encryption misconceptions include “longer keys are always better” (AES-256 vs AES-128 quantum resistance), “encryption alone prevents tampering” (need authenticated encryption like GCM), and “shared keys scale well” (per-device keys essential)
Video Resources: - Video Hub - Visual explanations of symmetric vs asymmetric encryption, TLS handshakes, and cryptographic pitfalls
Simulations: - Simulation Hub - Hands-on tools for visualizing encryption modes (ECB vs CBC vs GCM), key exchange protocols (Diffie-Hellman), and multi-layer E1-E5 architecture
1445.4 Quiz: Comprehensive Encryption Review
Question 1: Your wireless sensor network uses E1 (link-layer) encryption with a shared AES-128 key across all 50 devices. An attacker steals one sensor and extracts its key. What is the immediate security impact?
Explanation: E1 uses a single shared key for all devices at the link layer. Compromising any single device exposes the shared key, allowing the attacker to decrypt communications between all devices on the network. This is why E1 alone is insufficient—you must layer E2 (device-specific keys) on top. With E2, even if the link layer is compromised, each device’s application-layer data remains encrypted with unique keys. Defense-in-depth: Never rely on a single encryption layer, especially with shared keys. Real-world: Zigbee networks suffered from this vulnerability when the default trust center link key was publicly known.
Question 2: A smart home gateway receives encrypted sensor data using E2 (AES-256), processes it, and forwards aggregated results to the cloud using E4 (TLS). An attacker compromises the gateway. Which data can the attacker access?
Explanation: The gateway must decrypt E2 sensor data to process/aggregate it, then re-encrypts with E4 for cloud transmission. A compromised gateway has access to plaintext data during processing. This is the fundamental tension: gateways need plaintext access to perform their function (aggregation, filtering, protocol translation), creating a trust boundary. Solutions: 1) Use E3 (device-to-cloud direct encryption) bypassing gateway entirely, 2) Implement Trusted Execution Environments (TEE) like ARM TrustZone in gateway, 3) Minimize data exposure with federated learning or homomorphic encryption where processing happens on encrypted data. Real-world: This is why end-to-end encryption (E3) is critical for sensitive IoT applications—medical devices, financial IoT, etc.
Question 3: Your IoT deployment needs to encrypt 1 GB of sensor data daily. Security audit recommends either RSA-2048 for all encryption or AES-256 with RSA-2048 for key exchange. Which approach is better and why?
Explanation: Hybrid encryption combines strengths of both: RSA (asymmetric) solves key distribution securely but is ~1000x slower than AES. AES (symmetric) encrypts bulk data efficiently but requires secure key sharing. Solution: Use RSA to encrypt and transmit a random AES session key, then use that AES key for actual data encryption. Performance: RSA-2048 encrypts ~50 KB/s, AES-256 encrypts ~500 MB/s on typical hardware. For 1 GB daily, RSA would take ~5.5 hours vs AES taking ~2 seconds! Real-world: This is exactly how TLS/SSL works: RSA/ECDH for handshake, AES-GCM for application data. All modern systems use hybrid approach. Diffie-Hellman is for key exchange only, not data encryption.
Question 4: An IoT manufacturer embeds the same AES encryption key in 10,000 smart thermostats during manufacturing. An attacker extracts the key from one device. What security principle was violated?
Explanation: Per-device unique keys are fundamental to IoT security. With a global key, compromising one device exposes all 10,000 devices—attacker can decrypt their communications, spoof commands, and potentially compromise entire deployment. Best practice: Each device receives a unique key during manufacturing or initial provisioning, stored in secure storage (ideally Hardware Security Module). If one device is compromised, damage is contained to that device. Key management: Modern IoT platforms (AWS IoT Core, Azure IoT Hub) enforce unique device certificates/keys. Blast radius: Global key = 100% compromise risk. Per-device keys = 0.01% compromise risk (1/10,000). Key rotation helps but doesn’t fix the architectural flaw. AES-512 doesn’t exist (AES supports 128/192/256-bit keys). ECB mode is cryptographically broken.
Question 5: Your IoT system uses AES-128 in ECB mode. Two temperature sensors send identical readings (22.5°C). An attacker observing encrypted traffic notices identical ciphertext blocks. What vulnerability does this reveal?
Explanation: ECB (Electronic Codebook) mode is fundamentally insecure because it encrypts each block independently—same plaintext always produces same ciphertext. Attackers can: 1) Recognize repeated data patterns, 2) Replay encrypted blocks without decryption, 3) Rearrange blocks to alter messages. Famous example: ECB-encrypted images still show outlines because repeated pixel colors produce repeated ciphertext. Solution: Use CBC, CTR, or GCM modes which add randomness (IV) making each encryption unique even for identical inputs. IoT context: Temperature readings, commands, status codes often repeat—ECB mode leaks this information pattern. AES-128 length is sufficient; the problem is ECB mode’s lack of diffusion between blocks. Recommendation: Always use CBC or GCM mode, never ECB except for key encryption where each key block is unique.
Question 6: A medical IoT device needs to prove that Dr. Smith authorized changing a patient’s medication dosage. Which cryptographic technique provides non-repudiation (undeniable proof of action)?
Explanation: Digital signatures with asymmetric cryptography provide non-repudiation. Dr. Smith signs the authorization with their private key (only they possess). Anyone can verify the signature with Dr. Smith’s public key, proving: 1) Dr. Smith authorized it (authentication), 2) The message wasn’t altered (integrity), 3) Dr. Smith cannot deny signing it (non-repudiation—only their private key could have created that signature). AES symmetric encryption doesn’t prove who encrypted it (shared key). SHA-256 hash verifies integrity but not authorship. Password authentication proves identity during login but not for specific actions. HIPAA compliance: Medical records require digital signatures for auditing who accessed/modified patient data. Technical: Sign hash of message (not entire message) for efficiency: signature = RSA_sign(SHA256(message), private_key).
Question 7: Two IoT devices need to establish a shared encryption key over an insecure channel (Wi-Fi network). An attacker can observe all transmitted data. Which protocol allows them to derive a shared secret without transmitting the secret itself?
Explanation: Diffie-Hellman solves this elegantly through discrete logarithm problem: 1) Alice computes A = g^a mod p, sends A publicly, 2) Bob computes B = g^b mod p, sends B publicly, 3) Alice computes shared secret K = B^a mod p = g^(ab) mod p, 4) Bob computes K = A^b mod p = g^(ab) mod p. Both derive the same secret K, but an eavesdropper knowing g, p, A, B cannot feasibly compute g^(ab) mod p. Security: Based on discrete logarithm hardness—computing a from g^a mod p is computationally infeasible. Modern variant: ECDH (Elliptic Curve Diffie-Hellman) provides same security with smaller keys. AES pre-shared key requires prior secure channel. HTTPS already uses Diffie-Hellman internally! QR codes work but require physical proximity and out-of-band channel.
Question 8: Your IoT system implements forward secrecy. An attacker records 6 months of encrypted traffic, then compromises the server’s long-term RSA private key. What can the attacker decrypt?
Explanation: Forward secrecy (aka Perfect Forward Secrecy, PFS) ensures past sessions remain secure even if long-term keys are compromised. Implementation: Each session generates ephemeral key pairs for Diffie-Hellman key exchange. Session keys are derived from these ephemeral keys and destroyed after use. The long-term RSA key only signs the exchange (proves identity), it doesn’t encrypt session keys. Without PFS: Attacker with long-term key decrypts RSA-encrypted session keys → decrypts all past traffic. With PFS: Ephemeral keys are destroyed, long-term key compromise can’t reconstruct them. IoT benefit: If a device is stolen months later, past communications remain protected. TLS 1.3 requires PFS. Configure IoT systems with ECDHE (Ephemeral Elliptic Curve Diffie-Hellman) cipher suites like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
Question 9: An IoT gateway uses E5 (key renewal) to rotate encryption keys every 24 hours. What is the primary security benefit of periodic key rotation?
Explanation: Key rotation provides multiple security benefits: 1) Limited exposure window: If a key is compromised, attacker only accesses data encrypted with that key (24 hours, not entire deployment lifetime), 2) Reduced cryptanalysis data: Less ciphertext per key makes statistical analysis harder, 3) Forward secrecy: Past keys are destroyed, compromising current key doesn’t expose past data, 4) Breach containment: Limits damage from undetected compromise. Trade-off: Rotation overhead vs security benefit. Daily rotation is common for high-security IoT. Implementation: E5 layer uses asymmetric encryption (RSA) to securely distribute new symmetric keys. Keys don’t make encryption faster (same algorithm). Not all regulations mandate daily rotation. Hardware failures are unrelated to key age. Recommendation: Rotate based on sensitivity—critical systems daily, low-risk systems monthly/quarterly.
Question 10: Your IoT deployment stores encryption keys in three options: A) Plain text file on device, B) Encrypted file with master key, C) Hardware Security Module (HSM). An attacker gains physical access to devices. Rank security from worst to best.
Explanation: A) Plaintext: Trivially extracted with flash memory read—zero security. B) Encrypted file: Attacker must find master key (often hardcoded in firmware or stored nearby), but reverse engineering firmware usually reveals it—marginally better but still vulnerable. C) HSM (Secure Element/TPM): Keys generated and stored in tamper-resistant hardware, never exported. Cryptographic operations happen inside chip. Physical attacks trigger self-destruct. Massive security difference: HSM provides orders of magnitude better protection. Real-world: Payment terminals use HSMs because regulatory requirements recognize A/B as effectively unprotected. IoT options: ATECC608 ($0.50), TPM 2.0, ARM TrustZone. Cost: HSM adds minimal cost but provides real security. Encrypted files create false sense of security—master key problem is recursive (where do you store the key that encrypts the keys?).
Question 11: A smart city deploys 1,000 IoT traffic sensors. During rush hour, sensors send encrypted data every 5 seconds. Which encryption mode provides authenticated encryption with parallelizable decryption for the cloud server?
Explanation: GCM (Galois/Counter Mode) is optimal for high-throughput IoT cloud processing: 1) Authenticated Encryption: Combines encryption with GMAC authentication—detects tampering without separate HMAC, 2) Parallelizable: Counter mode allows independent block processing—cloud can decrypt 1,000 sensors simultaneously using multiple CPU cores, 3) Performance: ~10x faster than CBC on modern CPUs with AES-NI instructions, 4) No padding: Works with any data length. CBC requires sequential decryption (blocks depend on previous blocks—slow). ECB is cryptographically broken. OFB lacks authentication. Real-world: TLS 1.3 mandates GCM. AWS IoT Core, Azure IoT Hub recommend AES-GCM. IoT benefit: Rush hour = 1,000 sensors × 12 messages/minute = 12,000 msgs/min. GCM’s parallelization keeps latency low during traffic bursts.
Question 12: An IoT device generates encryption keys using rand() seeded with srand(time(NULL)) in C. An attacker observes the device was powered on at 2024-10-26 14:30:00 UTC. What is the vulnerability?
Explanation: Catastrophic failure: rand() is a pseudo-random number generator (PRNG), not cryptographically secure. With known seed (timestamp), attacker can run identical code to generate the exact same “random” keys. time(NULL) has 1-second granularity—attacker can try at most 86,400 seeds (24 hours) to find the key. Attack: Power on device at known time → predict seed → regenerate keys → decrypt all traffic. Correct approach: Use Cryptographically Secure PRNG (CSPRNG): /dev/urandom (Linux), CryptGenRandom() (Windows), esp_random() (ESP32), Hardware RNG (ATECC608). These use entropy from hardware noise (thermal, electrical) making prediction impossible. Real vulnerability: Mirai botnet exploited devices with predictable random number generation. IoT critical: Many devices boot at predictable times (power outage recovery, scheduled updates)—never use rand() for cryptography!
Question 13: Your IoT system needs end-to-end encryption from device sensors to cloud analytics, bypassing the gateway entirely. The gateway should only route packets without accessing plaintext. Which encryption architecture achieves this?
Explanation: E3 (Device-to-Cloud direct encryption) implements true end-to-end encryption: 1) Device encrypts data with cloud’s public key or shared symmetric key established via direct handshake, 2) Gateway routes encrypted packets as opaque blobs without decryption capability, 3) Only cloud possesses decryption key. E2 fails: Gateway must decrypt to forward, creating trust boundary. E1 + E4 fails: Gateway sees plaintext between E1 decryption and E4 encryption. E5: Key renewal doesn’t change gateway’s access to plaintext. Trade-offs: E3 prevents gateway processing (aggregation, filtering). Use cases: Medical IoT (HIPAA), financial transactions, sensitive surveillance. Implementation: DTLS or TLS tunnel from device directly to cloud. Gateway acts as IP router only. Limitation: Requires devices with sufficient CPU/memory for TLS handshake. Resource-constrained devices may need E2 with trusted gateway.
1445.5 Quiz Score Interpretation
| Score | Interpretation | Recommended Action |
|---|---|---|
| 12-13 | Expert - Comprehensive understanding | Ready for advanced security implementation |
| 9-11 | Proficient - Strong foundation | Review explanations for missed questions |
| 6-8 | Developing - Gaps in knowledge | Re-read Multi-Layer Architecture chapter |
| 0-5 | Foundational - More study needed | Start with Encryption Fundamentals Review |
1445.6 Summary
This comprehensive quiz covered the essential IoT encryption concepts:
Key Themes Tested: - Shared vs Per-Device Keys: Global keys create catastrophic single points of failure - Gateway Trust Boundaries: E2 exposes data during processing; use E3 for sensitive data - Hybrid Encryption: RSA for key exchange, AES for bulk data - Block Cipher Modes: GCM for authenticated, parallelizable encryption; never ECB - Key Storage: HSMs provide dramatically better security than software storage - Random Number Generation: Use CSPRNG, never rand() with predictable seeds - Forward Secrecy: Ephemeral keys protect past communications
- E1-E5 Architecture: Five layers of defense-in-depth encryption
- Per-Device Keys: Essential for containing breaches
- AES-GCM: Authenticated encryption with integrity protection
- Digital Signatures: Non-repudiation via asymmetric cryptography
- Diffie-Hellman: Secure key exchange without transmitting secrets
- Hardware Security Modules: Tamper-resistant key storage
1445.7 Videos
1445.8 What’s Next
With encryption concepts mastered, the next chapter explores Safeguards and Protection where you’ll learn comprehensive security frameworks including NIST Cybersecurity Framework’s five functions, implement the Information Assurance Cube covering security services across data states, establish security policies for passwords and data classification, deploy hardware security including OTP memory and code signing, and configure wireless security with WPA3 and Bluetooth Secure Simple Pairing.
Continue to Safeguards and Protection →
1445.9 See Also
Related Topics:
- IoT Devices and Network Security: Broader security framework including physical security, firmware protection, and network segmentation that complements encryption for comprehensive IoT device protection
- Threat Modeling and Mitigation: Systematic approach to identifying threats that encryption addresses, helping prioritize security investments and choose appropriate encryption strength
- Secure Data and Software: Application-layer security practices including secure coding, data validation, and software updates that work alongside encryption for defense-in-depth
Further Reading:
- MQTT Protocol Security: Implementing TLS/SSL for MQTT connections, understanding how E4 encryption secures publish-subscribe messaging in IoT applications
- CoAP Security with DTLS: Applying Datagram TLS to UDP-based CoAP protocol, relevant for E2 and E3 encryption layers in constrained device scenarios
- Privacy by Design: Architectural approaches that leverage encryption for data minimization, purpose limitation, and user control over personal information
1445.10 Academic Resources
Source: University of Edinburgh - IoT Systems Security Course
Key Exchange Process: 1. ANonce/SNonce Exchange: Both sides contribute random nonces for freshness 2. PTK Derivation: Both calculate same key from nonces + PMK without transmitting it 3. MIC Verification: Message Integrity Code confirms successful key agreement 4. GTK Distribution: Group Temporal Key encrypted with PTK for broadcast traffic
1445.11 Standards References
- NIST FIPS 197: Advanced Encryption Standard (AES)
- RFC 5246: The Transport Layer Security (TLS) Protocol
- RFC 3526: More Modular Exponential (MODP) Diffie-Hellman groups
- NIST SP 800-57: Recommendation for Key Management
- RFC 7539: ChaCha20 and Poly1305 for IETF Protocols