CLIAMS:1. A computer implemented system using message queuing telemetry transport protocol for selective secure data transfer of heterogeneous data, said system comprising:
a generating host, a public key generation unit, a broker and a plurality of client nodes;
the generating host configured to formulate and transmit an access policy having pre-determined attributes, receive public parameters, and generate, encrypt and transmit heterogeneous data having related topic identifiers;
the public key generation unit configured to receive access policies, verify the generating host and the client nodes, generate public parameters and private keys based on the access policies, and transmit generated public parameters to the generating host and private keys to the client nodes;
the broker configured to receive subscription requests containing topic identifiers from client nodes, create tables containing matches between client nodes and corresponding subscription requests, receive encrypted heterogeneous data having related topic identifiers, match received topic identifiers with client nodes using the created tables to identify suitable client nodes and transmit encrypted heterogeneous data selectively to the suitable client nodes; and
client nodes having inherent set of attributes, each of the client node configured to transmit subscription request containing topic identifiers corresponding to topics, receive private keys from the public key generation unit and encrypted heterogeneous data related to the subscribed topics from the broker, and decrypt received heterogeneous data with a received private key by comparing its attributes with the attributes in the access policy thereby achieving selective secure data transfer of heterogeneous data from generating host to itself.

2. The system as claimed in claim 1, wherein the generating host comprises the following:
a first repository configured to store a pre-determined first set of rules and at least one access tree containing a set of pre-determined attributes;
an input module configured to cooperate with the first repository and invoke the stored access tree;
a first processor configured to cooperate with the input module to receive the invoked access tree and with the first repository to receive the pre-determined first set of rules, and further configured to provide a first set of processing commands based on said pre-determined first set of rules and formulate an access policy having said set of pre-determined attributes based on the invoked access tree;
a first transceiver configured to cooperate with the first processor and transmit under influence of the first set of processing commands to the public key generation unit, the formulated access policy and the unique identifier, and receive from the public key generation unit, public parameters associated with each of said attributes present in the formulated access policy;
an encrypter configured to cooperate with the first processor and the first transceiver, and encrypt under influence of the first set of processing commands, heterogeneous data using the access policy and the received public parameters; and
a first transmitter configured to transmit through a secure publish message command and under influence of the first set of processing commands to the broker, the encrypted heterogeneous data and a topic identifier related to the heterogeneous data.

3. The system as claimed in claim 1, wherein said public key generation unit comprises the following:
a second processor configured to provide a second set of processing commands based on a pre-determined second set of rules;
a first receiver configured to receive from the generating host the unique identifier and the access policy, and receive from the plurality of client nodes respective unique identifiers, sets of attributes and topic identifiers;
a verification module configured to cooperate with the second processor and the first receiver and further configured to verify under influence of the second set of processing commands, the generating host and the client nodes based on the received unique identifiers;
a public parameter and private key generator configured to cooperate with the second processor and the first receiver and further configured to generate public parameters and private keys for each of the attributes present in the access policy under influence of the second set of processing commands; and
a second transceiver configured to cooperate with the verification module and the public parameter and private key generator, and configured to transmit to the verified generating host, the generated public and to the verified client nodes, the private keys for each of the attributes received from said client nodes.

4. The system as claimed in claim 1, wherein the broker comprises the following:
a third processor configured to provide a third set of processing commands based on a pre-determined third set of rules;
a second receiver configured to cooperate with the third processor and receive under influence of the third set of processing commands, subscription requests containing the topic identifiers from the client nodes and unique identifiers of respective client nodes;
a second repository configured to cooperate with the third processor and the second receiver and further configured to store under influence of the third set of processing commands, a table containing matches between the client nodes and corresponding subscription requests containing topic identifiers;
a third receiver configured to cooperate with the third processor to receive third set of processing commands and with the generating host to receive encrypted heterogeneous data and related topic identifier, the third receiver having a comparator configured to cooperate with the second repository and match under influence of the third set of processing commands, the received topic identifier with the client nodes using the created tables to identify suitable client nodes; and
a second transmitter configured to cooperate with the third processor and the third receiver and further configured to transmit selectively under influence of the third set of processing commands, the encrypted heterogeneous data to the identified suitable client nodes.

5. The system as claimed in claim 1, wherein each of the plurality of client nodes comprise the following:
a fourth processor configured to provide a fourth set of processing commands based on a pre-determined fourth set of rules;
a third transceiver configured to transmit to the public key generation unit under influence of the fourth set of processing commands, the unique identifier, the set of attributes of the client node and transmit to the broker the subscription requests containing topic identifiers corresponding to topics pre-determined by the client node, and receive from the public key generation unit, private keys corresponding to the transmitted set of attributes;
a fourth receiver configured to receive from the broker, under influence of the fourth set of processing commands, the encrypted heterogeneous data related to the subscription requests transmitted by third transceiver;
a determiner configured to cooperate with the public key generation unit to receive the set of attributes present in the access policy and further configured to compare the received set of attributes present in the generated access policy with set of inherent unique attributes of the client node to determine if the client node satisfies the access policy; and
a decrypter configured to cooperate with the third transceiver, the fourth receiver and the determiner, and further configured to decrypt the encrypted data with the received private key if the client node satisfies the access policy to obtain the data related to corresponding subscribed topics.

6. The system as claimed in claim 1, wherein the generating host is configured to encrypt heterogeneous data using the received public parameters and a random number.

7. The system as claimed in claim 1, wherein the broker identifies client nodes suitable for communication by determining whether said client nodes satisfy the access policy.

8. The system as claimed in claim 1, wherein the broker comprises an editor configured to edit the created table by one of addition and deletion of one of the client nodes and the subscription requests.

9. The system as claimed in claim 1, wherein the broker comprises a sorter configured to sort the heterogeneous data based on a pre-determined importance score of the subscription requests.

10. The system as claimed in claim 1, wherein said system provides inter-broker communication between brokers present in different clusters.
11. The system as claimed in claim 10, wherein a generating host present in one cluster publishes messages to client nodes from other clusters.

12. The system as claimed in claim 10, wherein said system provides inter-broker communication by configuring addresses of all brokers present in different clusters in a central broker.

13. A computer implemented method using message queuing telemetry transport protocol for selective secure data transfer of heterogeneous data, said method comprising the following steps:
formulating at a generating host, an access policy having pre-determined attributes, transmitting the access policy, receiving public parameters, and generating, encrypting and transmitting heterogeneous data having related topic identifiers;
receiving at a public key generation unit, access policies from the generating host, verifying the generating host and a plurality of client nodes, generating public parameters and private keys based on the access policies, and transmitting generated public parameters to the generating host and private keys to the client nodes;
receiving at a broker, subscription requests containing topic identifiers from the client nodes, creating tables containing matches between client nodes and corresponding subscription requests, receiving encrypted heterogeneous data having related topic identifiers, matching the received topic identifiers with the client nodes using the created tables to identify suitable client nodes and transmitting encrypted heterogeneous data selectively to the suitable client nodes; and
transmitting from each of the client nodes having inherent set of attributes, a subscription request containing topic identifiers corresponding to topics, receiving private keys and encrypted heterogeneous data, and decrypting received heterogeneous data with a received private key by comparing its attributes with the attributes in the access policy thereby achieving selective secure data transfer of heterogeneous data from generating host to itself.

