6 Symmetric Encryption for IoT
Shared Keys, AEAD Modes, Nonces, and Verify-Before-Use
IoT symmetric encryption, AES-GCM, AEAD nonce, authenticated encryption, shared key distribution, ChaCha20-Poly1305, verify before use
6.1 Start Simple
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.
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.
The One-Minute View
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.
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.
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.
Beginner Examples
- 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, but a single extracted device then exposes every device in that scope. Per-device keys contain the damage.
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.
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.
Walkthrough: From Boundary to Verified Plaintext
- 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.
- 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.
- 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.
- 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.
- Verify before use. Confirm the receiver checks the authentication tag, and any freshness value, before it parses, routes, logs, or acts on the plaintext.
- Plan key distribution and lifecycle. Show how the shared key is established without sending it in the clear, kept per device, rotated, and revoked.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Common Pitfalls
- 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.
- Using ECB for real data. Identical plaintext blocks produce identical ciphertext blocks, leaking structure. Never use ECB for confidentiality.
- Encrypting without authenticating. CBC and CTR hide data but do not detect tampering; pair them with encrypt-then-MAC or, better, use AEAD.
- Reusing a nonce. A repeated nonce under the same key breaks a counter-based AEAD, including after a careless reboot counter reset.
- Acting before verifying. Parsing, routing, or executing decrypted bytes before the tag is checked defeats the integrity guarantee.
- Claiming non-repudiation from a shared key. A shared key cannot prove which party acted; that needs an asymmetric signature.
- 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.
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.2 Summary
- Symmetric encryption uses one shared secret key for both encryption and decryption; it is fast and is the workhorse for bulk IoT traffic.
- 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.
- 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.
- Prefer AEAD such as AES-GCM, AES-CCM, or ChaCha20-Poly1305: confidentiality plus integrity and authenticity of the ciphertext, and authentication of associated data.
- 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.
- Symmetric encryption needs secure key establishment, so real systems pair it with an asymmetric or hybrid setup, per-device keys, rotation, and revocation.
- A shared key gives confidentiality, integrity, and authenticity, but not non-repudiation, because it cannot prove which party produced a message.
- 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.3 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.