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.
- Firmware means software stored on a device.
- A gateway means the bridge between local devices and a wider network.
- A payload means the useful data inside one message.
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.
- If the payload must stay protected past an intermediary, choose object security for the message.
Major section
Practitioner: Match Each Path to a Mechanism (continued)
Walkthrough: From Paths to ControlsFollow the sequence from decision to evidence.
- A secure channel to the wrong party, or one that accepts an old message, still fails.
- The Protocol-Fit LedgerPath.
- DTLS when the endpoint session itself is the protection boundary.
- Every executable update path must be signed, version-checked, and recoverable.
Major section
Practitioner: Match Each Path to a Mechanism (continued)
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.
- 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.
Major section
Practitioner: Match Each Path to a Mechanism (continued)
A VPN or IPsec tunnel with allow-listed peers, route control, and logging.
- Replay handling on the UDP path and anti-rollback on the local recovery update path are not tested.
- ConclusionAccept 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.
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 DTLSSession 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 MessageObject 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.
Major section
Summary · Key Takeaway
Session security (TLS over TCP, DTLS over UDP) protects a connection between two endpoints; an intermediary that terminates it sees plaintext, so it is hop-by-hop.
- Object security (COSE, and OSCORE for CoAP) protects the message itself, so it stays protected end-to-end past brokers and proxies.
- The central decision: a payload that must stay confidential past a broker needs object security, not just TLS to the broker.
- A VPN or IPsec tunnel protects a network path between gateways or sites but still terminates at the tunnel endpoints, where identity and authorization are still required.
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 ControlsFollow the sequence from decision to evidence.
- Trying to run TLS over UDP, or omitting replay and reconnect behaviour from testing.
- A VPN or IPsec tunnel with allow-listed peers, route control, and logging.
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: C 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: C 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: D Forward secrecy comes from fresh ephemeral key agreement each session.
Print reference
Answers
Answer key.
- C · Session security protects the connection up to the endpoint that terminates it.
- C · The boundary is the message, not the link.
- D · Forward secrecy comes from fresh ephemeral key agreement each session.