14. The method as claimed in claim 13, wherein implementation of said method at the generating host comprises the following steps:
storing a pre-determined first set of rules and at least one access tree containing a set of pre-determined attributes;
invoking the stored access tree;
providing a first set of processing commands based on said pre-determined first set of rules;
formulating an access policy having said set of pre-determined attributes based on the invoked access tree;
transmitting under influence of the first set of processing commands to the public key generation unit, the formulated access policy and the unique identifier;
receiving from the public key generation unit, public parameters associated with each of said attributes present in the formulated access policy;
encrypting under influence of the first set of processing commands, heterogeneous data using the access policy and the received public parameters; and
transmitting through a secure publish message command and under influence of the first set of processing commands to the broker, the encrypted heterogeneous data and a topic identifier related to the heterogeneous data.

15. The method as claimed in claim 13, wherein implementation of said method at the public key generation unit comprises the following steps:
providing a second set of processing commands based on a pre-determined second set of rules;
receiving from the generating host, the unique identifier and the access policy, and receiving from the plurality of client nodes respective unique identifiers, sets of attributes and topic identifiers;
verifying under influence of the second set of processing commands, the generating host and the client nodes based on the received unique identifiers and transmitting to the verified client nodes, the set of attributes present in the received access policy;
generating public parameters and private keys for each of the attributes present in the access policy under influence of the second set of processing commands; and
transmitting the generated public parameters to the verified generating host and the private keys to the verified client nodes.

16. The method as claimed in claim 13, wherein implementation of said method at the broker comprises the following steps:
providing a third set of processing commands based on a pre-determined third set of rules;
receiving under influence of the third set of processing commands, subscription requests containing the topic identifiers from the client nodes and unique identifiers of respective client nodes;
creating and storing under influence of the third set of processing commands, a table containing matches between the client nodes and corresponding subscription requests containing topic identifiers;
receiving encrypted heterogeneous data and related topic identifier from the generating host and, matching under influence of the third set of processing commands, the received topic identifier with the client nodes using the created tables to identify suitable client nodes; and
transmitting selectively under influence of the third set of processing commands, the encrypted heterogeneous data to the identified suitable client nodes.

17. The method as claimed in claim 13, wherein implementation of said method at each of the client node comprises the following steps:
providing a fourth set of processing commands based on a pre-determined fourth set of rules;
transmitting to the public key generation unit under influence of the fourth set of processing commands, the unique identifier, the set of attributes of the client node and transmitting to the broker the subscription requests containing topic identifiers corresponding to topics pre-determined by the client node;
receiving from the public key generation unit, private keys corresponding to the transmitted set of attributes;
receiving from the broker, under influence of the fourth set of processing commands, the encrypted heterogeneous data related to the subscription requests transmitted by third transceiver;
receiving from the public key generation unit, the set of attributes present in the access policy and comparing the received set of attributes present in the generated access policy with set of inherent set of attributes of the client node to determine if the client node satisfies the access policy; and
decrypting the encrypted data with the received private key if the client node satisfies the access policy to obtain data related to corresponding subscribed topics.

18. The method as claimed in claim 13, wherein the step of encrypting the heterogeneous data includes the step of encrypting the data using the received public parameters and a random number.

19. The method as claimed in claim 13, wherein implementation of said method at the broker includes the step of identifying client nodes suitable for communication by determining whether said client nodes satisfy the access policy.

20. The method as claimed in claim 13, wherein implementation of said method at the broker includes the step of editing the created table by one of addition and deletion of one of the client nodes and the subscription requests.

21. The method as claimed in claim 13, wherein implementation of said method at the broker includes the step of sorting the heterogeneous data based on a pre-determined importance score of the subscription requests.

22. The method as claimed in claim 13, wherein said method provides inter-broker communication between brokers present in different clusters.

23. The method as claimed in claim 22, wherein said method of providing inter-broker communication includes the step of publishing messages from a generating host present in one cluster to a plurality of client nodes from other clusters.

24. The method as claimed in claim 22, wherein said method of providing inter-broker communication includes the step of configuring addresses of all brokers present in different clusters in a central broker. ,TagSPECI:TECHNICAL FIELD
The present disclosure relates to the field of secure data transfer using message queue telemetry transport protocol.
DEFINITIONS OF TERMS USED IN THE SPECIFICATION
The expression ‘IoT’ used hereinafter in this specification refers to Internet of Things wherein uniquely identifiable objects are represented in the Internet structure.
The expression ‘topic’ used hereinafter in this specification refers to a subject name/identifier that relates to specific data which is to be transmitted and/or received.
The expression ‘heterogeneous data’ used hereinafter in this specification refers to the data related to different topics.
The expression ‘generating host’ used hereinafter in this specification refers to a sending device that transmits information related to a particular topic. It can also generate the information that needs to be transmitted.
The expression ‘client node’ used hereinafter in this specification refers to a receiving device that receives information related to a particular topic to which the receiving device has subscribed.
The expression ‘broker’ used hereinafter in this specification refers to an interface device that enables communication between generating hosts and client nodes.
The expression ‘access tree’ used hereinafter in this specification refers to a tree structure used by the generating host for creating rules to allow the client nodes to access information related to subscribed topics.
The expression ‘access policy’ used hereinafter in this specification refers to rules created by the generating host using the access tree for allowing client nodes to access information related to subscribed topics.
The expression ‘public parameters’ used hereinafter in this specification refers to parameters related to various attributes of the access policy based on which the information is encrypted.
The expression ‘Pub-Sub protocol’ used hereinafter in this specification refers to a protocol in which the senders of messages do not directly send messages to specific receivers. The messages are instead characterized and the receivers only receive messages that are of their pre-determined interest.
The expression ‘ABE (Attribute-Based Encryption)’ used hereinafter in this specification refers to a type of public-key encryption in which the secret key of a user and the ciphertext are dependent on certain attributes, and the decryption of the ciphertext is possible only if the set of attributes of the user match the attributes of an access policy.
The expression ‘AES (Advanced Encryption Standard)’ used hereinafter in this specification refers to a symmetric block cipher technique used for encrypting data.
These definitions are in addition to those expressed in the art.
BACKGROUND
In recent years, innovations in the area of information communication technology have enabled rapid deployment of Internet of Things (IoT). The IoT can be utilized to provide solutions for multitude of diversified problems, for instance its services can be leveraged to realize a smart city, a smart home or a smart infrastructure. Even though the IoT has a lot of potential in the digital world, it encounters several issues with respect to heterogeneity of devices, device identities, device management and secure device to device communication during deployment. To overcome the issues of integration and management of heterogeneous IoT devices, architectures such as Ubiquitous Sensor Network (USN) and Sensor Web Enablement (SWE) have been proposed. But, considering the plethora of applications of IoT, it is essential to ensure security and privacy of the IoT and the users of the IoT with respect to identity, storage and communication. Proposed architectures like USN and SWE address the security and privacy issues, but, they do not address the issues of secure device to device communication and the issues in securing the device and its data and device identity theft. These techniques serve the purpose of basic security primitives during device to device communication, but, do not solve the issue at the communication protocol level. Protocols like Constrained Application Protocol (CoAP, UDP based) and Message Queue Telemetry Transport (MQTT, TCP based) have been proposed for IoT at different layers. However, these protocols do not have security features
Therefore, there is a need for a system and a method that provides an additional security feature for existing MQTT protocol to limit the aforementioned drawbacks.
OBJECTS
Some of the objects of the system and method of the present disclosure, which at least one embodiment herein satisfies, are as follows:
An object of the present disclosure is to provide a computer implemented system for secure data transfer using message queuing telemetry transport protocol.
Another object of the present disclosure is to provide a system that uses lightweight encryption to ensure message confidentiality.
Still another object of the present disclosure is to provide a method with a robust, scalable and lightweight encryption scheme.
Other objects and advantages of the present disclosure will be more apparent from the following description when read in conjunction with the accompanying figures, which are not intended to limit the scope of the present disclosure.
SUMMARY
The present disclosure relates to a computer implemented system and method using message queuing telemetry transport protocol for selective secure data transfer of heterogeneous data. In an embodiment, the system for selective data transfer comprises a generating host, a public key generation unit, a broker and a plurality of client nodes. Further the generating host may formulate and transmit an access policy having pre-determined attributes. It may also receive public parameters, and generate, encrypt and transmit heterogeneous data having related topic identifiers. The public key generation unit may receive the access policies, verify the generating host and the client nodes and, generate public parameters and private keys based on the access policies. The public key generation unit may further transmit the generated public parameters to the generating host and private keys to the client nodes. The broker present in the system may receive subscription requests containing topic identifiers from client nodes and create tables containing matches between client nodes and corresponding subscription requests. The broker may further receive encrypted heterogeneous data having related topic identifiers and then match the received topic identifiers with client nodes using the created tables to identify suitable client nodes. Furthermore, the broker may transmit encrypted heterogeneous data selectively to the identified suitable client nodes. The client nodes present in the system may have inherent set of attributes. Each of the client nodes may transmit subscription request containing topic identifiers corresponding to topics to the broker and receive private keys from the public key generation unit and encrypted heterogeneous data related to the subscribed topics from the broker. The client node may then decrypt the received heterogeneous data with a received private key by comparing its attributes with the attributes in the access policy thereby achieving selective secure data transfer of heterogeneous data.

BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS
A computer implemented system of the present disclosure using message queuing telemetry transport protocol for selective secure data transmission of heterogeneous data will now be described with the help of accompanying drawings, in which:
Figure 1 illustrates one embodiment of a schematic of the system for selective secure data transfer between a generating host and client nodes via a broker;
Figure 2 illustrates an MQTT Header;
Figure 3 illustrates an embodiment of SMQTT architecture of the system using ‘SPublish’ command message based on the ABE scheme;
Figure 4 illustrates an embodiment of an access policy represented as an n-ary tree, where n = 2;
Figure 5 illustrates an interaction diagram of SMQTT protocol;
Figure 6 illustrates an MQTT−SN architecture diagram;
Figure 7 illustrates a typical message format of MQTT-SN;
Figure 8 illustrates a Variable Message Header for Publish command of MQTT-SN;
Figure 9 illustrates an architecture diagram of an embodiment of internetworking of Brokers in MQTT−SN; and
Figure 10a, 10b and 10c illustrate graphs displaying experimental results of the SMQTT scheme for packet overhead, performance of ABE encryption and performance of ABE decryption respectively.
DETAILED DESCRIPTION
A preferred embodiment of the present disclosure will now be described in detail with reference to the accompanying drawings. The preferred embodiment does not limit the scope and ambit of the disclosure. The description provided is purely by way of example and illustration.
The embodiments herein and the various features and advantageous details thereof are explained with reference to the non-limiting embodiments in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
The following description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.
MQTT protocol is used for communication between the IoT devices. It is a Pub-Sub protocol for device (generating host: sending device) to device (client node: receiving device) communication based on Transmission Control Protocol (TCP) through a broker. In this protocol, a generating host publishes a message based on a topic. Subsequently all the client nodes who subscribe to that topic receive the message through a broker. Various message types are used in this protocol that are distinguishable by message type in the MQTT message header. Referring to the accompanying drawings, Figure 2 represents an MQTT header. It consists of two bytes of a Fixed Header, a Variable Header whose length varies and Payload. In the Fixed header, the first byte contains fields like Message Type, QoS Level, Dup Flag and Retain Flag (Ret). From the second byte, the length of the packet is inferred. Four bits are allocated to accommodate 16 message types (such as subscribe, publish, connect, etc.) and the message type ‘0000’ is reserved for the future. Further, the DUP flag indicates whether the packet is retransmitted or not. The Retain flag indicates whether the packet in the queue must be retained or not after sending it to the corresponding clients. The Variable header is followed after the fixed header which contains these flags. A password and a username flag can be set and their corresponding values can be included in the payload. However, these values are not encrypted and are unsafe. To overcome this, the system in the present disclosure proposes a Secure MQTT (SMQTT) protocol which provides an additional security feature to the existing MQTT. To achieve this, a new MQTT Publish message command ‘Spublish’ with message type 0000 is introduced, wherein the payload is encrypted using Attribute Based Encryption (ABE) scheme.
Typically, the systems that use ABE to ensure privacy for IoT encrypt the data using symmetric Advance Encryption System (AES) cryptography, as the size of the cipher text remains constant by using the AES key. But, usually most of the IoT devices generate only few bits of data and to encrypt that data devices are required to perform both AES and ABE encryption techniques which tend to increase overhead for these devices. The system of present disclosure envisages a reconfigured ABE scheme adapted for secure transmission of data between a generating host and a plurality of client nodes.
Referring to the accompanying drawings, Figure 1 illustrates one embodiment of a schematic of the system for selective secure data transfer between a generating host and client nodes via a broker. In the exemplary embodiment, the system 100 comprises a generating host 102 that selectively and securely transfers heterogeneous data to a plurality of client nodes 108 via a broker 106 by using message queuing telemetry transport protocol. The generating host 102 is also configured to generate heterogeneous data. The generating host 102 and each of the client nodes 108 have unique identifiers that enable them to be verified by a public key generation unit 104. The generating host 102 comprises a first repository 110 which stores a pre-determined first set of rules and an access tree containing a set of pre-determined attributes. An input module 112 present in the generating host 102 invokes this stored access tree containing the pre-determined attributes and provides the invoked access tree to a first processor 114. The first processor 114 present in the generating host 102 then formulates an access policy based on the first set of processing commands. This formulated access policy contains the sets of attributes present in the invoked access tree. A first transceiver 116 then transmits this formulated access policy and the generating host’s unique identifier to the public key generation unit 104. A third transceiver 144 present in each of the client node 108 also transmits a respective unique identifier of the client node 108 and an inherent set of attributes of that client node 108 to the public key generation unit 104. This data including the unique identifier and the formulated access policy from the generating host 102 and respective unique identifiers and sets of attributes from the client nodes, is received by a first receiver 124 present in the public key generation unit 104 based on a second set of processing commands provided by a second processor 122 present in the public key generation unit 104. This received data is then used by a verification module 126 that cooperates with the first receiver 124. The verification module 126 verifies under influence of the second set of processing commands, the generating host 102 and the client node 108 based on the received respective unique identifiers. On successful verification, a public parameter and private key generator 128 present in the public key generation unit 104 generates public parameters and private keys for each of the attributes present in the received access policy. A second transceiver 130 present in the public key generation unit 104 then transmits the generated public parameters to the first transceiver 120 of the generating host 102 and also transmits the generated private key for each of the attribute of the client node 108 to respective verified client node 108. An encrypter 118 present in the generating host 102 uses the received public parameters and the generated access policy to encrypt heterogeneous data to be published to the client node 108 via the broker 106. The generating host 102 comprises a first transmitter 120 that transmits this encrypted heterogeneous data and a topic identifier related to the data through a secure publish-message command to the broker 106.
The broker 106 comprises a third processor 132 that is configured to provide a third set of processing commands based on a pre-determined third set of rules. The encrypted heterogeneous data transmitted through the secure publish message command by the first transmitter 120 of the generating host 102 is received by a third receiver 138 present in the broker 106. The broker comprises a second receiver 134, which under influence of the third set of processing commands, receives subscription requests from client nodes 108. These subscription requests contain topic identifiers denoting the topics that the client node 108 wants to subscribe to along with the unique identifier of the client node 108. Based on the subscription request, a table is created that contains matches between the client nodes and corresponding subscription requests, which is stored in a second repository 136 present in the broker 106. On receiving the encrypted heterogeneous data and related topic identifier from the generating host 102, the third receiver 138 present in the broker 106, matches with the help of a comparator 138a present, the received topic identifier with the client nodes based on the stored table to identify suitable client node 108. Once the suitable client node 108 is identified a second transmitter 140 present in the broker 106 selectively transmits the received encrypted heterogeneous data to the suitable client node 108 who has subscribed to the topic related to which the data is being transmitted.
This published encrypted data related to the topic identifiers to which the client node 108 has subscribed, is received by a fourth receiver 146 present in each of the client node 108. The client node 108 comprises a fourth processor 142 that provides a fourth set of processing commands to the components present in the client node 108. Based on the fourth set of processing commands, the third transceiver 144 present in the client node 108, transmits the unique identifier and the set of attributes of the client node 108 to the public key generation unit 104 and also transmits the subscription requests having topic identifiers to the broker 106. The third transceiver 144 also receives private keys corresponding to the transmitted set of attributes from the public key generation unit 104. A determiner 148 present in the client node 108 cooperates with the public key generation unit 104 to receive the set of attributes present in the access policy and then compares the received set of attributes with a set of inherent unique attributes of the client node 108 to determine if the client node 108 satisfies the access policy. If the client node 108 satisfies the access policy, a decrypter 150 present in each of the client node 108 decrypts the received encrypted heterogeneous data with private keys related to its attributes, received by the third transceiver 144 to obtain the data related to corresponding subscribed topic thus allowing a selective and secure data transfer of heterogeneous data between the generating host 102 and the client node 108.
In one embodiment, if a client node is a low end device then the broker determines if the client node satisfies the access policy and publishes the data encrypted by the generating host only to the client nodes that satisfy the access policy.
In another embodiment, the system of the present disclosure comprises an editor that edits the table created by the broker. The editor adds and/ or deletes the identifiers of the client nodes and/ or the subscription requests of the client nodes.
In one more embodiment, the broker comprises a sorter that sorts heterogeneous data based on a pre-determined importance score of the subscription requests. This allows a client node to prioritize the data request. The broker then transmits the sorted heterogeneous data based on the client nodes prioritization request.
Referring to the accompanying drawings, Figure 3 illustrates an embodiment of SMQTT architecture of the system using ‘SPublish’ command message based on the ABE scheme. A new publish service ‘SPublish’ is proposed in this embodiment which uses the reserved message type ’0000’ and the message is encrypted using Attribute Based Encryption. In order to make it lightweight and suitable for IoT, ABE scheme based on lightweight Elliptic Curve cryptography (ECC) is incorporated. Here, a generating host uses ‘Spublish’ command to publish/transmit an encrypted message/data based on an access policy and only those client nodes, which satisfy the access policy, are capable of decrypting the published message/data. Typically, the access policy is expressed as predicate with set of attributes and Boolean constructs (OR, AND, NOT, etc.).
Further, Figure 4 from the accompanying drawings illustrates an embodiment of an access policy represented as an n-ary tree, where n = 2. Here a temperature sensor device publishes a temperature data under the topic ‘Smart Home’ through ‘SPublish’ in which only a client node who is either part of fire alarm system or utility system which is either a heater or air condition controller and whose location id matches with the location of the temperature sensor can decrypt the data for the smart home application. The payload data consists of cipher text (encrypted data) along with this access policy in order to allow only the client nodes who have subscribed to ‘Smart Home’ to decrypt the cipher text.
In Attribute Based Encryption a sender party (Generating Host) encrypts a document for all users (client nodes) that have a certain set of attributes. Any user who has an identity that contains all of these attributes can decrypt the document. The user can reconstruct a decryption key using the polynomial interpolation method (for example, the Lagrange’s interpolation technique). There are two types of ABE schemes: Key Policy Attribute based Encryption (KP-ABE) and Cipher text Policy Attribute based Encryption (CP-ABE). In KP-ABE the user private keys contain the access policy which is the collection of rules defined using the attributes for decryption. The attribute values are part of the cipher text. This scheme can handle AND, OR and Threshold gates. But it does not support the Not gate. In contrast, in case of CP-ABE scheme, the cipher text contains the access policy and the user decryption keys contain the attributes.
The system of the present disclosure provides additional features for MQTT protocol with both KP-ABE and CP-ABE scheme. To enable ABE, activities including setup, extract, encryption and decryption need to be performed. Referring to Figure 3, in an exemplary embodiment during the setup phase, a Public Key Generation unit (PKG) generates the master secret key and publishes public parameters for each attribute of the access policy. Considering an illustration for secure MQTT based on CP-ABE and KP-ABE, system parameters generated by the Public Key Generation unit (PKG) during the setup phase are as follows:
• Equation of Super Singular Elliptic Curve E: y2=x3+x over prime number p
• Random number generated r = 2345678901 for encryption
• Master secret key for Encryption sres = 1094825639957159221500547207126964684157066674176
where, sres is used to generate private keys of the attributes
• Prime number p (upper bound for the integer field) = 109836762562089755439710412785302291476310964802292886550311415346968690934362496833960954250583272879636740982263693728593951807995466301001184452657841041367
• Prime number q (upper bound for Torsion Field) = 13729595320261219429963801598162786434538870600286610818788926918371086366795312104245119281322909109954592622782961716074243975999433287625148056582230130171
• Point on the Elliptic curve that is generated from P.
P (x, y, z) = (85608477432040872385960847112824018951251309935206137694359293826606576385337371410876654409828742430690547501791617445653251518387066512551328921926675082346, 15223893830655100048486511306704881399342401222794478356575765909334632261068308382179592627672068294267070303117177724020711813772432452182844069643762457960,
1)
•Point on the Elliptic curve that is generated from Q.
Q (x, y, z) =
(66915172303021824801945469853790102911679193945242404457300535394326755718413293783652688630763735784682909588065604985206396398451912846497620686434410899902,
62867566528032463334656073847898888391891358824924567484556833767976763777434602169044694857775634686335880529642765789804483766840906166637104010129697363736,
1)
In this illustration, the system parameters are considered for a protocol which is common for both the schemes (KP-ABE and CP-ABE). Here, p, q, E, P and Q are the public parameters used during key generation, encryption and decryption.
Each device must register itself with an Identity and set of attributes with the Public Key Generation unit. The PKG then verifies the attributes and other details given by the user and based on the verification result, the Public Key Generation unit sends public parameters (p, q, E, P and Q in reference to the aforementioned illustration) to sending device (Generating Host) for encrypting data. In KP-ABE scheme, only the public parameters and private keys are shared by the PKG. When the access policy is changed, the private keys also need to be changed as the scheme is condition based. In continuation with the illustration, an access policy for the ABE scheme in this example states that the message in MQTT payload can be decrypted only when all five doctors Dr. A, Dr. B, Dr. C, Dr. D and Dr. E submit their keys. Hence, the access policy is the logical ‘AND’ of all the attributes of the above five doctors and the values for keys in this access policy as obtained by the PKG considering the KP-ABE approach are as follows:
• Dr. A (x, y, z) (21403529407598868599091416475528683957215573967510975404349957547984369080035720880465111714414120383757444842435582002582444127658586690161153447416702327710,
86834154977639981025674100822106255028041826599973478786358202032385823298992451250693270369423602890630551331152099821072245008122337075956892136718115980276,
1)
• Dr. B (x, y, z)
(21392307520430479279486958118412905609986299845212443336572975900497045413302832309876790485675597633416819355467227000711264461309574495213350063412432360562,
4293201081936832547101816984477759974060069461626508412895351974849311112363949212151155661486699181912912328095959911839559847525322505552853937354386836,
1)
• Dr. C (x, y, z)
(7568541424601164292957465127224367243705237841294852378009303205952506369243260869825762259120787241533295022763219865850167358044358865718454434988577091770,
13620251352958356642125499094262073106363368542177014502582524085375396764105196449271724753050467175989207437398069962568471476766040807136267414869240410988,
1)
• Dr. D(x, y, z)
(92442514572737524557817325911507437131103853315504587059724690251149809221844061109280216421391297683846530378800133106122518913696216237897332913092518799306,
89810329506196516577137545365900383911656364130156282024625012364367075889282370983141882865486247716594144942724980889901252808945959813936477396107585017645,
1)
• Dr. E (x, y, z)
(7902583611895715927845418309764984858744365784821824271522981081786944819116546888748707550194971275911696843138664412453641268780020486233621896793832982661,
34695138237509518878371095568339442114016959023222777458944087429887533224015132661044374637084859459223054859932942662212303172199898360995691554970186062435,
1)
In CP-ABE scheme, the public parameters and private keys for each attribute is generated by the PKG. However, in this scheme, if the access policy changes, the private keys need not be changed as the scheme is attribute based. Therefore, considering the illustration, in case of CP-ABE scheme, parameters added for each of the attributes are D, DJDash, DJ, CY and CYDash, wherein these points lie on an elliptic curve ‘E’ which means that they are in form (x, y, z). Therefore, values for keys as obtained by PKG considering the CP-ABE approach are as follows:
• Key : Dr. A
o D Value(x, y, z)
(45767095054127806355047906536582160113003949752207549508384341598205670467912972190721327693329666655911882135065143321367307074531140833542775825898513844736, 1060571780909373423672206585450586313081052880221618728548460657414520797551533216826977876211928513370721650571135616172190947226770210641677144319171712735,
1)
o DJDash(x, y, z)
(74229823924951453776210796896897238186562339698692516075598840141325693479407980325636480967294989358158818465113666469486337210696011955099652895753840340152,
6923624614371508980502211531018544096682701348443441019283745075648189834735388497096913978030614202744027700098179496679924343133019470971834527940032910311,
1)
o DJ(x, y, z)
(56015915797771677213712375578690856788433468789841431404133031733000178053444019475712637246647340862860864068224396684644453822286351869381419970570809245471,
14329621434587248321330318822003953445962630575478769575571452121816241992068643123616541508918708534403158641912491269902272083247585175052945985226239721945,
1)
o CY(x, y, z)
(22466280882847804768829032919120330905024542253228470758317533438252592203279529814890241206733887743277751361308687255267869914796949555639121096926669426968,
44758458684920978213759298313678686245571218477688412753469675778997768617363000376843601406910726071234668053808600598666595260431554765839539978520494238918,
1)
o CYDash(x, y, z) (95113610041249583671445060835722948569147093787549219913248303109738068107824757285607065397366597487685017768145898556444509333132670934991474149751901224929,
49271223362507121457851292145252008476644514183755711676356627906702077680858651687841083893921733009669543598514329662346646835431324938346143448421867918056,
1)

