Wirth_Andreas

Securing the MQTTPublish-Subscribe Protocol

Andreas WirthZurich, Switzerland

Student ID: 99-706-731

Supervisor: Prof. Dr. Burkhard Stiller, Dr. Daniel BauerDate of Submission: July 17, 2006

University of ZurichDepartment of Informatics (IFI)Binzmuehlestrasse 14, CH-8050 Zurich, Switzerland

DIP

LO

MA

TH

ES

IS–

Com

mun

icat

ion

Sys

tem

sG

roup

,Pro

f.D

r.B

urkh

ard

Stil

ler

Diploma ThesisCommunication Systems GroupDepartment of Informatics (IFI)University of ZurichBinzmuehlestrasse 14, CH-8050 Zurich, SwitzerlandURL: http://csg.ifi.unizh.ch

Zusammenfassung

Publish/Subscribe ist ein messaging Paradigma, welches dynamische many-to-many Kom-munikation in lose gekoppelten und verteilten Umgebungen ermoglicht. Das MQ Teleme-try Transport Protocol (MQTT) ist ein topic-based publish/subscribe Protokoll. Infor-mationsproduzenten publizieren Nachrichten zu einem Thema (Topic) an einen Message-Broker, und Informationskonsumenten schreiben sich auf einem Message-Broker ein, umdie Nachrichten zu den sie interessierenden Topics zu erhalten. Dabei ist der Message-Broker fur die Speicherung und Weiterleitung der Nachrichten verantwortlich. IBM hateine publish/subscribe Infrastruktur entwickelt, welche MQTT als Messaging-Protokollverwendet. Das Herz der Infrastruktur bildet ein Message-Broker von geringer Grosse.Das Design der implementierten Losung ermoglicht ein dynamisches Konfigurieren der ver-wendeten Protokollstapel mittels einfugbaren Modulen. Die Module garantieren gewisseKommunikationseigenschaften wie zum Beispiel Zuverlassigkeit oder segmentation andreassembly. Dieses publish/subscribe System wird vor allem in Umgebungen eingesetzt,welche von einer zentralen Instanz betrieben und administriert werden. Dabei kann einsolches System hunderte oder gar tausende Teilnehmer umfassen.Da das verwendete MQTT Protokoll keinerlei Sicherheitseigenschaften anbietet, hat sichdas Bedurfnis nach gesicherter Kommunikation entwickelt. Damit konnten die Teilnehmerauch in nicht vertrauenswurdigen Netzwerken eingesetzt werden.

Zielsetzung

Das Ziel dieser Diplomarbeit ist es, geeignete Mechanismen zu evaluieren um die Kommu-nikation im publish/subscribe Netzwerk zu verschlusseln und die Integritat der Nachrichtensicherzustellen. Zudem soll der Zugriff auf die Message-Broker und die Topics kontrol-liert werden. Die evaluierten Mechanismen sollen prototypisch implementiert werden undsich in die konfigurierbaren Protokollstapel einfugen lassen. Dabei soll sowohl TCP, wieauch UDP als Transportprotokoll verwendet werden konnen. Das MQTT Protokoll spez-ifiziert Wildcards um eine Menge von Topics zu beschreiben. Der zu implementierendeZugriffskontrollmechanismus soll diese Wildcards ebenfalls unterstutzen.

i

ii

Resultat

Da die publish/subscribe Infrastruktur von einer vertrauten Partei betrieben wird, kanndie Vertraulichkeit und Integritat einer Nachricht, welche von einem Informationspro-duzenten an sich interessierende Informationskonsumenten per Message-Broker weiterg-ereicht wird, sichergestellt werden, indem die Kommunikation der einzelnen Teilnehmermit dem Message-Broker gesichert wird. Eine Verschlusselung und Authentifikation basierendauf asymmetrischer Kryptographie wurde als besonders zweckmassig erkannt, da sichdiese Mechanismen auf die grosste Menge von moglichen Anwendungsszenarien anwen-den lassen. Um die Teilnehmer von aufwandigen Berechnungen basierend auf privatenSchlusseln zu entlasten, wurde die Moglichkeit von passwortbasierter Authentifizierunggegenuber dem Message-Broker gewahlt. Diese Losung ist im Falle von MQTT besondersinteressant, weil das Protokoll ein Client ID Feld vorsieht, dass ohnehin konfiguriert wer-den muss. Dieses Feld wurde benutzt um Passworter zu transportieren. Verschlusselungund Authentifizierung der Message-Broker gegenuber den Teilnehmern wurde mittels desSSL/TLS Protokolls realisiert. Die Authentifizierung der Message-Broker kann wahlweisemittels X.509 Zertifikaten oder mit Benutzername und Passwort erfolgen. Authorisationerfolgt mittels einer Zugriffskontrollliste, wobei ein rollenbasierter Ansatz gewahlt wurdeum die Authorisation der Teilnehmer bezuglich der Topics durchzufuhren. Die imple-mentierte Losung beinhaltet SSL/TLS Module die an das TCP Protokoll gebunden sind,sowie ein Modul welches eine beliebige zuverlassige Verbindung erfordert.

Fazit

Die Implementation von SSL/TLS Modulen innerhalb der dynamisch konfigurierbarenProtokollstapel ist ohne grossere Probleme machbar. Das Design der Protokollstapel hatsich als flexibel genug erwiesen um eine kleine Erweiterung vorzunehmen, damit Au-thentifikationsinformationen von den SSL/TLS Modulen zu den Zugriffskontrollmodulenweitergegeben werden konnen. Allerdings erwies sich das MQTT Protokoll in der heutigenVersion als unzureichend um Authorisation auf Topic-Ebene problemlos durchfuhren zukonnen. Das Problematische ist, dass der Protokollfluss gestort wird sobald einem Teil-nehmer der Zugriff auf ein Topic verwehrt wird. Die Zugriffskontrollmodule mussen danndafur sorgen, dass das Protokoll nicht zusammenbricht, indem sie passende MQTT Paketezuruckschicken, was in manchen Fallen sehr aufwandig wird. Eine zukunftige Version desMQTT Protokolls sollte fur diesen Fall entsprechende Antwortpakete spezifizieren.

Abstract

Publish/Subscribe is a messaging paradigm that supports dynamic many-to-many com-munication in a loosely coupled distributed environment. MQTT is a topic-based pub-lish/subscribe protocol. Information producers publish topic related events to a messagebroker, and information consumers subscribe to some of these topics. The message brokeris responsable to store the events and forward them to the information consumers. IBMimplemented a publish/subscribe infrastructure consisting of a small footprint messagebroker and messaging clients, using the MQTT protocol. The flexible design of this im-plementation allows to dynamically configure protocol stacks consisting of modules thatoffer different services, such as reliability or segmentation and reassembly. The MQTTprotocol has been designed without security in mind, but the need of a secured commu-nication between the messaging clients and the message broker evolved. In this thesis,the design and prototypical implementation of encryption and access control modules isintroduced, which are pluggable into the protocol stacks.

iii

iv

Contents

1 Overview 1

1.1 Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

1.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Thesis goal: Extensions to the Microbroker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4.1 ”null” Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4.2 SSL/TLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

1.4.3 SSL/TLS with Client Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4.4 Secured Channel over UDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

1.4.5 Topic-based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

1.5 Chapter overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Related Work 7

3 System Analysis 9

3.1 MQTT Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.2 Variable Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.3 Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.4 Protocol flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

3.2 Microbroker and CommsSubsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

v

vi CONTENTS

4 Access Control Mechanisms 15

4.1 Authentication Mechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

4.1.1 Password-Based Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1.3 Entity Authentication Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1.4 Third Party Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Authorization Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 Key Establishment Protocols 23

5.1 Key Transport Protocols using Shared Key Cryptography . . . . . . . . . . . . . . . . . 24

5.1.1 Janson-Tsudik 2PKDP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

5.1.2 ISO/IEC 11770-2 Server-Less Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2 Key Agreement Protocols using Symmetric Cryptography . . . . . . . . . . . . . . . . . 25

5.2.1 Boyd Two-Pass Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2.2 ISO/IEC 11770-2 Server-Less Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.3 Server-Based Protocols using Symmetric Cryptography . . . . . . . . . . . . . . . . . . . 27

5.3.1 Yahalom Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3.2 3PKDP and Optimized 3PKDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.3.3 Gong’s Alternative Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.3.4 Boyd Four-Pass Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.4 Key Transport Protocols using Asymmetric Cryptography . . . . . . . . . . . . . . . . 30

5.4.1 ISO/IEC 11770-3 Key Transport Mechanism 1 . . . . . . . . . . . . . . . . . . . . . . 30






CONTENTS vii

5.5 Key Agreement Protocols using Asymmetric Cryptography. . . . . . . . . . . . . . . .32

5.5.1 Key Broadcasting Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.6 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.6.1 TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.6.2 SSH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

5.6.3 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6 Evaluation of Authentication and Encryption Mechanisms 43

6.1 Configuration Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.1.1 Revocation Costs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

6.2 Key Establishment Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.2.1 TLS/SSL and SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.2.2 Password based Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.3 Authentication Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7 Java Security Frameworks 51

7.1 Java Authentication Frameworks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

7.1.1 JAAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.1.2 Java SASL API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.1.3 JGSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2 Java Secure Socket Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

8 Module Design 55

8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

8.2 Per-Connection Access Control: ConnectionAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8.2.1 ConnectionAC: Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8.2.2 ConnectionAC: Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

viii CONTENTS

8.2.3 MqttLogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

8.3 Per-Topic Access Control: TopicBasedAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

8.3.1 TopicBasedAC: Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8.3.2 TopicBasedAC: Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8.3.3 RoleResolver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8.4 Encryption and Integrity Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

8.4.1 SSL/TLS over TCP: TLSInitiator and TLSThreadedListener . . . . . . . . 66

8.4.2 Transport Layer Independent SSL/TLS Module: TLSModule . . . . . . . . 68

9 Module Implementation 73

9.1 Access Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73

9.1.1 Connection based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

9.1.2 Topic based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

9.2 SSL/TLS modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

9.2.1 ITLSAuthenticator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

9.2.2 TCP based SSL/TLS: TLSInitiator and TLSThreadedListener. . . . . . .80

9.2.3 Transport Layer independent SSL/TLS: TLSModule. . . . . . . . . . . . . . . . .82

10 Conclusions 87

Appendices 89

A Module Configuration 89

A.1 Access Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

A.1.1MqttLogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.1.2RoleResolver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.1.3ConnectionAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.1.4TopicBasedAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

CONTENTS ix

