Cryptography · Study deck
Why Cryptography Matters for IoT
Picture a remote command crossing a site bridge before it opens a valve.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
Turn a security claim into a named job, a boundary, and a failure test.
- Confidentiality, integrity, authentication, and freshness have different security jobs.The valve command needs a decision about each property instead of assuming that encryption alone establishes safe acceptance.
- The required message property determines the appropriate primitive.A public firmware image can need a signature for origin while remaining readable to anyone who downloads the artifact.
- The plaintext boundary identifies who may read decrypted data.An authorised gateway may terminate a protected link, while an end-to-end payload can remain opaque through the same forwarding point.
- Nonce handling, key ownership, and negative tests need recorded evidence.Changed packets, wrong senders, replayed commands, and receiver restart must fail safely before the valve can act on missing proof.
Major section
Start With the Job, Not the Cipher
Before a valve moves, verify more than the presence of encryption.
- A private command can still lack integrity, sender proof, or freshness.The statement that encryption is present does not establish whether the valve should trust this controller or this copy of the command.
- Each unwanted case needs a control that rejects acceptance.The review must challenge changed, copied, replayed, expired, and wrong-sender commands instead of stopping at a successful encrypted exchange.
- Receiver restart tests must challenge saved state and freshness.A restarted device can expose counter-reset or replay behaviour that was absent while the command channel ran continuously.
- Missing proof requires the defined local safe state.The actuator must not turn an unverified command into physical action simply because the channel carries ciphertext.
Major section
Four jobs behind command acceptance
Separate the security properties before combining their controls.
- Confidentiality keeps the protected message unreadable to excluded readers.The review still needs a named plaintext boundary because an authorised gateway may read data after terminating a protected link.
- Integrity lets the receiver detect a changed message.A temperature value altered in transit can trigger a false alarm even when the original sensor reading was useful.
- Authentication establishes the sender identity needed by the receiver.The command path must know which controller may issue an instruction rather than accepting any endpoint that answers.
- Freshness prevents acceptance of an old valid message as new.A previously authenticated valve command can still verify unless a sequence number, counter, or replay window rejects the old delivery.
Major section
The parcel’s four protective features
The parcel analogy assigns a different job to each protective feature.
- The locked box is the confidentiality part of the parcel analogy.Its purpose is private contents, leaving tamper evidence, sender proof, and an old delivery’s rejection to other controls.
- The tamper-evident seal is the integrity check.The seal can reveal unwanted opening or change, which is a different promise from hiding the contents inside the box.
- The sender’s signature is the authentication part of the analogy.The chapter uses this mark to represent proof of who prepared the parcel rather than proof that nobody can read the contents.
- The dated single-use label is the freshness control.The label must prevent the same parcel from being resent later, just as an old valid command needs explicit replay rejection.
Major section
Temperature telemetry needs a property-by-property review
The required protection depends on the consequences of each message path.
- Temperature telemetry may need confidentiality when it reveals occupancy.The review must identify who may read the measurement rather than treating all telemetry as harmless public data.
- A changed temperature value can require integrity protection.An altered measurement can trigger a false alarm, so secrecy alone does not establish that the reported value remained unchanged.
- The receiver must know which sensor supplied the reading.Authentication is needed when the cloud’s trust in the report depends on the identity of its source.
- Replayed readings need freshness checks despite valid original authentication.An old reading can be resent during an outage, so a valid sender proof does not establish a current measurement.
Major section
Readable firmware and the limits of an AES claim
An algorithm name leaves the mode, keys, and readable-data boundary unresolved.
- A readable firmware image can still have a valid origin signature.Signing establishes a different property from secrecy, so public access to the image does not remove the need to verify its origin.
- Encryption without tamper detection can leave an integrity gap.The chapter’s encrypted telemetry example can hide data while still failing to detect a changed message.
- The gateway’s decryption role and key owner need documentation.A protected link can legitimately expose plaintext at an authorised gateway, while another design withholds the inner-payload key.
- An AES claim still needs a mode and nonce plan.The cipher name alone does not establish the protection boundary, who holds the keys, or which negative tests the design passes.
Major section
Match Primitives and Build the Hybrid Channel
Follow peer authentication through shared-secret derivation to protected traffic and key retirement.
- Peer authentication must precede trust in the key-establishment result.The first stage needs the device, gateway, or service identity checked before its shared-secret material can support a protected channel.
- ECDH or approved provisioning supplies material for HKDF-scoped keys.The derivation stage must bind separate traffic keys to protocol, role, direction, and session context rather than reusing one key across purposes.
- AEAD protects traffic with nonce and tag checks.Telemetry, commands, and updates need authenticated record protection after identity and key setup have prepared the channel.
- The lifecycle branch requires rekey, revocation, recovery, and retirement evidence.A channel review must show key rollover and compromised-credential handling instead of ending at the first successful protected record.
Major section
What each primitive can establish
Choose a primitive by its promise and by what it leaves unproved.
- Encryption can hide content within its defined boundary.It does not establish tamper rejection or sender proof unless the chosen mode also provides authentication.
- AEAD provides confidentiality and tamper rejection for protected traffic.The ciphertext and associated data need verification, while identity still depends on how the keys or certificates are bound to peers.
- A bare hash cannot establish who sent a message.Anyone can recompute the digest, so an unkeyed fingerprint needs a keyed MAC or signature when origin matters.
- HMAC and signatures can authenticate data that remains readable.A signature supports public verification, while an HMAC establishes possession of a shared key without providing confidentiality.
Activity 1 · Match
✎ Choose the primitive by its job
I want you to match each tool to the promise it can actually support.
On paper, match encryption, AEAD, hash, HMAC, and signature to: public verification; shared-key sender proof; unreadable content; an unkeyed fingerprint; private traffic with tamper rejection.
3 minutes · Pen and paper · Answer: Activity 1
Major section
Authenticated setup and keys with one purpose
Key setup prepares protection; traffic still needs an authenticated mode.
- Peers need authentication before their shared-secret material is trusted.An answering gateway or service endpoint must not gain trust merely by participating in a key exchange.
- Approved agreement or provisioning can establish the secret material.The setup must avoid sending reusable keys inside messages and still needs a secure mode to protect later traffic.
- Derived traffic keys need protocol, role, direction, and session context.Labels and context keep a key for one purpose from being confused with another within the channel.
- The lifecycle record needs tested rollover and credential revocation.The channel must limit key lifetime and retire compromised credentials rather than assuming the original setup remains acceptable forever.
Major section
Firmware acceptance and command freshness
Firmware protection and command protection require different acceptance checks.
- Firmware needs signatures over metadata and image bytes before installation.Verification must also precede boot, so a signed download channel alone cannot establish trust in the executable artifact.
- Update, rollback, and recovery paths need the same acceptance policy.Every executable update path must have signature validation, a version policy, and recovery behaviour rather than an unsigned bypass.
- A command channel needs authenticated sender identity and tamper rejection.The building sensor’s proposed encrypted messages do not by themselves prove who may issue a configuration command.
- Freshness checks must prevent old commands becoming new physical actions.A correctly authenticated command can be replayed unless the receiver has a sequence number, counter, or replay window.
Major section
Identity anchors and separate key responsibilities
Turn the threat-to-control map into tests for each message path.
- AEAD requires nonce uniqueness per key and tag verification before use.A modified command must fail before the device releases plaintext or turns its contents into an action.
- Gateway and service identities need a documented trust anchor.The chapter also requires renewal and recovery planning instead of trusting any endpoint that answers the device.
- A keyed MAC supports shared-key possession checks on readable data.An unkeyed hash cannot establish that the sender held the secret required by this integrity-without-secrecy path.
- Password storage, session derivation, and device identity are separate responsibilities.Hashing a password once must not silently turn that result into a long-term device key.
Major section
The encrypted command proposal’s missing checks
Review the proposed encrypted sensor-command channel against the claims it still needs.
- Encryption can hide the command body within the protected boundary.An observer on the link or broker may be excluded from the contents, but that does not complete the command acceptance policy.
- Sender authentication must establish the authorised command source.The channel needs evidence about which controller may configure the building sensor rather than only a ciphertext capture.
- Changed commands must fail verification before the device acts.Confidentiality alone cannot establish tamper rejection, so the receiver needs an authenticated acceptance check.
- Replayed commands need freshness rejection and a key-lifecycle plan.The review must include old-command tests and compromised-credential handling before the proposed channel can be accepted.
Major section
Boundaries, AEAD, and Failure Modes
Compare gateway access in the first two models, then inspect readable signed firmware.
- Hop-by-hop protection permits an authorised gateway to decrypt and re-protect data.The first model deliberately terminates separate protected links, allowing the gateway to process plaintext for its named role.
- End-to-end payload protection keeps inner ciphertext opaque through the gateway.The second model withholds the inner-payload key even when outer transport protection may terminate on individual hops.
- Signed firmware remains readable while the device checks acceptance.The third model needs signer and digest, target and model, and anti-rollback checks before installation rather than confidentiality.
- Every model needs data, trust, key, and evidence boundaries.The comparison must establish who may read, modify, forward, decrypt, sign, and publish evidence without leaking secrets.
Major section
AEAD verification and unique nonces
AEAD needs correct tag handling and a nonce plan that survives device operation.
- Tag verification must precede plaintext release or action.A failed authentication tag requires rejection, because acting on unverified contents would restore the tampering risk.
- Associated data is readable but protected against undetected change.Headers or routing fields can remain visible while AEAD authenticates the fields that must not be altered.
- A nonce must never repeat under the same AEAD key.The device’s nonce plan needs reboot and counter-reset tests so continuous operation does not hide a later reuse failure.
- AES-GCM nonce reuse can expose relationships and enable forged tags.Repeating the nonce with the same key can break confidentiality and integrity, so a successful ordinary exchange is insufficient evidence.
Major section
Freshness, shared-key proof, and public verification
Valid authentication does not establish that a command is current.
- An old authenticated command can remain valid without freshness checks.The receiver must reject replay through a sequence number, counter, or replay window instead of treating tag validity as current intent.
- A counter or replay window supplies a separate acceptance control.Restart testing must show that saved or reset state does not let an old valve command become a new physical action.
- An HMAC establishes shared-key possession without identifying which holder signed.Either shared-key holder can produce the tag, so the pair cannot prove to a third party which one created the message.
- A digital signature supports verification through the matching public key.Only the private-key holder can create a valid signature, which supports public verification beyond the shared-key MAC’s promise.
Activity 2 · Predict
✎ Replay a valid command
I want you to predict what a valid tag leaves unanswered.
On paper, replay an old authenticated valve command. Predict the result if the receiver checks only its tag. Add a freshness control, then name the restart test needed for that control.
3 minutes · Pen and paper · Answer: Activity 2
Major section
Session keys, reboot tests, and lifecycle evidence
Keep a release record connecting the security objective to failure tests and key management.
- Fresh ephemeral session keys can protect past traffic after later compromise.The chapter’s forward-secrecy case prevents a later long-term key compromise from exposing earlier session traffic.
- Separate derived keys need labels and context for their purposes.HKDF can scope the shared material so a key for one direction or job is not confused with another.
- Reboot tests must challenge nonce reuse, replay, and counter reset.A continuously running device can hide acceptance failures that appear only when saved or reset state is used after restart.
- Provisioning, per-device keys, rotation, and revocation need concrete evidence.A leaked credential needs a tested retirement path in the field rather than a plan that requires reflashing every affected device.
Deck summary
Key takeaways
A reviewable security claim names the protection, its boundary, and evidence of rejection.
- The message’s required properties must guide primitive selection.The command path needs separate confidentiality, integrity, sender, and freshness decisions before a named cipher can support its review.
- The review needs plaintext boundaries and named key owners.A gateway may be authorised to decrypt a link while an end-to-end design keeps the inner payload opaque through the same boundary.
- Tag verification must precede use, with nonce uniqueness per key.Failed tags require rejection, and reboot testing must show that saved or reset state does not repeat a nonce under the same key.
- Release evidence needs negative tests and a tested key lifecycle.Replay, wrong peers, changed messages, and compromised credentials must have recorded rejection or recovery behaviour before field acceptance.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1A vendor says "our device uses AES, so the data is secure." What is the strongest correction?
Show answer
Answer: C Naming AES is not a security claim.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A team says its device commands are safe because the payload is encrypted, but gateway logs show old encrypted command packets can still be replayed successfully. What is the correct review conclusion?
Show answer
Answer: A The design fails because hiding the command body does not stop an old valid message from being reused.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3A constrained device reuses the same nonce with the same key for two AES-GCM messages to save state. Why is this a serious failure rather than a minor optimization?
Show answer
Answer: A Counter-based AEAD modes such as GCM require a unique nonce per key.
Print reference
Answers
Answer key.
- C · Naming AES is not a security claim.
- A · The design fails because hiding the command body does not stop an old valid message from being reused.
- A · Counter-based AEAD modes such as GCM require a unique nonce per key.
Print reference
Activity 1 answer
Model answer.
Match: Encryption: unreadable content. AEAD: private traffic with tamper rejection. Hash: an unkeyed fingerprint. HMAC: shared-key sender proof. Signature: public verification. None of these matches alone establishes a complete replay policy.
Print reference
Activity 2 answer
Model answer.
Predict: The old tag can verify, allowing the command to be accepted again without freshness checks. Add a sequence number, counter, or replay window. Restart the receiver and test that saved or reset state does not allow old commands or reuse nonces under the same key.