16 Secure Communication and Firmware

Session vs Object Security, Update Trust, and Boundary Evidence

security

cryptography

iot

Keywords

IoT secure communications, session vs object security, end-to-end vs hop-by-hop, TLS DTLS IoT, object security OSCORE COSE, signed firmware update, anti-rollback

16.1 Start With the Protection Boundary

Imagine a sensor reading that leaves a device, crosses a gateway, lands in a broker, and triggers a cloud rule. Saying “the link is encrypted” is not enough. A reviewer still needs to know where plaintext appears, which intermediary is trusted, and whether the same evidence would protect a signed firmware image before the device installs it.

This chapter follows that one question through the whole route: name the boundary, choose session or object protection, then prove the firmware and message paths fail closed when the wrong party, stale version, or modified payload appears.

Overview: Secure Communication Is a Boundary Decision

Secure communication protects messages as they travel between the parts of an IoT system: a sensor, a gateway, a message broker, and a cloud service. The first question is not which protocol to enable. It is how far the protection must reach, and who is allowed to read the data along the way.

Two protection styles answer that question. Session security protects a connection between two endpoints, so the data is safe only along that hop. Object security protects the message itself, so it stays protected end-to-end even when it passes through intermediaries. Firmware updates are a special case of the same idea: the message is code, and the device must verify it is authorized before running it.

If you only need the intuition, this layer is enough: name the boundary first. Decide how far protection must travel and who may read the data on the way. Session security protects one hop; object security protects the message end-to-end; and the network path is never enough on its own to trust a firmware update.

Think of mailing a letter through a sorting centre. An armoured van between two post offices protects the mailbag only while it rides that van; at the sorting centre the bag is opened and re-bagged, and the staff there can read every letter. That is session security: safe for one hop, exposed at the intermediary. A sealed, signed envelope inside the bag stays sealed through every van and every sorting centre until the addressee opens it. That is object security: protected end-to-end. If a letter must stay private past the sorting centre, it needs the sealed envelope, not just an armoured van to the centre.

Secure communications start by naming the boundary: how far protection must travel and which intermediaries sit in the middle.

The One-Minute View

Name the boundary first

Decide how far protection must travel, one hop or end-to-end, and who may read the data along the way, before naming any protocol.

Session security protects a hop

TLS over TCP and DTLS over UDP protect a connection between two endpoints. A broker or proxy that terminates the session still sees plaintext.

Object and signed code travel further

To keep a payload protected past an intermediary, protect the message itself. For firmware, the device must verify a signed image, not trust the delivery path.

Beginner Examples

A device that uses TLS to a message broker has a private link to the broker, but the broker still reads every message in plaintext. That is hop-by-hop protection, not end-to-end.
A firmware download over HTTPS proves the link to the server, not that the firmware is authorized. The device still has to verify a signature before it installs the image.
"The connection is encrypted" is not a claim a reviewer can accept. Encryption to the wrong endpoint, or only as far as the broker, may not be the protection the data actually needs.

Overview Knowledge Check

If you can explain the difference between protecting a single hop and protecting a message end-to-end, you can stop here. Continue to Practitioner to match each path to a mechanism and review a real fleet.

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.

Walkthrough: From Paths to Controls

List the communication paths. Enumerate every path: device-to-gateway telemetry, command and control, gateway-to-cloud, technician or remote access, and firmware update.
Name the boundary for each path. Decide how far protection must travel and which intermediaries, brokers, proxies, or gateways, sit in the middle and might terminate the session.
Decide session or object. If protection only needs to reach the next endpoint, session security fits. If the payload must stay protected past an intermediary, choose object security for the message.
Pick the transport mechanism. TCP sessions take TLS; UDP sessions take DTLS; messages through brokers take object security (COSE, and OSCORE for CoAP); gateway or site paths take a VPN or IPsec tunnel, with endpoint identity still checked inside it.
Pin identity and freshness, not just encryption. Validate the peer identity (certificate, raw public key, or PSK) and add replay protection. A secure channel to the wrong party, or one that accepts an old message, still fails.
Treat firmware as a signed object. Distribute a signed manifest and image; the device verifies the signature before install, and before boot where supported, with anti-rollback and a verified recovery path. Then define key rotation, revocation owners, and the negative tests that prove bad inputs are rejected.

Match the mechanism to the communication path and its intermediaries, not to the application protocol name alone.

The Protocol-Fit Ledger

Path

Common Fit

Failure Mode

Decision Rule

MQTT or HTTPS over TCP

TLS with peer-identity validation, a current cipher-suite policy, and credential rotation.

Disabling validation, trusting the wrong hostname, or shipping a test trust anchor.

Do not approve until the device rejects a wrong certificate, wrong name, expired credential, and untrusted issuer.

CoAP or LwM2M over UDP

DTLS when the endpoint session itself is the protection boundary.

Trying to run TLS over UDP, or omitting replay and reconnect behaviour from testing.

Use a datagram-aware stack and test loss, reordering, reset, replay, and credential renewal.

Messages through a broker or proxy

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.

Protect the object itself when the message must stay trusted beyond one hop.

Gateway or site network path

A VPN or IPsec tunnel with allow-listed peers, route control, and logging.

Using the tunnel as a substitute for device identity, broker authentication, or least-privilege access.

Protect the network path, then still authenticate the application endpoints inside the tunnel.

Firmware update package

A signed manifest and image verified on the device, with anti-rollback and recovery behaviour.

Trusting HTTPS or VPN delivery alone, or signing only the main path while recovery stays unsigned.

Every executable update path must be signed, version-checked, and recoverable.

Worked Review: A Facilities Sensor Fleet

