3  Encryption Principles & Basics

3.1 Overview

This comprehensive guide covers cryptographic fundamentals for IoT security. The content has been organized into focused chapters for easier learning and reference.

Minimum Viable Understanding (MVU)

What is encryption? Encryption scrambles your data so only authorized people can read it. Even if someone intercepts your message, they see gibberish without the key.

The 3 Types You Need to Know:

1. Symmetric (AES): One shared secret key for both encryption and decryption - fast, used for bulk data
2. Asymmetric (RSA/ECC): Two keys (public/private) - slower, used for key exchange and signatures
3. Hashing (SHA-256): One-way function for integrity verification - cannot be reversed

IoT Reality: Most IoT devices use a hybrid approach - asymmetric encryption to securely exchange a symmetric key, then symmetric encryption for fast data transfer. This is exactly how TLS/DTLS works.

Key Takeaway: For battery-powered IoT devices, prefer AES-128-GCM for data encryption and ECC (not RSA) for key exchange because ECC provides the same security with 10x smaller keys and less computation.

Sensor Squad: Secret Codes for Smart Devices!

Hey kids! Let’s learn about encryption with the Sensor Squad!

Sammy the Sensor says: “Imagine you and your best friend have a secret language that only you two understand. When you pass notes in class, even if someone else reads the note, they just see nonsense! That’s exactly what encryption does for smart devices!”

Lila the Light Sensor explains: “When your smart thermostat tells the cloud what temperature your room is, it uses a secret code. Even if a bad guy intercepts the message, they can’t understand it!”

Max the Motion Detector adds: “There are two main types of secret codes:

1. Symmetric - Like when you and your friend both have the same decoder ring
2. Asymmetric - Like a special mailbox where anyone can drop in mail, but only you have the key to open it!”

Bella the Button shares: “The best part? Smart devices use BOTH types together! They use the special mailbox to safely share their decoder ring, then use the decoder ring for all their secret messages. Super clever!”

Try this at home: Write a message using a simple code (like shifting each letter by 3 - A becomes D, B becomes E). That’s a basic encryption! Now imagine computers doing this millions of times per second with super complex codes!

3.2 Learning Objectives

By completing this chapter series, you will be able to:

• Explain Cryptographic Fundamentals: Describe the purpose and mechanics of encryption for IoT security
• Compare Algorithm Types: Distinguish between symmetric (AES) and asymmetric (RSA, ECC) encryption and their use cases
• Apply Hashing Functions: Use cryptographic hashes (SHA-256) for data integrity and password storage
• Implement Key Management: Design secure key generation, distribution, and rotation strategies
• Select IoT-Appropriate Crypto: Choose lightweight cryptographic solutions for resource-constrained devices
• Explain TLS/DTLS: Describe how transport security protocols protect IoT communications

In 60 Seconds

IoT encryption uses symmetric algorithms (AES) for fast data protection and asymmetric algorithms (RSA/ECC) for secure key exchange; TLS/DTLS builds on these foundations to secure device-to-cloud communications with authentication and confidentiality.

3.3 For Beginners: Encryption Principles & Basics

Cryptography for IoT is the science of keeping sensor data and device commands secret and tamper-proof. Think of it as the digital equivalent of secret codes, locked boxes, and wax seals. Even if someone intercepts your IoT data traveling through the air, cryptography ensures they cannot read or alter it without the proper keys.

How It Works: IoT Cryptography Stack

IoT cryptography operates in layers from mathematical primitives to complete protocols:

1. Primitive Selection: Choose symmetric (AES) for bulk data, asymmetric (ECC/RSA) for key exchange, hash functions (SHA-256) for integrity
2. Mode Configuration: Configure AES in GCM or CCM mode for authenticated encryption (confidentiality + integrity in one operation)
3. Key Establishment: Use asymmetric cryptography (ECDH) to securely exchange symmetric session keys over untrusted networks
4. Session Encryption: Encrypt application data with fast symmetric AES using the established session key
5. Integrity Verification: Authentication tags (GCM/CCM) or HMACs detect tampering
6. Key Rotation: Periodically renew session keys to limit exposure window if keys are compromised

This hybrid approach combines the security benefits of asymmetric cryptography (no pre-shared secrets needed) with the performance of symmetric encryption (1000x faster for bulk data).

3.4 Chapter Guide

This topic is divided into focused chapters. Start with the fundamentals or jump to specific topics:

3.4.1 Core Concepts

