6 Symmetric Encryption for IoT
6.1 Start Simple
Reject One Changed Command Before It Reaches the Pump
Picture a water pump receiving a private command from a field controller. Hiding the command is not enough; the pump must also reject a changed or repeated command. The useful starting point is one message whose sender, age, and result can be checked.
Firmware means the software stored on a device. MQTT means Message Queuing Telemetry Transport, a lightweight way to exchange messages. Telemetry means measurements and status sent for remote use.
Send one known command with a fresh message number, alter one byte, repeat the old message, use the wrong key, and restart the receiver. Record which checks fail before any physical action. Keep the last safe local state when proof is missing.
This runway does not prove that one cipher mode or key plan fits every system. The deeper sections explain shared secrets, nonces, authenticated encryption, key handling, message boundaries, and failure behavior.
Imagine two devices already share one secret. Symmetric encryption is the fast way to use that secret to protect every reading and command, but it only works when the mode checks tampering and the nonce never repeats. Start with one message, one shared key, one unique nonce, and one rule: verify the tag before the device acts.
6.2 Overview: One Shared Key for Both Directions
Symmetric encryption protects data with a single secret key that is used to both encrypt and decrypt. It is fast and cheap to run, which makes it the workhorse for the high-volume traffic of an IoT system: telemetry, commands, firmware records, and stored data. The same key that locks the data also unlocks it, so the security of the whole scheme rests on two things: who holds a copy of that key, and whether the key is used correctly.
The most common mistake is to treat the word "encrypted" as the finish line. A shared key only delivers a strong claim when the encryption mode is right, when a one-time value called the nonce never repeats under the same key, and when the receiver checks that the data has not been tampered with before acting on it. For an MQTT command channel, that means the device verifies the tag over the command, topic, device identity, sequence value, and key identifier before it changes actuator state.
If you only need the intuition, this layer is enough: symmetric encryption shares one secret key for both sides. Prefer an authenticated mode (AEAD) that hides the data and detects tampering in one step, never reuse a nonce under the same key, and always verify the authentication tag before trusting the decrypted bytes.
Think of a lockbox whose single combination has been shared with one trusted friend. The combination keeps strangers out, which is confidentiality. But the plain lock by itself cannot tell you whether someone who knows the combination opened the box and swapped a note inside; for that you need a tamper-evident seal, which is integrity and authenticity. And because the combination is shared, the box can never prove which of the two of you left a note, so it offers no non-repudiation. Modern symmetric encryption ships the lock and the tamper-evident seal as one bundle, and that bundle is called AEAD. Inspect Figure 6.1 before following the receiver’s checks.
Read Figure 6.1 from plaintext, scoped shared key, and unique nonce into ciphertext, associated data, and the authentication tag. The ciphertext hides the protected fields; associated data remains visible but is bound against modification; and the receiver must verify the tag before releasing or acting on plaintext. The same secret permits both endpoints to protect records, so it does not identify which key holder created one. This path connects symmetric speed to the nonce, scope, and verification duties that make its security claim honest.
6.2.1 The One-Minute View
6.2.2 One key, both ways
The same secret encrypts and decrypts, so it is fast for bulk IoT traffic, but every key holder can read and produce protected data within that scope.
6.2.3 Prefer authenticated modes
AEAD modes such as AES-GCM, AES-CCM, and ChaCha20-Poly1305 give confidentiality and tamper detection together; plain encryption hides data but does not detect changes.
6.2.4 Nonce and key discipline
A nonce must never repeat under the same key, and the secret must be distributed and stored safely. These two rules carry most of the real risk.
6.2.5 Beginner Examples
These examples show why the mode, nonce plan, and key scope matter. A device that encrypts a reading with AES-GCM and checks the tag before using it has confidentiality and tamper detection. A device that encrypts with AES-CTR and acts on the plaintext with no separate check has confidentiality only. "We use AES" does not say which mode. AES in ECB mode leaks repeated patterns, and AES-GCM with a reused nonce can break entirely. The mode and the nonce plan are the real claim. A whole fleet sharing one secret key is convenient. Extracting the key from a single device then exposes every device in that scope. Per-device keys contain the damage.
6.2.6 Overview Knowledge Check
If you can explain why a shared key needs the right mode and a unique nonce, you can stop here. Continue to Practitioner to choose a mode and apply it to a real channel.
6.3 Practitioner: Choose a Mode and Protect a Channel
The practical workflow turns "we will encrypt it" into a boundary, a mode, a nonce rule, and a key plan, then proves the choice with negative tests. Each step closes a gap that a single algorithm name leaves open, and the common review failure is approving confidentiality while integrity, freshness, or key distribution stays unexamined.
6.3.1 Walkthrough: From Boundary to Verified Plaintext
Follow the sequence from decision to evidence. First, Name the boundary and key scope. Decide where plaintext is allowed to appear and who holds the key: device, session, tenant, direction. Aim for one key with one purpose. Next, Pick an authenticated mode by default. Choose a reviewed AEAD such as AES-GCM, AES-CCM, or ChaCha20-Poly1305 so confidentiality and integrity arrive together. Treat confidentiality-only modes as legacy exceptions. Next, Fix the nonce or IV rule. Define how the nonce stays unique per key across reboot, retry, reconnect, and counter rollover. Never reset a counter to zero on reboot while keeping the same key. Next, Bind the associated data. List the visible context that must not change silently, such as device id, message type, sequence, or key id, and authenticate it as AEAD associated data. Next, Verify before use. Confirm the receiver checks the authentication tag, and any freshness value, before it parses, routes, logs, or acts on the plaintext. Finally, Plan key distribution and lifecycle. Show how the shared key is established without sending it in the clear, kept per device, rotated, and revoked.
6.3.2 Choosing a Mode
Mode selection is a security decision, not a naming preference. Start from a reviewed authenticated mode and only fall back to a confidentiality-only mode as a documented legacy exception with its own authentication.
6.3.3 Worked Review: A Telemetry Channel
A device sends temperature readings to a gateway. The team proposes "AES-CTR encryption" as the protection. The reviewer turns that into evidence questions.
6.3.3.1 What the claim covers
CTR, used correctly with a unique key and counter, hides the reading value from an observer on the link or at the broker.
6.3.3.2 What the claim misses
CTR provides no tamper detection. A flipped ciphertext bit changes the decrypted value, and nothing rejects it. There is no authentication tag and no replay check.
6.3.3.3 Conclusion
Move to an AEAD mode such as AES-GCM or ChaCha20-Poly1305, or add an encrypt-then-MAC composition, and verify the tag before the reading is stored or acted on. Confidentiality alone is not enough.
6.3.4 Practitioner Knowledge Check
If you can pick an authenticated mode and defend its nonce and key plan, you can stop here. Continue to Under the Hood for the mechanisms, formats, and failure modes.
6.4 Under the Hood: Block Cipher, Modes, and Failure Modes
The deeper layer explains why the workflow separates the cipher, the mode, the nonce, and the key. Each is an independent guarantee, and a weakness in any one can undo the others even when the algorithm name looks strong.
6.4.1 Block Cipher Versus Mode of Operation
AES is a standardized block cipher: it transforms one fixed 128-bit block under a key of 128, 192, or 256 bits. On its own it only encrypts a single block. A mode of operation extends that single-block transform to messages of any length and decides the security properties, so the same AES core is safe or unsafe depending entirely on the mode. ECB applies the block cipher independently to each block, so identical plaintext blocks always map to identical ciphertext blocks; that visible repetition leaks structure, which is why ECB must never be used for confidentiality. CBC and CTR remove that pattern but still provide confidentiality only.
AES was standardized from the Rijndael design and is the modern default block cipher for most new symmetric-encryption reviews. It replaced DES, whose original key size is far too small for modern use; even 3DES is now treated as legacy and should not appear in new IoT designs. Older notes and products may still mention IDEA, Blowfish, RC4, RC5, or RC6, but a review should not approve them by name alone. It should ask for the approved protocol profile, the mode, the key length, the nonce or IV rule, and the migration plan away from deprecated ciphers such as DES, 3DES, and RC4.
6.4.2 Inside the Block Cipher: Feistel Structure and the AES Round
The mode of operation decides how a block cipher scales to a whole message, but the block cipher's own internal structure is worth knowing when a review has to look past an algorithm name. Many classic block ciphers, including DES and the lightweight cipher XTEA, are Feistel ciphers: each round splits the block into a left half and a right half, runs a round function over the right half combined with that round's subkey, XORs the result into the left half, then swaps the halves before the next round. The round function itself does not need to be reversible, because the split-and-swap structure is what makes the whole round reversible; decryption runs the identical structure with the round subkeys applied in reverse order.
A short worked pass shows the mechanics on a toy 32-bit block. Splitting the plaintext 0xAABBCCDD gives a left half of 0xAABB and a right half of 0xCCDD. Using a first-round subkey of 0x1A2B and a round function that rotates the right half two bits and XORs it with the subkey, the round produces a new right half of 0xC3A7, while the old right half, 0xCCDD, becomes the new left half. The next round repeats the same split-mix-swap pattern against a second subkey (0x3F07) and the updated halves. A real Feistel cipher runs many more rounds with a substantially more complex round function, but the shape, split, mix, swap, is exactly this.
AES is not a Feistel cipher; it is a substitution-permutation network, and every round applies four distinct operations to the block, arranged as a 4x4 grid of bytes: SubBytes replaces each byte through a fixed substitution table, ShiftRows cyclically shifts each row of the grid by a different amount, MixColumns mixes each column's bytes together to spread any change across the block (skipped on the final round), and AddRoundKey XORs the grid with that round's slice of the expanded key. The key size determines how many rounds run. This structure is what turns "AES-128" from a label into a claim a reviewer can reason about: a fixed block size, four round operations, and a key schedule that derives every round's subkey from the original key.
6.4.3 Why Authenticated Encryption
Authenticated encryption with associated data (AEAD) produces a ciphertext and an authentication tag together. The tag covers both the encrypted payload and any associated data, which are fields such as headers, routing, or sequence numbers that must stay readable but must not be altered. The receiver recomputes the tag and must reject the message if it does not match, before using any plaintext or any associated data. That is what verify-before-use means: acting on unverified plaintext reintroduces exactly the tampering risk AEAD removes. Associated data is authenticated but not encrypted, so it stays visible while it cannot be silently changed.
6.4.4 Nonces, Counters, and Why Reuse Is Fatal
Counter-based modes (CTR, and AES-GCM built on it) turn a block cipher into a keystream generator driven by the key and the nonce, then combine that keystream with the plaintext. This is why a repeated nonce under the same key is catastrophic: two messages encrypted with the same key and nonce share the same keystream, so combining the two ciphertexts cancels the keystream and exposes the relationship between the two plaintexts. For GCM specifically, nonce reuse can also expose the secret value used inside the authentication step, which can let an attacker forge valid tags for that key, so both confidentiality and integrity collapse. AES-GCM commonly uses a 96-bit (12-byte) nonce as its standard, most efficient choice. The nonce does not need to be secret, but it must be unique per key, which is why reboot, retry, reconnect, and rollover all need a defined rule.
6.4.5 Confidentiality, Integrity, Authenticity, and What Symmetric Cannot Do
These properties are distinct. Confidentiality hides the content. Integrity detects modification. Authenticity proves the data came from a holder of the key. AEAD, and a separate MAC, both give integrity and authenticity of the ciphertext to anyone holding the shared key. But because the key is shared, symmetric encryption cannot provide non-repudiation: either party could have produced the tag, so it cannot prove to a third party which one did. Non-repudiation needs an asymmetric digital signature, where only one party holds the private key.
6.4.6 Legacy Composition and Key Establishment
When a confidentiality-only mode must be used, the safe composition is encrypt-then-MAC: encrypt the plaintext, compute a MAC over the ciphertext and any associated data, and on receive verify the MAC before decrypting. Hand-built compositions are easy to get wrong, so a modern design prefers a reviewed AEAD instead. Symmetric encryption also assumes both sides already share the key, but it does not solve how the key arrived. Sending a raw key over an unprotected channel defeats the whole design, so real systems establish symmetric keys through an asymmetric or hybrid setup: a key-agreement or provisioning step authenticates the peers and yields shared secret material, a key derivation function expands it into scoped traffic keys, and symmetric AEAD then protects the bulk traffic. Keys should be per device, or derived from per-device material, and they should be rotatable and revocable.
Key use also has an operating limit. Long-lived symmetric keys can suffer key exhaustion: every protected record gives an attacker more material to study and increases the cost of recovering safely if the key later leaks. A release record should therefore define data-volume limits, key epochs, rotation triggers, and what happens to old ciphertext if a retired key is lost. Symmetric keys also do not carry rich use policy by themselves. Unlike a certificate or signed authorization object, a raw shared key does not embed expiry, permitted use, or access-control metadata; those constraints must be enforced by the surrounding key-management system and authenticated associated data.
6.4.7 Common Pitfalls
-
Wrong: A strong cipher name makes the whole design safe. Mode, fresh counters, tamper checks, and key care still matter.
Follow the sequence from decision to evidence. First, Treating "AES" as a complete design. AES is one block operation; the mode, nonce plan, associated data, and key scope decide whether it is safe. Next, Using ECB for real data. Identical plaintext blocks produce identical ciphertext blocks, leaking structure. Never use ECB for confidentiality. Next, Encrypting without authenticating. CBC and CTR hide data but do not detect tampering; pair them with encrypt-then-MAC or, better, use AEAD. Next, Reusing a nonce. A repeated nonce under the same key breaks a counter-based AEAD, including after a careless reboot counter reset. Next, Acting before verifying. Parsing, routing, or executing decrypted bytes before the tag is checked defeats the integrity guarantee. Next, Claiming non-repudiation from a shared key. A shared key cannot prove which party acted; that needs an asymmetric signature. Finally, Letting one key live forever. Bulk symmetric traffic needs key epochs, rotation triggers, and recovery evidence so key exhaustion or a retired-key loss does not become a fleet incident.
6.4.8 Under-the-Hood Knowledge Check
At this depth, symmetric encryption is a set of independent guarantees built on one shared key: a block cipher used through a sound mode, an authentication tag that is verified before use, a nonce that never repeats per key, associated data bound against silent change, and a key that is scoped, distributed safely, and revocable. Get the mode and nonce discipline right, pair the shared key with an asymmetric setup for distribution, and remember the one job it cannot do alone, which is proving which party produced a message.
6.5 Summary
Carry the chapter forward as one connected chain. First, Symmetric encryption uses one shared secret key for both encryption and decryption; it is fast and is the workhorse for bulk IoT traffic. Then, AES is a block cipher with a 128-bit block and 128, 192, or 256-bit keys; the mode of operation, not AES alone, decides the security properties. Then, ECB is unsafe for general data because identical plaintext blocks produce identical ciphertext blocks; CBC and CTR provide confidentiality only and need a separate MAC. Then, Prefer AEAD such as AES-GCM, AES-CCM, or ChaCha20-Poly1305: confidentiality plus integrity and authenticity of the ciphertext, and authentication of associated data. Then, A nonce must be unique per key; reusing a nonce under one key in GCM is catastrophic, and the receiver must verify the tag before using any plaintext. Then, Symmetric encryption needs secure key establishment, so real systems pair it with an asymmetric or hybrid setup, per-device keys, rotation, and revocation. Then, A shared key gives confidentiality, integrity, and authenticity, but not non-repudiation, because it cannot prove which party produced a message. Finally, Legacy algorithm names such as DES, 3DES, IDEA, Blowfish, RC4, RC5, or RC6 are review prompts, not approval evidence; the modern claim needs a profile, mode, nonce rule, lifecycle, and migration plan.
Symmetric encryption protects IoT data efficiently only when the mode is authenticated, the nonce never repeats under a key, the tag is verified before use, and the shared key is scoped, safely distributed, and revocable. A strong key cannot rescue a weak mode or a reused nonce.
6.6 See Also
Asymmetric Encryption
See how public-key agreement and signatures establish the shared keys that symmetric encryption depends on.
Encryption Key Management
Provision, scope, rotate, and revoke the per-device keys this chapter assumes are already in place.
TLS and DTLS
Watch symmetric AEAD protect a real session after a handshake negotiates the keys and identity.