Cryptography · Study deck
Symmetric Encryption for IoT
Picture a water pump receiving a private command from a field controller.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: 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.
- Explain: 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.
- Explain: The receiver recomputes the tag and must reject the message if it does not match, before using any plaintext or any associated data.
Major section
Start Simple · Overview: One Shared Key for Both Directions
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.
Major section
Practitioner: Choose a Mode and Protect a Channel
Leaks structure and repeated patterns; never use it for confidentiality.
- 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.
- Mode selection is a security decision, not a naming preference.
- CTR provides no tamper detection.
Major section
Practitioner: Choose a Mode and Protect a Channel (continued)
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.
- Nonce reuse under one key is catastrophic; it needs a proven unique-nonce rule.
- General IoT traffic where the platform or profile supports GCM and nonce uniqueness can be proven.
- Constrained or link-layer IoT profiles, including shortened-tag variants the profile defines.
Major section
Practitioner: Choose a Mode and Protect a Channel (continued)
If you can pick an authenticated mode and defend its nonce and key plan, you can stop here.
- Nonce format, length limits, and tag length are profile-specific and must be documented, not guessed.
- Legacy profiles that cannot change yet; add authentication and plan migration to AEAD.
- Confidentiality alone is not enough.
Major section
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.
- 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.
- Integrity detects modification.
Major section
Under the Hood: Block Cipher, Modes, and Failure Modes (continued)
AES was standardized from the Rijndael design and is the modern default block cipher for most new symmetric-encryption reviews.
- CBC and CTR remove that pattern but still provide confidentiality only.
- A short worked pass shows the mechanics on a toy 32-bit block.
- The key size determines how many rounds run.
Major section
Under the Hood: Block Cipher, Modes, and Failure Modes (continued)
These properties are distinct.
- 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.
- Key use also has an operating limit.
- Unverified plaintext never affects system state.
Major section
Under the Hood: Block Cipher, Modes, and Failure Modes (continued)
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.
- 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.
- Symmetric keys also do not carry rich use policy by themselves.
Major section
Under the Hood: Block Cipher, Modes, and Failure Modes (continued)
Non-repudiation needs an asymmetric digital signature, where only one party holds the private key.
- Splitting the plaintext 0xAABBCCDD gives a left half of 0xAABB and a right half of 0xCCDD.
- 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.
- A confidentiality-only mode protects commands while tampering is accepted silently.
Major section
Under the Hood: Block Cipher, Modes, and Failure Modes (continued)
The receiver recomputes the tag and must reject the message if it does not match, before using any plaintext or any associated data.
- Associated data is authenticated but not encrypted, so it stays visible while it cannot be silently changed.
- AES-GCM commonly uses a 96-bit (12-byte) nonce as its standard, most efficient choice.
- Mode profile, tag length, and a test that rejects modified ciphertext and modified associated data.
Major section
Under the Hood: Block Cipher, Modes, and Failure Modes (continued)
Hand-built compositions are easy to get wrong, so a modern design prefers a reviewed AEAD instead.
- 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.
- 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.
- Symmetric encryption also assumes both sides already share the key, but it does not solve how the key arrived.
Major section
Under the Hood: Block Cipher, Modes, and Failure Modes (continued)
Keys should be per device, or derived from per-device material, and they should be rotatable and revocable.
- 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.
- One key and nonce pair is never reused, so keystreams never repeat.
- Nonce construction plus negative tests across reboot, retry, and counter rollover.
Major section
Under the Hood: Block Cipher, Modes, and Failure Modes (continued)
A reused nonce leaks plaintext relationships and can enable tag forgery in GCM.
- 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.
- 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 reject-before-parse test on a modified tag, wrong key, and wrong associated data.
Deck summary
Key takeaways
Hiding the command is not enough; the pump must also reject a changed or repeated command.
- Leaks structure and repeated patterns; never use it for confidentiality.
- 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.
- If you can pick an authenticated mode and defend its nonce and key plan, you can stop here.
- The deeper layer explains why the workflow separates the cipher, the mode, the nonce, and the key.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1A vendor says a sensor 'encrypts its data with a shared key, so the readings are safe.' What is the strongest correction?
Show answer
Answer: A A shared key alone does not say whether tampering is detected or whether nonces repeat.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A device protects gateway commands with AES-GCM, but on every reboot it resets the message nonce counter to zero while keeping the same key. Why is this unsafe?
Show answer
Answer: B GCM requires a unique nonce per key.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3Two AES-GCM messages are sent under the same key with the same nonce to save state on a constrained device. Beyond leaking the relationship between the two plaintexts, what is the additional consequence specific to GCM?
Show answer
Answer: C GCM's authentication relies on a per-key secret used in the tag computation.
Print reference
Answers
Answer key.
- A · A shared key alone does not say whether tampering is detected or whether nonces repeat.
- B · GCM requires a unique nonce per key.
- C · GCM's authentication relies on a per-key secret used in the tag computation.