Chapter	Focus	Difficulty
Symmetric Encryption	AES, block ciphers, modes of operation	Intermediate
Asymmetric Encryption	RSA, Diffie-Hellman, digital signatures	Intermediate
Elliptic Curve Cryptography	ECC for IoT, Curve25519, Ed25519	Advanced
Hash Functions	SHA-256, HMAC, data integrity	Intermediate

3.4.2 Applied Security

Chapter	Focus	Difficulty
TLS/DTLS Transport Security	Secure connections, certificates, handshakes	Intermediate
Key Management	Key lifecycle, storage, rotation	Intermediate

3.4.3 Hands-On Learning

Chapter	Focus	Difficulty
Interactive Tools	Calculators, comparisons, decision aids	Beginner
Encryption Labs	Wokwi ESP32 simulations, exercises	Intermediate
Cipher Challenge Game	Interactive puzzles, knowledge testing	Beginner

Interactive: Symmetric vs Asymmetric Encryption

3.5 Quick Reference

3.5.1 Encryption Type Selection

The following diagram illustrates how different cryptographic primitives work together in a layered IoT security stack:

Figure 3.1: IoT Cryptographic Primitives and Their Relationships

3.5.2 IoT Encryption Recommendations

Use Case	Symmetric	Asymmetric	Hash / KDF
Sensor data encryption	AES-128-GCM	-	-
Key exchange	-	ECC-256	-
Firmware signing	-	Ed25519	SHA-256
Password storage	-	-	Argon2 (KDF)
TLS connections	AES-128-GCM	ECDHE	SHA-256

3.5.3 Key Size Comparison

Security Level	AES	RSA	ECC
128-bit	128 bits	3,072 bits	256 bits
192-bit	192 bits	7,680 bits	384 bits
256-bit	256 bits	15,360 bits	521 bits

Takeaway: ECC provides RSA-equivalent security with 10-30x smaller keys – ideal for IoT.

viewof selectedSecurity = Inputs.select(
  ["128-bit", "192-bit", "256-bit"],
  {value: "128-bit", label: "Select Security Level"}
)

keySizeData = {
  const data = {
    "128-bit": {aes: 128, rsa: 3072, ecc: 256},
    "192-bit": {aes: 192, rsa: 7680, ecc: 384},
    "256-bit": {aes: 256, rsa: 15360, ecc: 521}
  };
  const d = data[selectedSecurity];
  const rsaToEccRatio = (d.rsa / d.ecc).toFixed(0);
  const rsaToAesRatio = (d.rsa / d.aes).toFixed(0);
  return {...d, rsaToEccRatio, rsaToAesRatio, level: selectedSecurity};
}

html`<div style="border-left: 4px solid #3498DB; padding: 0.8em 1em; margin: 1em 0; background: #f8f9fa; border-radius: 0 4px 4px 0;">
<strong>Key Size Comparison at ${keySizeData.level} Security</strong><br/>
<table style="width:100%; margin-top: 0.5em; border-collapse: collapse;">
<tr style="border-bottom: 2px solid #dee2e6;">
  <th style="text-align:left; padding: 4px 8px;">Algorithm</th>
  <th style="text-align:right; padding: 4px 8px;">Key Size</th>
  <th style="text-align:right; padding: 4px 8px;">vs RSA</th>
</tr>
<tr style="background: #e8f8f5;">
  <td style="padding: 4px 8px;"><strong>AES</strong> (symmetric)</td>
  <td style="text-align:right; padding: 4px 8px;">${keySizeData.aes} bits</td>
  <td style="text-align:right; padding: 4px 8px;">${keySizeData.rsaToAesRatio}x smaller</td>
</tr>
<tr>
  <td style="padding: 4px 8px;"><strong>RSA</strong> (asymmetric)</td>
  <td style="text-align:right; padding: 4px 8px;">${keySizeData.rsa.toLocaleString()} bits</td>
  <td style="text-align:right; padding: 4px 8px;">baseline</td>
</tr>
<tr style="background: #e8f8f5;">
  <td style="padding: 4px 8px;"><strong>ECC</strong> (asymmetric)</td>
  <td style="text-align:right; padding: 4px 8px;">${keySizeData.ecc} bits</td>
  <td style="text-align:right; padding: 4px 8px;">${keySizeData.rsaToEccRatio}x smaller</td>
</tr>
</table>
<p style="margin: 0.5em 0 0; font-size: 0.9em; color: #555;">
<strong>IoT Impact</strong>: At ${keySizeData.level} security, an ECC key is <strong>${keySizeData.rsaToEccRatio}x smaller</strong> than RSA -- saving RAM, bandwidth, and battery on constrained devices.
</p>
</div>`

