2  Cryptography Route Map

Route Map for IoT Confidentiality, Integrity, Identity, Freshness, Key Lifecycle, and Release Evidence

cryptography
route
map
In 60 Seconds

This book is the cryptography and encryption route map for IoT systems. Use it to decide what security property you need, where the plaintext boundary sits, which primitive or protocol fits that boundary, how keys are provisioned and rotated, and what negative tests prove the claim before release.

2.1 Start With the Story

A field gateway receives a temperature reading, signs a firmware manifest, and forwards an alert to the cloud. A learner might ask whether the system is encrypted, but the better first question is: who is allowed to read, alter, or approve each step? The answer changes as the data moves from a local link to a gateway, from a gateway to a cloud API, and from a signed update package back to the device.

Use this route map like a design review. First name the promise, such as confidentiality, integrity, identity, freshness, or accountability. Then find the chapter that proves the promise with the right boundary, primitive, key lifecycle, negative tests, and redacted evidence.

Learning Objectives

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

  • choose a learning path through confidentiality, integrity, identity, freshness, and key lifecycle topics;
  • route an IoT security claim to the right chapter group without confusing link, transport, object, and key-renewal layers;
  • identify which chapters provide implementation practice and which chapters provide release-review evidence;
  • assemble a lightweight evidence checklist for cryptography decisions before reading the detailed chapters.

2.2 How to Use This Book

Cryptography fails most often at the boundary around the primitive: the wrong data is protected, the wrong endpoint is trusted, a key outlives its purpose, or evidence proves only the happy path. This book is organized to keep those decisions visible.

Cryptography route map with five numbered stages on a vertical path: (1) Cryptography Foundations, 3 chapters; (2) Encryption Algorithms, 3 chapters; (3) Key Management, 2 chapters; (4) Layered Encryption, 5 chapters; (5) Cryptography Applications, 3 chapters.
Figure 2.1: Cryptography module route map: five numbered stages from cryptography foundations through encryption algorithms, key management, layered encryption, and cryptography applications, each labeled with its chapter count.
Start

New to the topic

  1. Encryption Principles & Crypto Basics
  2. Security Properties & Practices
  3. Encryption Architecture and Levels
Build

Protect device data

  1. Symmetric Encryption for IoT
  2. E1 Link Layer Encryption
  3. E2 Device-to-Gateway Encryption
Trust

Prove identity and origin

  1. Public Key Cryptography
  2. Elliptic Curve Cryptography
  3. Hash Functions and Data Integrity
Operate

Manage keys over time

  1. Key Management for IoT Devices
  2. E5 Key Renewal and Asymmetric Trust
  3. TLS and DTLS for IoT

2.3 Route by Question

Start with the claim you need to make. Then read the chapters that force the boundary, keys, and evidence to match that claim.

Question
Read First
Evidence You Should Produce
What property is required?
Security Properties & Practices and Encryption Principles
Confidentiality, integrity, identity, freshness, and accountability claims with the data owner named.
Where does plaintext appear?
Architecture and Levels, E3-E4 Transport Encryption, and TLS/DTLS
Plaintext-owner map, gateway or proxy termination decision, and logs/support bundle redaction checks.
Which primitive fits?
Symmetric Encryption, Public Key Cryptography, ECC, and Hash Functions
Primitive role, mode, nonce or context policy, peer validation, and tamper or wrong-peer rejection tests.
How are keys controlled?
Key Management and E5 Key Renewal
Provisioning boundary, protected storage, per-device scope, rotation, revocation, and old-key rejection evidence.
How do we validate release readiness?
Review Checks & Scenarios, Encryption Review Quiz, and Labs, Quiz, and Review
Negative tests, sanitized captures, secret redaction, lifecycle decisions, and exceptions that name owner and expiry.

2.4 Chapter Groups

2.4.1 Cryptography Foundations

These chapters define the vocabulary and decision model used throughout the book.

2.4.2 Symmetric Protection and Local Boundaries

These chapters help you protect traffic and frames after the key scope is known.

2.4.3 Identity, Hashing, and Key Lifecycle

These chapters focus on endpoint identity, signatures, digests, KDFs, and key operations.

2.4.4 Transport, Firmware, and Communication Boundaries

