2 Cryptography Route Map

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.

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. Before choosing a chapter, inspect Figure 2.1 to see why the route begins with security claims and primitives, then adds key custody, protection boundaries, and application evidence in that order.

Read Figure 2.1 from stage 1 to stage 5. Foundations name the property that must hold; algorithms provide mechanisms for that property; key management keeps the mechanism trustworthy over time; layered encryption places protection at the correct readers; and applications turn those choices into testable release evidence. The sequence is the running narrative for the book, although a reviewer may return to an earlier stage whenever later evidence exposes a weak assumption.

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.

2.4 Chapter Groups

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. Inspect Figure 2.2 to see why the review returns to the original claim after evidence is collected.

Read Figure 2.2 clockwise from claim to boundary, primitive, lifecycle, negative tests, and sanitized evidence. Each stage constrains the next: the claim selects a boundary, the boundary gives the mechanism a job, lifecycle keeps its keys valid, and failure tests challenge the promised behavior. Evidence then returns to the claim; a mismatch reopens the design instead of being filed as a pass. That feedback connection is the common narrative shared by every route through the module.

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.

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.

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.

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.

2.9 Start by Role

2.10 Release Evidence Checklist

Use this before moving from chapter learning to production design.

2.11 Practice: Route the Cryptography Decision

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

2.12 Common Pitfalls

2.13 References

• NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management
• NIST SP 800-56A Rev. 3: Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography
• NIST SP 800-38D: Galois/Counter Mode for Block Ciphers
• FIPS 197: Advanced Encryption Standard (AES)
• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 9147: The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
• RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF)

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.