• Key : Dr. B
o D Value(x, y, z)
(45767095054127806355047906536582160113003949752207549508384341598205670467912972190721327693329666655911882135065143321367307074531140833542775825898513844736,
1060571780909373423672206585450586313081052880221618728548460657414520797551533216826977876211928513370721650571135616172190947226770210641677144319171712735,
1)
o DJDash(x, y, z)
(70179817134033535627325147586694995291625771923365069701257140722541168981950524137406715098456693890291210639712725178358933955737270578671615747800695684539,
107793887794012127550531346461865104563346878332308487281068450613409819938552857436629137702210093506256483187153568216235110633846091959325402150151897409376,
1)
o DJ(x, y, z)
(42168340874472208753094680238808606950294750224286066376083868236463580471866146122868356102692202794763756575098519352353069635309562467623848986555781573015,
57573239259917106243179337143764730477267512993217841802664844772144393120374643837092528053386942295553652379135602228834147362855941831719488065264258405408,
1)
o CY(x ,y, z)
(109004186331544741638530779252077605883326998011208788616856250779292195025959690312633934999447934417920686682140388940012830087993994548891234304175760416923,
36587943892736493708348880319080581824257020487543269135200759310557719626391374568961239502848183297969543541768079422287284141049280470507041446348949740990,
1)
o CYDash(x, y, z) (94855491596209744825377606927350371615997949743412188761858892828119297676740682257587714861462830526586580351086285344181127458180820580862060890978372732161,
89857158722051970694538778483691280467738707659910830481582311939907739137279805235448078099642123063710210095046350785645742773735123094853521303909592950200,
1)

