Cryptography · Study deck
Secure Communication and Firmware
Picture a door sensor sending an alarm through a building bridge to a phone.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: Object Security: Protecting the Message Object security protects the message itself, independent of the transport, so it stays protected across stores, queues, brokers, and proxies until it reaches the true recipient.
- Explain: In both, protection ends at each endpoint: when a broker, proxy, or gateway terminates the session, it holds the plaintext and can read or change it before forwarding.
- Explain: The practical workflow turns a set of communication paths into a boundary, a mechanism, and an identity and freshness plan, then proves the choice with negative tests.
- Match TLS DTLS tunnels and object security to paths
Major section
Start With the Protection Boundary · Overview: Secure Communication Is a Boundary Decision
Hiding the radio signal is not enough if a middle service can read, change, or repeat the alarm without the owner knowing.
- A protocol means shared rules for an exchange.
- Firmware means software stored on a device.
- A gateway means the bridge between local devices and a wider network.
Major section
Practitioner: Match Each Path to a Mechanism
The practical workflow turns a set of communication paths into a boundary, a mechanism, and an identity and freshness plan, then proves the choice with negative tests.
- The common failure is naming a protocol before naming the boundary, which leads to session security where the data really needs to survive an intermediary.
Major section
Practitioner: Match Each Path to a Mechanism (continued)
Walkthrough: From Paths to Controls Follow the sequence from decision to evidence.
- If the payload must stay protected past an intermediary, choose object security for the message.
- A secure channel to the wrong party, or one that accepts an old message, still fails.
- The Protocol-Fit Ledger Path.
Major section
Practitioner: Match Each Path to a Mechanism (continued)
DTLS when the endpoint session itself is the protection boundary.
- Trying to run TLS over UDP, or omitting replay and reconnect behaviour from testing.
- Object security such as COSE, or OSCORE for CoAP, when intermediaries must not read or change the payload.
- Every executable update path must be signed, version-checked, and recoverable.
Major section
Practitioner: Match Each Path to a Mechanism (continued)
Assuming transport security still protects the payload after a broker or proxy terminates the session.
- The claim under review is: the readings are end-to-end secure and the updates are safe.
- Both links are encrypted and authenticated to their next endpoint.
- Replay handling on the UDP path and anti-rollback on the local recovery update path are not tested.
Major section
Practitioner: Match Each Path to a Mechanism (continued)
Conclusion Accept only the hop-by-hop claim: each link is protected to its next endpoint.
- For confidentiality past the broker, require object security on the payload, and hold the firmware claim until recovery-path signing and anti-rollback are tested.
- If you can assign each path a boundary and a mechanism and scope the claim to the evidence, you can stop here.
- A VPN or IPsec tunnel with allow-listed peers, route control, and logging.
Major section
Under the Hood: Mechanisms, Boundaries, and Failure Modes
The deeper layer explains why session security, object security, network tunnels, and signed firmware are different guarantees.
- The difference comes down to where decryption happens and which intermediaries are trusted, and each control still depends on identity, freshness, and key custody to mean anything.
- Intermediaries can act only on what remains readable.
Major section
Under the Hood: Mechanisms, Boundaries, and Failure Modes (continued)
A securely encrypted channel to the wrong party is still a channel to an attacker.
- Session Security: TLS and DTLS Session security authenticates two endpoints and protects the connection between exactly those two.
- Endpoint identity and authorization are still required inside the tunnel.
- Proof that an image is authorized for the device.
Major section
Under the Hood: Mechanisms, Boundaries, and Failure Modes (continued)
In both, protection ends at each endpoint: when a broker, proxy, or gateway terminates the session, it holds the plaintext and can read or change it before forwarding.
- Object Security: Protecting the Message Object security protects the message itself, independent of the transport, so it stays protected across stores, queues, brokers, and proxies until it reaches the true recipient.
- In constrained IoT the standard building block is COSE (CBOR Object Signing and Encryption), and OSCORE applies object security to CoAP.
- Object security is end-to-end.: The message stays protected past intermediaries, but the true endpoints must manage keys between them.
Major section
Under the Hood: Mechanisms, Boundaries, and Failure Modes (continued)
Because protection is bound to the object, an intermediary can route or store the message without being able to read or silently alter the protected parts.
- Fields an intermediary genuinely needs, such as routing headers, can be left readable but integrity-protected, much like the associated data of an authenticated-encryption scheme.
- Session security is hop-by-hop.: It is strong for a direct endpoint-to-endpoint connection, but protection resets at every intermediary that terminates the session.
- A VPN or IPsec tunnel is a network-layer hop.: It protects traffic between gateways or sites, but terminates at the tunnel endpoints.
Major section
Under the Hood: Mechanisms, Boundaries, and Failure Modes (continued)
Authentication.: The device must validate the peer identity (certificate, raw public key, or PSK) and the expected name.
- Freshness.: A correctly authenticated old message can still be replayed unless the protocol adds a sequence number, counter, or replay window.
- A later compromise of a long-term key does not expose traffic from past sessions.
- A standard manifest approach for constrained devices is SUIT, named here only as the recognised model.
Major section
Under the Hood: Mechanisms, Boundaries, and Failure Modes (continued)
The signing private key stays off-device, in a controlled signing service, so a compromised device cannot forge an accepted update.
- At each session endpoint; a broker or proxy that terminates it sees plaintext.
- Assuming it protects data past the endpoint that terminates the session.
- Running TLS over UDP, or skipping replay, reorder, and reset tests.
- A trustworthy review records where protection ends, not just that the traffic is encrypted.
Deck summary
Key takeaways
Hiding the radio signal is not enough if a middle service can read, change, or repeat the alarm without the owner knowing.
- The practical workflow turns a set of communication paths into a boundary, a mechanism, and an identity and freshness plan, then proves the choice with negative tests.
- Walkthrough: From Paths to Controls Follow the sequence from decision to evidence.
- DTLS when the endpoint session itself is the protection boundary.
- Assuming transport security still protects the payload after a broker or proxy terminates the session.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1A vendor says sensor readings are end-to-end secure because each device uses TLS to the cloud message broker, which then forwards the readings to other services. What is the strongest correction?
Show answer
Answer: A Session security protects the connection up to the endpoint that terminates it.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2Telemetry must stay confidential from the cloud message broker, which only needs to route it. The team secures every device-to-broker link with TLS. What is the correct review conclusion?
Show answer
Answer: B The boundary is the message, not the link.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3A device uses a fixed long-term key to derive the same session key for every TLS connection, to save computation. Years of recorded ciphertext are later exposed when that long-term key leaks. Why is this worse than a design that uses ephemeral key agreement per session?
Show answer
Answer: A Forward secrecy comes from fresh ephemeral key agreement each session.
Print reference
Answers
Answer key.
- A · Session security protects the connection up to the endpoint that terminates it.
- B · The boundary is the message, not the link.
- A · Forward secrecy comes from fresh ephemeral key agreement each session.