Wireless sensors reach a local gateway over a constrained UDP protocol; the gateway publishes MQTT to a cloud broker, which forwards readings to analytics services; firmware can be delivered from the cloud or from local recovery media. The claim under review is: the readings are end-to-end secure and the updates are safe.

What the evidence covers

DTLS protects the sensor-to-gateway hop; TLS protects the gateway-to-broker hop; the gateway validates the broker identity. Both links are encrypted and authenticated to their next endpoint.

What the evidence misses

The broker terminates TLS and forwards readings in plaintext to analytics, so the end-to-end claim is unproven. Replay handling on the UDP path and anti-rollback on the local recovery update path are not tested.

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.

Practitioner Knowledge Check

If you can assign each path a boundary and a mechanism and scope the claim to the evidence, you can stop here. Continue to Under the Hood for the mechanisms that make session, object, and update security different guarantees.

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.

Session Security: TLS and DTLS

Session security authenticates two endpoints and protects the connection between exactly those two. TLS runs over a reliable stream transport such as TCP. DTLS adapts the same handshake and record idea to datagram transports such as UDP, where it must tolerate loss, reordering, and retransmission that TCP would otherwise handle. 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. This is what makes session security hop-by-hop.

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. 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. These are named here as the standard approaches; the point is the boundary they move, not implementation detail.

Hop-by-Hop Versus End-to-End

The central design decision restates cleanly at the mechanism level:

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.
Object security is end-to-end. The message stays protected past intermediaries; the cost is managing keys between the true endpoints and accepting that intermediaries can act only on whatever is left readable.
A VPN or IPsec tunnel is a network-layer hop. It protects traffic between gateways or sites, but still terminates at the tunnel endpoints, so endpoint identity and authorization are still required inside the tunnel.

Identity, Freshness, and Forward Secrecy

Encryption is not the same as identity, and a secure channel still needs three guarantees kept distinct from confidentiality:

Authentication. The device must validate the peer identity (certificate, raw public key, or PSK) and the expected name. A securely encrypted channel to the wrong party is still a channel to an attacker.
Freshness. A correctly authenticated old message can still be replayed unless the protocol adds a sequence number, counter, or replay window.
Forward secrecy. Ephemeral key agreement (ECDHE) gives a fresh per-session key, so a later compromise of a long-term key does not expose traffic from past sessions.

Confidentiality, integrity, authenticity, and freshness are separate jobs; a channel can provide some and not others, and a review should say which.

Firmware Update Trust

A firmware update is a command to run new code, and the channel that delivers it does not authorize it. The release process distributes a signed manifest and image; the device verifies the signature with public key material before install, and before boot where the platform supports it. The signing private key stays off-device, in a controlled signing service, so a compromised device cannot forge an accepted update. Anti-rollback rejects older but still validly signed versions, typically through a monotonic security version, so a downgrade cannot reopen a fixed weakness, while a verified recovery path lets a failed update fall back without an unsafe bypass. A standard manifest approach for constrained devices is SUIT, named here only as the recognised model.

Firmware trust is enforced as a chain of trust: each boot stage cryptographically verifies the next, from the hardware root of trust through the signed kernel, with anti-rollback protection.

Mechanisms and Where Protection Ends

Mechanism

What It Protects

Where Protection Ends

Failure Mode If Weak

TLS (session, TCP)

The connection between two authenticated endpoints.

At each session endpoint; a broker or proxy that terminates it sees plaintext.

Assuming it protects data past the endpoint that terminates the session.

DTLS (session, UDP)

The same protection adapted for datagram transports.

At each session endpoint, like TLS.

Running TLS over UDP, or skipping replay, reorder, and reset tests.

Object security (COSE, OSCORE)

The message itself, end-to-end, independent of transport.

Only at the true sender and recipient.

Leaving sensitive fields outside the protected object, or weak key management between endpoints.

VPN or IPsec tunnel

Traffic across a network path between gateways or sites.

At the tunnel endpoints.

Treating tunnel membership as device identity or authorization.

Signed firmware

Proof that an image is authorized for the device.

Holds only while the private key stays off-device and every path is signed.

Trusting the delivery path, an on-device private key, no anti-rollback, or an unverified recovery image.

Common Pitfalls

Treating session security as end-to-end. TLS and DTLS protect a hop; a broker that terminates the session reads plaintext, so the payload is not protected past it.
Encrypting without authenticating identity. A secure channel to an unverified peer can be a secure channel to an attacker.
Forgetting freshness. An authenticated message can still be replayed without a counter, sequence number, or replay window.
Trusting the network path for firmware. HTTPS or VPN delivery does not replace device-side signature, version, and recovery checks.
Signing one update path only. Local recovery, factory, and alternate-slot images must follow the same signing and anti-rollback rules.

Under-the-Hood Knowledge Check

At this depth, secure communication is a set of independent guarantees chosen by how far protection must travel: session security for a single hop, object security for messages that cross intermediaries, a network tunnel for path access, and signed firmware for code that must be authorized before it runs. Each is only as strong as the endpoint identity, freshness, forward secrecy, and key custody behind it. A trustworthy review records where protection ends, not just that the traffic is encrypted.

16.2 Summary

Secure communication is a boundary decision: name how far protection must travel, and who may read the data on the way, before naming a protocol.
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.
A secure channel still needs authenticated identity and replay protection; forward secrecy from ephemeral key agreement protects past sessions if a long-term key later leaks.
Firmware updates need a signed manifest and image the device verifies before install, and before boot where supported, with anti-rollback and a verified recovery path; the signing private key stays off-device.

Key Takeaway

Choose a secure-communication control by how far protection must travel: session security for one hop, object security for messages that cross intermediaries, a tunnel for a network path, and signed firmware for code. Encryption to the wrong endpoint, or only as far as the broker, is not the protection the data needs.