• Key : Dr. C
o D Value(x, y, z)
(45767095054127806355047906536582160113003949752207549508384341598205670467912972190721327693329666655911882135065143321367307074531140833542775825898513844736,
1060571780909373423672206585450586313081052880221618728548460657414520797551533216826977876211928513370721650571135616172190947226770210641677144319171712735,
1)
o DJDash(x, y, z) (14401649511054416035524123024678061549503161490258106913579191957723216177841851580560317940153918312440703549949877714797979690371904548754223110286878519699,
95064850286248211637432070168463919205739070399466160747624048740721035424654925752489787452246767594384362730526625864074371477712768653346425108572898922931,
1)
o DJ(x, y, z)
(88380909237431920055598896166451861468814268250845460724696091589726702456612686154790617388259229334667264443606006038276460816010651541601094630848253138071,
93764960670546828578959924440830461336792896178049433571127849518546336572338190476986012735318507843309770473672469503824876938843705400672729700277190141876,
1)
o CY(x, y, z)
(89940847196305669920022316132534238855831579537735349341533664547155472326097832306668597911197551986493967034518260440700559305185824545225955310211200155117,
28364909541867611265940381691870448720496222925773623664471081028940183936026654052154849027405196453478025596575521435763575449913881152529987648093416487558,
1)
o CYDash(x, y, z) (38395954485903101070934005875249321307001394643804986002457570828083798547614927361945446925425204181835719898604136197202101517655749995335534036873552791913,
1716231995328763951367621774592018582973888064194066341030009093248974199383038098706150936411899121431280065240894479599533871774483382526492779913616853418,
1)

