3 Why Cryptography Matters for IoT
Choosing the Right Primitive, Boundary, and Evidence
IoT cryptography basics, security objective, authenticated encryption, plaintext boundary, hybrid cryptography, key lifecycle, crypto release evidence
3.1 Start With the Job, Not the Cipher
Imagine a sensor command that crosses a gateway before it changes a real actuator. If the review starts with “we use AES,” nobody yet knows whether the command is private, unmodified, from the right controller, or too old to accept. The cipher name is a tool label; the security job is the claim that can pass or fail.
This chapter follows that one review habit: name the job, choose the primitive for that job, locate the plaintext boundary, and keep evidence that the wrong sender, changed packet, reused nonce, or replayed command fails closed.
Crypto Is a Set of Jobs, Not a Shield
Cryptography is a toolbox of controls, not a single magic shield. Each tool proves one narrow thing. The most common mistake is to name an algorithm, such as "we use AES," and assume the system is now secure. The first question is never which algorithm. It is which job the cryptography must do.
Four jobs cover most IoT needs. Confidentiality keeps a message unreadable. Integrity lets the receiver detect any change. Authentication proves who sent the message. Freshness stops an old valid message from being replayed.
If you only need the intuition, this layer is enough: name the job first, then pick a reviewed primitive for that job, then decide where the data is allowed to be read and who holds the keys. An algorithm name on its own is not a security claim.
Think of shipping a parcel. A locked box keeps the contents private (confidentiality). A tamper-evident seal shows if someone opened it (integrity). A handwritten signature proves who packed it (authentication). A dated, single-use shipping label stops the same parcel being re-sent later (freshness). One control rarely does all four jobs, so a real design combines them on purpose.
The same split shows up in ordinary IoT traffic. A temperature reading sent over MQTT may need confidentiality if the value reveals occupancy, integrity if a changed value could trigger a false alarm, authentication if the cloud must know which sensor reported it, and freshness if an old reading could be replayed during an outage. A firmware image can be public but still needs a signature. A gateway may legitimately see plaintext after decrypting a link, while a broker or analytics service may not. Those are separate design decisions, which is why a review asks for the job, the plaintext boundary, the key owner, and the failure test instead of accepting a cipher name.
The One-Minute View
Name the job
Decide whether you must hide data, detect tampering, prove the sender, reject replay, or some combination of these.
Pick a reviewed primitive
Choose an established primitive for that job, such as authenticated encryption for private and tamper-evident traffic.
Define boundary and keys
Name where plaintext appears and who holds each key. A primitive protects only the boundary where it is applied.
Beginner Examples
- A device that encrypts telemetry but cannot detect a changed message has confidentiality without integrity.
- A signed firmware image proves origin, yet anyone who downloads it can still read it. Signing is authentication, not secrecy.
- "We use AES" is not a claim a reviewer can accept. It names a cipher but not the mode, the nonce plan, the boundary, or the key owner.
Overview Knowledge Check
If you can name the four jobs and explain why an algorithm name is not a claim, you can stop here. Continue to Practitioner to choose primitives and review a real channel.
Match Primitives and Build the Hybrid Channel
The practical workflow turns a security objective into a primitive choice, a boundary, and a key owner, then proves the choice with negative tests. Each primitive has a narrow role, and the common review failure is asking one primitive to do a job it does not provide.
Primitive Roles
Walkthrough: The Hybrid Channel
Most secure IoT connections use a hybrid pattern. Public-key mechanisms authenticate the peers and establish shared secret material; a key derivation function turns that material into traffic keys; symmetric authenticated encryption protects the high-volume telemetry, command, and update traffic.
- Authenticate the peers. Check device, gateway, or service identity before trusting any key-exchange output.
- Establish secret material. Use an approved key-agreement or provisioning method instead of sending reusable keys in messages.
- Derive scoped keys. Bind derived keys to protocol, role, direction, and session context so one key has one purpose.
- Protect the traffic. Use authenticated encryption or a protocol profile that rejects both tampering and replay.
- Rekey and retire. Limit key lifetime, revoke compromised credentials, and record rollover behavior.
IoT Threat-to-Control Map
Use this map as a design-review starting point. It links each IoT security goal to a common control, the failure mode reviewers see most often, and the decision rule that confirms the control is correctly applied.
Worked Review: A Sensor Command Channel
A building sensor accepts remote configuration commands through a gateway. The team proposes "encrypted messages" as the control. The reviewer turns that statement into evidence questions.
What the claim covers
Encryption can hide the command body from an observer on the link or at the broker.
What the claim misses
It says nothing about who may send commands, whether a changed command is rejected, or whether an old command can be replayed.
Conclusion
Require authenticated sender identity, tamper rejection, a freshness check, and a key-lifecycle plan before accepting the channel. Confidentiality alone is not enough for a command path.
Practitioner Knowledge Check
If you can match primitives to jobs and scope a channel claim to the evidence, you can stop here. Continue to Under the Hood for boundaries, AEAD mechanics, and failure modes.
Boundaries, AEAD, and Failure Modes
The deeper layer explains why the workflow separates objective, boundary, primitive, and key custody. Each is an independent guarantee, and a weakness in any one can undo the others.
Boundary Before Algorithm
A primitive protects only the boundary where it is applied. A link-layer frame can be encrypted while the gateway still sees plaintext. A TLS channel can protect device-to-cloud transport while the cloud service stores decrypted payloads. A signed firmware image proves origin while remaining readable by anyone. A complete review names four boundaries: the data boundary (who may read it), the trust boundary (who may modify or forward it), the key boundary (who can decrypt or sign), and the evidence boundary (what may be published without leaking secrets).
Why Authenticated Encryption
Plain encryption hides content but does not detect change. An attacker can flip ciphertext bits and, in many modes, predictably alter the decrypted plaintext. Authenticated encryption with associated data (AEAD) solves this by producing a ciphertext and an authentication tag together. The receiver recomputes and checks the tag, and must reject the message if the tag fails, before using any plaintext. AEAD also authenticates associated data, such as headers or routing fields, that must stay readable but must not be altered.
- Verify before use. A correct AEAD implementation does not release or act on plaintext until the tag verifies. Acting on unverified plaintext reintroduces the tampering risk.
- Nonces must be unique per key. AEAD modes require a nonce that is never repeated under the same key. In a counter-based mode such as AES-GCM, reusing a nonce with the same key is catastrophic: it can leak relationships between the two plaintexts and can expose the value used to forge tags, breaking both confidentiality and integrity for that key.
- Confidentiality is not freshness. AEAD rejects tampering, but a correctly authenticated old message can still be replayed unless the protocol adds a sequence number, counter, or replay window.
Hash, MAC, and Signature
These three are routinely confused, but they make different promises:
- A hash (for example SHA-256) maps data to a fixed digest. It detects accidental change and fingerprints data, but anyone can recompute it, so a bare hash proves neither secrecy nor origin.
- An HMAC mixes a shared secret into the digest, so a valid tag proves the sender held the shared key. Because both parties share that key, HMAC gives integrity and authentication but not non-repudiation: neither party can prove to a third party which of them produced the tag.
- A digital signature uses a private key to sign and the matching public key to verify. Only the private-key holder can produce a valid signature, so signatures support public verification and non-repudiation, which a shared-key MAC cannot.
Key Agreement and Derivation
Key agreement (for example Diffie-Hellman or its elliptic-curve form) lets two peers compute a shared secret without sending the final traffic key. When each side uses a fresh ephemeral key per session, the exchange also provides forward secrecy: a later compromise of a long-term key does not expose past session traffic. A key derivation function (KDF) such as HKDF then expands the shared secret into separate, scoped keys, binding each to a label and context so that a key for one direction or purpose cannot be confused with another.
Common Pitfalls
- Naming an algorithm instead of a job. "We use AES" omits the mode, nonce plan, boundary, and key owner that decide whether it is safe.
- Encrypting without authenticating. Confidentiality without integrity lets an attacker tamper with ciphertext undetected.
- Reusing a nonce. A repeated nonce under the same key can break a counter-based AEAD mode entirely.
- Treating a hash as proof of origin. Anyone can recompute a hash, so it needs a key (MAC) or a signature to prove the sender.
- Forgetting freshness. An authenticated message can still be replayed without a counter, sequence number, or replay window.
IoT Device Acceptance Evidence
Before field rollout, an IoT crypto review should produce concrete records, not a single "encrypted" label. The strongest acceptance file confirms the items below.
Under-the-Hood Knowledge Check
At this depth, a crypto basics review is a chain of independent guarantees: a named objective, a defined boundary, an authenticated primitive used correctly, a unique nonce and freshness plan, distinct keys with a lifecycle, and negative tests that prove bad inputs are rejected. A trustworthy review records each link instead of accepting a single algorithm name.
3.2 Summary
- Cryptography is a set of jobs, not a shield: name confidentiality, integrity, authentication, or freshness before naming an algorithm.
- Each primitive has a narrow role, and the common failure is asking one primitive to do a job it does not provide.
- Most secure IoT channels use a hybrid pattern: public-key setup and key agreement, a KDF for scoped keys, and symmetric AEAD for traffic.
- A primitive protects only the boundary where it is applied, so the review must name the data, trust, key, and evidence boundaries.
- AEAD needs verify-before-use and a unique nonce per key; confidentiality alone does not provide freshness.
- Hashes detect change, MACs prove a shared-key sender, and signatures add public verification and non-repudiation.
- Release evidence connects the objective to negative tests and a key lifecycle, not just a cipher name.
Start every cryptographic design with the security job it must prove, then choose a reviewed primitive, fix the plaintext boundary, manage the keys, and keep evidence from negative tests. An algorithm name is never, by itself, a security claim.
3.3 See Also
Apply the AEAD, nonce, and key-discipline ideas to AES-GCM, AES-CCM, and ChaCha20-Poly1305.
See how public-key agreement, signatures, and certificates anchor identity and forward secrecy.
Encryption Security Properties
Deepen the confidentiality, integrity, authenticity, and freshness goals behind every primitive choice.