Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Securing MQTT - BuildingIoT 2016 slides

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.

  • Login to see the comments

Securing MQTT - BuildingIoT 2016 slides

  1. 1. Securing MQTT #buildingIoT 2016
  2. 2. INTRODUCTION Dominik Obermaier @dobermai
  3. 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. 4. Key Protocol Facts
  5. 5. MQTT Protocol Characteristics Messaging Protocol Binary Publish / Subscribe Data Agnostic Lightweight Easy
  6. 6. Publish / Subscribe temperature sensor MQTT-Broker laptop mobile device publish: “21°C“ publish: “21°C“ publish: “21°C“ subscribe subscribe
  7. 7. Security
  8. 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. 9. Multiple Security Layers and Aspects
  10. 10. Security Layers Data Application Host Network
  11. 11. Network & Secure Communication
  12. 12. Reduced Attack Surface
  13. 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. 14. NAT
  15. 15. Transport Layer Security (TLS)
  16. 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. 17. Network Stack
  18. 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. 19. TLS Handshake Source: Wikimedia Commons:
  20. 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. 21. TLS — Encrypted communication — Widely available — Session Resumption Possible — Prohibits Man-In-The-Middle attacks — CPU, RAM & Network Overhead ADVANTAGES DISADVANTAGES
  22. 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. 23. X509 Client Certificates
  24. 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. 25. The challenge: Provisioning and revocation
  26. 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. 27. Security Layers Data Application Host Network
  28. 28. Firewall
  29. 29. MQTT Ports 8883 Official IANA Port MQTT + TLSMQTT + TCP 1883 Official IANA Port 80 / 443 Standard HTTP Ports MQTT + Websockets
  30. 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. 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. 32. Security Layers Data Application Host Network
  33. 33. Choose your MQTT Broker wisely
  34. 34. Broker Selection
  35. 35. Broker specific security mechanisms — Authentication — Authorization — Throttling — Message Size Restrictions
  36. 36. Criteria for choosing MQTT brokers
  37. 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. 38. Authentication
  39. 39. Authentication is the act of confirming the truth of an attribute of a single piece of data or entity. - Wikipedia on “Authentication” “
  40. 40. But how does Authentication work with MQTT?
  41. 41. Authentication
  42. 42. Authentication
  43. 43. CONNECT Response Codes Response Code Description 0 Connection Accepted 4 Connection Refused, bad user name or password 5 Connection Refused, not authorized
  44. 44. Authentication Information — Username + Password — Client Identifier — IP Address — X509 Client certificate
  45. 45. Authorization
  46. 46. 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)
  47. 47. OAuth 2.0
  48. 48. 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
  49. 49. OAuth 2.0 Client Credentials Flow
  50. 50. Why OAuth 2.0 instead of plain User Credentials?
  51. 51. 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
  52. 52. Security Layers Data Application Host Network
  53. 53. Payload Encryption
  54. 54. MQTT PUBLISH
  55. 55. MQTT Encrypted PUBLISH
  56. 56. 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
  57. 57. End-to-End Encryption
  58. 58. Client-to-Broker Encryption
  59. 59. Message Data Integrity
  60. 60. MQTT Message Data Integrity
  61. 61. 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.
  62. 62. Security Layers Data Application Host Network
  63. 63. 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 “