Security: Threats & Defense · Study deck

Secure Data in IoT Protocols

A smart lock can send encrypted messages while still accepting a replayed old command or exposing a key to the wrong service.

Shield Shelly is your guide for this deck.

iot-securityprotocol-securitymqtt-security

Shield Shelly, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

review one data flow at a time instead of trusting a protocol name as a security claim
compare what MQTT (broker model) and CoAP (request-response over UDP) each require for security
distinguish authentication from authorization precisely at a gateway boundary
check replay protection, freshness, and gateway trust rather than encryption alone

Major section

Follow Protection From Sensor Record to Consumer

A TLS session to a gateway may protect radio or IP transit while the gateway can still read and transform the payload.

A secure-data record is incomplete if it only proves that an allowed secure protocol message arrived.
Telemetry needs related but different treatment.
The system should preserve observation time and reject altered units.

Protocol security is layered: transport protection, endpoint identity, authorization, message validation, and operations evidence each answer a different question

Major section

Follow Protection From Sensor Record to Consumer (continued)

If cmd-884 is captured and replayed after acceptance, the stable identifier or nonce state should reject a second unlock.

At rest, encrypt sensitive stores, limit retention, and keep keys separate from exported secure data where possible.
Secure key lifecycle is part of the protocol design.
Failure must be secure and observable.

The record follows a message from identity through broker or gateway policy, validation, destination authorization, and monitoring evidence

Major section

Follow Protection From Sensor Record to Consumer (continued)

An expired certificate should not make the device accept any certificate, switch to plaintext, or ignore time without a bounded recovery rule.

A fleet-wide shared secret makes one extracted secure key a fleet boundary failure.
Logs should identify credential versions without printing secret material.
Include clock behavior in secure-message tests.

Major section

Follow Protection From Sensor Record to Consumer (continued)

A chain of individually encrypted links can still have one highly trusted middle system.

A locked-out fleet is also harmful, so test credential renewal before expiry, clock loss, partial rollout, and rollback.
Retain identifiers, decisions, versions, and error categories needed for investigation, but do not copy keys, authorization headers, or complete sensitive payloads.
Freshness based on time can fail when a device reboots without a trusted clock.

Major section

Start With the Story: The Lock Was Real, but the Rule Was Missing

The lock symbol appears, but the same identity can also send a shutdown command.

Protected travel did not prove that the sender had the right permission.
Telemetry is the device reading and status inside a protected message.
A protocol is an agreed set of message and timing rules.

Major section

Start With the Story: The Lock Was Real, but the Rule Was Missing (continued)

A payload is the useful data inside a message.

Message Queuing Telemetry Transport (MQTT) carries named messages through a service.
Transport layer security is protection for data moving across a network.
Transport Layer Security (TLS) protects a connected path.
Datagram Transport Layer Security (DTLS) protects message-based paths.

Major section

Start With the Story: The Lock Was Real, but the Rule Was Missing (continued)

None of these names alone states who may read, send, or change a resource.

This exercise cannot prove every product rule or secret-handling step.
A temperature sensor publishes through an encrypted MQTT connection.
The dashboard shows the padlock, so the team assumes the flow is safe.

Major section

Start With the Story: The Lock Was Real, but the Rule Was Missing (continued)

During review, the same credential can publish to a command topic and subscribe to other devices' readings.

The channel was protected, but the rule that limits what that identity may do was missing.
This chapter uses that small mistake as the starting point.
TLS or DTLS protects the path, but identity, authorization, validation, and monitoring turn the protocol into a defensible IoT control.

Deck summary

Key takeaways

A TLS session to a gateway may protect radio or IP transit while the gateway can still read and transform the payload.

If cmd-884 is captured and replayed after acceptance, the stable identifier or nonce state should reject a second unlock.
An expired certificate should not make the device accept any certificate, switch to plaintext, or ignore time without a bounded recovery rule.
A chain of individually encrypted links can still have one highly trusted middle system.
The lock symbol appears, but the same identity can also send a shutdown command.

Retrieval practice

Recall check 1 of 3

Shield Shelly says: answer from memory, then check your reasoning.

Q1An MQTT broker requires encrypted connections, yet every connected device can subscribe to every topic. Which layer is missing?

AStronger channel encryption without restrictions on broker topic access.

BA different protocol because publish-subscribe access cannot be restricted.

CTopic authorization that limits each identity's publish and subscribe scope.

DLonger retention of messages without limiting which device reads them.

Show answer

Answer: C Encryption protects the channel and authentication identifies the client, but authorization decides what each identity may access.

Retrieval practice

Recall check 2 of 3

Shield Shelly says: answer from memory, then check your reasoning.

Q2An MQTT broker requires TLS client certificates, so every device is strongly authenticated, but there is no per-identity topic policy. What is the most accurate review conclusion?

ACertificates establish topic permissions because the fleet CA enrolled devices.

BRemoval of TLS would simplify a broker that lacks per-topic policies.

CTopic authorization adds no protection after certificate authentication.

DTLS and certificates support transport and identity; topic authorization remains missing.

Show answer

Answer: D Client certificates prove identity over a protected channel; they do not constrain which topics each identity may use.

Retrieval practice

Recall check 3 of 3

Shield Shelly says: answer from memory, then check your reasoning.

Q3A constrained device opens a DTLS connection to a gateway but does not validate the gateway's certificate or key. What is the most accurate description of the protection?

AThe connection is fully secure because DTLS encrypts the data

BNo protection exists at all because certificates were not validated

CThe channel is protected against passive eavesdropping.

DCertificate validation only matters for the server, never the device

Show answer

Answer: C Encryption without verifying the peer leaves a middle-person attack open.

Print reference

Answers

Answer key.

C · Encryption protects the channel and authentication identifies the client, but authorization decides what each identity may access.
D · Client certificates prove identity over a protected channel; they do not constrain which topics each identity may use.
C · Encryption without verifying the peer leaves a middle-person attack open.