• Key : Dr. D
o D Value(x, y, z)
(45767095054127806355047906536582160113003949752207549508384341598205670467912972190721327693329666655911882135065143321367307074531140833542775825898513844736,
1060571780909373423672206585450586313081052880221618728548460657414520797551533216826977876211928513370721650571135616172190947226770210641677144319171712735,
1)
o DJDash(x, y, z) (74229823924951453776210796896897238186562339698692516075598840141325693479407980325636480967294989358158818465113666469486337210696011955099652895753840340152,
6923624614371508980502211531018544096682701348443441019283745075648189834735388497096913978030614202744027700098179496679924343133019470971834527940032910311,
1)
o DJ(x, y, z)
(56015915797771677213712375578690856788433468789841431404133031733000178053444019475712637246647340862860864068224396684644453822286351869381419970570809245471,
14329621434587248321330318822003953445962630575478769575571452121816241992068643123616541508918708534403158641912491269902272083247585175052945985226239721945,
1)
o CY(x, y, z)
(94909244485739352933736966061490844019021190592443244939714664167827150989190001118973885361579383507915728578226018948378570240438228484673557135962994460943,
102705704469703503696734117460437368390428295791265467994852319774348174625717489901588426499284445075037812651355106936970288744184685568912008581856695904666,
1)
o CYDash(x, y, z) (3408412474797221993465175946090922226782055396276867622106576841045447052525507623738366516456672840315263290951532346880983948667431300042579912230449986691,
43694625990451974154397768647823524954618155864841325614041729515274109178730730058250680476948647606883067358633933793239937680975569609522776710298662627231,
1)

• Key : Dr. E
o D(x, y, z)
(45767095054127806355047906536582160113003949752207549508384341598205670467912972190721327693329666655911882135065143321367307074531140833542775825898513844736,
1060571780909373423672206585450586313081052880221618728548460657414520797551533216826977876211928513370721650571135616172190947226770210641677144319171712735,
1)
o DJ Dash(x, y, z)
(9606053588569844911156539493871236397604867779966944892629493124052634392864079653865573132330706778825939812912354729537860031295883077289515379611411216468,
83914726333050488057445446429899702112017758998192538814766414497622150110959384792622390687947794298555499532535923115212162858257763462740160712877680084704,
1)
o DJ(x, y, z) (86251250605139044576805674115645792619968110436877885989206741319340593283860597357538888651762801355476083610338859155582485835252264670818875500996459653219,
68345361515551321034543307410377723015401409127756952163160564325848402773971240632764423030232277331593066200120077167313076137313594015665371004838015704390,
1)
o CY(x, y, z)
(76682146483523509249866580376682208237400407383685521666104038989822121145497694558883061546487511083462137877150310117237393793848355159450507570028989619586,
97921042007987321402438452175358486739400776097824347812926396471971142149052695565680781734877753180828491584100834520481087713247297181815135133490004359165,
1)
o CYDash(x, y ,z) (5168892378496675357652095573705839315924907423944862739178841236021839315358413030170437064515529749253256357653173702320049832951981317616438362323539101333,
53299732686702909743099061087891592565039638258673963878300110745118988744691796460964381230111848966120828101391068678326282168429318526226772944139372350258,
1)
Such private keys for each attribute are sent to the receiver (Client node) by the PKG. Henceforth, the sending device (Generating Host) is able to encrypt the data using the formulated access policy and the public parameters given by the PKG. For example, in the considered illustration, if a plaintext message is ‘12345’, MQTT payload from the Generating Host contains the following:
In case of KP-ABE
• Data = :{ }. Here the Hashmap contains (@[])
• Here encrypted message = (list of attributes, E’ = m e(g1,g2)s ,
E’’ = gs, {Ei=T(i)s}), where m is message, e(g1,g2) is bilinear mapping, s is secret, function T(x) = g2(x)n g1h(x)

