Cryptography · Study deck

Cryptography Route Map

Picture a health reading leaving a wearable, crossing a home bridge, and entering a clinical service.

Shield Shelly is your guide for this deck.

route

Shield Shelly, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

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.

Major section

In 60 Seconds

Encrypting one link is not enough if an unnamed reader can copy or change the record at the next boundary.

An API is a named software entry point used by another program.
A gateway is the device or service that joins two system paths.
Firmware is the stored device code and its version.

Major section

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.
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.

Cryptography route map: five review stages move from naming the required security property through choosing mechanisms, controlling key lifecycle, placing the protection boundary, and proving release evidence; a worked TLS 1.3 hybrid mechanism and AES-256 key-scope check make the route concrete.

Major section

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.

Evidence then returns to the claim; a mismatch reopens the design instead of being filed as a pass.
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.
That feedback connection is the common narrative shared by every route through the module.

A cryptography decision is not complete until the negative tests and redacted evidence match the claim — every crypto chapter returns to this one loop.

Major section

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.
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.

Major section

Hybrid Protocol Pattern

TLS 1.3 also permits PSK-only key exchange, which lacks forward secrecy.

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.
DTLS 1.3 adds datagram-specific evidence for loss, reordering, retransmission, and replay windows.

Major section

Hashes, Keys, and Failure Behavior

Anyone who can edit a message can compute a new digest.

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.
Key lifecycle is the operational part of cryptography.

Deck summary

Key takeaways

Encrypting one link is not enough if an unnamed reader can copy or change the record at the next boundary.

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.
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.
Cryptography is a toolbox, not one universal control.
Anyone who can edit a message can compute a new digest.

Retrieval practice

Recall check 1 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q1A message must prove it was not altered and came from the expected sender, but secrecy is not required. Which primitive fits?

AEncryption alone without authentication

BCompression before every packet

CA MAC or digital signature

DA nonce stored without a tag

Show answer

Answer: C Integrity and origin evidence come from a MAC or signature; encryption is not required for this claim.

Retrieval practice

Recall check 2 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q2A fleet uses AES-256 correctly but hard-codes one shared key into every device. What is the main risk?

AAES-256 becomes too small for IoT messages

BOne extracted device key can expose the whole fleet

CHashing the shared key makes reuse safe

DNo rotation plan is needed with strong ciphers

Show answer

Answer: B The cipher can be strong while key scope, storage, and revocation make the deployment unsafe.

Retrieval practice

Recall check 3 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q3A team says a gateway may decrypt device messages before forwarding them to a cloud service, but the product page claims end-to-end confidentiality. Which chapter should they read first?

ACipher Challenge Game, for selecting a stronger cipher for the gateway

BInteractive Cryptography Tools, for checking the encryption settings

CEncryption: Architecture and Levels, for the gateway trust boundary.

DEncryption Review Quiz, for signing off the confidentiality claim

Show answer

Answer: C The first issue is the claim boundary: who can see plaintext and where the protected layer ends.

Retrieval practice

Recall check 4 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q4A device fleet uses a shared key and has no way to revoke a single device. Which chapter group should be prioritized?

ACipher selection and implementation checks.

BKey management and renewal

CGeneral threat modeling and security orientation.

DInterface authentication and access logging.

Show answer

Answer: B Shared-key blast radius and revocation are lifecycle problems before they are protocol problems; the issue is key scope, containment, revocation, and old-key rejection.

Retrieval practice

Recall check 5 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q5A datagram-based protocol needs encrypted communication without changing its transport behavior. Which route is most useful?

AUse link-layer encryption only and skip transport identity

BUse a hash function alone for confidentiality

CRoute directly to privacy regulations

DUse DTLS and verify the datagram transport boundary.

Show answer

Answer: D DTLS handles datagram transport, while E3-E4 clarifies what the transport session does and does not protect.

Q6Complete a small router that selects the next chapter group for a cryptography review:

Aif claim['plaintext_boundary'] == 'unclear':

Bif claim['button_color'] == 'blue':

Cif claim['page_title'] == 'short':

Dif claim['diagram_count'] == 0:

Show answer

Answer: A A review route starts with unclear plaintext boundaries, then missing key lifecycle, then release checks and labs once the design is coherent.

Print reference

Answers 1 of 2

Answer key.

C · Integrity and origin evidence come from a MAC or signature; encryption is not required for this claim.
B · The cipher can be strong while key scope, storage, and revocation make the deployment unsafe.
C · The first issue is the claim boundary: who can see plaintext and where the protected layer ends.
B · Shared-key blast radius and revocation are lifecycle problems before they are protocol problems; the issue is key scope, containment, revocation, and old-key rejection.

Print reference

Answers 2 of 2

Answer key.

D · DTLS handles datagram transport, while E3-E4 clarifies what the transport session does and does not protect.
A · A review route starts with unclear plaintext boundaries, then missing key lifecycle, then release checks and labs once the design is coherent.