MQTT · Study deck

MQTT Security Fundamentals

Picture a message that tells a factory valve to open.

Broker Bex is your guide for this deck.

fundsecurity
Broker Bex, the module guide, in a scene from this chapter.
iotclass.org

After studying this chapter

Learning objectives

You will be able to:

  • Implement Transport Security: Configure TLS/SSL on port 8883 for encrypted MQTT communication and explain why plaintext port 1883 is unacceptable in production
  • Compare Authentication Methods: Distinguish between username/password, client certificates, and JWT-based authentication, and justify when each is most appropriate
  • Design Access Control Policies: Construct topic-level ACL rules that enforce least-privilege access for sensors, actuators, and dashboards
  • Analyze Attack Surfaces: Evaluate which attack vectors (eavesdropping, injection, impersonation, DoS) remain open under different security configurations
• Protect the valve-command link with TLS.
• Prove each device identity.
• Restrict publish and subscribe topics.
• Test denied commands and invalid certificates.
• Budget connection cost.
iotclass.org

Major section

In 60 Seconds

The system must hide it from strangers, prove who sent it, and reject any sender who lacks permission.

  • Telemetry means data sent from a device for remote use.
  • Message Queuing Telemetry Transport (MQTT) is a set of rules for sending such small messages through a central service.
  • A topic is the named route used for that choice.

Key terms

Transport layer security
Transport layer security is the protected-link method often shortened to TLS.
iotclass.org

Major section

In 60 Seconds (continued)

That central service receives each message and sends it to the right listeners.

  • Transport layer security is the protected-link method often shortened to TLS.
  • Third, limit each identity to the few topics and actions it needs.
  • An access control list is the central service's written set of those limits.
iotclass.org

Major section

Putting Numbers to It: TLS Handshake Overhead

Enabling TLS on MQTT adds a handshake cost per new TLS connection.

  • Amortized per message (connect once, send NNN messages): Eper_msg=0.72N+EMQTT E_{\text{per\_msg}} = \frac{0.72}{N} + E_{\text{MQTT}} Eper_msg​=N0.72​+EMQTT​.
  • The simplified RTT component adds 100 ms for a full TLS 1.3 handshake or 200 ms for TLS 1.2 at the assumed RTT; total setup takes longer.
  • Modern brokers support JWT tokens for scalable device authentication.
Setup: 0.72 mA·s; messages: 0.4 + 0.72/N mA·s. 1,440 messages: setup adds 0.0005 mA·s. RTT=100 ms: TLS 1.3 adds 100 ms; TLS 1.2 adds 200 ms. Other delays remain.
iotclass.org

Major section

Access Control Lists (ACLs)

Mosquitto substitutes %u and %c only on pattern lines; a topic line containing %u is literal.

  • Security principle: Least privilege - devices only access topics they need.
  • Each active MQTT client needs a unique client ID: when a second device connects with the same ID, the broker replaces the earlier connection, which can cause repeated disconnects.
  • This progression connects topic syntax to least privilege instead of treating wildcard convenience as harmless.

Why it matters

Wildcards and pattern substitution reduce rule count significantly compared to per-device exact rules.

iotclass.org

Major section

Deep-Dive Note: Broker-Enforced Security Boundaries

MQTT security has to be reviewed as three independent broker-enforced layers: transport encryption, authentication, and authorization.

  • TLS on port 8883 protects credentials and payloads in transit, while plaintext MQTT on 1883 exposes the CONNECT credentials and PUBLISH payloads to anyone on path.
  • For authentication, confirm every device has a distinct revocable identity.

Why it matters

A deployment is not secure because one layer exists; the broker must demonstrate all three for the same connection.

MQTT security is a broker-centered control plane: TLS protects the client-to-broker path, authentication proves the client identity, and authorization limits which topics that identity may publish or subscribe to.
MQTT security is a broker-centered control plane: TLS protects the client-to-broker path, authentication proves the client identity, and authorization limits which topics that identity may publish or subscribe to.
iotclass.org

Major section

Deep-Dive Note: Broker-Enforced Security Boundaries (continued)

This ordered review connects the architecture to the negative evidence required below.

  • Authentication proves which client identity is connecting, using username/password, JWT, or preferably per-device certificates for high-value fleets.
  • For transport, verify clients reach the TLS listener, validate the broker certificate chain, and fail closed on invalid or expired trust.
  • MQTT 5 helps narrow fault diagnosis instead of loosening every control at once.
iotclass.org

Major section

Deep-Dive Note: Broker-Enforced Security Boundaries (continued)

For authorization, prove that a telemetry device cannot publish to site/line1/cmd/# and that a dashboard cannot read maintenance-only topics without explicit permission.

  • Enhanced authentication uses the AUTH packet for challenge-response exchanges such as SCRAM, and reason codes such as Not Authorized (0x87) make denied connects, publishes, or subscribes explicit.
  • TLS still does not protect payloads at rest inside broker queues, so end-to-end payload confidentiality remains an application-level design choice.
  • Some papers and legacy course notes use Secure MQTT (SMQTT) to mean more than MQTT over TLS.
iotclass.org

Major section

Implementation-Level Attack Surface: String Validation and Message Stages