3.6 Prerequisites

Before diving into these chapters, you should be familiar with:

• Security and Privacy Overview: Fundamental security concepts and threat models
• Networking Basics: Network communication protocols
• IoT Reference Models: IoT system architecture

3.7 Related Resources

Security Context:

• Cyber Security Methods - Defense techniques
• Threat Modelling - Risk assessment
• IoT Device Security - Implementation

Protocol Security:

• MQTT - TLS for pub/sub
• CoAP - DTLS for constrained devices
• Bluetooth Security - Pairing and encryption

Learning Hubs:

• Quiz Navigator - Security quizzes

3.8 Getting Started

New to cryptography? Start with:

1. Interactive Tools - Build intuition with calculators
2. Symmetric Encryption - Learn AES fundamentals
3. Cipher Challenge Game - Test your knowledge

Building IoT devices? Focus on:

1. Symmetric Encryption - AES-GCM for data
2. ECC - Small keys for constrained devices
3. TLS/DTLS - Secure connections
4. Key Management - Proper key handling

Hands-on learner? Jump to:

1. Encryption Labs - ESP32 simulations
2. Cipher Challenge Game - Interactive puzzles

3.9 Knowledge Check

Test your understanding before exploring the detailed chapters:

Question 1: Encryption Selection

Your IoT gateway receives 1 MB of sensor data per minute from 50 devices and needs to encrypt all data before sending to the cloud. Which encryption approach is most appropriate?

Options:

• 1. RSA-2048 for all data because it’s more secure
• 2. AES-128-GCM for bulk data, with ECDH for the initial key exchange
• 3. SHA-256 hash of all data for integrity
• 4. No encryption needed if using HTTPS

Answer

Correct: B) AES-128-GCM for bulk data, with ECDH for the initial key exchange

This is the hybrid encryption approach used in real-world systems like TLS:

• Why not A? RSA is computationally expensive - encrypting 1 MB directly with RSA would take seconds to minutes, not practical for real-time data
• Why not C? SHA-256 provides integrity but not confidentiality - data would still be readable by anyone who intercepts it
• Why not D? HTTPS does use this hybrid approach internally, but assuming you don’t need encryption because of HTTPS misses the point - you still need to understand what HTTPS is doing

Key insight: The hybrid approach (asymmetric for key exchange, symmetric for data) combines the security benefits of public-key cryptography with the speed of symmetric ciphers. AES-128-GCM specifically provides both encryption AND authentication in a single operation.

Question 2: Key Size Trade-offs

A medical device manufacturer asks whether to use AES-128 or AES-256 for their insulin pump. What’s the key consideration?

Options:

• 1. AES-128 is sufficient because no one has ever broken it
• 2. AES-256 should be used for critical medical devices despite higher power consumption
• 3. Neither - use RSA for maximum security
• 4. Key size doesn’t matter if keys are properly managed

Answer

Correct: B) AES-256 should be used for critical medical devices despite higher power consumption

For life-critical medical devices:

• Device lifetime: Insulin pumps are deployed for 10+ years - must remain secure throughout
• Quantum resistance: AES-256 offers better protection against future quantum computing attacks (Grover’s algorithm halves the effective security, reducing AES-256 to 128-bit equivalent)
• Regulatory requirements: Medical devices often mandate higher security margins
• Power trade-off: ~40% more computation is acceptable for critical systems

Why other options are wrong:

• A is partially true but misses the defense-in-depth principle for critical systems
• C is wrong because RSA is for key exchange/signatures, not bulk data encryption
• D is misleading - while key management is crucial, key size does matter for long-lived devices

Question 3: Understanding Hash Functions

A firmware update is 5 MB. The manufacturer publishes a SHA-256 hash of the firmware. What does verifying this hash prove?

Options:

• 1. The firmware is encrypted and cannot be read by attackers
• 2. The firmware came from the authentic manufacturer
• 3. The firmware has not been modified since the hash was computed
• 4. The firmware is free from security vulnerabilities

Answer

Correct: C) The firmware has not been modified since the hash was computed

Hash functions provide integrity verification only:

• Avalanche effect: Changing even 1 bit produces a completely different hash
• Deterministic: Same input always produces same hash
• One-way: Cannot reverse a hash to get the original data

What hashes do NOT provide:

• Not encryption (A): The firmware file is still fully readable - hash just verifies it
• Not authentication (B): Anyone can compute a hash - you need a digital signature (hash encrypted with private key) to prove origin
• Not security audit (D): Hash says nothing about code quality or vulnerabilities

