Compare Encryption Approaches: Explain the fundamental differences between symmetric and asymmetric encryption
Select Appropriate Algorithms: Choose the right encryption type based on IoT system requirements
Apply Hybrid Encryption: Combine symmetric and asymmetric methods for optimal security and performance
Evaluate Performance Trade-offs: Balance encryption strength against computational and power constraints
In 60 Seconds
Symmetric encryption (AES-128/256) is fast and power-efficient for IoT data encryption, while asymmetric encryption (ECC/RSA) enables secure key exchange; the right choice depends on device constraints, data sensitivity, and communication patterns.
Understanding the fundamental difference between symmetric and asymmetric encryption is critical for IoT security design.
Figure 18.1: Symmetric encryption uses one shared key for both encryption and decryption, offering high speed but requiring secure key distribution. Asymmetric encryption uses a public-private key pair, solving key distribution but at significantly slower performance. IoT systems typically use hybrid approaches: asymmetric encryption for key exchange, symmetric encryption for bulk data.
18.3.1 Key Characteristics Comparison
Feature
Symmetric (AES)
Asymmetric (RSA/ECC)
Keys
Single shared key
Public + Private key pair
Speed
100-500 MB/s
10-100 KB/s
Key Size
128-256 bits
2048-4096 bits (RSA)
Primary Use
Bulk data encryption
Key exchange, signatures
Challenge
Key distribution
Computational cost
18.3.2 When to Use Each Approach
Use Symmetric Encryption (AES) when:
Encrypting large amounts of data
Processing real-time sensor streams
Working with constrained devices
Both parties already share a key
Use Asymmetric Encryption (RSA/ECC) when:
Establishing new connections
Exchanging session keys
Creating digital signatures
Authenticating device identity
18.4 IoT Encryption Selection Decision Tree
Figure 18.2: Decision tree for selecting encryption algorithms in IoT systems. Asymmetric encryption (RSA, ECC) handles key establishment while symmetric encryption (AES) provides fast bulk data encryption. Most IoT implementations use a hybrid approach.
18.5 Hybrid Encryption in Practice
Modern IoT systems combine both approaches for optimal security and performance:
1. Key Exchange Phase (Asymmetric - RSA/ECDH):
Device -> Cloud: "Here's my public key"
Cloud -> Device: AES session key encrypted with device's public key
2. Data Transfer Phase (Symmetric - AES):
Device -> Cloud: Sensor data encrypted with AES session key
Cloud -> Device: Commands encrypted with AES session key
For Beginners: Why Not Just Use One Type?
Why not always use Asymmetric (RSA)?
Too slow! RSA can only encrypt about 50 KB per second
A temperature sensor sending data every second would overwhelm the processor
Battery would drain quickly on constrained devices
Why not always use Symmetric (AES)?
The “key distribution problem” - how do you share the secret key securely?
If you send the key over the network, anyone watching can steal it!
This is like trying to send a house key through the mail
The Hybrid Solution:
Use RSA once to securely exchange the AES key
Use AES for all actual data (10,000x faster)
Like using a secure courier once to deliver a house key, then using the key forever
Putting Numbers to It
Hybrid Encryption Economics for Smart City Camera Network:
A smart city deploys 5,000 traffic cameras, each transmitting 1 GB of encrypted video per day to a central analytics server. Compare pure asymmetric encryption vs hybrid (asymmetric + symmetric) approach.
Step 1: Use RSA-2048 to encrypt a 32-byte AES session key once per hour (24 handshakes/day) \[
\text{RSA time per day} = 24 \times \frac{32 \text{ bytes}}{51{,}200 \text{ bytes/s}} = 0.015 \text{ seconds}
\]
Step 2: Use AES-256-GCM to encrypt the 1 GB video data \[
\text{AES encryption rate} = 500 \text{ MB/s}
\]
Key Insight: Hybrid encryption achieves RSA’s security for key exchange with AES’s speed for bulk data, reducing encryption time from 5.83 hours/day to 2 seconds/day per camera.
18.5.1 Hybrid Encryption Cost Explorer
Use the interactive calculator below to experiment with different fleet sizes, data volumes, and encryption rates to see how hybrid encryption compares to pure asymmetric approaches in your own IoT deployment scenarios.
Show code
viewof numCameras = Inputs.range([100,50000], {value:5000,step:100,label:"Number of cameras"})viewof dataPerDayGB = Inputs.range([0.1,10], {value:1.0,step:0.1,label:"Data per camera per day (GB)"})viewof rsaRateKBs = Inputs.range([10,200], {value:50,step:5,label:"RSA encryption rate (KB/s)"})viewof aesRateMBs = Inputs.range([100,2000], {value:500,step:50,label:"AES encryption rate (MB/s)"})viewof powerW = Inputs.range([1,10], {value:3.5,step:0.5,label:"Encryption power draw (W)"})viewof electricityCost = Inputs.range([0.05,0.40], {value:0.12,step:0.01,label:"Electricity cost ($/kWh)"})
Key Insight: AES-128 remains secure for most IoT deployments (battery-powered sensors). Use AES-256 for long-lived critical infrastructure (30+ year deployments) or regulatory requirements.
18.6.2 ECC vs RSA for Constrained Devices
Algorithm
Key Size
Security Equivalent
Handshake Time (Cortex-M4)
ECC-256
256 bits
RSA-3072
180 ms
RSA-2048
2048 bits
ECC-224
350 ms
RSA-4096
4096 bits
ECC-384
2,800 ms
Recommendation: Use ECC (Elliptic Curve Cryptography) for IoT devices. It provides equivalent security with 10x smaller keys and faster operations.
18.7 Block Cipher Modes
AES is a block cipher that encrypts 128-bit blocks. The mode determines how multiple blocks are processed:
Mode
Security
Parallelizable
Authentication
IoT Use Case
ECB
Weak
Yes
No
NEVER use
CBC
Good
Decrypt only
No
Legacy systems
CTR
Good
Yes
No
Stream data
GCM
Best
Yes
Yes
Recommended
Never Use ECB Mode
ECB (Electronic Codebook) mode encrypts each block independently. Identical plaintext blocks produce identical ciphertext blocks, revealing patterns in your data. This is a critical security flaw for IoT sensor data.
Why This Matters in IoT: Implementing mbedtls_aes_crypt_ecb() might seem attractive because it requires no initialization vector (IV), making the code shorter. However, it leaks data patterns.
Real-World Example:
// INSECURE CODE - DO NOT USEuint8_t sensorData[16]={0x22,0x22,0x22,0x22,...};// Repeated temp = 22Cmbedtls_aes_crypt_ecb(&ctx, MBEDTLS_AES_ENCRYPT, sensorData, ciphertext);// Result: If temp is 22C multiple times, ciphertext is IDENTICAL each time// Attacker sees: "Sensor sent same reading 50 times today" without decrypting
Attack Scenario: An attacker monitoring encrypted smart thermostat traffic notices the same 16-byte ciphertext block appears whenever the temperature reading is “22.5C”. They can track temperature patterns by watching for that specific ciphertext block. If the ciphertext appears 10 times between 6am-8am, the attacker knows the house was at 22.5C during that window, revealing occupancy patterns.
Correct Approach: Always use CBC, CTR, or GCM mode with a unique IV for each encryption:
// SECURE CODEuint8_t iv[16];// Generate fresh random IVesp_fill_random(iv,sizeof(iv));// ESP32 hardware RNGmbedtls_aes_crypt_cbc(&ctx, MBEDTLS_AES_ENCRYPT,16, iv, sensorData, ciphertext);// Send: [IV || ciphertext] - attacker sees no patterns even if data repeats
Energy Cost: Adding IV generation and using CBC mode adds only 2-3 microseconds and <0.1 uJ per encryption – negligible compared to the 33 uJ BLE transmission cost.
Rule of Thumb: If your encryption code has no IV parameter, you are probably using ECB mode incorrectly. The only exception is key encryption keys (KEKs) where each key is unique by definition.
18.8 Visual Reference Gallery
Visual: Symmetric Encryption Block Operations
AES symmetric encryption block cipher operations
Symmetric encryption provides efficient bulk data protection through shared secret keys, with AES achieving hardware-accelerated performance on constrained IoT devices.
Visual: Asymmetric Encryption Key Pairs
RSA public-private key pair cryptography
Asymmetric cryptography solves the key distribution problem, enabling secure communication between parties who have never exchanged secrets, fundamental to PKI and certificate-based IoT authentication.
18.9 Worked Example: Securing a Smart Agriculture Gateway
Scenario: A farm deploys 200 soil moisture sensors transmitting readings every 15 minutes to an ESP32 gateway. The gateway forwards aggregated data to AWS IoT Core over cellular. Design the encryption strategy, selecting algorithms for each link and calculating the performance impact.
Requirements:
Sensor-to-gateway: BLE 5.0, 20-byte payload per reading
Gateway-to-cloud: LTE-M cellular, MQTT over TLS
Sensor battery: CR2032 coin cell (225 mAh), 5-year target life
Gateway: Solar-powered with 2000 mAh backup battery
Decision: AES-128-CCM. Provides authenticated encryption (confidentiality + integrity) with lowest energy cost. 128-bit keys provide 10+ years of security against brute force, sufficient for soil data.
Energy impact calculation:
Per reading: 0.9 uJ encryption + 0.1 uJ key schedule = 1.0 uJ
Readings per day: 96 (every 15 min)
Daily encryption energy: 96 uJ = 0.096 mJ
Annual encryption energy: 35 mJ
Compare to BLE transmission energy per reading:
BLE TX at 0 dBm: ~10 mA for 1 ms = 33 uJ (at 3.3V)
Daily TX energy: 96 x 33 uJ = 3,168 uJ = 3.2 mJ
Encryption adds only 3% to BLE transmission energy.
Step 2: Key Distribution for 200 Sensors
Problem: AES-128-CCM requires a pre-shared key. How to securely provision 200 sensors?
Method
Setup Time (200 sensors)
Security
Key Rotation
Hard-coded key
0 (factory)
Critical risk: one compromised sensor exposes all
Impossible without firmware update
Per-device unique key
4 hours (manual)
Good: compromise isolated
Requires gateway key database
ECDH key exchange at pairing
10 min (automated)
Best: forward secrecy
Automatic on reconnection
Decision: ECDH (Elliptic Curve Diffie-Hellman) key exchange during BLE pairing. Each sensor generates an ephemeral ECC-256 key pair, derives a shared AES-128 session key with the gateway. Key exchange happens once at setup (180 ms on Cortex-M0), then AES-128-CCM for all subsequent data.
Step 3: Gateway-to-Cloud Encryption
The ESP32 gateway connects to AWS IoT Core using MQTT over TLS 1.3. Compare handshake options:
TLS Configuration
Handshake Time (ESP32)
Memory
Mutual Auth
RSA-2048 + AES-128-GCM
1,200 ms
45 KB
Yes (X.509)
ECC-256 + AES-128-GCM
480 ms
28 KB
Yes (X.509)
PSK + AES-128-GCM
50 ms
8 KB
No (shared secret)
Decision: ECC-256 + AES-128-GCM. Provides mutual authentication via X.509 certificates (required by AWS IoT Core) with 60% faster handshake than RSA and 38% less memory. PSK is fastest but AWS requires certificate-based authentication.
Step 4: End-to-End Encryption Budget
Sensor (per 15-min reading):
AES-128-CCM encrypt: 1.0 uJ
BLE transmit: 33 uJ
Total per reading: 34 uJ
Annual: 34 uJ x 96/day x 365 = 1.19 J
CR2032 capacity: 225 mAh x 3V = 2,430 J
Encryption overhead on battery: 0.05%
Gateway (per 15-min aggregation cycle):
200 x AES-128-CCM decrypt: 200 uJ
Aggregate + re-encrypt (AES-128-GCM): 15 uJ
TLS record (1 per cycle): 5 uJ
Cellular transmit (500 bytes): 180 mJ
Encryption overhead: < 0.001% of cellular TX cost
Result: The hybrid encryption strategy adds negligible energy overhead (0.05% for sensors, <0.001% for gateway) while providing authenticated encryption on both links. AES-128-CCM at the sensor layer and TLS 1.3 with ECC-256 at the cloud layer deliver defense-in-depth without compromising the 5-year battery target.
Key lesson: For constrained IoT devices, encryption energy is typically 100-1000x smaller than radio transmission energy. The real cost is not encryption itself but key management complexity. Using ECDH for automated key exchange eliminates the manual provisioning burden of 200 sensors while providing forward secrecy.
Decision Framework: Choosing Between AES-128 and AES-256
Decision Context: When selecting AES key length for IoT deployments, balance security strength against performance, energy, and operational lifetime.
Factor
AES-128
AES-256
Security Strength
2^128 operations to brute force
2^256 operations to brute force
Quantum Resistance
2^64 quantum (Grover’s algorithm)
2^128 quantum (still secure)
Performance
10 rounds, ~20% faster
14 rounds, baseline
Energy per Encryption
~15% less energy
Baseline
Key Size
128 bits (16 bytes)
256 bits (32 bytes)
Compliance
NIST-approved, sufficient for most
Required for TOP SECRET
Deployment Lifetime Protection
Secure for 10-15 years
Secure for 30+ years
Use AES-128 when:
Battery-powered sensors with 5-10 year target life
Data sensitivity is moderate (commercial IoT, non-critical infrastructure)
Performance/energy optimization is critical (millions of packets per day)
Devices have no quantum threat exposure window (data obsoletes quickly)
Use AES-256 when:
Critical infrastructure with 30+ year deployment lifetime
High-value data (financial transactions, medical records, classified information)
Regulatory requirements mandate it (e.g., NSA Suite B for TOP SECRET)
Future quantum computer threat is relevant (long-lived secrets like root keys)
Performance difference is negligible (mains-powered gateways, cloud servers)
Example Decision: A smart meter deployment with 20-year lifetime storing cumulative energy usage (financially sensitive, long-lived data) should use AES-256. The meter readings are transmitted once per hour, so the 20% performance penalty is negligible compared to the extended security assurance.
Concept Relationships
Concept
Builds On
Enables
Related To
Symmetric Encryption
Shared secret keys, AES
Fast bulk data encryption
AES-GCM modes, session keys
Asymmetric Encryption
Public/private key pairs
Secure key exchange, signatures
RSA, ECC, Diffie-Hellman
Hybrid Approach
Symmetric + asymmetric
Real-world IoT security
TLS handshake, MQTT over TLS
ECC (Elliptic Curve)
Discrete logarithm problem
Small keys with RSA-equivalent security
ECDH, Ed25519, Curve25519
Block Cipher Modes
AES block operations
Prevent pattern leakage
ECB (insecure), CBC, CTR, GCM
Key Dependencies: Asymmetric encryption solves the key distribution problem for symmetric encryption. Hybrid approach uses asymmetric once (handshake) then symmetric for all data (performance). ECC provides asymmetric security with 10x smaller keys than RSA - critical for IoT.
Common Pitfalls
1. Treating Encryption as a Binary Property
Encryption is not simply ‘on’ or ‘off’ — the strength depends on algorithm choice, key size, mode of operation, and implementation quality. A system using DES is ‘encrypted’ but trivially broken.
2. Not Understanding the Difference Between Confidentiality and Integrity
Encryption alone provides confidentiality (no one can read it) but not integrity (no one can modify it undetected). Encrypting without authenticating leaves data vulnerable to bit-flipping and injection attacks. Use authenticated encryption.
3. Relying on Review Materials Instead of Implementation Practice
Understanding cryptographic concepts at review level is necessary but not sufficient — correct implementation requires hands-on experience with real APIs and error handling. Supplement review with the accompanying labs.
Now that you understand the fundamental encryption approaches, continue to Multi-Layer Encryption Architecture where you’ll learn about the five-layer E1-E5 encryption model, implementing defense-in-depth security from device to cloud, and hands-on lab exercises for building complete encryption stacks.
