New Approach for Keys Distribution Through Publish/Subscribe Protocols

New approach for keys distribution througth
publish/subscribe protocols
Abdessamad MEKTOUBI*, Olaf MALASS#,Hicham BELHADAOUI* and Mounir RIFI*
* CED Engineering Science, ENSEM, Lab. RITM/ESTC Hassan II University Casablanca, Morocco
# ENSAM/ParisTech, Metz,France
amektoubi@gmail.com
olaf.malasse@ensam.eu
Abstract— The Internet of things (IoT) is the interconnection of
physical objects with the Internet network, using existing
technologies and communication protocols. The speed up and
massive uses of this network’s type in a multitude domain, from
large industrial applications to small every day’s uses, raises new
serious problematic related to security. Indeed, recent reports on
cyber security highlighted the Internet of things’ vulnerability,
and the risks continue to increase exponentially, especially with the
deployment of intelligent networks [1][2][3].
Indeed, the user is able, in such an environment, to have access to
the information, such information passes through different
networks using different protocols, with a wide range of services
delivered by different providers. In addition, end users ask to be
constantly connected anyhow to the information. They also wish to
have secure access to this information through different protocols.
Faced with this heterogeneity of support and protocol, several
security challenges arise. The environment is increasingly open,
multiple protocols are not known in advance and we have a variety
of communications between protocols and machines.
In this work we propose a new method for key distribution
through publish/subscribe protocol.
Keywords-component; publish/subscribe, key distribution,
MQTT, Internet of Things.
I. INTRODUCTION
Generally, the security of networks and information systems
“IS” is indispensable to any entity or organization trying to
protect their data and resources (hardware or software). In this
perspective, several aspects must be controlled. First, the
information availability in Information System (IS) can be
ensured through redundancy mechanisms or back-up for
example. The data integrity must be protected against intentional
or accidental alteration or destruction. In addition, enhancement
of the IS security also requires the establishment of
authentication and authorization protocols (e.g. Identity Access
Management or IAM [4]) to limit and control the resources
access. Finally, in the case of sensitive Data (financial,
industrial, chemical formulas ...), it should not be accessible to
unauthorized person. Cryptography (symmetric or asymmetric)
provides in this case an appropriate solution [5][6], although
problems remain suspended and require more attention from the
scientific community as the solution based on the sharing key
[7].
The sharing of encryption keys has always been a challenge.
The use of algorithms such as "Diffie-Hellman" with
asymmetric cryptography used to establish a secret key (known
as session key) between two entities. This is even more
constraining if we need to share keys between a group of users.
Several works were carried out in order to solve this problem;
we classify them into three categories: "Centralized Group Key
Distribution (CGKD)"[8], where the distribution is ensured by a
central trusted entity. "Decentralized Group Key Management
with Relaying (DGKM)"[8] where the set of users is divided into
subgroups to which one distinctly assigns central distribution
entities. Finally, "Contributory Distributed Group Key
Agreement (CGKA)"[9] in this case the group was organized to
establish a secret key without using a third party.
II. STATE OF THE ART
A. Publish/Subscribe Pattern:
The "Publish/subscribe" model is a concept based on the
exchange of messages without prior knowledge of the different
actors which are transmitters or receivers. This type of
architecture avoids any coupling between actors, unlike
traditional models that require exemplary knowledge of the IP
or full DNS (Domain Name System) name destination addresses
of individual, group or domain recipient. This decoupling model
offers more dynamism, scalability and flexibility. Three
components parts are essentials in a Publish/Subscribe model;
the first part is the publisher that sends messages, the second part
is a Publish/Subscribe server (called Broker) that handles and
switch messages and the third part is a Subscriber that remains
constantly and exclusively listening to the messages concerning
him. This model can be implemented in two different ways. The
Publisher tags its messages by a topic representing a subject or a
specific class that the server loads and broadcast to all
Subscribers who are subscribed on this topic. In the second type
of implementation, the messages are routed to the Subscribers
according to their content.
B. Problematic:
In the following, we consider that a group of users, named
Trust Group (TG), wants to communicate securely over a
Publish/Subscribe protocol.
In Publish/Subscribe architecture with several public
brokers, all the users have the right to publish or subscribe to any
Topic. This exchange of unsecured data is greatly threatening
International Journal of Computer Science and Information Security (IJCSIS),
Vol. 15, No. 8, August 2017
1 https://sites.google.com/site/ijcsis/
ISSN 1947-5500