50664669065323130471370969249450783836775060042905588068395126608547366644778355772308683766597300211855262553377123023787100333083090977252407360097037797154:47817470032819817174310285705583480961508491950631270123966555332522050059673245623546603706395634398225711253032534470248173118396120265456826360041505130293: {Dr.A[21403529407598868599091416475528683957215573967510975404349957547984369080035720880465111714414120383757444842435582002582444127658586690161153447416702327710,86834154977639981025674100822106255028041826599973478786358202032385823298992451250693270369423602890630551331152099821072245008122337075956892136718115980276,1] @Dr.C[7568541424601164292957465127224367243705237841294852378009303205952506369243260869825762259120787241533295022763219865850167358044358865718454434988577091770,13620251352958356642125499094262073106363368542177014502582524085375396764105196449271724753050467175989207437398069962568471476766040807136267414869240410988,1] @Dr.B[21392307520430479279486958118412905609986299845212443336572975900497045413302832309876790485675597633416819355467227000711264461309574495213350063412432360562,4293201081936832547101816984477759974060069461626508412895351974849311112363949212151155661486699181912912328095959911839559847525322505552853937354386836,1] @Dr.E[7902583611895715927845418309764984858744365784821824271522981081786944819116546888748707550194971275911696843138664412453641268780020486233621896793832982661,34695138237509518878371095568339442114016959023222777458944087429887533224015132661044374637084859459223054859932942662212303172199898360995691554970186062435,1] @Dr.D[92442514572737524557817325911507437131103853315504587059724690251149809221844061109280216421391297683846530378800133106122518913696216237897332913092518799306,89810329506196516577137545365900383911656364130156282024625012364367075889282370983141882865486247716594144942724980889901252808945959813936477396107585017645,1]}
and
In case of CP-ABE Ciphertext = :< CDASH> :< CY> :< CYDASH>
where, C=hs, h and s are numbers of a field of size q,
CDASH = M e(g,g)αs here α, g and s are random numbers,
CY= g qy(0) where qy( ) is a polynomial and
CYDASH = H(att(y) qy(0) ) where H is a hash function
is
64726888495339223657937810776888807124397640293665156681960416723614450452231796849179073680542580390820011154173758140428549567904405523506072316037359190578OO23287457588325409812541028163349587814064658726922373647437204171029557924456687216486204592711802765964057818282924745243488291328310236245374370778265769423OO1:337998963819516503085048459498803878875426534832056752883585132309566410560699560257627780613986498985564999997308596029534650187683276391592807927595488231&34463687947892897551705668127292241060967422517905491449749555715749305364079293977443232040240463559695597081512447013966753310361036632909183273675021608088:22466280882847804768829032919120330905024542253228470758317533438252592203279529814890241206733887743277751361308687255267869914796949555639121096926669426968OO44758458684920978213759298313678686245571218477688412753469675778997768617363000376843601406910726071234668053808600598666595260431554765839539978520494238918OO1,109004186331544741638530779252077605883326998011208788616856250779292195025959690312633934999447934417920686682140388940012830087993994548891234304175760416923OO36587943892736493708348880319080581824257020487543269135200759310557719626391374568961239502848183297969543541768079422287284141049280470507041446348949740990OO1,89940847196305669920022316132534238855831579537735349341533664547155472326097832306668597911197551986493967034518260440700559305185824545225955310211200155117OO28364909541867611265940381691870448720496222925773623664471081028940183936026654052154849027405196453478025596575521435763575449913881152529987648093416487558OO1,94909244485739352933736966061490844019021190592443244939714664167827150989190001118973885361579383507915728578226018948378570240438228484673557135962994460943OO102705704469703503696734117460437368390428295791265467994852319774348174625717489901588426499284445075037812651355106936970288744184685568912008581856695904666OO1,76682146483523509249866580376682208237400407383685521666104038989822121145497694558883061546487511083462137877150310117237393793848355159450507570028989619586OO97921042007987321402438452175358486739400776097824347812926396471971142149052695565680781734877753180828491584100834520481087713247297181815135133490004359165OO1,:95113610041249583671445060835722948569147093787549219913248303109738068107824757285607065397366597487685017768145898556444509333132670934991474149751901224929OO49271223362507121457851292145252008476644514183755711676356627906702077680858651687841083893921733009669543598514329662346646835431324938346143448421867918056OO1,94855491596209744825377606927350371615997949743412188761858892828119297676740682257587714861462830526586580351086285344181127458180820580862060890978372732161OO89857158722051970694538778483691280467738707659910830481582311939907739137279805235448078099642123063710210095046350785645742773735123094853521303909592950200OO1,38395954485903101070934005875249321307001394643804986002457570828083798547614927361945446925425204181835719898604136197202101517655749995335534036873552791913OO1716231995328763951367621774592018582973888064194066341030009093248974199383038098706150936411899121431280065240894479599533871774483382526492779913616853418OO1,3408412474797221993465175946090922226782055396276867622106576841045447052525507623738366516456672840315263290951532346880983948667431300042579912230449986691OO43694625990451974154397768647823524954618155864841325614041729515274109178730730058250680476948647606883067358633933793239937680975569609522776710298662627231OO1,51688923784966753576520955737058393159249074239448627391478841236021839315358413030170437064515529749253256357653173702320049832951981317616438362323539101333OO53299732686702909743099061087891592565039638258673963878300110745118988744691796460964381230111848966120828101391068678326282168429318526226772944139372350258OO1
The receiver (Client node) decrypts this cipher text with the private key corresponding to the attributes mentioned in the access policy.
Whenever a Generating host wants to publish the data pertaining to a topic, it encrypts the data and publishes the encrypted data to the Broker along with the topic identifier. In one embodiment, the topic identifier is topic name related to the encrypted data. Here the topic identifier is not encrypted. Whenever the data pertaining to a particular topic is uploaded by the generating host, the broker forwards the encrypted data to all the client nodes that are subscribed to this topic by comparing the topic identifiers. Only the client nodes that satisfy the access policy can decrypt the data using their private keys. The encryption is done using ABE. The receiving devices/ client nodes decrypt the data using keys corresponding to attributes contained in the access policy.
Referring to the accompanying drawings, Figure 5 illustrates an interaction diagram of SMQTT protocol. It denotes the steps involved in transferring data securely between three parties: a Generating Host which sends the data, a Client node that receives the data and a Public Key Generator (PKG) which is the trusted third party. There are essentially four phases in this protocol. The registration and key management is done in a setup phase. Next phase is an encrypt phase wherein the data is encrypted and in a publish phase, the encrypted data and the topic identifier relevant to the data is sent to a Broker by the Generating Host. In a decrypt phase the data is decrypted by the receiving device (client node).
Referring to Figure 5, in setup phase, the Generating Host and the Client node registers with the PKG by mentioning a unique identity called Universal Resource Identifier (URI). The PKG generates a Master Secret key set and public parameters according to the CP/KP-ABE scheme. For CP-ABE scheme, all users who own the attributes receive the generated key set from the PKG. An access policy based on the access tree (similar to the access tree illustrated in Figure 4) is designed by the Generating Host. In case of KP-ABE scheme, the Generating Host sends the access tree to PKG and PKG generates key policy and generates the keys accordingly. This scheme is useful wherein the topics and group of client nodes who access the topics are known a priori and where a standard set of access policies are also determined. In such a case, and all the client nodes get their set of keys for all the required access policies a priori. In case of CP-ABE scheme, the Generating Host generates the access tree and access policy itself and encrypts payload data using a random number and public parameters set and also provides additional information along with the access policy to facilitate decryption. In case of KP-ABE, the Client node verifies if it satisfies the access policy. If it satisfies the access policy, it requests the PKG to issue corresponding key set. PKG then validates the request and sends the keys to the client node. For CP-ABE, a client node that satisfies the access policy can decrypt the cipher-text using its private keys set and information provided in the access policy thereby enabling non-interactive and offline requirement of PKG. For such a case, MQTT system works without any intervention of PKG. Once the setup and extraction phase is completed, the requirement of PKG no longer exists. Thus, CP-ABE scheme is more generic and suits the requirement of scalability for IoT, but the complexity of this scheme is high with respect to storage and computation than that of KP-ABE scheme. On completion of the setup phase, the Broker sends an acknowledgement packet to the Client node indicated by indicia ‘SUBACK’ as seen in Figure 5.
In the Encrypt Phase, the Generating Host encrypts the data using the public parameter and the random key and generates the cipher-text as given in the KP-ABE and CP-ABE schemes.
During the Publish Phase, as seen in Figure 5, the Generating Host sends encrypted data as payload to the Broker using a command indicated by indicia ‘SPublish’. A topic identifier related to the encrypted data is set accordingly by the Generating Host in the variable header. On receiving the encrypted data packets, the Broker responds by sending an acknowledgement packet indicated by indicia ‘PUBACK’ to the Generating Host. The Broker also sends/transmits the received encrypted data packets to all the Client nodes that have subscribed to topics whose topic identifiers match the topic identifier related to the encrypted data. The Generating Host on receiving the acknowledge message from the Broker, sends a packet indicated by indicia ‘PUBREL’ to the Broker. The Broker in turn replies the Generating Host by sending a packet indicated by indicia ‘PUBCOMP’ to the Generating Host. Similarly, the Client node sends an acknowledgement packet indicated by the indicia ‘PUBACK’ to the Broker on receiving the encrypted data packets and the Broker responds by sending a packet indicated by indicia ‘PUBREL’ to the Client node. Finally the Client node ends the communication by replying with a packet indicated by indicia ‘PUBCOMP’ to the Broker.
In the Decrypt Phase, the Client node decrypts the cipher text using the private keys of the set of attributes which satisfy the access policy thereby achieving secure data transfer.
Referring to the accompanying drawings, Figure 6 illustrates an architecture diagram of MQTT−SN. The MQTT−SN protocol is usually designed for Sensor Networks based on UDP to envisage communication for power constraint devices. As illustrated in Figure 6, the system comprises MQTT-SN clients which are Generating Hosts that send messages to a Gateway which in turn converts the MQTT-SN messages to MQTT messages and forwards them to a Broker. The Broker then delivers these messages to MQTT-SN clients (which are Client nodes from another Gateway). In such a scenario, the Gateway acts as a protocol converter that converts MQTT to MQTT-SN and vice versa.
Referring to the accompanying drawings, Figure 7 illustrates a typical message format of MQTT-SN protocol. It consists of two or four octets of Message Header and ‘n’ octets of Variable Header. Message Header contains Length and Message Type fields. MQTT-SN supports 256 message types. In this, message types (MsgType) ranging from 0X1E −0XFD, 0X19 and 0XFF are reserved for future use.
The present disclosure envisages a secure version of publish command for the MQTT-SN protocol SecureMQTT − SN, underneath the secure MQTT protocol with Spublish command 0X00.
Referring to the accompanying drawings, Figure 8 illustrates a Variable Message Header for Publish command of the MQTT-SN. Reserved messages with its MsgType field equal to 0X1E and 0X1F are utilized as CPPublish and KPPublish secure publish commands based on CP-ABE and KP-ABE schemes respectively. In accordance with the envisaged system, for the Secure MQTT-SN protocol, a Generating Host encrypts the message using the CP/KP-ABE scheme and sets the message type appropriately and sends it to a gateway. The gateway converts CP/KPPublish command to ‘Spublish’ command MQTT message and sends it to a Broker. The Broker forwards packet to all the gateways which are subscribed under a particular topic using the MQTT protocol. The Gateways then convert the ‘Spublish’ command to CP/KPPublish command and send it to the intended client nodes. Finally, the client nodes that satisfy the access policy are able to decrypt ciphertext successfully.
Typically, a smart city or infrastructure, demands deployment of large number of IoT devices over a large area and hence topology of the IoT is large. In such cases, if a cluster based topology is considered, it comprises devices that are grouped under different clusters with gateway as the cluster head. These gateways are then connected to a central broker. Here, the gateway acts as a broker (in order to envisage a Pub-Sub protocol) for the devices of the cluster it manages. For such cases, it is challenging to establish a secure communication for Pub-Sub scheme. To limit this, a secure Inter-Broker communication is envisaged. Referring to the accompanying drawings, Figure 9 illustrates an architecture diagram of an embodiment of internetworking of Brokers in MQTT−SN. In this architecture, a Generating Host belonging to one cluster is able to publish a message wherein Client nodes that are part of other clusters are allowed to subscribe. This Inter-Broker communication is achieved by configuring addresses (identifiers) of all the Brokers that are present in different clusters, in a source Broker. In this setup, Generating Host encrypts a message using public key governed by access policy. Local PKG enables cryptography primitives for its devices through Global PKG while the Global PKG does the key management. The Generating Host then sends encrypted messages to the Broker of the cluster to which it belongs. The Broker of that cluster then forwards the encrypted message to all the Client nodes in the same cluster as well as to the Brokers of other clusters. All the intended Client nodes decrypt messages using keys provided by the Global PKG over the cloud. Thus, in this technique security is realized in an end-to-end basis rather than hop-to-hop basis.
Referring to the accompanying drawings, Figure 10a, 10b and 10c illustrate graphs displaying experimental results of the SMQTT scheme for packet overhead, performance of ABE encryption and performance of ABE decryption respectively. In one embodiment of the experiment, during the Setup/Extraction phase, it is assumed that PKG distributes keys to Sender (Generating Host) and Receiver devices (Client nodes) in a secure manner. In this embodiment PKG and Broker are considered to be one entity. Broker can be connected to another Broker using a Bridge to envisage internetworking of the different Brokers thus realizing security on an end-to-end basis. In order to envisage a secured MQTT-SN, underlying SMQTT is required and therefore, performance analysis of proposed SMQTT is also applicable to secure MQTT-SN. In this embodiment of the experiment, performance of secure MQTT is compared in terms of the time taken to perform encryption, decryption, key generation and validation against various attributes with different key sizes (256, 512 bits) and also its effect on the MQTT payload.
Figure 10a of the accompanying drawings, illustrates graph describing the impact of SMQTT protocol using KP/CP ABE in terms of packet overhead and the number of attributes for a data of three bytes. It is observed that for both the schemes as the number of attributes increases the payload size of the packet also increases. But, size of the cipher text in CP-ABE is large when compared to KP-ABE. This is due to the additional information that needs to be provided in the policy to facilitate the decryption.
Performance of encryption and decryption using the system of the present claimed subject matter for KP/CP-ABE is depicted in Figure 10b and Figure 10c respectively, with key sizes (256, 512 bits) and varying number of attributes in the access policy. Encryption and decryption time for CP-ABE is more when compared to KP-ABE scheme, since additional information needs to be computed and provided in the access policy in case of CP-ABE. During decryption in case of CP-ABE, in one embodiment, more number of Tate pairing and complex multiplicative inverse operations need to be performed than in KP-ABE. Therefore, maximum time is spent in computing these operations.
Based on the performance analysis, it is observed that SMQTT based on KP-ABE scheme is suitable where the access policies are fixed and known a priori and requirement of interactive PKG is feasible. SMQTT based on CP-ABE scheme is suitable where the devices have more computing power and storage, and requires dynamic access policies. Further, SMQTT based CP-ABE scheme is more generic, dynamic and non-interactive (with respect to PKG) and enables less communication overhead.