A.2 SSL/TLS Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.2.1Certificate Authority (CA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.2.2Broker and Client Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.2.3TLSInitiator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

A.2.4TLSThreadedListener . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

A.2.5TLSModule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

B Java Runtime Environment Configuration 95

x CONTENTS

List of Figures

1.1 Topic based Publish/Subscribe system . . . . . . . . . . . . . . . . . . . . 2

3.1 MQTT: CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 MQTT: PUBLISH for QoS level two (2) . . . . . . . . . . . . . . . . . . . 13

3.3 MQTT: SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 Microbroker and CommsSubsystem . . . . . . . . . . . . . . . . . . . . . . 14

4.1 ISO/IEC 9798-2 one-pass unilateral Authentication Protocol . . . . . . . . 17

4.2 ISO/IEC 9798-2 two-pass unilateral Authentication Protocol . . . . . . . . 17

4.3 ISO/IEC 9798-2 two-pass mutual Authentication Protocol . . . . . . . . . 18

4.4 ISO/IEC 9798-2 three-pass mutual Authentication Protocol . . . . . . . . 18

4.5 Gray variant of SPLICE/AS . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.6 ISO/IEC 9798-3 one-pass unilateral authentication . . . . . . . . . . . . . 19

4.7 ISO/IEC 9798-3 two-pass unilateral authentication . . . . . . . . . . . . . 19

4.8 ISO/IEC 9798-3 two-pass mutual authentication . . . . . . . . . . . . . . . 20

4.9 ISO/IEC 9798-3 three-pass mutual authentication . . . . . . . . . . . . . . 20

4.10 ISO/IEC 9798-3 two-pass parallel authentication . . . . . . . . . . . . . . 20

5.1 Janson-Tsudik 2PKDP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2 ISO/IEC 11770-2 Key Establishment Mechanism 2 . . . . . . . . . . . . . 25



5.5 Boyd two-pass Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

xi

xii LIST OF FIGURES




5.9 Yahalom Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.10 Janson-Tsudik Optimized 3PKDP Protocol . . . . . . . . . . . . . . . . . 29

5.11 Alternative Gong’s Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.12 Boyd Key agreement protocol . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.13 ISO/IEC 11770-3 Key Transport Mechanism 1 . . . . . . . . . . . . . . . . 30






5.19 Abstracted SSL/TLS Diffie-Hellman Key Agreement . . . . . . . . . . . . 33

5.20 TLS record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.21 TLS Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.22 TLS Session resumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.23 SSH: Binary Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.24 SSH: Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.25 Kerberos: Obtaining a Ticket Granting Ticket . . . . . . . . . . . . . . . . 41

5.26 Kerberos: Obtaining a Ticket . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.27 Kerberos: Login into an Application Server . . . . . . . . . . . . . . . . . 41

7.1 Java Security Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.2 JAAS Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8.1 Connection based Access Control: Finite State Machine . . . . . . . . . . 58

8.2 Connection based Access Control with SSL/TLS Encryption and Authen-tication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

8.3 Topic based Access Control: Finite State Machine . . . . . . . . . . . . . . 62

LIST OF FIGURES xiii

8.4 Topic based Access Control with SSL/TLS Encryption and Authentication 64

8.5 RoleResolver: Tree of roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8.6 TLSThreadedListener and TLSInitiator: Finite State Machine . . . . . . . 67

8.7 TLSModule: Finite State Machine . . . . . . . . . . . . . . . . . . . . . . 70

8.8 TLSModule with connection based Access Control . . . . . . . . . . . . . . 71

9.1 ConnectionAC: Access Control Algorithm . . . . . . . . . . . . . . . . . . 74

9.2 TopicBasedAC: Access Control Algorithm . . . . . . . . . . . . . . . . . . 77

9.3 TLSInitiator Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 81

9.4 TLSThreadedListener Implementation . . . . . . . . . . . . . . . . . . . . 81

9.5 TLSModule Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 83

9.6 TLSModule Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 84

xiv LIST OF FIGURES

List of Tables

3.1 MQTT: Fixed Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 MQTT: Message Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 MQTT: Variable Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 MQTT: Connect Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.5 MQTT: Payload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6.1 Configuration complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2 Key Establishment Protocols: Summary . . . . . . . . . . . . . . . . . . . 46

6.3 Key Establishment Protocols: Complexity . . . . . . . . . . . . . . . . . . 47

6.4 Authentication Protocols: Summary . . . . . . . . . . . . . . . . . . . . . 48

8.1 Module responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8.2 Connection based Access Control Module: States . . . . . . . . . . . . . . 58

8.3 Connection based Access Control Module: Transitions . . . . . . . . . . . 59

8.4 Topic based Access Control Module: States . . . . . . . . . . . . . . . . . 62

8.5 Topic based Access Control Module: Transitions . . . . . . . . . . . . . . . 64

8.6 TCP based SSL/TLS Modules: States . . . . . . . . . . . . . . . . . . . . 67

8.7 TCP based TLS/SSL Modules: Transitions . . . . . . . . . . . . . . . . . 68

8.8 Transport Layer Independent SSL/TLS Module: States . . . . . . . . . . . 70

8.9 Transport Layer Independent SSL/TLS Module: Transitions . . . . . . . . 71

9.1 ConnectionAC: Implementation . . . . . . . . . . . . . . . . . . . . . . . . 75

9.2 TopicBasedAC: Implementation . . . . . . . . . . . . . . . . . . . . . . . . 78

xv

xvi LIST OF TABLES

9.3 TLSModule: Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 84

A.1 MqttLogin: Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.2 TLSInitiator: Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 93

A.3 TLSThreadedListener: Configuration . . . . . . . . . . . . . . . . . . . . . 94

Chapter 1

Overview

The MQ Telemetry Transport Protocol [1] is a so called Topic Based Publish/Subscribe[38] protocol that has been implemented by IBM into a small footprint Message Broker[47] called Microbroker. This chapter outlines the motivation behind the evolved need tosecure the MQTT driven communication between the Microbroker and its clients, givesa short introduction into the publish/subscribe messaging paradigm, and explains thenature and scope of the problem of securing the MQTT publish/subscribe system. At theend of this chapter the thesis goal, the development of extensions to the Microbroker tosecure the MQTT protocol, is outlined in detail.

1.1 Motivation

IBM’s Microbroker is a small and flexible publish/subscribe message broker, capable ofrunning on resource limited devices. It provides a messaging infrastructure [47] thatenables messaging clients to communicate among each other, as well as with enterprisebrokers. It is purely written in the Java programming language.A lot of its flexibility comes from the underlining communication subsystem (CommsSub-system), that provides dynamic configurable protocol stacks. Among other publish/sub-scribe protocols, the usage of the MQTT protocol is the most frequent. Because MQTThas been designed for systems deployed in a trusted environment, using trusted networks,security has not been kept in mind. In future deployment scenarios, the Microbroker mightoperate in an untrusted environment; untrusted in terms of clients communicating withthe Microbroker over an untrusted network. Thus, the need for authentication among thecommunicating peers, as well as message confidentiality and integrity protection evolved.

1.2 Introduction

Publish/Subscribe is a messaging paradigm that supports many-to-many communicationin a distributed environment [38]. Publish/Subscribe systems consist of at least one

1

2 CHAPTER 1. OVERVIEW

Message Broker and clients connecting to that broker. Clients that act as informationproducers are called publisher. They send (publish) their information (events) to the bro-ker. The broker stores and forwards these events (notification) to information consumers(subscribers), that are interested in a specified kind of event. The advantage of this kind ofevent-based interaction is the decoupling in time, space and synchronization between pub-lishers and subscribers [38] [34]. Space decoupling means that the clients do not need toknow each other. Time decoupling relates to the property that publishers and subscribersdo not need to actively participate in the interaction at the same time. Synchronizationdecoupling means that publishers are not blocked while producing events, and subscriberscan receive notifications asynchronously while performing some other activity [38].MQTT is a Topic Based Publish/Subscribe Protocol. Topic based protocols specify theearliest publish/subscribe scheme [38]. Here, different kind of event-types are organized inan hierarchical manner respectively in a tree-structure. There is a root-topic and a set ofsub-topics that might have sub-topics as well. Using these protocols, clients can publishor subscribe to individual topics, which are identified by keywords [38]. For example, ifa client publishes an event on topic a/b, the event will be asynchronously forwarded bythe message broker to all clients that subscribed to sub-topic b of topic a. Figure 1.1visualizes this mechanism.

Figure 1.1: Topic based Publish/Subscribe system

1.3 Problem Statement

Security issues in publish/subscribe systems have often not been taken into account un-til people started thinking about deploying these system across different administrativedomains interconnected through the internet [9]. As described in [48], the initial discus-

1.4. THESIS GOAL: EXTENSIONS TO THE MICROBROKER 3

sion on Security Issues and Requirements for Internet-Scale Publish/Subscribe Systemsoutlines two different security scenarios:� Publishers and subscribers may not trust each other, and may not trust the pub-

lish/subscribe infrastructure.� The infrastructure may not trust publishers and subscribers, and components of theinfrastructure may not trust each other.

The scenario IBM’s Microbroker is most likely deployed in differs slightly. A set of clientsand brokers might reside in the same administrative domain. Clients might connect tothe brokers using wireless links, and brokers might be interconnected over an untrustednetwork. Clients may travel from broker to broker, or might use a broker, that is onlyreachable over the internet. And most likely, there is a well defined set of clients andbrokers, taking part on the publish/subscribe system. This set is known to the entityrunning and administrating the core of the system. So, the security scenarios for theMicrobroker can be described as following:� Publishers and subscribers may not trust the network, but trust the brokers they

are supposed to connect to.� The Microbroker may not trust publishers and subscribers, and may eventually nottrust other brokers as well.

In this scenario, trust between clients or brokers can be achieved using so called SecuredChannels [2]. If a client trusts the secured communication between every other clientand the broker, and trusts the brokers access control mechanism too, then this client alsotrusts other clients. In other words, this means that trust can be achieved in securingthe client-server communication. The advantages of this approach is evident: It is a wellunderstood problem and it does not eliminate the main advantage of publish/subscribesystems - the decoupling of information producers and consumers, a secured client-to-client communication would lead to.The challenge of this approach is scalability, simplicity and the fact that the communica-tion between clients and broker is often done using UDP.

1.4 Thesis goal: Extensions to the Microbroker

The scenario outlined in Section 1.3 leads to the requested extensions described below.The common denominator of these extensions is scalability, simplicity and the usage ofstandards such as X.509 certificates. Possible solutions that need a sophisticated set-upor any infrastructure that exceeds the tiny publish/subscribe infrastructure in size oradministrative costs are not desired.


1.4.1 ”null” Scenario

In the ”null” scenario, no security mechanisms are requested. The goal is that the systemperforms as efficient as no security would have been applied.

1.4.2 SSL/TLS

In some deployment scenarios encryption is requested, but no client authentication andaccess control. The goal is that almost no additional maintenance costs arise.

1.4.3 SSL/TLS with Client Authentication

This extension requires encryption and broker authentication with SSL/TLS. Further-more, clients have to be authenticated using a mechanism working on top of SSL/TLS.The goal is an authentication mechanism that is applicable not only using SSL/TLS. Theaccess control mechanism described below has to be applicable within this extension, andan access control mechanism for MQTT connection has to be deployed.

1.4.4 Secured Channel over UDP

The communication between peers using UDP on the transport layer has to be secured.It should be possible to use the same authentication and access control mechanism as inthe TCP case and the same certificates as in the SSL/TLS extension.

1.4.5 Topic-based Access Control

In this scenario, authentication and per-topic access control are required. A client that isnot authorized to publish or subscribe to a topic has to be informed.

1.5 Chapter overview

After a short overview into related work concerning security issues for publish/subscribesystems, Chapter 3 introduces into the MQTT protocol and analyzes the design of theMicrobroker with its dynamically configurable protocol stacks. Chapter 4 and Chapter5 investigate access control mechanisms and key-establishment protocols found in litera-ture and describe the security goals they provide. In the next chapter an evaluation ofthe investigated mechanisms is given, and it is explained what mechanism fits for whatdeployment scenario of the Microbroker. Chapter 7 overviews available access controlmechanisms as well as the encryption and integrity protection frameworks the Java pro-gramming language offers. In Chapter 8 and Chapter 9 a description of the design and

1.5. CHAPTER OVERVIEW 5

implementation of security modules is given. The last chapter contains conclusions of theimplemented solution and outlines the limitations of the MQTT protocol version 3. Thechapter also contains suggestions for future releases of the protocol.


Chapter 2

Related Work

In [48] the authors investigate the security requirements for internet-scale publish/sub-scribe systems. The investigations describe that either end-to-end or point-to-point au-thentication can be desirable in a publish/subscribe system. End-to-end authenticationmeans that the originator of a publication can be authenticated by subscribers. Point-to-point authentication means that a message broker is able to authenticate the publisherof a message, and a subscriber is able to authenticate the message broker. Further, itis outlined that end-to-end authentication can be replaced with point-to-point authen-tication if the publish/subscribe infrastructure is trusted. Besides the requirements forauthentication, the requirements for integrity, confidentiality, anonymity, accountabilityand availability are described. It is also explained that no end-to-end security can beachieved using traditional mechanisms without taking away an important benefit of thepublish/subscribe model - the unawareness of the peers of each other. However, the au-thors show that the security requirements differ for publish/subscribe systems where thepeers are aware of each other, and for such systems where the peers are unaware of eachother.A framework for secure end-to-end delivery of messages in publish/subscribe systems isintroduced in [44]. The basic idea behind this framework is that there is a central entitycalled Key Management Center (KMC). The KMC creates secret keys for each topic andissues them to authorized clients. Further, the KMC issues security tokens, containing theaccess rights of a client. All communication between the clients and the KMC is encryptedand integrity protected using asymmetric cryptography, and all events sent to or from themessage broker are secured using the topic-key. Basically, if a client wants to publish anevent to a certain topic, it first has to contact the KMC that checks the client’s authoriza-tion to access this topic. It sends the topic-key as well as the security-token back. Theclient stores both for future use. The publisher now encrypts and integrity protects itsmessage with the topic-key. It also calculates a signature of the message using its privatekey. The message and the security token is then sent to the message broker. The token isused by the message broker to check if the client is allowed to access the topic. If anotherclient subscribes to the same topic, it first has to obtain the topic-key from the KMC aswell as its own security-token. Now, it is able to subscribe to the topic by presenting thetoken within the subscription request. If the client receives a message from the broker, itdecrypts and integrity checks it with the topic-key. Further, the client can authenticate

7

8 CHAPTER 2. RELATED WORK

the originator of the message by checking the signature.A similar approach is used in [46]. The proposal consists also of a centralized entity todistribute topic-keys, but unlike in [44] security tokens do not represent access permissionsbut the topic itself. This way, the proposed frameworks hides the topics from unautho-rized clients.In [4] a design and an implementation of a role based access control mechanism for pub-lish/subscribe system is presented. The proposal covers point-to-point authenticationand authorization between clients and message brokers as well as between interconnectedbrokers. To control access of clients to brokers either some kind of access control list orcapabilities [47] are used. The brokers use X.509 certificates to authenticate each otherand build a graph of successfully authenticated and interconnected message brokers. Thisgraph represents a subset of the publish/subscribe infrastructure that is trusted by a bro-ker and usable to forward messages. Further, the concept of restrictions is introduced.A restriction is a message filter that is assigned to a client by a message broker. Such arestriction is created as soon as a client registers itself for events it is not allowed to. Ifno restriction exists, no authorization checks are made by the broker.The access control mechanism proposed in [35] also uses some kind of capabilities toauthenticate the clients. Further, a formal authorization mechanism for content-basedpublish/subscribe systems is described.

Chapter 3

System Analysis

The design of IBM’s Microbroker focuses on scalability, size, performance and flexibility.There might be thousands of clients connecting to a single broker. Neither the brokernor the clients need any sophisticated configuration. Thus, a security mechanism has tofollow these design principles too. Any mechanism requiring a complex setup, or additionalinfrastructure will not be applicable in many situations.

3.1 MQTT Protocol

MQTT is the protocol that establishes the publish/subscribe mechanism between the Mi-crobroker and its clients. It is designed for resource-constrained devices and networks.The protocol-semantic is very simple. Clients initially connect to the broker, and keepconnected until they disconnect. During an ongoing connection, they can publish messagesto a distinct topic, subscribe to a topic, or unsubscribe from it. Subscriptions to topics canbe expressed using Wildcards. A wildcard represents a set of topics. Two different wild-cards are specified: The + wildcard represents an arbitrary topic, including all sub-topics.The # wildcard represents none, or an arbitrary topic, also including all sub-topics.The protocol assures three Quality of Service (QoS) types: ”at most once”, ”at least once”,and ”exactly once”. An optional Will Message is sent to the Will Topic if a client is un-expectedly disconnected. The current MQTT version (version 3) does not support anysecurity mechanism at all. Version 4 is currently in the specification phase. It will providea hook to plug in several extensions such as security.

The following technical descriptions explain the basics of MQTT:

3.1.1 Message Format

The message format for MQTT command messages contains a Fixed Header, the Payloadand, depending of the Message Type, one or more Variable Headers fields.

9

10 CHAPTER 3. SYSTEM ANALYSIS

The Fixed Header has at least two bytes. Message Type, DUP flag, QoS and RE-TAIN are encoded in the first one. The following bytes represent the number of bytesremaining within the message.

Table 3.1: MQTT: Fixed Header

bit 7 6 5 4 3 2 1 0byte 1 Message Type DUP

flagQoS level RETAIN

byte 2 Remaining Length

Table 3.2 shows the defined Message Types and their description.

Table 3.2: MQTT: Message Types

Type Enumeration DescriptionReserved 0 ReservedCONNECT 1 Client request to connect to a brokerCONNACK 2 CONNECT acknowledgmentPUBLISH 3 Publish a messagePUBACK 4 PUBLISH acknowledgmentPUBREC 5 PUBLISH receivedPUBREL 6 PUBLISH releasePUBCOMP 7 PUBLISH completeSUBSCRIBE 8 Client subscribe requestSUBACK 9 SUBSCRIBE acknowledgmentUNSUBSCRIBE 10 Client unsubscribe requestUNSUBACK 11 UNSUBSCRIBE acknowledgmentPINGREQ 12 PING requestPINGRESP 13 PING responseDISCONNECT 14 Client is disconnectingReserved 15 Reserved

The DUP flag is set in the case when a client or broker redelivers a PUBLISH message.This requires QoS one or two. If a message is redelivered, the Variable Header has toinclude a Message ID.

As already mentioned, there exist three QoS levels. QoS Zero (0) corresponds to ”atmost once”, QoS One (1) to ”at least once”, and QoS Three (3) to ”exactly once”.

A Fixed Header containing the Retain Flag indicates to the broker that this messagehas to be sent as an initial message to new subscribers to this topic. Like that, newsubscribers can easily be informed about the current number of topics.

The Remaining Length represents the number of bytes within the current message,

3.1. MQTT PROTOCOL 11

including data in the variable payload. The encoding is not important here, but can belooked up in [1].

3.1.2 Variable Header

The Variable Header resides between the Payload and the Fixed Header. Table 3.3 lists thespecified Variable Header fields and the MQTT command messages that use a dedicatedfield. The Message Identifier is only needed if the QoS level is 1 or 2.

Table 3.3: MQTT: Variable HeadersField Used in QoSProtocol name CONNECT 0-2Protocol version CONNECT 0-2Connect flags CONNECT 0-2Keep Alive timer CONNECT 0-2Connect return code CONNACK 0-2Topic name PUBLISH 0-2Message identifier PUBLISH 1-2

PUBACK 1-2PUBREC 1-2PUBREL 1-2

PUBCOMP 1-2SUBSCRIBE 1-2

SUBACK 1-2UNSUBSCRIBE 1-2

UNSUBACK 1-2PINGREQ 1-2PINGRESP 1-2

DISCONNECT 1-2

Detailed explanation of the semantic and the encoding of the Variable Header can belooked up in [1]. The most interesting field here is the Connect Flags. These are encodedin one byte as shown in Table 3.4.

Table 3.4: MQTT: Connect Flagsbit 7 6 5 4 3 2 1 0

Reserved Reserved WillRetain

Will QoS WillFlag

Cleanstart

Reserved

If the Will Flag is set, a Will Message is published by the broker on behalf of the clientwhen there has been an I/O error or when the client failed to send a message within the


Keep Alive time. The Will Retain flag is set if the broker should retain the Will Messagein the case that the client is disconnected.

3.1.3 Payload

The MQTT command messages that have a payload are shown in Table 3.5.

Table 3.5: MQTT: PayloadMessage Type PayloadCONNECT One or three UTF-8 encoded strings. The

first string uniquely identifies the client tothe broker. The second string is the WillTopic and the third the Will Message. Thesecond and third string are only used if theWill Flag is set in the Variable Header.

SUBSCRIBE List of topic names to which the client wantsto subscribe to, and the desired QoS levels.

SUBACK List of granted QoS in the same order as inthe corresponding SUBSCRIBE message.

PUBLISH Application specific data only. No assump-tions are made here.

3.1.4 Protocol flow

Each time a client (publisher or subscriber) wants to establish a connection to the broker,it has to perform a CONNECT as shown in Figure 3.1.

Client Broker Message Type(Variable Header)[Payload]

---------------------------------------------------------------------

-------> CONNECT(Protocol Name, Protocol Version,

Connect Flags, Keep Alive Timer)

[Client ID,(Will Message, Will Topic)]

<------- CONNACK(Connect Return Code)[]

Figure 3.1: MQTT: CONNECT

This connection is kept alive as long as no keep alive timeout occurs. If a client hasno message to send or receive during this period, PINGREQ and PINGRESP, as aresponse to PINGREQ, are used to keep the connection alive.

3.2. MICROBROKER AND COMMSSUBSYSTEM 13

The protocol flow, initiated by the PUBLISH control message, depends on the chosenQoS level, set in the Fixed Header shown in Table 3.1. For QoS 0 a single PUBLISH issent, containing the Topic Name and Message Identifier fields in the Variable Header andthe message in the Payload as outlined in Table 3.3 Table and 3.5.For QoS 1 the PUBLISH message will be acknowledged with a PUBACK including theMessage Identifier in the Variable Payload.The protocol flow using QoS 2 is visualized in Figure 3.2.


---------------------------------------------------------------------

-------> PUBLISH(Topic Name, Message Identifier)[Message]

<------- PUBREC(Message Identifier)

-------> PUBREL(Message Identifier)

<------- PUBCOMP(Message Identifier)

Figure 3.2: MQTT: PUBLISH for QoS level two (2)

For QoS 0 the broker directly forwards the received message to the subscribers, for QoS1 it stores the message in a database, too. QoS 2 assures exactly once delivery. Thus,the broker first stores the message in a database, and forwards it after the receptionof PUBREL. These PUBLISH protocol flows are not only used by publisher, sending amessage to the broker, but also by the broker, notifying the clients about the publication.The protocol flow initialized by the SUBSCRIBE control message is QoS independent.In Figure 3.3 the client sends a SUBSCRIBE message to the broker containing the MessageIdentifier field in the Variable Header and the Payload as outlined in Table 3.5. The brokerresponds with a SUBACK control message.


---------------------------------------------------------------------

-------> SUBSCRIBE(Message Identifier)

[Topic Names, Desired QoS]

<------- SUBACK(Message Identifier)[Granted QoS]

Figure 3.3: MQTT: SUBSCRIBE

3.2 Microbroker and CommsSubsystem

The Microbroker is the message broker enabling the MQTT driven publish/subscribe sys-tem. It consists of the publish/subscribe engine, that receives and distributes the messagesfrom and to its clients and it is responsable for persistence. All network communication is


done by the CommsSubsystem. This communication subsystem uses dynamic configurableprotocol stacks, consisting of pluggable modules, that implement specific protocol func-tionalities. The top module of the CommsSubsystem is the MQTT Module that parsesand creates MQTT messages and is the interface to the publish/subscribe engine. On thetransport layer, a Listener Module listens for network traffic and launches the stacks assoon as there is some data that arrives. On the client-side, an Initiator Module establishesthe communication on the transport layer with the Microbroker. The other modules, suchas modules for reliable UDP communication, or segmentation and reassembly, are pluggedbetween Listener and MQTT module or Initiator and MQTT module, respectively. Figure3.4 shows a Microbroker that has been configured to listen for UDP datagrams to arrive.As soon as a datagram has arrived, the Listener module launches a new stack containinga module for reliability and a segmentation and reassembly module.

Figure 3.4: Microbroker and CommsSubsystem

The design of the CommsSubsystem is done in a way that the modules do not directlycommunicate with each other. In fact, they even do not offer a service interface that isaccessable directly from other modules. The packets that arrive, or have to be sent, arehanded out to a dispatcher, that controls the data flow in the protocol stacks, and deliversthe packets to the upper or downer module.

Chapter 4

Access Control Mechanisms

This chapter provides an overview of authentication and authorization mechanisms po-tentially suitable for access control use within the CommsSubsystem. The focus is mainlyon mechanisms providing authentication only, although some mechanisms, that establishalso a session-key, are outlined too.

4.1 Authentication Mechanisms

This section discusses authentication mechanisms found in literature. Because a SSL/TLSmodule is requested to secure the TCP based protocol stacks, a solution to authenticateclients to brokers in a pluggable module on top of the SSL module is of special interest.

4.1.1 Password-Based Authentication

Password based authentication is the simplest authentication mechanism. If randomlychosen, the strength of passwords, and other secrets, can be assessed by the average num-ber of trials required by a brute-force attack. Thus, the strength depends on the lengthof the password and the size of the character set. Assumed we have an 8 byte password,and an attacker can check fifteen million passwords per second, as promised by Elcomsoftfor their ”Advanced Archive Password Recovery Tool” running on an 1 GHz CPU, theaverage time the tool needs is:

2568

2 ∗ 3600 ∗ 24 ∗ 365 ∗ 15000000= 19498.08 years.

If only the 95 printable ASCII characters are used, it will still need

958

2 ∗ 3600 ∗ 24 ∗ 365 ∗ 15000000= 7.01 years.

The bigger problem using passwords is not their strength, especially concerning on-line

15

16 CHAPTER 4. ACCESS CONTROL MECHANISMS

password-guessing, but their storage. In addition, an access control module using pass-word based authentication has to ensure that no client is capable of sending the passwordover the network without encryption and broker authentication.On the broker side, there are generally two possibilities to store the passwords: Hashedstorage and encrypted storage. Encrypted storage has the drawback that the encryptionkey has to be stored as securely as one would have to store the unencrypted passwords. Sothere is no big gain. Hashed storage has the disadvantage to be vulnerable to dictionaryattacks. Recent UNIX systems focus this problem using two different mechanisms: Bythe usage of Salt and by hashing the password multiple times [45]. The use of a multipletimes hashed password is to increase the time needed to build the character-string, that iscompared during login. This slows down directory attacks. The algorithm used in recentUNIX systems, further randomizes the number of iterations on the basis of the passwordlength. But before the password is hashed, some random bytes - the salt - is added. Theserandom bytes are then stored in plaintext. The usage of the salt is to randomize the re-sulting hash-value in a way that it makes it impossible for an attacker to prepcomputethe hash-values for often used passwords, and simply to compare this values to a fetchedpassword file.The problem being more important and more excessive can be found on the client side.Because clients usually act without human interaction, the passwords have to be storedin cleartext, or have to be encrypted. So one has either to protect the password file or theencryption key very carefully. Of course the worst-case scenario is a physically deployed(stolen) client.The interesting thing about password based authentication concerning MQTT version 3is that the protocol has a 23 byte Client ID (Table 3.5). The application programmerhas to configure this ID anyway and its length is sufficient to encode the Client ID and apassword. This assumes that encryption and broker authentication is always used.Besides the traditional password based authentication there exist so called Password BasedProtocols or Strong Password Protocols, as well as one-time passwords schemes like theLamport’s hash [32]. They have in common that there is no need for an encrypted channelor an already authenticated broker, but they do not solve the storage problem, especiallyon the client side. These authentication protocols will be covered in the next subsection.

4.1.2 Capabilities

Another approach doing authentication are Capabilities [42]. One can imagine capabilitiesas a distributed Access Control List (ACL) - distributed to the clients. The clients hold theaccess control information by their own. Of course one has to ensure that a client cannotmodify its capability by protecting them with a signature. When using capabilities, aclient presents its capability to the broker. The client’s access control rights, such as thetopics it is allowed to subscribe or to publish to, are encoded in the capability. The brokeronly has to check the capabilities validity and whether the requested topic is listed in it.Instead of a capability including the client ID and its permissions, one could include theclient’s role or group membership.A generalization of capabilities are Attribute Certificates described in [18]. Attributecertificates are intended to bind attributes, such as access rights to an entity. A fieldcontaining the entities X.509 certificate serial number may be included in the attribute

4.1. AUTHENTICATION MECHANISMS 17

certificate. Therefore, it binds a public key certificate to a set of access rights. Attributecertificates are issued and signed by a so called Attribute Authority (AA). These areassumed to be certified by a Certificate Authority (CA). Like that, a single point of trust- the trusted public key of a root CA - can be used to validate the certificates of AAs,other CAs and other clients [41].Capabilities or attribute certificates are especially interesting in conjunction with RoleBased Access Control [19]. The AA does not have to issue an attribute certificate foreach client. Only one per role is needed. Further, the broker does not need to maintainan ACL, it only has to parse the capability during the MQTT CONNECT. The lack ofan ACL and a shared secret between clients and brokers lead to a system where clientscan travel from broker to broker with almost no additional configuration. The only thingthat has to be issued to the brokers is the certificate needed to validate the presentedcapability.

4.1.3 Entity Authentication Protocols

Most protocols for entity authentication come along with session key establishment. Thissubsection mainly covers protocols that do not establish a session key; the ones that doare shown in the Chapter 5.

Shared Key-BasedAccording to [7],[3],[49],[12] and [2] the only protocols in this category not known asvulnerable are the ISO/IEC 9798-2 Protocols. Although there is no prove that theseprotocols are secure [7], no attack has been published so far.Among the four entity authentication protocols in the ISO/IEC 9798-2 specification, twoare concerned with unilateral authentication. These two protocols are outlined in Figure4.1 and Figure 4.2. The following syntax is used: T(A) means a timestamp created by theclient (A), K(AB) means a secret-key A and the broker (B) share, and K(AB){message}means that ”message” is encrypted and integrity protected with K(AB). N(A) is a nonce,a random number only used once, created by A. Its purpose is similar that of timestamps.It prevents from replay-attacks.

C B Message

---------------------------------------------------------------------

-------> K(AB){T(A),B}

Figure 4.1: ISO/IEC 9798-2 one-pass unilateral Authentication Protocol

A B Message

---------------------------------------------------------------------

<------- N(B)

-------> K(AB){N(B),B}

Figure 4.2: ISO/IEC 9798-2 two-pass unilateral Authentication Protocol


Both provide the same properties, they authenticate the client to the broker.The third protocol (Figure 4.3) is simply the two-pass version of the protocol in Figure4.1 and provides mutual authentication.

Client Broker Message

---------------------------------------------------------------------

-------> K(CB){T(C),B}

<------- K(CB){T(B),C}

Figure 4.3: ISO/IEC 9798-2 two-pass mutual Authentication Protocol

The last protocol in this family has the same properties as the protocol in Figure 4.3. Butinstead of using timestamps it uses nonces.

A B Message

---------------------------------------------------------------------

<------- N(B)

-------> K(AB){N(A),N(B),B}

<------- K(AB){N(B),N(A)}

Figure 4.4: ISO/IEC 9798-2 three-pass mutual Authentication Protocol

The drawback of these protocols are related to scalability in most cases, because theyrely on symmetric keys. One can think about one case where this protocols do not havedisadvantages concerning configuration costs in comparison to protocols based on asym-metric keys: If there is only one broker and n clients. Because clients do not communicatedirectly with each other there will only be the need to share n symmetric keys. Otherdisadvantages may be the need of synchronized clocks if timestamps are used, or the needto keep track of nonces used in previous communication.

Public Key CryptographyProtocol candidates using public key cryptography are according to [7] and [2] the follow-ing:� ISO/IEC 9798-3 Protocols [28]� ISO/IEC 9798-5 Protocols [29]� SPLICE/AS Protocol variants[50]

Among the SPLICE/AS protocols, only the Gray variant of SPLICE/AS [22] shownin Figure 4.5 is not known as vulnerable [7]. Here, SIG(A)[message] is a signature of”message” performed by A, and L is the lifetime of the message used to prevent replayingthis message. The protocol provides mutual authentication of A and B.


A B Message

---------------------------------------------------------------------

-------> A,B,T(A),L,SIG(A)[B,T(A),L,N(A)]

<------- B,A,N(A),SIG(B)[A,N(A)]

Figure 4.5: Gray variant of SPLICE/AS

The ISO/IEC 9798-5 Protocols are mechanisms using zero-knowledge techniques.They are based on the Fiat-Shamir [20], Guillou-Quisquater [23] and the patented Schnorr[43] protocols. These protocols prove knowledge of the private key corresponding to thepublic key. A drawback is that they are strongly dependent on specific cryptographicmechanisms [7]. For example they rely on the same idea used in RSA [40], but RSA keysare not applicable with these protocols.There are five ISO/IEC 9798-3 Protocols for authentication. Two are for unilateral,and three for mutual authentication. The protocols in Figure 4.7 and 4.9 are also includedin the Federal Institute Processing Standard 196. These protocols allow for optional text-fields or transportation of the corresponding certificate within the messages [28] [7] [2].The text fields may contain the sender’s identity which is otherwise not included in theprotocol. The first protocol (Figure 4.6) consists of a single message from a client to theverifying broker.

A B Message

---------------------------------------------------------------------

-------> T(A),B,Sig(A)[T(A),B]

Figure 4.6: ISO/IEC 9798-3 one-pass unilateral authentication

The timestamp prevents from replay attacks, and may be substituted by a counter. Theprotocol assures the client’s identity as well as it is aware of a distinct broker.The protocol in Figure 4.7 uses a nonce instead of a timestamp. An other differenceis that nonce N(A) is chosen by A. There is no reason to include this nonce becauseof authentication, but it prevents A from blindly signing a message chosen by B. Theprotocol provides entity authentication of A to B.


---------------------------------------------------------------------

<------- N(B)

-------> N(C),N(B),B,Sig(C)[N(A),N(B),B]

Figure 4.7: ISO/IEC 9798-3 two-pass unilateral authentication

The protocol below (Figure 4.8) is simply the mutual authentication version of the protocolin Figure 4.6. Timestamps can be replaced by counters, and because the exchangedmessages are independent of each other, the messages can be exchanged in parallel.


A B Message

---------------------------------------------------------------------

-------> T(A),B,Sig(A)[T(A),B]

<------- T(B),A,Sig(B)[T(B),A]

Figure 4.8: ISO/IEC 9798-3 two-pass mutual authentication

The next protocol, shown in Figure 4.9, is an extension of the protocol in Figure 4.7 whichprovides mutual authentication. This is the only protocol of the family that has provensecurity [7].


---------------------------------------------------------------------

<------- N(B)

-------> N(C),N(B),B,Sig(C)[N(C),N(B),B]

<------- N(B),N(C),C,Sig(B)[N(B),N(C),C]

Figure 4.9: ISO/IEC 9798-3 three-pass mutual authentication

The final protocol of this standard (Figure 4.10) allows parallel authentication of thepeers. The first two and the last two messages can be sent together. The protocol assuresmutual authentication.

A B Message

---------------------------------------------------------------------

-------> N(A)

<------- N(B)

-------> N(A),N(B),B,Sig(A)[T(A),B]

<------- N(B),N(A),C,Sig(B)[N(B),N(A),A]

Figure 4.10: ISO/IEC 9798-3 two-pass parallel authentication

Password based ProtocolsPassword based protocols have been designed for situations where the communicationparties only share a short password. Interesting attributes of password based protocolsare that if someone eavesdrops on an authentication exchange or impersonates one end,he will not be able to perform off-line password-guesses. He will only be able to try asingle on-line guess. Further, the protocols establish a session-key.So called Augmented Strong Password Protocols [10] have in addition the property, thateven if the server’s database has been stolen, an attacker will not be able to impersonatea client. These protocols can also be used to download a credential, e.g an asymmetrickeypair, from a server. The basic idea is that both peers share a week secret, which is ahash of the client’s password. They do a Diffie-Hellman Key Exchange [16] and encryptthe exchanges messages with the weak secret. Afterward, they mutually authenticate eachother using the agreed Diffie-Hellman secret. The reason why these protocols work, is that


any trial decryption of the exchanged Diffie-Hellman messages with a chosen passwordleads to a randomly looking number that gives no information about the correctness ofthe chosen password.

A special mechanism is the so called Lamport’s hash [32]. In fact it is not a passwordbased protocol but it is applicable in the same scenario: The parties only share a passwordand there is no encrypted channel. Of course, password based authentication over anSSL/TLS secured transport layer fits in this scenario, too.The Lamport’s hash does not establish a session key. It can only be used to authenticatethe client to the server a finite amount of times. First, the mechanism has to be set-up.Out of the client’s password a hash x1 = hash(password) has to be computed, thenx2 = hash(x1). This continues until we arrive at some xn = hashn(password). Thisvalue has to be stored on the server. When the client needs to authenticate to the server,it sends its user ID to the server which responds with n. Then, the client computeshashn−1(password) and sends this back to the server which hashes the received hash andlooks up in its table if hash((hashn−1(password)) is equal to its stored entry. If so, itdecrements n by one and stores hashn−1(password). If n gets to one, the mechanism hasto be set-up again. A variant of this mechanism is to enhance the hash with a salt [10]. Sothe same password can be used for different servers without the danger of a reply attack.Another advantage is that the client does not need a new password if n decreases to one,instead just another salt can be used. Of course, the calculation of that many hashesduring each login needs some CPU time and might not be applicable for resource limiteddevices with large n. An advantage of this mechanism could be seen in accountability.For example one could sell n-times access to a dedicated broker without the need of asophisticated accounting mechanism.

4.1.4 Third Party Authentication

The usage of shared keys scales badly, especially if clients connect to multiple brokers.A workaround is the usage of a Key Distribution Center (KDC). The idea is that clientsonly have to share a secret key with the KDC. If a client wants to connect to a brokerit first communicates with the KDC, using the shared key, and asks for a session-key tosecure the connection to the broker. After authentication of the client, the KDC createsthe requested key and encrypts it one time with the broker’s key, and another time withthe client’s key. The session-key encrypted with the broker-key is called a ticket. Now theclient can send this ticket to the broker which decrypts the ticket to get the key for thesecured communication. This is the basic idea behind the Needham-Schroeder Protocol[37]. The protocol is known as vulnerable [7], but the basic idea behind it is picked upby a lot of other protocols. The most famous is the Kerberos protocol [31]. It providesmutual authentication of the peers and establishes a session key. A detailed descriptionof the protocol follows in Subsection 5.6.3.


4.2 Authorization Mechanisms

Discretionary Access ControlThe discretionary access control model governs access of users to resources on the basisof the user’s identity. There are rules, defining the access rights for each user and eachobject in the system. In the classical discretionary access control model each user thatcreates an object administers access to the object by its own. This model is, for example,used on UNIX Systems.Advantages concerning the Microbroker are the ease of implementation and the possibilityto revoke the access rights of a single client without much costs. Disadvantages are theadministrative costs if clients travel between different brokers.

Mandatory Access ControlThe mandatory access control model uses a classification of each object and each useron a system. The classification is used to define rules to control access by a referencemonitor [10]. The classification is an ordered set of elements, for example, Unclassified,Confidential, Secret and Top Secret. Usually elements belong to a category, for exampleClient Addresses or Asset Portfolio. Client Addresses may be in Unclassified and Asset Port-

folio in Secret. Thus, a user that has access to Confidential data is allowed to access Client

Addresses but not Asset Portfolio.

Role based Access ControlIn the role based access control model, the administration of the access-right is performedthrough roles and privileges granted to roles. Users belong to one or more roles, and arole policy regulates the access of users to resources on the system. A role can be definedas a set of actions role-members can perform. According to [41] attribute certificates maybe well suitable with role based access control. Attribute certificates may be distributedcontaining a role the certificates possessor belongs to. The advantages using role basedaccess control are [41]:� Authorizations can be specified with reference to classes of topics, rather than to

single topics.� Authorization to access topics may be defined on the basis of activities a client hasto perform.� A natural hierarchy of topics may already exist. Clients, assigned to a specific role,may inherit the authorization assigned to a super-role. A root-role may exist thatgives default authorization to all sub-roles. Thus, a hierarchical definition of rolescan simplify authorization management dramatically.� Roles allow a client to sign at the lowest access-level needed.

Chapter 5

Key Establishment Protocols

The goal of this chapter is to give an overview of key establishment protocols and stan-dards found in literature, and to show what security goals they provide. The protocolsdescribed in this chapter do not only establish a session key between the peers, but doalso authenticate at least one peer to the other. The chapter does not cover the initialdistribution of symmetric keys, or the distribution and verification of public-key certifi-cates. It assumes that either symmetric keys have already been distributed, or that thecommunicating peers have the possibility to verify the counterparty’s public-key certifi-cate and download it if necessary.One can distinguish key establishment protocols using two criteria [7].

1. The cryptographic keys that are available a priori (symmetric or asymmetric).

2. The session keys generated.

The second criteria covers two different key establishment types. Key Transport Protocolsand Key Agreement Protocols. According to [7] and [2], key transport protocols transfer akey, created by one of the peers, to the other, and a key agreement protocol is a protocol,in which the session key is a function of inputs provided by both peers. This chapter alsofollows this separation because of two reasons: First, computation based on asymmetrickeys is very time consuming on resource constrained devices [13] and [14], and second,key agreement protocols often achieve a security goal that key transport protocols cannotprovide: Forward Secrecy. This means that if a long-term key is compromised, sessionkeys, that were previously established using this long-time key, cannot be compromised,too. Key transport protocols use this long-term key to encrypt session-keys before trans-mitting it, and therefore cannot provide forward secrecy [7] and [2].Basically there are two approaches to follow to secure the communication between clientsand brokers using the MQTT publish/subscribe system, not using TCP on the transportlayer. The first is to choose one or more key establishment protocols from literature andimplement it. The second is to adapt, or simply use an API implementing an establishedstandard such as SSH [54], in a way that it fits into the CommsSubsystem. Thus, thischapter also gives an overview of established standards, potentially suitable for use withinthe CommsSubsystem.

23

24 CHAPTER 5. KEY ESTABLISHMENT PROTOCOLS

5.1 Key Transport Protocols using Shared Key Cryp-

tography

Server-less key transport protocols always require that the communicating peers alreadyshare a long-term secret key. This key has to be distributed in a confidentiality andintegrity protected way. In general, one of the peers taking part on the protocol createsa session key and transports it in a confidential and integrity protected way to the other.

5.1.1 Janson-Tsudik 2PKDP Protocol

The Janson-Tsudik two Party Key Distribution Protocol [30] provides authentication ofboth peers as well as key establishment. The protocol makes use of bitwise exclusive-or toprovide confidentiality, and of a Message Authentication Code (MAC or HMAC) [25] toprovide authentication. Figure 5.1 shows the protocol-flow. Here Ks is referenced as thesession key, K[message] as a MAC of ”message” computed using the shared long-time keyand K[[message]] means a message that is encrypted but not integrity protected. Further,the following definitions are used:

AUTH = K[N(A), Ks, B]

MASK = K[[AUTH ]]

A B Message

---------------------------------------------------------------------

-------> A,N(A)

<------- AUTH,MASK xor Ks

-------> K[N(A),Ks,A]

Figure 5.1: Janson-Tsudik 2PKDP Protocol

Using the terms of a publish/subscribe system, the client (A) sends in the first messageits client ID and a nonce to the broker (B). In the second message, the broker generatesa new session key and computes the two values AUTH and MASK using the long-termkey K. The second part of this message is similar to the encryption with a one-time-pad[2]. Therefore, MASK should be as long as Ks. Upon receiving the second message,the client decrypts the received AUTH with K. This value allows now the decryption of(MASK XOR Ks) to receive the session key Ks. The client can now compute AUTH =K[N(A),Ks,B] and compare it to the AUTH it received from the broker. This proves thatthe broker shares the same key with the client and that the received Ks is correct. Further,it proves that Ks is a new session key and not a replayed one. The third message is similarto the AUTH, but contains the client ID. The broker can now verify this message to getconfirmation that the client possesses the same long-time key, as well as that the clientreceived the session key correctly. According to [30] this protocol uses a minimal numberof messages and a minimum message size to achieve authentication and key distribution.

5.2. KEY AGREEMENT PROTOCOLS USING SYMMETRIC CRYPTOGRAPHY 25

5.1.2 ISO/IEC 11770-2 Server-Less Protocols

Among the six server-less protocols in the ISO/IEC 11770-2 standard [26], three are keytransport protocols and described here. The remaining three are described in the Section5.2. The simplest protocol only consists of a single message (Figure 5.2). A generates asession key and sends it encrypted to B. A cannot be sure that B really received the keyand B does not know if the key received from A is a newly generated or if it has beenreplayed. The only thing that is guaranteed is that only A and B are able to access thesession-key and B has the assurance that A is aware of it.

A B Message

---------------------------------------------------------------------

-------> K(Ks)

Figure 5.2: ISO/IEC 11770-2 Key Establishment Mechanism 2

The protocol in Figure 5.3 adds a timestamp and B’s identity to the message. In additionto the protocol shown in Figure 5.2 B can also verify that the key received from A isfreshly generated.

A B Message

---------------------------------------------------------------------

-------> K(T(A),B,Ks)


The last key transport protocol using symmetric cryptography of the standard achievesthe same goals, but instead of using a timestamps it uses nonces as shown in Figure 5.4.

A B Message

---------------------------------------------------------------------

<------- N(B)

--------> K(N(B),B,Ks)


5.2 Key Agreement Protocols using Symmetric Cryp-

tography

Key agreement protocols using symmetric cryptography rely on a long-term shared key,too. In comparison to the key transport protocols, both peers deliver some input to thekey, and these protocols achieve Forward Secrecy.


5.2.1 Boyd Two-Pass Protocol

In [5] a classification of key agreement protocols is introduced as well as basic protocolexamples. The classification is made on regards to Key-Oriented Goals [7]. In comparisonto User-Oriented Goals, they cover only properties concerning the key itself, such asthe ability to verify that a generated session key is new and not replayed, and that aneavesdropper is not able to find the session-key. User-oriented goals cover the problem ofentity authentication. In most cases, both user- and key-oriented goals are desirable, in away that an assurance can be made that only authenticated peers are able to run the keyagreement protocol, or that the key agreed during the protocol run has really been agreedwith the intended communication partner. However, one of the protocols outlined in [5]and [7], that only guarantees key-oriented goals, is shown in Figure 5.5. Both parties apriori agree on a function f , used to create the session key Ks = f(N(C), N(B), K). f

is a so called key derivation function. Here, N(C) and N(B) are random nonces createdby either the client or the broker, and not functions. According to [5] a combination ofMACs, such as f(N(C), N(B), K) = MAC[K](N(C))xorMAC[K](N(B)), can be usedas a key derivation function. MAC[K](input) is a MAC calculated with the long time keyK over ”input”.

A B Message

---------------------------------------------------------------------

-------> N(A)

<------- N(B)

Figure 5.5: Boyd two-pass Protocol

After both peers exchanged their random numbers, they calculate the session-key usingf , with both nonces and with the long time key as input. Once again, the protocol doesnot provide authentication, but assurance that only the intended communication partneris able to generate the session-key.

5.2.2 ISO/IEC 11770-2 Server-Less Protocols

The key agreement protocols of this standard make also use of a key derivation functionto generate the session key from two or more inputs. According to [26] this can either bea bitwise exclusive-or of the inputs or a hash to the concatenated inputs. The simplestprotocol is a single message. A timestamp generated by A is encrypted and sent to B(Figure 5.6). Afterward, both peers calculate the session-key Ks = f(K, T (A)) wheref is the key derivation function. Neither A nor B can be sure that the communicationpartner generated the (same) session-key, but both know, that as long as their long-timekey is kept in secret, only the counterparty is able to generate the session-key.

5.3. SERVER-BASED PROTOCOLS USING SYMMETRIC CRYPTOGRAPHY 27

A B Message

---------------------------------------------------------------------

-------> K(T(A))


Mechanism 5 of the ISO/IEC 11770-2 standard, shown in Figure 5.7, is constructed fromtwo instances of mechanism 3, visualized in Figure 5.3. But instead of one peer choosingthe session-key, both peers provide the other with some key material. After the protocolruns are finished, both generate the session key using a key derivation function f such asKs = f(F (A), F (B)), where F (A) and F (B) are the key materials.

A B Message

---------------------------------------------------------------------

-------> K(T(A),B,F(A))

<------- K(T(B),A,F(B))


This protocol assures to both peers that the generated session-key is fresh and only knownto the communication partner. In addition, A is assured that B really has possession ofthe new secret-key.The last server-less mechanism of this standard, mechanism 6, follows the same idea asmechanism 5, but uses nonces instead of timestamps. This protocol is shown in Figure 5.8.Because both nonces are included in message 2 and 3, the protocol additionally assuresthat both messages belong to the same protocol run.

A B Message

---------------------------------------------------------------------

<------- N(B)

-------> K(N(A),N(B),B,F(A))

<------- K(N(B),N(A),A,F(A))


5.3 Server-Based Protocols using Symmetric Cryp-

tography

In literature, numerous server-based key establishment protocols exist. A lot of them arebased on the idea of the Needham and Schroeder Protocol [37]. The most important, anda de-facto standard, is the Kerberos protocol [31]. It will be described later in Subsection5.6.3. All server based protocols have in common that the peers share a secret key witha KDC (S), and the KDC is responsible to negotiate a session key between the peers.


In some protocols the server is the single instance that controls the input for sessionkey generation, in other protocols either one peer, both peers or both peers and theKDC deliver input to the key derivation function. According to [2] and [7] the followingalternatives to Kerberos exist:� Yahalom Protocol [8]� 3PKDP [30]� Optimized 3PKDP [30]� Gong Alternative Protocol [21]� Boyd Four-Pass Protocol[6]

Only protocols that achieve similar or stronger security in comparison to the Kerberosprotocol are listed above. Besides these, many other protocols exist in literature thateither do not guarantee to both peers that the created session key is fresh (not replayed),or that do not proof to both parties that the communication partner is really in possessionof the key, and therefore ready to participate on the secured communication. The latterproperty is not a primary security goal, but of rather practical use in order to reducecommunication failures and therefore network traffic.

5.3.1 Yahalom Protocol

The Yahalom Protocol [8] is suspected to be vulnerable, but so far, no vulnerability hasbeen found [7]. Figure 5.9 shows the message flow of this protocol. K(AS) and K(BS)represent the keys the peers share with the KDC (S) and K(AB) represents the sessionkey.

A B S Message

---------------------------------------------------------------------

-------> A,N(A)

--------> B,K(BS){A,N(A),N(B)}

<---------------- K(AS){B,K(AB),N(A),N(B)},K(BS){A,K(AB)}

-------> K(BS){A,K(AB)},K(AB){N(B)}

Figure 5.9: Yahalom Protocol

The first part of the third message proves to A that the session key K(AB) is not a replayfrom a previous protocol run, because it includes its nonce. The situation for B is moredifficult. The forth message gives only a proof that K(AB) was used recently by A. Only ifA acts properly, and forwards K(BS)A,K(AB), received from S correctly, it can be assuredthat the key is fresh.

5.3. SERVER-BASED PROTOCOLS USING SYMMETRIC CRYPTOGRAPHY 29

5.3.2 3PKDP and Optimized 3PKDP

The Three Party Key Distribution Protocol (3PKDP) [30] performs two executions ofthe 2PKDP described in Subsection 5.1.1. It achieves both key establishment and entityauthentication. The Optimized 3PKDP combines messages together and therefore needsfewer message exchanges. This protocol is shown in Figure 5.10. Here N(A) and N(B) arenonces, generated by A and B for use with the KDC, and N’(A) and N’(B) are nonces foruse between the peers. AUTH(A), AUTH(B), MASK(A) and MASK(B) have the samemeaning as AUTH and MASK in Subsection 5.1.1, but they refer to A or B, and aretherefore encrypted respectively integrity protected with K(AS) or K(BS).

A B S Message

--------------------------------------------------------------------------------

-------> A,N(A),N’(A)

--------> A,B,N(A),N(B)

<-------- AUTH(A),MASK(A) xor K(AB),AUTH(B),MASK(B) xor K(AB)

<------- AUTH(A),MASK(A) xor K(AB),K(AB){N’(A),N’(B),B},N’(B)

-------> K(AB){N’(A),N’(B),A}

Figure 5.10: Janson-Tsudik Optimized 3PKDP Protocol

5.3.3 Gong’s Alternative Protocol

The protocols described in [21] are all key agreement protocols rather than key transportprotocols. So both peers, A and B, provide some random input, that is used to createthe session key on both sides. Here, the KDC authenticates the inputs origin and deliversit to the intended communication partner. A and B then calculate the session key asf(k(A), k(B)), where f is a on-way hash function and k(A) and k(B) are some input fromA and B. The protocols are designed to use as few messages as possible, but not to reducemessage size. There are some redundant fields in the messages such as the enclosure ofa sender, a recipient, a sender ID and a recipient ID field. Figure 5.11 shows the Gong’sAlternative Protocol that provides both parties with a proof that the session key is fresh,that the key is only known to the two parties and the KDC, and that both parties are inpossession of the session key.

A B S Message

--------------------------------------------------------------------------------

-----------------> A,B,K(AS){A,S,A,k(A),B},N(A)}

<--------- A,B,K(BS){S,B,A,k(A),B),N(A)}