These chapters connect cryptography decisions to deployed communication paths.

2.4.5 Practice, Review, and Tools

Use these chapters after the concept chapters to test whether a decision is release-ready.

2.5 Evidence Loop

Every chapter in this book points back to the same release-review loop: name the claim, place the boundary, choose the primitive or protocol, prove key lifecycle, run negative tests, and keep evidence without leaking secrets.

A closed six-step release-review loop that every cryptography chapter returns to. Step 1 Claim names the required property and the data or command it protects. Step 2 Boundary marks where plaintext appears and which component owns it. Step 3 Primitive selects AEAD, HMAC, KDF, signature, key agreement, TLS, or DTLS for that boundary. Step 4 Lifecycle documents provisioning, storage, rotation, revocation, and old-key rejection. Step 5 Negative tests reject a wrong peer, a tampered record, a reused nonce, a replay, a downgrade, and an expired credential. Step 6 Evidence keeps sanitized captures and logs with no raw secrets or plaintext, then the loop closes back to the claim. The center states that a claim is not complete until negative tests and redacted evidence match it.
Figure 2.2: A cryptography decision is not complete until the negative tests and redacted evidence match the claim — every crypto chapter returns to this one loop.
1. ClaimName the required property and the data or command it protects.
2. BoundaryMark where plaintext appears and which component owns it.
3. PrimitiveSelect AEAD, HMAC, KDF, signature, key agreement, TLS, or DTLS for that boundary.
4. LifecycleDocument provisioning, storage, rotation, revocation, and old-key rejection.
5. Negative testsReject wrong peer, tampered record, reused nonce, replay, downgrade, and expired credential cases.
6. EvidenceKeep sanitized captures and logs without raw secrets or sensitive plaintext.

2.6 Property-to-Primitive Review Map

Cryptography is a toolbox, not one universal control. The first review move is to name the property required by the claim, then pick the primitive or protocol that actually proves that property. Encrypting a payload does not prove who created it. Hashing a file does not prove a trusted signer approved it. A nonce does not prove integrity unless it is bound into an authenticated protocol.

Security property
Typical primitive or protocol
Evidence to keep
Confidentiality
AEAD encryption, TLS, DTLS, or approved object protection.
Plaintext boundary, key owner, cipher suite, and no-cleartext-fallback tests.
Integrity and authenticity
HMAC, AEAD authentication tag, or digital signature.
Tamper tests, wrong-key tests, signer or shared-secret scope, and reject-before-parse behavior.
Identity and origin
Certificates, signatures, enrolled device keys, or authenticated service identity.
Wrong-peer, expired credential, revoked credential, and unapproved issuer failures.
Freshness
Nonce, counter, timestamp, sequence window, or protocol replay window.
Replay, rollback, reboot, sleep, and packet-loss tests under the same key epoch.

In an IoT review, the property should be written as a testable claim. “Telemetry is encrypted” is not enough. The claim should say whether the protected boundary is the local link, the TLS or DTLS transport session, the object stored by a gateway, or the full device-to-cloud application payload. That boundary decides who may read plaintext, who authenticates whom, and where logs may accidentally expose secrets.

Property to Primitive

2.7 Hybrid Protocol Pattern

Real channels usually combine asymmetric and symmetric cryptography. Asymmetric mechanisms such as ECDH, signatures, and certificates solve key agreement and identity problems, but they are not the right tool for bulk telemetry. Symmetric AEAD modes such as AES-GCM and ChaCha20-Poly1305 protect most records after the protocol has established session keys.

Asymmetric setup:
  Identify the peer or signer, agree fresh key material, and feed a KDF.

Symmetric records:
  Protect bulk data with an authenticated mode and strict nonce policy.

Review evidence:
  Reject wrong peer, weak version, bad tag, replay, stale key, and rollback.

TLS 1.3 is the familiar hybrid pattern: authenticated key agreement establishes fresh secrets, a KDF derives traffic keys, and symmetric record protection carries the data. DTLS 1.3 adds datagram-specific evidence for loss, reordering, retransmission, and replay windows. Firmware-update channels use the same discipline differently: signed manifests and rollback rejection prove origin and lifecycle, while encryption only hides package contents if confidentiality is also required.