the confidentiality of data exchanged. The first solutions is to
limit the number of users listening on a Topic, several protocol
implementations or provide an authentication system along with
a communication encryption (e.g. SSL communication for tcp
protocols). This approach becomes credible if the broker is under
the management of a trusted organization. Otherwise we cannot
be certain if the messages are routed only to users who belong to
the Trust Group.
A second approach is to encrypt messages with an encryption
key. Consequently, only users who have the decryption key can
read the message content. However, this approach assumes that
the set of TG have the encryption and decryption keys. In this
case new users should receive the same key. Hence, this needs
an implementation of a key distribution strategy for new users of
TG.
In this work, we propose a new approach of communication
and management of keys in a Publish/Subscribe architecture.
This is based on a Public Key Infrastructure (PKI) [12].
III. APPROACH AND PROPOSED MODEL:
The main objective of this work is to secure distribution of
encryption-decryption keys in order to secure communication
and messages exchanged between a set of users within a
Publish/Subscribe protocol.
In this context, we propose to use two types of certificates
that will be issued by a Certification Authority "CA". The first
type is a certificate for TG’s users, the second type will be
dedicated to Topics, meaning that the messages exchanged in a
given Topic will be encrypted by the public key of this Topic.
Our approach is based on a sending request system on a
specific Topic named "Topic Demand" TD. All users must be
subscribed to "TD". All users can respond to requests based on
its type, and depending on a set of criteria and constraints. In fact
we define three types of requests:
 The certificate request.
 The private key request.
 The revocation list request.
Several formal approaches to analyze security protocols are
based on the Dolev-Yao[10] model. In this work, we use a
formalism to describe the basic assumptions of this model.
In the rest of this work, we use the same formalism and
notation to describe our Keys’ distribution protocol.
Sending a message M on Topic T by a user U1 using a
Broker B, and received by a user U2, can be modeled by the
following:
U1 →B: T, M
B → U2: T, M
For simplification reasons, this will be expressed as
(skipping the exchanges with the broker B):
U1 →T U2: M
Each message sent by a member of the TG consists of two
parts. The first part is a header describing the type of the
message, the certificate and the revocation list versions. The
second part contains the message body.
At the beginning, we will consider a set of a TG users aiming
to communicate on a topic "T". Each one, noted UTGi, has a
certificate CUTGi published by the CA and its own private key
SKUTGi. We also assume that at least one TG user has the
public key PKT and the private key SKT of the topic T.
We consider a new user UTGN who wants to communicate in a
secure manner through the topic T. The first step is to retrieve
the certificate of the topic T, which contains the public key PKT.
For this, UTGN will send a request (containing the Response
Topic RT) for topic T’s certificate on the topic DT. The
modeling of this is summarized in the following lines:
UTGN →DT
UX: MT, TT, RT
UTGN: New TG user.
DT: Demand Topic.
UX: the User who handles the request.
MT: the message type, in this case: “the certificate request”
TT: Target Topic, in this case: the topic "T".
RT: Response Topic.
Algorithm 1: Certificate request
Input: MT, TT, DT output:
BEGIN
RT ← generateRandomTopic ()
subscribe (RT)
M← {MT, TT, RT}
publish (DT, M)
END
Figure 1: Certificate request algorithm
Any UX having the Topic certificate TC can respond to the
request above by including it in a response on RT. UTGN will
stop listening after he receives the first valid response:
UX →RT
UTGN: MT, TT, TC
MT: the message type, in this case: “the certificate response”
TC: Topic Certificate of "T".
Algorithm 2: Certificate response
Input: {MT, TT, RT} output:
BEGIN
RM← {MT, TT, RT}
TT ← getTargetTopic (RM)
RT ← getResponseTopic (RM)
TC ← getTopicCertificate (TT)
MT← getMTPublicKeyResponse ()
M ← {MT, TT, TC}
publish (RT, M)
END
Figure 2: Certificate response algorithm
The second step is obviously to request the secret key SKT. For
this, UTGN will send a private key request for the topic "T"
(containing the Response Topic RT along with his own
certificate, both encrypted with PKT) on the topic DT.
UTGN →DT
UX: MT, TT, {CUTGN, RT} PKT
MT: Message Type, in this case: "private key request".
CUTGN: Certificate of the user UTGN.
PKT: Public Key of the Topic "T".
Vol. 15, No. 8, Augus 2017
ISSN 1947-5500