---------> K(BS){B,S,B,k(B),A},K(AB){B,A,N(A)},N(B)

<----------------- K(BS){S,A,B,k(B),A},K(AB){B,A,N(A)},N(B)

-------> K(AB){A,B,N(B)}

Figure 5.11: Alternative Gong’s Protocol


5.3.4 Boyd Four-Pass Protocol

In [6] a protocol is introduced in which all three parties deliver input to the key deriva-tion function. As shown in Figure 5.12, the protocol only uses four messages. Here,K(AB)[N(A)] and K(AB)[N(B)] means a MAC of N(B) and N(B), using the session keyK(AB).

A B S Message

--------------------------------------------------------------------------------

-----------------> A,B,N(A)

<--------- K(AS){A,B,K(S)),K(BS){A,B,K(S)}.N(A)

<-------- K(AS){A,B,K(S)},K(AB)[N(A)],N(B)

--------> K(AB)[N(B)]

Figure 5.12: Boyd Key agreement protocol

The values N(A) and N(B) are used as input to the key derivation function, as well asK(S), generated by the KDC. A keyed hash function, respectively a HMAC or MAC, isused to generate the session key K(AB) = MACK(S)(N(A), N(B)). The protocol assuresto both A and B, that the key has not been used before, that the key is only known toA, B and S, and that the communication partner really has possession of the session key.