For true firmware authenticity: Manufacturer should sign the hash with their private key using Ed25519 or ECDSA.

Question 4: ECC vs RSA for IoT

Why is Elliptic Curve Cryptography (ECC) preferred over RSA for resource-constrained IoT devices?

Options:

• 1. ECC is newer and therefore more secure than RSA
• 2. ECC provides equivalent security with 10-30x smaller keys, reducing computation and bandwidth
• 3. RSA cannot be used on microcontrollers at all
• 4. ECC is faster because it uses simpler mathematical operations

Answer

Correct: B) ECC provides equivalent security with 10-30x smaller keys, reducing computation and bandwidth

Key size comparison for equivalent security:

Security Level	RSA Key Size	ECC Key Size	Ratio
128-bit	3,072 bits	256 bits	12x
192-bit	7,680 bits	384 bits	20x
256-bit	15,360 bits	521 bits	30x

Why this matters for IoT:

• Memory: Smaller keys = less RAM needed for crypto operations
• Bandwidth: Certificates and handshakes use less data over limited networks
• Power: Fewer CPU cycles = longer battery life
• Speed: Key operations are faster (though not because operations are “simpler” - D is wrong)

Why other options are incorrect:

• A: Age doesn’t determine security - both are well-studied
• C: RSA can run on MCUs, just less efficiently
• D: ECC math (elliptic curves) isn’t simpler - efficiency comes from smaller numbers

Question 5: TLS vs DTLS for IoT

Your IoT device communicates over UDP because TCP’s overhead is too high. Which protocol should you use to secure the connection?

Options:

• 1. TLS 1.3 - it works over any transport protocol
• 2. DTLS 1.2 or 1.3 - designed specifically for datagram protocols
• 3. IPsec - the standard for securing UDP traffic
• 4. Application-layer encryption only - transport security isn’t needed for UDP

Answer

Correct: B) DTLS 1.2 or 1.3 - designed specifically for datagram protocols

DTLS (Datagram TLS) adapts TLS for unreliable datagram transport:

Feature	TLS	DTLS
Transport	TCP only	UDP, CoAP, etc.
Packet loss	TCP handles	DTLS handles retransmission
Reordering	TCP handles	DTLS sequence numbers
Fragmentation	TCP handles	DTLS explicit fragmentation

Why DTLS for IoT:

• CoAP (Constrained Application Protocol) runs over UDP - uses DTLS for security
• Low overhead: UDP + DTLS is often lighter than TCP + TLS for constrained devices
• Real-time: Better for latency-sensitive applications

Why other options are wrong:

• A: TLS requires TCP’s reliable, ordered delivery - cannot work over raw UDP
• C: IPsec is typically used for VPNs, not application-layer IoT security
• D: Transport security (DTLS) provides key exchange, handshakes, and forward secrecy that application-layer encryption alone cannot

Putting Numbers to It: Hybrid Encryption Performance

Computational cost comparison for hybrid vs pure asymmetric encryption on a Cortex-M4 processor.

viewof rsaTime = Inputs.range([10, 200], {
  value: 50,
  step: 1,
  label: "RSA-2048 single operation (ms)"
})

viewof aesTimePerBlock = Inputs.range([1, 100], {
  value: 15,
  step: 1,
  label: "AES-GCM per block (microseconds)"
})

viewof dataSizeMB = Inputs.range([0.1, 10], {
  value: 1,
  step: 0.1,
  label: "Data size (MB)"
})

hybridCalc = {
  const dataBytes = dataSizeMB * 1024 * 1024;
  const aesBlocks = Math.ceil(dataBytes / 16);
  const rsaBlocks = Math.ceil(dataBytes / 245);

  const aesTotalMs = (aesBlocks * aesTimePerBlock) / 1000;
  const hybridTotalMs = rsaTime + aesTotalMs;
  const rsaOnlyMs = rsaBlocks * rsaTime;
  const speedup = (rsaOnlyMs / hybridTotalMs).toFixed(0);

  const rsaOnlyFormatted = rsaOnlyMs > 60000
    ? (rsaOnlyMs / 60000).toFixed(1) + " minutes"
    : (rsaOnlyMs / 1000).toFixed(1) + " seconds";

  return {
    aesBlocks, rsaBlocks, aesTotalMs: aesTotalMs.toFixed(1),
    hybridTotalMs: hybridTotalMs.toFixed(1), rsaOnlyMs,
    rsaOnlyFormatted, speedup, dataSizeMB
  };
}