Algorithm 3: Private Key request
Input: MT, TT, CUTGN, DT output:
BEGIN
PKT← getPKT (TT)
RT ← generateRandomTopic ()
RT ← getResponseTopic (M)
EM← encrypt ({CUTGN, RT}, PKT)
subscribe (RT)
M← {MT, TT, EM}
publish (DT, M)
END
Figure 3: Private Key request algorithm
Only an UX owning SKT can decrypt {CUTGN, RT} PKT. He
checks the certificate CUTGN in order to send a private key
response containing the SKT encrypted with the public key of
UTGN named PKUTGN on the topic RT.
UX →RT
UTGN: MT, TT, {CUX, SKT} PKUTGN
MT: message type, in this case: "private key response".
SKT: secret key of “T”.
CUX: the user UX certificate
PKUGCN: public key of UTGN
Algorithm 4: Private Key response
Input :{ MT, TT, {CUTGN, RT} PKT}, CUX output:
BEGIN
RM ← {MT, TT, {CUTGN, RT} PKT}
TT ← getTargetTopic (RM)
PKT← getPKT (TT)
DM ← decrypt ({CUTGN, RT} PKT, PKT)
CUTGN← getUserCertificate (DM)
RT ← getResponseTopic (DM)
IS_UCOK← verifyUserCertificate (CUTGN)
If IS_UCOK =true then
SKT← getPrivateKey (TT)
PKUTGN← getUserPublicKey (CUTGN)
ESM ←encrypt ({CUX, SKT}, PKUTGN)
M ← {MT, TT, ESM}
publish (RT, M)
End if
END
Figure 4: Private Key response algorithm
After receiving a private key response, UTGN will decrypt
{CUX, SKT} PKUTGN (using PSUTGN), check CUX and stop
listening to RT.
UTGN can henceforth communicate with other users on the
target topic T using the pair SKT and PKT:
UTGN →T
UX: MT, TT, {M} PKT
MT: the message type, in this case: "Encrypted Message"
A. Topic keys management:
Among the essential features of a "CA" is to update the
revocation list (fraud, loss of keys, attack...). Indeed, to ensure
that a revoked certificate is not used, we will introduce in all
exchanged messages an additional field in the header
representing the version of the revocation list.
The above list is simply a message signed by the "CA"
containing the serial numbers of the revoked certificates along
with the list’s version which is updated after every modification.
To retrieve the last version, a user will send a revocation list
request on the demand topic DT:
Ui → DT
Uj: MT, RT
MT: message type, in this case: revocation list request
The answer to this request by the user Uj will be:
Uj → RT
Ui: MT, RL
MT: message type: Response to revocation list request
RL: List of Revoked Certificates
This request is sent in two cases; the first is at the beginning,
when a client lunches his program, the second case is the
reception of a message with a version of the revoked list newer
than the user’s version. In the latter case, the user stops its
activity (sending messages, handling requests...) in order to fetch
the current revocation list. Subsequently, the user will update his
certificates data base in compliance with the new revocation list.
B. handling of the hierarchical topics:
In most cases, topics are organized in a hierarchical structure,
so that a user can subscribe for one or multiple levels in one time.
In this case the user will not retrieve all the keys related to topics
within a hierarchy. He will, on the contrary, wait until he
receives a message on a giving topic, and run the process of key
retrieving in case he does not have it.
C. System Setting:
For the proper functioning of the system, we will introduce
two parameters:
The first parameter is a waiting time before restarting a new
request. Basically, our approach is based on a request-response
logic. However, the response may not arrive. Hence, the
applicant should be able to resend a new one. For that, the
protocol defines a period of validity for the requests so that the
user ignores an out of date message.
For this reason, we add two additional fields in the header;
the sending timestamp and the period of validity.
Ui → DT
Uj: MT, RT, timestamp, PV
PV: period of validity
The second parameter is related to the processing control and
the system constraints. To protect the users against DoS attacks,
we use thresholds (e.g. energy level, number of simultaneous
requests, bandwidth…) beyond which we the system stop
processing requests.
Those two parameters depend on the type of the
implementation. For example, in an "Internet of Things"
environment the energy efficiency and processing capacity are
primary constraints.
Vol. 15, No. 8, Augus 2017
ISSN 1947-5500