5.4 Key Transport Protocols using Asymmetric Cryp-

tography

5.4.1 ISO/IEC 11770-3 Key Transport Mechanism 1

The ISO/IEC 11770 Part 3 [27] standard specifies six key transport protocols. The sim-plest protocol in the standard is shown in Figure 5.13. The term K(B){message} meansan encryption of ”message”. with the public key of peer B.

A B Message

---------------------------------------------------------------------

-------> K(B){A,K(AB),T(A)}

Figure 5.13: ISO/IEC 11770-3 Key Transport Mechanism 1

This protocol gives A the assurance that K(AB) is fresh and only known to itself and B.Out of the point of view of B, this assurance is not achieved. B is even not sure if themessage really originates from A.

5.4. KEY TRANSPORT PROTOCOLS USING ASYMMETRIC CRYPTOGRAPHY31


The protocol shown in Figure 5.14 solves these problems. Here, the term K(A)[M] isreferenced as a signature of message M generated with the private key of A.

A B Message

---------------------------------------------------------------------

-------> B,T(A),K(B){A,K(AB)},K(A)[B,T(A),K(B){A,K(AB)}]


The special thing in this protocol is that A signs an encrypted message. This is usuallyavoided because the receiver cannot be sure if the sender is really aware of the plaintext[7], [2] and [10]. Using this protocol, B has to trust in A that A only signs keys it createdby itself, otherwise B has no assurance that the session key K(AB) is really generated byA.


The protocol in Figure 5.15 changes the order in which signature and encryption areperformed, and therefore solves the problem mentioned above.

A B Message

---------------------------------------------------------------------

-------> K(B){B,K(AB),T(A),K(A)[B,K(AB),T(A)]}



The next protocol in the standard describes a solution that addresses the problem of theprotocol in Figure 5.14 in a different way. It uses two messages and a nonce instead ofa timestamp. This assures that the message B receives is really originated from A. Theprotocol is shown in Figure 5.16.

A B Message

----------------------------------------------------------------------------

<------- N(B)

-------> B,N(B),N(A),K(B){A,K(AB)},K(A)[B,N(B),N(A),K(B){B,K(AB)}]




The protocol in Figure 5.17 transports one key from A to B (K(AB)) and another keyfrom B to A (K(BA)). The standard proposes that both keys can be combined to a singlesession key, or that one uses both keys for a single direction. Using different keys fordifferent directions has the advantage that it is impossible to force one party to encryptsomething, and inject it in a later protocol run [10]. In addition to the previous protocols,it achieves authentication of both peers.

A B Message

----------------------------------------------------------------------------

-------> N(A)

<------- N(B),N(A),A,K(A){B,K(BA)},K(B)[N(B),N(A),A,K(A){B,K(BA)}]

-------> N(A),N(B),B,K(B){A,K(AB)},K(A)[N(A),N(B),B,K(B){A,K(AB)}]



The last protocol in the standard only uses encryption and no signatures, although thepeers are authenticated. Figure 5.18 visualizes the protocol messages. It achieves thesame security goal as the protocol in Figure 5.17

A B Message

----------------------------------------------------------------------------

-------> K(B){A,K(AB),N(A)}

<------- K(A){B,K(BA),N(A),N(B)}

-------> N(B)


5.5 Key Agreement Protocols using Asymmetric Cryp-

tography

Key agreement protocols using asymmetric cryptography are the most common group ofkey agreement protocols. Standards like The Secure Shell Protocol (SSH) [53] or SSL/TLSmake also use of them. Most of these protocols are based on the idea of the Diffie-HellmanProtocol [16]. This protocols allow two parties the negotiation of a shared secret over aninsecure communication link, that often achieves forward secrecy [7]. Because the Diffie-Hellman protocol lacks any authentication, it is vulnerable to man in the middle attacks[2], [7] and [10]. Therefore, all these protocols add some kind of authentication to theoriginal Diffie-Hellman protocol messages. Some of them use the mathematical relationbetween public and private keys, and process these keys with the parameters calculated for

5.5. KEY AGREEMENT PROTOCOLS USING ASYMMETRIC CRYPTOGRAPHY33

Diffie-Hellman mechanism. Other use asymmetric cryptography in order to authenticateand integrity protect the messages exchanged between the peers during the protocol-run.Besides the Diffie-Hellman based protocols there exist others that use random numbersas input to a key derivation function. These random numbers are encrypted and integrityprotected with asymmetric cryptography before sent over the network.Key agreement protocols using asymmetric cryptography are the most complex of all keyestablishment protocols. They often do not only consist of the protocol itself, but alsoof a key generation algorithm based on the computational expensive idea of Diffie andHellman. There are some protocols that face this problem by making the required com-putational effort reside on one side [7].Table 5.19 shows an abstracted version of the SSL/TLS protocol performing a Diffie-Hellman key agreement. In the first two messages, A sends a random value to B, and Bresponses with another random value, Message1 and Sig(A){Message1}, which is referredas a signature of Message1 using the private key of B. Message1 contains parameters cre-ated by B to generate the Diffie-Hellman secret [16] and [53]. Then, A generates its Diffie-Hellman parameters, calculates the session key, and sends K(AB)[Message1,Message2]back to B, which is a HMAC of Message1 and Message2. The random values, sent at thebeginning of the protocol, are also used as input to the key derivation function [53]. AfterB has generated the session-key, it is able to verify that A has generated the same key, byverifying the received HMAC. Within the next message, B proves to A that both agreedon the same session-key.

A B Message

----------------------------------------------------------------------------

-------> N(A)

<------- N(B),Message1,Sig(B){Message1},

-------> Message2,K(AB)[Message1,Message2]

<------- Message3,K(AB)[Message1,Message2,Message3]

Figure 5.19: Abstracted SSL/TLS Diffie-Hellman Key Agreement

5.5.1 Key Broadcasting Protocols

Besides key agreement protocols between two parties, protocols have been designed whichhave the agreement of a session key, involving more than two parties, as goal. With socalled Conference Key Agreement Protocols a group of communicating peers agree togetheron a session key. Because all peers in this group have to be aware of each other, theseprotocols do not fit into a publish/subscribe system, where each client is usually only awareof a message broker. More interesting for use within a publish/subscribe system are KeyBroadcasting Protocols. The idea of these protocols is that a session key, generated by thebroadcaster, is securely transported to all relevant peers. In [11] a proposal using numbertheory has been made. Other protocol proposals make use of preshared symmetric keys,to encrypt the broadcasted session key [7]. In contrast to some conference key agreementprotocols, they do not focus the problem of peers joining or leaving the broadcast-group,and are not that extensively investigated.


5.6 Standards

This section covers the SSL/TLS, the SSH and the Kerberos standards. The intention isto summarize the necessary information in order to investigate how good these standardsfit into the CommsSubsystem. Thus, the focus is not only on the message flow but alsoon the way encryption is done and on what is passed to the transport layer.

5.6.1 TLS

The TLS and the SSL protocols are very similar in terms of what data is passed to thetransport layer, how the security parameters, such as a shared keys, are negotiated, andhow authentication is done. The mayor difference is that TLS uses different keys forencryption in each direction [15] and [10]. This subsection covers the TLS protocol as itis described in [15]. The protocol provides an encrypted channel and integrity protectedcommunication. Authentication is optional and in most cases only used to authenticatethe server to the clients.The TLS protocol consists of an handshake mechanism, to negotiate the security parame-ters, and of a message format to exchange the protected payload. The security parametersare [15]:� Connection End: Whether an entity is considered to be a client or a server for this

connection.� Bulk Encryption Algorithm: The algorithm to use for encryption and the key-length.� MAC Algorithm: Algorithm used for message authentication.� Compression Algorithm: The algorithm to use for plaintext compression, might benull.� Master Secret: A 48 byte secret shared between the peers.� Client Random: A 32 byte value generated by the client.� Server Random: A 32 byte value generated by the server.

These security parameters are used to generate the following items:� Client Write MAC Secret: Value to calculate and verify the HMAC in the client-to-server direction.� Server Write MAC Secret: The secret used in the other direction.� Client Write Key: The session key used in the client-to-server direction.� Server Write Key: The session key for the other direction.

5.6. STANDARDS 35� Client Write IV: The initialization vector [2] used in client-to-server direction.� Server Write IV: The initialization vector for the other direction.

Starting from the first message, all communication is encapsulated into the so calledTLS Record as shown in Figure 5.20. The figure represents a TLS record message of typeApplicationData. Within this record the HMAC is encrypted too, which is of no use. Otherrecord types are: ChangeCipherSpec, Alert and Handshake. In case of handshake records,the payload starts with a one byte Handshake Type field and a three byte HandshakeLength field.

Figure 5.20: TLS record

TLS HandshakeIf the client requests a TLS connection, it first sends a ClientHello (handshake type) tothe server. The server responds with a ServerHello. After this message exchange, theprotocol version, a session ID, the ciphersuite, the compression method and the client-and server random are agreed. The ciphersuite describes the cipher-algorithm, the key-exchange method, and the hash algorithm for further use. Figure 5.21 visualizes thismessage exchange. In this figure the messages in parentheses may not necessary be sent.These are sent in dependence of the chosen ciphersuite or the authentication capabilities.If, for example, the server has a key that is only usable for signing, the ServerKeyExchangemessage is sent, too. This message contains the necessary information to perform a Diffie-Hellman key agreement. If the server’s public key can be used for encryption, it will only


send the Certificate message instead. Now, the server may request the client’s certificateand send the ServerHelloDone message afterward. The client is now able to check thesignature of the server’s certificate. The check itself is not part of the TLS protocol,and is usually done on the application layer. If the check fails, an alert message is sentto the server and the handshake is aborted. Otherwise, the client sends optionally itscertificate. The ClientKeyExchange message contains either the encrypted PremasterSecret or its Diffie-Hellman parameters. In the optional CertificateVerify message, theclient proves that it knows its private key. The ChangeCipherSpec message indicatesthat all the necessary security parameters have been received on this side, and that thecounterparty may now use the negotiated master secrets in the following messages. Thus,the Finished message is the first message that makes use of them. It proves that thesender has really possession of the keys, and that the keys are correct.

Client Server Handshake Type

---------------------------------------------------------------------

-------> ClientHello

<------- ServerHello

(Certificate)

(ServerKeyExchange)

(CertificateRequest)

ServerHelloDone

-------> (Certificate)

ClientKeyExchange

(CertificateVerify)

ChangeCipherSpec

Finished

<------- ChangeCipherSpec

Finished

<------> Application Data

Figure 5.21: TLS Handshake

Session ResumptionA TLS session has its unique session ID, defined by the client, and sent within theClientHello message. This session ID is cached on both sides and can be used to reestablisha terminated session. This procedure is shown in Figure 5.22.

5.6. STANDARDS 37

Client Server Handshake Type

---------------------------------------------------------------------

-------> ClientHello

<------- ServerHello

ChangeCipherSpec

Finished

-------> ChangeCipherSpec

Finished

<------> Application Data

Figure 5.22: TLS Session resumption

Key CalculationOnce a ChangeCipherSpec has been received, the receiving side has to use the negotiatedciphers. Therefore, it first creates the so called Master Secret using a Pseudo RandomFunction (PRF):MasterSecret = PRF (PreMasterSecret, ”mastersecret”, ClientRandom+ServerRandom).The PRF is an iterative function and produces more output the more iteration it goesthrough. This characteristic is used to calculate the Key Block and partitionate it intothe session keys, MAC secrets, and initialization vectors:KeyBlock = PRF (MasterSecret, ”keyexpansion”, ServerRandom + ClientRandom).

Application Data ProcessingAs soon as the handshake is finished, the application data can be encrypted and integrityprotected. Therefore, the application data is first divided into fragments of at most 16kilobytes. The fragment is then compressed. The compression method might be ”null”. Inthe case the application has already compressed its data, and compression has been chosenin the TLS protocol, the resulting compressed fragment must not exceed 17 kilobytes. Inorder to integrity protect the compressed fragment a HMAC of either 16 or 20 bytesis appended to the compressed fragment. The HMAC is not only calculated over thefragment but also over a sequence number. There is a sequence number for each directionstarting from zero, but it is not transmitted. In order to be able to encrypt the fragment,a padding has to be added to the fragment concatenated with the HMAC. The paddinglength is not specified exactly, but it must not exceed 255 bytes. The final task is toencrypt this data. The encrypted data must not be larger then 18 kilobytes. Beforedelivering to the transport layer, a header of 5 bytes is added as shown in Figure 5.20.


5.6.2 SSH

The Secure Shell (SSH) protocol as described in [53], [54], [51] and [52] can not only beused for remote interactive sessions, but theoretical for any kind of data transfer. Further,it supports tunneling facilities for TCP/IP services. This flexibility stems from its layereddesign. The major components of the SSH protocol are:� The Transport Layer Protocol, that provides server authentication, confidentiality,

integrity and optionally compression.� The User Authentication Protocol, which authenticates the client to the server andruns over the transport layer protocol.� The Connection Protocol, that multiplexes the encrypted session into multiple logicalchannels. It runs over the user authentication protocol.

The SSH packets that are delivered to the transport layer are usually in the so calledBinary Packet Format [51]. This general packet structure is shown in Figure 5.23.

Figure 5.23: SSH: Binary Packet Format

The SSH implementation must be able to process 32768 bytes of uncompressed payloadand at least a maximal packet size of 35000 bytes.

5.6. STANDARDS 39

SSH Key AgreementThe key agreement process takes part if a client wishes to start a secured connectionto a server, or if new keys have to be agreed for an existing connection. The standardsuggests that new keys should be agreed every hour, or after 1 GB of transferred data. If aclient starts the key agreement process, it first sends an Identification String, representingthe SSH protocol version and its software-version. Then, the server responds with itsidentification string, and may add arbitrary lines of data, that are not relevant for theprotocol itself. The purpose of this identification string is that it eases the agreementupon an encryption method to use, because often the implementations default encryptionsettings are chosen by the peers. After these messages, the following communication usesthe binary packet format. Figure 5.24 shows the process of a key exchange.

Client Server Message

------------------------------------------------------------------------------

-------> identification string

<------- identification string, eventually additional data

-------> SSH_MSG_KEXINIT

<------- SSH_MSG_KEXINIT

-------> SSH_MSG_KEXDH_INIT

<------- SSH_MSG_KEXDH_REPLY

-------> SSH_MSG_NEWKEYS

<------- SSH_MSG_NEWKEYS

Figure 5.24: SSH: Key Exchange

The SSH MSG KEXINIT messages are used to agree on a set of encryption algorithms,MAC and compression algorithms, as well as on the key exchange method. Accordingto [54], the only specified key exchange methods are Diffie-Hellman based. Within theSSH MSG KEXDH INIT message, the client sends its Diffie-Hellman parameter to theserver. The server responds with its parameter, a signature of a value H, that is a hashof the identification strings, the SSH MSG KEXINIT messages, the servers public key.Further, the server sends the shared Diffie-Hellman secret (K) back, it is now able togenerate. As soon as the client received this SSH MSG KEXDH REPLY message, it canalso calculate H and K, and verifies the signature, which proves the identity of the serveras well as proves to the client that the server shares the same secret values H and K. Theverification can either be done with a check against a local database or with a certifiedserver-to-key association.

Key CalculationAfter the verification of the server’s identity, both sides calculate for each direction aninitialization vector, an encryption key, and an integrity key. All these calculations aredone in an identical fashion by using a hash function. The only things that differ aresome defined constants. The initialization vector for client to server communication iscalculated as a hash of the concatenated values K, H, ”A” and session id, where thesession id is equal to the H of the first key agreement. The initialization vector for serverto client communication is calculated the same way using the constant ”B”, the encryption


keys is calculated with the constants ”C”and ”D”and the integrity keys with ”E”and ”F”.As soon as the peers have calculated the keys and initialization vectors, they exchange theSSH MSG NEWKEYS messages. These consist of a single byte payload within a binarypacket. If this is an initial key establishment process, the messages are not encrypted, ifnot, these are the last messages that are encrypted and integrity protected using the oldkeys.

Client AuthenticationAfter the keys are established, the client sends a SSH MSG SERVICE REQUEST, thatindicates the start of the User Authentication Protocol [51]. The server can accept therequest or disconnect the client. If the server accepts the request, the user authenticationprotocol starts with the SSH MSG USERAUTH REQUEST sent by the client, continueswith authentication method specific message exchanges, and ends with a success or failuremessage from the server.

Connection ProtocolThe application data is transported within the connection protocol. To indicate to theserver that a new channel has to be established, the client sends a SSH MSG CHANNEL OPENmessage, including the channel type it requests. The server responds with a confir-mation or with a failure message. The application data is then transported withinSSH MSF CHANNEL DATA messages.

5.6.3 Kerberos

Kerberos is a secret key based service to authenticate peers in a network and to distributesession keys between them [31]. The system was originally designed for an environmentwhere clients use username and password to authenticate themselves to a service [45].The Kerberos system consists of an Authentication Server (AS) and a Ticket GrantingServer (TGS) as well as of clients and of the Application Servers (AP), the clients wantto access. All peers share a secret key, in most cases encrypted with a password basedencryption algorithm, with the AS and the TGS. AS and TGS therefore use both thesame database of shared keys, and run usually on the same machine. They build togetherthe KDC. Usually the clients do only know the password to decrypt the shared key, andthe AP use a symmetric key for the same purpose.Figure 5.25 shows a simplified message exchange between a client and the AS. First, theclient sends its identity to the AS. The AS now reads the client’s key, referred as K(A),out of its database. The key is used to decrypt a session key, used between the AS andA, referred as S(A), as well as to decrypt the so called Ticket Granting Ticket (TGT).The TGT is basically the identity of A and S(A), encrypted with a symmetric key onlyknown to the KDC. The TGT also contains a timestamp, indicating its lifetime. The useof the TGT is that the KDC does not have to store a table, containing the clients thathave already been authenticated, and that are now allowed to request a session key to aAP. A successful decryption of the TGT out of the second message is a proof to the KDC,that the client is authorized to request session-keys.

5.6. STANDARDS 41

A AS Message

----------------------------------------------------------------------------

-------> A

<------- K(A)[S(A),TGT]

Figure 5.25: Kerberos: Obtaining a Ticket Granting Ticket

Now, the client is in possession of a TGT and of S(A), the shared key usable to securelycommunicate with the KDC. It can now request a session key for communication to theAP with identity B, as shown in Table 5.26.

A TGS Message

----------------------------------------------------------------------------

-------> TGT,S(A)[T(A)]

<------- S(A)[B,K(AB), ticketToB]

Figure 5.26: Kerberos: Obtaining a Ticket

As soon as the first message arrives at the TGS, it decrypts the TGT using its secretkey. The TGT contains S(A), and with S(A) the TGS now decrypts the timestamp T(A).If the TGT was still valid at the time T(A) was created, the request is accepted, andthe TGS creates the session-key K(AB) A and B will use. It also creates the ticketToBwhich mainly consists of this session key, an expiration time, and the identity of A. In thelast step the peers mutually authenticate each other as shown in Figure 5.27. A sendsthe ticketToB to B, and B decrypts it with its secret key to retrieve K(AB). In the lastmessage B proves to A that it has been able to decrypt the ticket.

A B Message

----------------------------------------------------------------------------

-------> ticketToB,K(AB)[T(A)]

<------- K(AB)[T(A)+1]

Figure 5.27: Kerberos: Login into an Application Server

The Kerberos protocol authenticated A to B and B to A, and assured that the establishedsession key is only known to A, B and the KDC. Further, it proves to A that K(AB) hasbeen newly created. Out of the point of view of B, this is not achieved. But B will acceptK(AB) as long as the ticket has not expired. Further, the lack of this prove to B makes itpossible for the client to cache the ticket and use it for future communication within thetickets validity.


Chapter 6

Evaluation of Authentication andEncryption Mechanisms

This chapter investigates the outlined key establishment protocols and standards, as wellas the access control mechanism of Chapter 4 and 5 in order to be able to choose themost appropriate method-combination for the most common deployment scenarios of theMicrobroker, under the restrictions outlined in Section 1.3. In case of MQTT, the com-munication overhead and the configuration costs play an important role. Some protocolsare designed to provide different security goals than others, therefore an overview of thesecurity goals they provide is given. Another important role are the computational costsneeded during the protocol run. This is difficult to estimate and depends much on thechosen cryptographic algorithms. A way to compare the computational costs of the dif-ferent protocols is to count the number of hash computations, symmetric encryption anddecryption processes, the number of cryptographic private- and public-key operations, andthe number of random-number generations a protocol needs. According to experimentsmade in [39] and [24] using resource limited devices, a rough estimation is that hashfunc-tions are similar complex as symmetric key operations. Asymmetric operations, based ona public key are more or less ten times more expensive as symmetric key operations, andoperations based a private key hundred times more expensive. Random numbers can begenerated using hash functions, and are therefore comparable to symmetric key and hashoperations. At the end of this chapter a conclusion, based on these investigations, is made.

The different authentication and key agreement protocols are investigated using the fol-lowing security goals:� Key Freshness: The property a session-key has been created newly and has not been

replayed.� Key Authentication: The key is known only to A and B and any mutually trustedparties.� Good Key: A key is good if it is fresh and authenticated.

43

44CHAPTER 6. EVALUATION OF AUTHENTICATION AND ENCRYPTION MECHANISMS� Key Confirmation: Key confirmation of A to B is provided if B has assurance thatkey K is a good key to communicate with A, and that A has possession of K.� Entity Authentication: Assurance to one peer of the other peer’s identity, and thatthe second has actually participated on this protocol run.� Forward Secrecy: The property that, if a long-term key has been compromised,session keys, that were previously established using this long-time key, cannot becompromised, too. Forward secrecy is assured for all key agreement protocols basedon the Diffie-Hellman key exchange mechanism.

In order to quantify the configuration costs needed to run the different protocols, theconfiguration complexity is described as a function of the numbers of clients and thenumbers of brokers. The following terminology is used in this chapter:� c means number of clients.� b means number of brokers.� S means constant costs to creating a signature.� D means constant costs to distribute something to the peers.� SKG means the constant cost of creating a symmetric key.� AKG means the constant cost of creating a asymmetric keypair.� comp(c, b) is the function describing the configuration complexity.� ”Client configuration” means the configuration complexity on the client side.� ”Broker configuration” means the configuration complexity on the broker side.� ”Additional infrastructure” means additional configuration needs besides client or

broker configuration, e.g. on a third party.

6.1 Configuration Costs

Because of the deployment scenarios the Microbroker is most likely used, it is assumed thatno long term keys and certificates are created directly on the clients or on the brokers. Allkey and signature creation is done by a centralized configuration entity, that can securelyaccess the peers to distribute the created keys, certificates or passwords. Therefore, it isnot distinguished between distribution costs for security related information, that have tobe confidentiality and integrity protected, and for data that do not need any protection.Because of the centralized administration, the configuration costs to secure the MQTTpublish/subscribe system play an important role. Table 6.1 gives an overview of theconfiguration complexity occurring to create and distribute either passwords, capabilitiesor symmetric or asymmetric keys, as well as the configuration costs for a KDC and foran authentication server, acting as a backend to authenticate the clients on behalf of thebrokers using passwords.

6.1. CONFIGURATION COSTS 45

Table 6.1: Configuration complexity

Mechanism Client configura-tion

Broker configura-tion

Additional infras-tructure

Password comp(c, b) = b ∗ c ∗ D comp(c, b) = b ∗ c ∗ D

Authentica- comp(c, 0) = c ∗ D comp(0, b) = b ∗ D

tion serverCapability comp(c, 0) = c ∗ D comp(0, b) = b ∗ D comp(c, b) = c ∗ s +

AKG)Symmetrickey

comp(c, b) = b ∗ c ∗ D comp(c, b) = b ∗ c ∗ D comp(c, b) = b∗c∗SKG

Asymmetrickey

comp(c, 0) = (c+1)∗D comp(0, b) = (b+1)D comp(c, b) = (b ∗AKG) + (c ∗ AKG) +b ∗ S + c ∗ s

KDC comp(c, 0) = c ∗ D comp(0, b) = b ∗ D comp(c, b) = (b ∗SKG) + (c ∗ SKG)

The distribution of passwords and symmetric keys is similar in complexity. The coststo create the shared keys makes the latter a bit more complex. Because one can encodethe password in the MQTT client ID (Table 3.5), that has to be configured anyway, theusage of passwords on the client side could be interpreted to lead to almost neglectableadditional costs. In any case, the costs are acceptable if clients only connect to a few setof brokers. Both methods do not scale well in a scenario with multiple brokers and mo-bile clients. The usage of an authentication server would reduce this scalability problemdramatically.The configuration of the peers with capabilities or asymmetric keys scales better, butproduces the non neglectable costs of signing the public keys and the capabilities. If thereare only a few brokers running the publish/subscribe system, this overhead might be tobig. If there are many brokers, the usage of capabilities is the cheapest method to doaccess control. There will be no need for an ACL on the brokers.Using a trusted third party reduces the complexity needed to configure the peers in com-parison to the symmetric key based approach significantly. But further costs arise inmaintaining the KDC. The KDC can also be a bottleneck if a lot of clients connect to abroker at the same time, and is a single point of failure. If clients travel between multipleadministrative domains, the availability of a mechanism to deploy the trust in a client tothe foreign domain is needed and has to be configured, too.

6.1.1 Revocation Costs

The costs needed to revoke the different security tokens listed in Table 6.1 are moreor less inverse to their setup costs. It is easy to delete a client out of an ACL, evenif there are multiple brokers. It is also easy to delete a symmetric key and maybe ancorresponding ACL entry. Revocation of an asymmetric key or a capability is muchharder. Certificates can only be revoked by the CA, and a Certificate Revocation List

46CHAPTER 6. EVALUATION OF AUTHENTICATION AND ENCRYPTION MECHANISMS

(CRL) has to be distributed to all peers. Capabilities can only be revoked by its issuer,too. The choice of an accurate lifetime of certificates or capabilities can reduce thisproblem.

6.2 Key Establishment Protocols

Table 6.2 and Table 6.3 summarize the key establishment protocols outlined in Chapter5. They give an overview of the security goals the protocols provide, and of the numberof cryptographic operations needed during the protocol run. In order to give an overviewwhat operations are needed on the peers, the operations on the server are not taken intoconsideration in case of the server based key establishment protocols. The calculations arebased on the assumptions that the generation of a session key has similar complexity asthe generation of a random number and the calculation of a hash value. The assumptionis made based on the fact that session keys, generated during the run of a key agreementprotocol, are calculated by hashing the random values both peers contribute.

Table 6.2: Key Establishment Protocols: Summary

Protocol Freshness Authentication ConfirmationSymmetric Key Transport

Janson-Tsudik 2PKDP yes yes A+BISO/IEC 11770-2 Mechanism 2 yes yes AISO/IEC 11770-2 Mechanism 3 yes yes BISO/IEC 11770-2 Mechanism 4 yes yes B

Symmetric Key Agreement

Boyd two-pass yes yes noISO/IEC 11770-2 Mechanism 1 yes yes BISO/IEC 11770-2 Mechanism 5 yes yes AISO/IEC 11770-2 Mechanism 6 yes yes A

Symmetric Server based

Yahalom yes yes BJanson-Tsudik 3PKDP yes yes A+BGongs alternative yes yes A+BBoyd four-pass yes yes A+BKerberos yes yes B

Asymmetric Key Transport

ISO/IEC 11770-3 Mechanism 1 A A noISO/IEC 11770-3 Mechanism 2 yes yes BISO/IEC 11770-3 Mechanism 3 yes yes BISO/IEC 11770-3 Mechanism 4 yes yes AISO/IEC 11770-3 Mechanism 5 yes yes AISO/IEC 11770-3 Mechanism 6 yes yes A+B

Asymmetric Key Agreement

SSL/TLS like protocol yes yes A+Busing Diffie-Hellman

6.2. KEY ESTABLISHMENT PROTOCOLS 47

Table 6.3: Key Establishment Protocols: Complexity

Protocol Passes Cryptographic OperationsRand Hash Symm Priv Publ

Symmetric Key Transport

Janson-Tsudik 2PKDP 3 1 3 2 0 0ISO/IEC 11770-2 Mechanism 2 1 1 3 2 0 0ISO/IEC 11770-2 Mechanism 3 1 1 3 2 0 0ISO/IEC 11770-2 Mechanism 4 2 2 3 2 0 0

Symmetric Key Agreement

Boyd two-pass 2 2 2 2 0 0ISO/IEC 11770-2 Mechanism 1 1 4 2 0 0ISO/IEC 11770-2 Mechanism 5 2 2 6 4 0 0ISO/IEC 11770-2 Mechanism 6 3 4 6 4 0 0

Symmetric Server based

Yahalom 4 2 4 4 0 0Janson-Tsudik 3PKDP 5 3 3 4 0 0Gongs alternative 5 4 0 8 0 0Boyd four-pass 4 2 6 2 0 0Kerberos 3 0 0 7 0 0

Asymmetric Key Transport

ISO/IEC 11770-3 Mechanism 1 1 1 1 0 1 1ISO/IEC 11770-3 Mechanism 2 1 1 1 0 2 2ISO/IEC 11770-3 Mechanism 3 1 1 1 0 2 2ISO/IEC 11770-3 Mechanism 4 2 3 1 0 2 2ISO/IEC 11770-3 Mechanism 5 3 4 2 0 4 4ISO/IEC 11770-3 Mechanism 6 3 4 2 0 2 2

Asymmetric Key Agreement

SSL/TLS like protocol 4 2 8 0 1 2using Diffie-Hellman

The last row of Table 6.3 is based on the abstract version of the SSL/TLS key agreementprotocol described in Section 5.5, where only one peer authenticates itself to the other.The costs to verify this peers certificate is included in the table, too. Because the keys areagreed based on the idea of Diffie and Hellman [16] the costs of creating the Diffie-Hellmansecret have to be added to the listed complexity. The big number of cryptographic hashcalculation is caused by the way the session-key is created.

6.2.1 TLS/SSL and SSH

Key establishment with the SSL/TLS and SSH frameworks allows numerous options thatlead to the run of quite different protocols. Therefore, both are not directly comparableto the protocols in Table 6.2 and Table 6.3. The SSL/TLS framework can be configuredto perform key transport or agreement protocols based on asymmetric keys. The SSH


specification only describes key agreement protocols, but could also be used to performsession key establishment based on key transport. Further, the SSL/TLS protocol can beconfigured to authenticate none of the peers, one of them or to perform mutual authentica-tion, and the SSH specification separates the key establishment and server authenticationprocess and the client authentication process into two different protocols, both config-urable. Both frameworks assure key-freshness, key-authentication and key-confirmationif configured to use at least a certificate on one of the peers. The computational costsneeded during the run of SSL/TLS using a non Diffie-Hellman configuration, is compara-ble to the asymmetric key transport protocols listed in Table 6.3 that achieve the samesecurity goals. If the protocols are configured to perform a Diffie-Hellman key exchange,the complexity is comparable to the ”SSL/TLS like protocol” described in the same ta-ble. If the protocols are configured in a way that they include messages to exchange thepeers certificates, additionally one or two public key operation have to be added. Theseadditional operations are needed to verify the integrity of the received certificate duringeach key establishment process between the peers.

6.2.2 Password based Protocols

Password based protocols have interesting security features. They assure key-freshness,key-authentication, key-confirmation and mutual entity authentication and the peers onlyhave to be configured with a weak secret. The shared week secret leads to the same config-uration complexity as for symmetric key based approaches. But because the protocols arebased on a Diffie-Hellman key exchange, they need more computational ressources. Thus,the password based protocols are especially useful in situations with human interaction,but bring disadvantages in comparison to symmetric approaches if clients act withouthuman interaction.

6.3 Authentication Protocols

In Table 6.4 an overview is given of the authentication protocols outlined in Subsection4.1.3. The table lists for each protocol if it provides unilateral or mutual authentication,the messages that are exchanged during the protocol run, and the number of cryptographicoperations needed. The cryptographic operations are distinguished into random numbergeneration, generation of hash values, and operations based on symmetric, private andpublic keys.

Table 6.4: Authentication Protocols: Summary

Protocol Entity Au-thentication

Passes Cryptographic Operations

Rand Hash Symm Priv PublSymmetric Key based

6.4. CONCLUSION 49

ISO/IEC 9798-2one-pass unilat-eral

unilateral 1 0 2 2 0 0

ISO/IEC 9798-2two-pass unilat-eral


ISO/IEC 9798-2two-pass mutual

mutual 2 0 4 4 0 0

ISO/IEC 9798-2 three-pass mu-tual

mutual 3 2 4 4 0 0

Asymmetric Key based

ISO/IEC 9798-3one-pass unilat-eral


ISO/IEC 9798-3two-pass unilat-eral


ISO/IEC 9798-3two-pass mutual

mutual 2 0 0 0 2 2

ISO/IEC 9798-3 three-pass mu-tual

mutual 3 2 0 0 2 2

ISO/IEC 9798-3two-pass parallel

mutual 2 2 0 0 2 2

Gray variant ofSPLICE/AS

mutual 2 2 0 0 2 2

The computational costs of these mechanisms are comparable to the key establishmentprotocols that use the same cryptographic techniques. The usage of one of these protocolsin the case of the MQTT publish/subscribe system is questinable because a session-keyhas to be established anyway. However, a simple unilateral authentication mechanismcould be used complementary to a key establishment protocol that authenticates one ofthe peers.

6.4 Conclusion

The usage of a symmetric key establishment protocol, enabling encryption and integrityprotection with the agreed session-key, has advantages for simple environments with onlya few brokers and a relatively fixed amount of clients. As soon as the amount of clientschanges frequently, or if there are many brokers, and the client access multiple of them,this approach will lead to enormous configuration costs.A symmetric key agreement protocol, that is suitable for use within the MQTT pub-lish/subscribe system, should at least provide key-confirmation to the client. That means


that the clients have to be aware that the broker is really in possession of the sessionkey, before sending an encrypted MQTT CONNECT to it. Another issue is that theusage of timestamps within such a protocol requires synchronized clocks, which mightnot be possible. Within the remaining protocols, the Janson-Tsudik 2PKDP and theISO/IEC 11770-2 Mechanism 6 seem to be the most interesting ones. They provide mu-tually authentication as well as key confirmation to both parties, and both prove that theexchanged messages belong to the same protocol run. The ISO/IEC 11770-2 Mechanism6 and the Janson-Tsudik 2PKDP seem to be a good choice for environments that have asimple setup, such as a fixed set of clients connecting to only a few brokers. A mechanismfor a module that only authenticates the broker to the client, is the ISO/IEC 11770-2Mechanism 4. It achieves key confirmation and does not make use of timestamps.The configuration costs for a module establishing a session key based on asymmetric cryp-tography scales better. As soon as there are more than one or two message brokers, sucha solution has to be preferred. The SSL/TLS specification brings the advantage that itis configurable and is therefore a solution that fits in many deployments scenarios. It caneither authenticate one peer to the other, or mutually both peers, or none of them. Thechoice if mutually authentication should be configured, can be made in dependence ofthe computational power of the clients. Further, it can be configured to behave as a keytransport protocol, or to act as a key agreement protocol using the Diffie-Hellman mech-anism. So, it provides the choice between lower computational costs or forward secrecy.Although the SSL/TLS protocol leads to more computational needs than a solution basedon symmetric keys, it might even be preferred in the single broker case. In this scenario aCA is not necessary needed. One can distribute the public key of the broker to all clients.The distribution only has to be integrity protected, by doublechecking a hash of the key,and does not need encryption. The client can then verify the integrity of the SSL/TLShandshake messages without a CA. The usage of a CA gives the possibility to do ac-cess control based on capabilities or attribute certificates. This is the best scaling accesscontrol mechanism based on asymmetric keys. It especially reduces the configuration ofthe brokers dramatically, and is preferred in an environment where clients travel betweenmultiple brokers. Because the MQTT client ID has to be configured on the clients anyway,and there is enough space available in the client ID to encode a password in it, accesscontrol based on username and password is a good choice for a limited set of brokers.For a larger set of brokers, a solution using an authentication server has to be taken intoconsideration.Encryption and access control by using a third party and symmetric cryptography com-bines the advantages of asymmetric cryptography and the advantages of symmetric cryp-tography, by the cost of running an infrastructure that is more complex than the Microbro-ker itself. Further, such a third party is a single point of failure. But for an environmentwith multiple brokers and mobile clients, running on very resource limited devices, this isthe way to go.The SSL/TLS protocol exceeds the computational needs of symmetric key agreement andauthentication mechanisms. On the other hand it is applicable in most imaginable de-ployment scenarios. Because the computational effort of the clients can be reduced byauthenticating them with username and passwords, such a solution is a good compromisebetween configuration complexity, computational needs and applicability for different de-ployment scenarios. Thus, encryption and access control modules using SSL/TLS andcomplementary password based authentication have been designed and implemented.

Chapter 7

Java Security Frameworks

The Java programming language is shipped with a variety of security specific APIs. Start-ing from version 1.4 of the Java platform, support for cryptographic services, interfaces forcertificates and classes to manage them, SSL/TLS functionality as well as authenticationand authorization frameworks are included in a modular way. The core of the whole secu-rity framework is the Java Cryptographic Architecture (JCA) and the Java CryptographicExtension. The JCA provides algorithms for integrity protection and functionality to dealwith keys and certificates. The JCE was originally developed as an extension to the JCAand provides algorithms for encryption and key generation. Due to U.S. export regulationsthis extension was not exportable. Because the law changed, this extension is included,starting from version 1.4 of the Java platform. Both JCA and JCE are frameworks andtheir implementation is provided by so called Providers like IBM, SUN Microsystems andmany more. Other frameworks, such as the Java Authentication and Authorization Service(JAAS), the Java Secure Socket Extension (JSSE), the Java Simple Authentication andSecurity Layer API (Java SASL API) or the Java Generic Security Service API (JGSS)use the cryptographic functionality the JCA and the JCE provide.

Figure 7.1: Java Security Framework

51

52 CHAPTER 7. JAVA SECURITY FRAMEWORKS

7.1 Java Authentication Frameworks

7.1.1 JAAS

The Java Authentication and Authorization Service (JAAS) is a pluggable framework forauthentication and authorization. It was introduced as an optional package in Java 2 SDKv 1.3 and has been integrated into Java 2 SDK 1.4. The JAAS decouples the applicationfrom the underlining access control technologies. It provides an Application ProgrammingInterface (API) as well as a Service Provider Interface (SPI). Service Providers implementthe different authentication and authorization mechanisms that are pluggable into JAAS.The most important class in the API is the javax.security.auth.login.LoginContext. Theapplication instantiates an object of this factory-class and passes a string to the con-structor. The factory looks the string up in a configuration file and creates the appro-priate javax.security.auth.SPI Interface.LoginModule classes, which are implemented bythe security provider. The LoginModule implementation perform the interaction with the”Backend” e.g. the UNIX /etc/password and /etc/shadow files or Kerberos. After au-thentication and authorization, an object of javax.security.auth.Subject is returned to theapplication, including a java.security.Principal object, that represents the authenticatedsubject, as well as the authentication credentials. A credential represents the shared secretand can be implemented without any restrictions. Figure 7.2 shows these interactions.

Figure 7.2: JAAS Framework

The framework allows to perform a cascade of different mechanisms, and can be configuredto either require only one successful login or multiple.The JAAS may be applicable on the broker side. Therefore, a client may send its usernameand credential to the access control module which instantiates a LoginContext object andcalls its login() method. The framework then performs the configured access controlmechanism(s). Of course, one has to implement the desired LoginModules that performthe login steps. Problems occur if one chooses the Unix mechanism shipped by most

7.1. JAVA AUTHENTICATION FRAMEWORKS 53

providers like SUN or IBM. Access to /etc/shadow is only allowed for the root userand therefore not for the Java interpreter, as long as it does not run SUID root. Aworkaround could be to implement a native application that reads the /etc/shadow file,which can be set SUID root, and use that within the LoginModule implementation. Theadvantage of using this framework within the Microbroker is that it allows to changethe LoginModule(s) at runtime and it would be possible to only have one access controlmodule in the stack and do either connection based access control, topic based accesscontrol or both based on the current configuration. The disadvantage is that such a singleaccess control module would produce a significant overhead if only connection based accesscontrol is configured, because the module has to be implemented in a way that it checksevery PUBLISH and SUBSCRIBE message, too. Another drawback is that the frameworkexpects that for each client a new instance of a LoginContext is created.

7.1.2 Java SASL API

The Java SASL API is an implementation of the Simple Authentication and SecurityLayer (SASL) described in [36]. The idea is to provide a pluggable authentication mecha-nism and an optional secured channel [2] to connection based protocols. In comparison toJAAS which hides the access control mechanism from the application, the Java SASL APIcan be used to extend existing protocols easily with a configurable set of authenticationmechanisms. LDAP and IMAP are examples that can be configured to use SASL. To en-able the use of SASL, the application protocol has to include a command used to performthe SASL protocol. This command has a required argument, indicating the authenti-cation mechanism to use, such as CRAM-MD5, KERBEROS V5 and some others. Inthis cases, the application protocol encapsulates SASL. SASL then performs the requiredaction within the protocol using a challenge-response mechanism. For example, a serverapplication uses the SASL API to create a challenge, and then transmits the challengeto the client. Now, the client application passes the challenge to its SASL API, whichcreates the response and returns it to the application. Then the application transmits theresponse back to the server. Its SASL API checks the response and returns the result ofthis check. Depending on the result and the authentication mechanism, the authentica-tion may have finished or another round has to be made. The Java SASL API is includedsince Java version 5 and supports a subset of the defined SASL mechanisms.

7.1.3 JGSS

The Java GSS API (JGSS) implements the so called Generic Security Service API (GSS)defined in [33]. The purpose of GSS is to decouple the cryptographic primitives used toprotect communication with authentication, integrity and confidentiality, from communi-cation protocols. Thus, the caller of the GSS-API is a protocol itself. The communicationbetween the protocol peers and its GSS-API is very similar to SASL. But instead ofabstracting the protocol, GSS abstracts the cryptographic primitives. However, bothspecifications have many common attributes. Some SASL mechanism also provide con-fidentiality and integrity, and on the other hand, GSS also authenticates the peers. In

54 CHAPTER 7. JAVA SECURITY FRAMEWORKS

addition, according to [36], GSS is also a registered SASL mechanism. Furthermore, inorder to establish a so called security context between peers it is necessary for a GSSmechanism not only to define the cryptographic primitives, but also the semantic of themessages being exchanged between the peers. So, a protocol is implicitly being defined.Out of a practical point of view, the biggest differences between the two APIs are thatSASL allows to modify easily existing protocols enabling authentication and maybe en-cryption, and GSS better fits on the layer below the application protocol, protecting theapplication messages. SASL can for example be used above a SSL/TLS channel, withserver authentication, to perform authentication of clients in a password based manner.GSS is best used if SSL/TLS is not applicable for example if the communication is UDPbased.JGSS is part of Java 2 version 1.4 and currently implements Kerberos as its only mech-anism.

7.2 Java Secure Socket Extension

The Java Secure Socket Extension implements different versions of the SSL protocol aswell as the TLS protocol. The API includes classes and interfaces to use the SSL/TLSprotocol directly together with HTTP and with TCP. Starting with the release of version5.0 of the Java platform the javax.net.ssl.SSLEngine is included, which decouples the SS-L/TLS protocol completely from any transport protocol, and even from any input/outputoperation. IBMs Java implementation comes with two JSSE versions: JSSE and JSSE2.The latter uses the cryptographic functionalities provided by JCA and JCE. The JSSEframework uses its own implementation of the cryptographic functions. Both JSSE andJSSE2 are shipped together with IBMs Java platform, version 1.4.2, but only JSSE isconfigured. In order to use JSSE2 with this Java version, the Java Runtime Environmenthas to be configured as outlined in Appendix A.

Chapter 8

Module Design

This chapter describes the design of the access control and encryption modules for theCommsSubsystem. The modules are designed for use with MQTT version 3. First, anoverview of all modules is given and it is explained what their responsibility is. Then, thedesign of the connection based access control module is explained, afterward the design ofthe topic based access control module. Because the access control and encryption moduleswork together to authenticate the clients, the interactions of the modules are outlined inthe corresponding sections, too.

8.1 Overview

Because of the configuration flexibility the SSL/TLS framework offers, as described inSection 6.4, and the availability of an API, that decouples the SSL/TLS mechanismcompletely from I/O, mentioned in Section 7.2, a solution based on SSL/TLS would beapplicable in the biggest set of possible deployment scenarios, and can cover non TCPbased communication, too. For simple scenarios, authentication based on username andpassword enables the deployment of the security enhanced Microbroker and the MQTTclients with acceptable configuration costs. Further, the implementation of a role basedaccess control module eases the administration especially in the case of access controlbased on the topic level.

The modules and classes that have to be developed are the following:� A SSL/TLS enabled Initiator module called TLSInitiator.� A SSL/TLS enabled threaded listener module called TLSThrededListener.� A module that implements the SSL/TLS protocol in a TCP independent manner,called TLSModule.� A module that controls access to the Microbroker on the connection level, calledConnectionAC.

55

56 CHAPTER 8. MODULE DESIGN� A module that controls access to the Microbroker on a topic granularity, calledTopicBasedAC.� A mechanism that allows the access control module to detect if the SSL/TLS alreadyhas authenticated the client using a certificate.� A class that performs authentication and authorization based on username andpassword, called MqttLogin.� A class that resolves the roles a client belongs to, into its permissions to publish andto subscribe to certain topics, called RoleResolver.

Table 8.1 gives an overview over the authentication, authorization and encryption respon-sibilities the modules have.

Table 8.1: Module responsibilities

Module Authentication Authorization EncryptionTLSInitiator Broker to client Broker to client yesTLSThreadedListener Client to broker no yesTLSModule Server to broker, no

Client to broker yesConnectionAC Client to broker Client to broker noTopicBasedAC Client to broker Client to broker, no

Client to topic

The module called TLSModule can be used in both, the client stacks and the broker stacks.If the TLSInitiator initiates a SSL/TLS secured communication on behalf of the client,the TLSThreadedListener has to be used on the broker-side. Both access control modulesare intended only to be used on the broker-side. If the SSL/TLS modules have alreadyauthenticated the client, by verifying its certificate, they do only authorization. In order tobe recognizable if a module is able to authenticate a client using a certificate, this modulehas to implement the ITLSAuthenticator interface and return a java.security.Principalthrough its getPrincipal() method. The ConnectionAC and the TopicBasedAC modulesparse MQTT messages and have therefore to be resided just below the MQTT module.They act as a filter, and filter unauthorized MQTT packets out. If possible, they takecare that the MQTT protocol flow does not break, by producing own MQTT packetsas response for the client. The ConnectionAC module parses the packets and filters outunauthorized CONNECT messages. The TopicBasedAC module filters out unauthorizedCONNECT, PUBLISH, and SUBSCRIBE messages and therefore governs the access tothe broker as well as to the topics. Because no unauthorized SUBSCRIBE message canreach the MQTT module, the Microbroker will never send any publications to subscribersthat are not allowed to retrieve these messages.

8.2. PER-CONNECTION ACCESS CONTROL: CONNECTIONAC 57

8.2 Per-Connection Access Control: ConnectionAC

This section describes the functional requirements and the design of the ConnectionACmodule.

8.2.1 ConnectionAC: Functional Requirements

The module has to check whether a client that has sent an MQTT CONNECT to theMicrobroker is allowed to access it. If certificate based client authentication is used in theSSL/TLS module, this module has to recognize that, and only has to do authorization.Authorization, to access the Microbroker, has to be deniable even if a client presenteda valid certificate to a SSL/TLS module. Access control has to be based on usernameand password. If a client is not allowed to access the broker, a feedback should be sentback, the access violation has to be logged, and the stack has to be properly closed.No unauthorized MQTT message has to reach the module that processes the MQTTmessages, and the MQTT protocol flow has to be guaranteed.The following use cases model these requirements:

Use Case 1� Client without a certificate and with valid username/password connects.� The Module checks username/password against the ACL.� The Module delivers the packet up the stack.

Use Case 2� Client without a certificate and without valid username/password connects.� The Module checks username/password against the ACL.� The Module does not deliver any packets up the stack.� The Module sends a feedback to the client.� The Module initiates the closing of the stack.

Use Case 3� Client with a valid certificate connects. The client is authorized to connect to the Microbroker.� The Module checks if the authentication done by another module was successful.� The Module does an authorization against the ACL.� The Module sends the packet up the stack.

Use Case 4� Client with a valid certificate connects. The client is not authorized to connect to the Microbroker.� The Module checks if the authentication done by another module was successful.� The Module does an authorization against the ACL.� The Module does not deliver any packets up the stack.� The Module sends a feedback to the client.� The Module takes care that the MQTT protocol flow does not break.� The Module initiates the closing of the stack.

58 CHAPTER 8. MODULE DESIGN

Use Case 5� An MQTT packet arrives after successful authentication of the client.� The Module sends the packet up the stack.

8.2.2 ConnectionAC: Design

According to the cases outlined in Subsection 8.2.1, the requirements can be modeledwith the finite state diagram in Figure 8.1. Table 8.2 describes the possible states andentry-actions, and Table 8.3 the corresponding transitions.

Figure 8.1: Connection based Access Control: Finite State Machine

Table 8.2: Connection based Access Control Module:States

State State description Entry action Entry actiondescription

not started Broker is started andwaiting for clientsto connect.This moduleis not started yet.

started A client has connected parse packet Parsing first packet thatand the module has been arrives.started as part of thestack.

8.2. PER-CONNECTION ACCESS CONTROL: CONNECTIONAC 59

access denied The access to the close stack The Module initiates theMicrobroker for the closing of the stack.connecting clientis denied.

not accepting The module is not check if Check if the client hasaccepting any packets authenticated already been authenti-for delivery yet. created by another module.

not authenticated The client has not been authenticate Authenticate the clientauthenticated yet. using username/password.

not authorized The client is not authorize Check if the client is inauthorized to access the ACL.the Microbroker yet.

MQTT disordered The module has blocked send client Send a CONNACK toa CONNECT. response fulfill the protocol.

accepting Further packets are deliver Deliver received packetsaccepted without any packet up the stack.checks.

Table 8.3: Connection based Access Control Module:Transitions

Transition Transition descriptionclient connects A client has established a connection on the transport layer.CONNECT arrived A CONNECT message has reached this module.non-CONNECT A packet not containing a CONNECT message has reached thisarrived module.authentication A check if another module has already authenticated thedone client was successful.authentication A check if another module has already authenticated thenot done client was not successfully.authentication Authentication based on username/password succeeded.succeededauthentication Authentication based on username/password failed.failedstack has The stack, including this module, has been closed.closedresponse sent A CONNACK in response to the CONNECT, created in this

module, has been sent to the client.

The module for access control based on a connection level is pluggable into every stackjust below the module that processes the MQTT messages. The module performs rolebased authentication and authorization. Access control is done by username and pass-word checking against an access control list. Username and password are encoded in theMQTT client ID. To enable certificate based client authentication, authentication is onlydone by this module, if there is no other module in the stack that has already authen-


ticated the client. Figure 8.2 shows the interactions between the SSL/TLS modules andthe ConnectionAC module as well as the necessary I/O operations. As long as at leastone instance of the ConnectionAC class exists, there exists exactly one instance of theMqttLogin class. The MqttLogin class encapsulates the necessary operations to performauthentication and authorization on the connection level.

Figure 8.2: Connection based Access Control with SSL/TLS Encryption and Authentica-tion

8.2.3 MqttLogin

The MqttLogin class is responsible for username and password based authentication aswell as for authorization on the connection level. The password is not stored in cleartextbut it is hashed the same way as the passwords on FreeBSD and Linux systems. Thereexists at most one MqttLogin instance per Microbroker. The access control modules ofthe different stacks within a single broker each have a reference to this instance.

8.3 Per-Topic Access Control: TopicBasedAC

This section describes the functional requirements for the TopicBasedAC modules andoutlines its design.

8.3. PER-TOPIC ACCESS CONTROL: TOPICBASEDAC 61

8.3.1 TopicBasedAC: Functional Requirements

In addition to the requirements described in Subsection 8.2.1, this module has to check forevery PUBLISH and SUBSCRIBE if the client is authorized to access the desired topic. Ifauthorization has been denied, the MQTT message has not to be delivered up the stack.Further, the module has to take care that the MQTT protocol-flow does not break in away that the peers run into troubles. The module should support authorization checksfor topics containing wildcards.These additional requirements can be modeled with the following use cases:

Use Case 6� A PUBLISH from a client arrives. The client is allowed to access the desired topic.� The Module checks the authorization.� The Module delivers the packet up the stack.

Use Case 7� A PUBLISH from a client arrives. The client is not allowed to access the desired topic.� The Module checks the authorization.� The Module does not deliver the packet up the stack.� The Module takes care that the MQTT protocol does not break.� The Module initiates the closing of the stack.

Use Case 8� A SUBSCRIBE from a client arrives. The client is allowed to access the desired topics.� The Module checks the authorization.� The Module sends the packet up the stack.

Use Case 9� A SUBSCRIBE from a client arrives. The client is not allowed to access the desired topics.� The Module checks the authorization to subscribe to these topics.� The Module does not deliver any packets up the stack.� The Module sends a feedback to the client.� The Module takes care that the MQTT protocol does not break.� The Module initiates the closing of the stack.

Use Case 10� Another MQTT packet arrives.� The Module sends the packet up the stack.

8.3.2 TopicBasedAC: Design

Figure 8.3 visualizes the cases described in Subsection 8.3.1 as finite state machine andTable 8.4 explains the used states and entry actions. In addition to the transitions inTable 8.3 the ones in Table 8.5 are used here.


Figure 8.3: Topic based Access Control: Finite State Machine

Table 8.4: Topic based Access Control Module: States


not started Broker is started andwaiting for clientsto connect.This moduleis not started yet.


started A client has connected parse packet Parsing the first packetand the module has that arrives.been started aspart of the stack.

access denied The access to the close stack The module initiatesMicrobroker for the the closing of theconnecting client stack.is denied.

not accepting The module is not check if Check if the clientaccepting any packets authenticated has already beenfor delivery yet. authenticated by

another module.not authenticated The client has not been authenticate Authenticate the

authenticated yet. client usingusername/password.

connection not The client is not authorize Check if the clientauthorized authorized to access is in the ACL.

the Microbroker yet.will topic not The authorization for authorize publish Check if the client isauthorized the will topic has allowed to publish

not been checked yet. to the will topic.publish not The authorization to authorize publish Check if the clientauthorized publish to the is allowed to

desired topic has publish tonot been checked yet. this topic.

subscribe not The authorization to authorize subscribe Check if the client isauthorized subscribe to the allowed to subscribe

desired topics has to these topics.not been checked yet.

connection The client is allowed parse packet All arrived packetsauthorized to access the will be parsed and

Microbroker. the appropriate actionchosen.

publish The client is deliver packet Deliver the packetauthorized authorized to up the stack.

desired topic.subscribe The client is deliver packet Deliver the packetauthorized authorized to up the stack.

subscribe to thedesired topics.

MQTT disordered The module has blocked send client Send the appropriatea CONNECT. response MQTT messages to

fulfill the protocol.


Table 8.5: Topic based Access Control Module: Transi-tions

Transition Transition descriptionPUBLISH arrived A PUBLISH message has reached this module.SUBSCRIBE arrived A SUBSCRIBE message has reached this

module.SUBACK or A SUBACK or CONNACK has been successfullyCONNACK sent created and has been sent to the client.other packet Neither a PUBLISH nor a SUBSCRIBE arrived.

The module for access control on a topic level is pluggable into every stack, just be-low a module that processes MQTT packets. If authentication is not already done byanother module, that implements the ITLSAuthenticator interface, it first authenticatesthe client using username and password, encoded in the MQTT client ID. Afterward,the authorization to access the Microbroker, and maybe the will topic, is checked. Now,for every PUBLISH or SUBSCRIBE, the authorization to access the desired topics iscontrolled. Figure 8.4 shows the interactions between the TLSThreadedListener and theTopicBasedAC module. As long as at least one instance of the TopicBasedAC class ex-ists, there exists exactly one instance of the MqttLogin and RoleResolver class, too. TheRoleResolver encapsulates the functionality used to authorize clients to access the desiredtopics.

Figure 8.4: Topic based Access Control with SSL/TLS Encryption and Authentication


8.3.3 RoleResolver

The RoleResolver class uses a role based access control approach. A role is a necessaryset of permissions a client needs to perform its work. Usually, in role based access controlmechanisms, a client can be assigned to different roles at the same time and can choosebetween a set of roles while accessing a system. A scenario in which such kind of roleassignment is useful for the Microbroker is not very likely. In order to minimize configura-tion efforts on the client side, the best thing to have is no configuration at all. Therefore,a simplified role based access control mechanism is used here. The Microbroker assignsroles to the clients, and the clients have no possibilities to change the roles. The maintask of the RoleResolver is to return a set of topics a client is allowed to publish to, anda set of topics a client is allowed to subscribe to. The definition of these access rights isdone in an hierarchical way. On each broker a default role with default permissions hasto be defined. Additional roles extend the permissions of the default role, and sub-rolescan be created that extend the permissions of their parent role. The RoleResolver allowsa role only to have at most one parent role. Figure 8.5 visualizes a possible tree of rolesthat could be defined.

Figure 8.5: RoleResolver: Tree of roles

Role R1, role R5 and role R10 are the root-nodes of their tree. Because each role has atleast the access permissions of the default role, a single tree is implicitly defined.There can exist at most one RoleResolver instance per broker. Each TopicBasedACmodule of a broker has a reference to this RoleResolver instance. At the time this instanceis created, the file containing the roles is read. The permissions of a role is resolved as soonas the permission of this role is requested the first time. The resulting role-permissiontuple is cached for faster access for future requests.


8.4 Encryption and Integrity Protection

The TLSModule can be used on the broker-side as well as on the client-side and is plug-gable between the NetModule and the module that processes the MQTT messages. Onthe other hand, the TLSInitiator and TLSThreadedListener are directly coupled to theTCP protocol and therefore build the anchor of all TCP based SSL/TLS stacks. All thesemodules provide encryption, ensure message integrity and authenticate the broker to theclient using a certificate.

8.4.1 SSL/TLS over TCP: TLSInitiator and TLSThreadedLis-

tener

In this subsection the functional requirements of the TLSInitiator and the TLSThreadedlistener are described, and the design of the modules is explained.

TLSInitiator and TLSThreadedListener: Functional Requirements

The modules have to integrity protect and encrypt the communication between the brokerand the clients. Further, the module on the client-side has to ensure that clients only accessan authenticated broker. The module on the broker side has to be able to authenticatethe clients using a certificate or predistributed public keys. If the broker could not havebeen authenticated, the TCP connection has to be closed.The following use cases model this behavior.

Use Case 11� A client establishes a connection to a broker that has a valid certificate.� The client module authenticates the broker during the SSL/TLS handshake.� The broker module tries to authenticate the client during the SSL/TLS handshake.� The modules encrypt and integrity protect the network traffic.

Use Case 12� A client establishes a connection to a malicious broker.� The client module authenticates the broker during the SSL/TLS handshake.� The client module disconnects the client from the broker.

TLSInitiator and TLSThreadedListener: Design

Figure 8.6 shows the states of the TLSInitiator and the TLSThreadedListener as a finitestate machine. The used states and entry actions are explained in Table 8.6, and the usedtransitions in Table 8.7.

8.4. ENCRYPTION AND INTEGRITY PROTECTION 67

Figure 8.6: TLSThreadedListener and TLSInitiator: Finite State Machine

Table 8.6: TCP based SSL/TLS Modules: States


not started Module is not started yet.not initialized Module has been started. init Initializes the module.

Reads keys andcertificates toup the SSL/TLSframework.

initialized Initialization is done. listen/establish The module eitherlistens for newconnections, orestablishes newconnections.

not handshaked A TCP connection has handshake Do the SSL/TLSbeen established, but handshake.neither authenticationnor encryption hasbeen set up.

handshaked The broker has been start stack Start a new stack.authenticated to theclient, the client maybeto the broker.Integrity protection andencryption is set up.


Table 8.7: TCP based TLS/SSL Modules: Transitions

Transition Transition descriptionstarted The Anchor has been started.init failed The initialization of the SSL/TLS framework failed.init succeeded The initialization of the SSL/TLS framework succeeded.SSL error An error during the handshake occurred.TCP established A TCP connection has been established.broker authentication The broker could not prove its authenticationfailed to the client.handshake finished The SSL/TLS handshake has just been finished.stack has started The stack has just been started.

The TLSInitiator and, on the broker-side, the TLSThreadedListener are both anchormodules that establish, respectively wait for a TCP connection, and that are responsibleof starting a stack. The TLSInitiator only allows to keep a TCP connection to a bro-ker alive, if the broker has been authenticated. On the other hand, the client has thepossibility to identify itself to the broker, using a certificate or a predistributed publickey. The TLSThreadedListener implements the ITLSAuthenticator interface and there-fore gives other modules the possibility to check if a client has been authenticated by thismodule. Figure 8.2 shows the interactions between the SSL/TLS modules and Connec-tionAC module as well as the necessary I/O operations. The SSL/TLS modules storetheir private key and their certificate in a so called Keystore, and the CA certificates aswell as predistributed public keys in a so called Truststore. Both, keystore and truststore,can be set to be the same file. If a client connects to the broker, the SSL/TLS modulesfirst perform the SSL/TLS handshake. The client always needs to be able to authenticatethe broker during the handshake. If the handshake succeeded, the peers fire up theirstacks and enable the MQTT based communication. If the handshake failed, they closethe SSL/TLS, and the corresponding TCP connection. In this case the MQTT protocolhas been broken. The client has sent a CONNECT and never received a response. Oncethe SSL/TLS secured communication has been established, the ConnectionAC module isresponsible for authorization, and maybe authentication, if the client has not presenteda valid certificate or a public key to the broker. Because of the authorization checks inthe ConnectionAC module, access to the Microbroker for a distinct client can be denied,even if the client presented a valid certificate during the SSL/TLS handshake. This canbe achieved by simply removing the client out of the ACL. Like that, there is no need fora Certificate Revocation List used by the SSL/TLS modules.

8.4.2 Transport Layer Independent SSL/TLS Module: TLSMod-

ule

The TLSModule can be used on the broker side as well as on the client side and isdecoupled from the transport layer. The functional requirements and the design of thismodule are described in this subsection.


TLSModule: Functional Requirements

