XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Applied
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: MQTT-SN
    • Labels:
      None
    • Proposal:
      Hide

      Initial Proposal - Davide Lenzarini et al - ublox
       
      Definitions:

      • Producer: device in field collecting data from sensors
      • Consumer: customer application using the data collected in field

      Assumptions:

      • MQTT-SN Gateway can be an Internet service
      • The integrity of a MQTT-SN message is verified by the MQTT-SN Gateway
      • The exchange of an integrity key between the producer and the MQTT-SN Gateway is not in scope
      • The method to derive the keys from the key identity material is not in scope
      • The protection end-to-end, from a producer to a consumer, of the data generated by a producer is not in scope

      Goal: 

      • Protect the MQTT-SN Gateway and its MQTT Broker from DDoS and replay-attacks and message spoofing and unauthenticated message processing

      How to

      • The device generating data should 
      • Encrypt the payload
      • Forge a MQTT-SN message with the “Protection” field filled
      • Create the MAC using the integrity key for the MQTT-SN headers + encrypted payload
      • Add the MAC to the MQTT-SN headers (ENCRYPT-THEN-MAC schema)
      • The MQTT-SN Gateway once receiving the MQTT-SN message should:
      • Read the “Protection” field and extract the key identity material from which to infer the integrity key
      • Calculate the hash of the MQTT-SN headers + encrypted payload (without considering the MAC header)
      • Encrypt the hash with the integrity key and verify that it is matching with the MAC header content
      • Pass the payload as is in a MQTT message to the broker, discarding the “Protection” header
      • The MQTT broker forwards normally the payload to the consumer. No changes on the MQTT broker
      • The consumer extracts from the payload the key identity material used to unprotect the data

      Options:

      • MAC options: 8 bytes, 16 bytes, 24 bytes, 32 bytes
      • Symmetric key size options: 128 bits, 192 bits,  256 bits,  512 bits

      Proposed changes to MQTT-SN specs

      • A new variable length optional field called “Protection”: 1-X
      • First byte:
      • Version: 2 bits (for each version we can have a different integrity solutions)
      • 00: HMAC-SHA256
      • 01: Reserved for future use
      • 11: Reserved for future use
      • 10: Reserved for future use
      • Integrity options:
      • Bits 3-4: MAC size as 00=8 bytes, 01=12 bytes, 11=16 bytes, 10=32 bytes
      • Bits 5-6: Integrity key length as 00=128bits, 01=192,  11=256,  10=512
      • Bits 7-8: Protection field length (up to 20 bytes) as 00=12 byte, 01=14bytes, 11=16bytes, 10=20bytes
      • Bytes after the first
      • Reserved for key identity material and for a monotonic counter value to protect against replay attacks
      • A MQTT-SN Gateway that would like to have a protection from the wild internet should discard MQTT-SN messages without a “Protection” field

       
       
       
       

      Show
      Initial Proposal - Davide Lenzarini et al - ublox   Definitions: Producer: device in field collecting data from sensors Consumer: customer application using the data collected in field Assumptions: MQTT-SN Gateway can be an Internet service The integrity of a MQTT-SN message is verified by the MQTT-SN Gateway The exchange of an integrity key between the producer and the MQTT-SN Gateway is not in scope The method to derive the keys from the key identity material is not in scope The protection end-to-end, from a producer to a consumer, of the data generated by a producer is not in scope Goal:  Protect the MQTT-SN Gateway and its MQTT Broker from DDoS and replay-attacks and message spoofing and unauthenticated message processing How to The device generating data should  Encrypt the payload Forge a MQTT-SN message with the “Protection” field filled Create the MAC using the integrity key for the MQTT-SN headers + encrypted payload Add the MAC to the MQTT-SN headers (ENCRYPT-THEN-MAC schema) The MQTT-SN Gateway once receiving the MQTT-SN message should: Read the “Protection” field and extract the key identity material from which to infer the integrity key Calculate the hash of the MQTT-SN headers + encrypted payload (without considering the MAC header) Encrypt the hash with the integrity key and verify that it is matching with the MAC header content Pass the payload as is in a MQTT message to the broker, discarding the “Protection” header The MQTT broker forwards normally the payload to the consumer. No changes on the MQTT broker The consumer extracts from the payload the key identity material used to unprotect the data Options: MAC options: 8 bytes, 16 bytes, 24 bytes, 32 bytes Symmetric key size options: 128 bits, 192 bits,  256 bits,  512 bits Proposed changes to MQTT-SN specs A new variable length optional field called “Protection”: 1-X First byte: Version: 2 bits (for each version we can have a different integrity solutions) 00: HMAC-SHA256 01: Reserved for future use 11: Reserved for future use 10: Reserved for future use Integrity options: Bits 3-4: MAC size as 00=8 bytes, 01=12 bytes, 11=16 bytes, 10=32 bytes Bits 5-6: Integrity key length as 00=128bits, 01=192,  11=256,  10=512 Bits 7-8: Protection field length (up to 20 bytes) as 00=12 byte, 01=14bytes, 11=16bytes, 10=20bytes Bytes after the first Reserved for key identity material and for a monotonic counter value to protect against replay attacks A MQTT-SN Gateway that would like to have a protection from the wild internet should discard MQTT-SN messages without a “Protection” field        

      Description

      Various entities have expressed a desire to bake in some level of security to the MQTT-SN protocol. The desire is to protect from common exploits, whilst adhering to the principals of designing for low power, low bandwidth devices.

        Attachments

          Activity

            People

            • Assignee:
              thesii Simon Johnson [X] (Inactive)
              Reporter:
              simon.johnson1 Simon Johnson [X] (Inactive)
            • Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: