These slides from my talk at the buildingIoT conference discuss how to secure communication with the Internet of Things protocol "MQTT". It discusses Network, Host, Application and Data Security and also covers advanced topics like OAuth 2.0 and X509 client certificate authentication.

1. www.bestppt.com
Securing
MQTT
#buildingIoT 2016

2. INTRODUCTION
Dominik Obermaier
@dobermai

3. Disclaimer
All security suggestions and guidelines in this talk are
collected from real-world projects and experiences.
When in doubt how to apply these techniques in your own
projects, please consult a security professional you trust.
Obligatory Disclaimer:

4. www.bestppt.com
Key Protocol Facts

5. MQTT Protocol Characteristics
Messaging
Protocol
Binary
Publish /
Subscribe
Data Agnostic
Lightweight
Easy

6. Publish / Subscribe
temperature
sensor
MQTT-Broker
laptop
mobile device
publish: “21°C“
publish: “21°C“
publish: “21°C“
subscribe
subscribe

7. www.bestppt.com
Security

8. The mantra of any good security engineer is:
'Security is a not a product, but a process.' It's
more than designing strong cryptography into a
system; it's designing the entire system such that all
security measures, including cryptography, work
together.
- Bruce Schneier
“

9. www.bestppt.com
Multiple Security
Layers and Aspects

10. Security Layers
Data
Application
Host
Network

11. Network & Secure
Communication

12. Reduced Attack Surface

13. Reduced Attack Surface
— Client initiates TCP
connection
— Client doesn’t need (and
shouldn’t be) addressable
from outside
— IPv6 Privacy Mode should
be used
— NATs can further decrease
attack surface

14. NAT

15. Transport Layer
Security (TLS)

16. Secure communication is when two entities are
communicating and do not want a third party to listen
in. For that they need to communicate in a way not
susceptible to eavesdropping or interception.
- Wikipedia on “Secure Communication”
“

17. Network Stack

18. TLS
— Cryptographic protocol
— Provides a secure
communication channel
between client and server
— TLS handshake initiates
TLS session
— Client validates X509
certificate from server

19. TLS Handshake
Source: Wikimedia Commons: https://commons.wikimedia.org/wiki/File%3AFull_TLS_1.2_Handshake.svg

20. Best Practices
1 Always use TLS if possible
2 Use Certificates from trusted CAs
3 Always validate the
X509 certificate chain
4
Use highest TLS version and
secure cipher suites

21. TLS
— Encrypted communication
— Widely available
— Session Resumption Possible
— Prohibits Man-In-The-Middle
attacks
— CPU, RAM & Network
Overhead
ADVANTAGES DISADVANTAGES

22. TLS Session Resumption
— Reuse an already
negotiated TLS session
— Not all TLS libraries and
MQTT brokers implement
session resumption
— Session IDs &
Session Tickets

23. X509 Client
Certificates

24. X509 Client Certificates
— Client sends certificate as
part of the TLS handshake
— The server is able to
verify the identity of the
client and can abort the
handshake
— Authentication on
Transport Layer
— Some brokers can use
certificates for
authorization

25. The challenge:
Provisioning and revocation

26. X509 Client Certificate Provisioning + Revocation
— How to deploy certificates
to MQTT clients?
— Works great if PKI is
already in place
— Certificate Revocation
Lists for small
deployments
— Online Certificate Status
Protocol for online
certificate validation

27. Security Layers
Data
Application
Host
Network

28. Firewall

29. MQTT Ports
8883
Official IANA Port
MQTT + TLSMQTT + TCP
1883
Official IANA Port
80 / 443
Standard HTTP Ports
MQTT + Websockets

30. Firewall Best Practices
— Only listen on defined
ports
— Only allow traffic from a
specific IP range if
possible
— Block all protocols except
TCP *
— Create iptables rules for
common attacks
* ICMPv6 may be needed for IPv6

31. OS Best Practices (Linux)
— Keep libraries and
software updated
— Disallow Root Access and
use SSH Keys for SSH
— Setup SELinux
— Install Tools like Fail2Ban,
Snort, OSSEC

32. Security Layers
Data
Application
Host
Network

33. Choose your MQTT Broker
wisely

34. Broker Selection

35. Broker specific security mechanisms
— Authentication
— Authorization
— Throttling
— Message Size Restrictions

36. Criteria for choosing MQTT
brokers

37. Criteria for Broker selection
— What security features
does the broker have out
of the box?
— Does the broker have a
pluggable security
mechanism
— Is TLS supported?
— Do security features
thwart the broker?

38. Authentication

39. Authentication is the act of confirming the truth
of an attribute of a single piece of data or entity.
- Wikipedia on “Authentication”
“

41. But how does Authentication
work with MQTT?

42. Authentication

43. Authentication

44. CONNECT Response Codes
Response Code Description
0 Connection Accepted
4
Connection Refused, bad user name or
password
5 Connection Refused, not authorized

45. Authentication Information
— Username + Password
— Client Identifier
— IP Address
— X509 Client certificate

46. Authorization

47. Authorization and MQTT
— Authorization can restrict
Topics a client can publish
or subscribe to.
— Black and Whitelists
— Message characteristics
also possible to restrict
(Retained, QoS)

48. OAuth 2.0

49. OAuth 2.0
— Only Client Credentials
Flow Applicable to MQTT
— Designed for HTTP but
also usable for MQTT
— Uses JWT for Access
Tokens on CONNECT
— Online (JWKS) and Offline
Validation (Signature
Validation) Possible

50. OAuth 2.0 Client Credentials Flow

51. Why OAuth 2.0 instead of plain
User Credentials?

52. OAuth 2.0 Advantage over Credentials
— MQTT Brokers will never
see a password - Only
Authorization Servers
which issue Access Tokens
— Online and Offline
Validation Possible
— Access Tokens only have a
limited lifetime and can
get revoked
— Brokers are just Resource
Servers - Access Tokens
could also be valid for
other Resource Servers
— Authorization information
can get encoded in the
JWT by using custom
claims

53. Security Layers
Data
Application
Host
Network

54. Payload Encryption

55. MQTT PUBLISH

56. MQTT Encrypted PUBLISH

57. Payload Encryption - Advantages
— A completely secure end-to-
end encryption of application
data can be achieved
— Works well on constrained
devices where no TLS can be
used.
— Adds another layer of
security for topics which are
used for delivering
confidential information
— Encryption / decryption can
be resource intensive on
constrained devices
— A secure provisioning of the
keys to the MQTT clients
must be implemented.
— Doesn’t prevent from man-in-
the-middle attacks and replay
attacks.
ADVANTAGES DISADVANTAGES

58. End-to-End Encryption

59. Client-to-Broker Encryption

60. Message Data Integrity

61. MQTT Message Data Integrity

62. Mechanisms
Checksum MAC Digital Signature
Data Integrity
✔ ✔ ✔
Authentication
✘ ✔ ✔
Non-Repudiation
✘ ✘ ✔
Key None Symmetric Assymetric
Data Integrity: The recipient can make sure that the data was not modified (accidentally).
Authentication: The recipient can make sure that the message originates from a trusted sender,
because only trusted parties have access to the key for creating and verifying the stamp.
Non-Repudiation: Only the sender of the message – who has access to the private key – is able to
create the stamp. Other parties can verify the signature with the public key but they are not able to
create the stamp themselves.

63. Security Layers
Data
Application
Host
Network

64. A key concept is that security is an enabler, not a
disabler... security enables you to keep your job,
security enables you to move into new markets,
security enables you to have confidence in what
you're doing.
- Gene Spafford
“

65. www.bestppt.com
THANK YOU
QUESTIONS?