The TLSModule has to ensure encryption and integrity protection between communica-tion peers. Like the TCP based modules it has to authenticate the broker to the clientsand has to try to authenticate the clients to the broker. If the broker could not be authen-ticated, the module has to close the SSL/TLS connection as well as the whole stack. Ifconfigured, the TLSThrededListener should be able to authenticate the clients. Becausethe module can be used independently of any transport protocol, a closure of the SSL/TLSsession does not lead to a closure of a socket. Thus, the module has to take care thatno MQTT packet is processed after the closure of the SSL/TLS session has been initialized.

These requirements can be modeled with the following use cases:

Use Case 13� A client establishes a connection to a broker that has a valid certificate.� The client module authenticates the broker during the SSL/TLS handshake.� The broker module tries to authenticate the client during the SSL/TLS handshake.� If the authentication of the client was successful, the modules encrypts and integrityprotects the network traffic.

Use Case 14� A client establishes a connection to a malicious broker.� The client module authenticates the broker during the SSL/TLS handshake.� The client module closes the SSL/TLS connection.� The client module shuts the stack down.

Use Case 15� The closure of the stack has been initialized.� The module closes the SSL/TLS session.� The module initiates a SSL/TLS compliant closure of the stack.

TLSModule: Design

The closure of the stack is made compliant to [15] by immediately closing the receivingside of the stack after a SSL/TLS closure message has been sent. Although the responseof the other side cannot be received anymore, this is still compliant with the SSL/TLSspecification. The module then blocks any packet received from the upper module. If amodule is the receiver of a SSL/TLS closure message, it responds with a closure messageas well, and will not send any application data down the stack.The finite state machine corresponding to the requirements concerning authentication andencryption is shown in Figure 8.7. Table 8.8 explains the states and entry actions andTable 8.9 the transitions.


Figure 8.7: TLSModule: Finite State Machine

Table 8.8: Transport Layer Independent SSL/TLS Mod-ule: States


not started Module is not started yet.not initialized Module has been started. init Initializes the module.

Reads keys andcertificates toup the SSL/TLSframework.

not handshaked The handshake is not handshake Do the SSL/TLSfinished and no handshake.authentication,encryption andintegrity protectionhas been set up.

accepting The broker has been deliver packet Deliver packets upauthenticated to the and down the stack.client, the client maybeto the broker.Integrity protection andencryption is set up.

access denied Access has been denied. close stack Close the SSL/TLSconnection first,then close the stack.


Table 8.9: Transport Layer Independent SSL/TLS Mod-ule: Transitions

Transition Transition descriptionclient connects The first packet arrives at the module.init failed The initialization of the SSL/TLS framework failed.handshake failed An error during the handshake occurred, or the authentication

of the broker to the client failed.packet arrived A packet, to be processed by this module, arrived.stack has closed The stack has been closed.

The TLSModule can be used independent of any transport layer and is pluggable some-where between the modules implementing the transport layer and the MQTT module. Be-cause transport layer modules add some header information to the packets, the TLSMod-ule is not compatible to the TLSThreadedListener or the TLSInitiator. The TLSModuleis not an anchor module, and is therefore started with the other modules of the stack.Figure 8.8 gives an example how the TLSModule can be used. There, the TLSModule isused in conjunction with the ConnectionAC module.

Figure 8.8: TLSModule with connection based Access Control

As soon as data arrives from a client on the UDPListener, the broker fires up a new stackused for communication with this client. The TLSModule is part of this stack. As thepacket arrives at this module, the handshake is started. If the handshake has failed, themodule closes the TLS/SSL connection, and indirectly the sockets, by shutting down the


stack SSL/TLS compliant. The ConnectionAC module does authorization, and maybeauthentication, if not done yet by the TLSModule.

Chapter 9

Module Implementation

The implementation of the SSL/TLS modules uses the Java Secure Socket Extension(JSSE) described in Section 7.2. The implementation of the access control modules andclasses does not build on any framework at all. The transport layer independent TLSMod-ule makes use of the javax.net.ssl.SSLEngine that is included in the API since Java version5. The other modules require at least Java version 1.4.2. Starting from IBM’s Java2 Plat-form version 1.4.2, the Runtime Environment consists of two different JSSE implementa-tions: JSSE and JSSE2. The latter relies on the cryptographic algorithm-implementationsprovided by JCE, described in Chapter 7. This is the default implementation the IBMJava2 version 5 Runtime Environment uses. In order to be able to use this implementa-tion with version 1.4.2 of IBM’s Runtime Environment, some configuration is needed asdescribed in Appendix B.

9.1 Access Control

The access control modules are responsible to filter the MQTT packets and only letmessages pass a client is authorized to send to the broker. If possible, they also take carethat the MQTT protocol does not break if a packet is not delivered to the MQTT module.

9.1.1 Connection based Access Control

Access control on the connection level is done by the ConnectionAC module as well asan instance of the MqttLogin class. The responsibility of the ConnectionAC module is tofilter out unauthorized CONNECT messages. The authentication and authorization func-tionality is implemented in the MqttLogin class. Therefore, the ConnectionAC moduleholds a reference to a MqttLogin instance.

73

74 CHAPTER 9. MODULE IMPLEMENTATION

ConnectionAC

Access to the Microbroker is granted either if the client already has been authenticatedby an ITLSAuthenticator, or if the CONNECT message contains a valid username andpassword combination. If the first packet arrives, and that packet is not a CONNECT,the stack will be closed. Otherwise the username and password is parsed out of theMQTT Client ID. Figure 9.1 shows the algorithm the module uses to control access tothe Microbroker.

Figure 9.1: ConnectionAC: Access Control Algorithm

Table 9.1 explains how the checks and actions in Figure 9.1 are implemented.

9.1. ACCESS CONTROL 75

Table 9.1: ConnectionAC: ImplementationCheck/Action Implementation descriptionwait for packet Wait until we receive a packet from the dispatcher.is authenticated If a packet arrives and the client has been successfullyand authorized? authenticated and authorized, the packet will be delivered

to the MQTT module. This check is done on reception of everypacket.

is CONNECT? The arrived packet is parsed and it is checked if it is a MQTTCONNECT message.

is first packet? The fist packet that arrives should be a MQTT CONNECTmessage. This is checked here.

is authenticated? The stack reference iterates through the module andchecks if there is one in the stack that implements theITLSAuthenticator interface. If such a module is found itsgetPrincipal() method is called that returns an authenticatedjava.security.Principal or null.

authorization A client is authenticated if either the authenticate(Principal)succeeded? function of the MqttLogin instance returned true, or implicitly

if that instances authenticate(clientID) returned not null, whereclientID is the MQTT Client ID parsed out of the CONNECTmessage.

authenticate The authentication and implicitly the authorization check isdelegated to the MqttLogin instance.

authorize The authorization check is delegated to the MqttLogin instance.drop packet, log, The received packet will not be delivered up the stack, theclose stack access violation is logged, and the closing of the stack initiated.create and send A new MQTT message, a CONNACK, is created and sent backMQTT response to the client. The ”Connection Refused: Identifier rejected”

return code is assigned to the message.

Configuration OptionsThe module expects a single configuration option: In order to be able to retrieve the rightMqttLogin instance, the module has to know the brokername. The way to configure themodule is described in Appendix A.

MqttLogin

The MqttLogin class implements the authentication and authorization functionality. Itaccesses an ACL containing username, password and a list of roles. The password is storedin a hashed form, exactly the same way as done on FreeBSD and Linux systems. Theexact syntax of the ACL is outlined in Appendix A. The MqttLogin class only has threepublic functions:� public static synchronized MqttLogin getInstance(String brokername)

76 CHAPTER 9. MODULE IMPLEMENTATION� public String authenticate(String mqttClientID)� String authorize(Principal principal)

The getInstance(String brokername) returns an instance of the MqttLogin class. Onlyone instance can exist per broker. If an instance already exists at the time the functionis called, a reference to this instance is returned, otherwise a new instance is created,initialized and a reference returned to the caller.The authorize(String mqttClientID) function checks if the client is allowed to access theMicrobroker, and returns a string containing comma separated role-names if the checkwas successful, otherwise null. In addition, the authenticate(String mqttClientID) checksif the supplied password encoded in the client ID is correct.

Configuration OptionsThe MqttLogin class expects two configuration options: The provider implementing themd5 hashfunction and the location of the ACL. More specific information about how toconfigure the module and about the syntax of the ACL can be found in Appendix A.

9.1.2 Topic based Access Control

Access control based on a topic level is done by the TopicBasedAC module, the Connec-tionAC class and the RoleResolver class. The TopicBasedAC module is responsible tofilter out any unauthorized MQTT message. It holds a reference of a ConnectionAC andof a RoleResolver instance. Both instances are shared with other access control modulesof a broker.

TopicBasedAC

The TopicBasedAC module governs access to the Microbroker on the connection level aswell as on the topic level. If a MQTT CONNECT message reaches the module it checksfirst if the client is allowed to establish the connection, the same way as the ConnectionACmodule does. In addition, the set of topics this client is allowed to publish or subscribe to isrequested from the RoleResolver and stored within the module. Once a client is connected,the authorization to subscribe or to publish to the desired topic(s) is controlled as soonas the corresponding MQTT messages arrive. Figure 9.2 visualized the algorithm used togovern access to the Microbroker as well as to the topics.

9.1. ACCESS CONTROL 77

Figure 9.2: TopicBasedAC: Access Control Algorithm

Table 9.2 explains the implementation of the checks and actions that this module performsin addition to the ConnectionAC module.


Table 9.2: TopicBasedAC: Implementation

Check/Action Implementation descriptionis connection If the client has been authenticated and authorized toaccess control establish a connection to the broker, only the authenticationdone? of PUBLISH and SUBSCRIBE messages has to be done. This is checked

here.is PUBLISH? The arrived packet is parsed and it is checked if it is a MQTT

PUBLISH message.is SUBSCRIBE? The arrived packet is parsed and it is checked if it is a MQTT

SUBSCRIBE message.is protocol If the module drops a PUBLISH packet the MQTT protocol flow mightflow broken? be broken, depending on the QoS. This is checked here.is MQTT If QoS=2, and a PUBLISH message has been dropped, the module wouldclean-up have to keep track of the MQTT Message ID and therefore parse allpossible? PUBREL messages in order not to deliver the corresponding message

up the stack. This is considered as too expensive. This is checkedhere.

log The access violation is logged.drop packet,log, The packer is not delivered up the stack, the access violation is loggedclose stack and the closing of the stack is initiated.

Configuration OptionsThe module expects a single configuration option: In order to be able to retrieve the rightMqttLogin instance, the module has to know the brokername. The way to configure themodule is described in Appendix A.

RoleResolver

The RoleResolver implements role based authentication of the clients and governs theaccess to the topics. It accesses a file defining the roles as described in Subsection 8.3.3 andAppendix A. There exists only one instance of a RoleResolver per broker, and every stackwithin this broker possesses a reference to this instance. To speed up, the file containingthe definitions of the roles is accessed only during initialization. The topics a client isallowed to subscribe or publish to, are resolved and cached not until the access rights of thisclient are requested. The RoleResolver contains a inner class called PermissionCollector.This class implements the functionality of aggregating the set of topics a client is allowed toaccess. If the RoleResolver has to resolve this set of topics, it traverses the branches of therole tree, containing the roles the client belongs to, in a bottom-up fashion, and delegatesthe task of collecting the permissions to the PermissionCollector. The PermissionCollectoreliminates duplicated topics as well as topics that represent a subset of a wildcard topic.Therefore, it reduces the topics a client is allowed to access, to the minimal set of topicsdescribing its permissions.The public functions an access control module is able to use are:

9.1. ACCESS CONTROL 79� public static RoleResolver getInstance(String brokername)� public synchronized void init()� public String [] getPermissions(String role)� public String [] getPermissions(String[] roles)� public static boolean contains(String perm, Enumeration topics)� public static boolean contains(String perm, String topic)

The getInstance(String brokername) returns a reference to this brokers RoleResolver. Ifthe instance does not exist yet, it will be created and initialized using the init() function.The init() function reads the file containing the role definitions and stores the structure ofthe file. It is declared as public because it has to be called after a change is made to the filecontaining the roles. Otherwise the changes take not effect. The getPermissions(Stringrole) uses the PermissionCollector instance to resolve the roles a client can be assigned to.It first builds the part of the branch in the role tree the client belongs to, and then resolvesthe topics the client is allowed to access. It uses an instance of the PermissionCollectorto eliminate duplicated topics as well as topics matched by wildcard topics. To speed-up,this function has a side effect. It caches all resolved roles in an instance variable. If thepermissions for a role is requested a second time, they will be returned directly usingthis cache. The function returns a string array, containing the minimal set of topics,describing the access rights a member of the resolved role has to for publishing, at index0, and at index 1, the minimal set of topics representing the permissions to subscribe.The getPermissions(String[] roles) function uses getPermissions(String role) to return thepermissions of a set of roles. The contains(String perm, Enumeration topics) and thecontains(String perm, String topic) functions check if a client that intends to publish orsubscribe to the desired topics, represented through the arguments ”topic” and ”topics”,is allowed to do so, by looking up if if these topics are contained in the argument perm,representing the permissions.

Configuration optionsThe RoleResolver expects a single configuration: The location of the file containing therole definitions. The syntax of this file as well as the way to configure this class is describedin Appendix A.


9.2 SSL/TLS modules

The SSL/TLS modules are responsible for encryption and integrity protection, as wellas for authentication of the broker to the clients. If configured the modules authenticatethe clients to the broker. The authentication of the broker to the clients is avoidableby simply choosing a set of ciphersuites that do not allow the authentication of a peer.SSL/TLS modules that are coupled to the TCP protocol and a module that can beused independently of any transport layer, as far as it is reliable. This section describesthe implementations by showing the algorithm the modules follow to establish a securedchannel.

9.2.1 ITLSAuthenticator

The ITLSInitiator interface consists of a single method:� public Principal getPrincipal()

This method has to return a java.security.Principal if the client has been authenticatedusing a certificate or a public key. If the client could not have been authenticated, theimplementations have to return null.

9.2.2 TCP based SSL/TLS: TLSInitiator and TLSThreadedLis-

tener

SSL/TLS over TCP is done by the TLSInitiator on the client-side and by the TLSThread-edListener on the broker-side. Both modules make use of the javax.net.ssl.SSLSocket classwhich implements the SSL/TLS protocol bounded to TCP. The TLSInitiator initiates theTCP connection to the TLSThreadedListener and starts the SSL/TLS handshake. Itexpects that the broker authenticates itself to the client using a X509 certificate or apublic key. If the broker has been successfully authenticated, and the handshake has beenfinished, the module starts a new stack and hands the SSL/TLS decorated [17] input-and output-streams over to the newly created stack instance. If the authentication of thebroker fails, the stack is not started and an exception is thrown that has to be handled bythe application layer. The behavior of the TLSThreadedListener is similar. It waits for aTCP connection and a SSL/TLS handshake to start. If configured, it tries to authenticatethe client. As soon as the handshake successfully finished, a new stack is started and themodule waits for further clients to connect.

9.2. SSL/TLS MODULES 81

Figure 9.3: TLSInitiator Imple-mentation

Figure 9.4: TLSThreadedListenerImplementation

Configuration OptionsThe TLSInitiator expects the following configuration options:� The network address this initiator has to connect to.� The port this Initiator has to connect to.� The location of the keystore.� The keystore type.� The password of the keystore.� The password of the key.

82 CHAPTER 9. MODULE IMPLEMENTATION� The SSL/TLS version to use.� The location of the truststore.� The algorithm used to verify certificates.� The provider implementing the SSL/TLS functionality and the cryptographic func-tions.

In addition, the TLSThreadedListener needs to be configured with a flag, that controlsif certificate client authentication is desired, and with a set of ciphersuites the brokeraccepts. The way how to configure the modules is outlined in Appendix A.

9.2.3 Transport Layer independent SSL/TLS: TLSModule

The transport layer independent implementation of the SSL/TLS modules can be usedon both, the client-side as well as on the broker-side. The module makes use of thejavax.net.ssl.SSLEngine which performs the necessary cryptographic operations as well asthe handshake steps. Encryption, decryption and the handshake steps are hidden withinthe two methods wrap() and unwrap(). These have to be called in the right order duringhandshake and during the SSL/TLS secured communication according to the SSL orTLS protocol specification described in Subsection 5.6.1. Further, the module performs aTLS protocol compliant stack closure procedure. As soon as one peer disconnects from theother it sends an SSL closure alert [15] and closes the outgoing side of the communication.The module also stops delivering any data to the MQTT module. As soon as the outgoingside of the communication is closed, the incoming will be closed, too. Therefore, themodule has the chance to process the SSL closure alert of the communication partner,but there is no guarantee it will do. This behavior is SSL/TLS compliant [15]. Thealgorithm used by the module during handshake and ongoing communication is shownin Figure 9.5 for the broker-side, and in Figure 9.6 for the client-side. The actions andchecks, not already explained earlier, are shown in Table 9.3. This table shows the client-,as well as the broker-side of the TLSModule.


Figure 9.5: TLSModule Implementation: Broker-side


Figure 9.6: TLSModule Implementation: Client-side

Table 9.3: TLSModule: Implementation

Check/Action Implementation descriptionunwrapPacket Wrapper for the SSLEngines unwrap() function, that either decrypts a packet

or performs a handshake step.wrapPacket? Wrapper for the SSLEngines wrap() function, that either encrypts a packet

or performs a handshake step.needWrap? Check if wrapPacket has to be done next during the handshake.needUnwrap? Check if unwrapPacket has to be done next during the handshake.send handshake The handshake packets, in the CommsSubsystem packet format, are createdpackets and sent to the client.


If something goes wrong during the handshake, e.g. the broker could not have beenauthenticated, it will be discovered either during a unwrapPacket or a wrapPacket actionand the stack will then be closed.

Configuration OptionsThe TLSModule needs the same configuration option like the TLSInitiator on the client-side, and like the TLSThreadedListener on the broker-side.


Chapter 10

Conclusions

There is no silver bullet in securing the MQTT publish/subscribe system. Because of thedifferent scenarios that the Microbroker might be deployed in, even under the restrictionmade in Section 1.3 and the different computational resources of the devices running theclients and the Microbroker, no approach can fulfill all possible evolving needs. The usageof SSL/TLS brings a big flexibility and can be configured to need acceptable computa-tional resources. The javax.net.ssl.SSLEngine available in the Java 5 platform provides anAPI to this standard, that is independent of any I/O operation and has therefore easedthe development of a module, securing all reliable, non TCP based communication - notonly the communication based on reliability added UDP.The flexible design of the CommsSubsystem made it possible to develop security relatedmodules, that can easily be exchanged through modules implementing other securitymechanisms. In order to preserve the flexibility and configurability of the CommsSub-system, access control has been implemented in a module below MQTT. A drawback ofthis approach is that it increases the need to parse arriving MQTT packets, especiallyif authorization is done on a topic granularity. Out of a performance point of view, ac-cess control should be made directly in the MQTT layer, making the need for additionalparsing not necessary. A way to put the advantages of both approaches together, withoutexcluding ordinary clients out of the publish/subscribe system, can be the introduction ofan authenticated MQTT protocol version. A mechanism can be used that decides on thebasis of the MQTT CONNECT message, if authentication should be done by a separatemodule, or directly by the MQTT module that implements this authentication extension.Of course, such an authentication extension would lead to the need of additional protocolmessages.Besides the additional parsing of MQTT packets the separate access control module leadsto, the MQTT protocol version 3 forced a module implementation with some limitations.It is not possible to inform a client, that publishes or subscribes using QoS level 0, aboutan authorization failure. If a client uses QoS level 2, the additional parsing costs andmemory needs, that would evolve by sending corresponding PUBREC and PUBCOMPmessages back to the client, simply make an accurate response to an authentication failureto expensive. Further, the MQTT protocol version 3 lacks of an adequate return code forCONNACK messages, that could indicate that access control has been denied. Becauseof the described insights gained during design and implementation of an access control

87

88 CHAPTER 10. CONCLUSIONS

mechanism for MQTT version 3, some suggestions can be made for a future release of theprotocol:� An additional return code for the CONNACK message should be defined that indi-

cates that access has been denied.� A negative acknowledgment should be introduced as a response for a PUBLISHmessage, indicating an authorization failure.� Even if a client uses QoS level 0, this negative acknowledgment should be sent backand has to be processed by the client.� If QoS level 2 is used, the negative acknowledgment has to be the last message inthe protocol flow for this publication.� Either a negative subscribe acknowledgment has to be introduced as a response forthe SUBSCRIBE message, or an extension to the existing SUBACK has to be made,that lists the topics the client is not allowed to subscribe to. Then, the broker onlyhas to process the subscription requests for the topics the client is authorized tosubscribe to.

Appendix A

Module Configuration

The modules and classes used for encryption and integrity protection as well as the onesused for authentication need some configuration and set-up. The description below doc-uments these configuration and set-up needs.

A.1 Access Control

The configuration of the access control modules starts with the decision if topic basedaccess control or only connection respectively broker based access control is needed. Ac-cording to that decision, the chosen module has to be added to the stack-configuration.

A.1.1 MqttLogin

The MqttLogin class is used by both access control modules, by the ConnectionAC and bythe TopicBasedAC module. In the java.util.prefs.Preferences terminology, this modulesconfiguration has to be stored in a child node of the brokers node. This child node has tohave the name ”SecConf” and expects the key-value parits in TableA.1.

Table A.1: MqttLogin: ConfigurationKey ValueCryptoProvider The provider of the Java Cryptographic Extension (JCE)

that provides the md5 hash-algorithm.ACL The absolute path of the access control list.

Access Control List The access control list has the following synopsis:username:[password]:[roles]The password field is only needed if clients are authenticated by username and password,and the roles filed is only needed if the TopicBasedAC module is used, and the client