D. Modelisation :
To implement our approach, we choose the following
scenario: we assume that a set of connected users want to receive
metrics (e.g. temperature, humidity…) assessed by a Wireless
Sensor Network (WSN) through their mobile devices (smart
phones, tablets, laptops…) using a publish/subscribe broker. Our
implementation is based on the MQTT [11] protocol.
MQTT is an open source M2M (Machine to Machine)
protocol created by IBM and based on the publish/subscribe
pattern, it is often used in an Internet of things “IoT”
environment due to its low usage of bandwidth. It offers three
quality service levels and a last well notification mechanism in
case of a user disconnection. In November 2014, MQTT v3.1.1
has become a standard OASIS (Organization for the
Advancement of Structured Information Standards). A new
version of this protocol called MQTT - SN (MQTT for Sensor
Networks) intended for a no IP protocols such as Zigbee is now
available.
Our architecture (Figure 5) contains a Zigbee WSN
connected to a Raspberry chip which publishes the
measurements to a public MQTT broker.
Figure 5: Global model of experimental plateform.
We used Java as a programming language due to its richness
in functionality and its multiplatform aspect. We used the
Eclipse PAHO Library that offers MQTT 3.1.1 implementation.
We have developed our solution as a layer above the PAHO
Library (Figure 6). This allows us to use the same code on
multiple platforms (Android, Raspberry ...).
To secure all keys and certificates, we stored them in a Java
"keystore" encrypted with a password. This can be easily
replaced in a future work with a TPM (Trust Platform Module).
FIGURE 6: The architecture of a software application.
Our solution does not depend on the PAHO API. Indeed, we
used a java interface named “PublishSubscribe” implemented
with a class “PublishSubscribeImpl” (Figure 7). This will allow
us to easily switch to another MQTT implementation if needed.
The Message class represents a sent message in our protocol,
which contain a head (message type, target topic and the
revocation list version) and a body.
For each message type we have a different class that
implement the DetailMessage interface (SimpleMessage,
CertifcateRequest…) (Figure 8).
Figure 7: Class Diagram 1.
Figure 8: Class Diagram 2.
Any message type that uses an encrypted entity will
instantiate the EncryptedObject class which contains a
symmetric key “Ks” encrypted with a public asymmetric key
and an object encrypted with “Ks”.
IV. IMPLEMENTATION AND RESULTS :
We used the MEMSIC platform which is a Zigbee WSN, it’s
composed of a based station, the “MIB520” (Figure 9), and a set
of MICAZ sensors the (MDA100) (Figure 10). The said station
is connected with a Raspberry PI board (Figure 11) through a
USB port which publishes data to a MQTT server (Mosquitto).
Vol. 15, No. 8, Augus 2017
ISSN 1947-5500