html`<div style="border-left: 4px solid #3498DB; padding: 0.8em 1em; margin: 1em 0; background: #f8f9fa; border-radius: 0 4px 4px 0;">
<strong>Hybrid Encryption vs Pure RSA for ${hybridCalc.dataSizeMB} MB Data</strong>

<table style="width:100%; margin-top: 0.5em; border-collapse: collapse;">
<tr style="border-bottom: 2px solid #dee2e6;">
  <th style="text-align:left; padding: 4px 8px;">Metric</th>
  <th style="text-align:left; padding: 4px 8px;">Hybrid (RSA + AES)</th>
  <th style="text-align:left; padding: 4px 8px;">Pure RSA</th>
</tr>
<tr style="background: #e8f8f5;">
  <td style="padding: 4px 8px;">Blocks to process</td>
  <td style="padding: 4px 8px;">1 RSA + ${hybridCalc.aesBlocks.toLocaleString()} AES</td>
  <td style="padding: 4px 8px;">${hybridCalc.rsaBlocks.toLocaleString()} RSA</td>
</tr>
<tr>
  <td style="padding: 4px 8px;">Total time</td>
  <td style="padding: 4px 8px;"><strong>${hybridCalc.hybridTotalMs} ms</strong></td>
  <td style="padding: 4px 8px;"><strong>${hybridCalc.rsaOnlyFormatted}</strong></td>
</tr>
<tr style="background: #e8f8f5;">
  <td style="padding: 4px 8px;">Speedup factor</td>
  <td style="padding: 4px 8px;" colspan="2"><strong>${hybridCalc.speedup}x faster</strong> with hybrid encryption</td>
</tr>
</table>

<p style="margin: 0.5em 0 0; font-size: 0.9em; color: #555;">
<strong>Key insight</strong>: RSA encrypts a maximum of 245 bytes per operation (2048-bit key with PKCS#1 v1.5 padding). AES processes 16-byte blocks but is orders of magnitude faster. The hybrid approach uses RSA once for key exchange, then fast AES for all data.
</p>
</div>`

Result: Hybrid encryption is thousands of times faster than pure RSA for bulk data, enabling real-time IoT communication on constrained devices.

In practice: Battery-powered sensors transmit megabytes per day. Pure RSA would drain the battery in hours. The hybrid approach uses RSA once per session (negligible energy), then fast AES for all data (minimal overhead).

Concept Relationships

Concept	Builds On	Enables	Related To
Symmetric Encryption (AES)	Block ciphers, XOR operations	Fast bulk data encryption	AES-GCM, AES-CCM, ChaCha20
Asymmetric Encryption (ECC/RSA)	Number theory, discrete logarithm	Secure key exchange, digital signatures	ECDH, RSA-2048, Ed25519
Hash Functions (SHA-256)	One-way functions, compression	Data integrity, password storage	HMAC, Merkle trees, blockchain
Hybrid Encryption	Symmetric + asymmetric	Practical IoT security	TLS handshake, session keys
Authenticated Encryption (GCM/CCM)	Encryption + MAC	Confidentiality + integrity	AEAD modes, prevents tampering

Key Dependencies: Symmetric encryption provides performance, asymmetric provides key distribution. Hash functions enable both standalone integrity checks and keyed authentication (HMAC). Hybrid encryption combines the best of both worlds – used in TLS, DTLS, and all modern IoT protocols.

Common Pitfalls

1. Confusing Obscurity With Security

Hiding the algorithm or using an obscure cipher does not make a system secure. Kerckhoffs’s principle states that a system should be secure even if everything except the key is known. Always use well-analyzed, public algorithms.

2. Underestimating Cryptographic Attack Surfaces

Developers often focus on the algorithm itself but neglect key storage, random number generation, and side-channel vulnerabilities — the most common real-world attack vectors. Security requires protecting the entire system, not just the cipher.

3. Using Outdated Algorithms Because They ‘Still Work’

MD5, SHA-1, DES, and 3DES are still computationally functional but cryptographically broken. They appear in legacy IoT devices because they were once standard. Migrate to SHA-256/AES when updating firmware.

Label the Diagram

💻 Code Challenge

Order the Steps

:

3.10 What’s Next

Explore the focused chapters to master each topic:

Next Chapter	Description
Symmetric Encryption	Start with the fundamentals of AES and block cipher modes
ECC for IoT	Learn IoT-optimized public-key cryptography
TLS/DTLS Transport Security	Complete connection protection for constrained devices
Encryption Labs	Hands-on practice with real cryptographic implementations

🧠 Knowledge Check

🔗 Match the Concepts