Hybrid Cryptography

2.8 Hashes, Keys, and Failure Behavior

Hash functions, HMACs, signatures, KDFs, and password hashes are easy to confuse because they all mention “hashing.” A plain SHA-256 digest is useful for detecting accidental differences only when the digest itself is trusted. Anyone who can edit a message can compute a new digest. Authenticity requires a secret or private key around the digest, such as HMAC-SHA-256 for a shared-key relationship or Ed25519, ECDSA, or RSA-PSS for signed artifacts.

Modern reviews should also reject broken or misplaced hashes. MD5 and SHA-1 are broken for collision resistance and should not be used where collision resistance matters. Password storage should use a password-hashing function such as Argon2id, bcrypt, scrypt, or PBKDF2 with unique salts and an appropriate work factor, not a bare fast hash.

Key lifecycle is the operational part of cryptography. Device fleets need per-device or bounded group scope, manufacturing records that identify installed credentials, protected storage such as a secure element, TPM, or protected MCU key store where available, and rotation evidence showing old credentials fail after replacement. Under failure, the right behavior is rejection: no plaintext fallback when certificate validation fails, no payload parsing after an AEAD tag failure, and no boot when a firmware signature is missing.

Key Handling

2.9 Start by Role

Architect

Choose the protection layer

Read architecture, E1, E2, E3-E4, TLS/DTLS, and key management. Produce a plaintext-owner map and exception register.

Firmware

Use primitives safely

Read symmetric encryption, hash functions, ECC, labs, and tools. Prove nonce policy, tamper rejection, key storage, and secret redaction.

Backend

Validate peers and messages

Read public key cryptography, TLS/DTLS, secure communications, and review scenarios. Prove wrong-peer, downgrade, replay, and stale-key failures.

Reviewer

Approve release claims

Read review chapters, labs review, and the quiz. Check evidence coverage, lifecycle decisions, and whether any claim exceeds the protected boundary.

2.10 Release Evidence Checklist

Use this before moving from chapter learning to production design.

Boundary

Plaintext is mapped

  • Data owner named
  • Gateway and proxy termination marked
  • Logs and support bundles redacted
Primitive

Role is correct

  • AEAD protects records
  • HMAC or signature proves origin where needed
  • KDF context separates purposes
Keys

Lifecycle is controlled

  • Per-device or role scope documented
  • Rotation and revocation tested
  • Old credentials rejected
Tests

Failures fail closed

  • Wrong peer rejected
  • Tamper and replay rejected
  • No cleartext fallback path

2.11 Practice: Route the Cryptography Decision

Use these checks to practice the index-level decision process before moving into the chapter details.

Check 1: Pick the First Chapter
Check 2: Match Property to Evidence
Check 3: Key Lifecycle
Check 4: Transport Claim
Label the Route Map

Code Challenge: Choose a Review Route

Order a Cryptography Review

Match Chapter Group to Evidence

2.12 Common Pitfalls

Starting with an Algorithm Name

An algorithm name is not a release claim. Start with the property, boundary, key scope, and failure behavior, then select the primitive or protocol.

Claiming End-to-End Protection After a Gateway Decrypts

Transport protection ends where the session terminates. If the gateway reads plaintext, the claim must say so or add object-level payload protection.

Treating Key Rotation as Documentation Only

Rotation is not complete until old credentials fail, rollback is handled, and devices can recover without leaking secrets.

Saving Evidence That Exposes Secrets

Evidence should prove behavior without storing raw keys, PSKs, session secrets, or sensitive plaintext in reports, logs, screenshots, or support bundles.

2.13 References

2.14 What’s Next

Begin with Encryption Principles & Crypto Basics if you are new to the book. If you are reviewing a live design, start with Encryption: Architecture and Levels, then move to the primitive, transport, and key-lifecycle chapters that match the claim.

2.15 Summary

The cryptography module covers the primitives and architectures used to protect IoT data and communication: symmetric encryption, asymmetric cryptography, ECC, hashes, TLS/DTLS, multilayer encryption, and key management.

2.16 Key Takeaway

Cryptography in IoT is a lifecycle discipline. Pick the right primitive, protect keys, authenticate peers, rotate credentials, and test failure cases across the full device lifetime.