Figure 9: based station MIB520.
Figure 10 : MDA100 sensor.
Figure 11 : Raspberry PI.
Figure 12: Initialization phase
The figure above shows the initialization phase through which
we connect to a MQTT test server and lunch the process of key’s
retrieving.
Figure 13: Getting Data
After obtaining the key pair, we start receiving data (Figure 9).
CONCLUSIONS AND FUTURE WORK
in fact, the Industry 4.0 revolution brings a new risk
type for smart manufacturers and digital supply networks. In this
industry, cybersecurity strategies should be secure.
However, our approach allows to be vigilante towards
cyber attacks this through protecting the data exchange in no
secure communication, thus we proposed a new approach to
distribute encryption-decryption keys through a
Publish/Subscribe protocol which is widely used in IoT
environments. In the future work we will try to expand our
approach to be multiprotocol with the same security level.
REFERENCES
[1] T. Jonathan Charity and H. Jian Hua, “Smart World of Internet of Things
(IoT) and It's Security Concerns”, 2016 IEEE International Conference on
Internet of Things.
[2] M. Radovan*, B.Golub and Daimler AG, “Trends in IoT Security”, 2017
40th International Convention on Information and Communication
Technology, Electronics and Microelectronics.
[3] Gartner Inc., Gartner Press Release - 6.4 Billion Connected, “Things“
Will be in use in 2016, Stamford, Connecticut, USA :
http://www.gartner.com/newsroom/id/3165317, 2015.
[4] E. Osmanoglu Identity and Access Management: Business Performance
Through Connected Intelligence
[5] National Institute of Standards and Technology, “Specification for the
Advanced Encryption Standard (AES)”, Federal Information Processing
Standards Publication 197, November 26, 2001.
[6] R.L. Rivest, A. Shamir, and L. Adleman , “A Method for Obtaining
Digital Signatures and Public-Key Cryptosystems “.
[7] C. Yuan Chen and H. Chieh Chao, “A survey of key distribution in
wireless sensor networks”, Security Comm. Networks (2011). Online Library
[8] P. Adusumilli, X. Zou, B. Ramamurthy, “DGKD: Distributed Group Key
Distribution with Authentication Capability”, 2005 IEEE Workshop on
Information Assurance and SecurityUnited States Military Academy,
West Point, NY
[9] Yu-Yi Chen ,Chuan-Chiang Huang, Jinn-Ke Jan” The Design of Secure
Group Communication with Contributory Group Key Agreement Based
on Mobile Ad Hoc Network” 2016 IEEE 2016 International Symposium
on Computer, Consumer and Control
[10] D. Dolev and A.C. Yao. On the security of public-key protocols. IEEE
Transactions on Information Theory, 29(8):198– 208, August 1983
Vol. 15, No. 8, Augus 2017
ISSN 1947-5500

[11] OASIS Message Queuing Telemetry Transport (MQTT) Version 3.1.1
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf
[12] C. Adams and S. Lloyd ,”Understanding PKI: Concepts, Standards, and
Deployment Considerations”
AUTHORS PROFILE
Mektoubi Abdessamad currently a PhD student, University Hassan II
/ENSEM Casablanca Morocco. Received an engineering degree in
computer science in 2011 at ENSEM- Casablanca Morocco.
Research: Internet of things (Iot) security.
Olaf MALASS he is currently attached with NationalSchool of
Arts/ and Crafts/ ParisTech in Metz/France asAssociate Professor
in A3SI department.
Research: Automatic Signal Processing and
ComputerEngineering.
Hicham BELHADAOUI currently working as a Professor Ability
in UniversityHassan II /ESTC, Casablanca Morocco. Received his
Phd degree at the National Polytechnic Institute of
Lorraine/France.
Research: Security, Reliability, Automatic Signal Processingand Computer
Engineering.
Mounir RIFI currently working as a Professor in University
Hassan II /ESTC, Casablanca Morocco. Obtained his PhD
Physical Sciences: ElectroMagnetic Compatibility, October 1996
(University Mohamed V of Rabat - Morocco) and PhD in
Electronics, May 1987 (University of Lille - France) Director of
the Research Laboratory: RITM (Networks, Computer, Telecom
and Multimedia)
Research: Propagation of electromagnetic waves,
ElectroMagnetic Compatibility, RFID, Microwave, Transmission
Lines Theory, Antennas, Sensors, Networks.
Vol. 15, No. 8, Augus 2017
ISSN 1947-5500

New Approach for Keys Distribution Through Publish/Subscribe Protocols

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to New Approach for Keys Distribution Through Publish/Subscribe Protocols

Similar to New Approach for Keys Distribution Through Publish/Subscribe Protocols (20)

Recently uploaded

Recently uploaded (20)

New Approach for Keys Distribution Through Publish/Subscribe Protocols