TLS, authentication, and ACLs protect transport and broker access, while wire-format validation remains essential.

  • It permits, but does not require, closing the connection for certain other control characters and Unicode non-characters.
  • A PUBLISH payload is different: MQTT 3.1.1 §3.3.3 makes its content application-specific, so arbitrary payload bytes are valid at the protocol layer.
  • A related implementation risk is Regular Expression Denial of Service (ReDoS).
iotclass.org

Deck summary

Key takeaways

The system must hide it from strangers, prove who sent it, and reject any sender who lacks permission.

  • That central service receives each message and sends it to the right listeners.
  • Enabling TLS on MQTT adds a handshake cost per new TLS connection.
  • Mosquitto substitutes %u and %c only on pattern lines; a topic line containing %u is literal.
  • MQTT security has to be reviewed as three independent broker-enforced layers: transport encryption, authentication, and authorization.
iotclass.org

Retrieval practice

Recall check 1 of 4

Broker Bex says: answer from memory, then check your reasoning.

Q1An MQTT connection uses TLS but accepts any unauthenticated client and has no topic ACL; which risk remains?

AA client can impersonate a device and publish unauthorized commands.
BA passive observer can read TLS ciphertext as plaintext without any key.
CThe broker denies publishes automatically because topic access is restricted by the connection's security settings.
DQoS 2 authenticates the client before the broker checks its identity.
Show answer

Answer: A TLS hides traffic but does not grant identity or topic permission.

Q2Complete the MQTT username/password authentication:

Aclient.username_pw_set("iot_device", "secure_password")
Bclient.set_credentials("iot_device", "secure_password")
Cclient.authenticate("iot_device", "secure_password")
Dclient.login("iot_device", "secure_password")
Show answer

Answer: A username_pw_set() must be called BEFORE connect().

iotclass.org

Retrieval practice

Recall check 2 of 4

Broker Bex says: answer from memory, then check your reasoning.

Q3A temperature sensor in a smart building should only be able to publish its own readings. Which ACL rule best enforces this least-privilege requirement?

Atopic readwrite #, granting every topic and both directions.
Bpattern write sensors/%u/temperature, binding write to username.
Ctopic read sensors/#, granting reads rather than own-device publish.
Dtopic write sensors/+/temperature, permitting any sensor's topic.
Show answer

Answer: B Mosquitto substitutes the authenticated username for %u on a pattern line, restricting each sensor to writing its own temperature topic.

iotclass.org

Retrieval practice

Recall check 3 of 4

Broker Bex says: answer from memory, then check your reasoning.

Q4Your company deploys MQTT sensors in customer buildings. A sensor is configured with client_id='sensor' and username='device' with a shared password. Focusing on session availability across the fleet, what risk does reusing that client ID create?

AThe shared password prevents the broker from using TLS.
BThe username lets each sensor read every topic automatically.
CThe client_id disables QoS acknowledgement handling.
DRepeated client_id values make sensors disconnect each other.
Show answer

Answer: D MQTT brokers allow one active connection per client_id, so a second sensor using 'sensor' forces the previous session off and can cause connection loops and data loss.

iotclass.org

Retrieval practice

Recall check 4 of 4

Broker Bex says: answer from memory, then check your reasoning.

Q5What establishes the ordered byte stream beneath MQTT and TLS?

ATCP transport
BTLS encrypted channel
CClient authentication
DTopic ACL authorization
Show answer

Answer: A TCP establishes the ordered byte stream beneath MQTT and TLS.

Q6A client connects with TLS while ignoring an invalid broker certificate; what is the correct release test?

AAccept the certificate if the broker port is 8883
BCheck whether the broker ACL permits the client topic after TLS connects
CRotate the client credential and retry the same invalid broker certificate
DConfirm the client rejects the invalid certificate
Show answer

Answer: D TLS protection depends on validating the broker identity.

Q5: Which sequence traces an authorized command?
A. Publisher verifies broker certificate over TLS → broker authenticates publisher → broker checks publish ACL → eligible subscriber
B. Broker checks ACL → publisher skips TLS → subscriber
C. Subscriber authenticates publisher without broker → command
D. QoS acknowledgement → physical valve action

Q6: A client connects with TLS while ignoring an invalid broker certificate; what is the correct release test?
A. Accept the certificate if the broker port is 8883
B. Remove all ACLs to simplify the handshake
C. Share one credential across every device
D. Confirm the client rejects the invalid certificate.
Show answer

Answer: A TCP establishes the ordered byte stream beneath MQTT and TLS.

Show answer

Answer: D TLS protection depends on validating the broker identity.

iotclass.org
Q5: A — publisher verifies the broker certificate over TLS, broker authenticates the publisher, checks the publish ACL, then forwards to an eligible subscriber.
Q6: D — confirm the client rejects the invalid broker certificate.

Print reference

Answers

Answer key.

  1. A · TLS hides traffic but does not grant identity or topic permission.
  2. A · username_pw_set() must be called BEFORE connect().
  3. B · Mosquitto substitutes the authenticated username for %u on a pattern line, restricting each sensor to writing its own temperature topic.
  4. D · MQTT brokers allow one active connection per client_id, so a second sensor using 'sensor' forces the previous session off and can cause connection loops and data loss.
  5. A · TCP establishes the ordered byte stream beneath MQTT and TLS.
  6. D · TLS protection depends on validating the broker identity.
iotclass.org