89

90 APPENDIX A. MODULE CONFIGURATION

belongs to more roles than to the default role. The roles have to be defined as a commaseparated list of role names.

A.1.2 RoleResolver

The RoleResolver needs a single configuration entry in the SecConf child node of thebroker’s node. Its key is ”Rolefile” and its value is the absolute path to the file containingthe role definitions.

Role DefinitionsThe synopsis of the file containing the role definitions is the following:rolename:[parent rolename]:[topics allowed to publish]:[topics allowed to subscribe]� rolename is the name of the role.� parent rolename is the name of the parent role.� topics allowed to publish is a comma separated list of topics

a client is allowed to publish messages to.� topics allowed to subscribe is a comma separated list of topicsa client is allowed to subscribe to.

A role file has at least to contain a default role with rolename ”default”, an empty par-ent rolename and the two lists of topics. These lists may be empty.

A.1.3 ConnectionAC

The ConnectionAC module needs the brokername as a single configuration. Therefore,the key ”BrokerName” with the name of the broker as value has to be added to thestack-configuration.

A.1.4 TopicBasedAC

The TopicBasedAC has to be configured the same way as the ConnectionAC module.

A.2 SSL/TLS Modules

In order to set up the SSL/TLS modules at least a keypair for the Microbroker is needed.If certificate based client authentication is used, a keypair for the clients is needed, too.At this point, the configuration costs can be dramatically reduced, if one introduces a CAand signs all peers public keys with its private key to create certificates.

A.2. SSL/TLS MODULES 91

A.2.1 Certificate Authority (CA)

There are different ways to build a CA. The code Listing in A.1 uses openssl to create aRSA based CA.

Listing A.1: Creation of a Certificate Authority

user@host : / some/ dir > mkdir demoCAuser@host : / some/ dir > mkdir demoCA/ p r i v a t euser@host : / some/ dir > open s s l genrsa −des3 −out demoCA/ p r i v a t e / ca key. pem 2048user@host : / some/ dir > open s s l req −new −key demoCA/ p r i va t e / ca key . pem−x509 −days 365 − out demoCA/ ca c e r t . c e r

In the third line, a RSA keypair with a key length of 2048 bits is created and encryptedby a password based 3DES algorithm. The next line is used to create a self signed X509certificate with 365 days of validity. The command creates a Certificate Signing Request(CSR) first and signs it using the private key.

A.2.2 Broker and Client Keys

The Java JSSE API expects that the peers own keys and certificates have to be storedin a java.security.Keystore, and the keys and certificates a peer trusts have to be storedin a so called truststore. A truststore is syntacticly the same thing as the keystore andtherefore, keystore and truststore can be set to the same file. The code in Listing A.2shows how to set up a RSA keypair for the Microbroker, stored in a Keystore using thekeytool that is shipped with the Java Runtime Environment.

Listing A.2: Broker-key Generation using keytool

user@host : / some/ dir > keytoo l −genkey −v − a l i a s MicroBroker −keyalgRSA − key s i z e 1024 −key s t o r e b roker keys tor e . j k s

The client keys and keystores are created the same way. In contrast to the broker keys,the Client ID has to be included in the Common Name (CN) field of the X509 encodedkey. Listing A.3 shows this procedure. Client keys are only needed if certificate basedclient authentication is needed.

Listing A.3: ClientKey Generation using keytool

user@host : / some/ dir > keytoo l −genkey −v − a l i a s C l i en t1 −keyalgRSA − key s i z e 1024 − keys tor e c l i e n t 1 . j k sEnter keys tor e password : passwordWhat i s your f i r s t and l a s t name?

[ Unknown ] : C l i en t1What i s the name o f your o r g an i z a t i o n a l un i t ?

[ Unknown ] :What i s the name o f your o r gan i z a t i on ?

[ Unknown ] :What i s the name o f your City or Loca l i t y ?


[ Unknown ] :What i s the name o f your State or Province ?

[Unknown ] :What i s the two− l e t t e r country code f o r t h i s un i t ?

[Unknown ] :I s CN=Client1 , OU=Unknown , O=Unknown , L=Unknown , ST=Unknown ,C=Unknown co r r e c t ?( type ”yes ” or ”no ”)

[ no ] : yes

Generating 1 , 024 b i t RSA key pa i r and s e l f −s igned c e r t i f i c a t e(MD5WithRSA)

f o r : CN=Client1 , OU=Unknown , O=Unknown , L=Unknown ,ST=Unknown , C=Unknown

Enter key password f o r <Client1 >

(RETURN i f same as keys tor e password ) :[ Saving c l i e n t 1 . j k s ]user@host : / some/dir>

Now, a CA with a private key and a self signed public key, a client and a broker witha RSA keypair, encoded in the X509 format, has been created. To enable the clientto authenticate the broker, one possibility is to export the brokers public key from itskeystore, transport it to the client, and import it into the client’s truststore. Listing A.4shows the necessary steps. In the example the truststore and the keystore are set to thesame file.

Listing A.4: Import the broker-key into the client-truststore

user@host : / some/dir > keytoo l −−export − a l i a s MicroBroker − f i l e out . key −keys tor e b roker keys tor e . j k suser@host : / some/dir > keytoo l − import − a l i a s MicroBroker −keys tor e c l ient1 . j k s − f i l e out . key

To ensure integrity of the imported key, one of the displayed checksums have to be dou-blechecked with the checksum of the original key. Now the client is able to authenticatethe broker using the JSSE framework. To enable the broker to authenticate the client,one has to do the same steps as in Listing A.4 for the client key.The approach that scales better is to use the CA to sign the keys as shown in Listing A.5.

Listing A.5: Sign the broker-key: Create a broker-certificate

user@host : / some/dir > keytoo l − c e r t r eq −v − a l i a s MicroBroker −keys tor eb roker keys tor e . j k s − f i l e b roker r eques t . c s ruser@host : / some/dir > open s s l x509 − req −days 365 − in b roker r eques t . cs r −CA demoCA/ ca c e r t . c e r −CAkey demoCA/ p r i va t e / ca key . pem −CAcreates e r i a l −out MicroBroker . c e ruser@host : / some/dir > keytoo l − import − t r u s t c a c e r t s − a l i a s CA −keys tore b roker keys tor e . j k s − f i l e demoCA/ ca c e r t . c e ruser@host : / some/dir > keytoo l − import − a l i a s MicroBroker −key s t o r e broker keys tor e . j k s − f i l e MicroBroker . c e r

A.2. SSL/TLS MODULES 93

The first command creates a Certificate Signing Request (CSR)for the brokers publickey. With the second command the CSR is signed with the CAs private key. The thirdcommand imports the CA-certificate into the broker-keystore. This is only necessaryif the broker should later be able to authenticate clients using certificates. The lastcommand imports the X509 certificate into the broker-keystore. The procedure to createan X509 certificate for the clients is analogous to Listing A.5. Now both peers are able toauthenticate each other using a X509 certificate created by the CA.

A.2.3 TLSInitiator

The TLSInitiator needs the to be configured in the stack-configuration with the key-valuepaires listed in Table A.2.

Table A.2: TLSInitiator: ConfigurationKey Valueaddress The network address this Listener connects to.port The port to connect to.Keystore The absolute path of the keystore file.Truststore The absolute path of the truststore file.TrustManagerAlg The algorithm used to verify certificates and public keys.KeystoreType The format of the keystore.KeystorePwd The password of the keystore.KeyPwd The password of the private key.Protocol The protocol the module uses.Provider The underlining provider the JSSE framework uses.

Listing A.6 is a partial snapshot of thecom.ibm.mqttclient.factory.internal.PredefinedProtocolStacks class, that shows a sampleconfiguration of a stack using the TLSInitiator.

Listing A.6: TLSInitiator: Stack configuration

p r i v a t e s t a t i c f i n a l S t r ing tcpTLS StackDef =”MqttTcpTlsStack ;”+”com . ibm . mqttd i r ect . modules . tcp . c l i e n t . j 2 s e . TLSIn i t i a to r :”+”address=lo ca l h o s t , port =1884,”+”Keystore=/u/ywa/keys / c l i e n t 2 k ey s t o r e . jks ,”+”Trus t s to r e=/u/ywa/keys / c l i e n t 2 k ey s t o r e . jks ,”+”KeystoreType=JKS , KeystorePwd=123456 ,KeyPwd=123456 ,”+”Protoco l=TLS, Provider=IBMJSSE2 , TrustManagerAlg=IbmX509 ;”+”com . ibm . mqttd i r ect . modules . common . StreamDeframer ;”+”com . ibm . mqttc l i en t . i n t e r n a l . MqttClientModule ”;


A.2.4 TLSThreadedListener

On the broker-side, the configuration of the module is splitted from the configuration ofthe stack. That gives the flexibility to either use one configuration file for all TCP basedSSL/TLS stacks, or to use one configuration for a subset of stacks. Therefore, in the stack-configuration a reference to the module configuration has to be made by adding the key”conf” and the location of the module configuration-file as value. The configuration-file ofthe TLSInitiater has to be java.util.prefs.Preferences compliant. It expects the key-valuepairs in Table A.3.

Table A.3: TLSThreadedListener: ConfigurationKey Valueaddress The network address this module uses.port The port this module listens on.Keystore The absolute path of the keystore file.Truststore The absolute path of the truststore file.TrustManagerAlg The algorithm used to verify certificates and public keys.KeystoreType The format of the keystore.KeystorePwd The password of the keystore.KeyPwd The password of the private key.Protocol The protocol the module uses.Provider The underlining provider the JSSE framework uses.CipherSuites The CipherSuites that this stack allows to use.WantClientCert True if the module should try to authenticate the

clients during the SSL/TLS handshake, else false.

A.2.5 TLSModule

If used on the client-side, the TLSModule expects the same configuration as the TLSIniti-ater, if used on the broker-side, is uses the same configuration options as the TLSThreadedListener.

Appendix B

Java Runtime EnvironmentConfiguration

IBMs Java Platform version 1.4.2 comes with two different implementations of the JavaSecure Socket Extension: JSSE and JSSE2 as described in Section 7.2.The JSSE2 implementation makes use of the JCA and JCE, but is not configured by de-fault. In order to use this implementation, some changes in a Java Runtime configurationfile have to be made. The file to change is $JAVA HOME/jre/lib/security/java.security.First, one has to add the IBMJSSEProvider2 to the list of security provider in front ofthe IBMJSSEProvider. The part of the file containing the security providers should looklike in Listing B.1.

Listing B.1: Add of the IBMJSSEProvider2 to the Java Runtime

s e c u r i t y . p rov id e r .1=com . ibm . j s s e 2 . IBMJSSEProvider2s e c u r i t y . p rov id e r .2=com . ibm . j s s e . IBMJSSEProviders e c u r i t y . p rov id e r .3=com . ibm . crypto . p rov id e r . IBMJCEs e cu r i t y . p rov id e r .4=com . ibm . s e c u r i t y . j g s s . IBMJGSSProviders e c u r i t y . p rov id e r .5=com . ibm . s e c u r i t y . c e r t . IBMCertPath

Further, according to the documentation on the products webpage, the Runtime Environ-ment has to be configured to use a distinct implementation of the SSLSocketFactory andof the SSLServerSocketFactory within the same file as the configuration in Listing B.2 isdone.

Listing B.2: Add of JSSE2 SSLSocketFacortyImpl and SSLServerSocketFactoryImp

s s l . SocketFactory . p rov id e r=com . ibm . j s s e 2 . SSLSocketFactoryImpls s l . ServerSocketFactory . p rov id e r=com . ibm . j s s e 2 . SSLServerSocket \FactoryImp

This configuration does not seem to be necessary. Whatever configuration is used here, atthe end, a SSLSocket and SSLServerSocket implementation, provided by the first providerconfigured, is returned. The IBMs Java 5 Runtime Environment does not need any con-figuration at all. These configurations can also be made using the Java API at runtime,

95

96 APPENDIX B. JAVA RUNTIME ENVIRONMENT CONFIGURATION

but a hardcoded configuration in the module is not that of a flexible solution, and fur-thermore, the execution of the code might fail at that point, if the hardcoded provider isnot available in this Runtime Environment. Another point concerning the Java version1.4 Runtime Environment configuration is about using appropriate keysizes. By defaultthe Runtime Environment is restricted in a way that it is not possible to use keys withappropriate length for encryption and decryption operations. To fix that problem, theso called Unrestricted Policy Files have to be downloaded from the products webpageand put into $JAVA HOME/jre/lib/security/. There is no such issue with IBMs Java 5Platform.

Bibliography

[1] MQ Telemetry Transport Protocol Specification v3. www.mqtt.org.

[2] Paul C. van Oorschot Alfred J. Menezes and Scott A. Vanstone. Handbook of AppliedCryptography. Taylor and Friends Ltd., 1996.

[3] Jim Alves-Foss. Provably insecure mutual authentication protocols: The two partysymmetric-encryption case. 22nd National Information Systems Security Conference,1999.

[4] Andras Belokosztolszki, David M. Eyers, Peter R. Pietzuch, Jean Bacon, and KenMoody. Role-based access control for publish/subscribe middleware architectures. InDEBS ’03: Proceedings of the 2nd international workshop on Distributed event-basedsystems, pages 1–8. ACM Press, 2003.

[5] Colin Boyd. Towards a classification of key agreement protocols. In The EighthIEEE Computer Security Foundations Workshop (CSFW’95), March 13-15, 1995,Kenmare, County Kerry, Ireland, pages 38–43, 1995.

[6] Colin Boyd. A class of flexible and efficient key management protocols. In Proceedings9th IEEE Computer Security Foundations Workshop, pages 2–8. IEEE ComputerSociety Press, 1996.

[7] Colin Boyd and Anish Mathuria. Protocols for Authentication and Key Establishment.Springer, 2003.

[8] Michael Burrows, Martın Abadi, and Roger Needham. A logic of authentication,from proceedings of the royal society, volume 426, number 1871, 1989. In WilliamStallings, Practical Cryptography for Data Internetworks, IEEE Computer SocietyPress, 1996. 1996.

[9] A. Carzaniga, D. Rosenblum, and A. Wolf. Design of a scalable event notificationservice: Interface and architecture. 1998.

[10] Radia Perlman Charlie Kaufmann and Mike Speciner. Network Security: PRIVATECommunication in a PUBLIC World. Prentice Hall PTR, 2002.

[11] Guang-Huei Chiou and Wen-Tsuen Chen. Secure Broadcasting using the secure lock.IEEE Transactions on Software Engeneering, 1989.

97

98 BIBLIOGRAPHY

[12] John Clark and Jeremy Jacob. A survey of authentication protocol literature: Version1.0. http://www.cs.york.ac.uk/ jac, 1997.

[13] H. Fuentes D. Wong and A. Chan. The Performance Measurment of CryptographicPrimitives on Palm Devices. 17th Annual Computer Security Applications Confer-ence, 2001.

[14] N. Daswani and D. Boneh. Experimenting with Electronic Commerce on the PalmPilots. Lecture Notes in Computer Science, 1998.

[15] T. Dierks. The TLS Protocol. Internet Engeneering Task Force, RFC 2246, 1999.

[16] Whitfield Diffie and Martin E. Hellman. New directions in cryptography. IEEETransactions on Information Theory, IT-22(6):644–654, 1976.

[17] Ralph Johnson Erich Gamma, Richard Helm and John Vlissides. Design Patterns:Elements of Reusable Object-Oriented Software. Addison Wesley, 2001.

[18] S. Farrell and R. Housley. An Internet Attribute Certificate Profile for Authorization.Internet Engeneering Task Force, RFC 3281, 2002.

[19] D. Ferraiolo and R. Kuhn. Role-based access controls. In 15th NIST-NCSC NationalComputer Security Conference, pages 554–563, 1992.

[20] A. Fiat and A. Shamir. How to prove yourself: Practical solutions to identificationand signature problems. Springer, Advances in Cryptology - Crypto 86, 1987.

[21] Li Gong. Lower bounds on messages and rounds for network authentication protocols.In ACM Conference on Computer and Communications Security, pages 26–37, 1993.

[22] James W. Gray. On the Clark-Jacob version of SPLICE/AS. Information ProcessingLetter, 1997.

[23] L. Guillou and J.-J. Quisquater. A practical zero knowledge protocol fitted to se-curity microprocessor minimizing transmission and memory. Springer, Advances inCryptology - Crypto 88, 1988.

[24] Vipul Gupta and Sumit Gupta. Kssl: Experiments in wireless internet security, 2001.

[25] M. Bellare H. Krawczyk and R. Canetti. HMAC: Keyed-Hashing for Message Au-thentication. Internet Engeneering Task Force, RFC 2104, 1997.

[26] ISO. Information Technology - Security Techniques - Key Management - Part 2:Mechanisms using Symmetric Techniques ISO/IEC 11770-2. International Standard,1996.

[27] ISO. Information Technology - Security Techniques - Key Management - Part 3:Mechanisms using Symmetric Techniques ISO/IEC 11770-3. International Standard,1999.

[28] ISO. Information Technology - Security Techniquies - Entity Authentication Mecha-nisms - Part 3: Entity Authentication using a Public Key Algorithm ISO/IEC 9798-3.International Standard, 1999.

BIBLIOGRAPHY 99

[29] ISO. Information Technology - Security Techniquies - Entity Authentication Mech-anisms - Part 5: Mechanisms using Zero Knowledge Techiques ISO/IEC 9798-5.1999.

[30] Philippe Janson and Gene Tsudik. Secure and minimal protocols for authenticatedkey distribution. Technical report, 1993.

[31] J. Kohl and C. Neumann. The Kerberos Network Authentication Service (V5). In-ternet Engeneering Task Force, RFC 1510, 1993.

[32] L. Lamport. Password Authentication with Insecure Communication. Communica-tions of the ACM, 1981.

[33] J. Linn. Generic Security Service Application Program Interface Version 2, Update1. Internet Engeneering Task Force, RFC 2743, 2000.

[34] Ying Liu and Beth Plale. Survey of Publish Subscribe Systems. Computer ScienceDept. Indiana University, 2003.

[35] Zoltan Miklos. Towards an access control mechanism for wide-area publish/subscribesystems. In ICDCSW ’02: Proceedings of the 22nd International Conference onDistributed Computing Systems, pages 516–524. IEEE Computer Society, 2002.

[36] J. Myers. Simple Authentication and Security Layer (SASL). Internet EngeneeringTask Force, RFC 2222, 1997.

[37] R. Needham and M. D. Schroeder. Using encrition for authentication in large net-works of computers. Communications of the ACM, 1978.

[38] Rachid Guerraoui Patrick Th. Eugster, Pascal A. Felber and Anne-Marie Kermarrec.The many faces of publish/subscribe. ACM Comput. Surv., 35(2):114–131, 2003.

[39] Handheld Devices Patroklos. Performance analysis of cryptographic protocols on,2003.

[40] A. Shamir R. L. Rivest and L. M. Adleman. A method for Obtaining Digital Signa-tures and Public-Key Cryptosystems. Communicaions of the ACM, 1978.

[41] G. Pernul R. Oppliger and C. Strauss. Using Attribute Certificates to ImplementRole-based Authorisation and Access Controls. 2000.

[42] R. Sandhu and P. Samarati. Access control: Principles and practice, 1994.

[43] C. P. Schnorr. Efficient identification and signatures for smart cards. Springer,Advances in Cryptology - Crypto 89, 1990.

[44] Hashawarhan Gadgil Shrideep Pallickara, Marlon Pierce, Geoffry Fox, Yan Yan, andYi Huang. A framework for secure end-to-end delivery of messages in publish/sub-scribe systems. 2005.

[45] Richard E. Smith. Authentication. Addison Wesley, 2002.

100 BIBLIOGRAPHY

[46] Mudhakar Srivatsa and Ling Liu. Securing publish-subscribe overlay services witheventguard. In CCS ’05: Proceedings of the 12th ACM conference on Computer andcommunications security, pages 289–298, New York, NY, USA, 2005. ACM Press.

[47] Andrew S. Tannenbaum and Maarten van Steen. Distributed Systems, Principles andParadigms. Prentice Hall Inc., 2002.

[48] Chenxi Wang, Antonio Carzaniga, David Evans, and Alexander L. Wolf. SecurityIssues for Internet-Scale Publish-Subscribe Systems. Hawaii International Conferenceon System Sciences, January 7-10, 2002.

[49] Thomas Y. C. Woo and Simon S. Lam. A lesson on authentication protocol design.ACM Operating System Review, 1994.

[50] Suguru Yamaguchi and Kiyohiko Okayama. Design and Implementation of an au-thentication system in WIDE internet environment. IEEE Region 10 Conference onComputer and Communication Systems, 1990.

[51] T. Ylonen and Lonvick. The Secure Shell (SSH) Authentication Protocol. InternetEngeneering Task Force, RFC 4252, 2006.

[52] T. Ylonen and Lonvick. The Secure Shell (SSH) Connection Protocol. InternetEngeneering Task Force, RFC 4254, 2006.

[53] T. Ylonen and Lonvick. The Secure Shell (SSH) Protocol Architecture. InternetEngeneering Task Force, RFC 4251, 2006.

[54] T. Ylonen and Lonvick. The Secure Shell (SSH) Transport Layer Protocol. InternetEngeneering Task Force, RFC 4253, 2006.

Date post:	02-Oct-2014
Category:	Documents
Upload:	quynh-nguyen-thi-nhu
View:	316 times
Download:	4 times

Wirth_Andreas

Documents