ICACT20220056 Slide.15
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
Finally, I conclude my presentation.
To resolve the end-to-end security problem of the MQTT protocol, we propose a new secure secret key-sharing system for resource-constrained IoT devices using MQTT.
The proposed system is particularly suitable for resource-constrained IoT devices as it uses a lightweight and less resource-intensive secret-sharing scheme.
For future work, we will improve the delay performance by optimizing the system parameters (k, n, and NB).
Thank you very much for your kind attention.
|
|
ICACT20220056 Slide.14
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
This slides shows the key-sharing delay performances of the proposed system and the public key-based system in the two scenarios.
The minimum, median, maximum, and standard deviation (SD) of the key sharing delay over a total of 30 measurements are tabulated in this table.
The delay-increasing-ratio (B/A) is calculated by dividing the key-sharing delay of the public key-based system (B) by that of the proposed system (A), which represents the delay performance ratio between the public key-based system and the proposed system.
The key-sharing delay of the proposed system is observed to be significantly lower than that of the public key-based system in both Raspberry Pi 3 model B+ and Raspberry Pi Zero WH scenarios.
The median of the key-sharing delay of the public key-based system is observed to be approximately 13.5–14.8 times higher than that of the proposed system.
The longer delay of the public key-based system is attributed to the heavy computational load of prime number generation.
The delay performance of the proposed system is verified to be stable with a small variation.
The standard deviations in the Raspberry Pi 3 model B+ and Raspberry Pi Zero WH scenarios are observed to be 0.00658 and 0.01085, respectively.
On the other hand, the variation of the delay performance of the public key-based system is significantly larger than that of the other.
The standard deviations in the Raspberry Pi 3 model B+ and Raspberry Pi Zero WH scenarios are 0.68271 and 1.54697, respectively.
In the scenario using the Raspberry Pi Zero WH board with lower CPU performance and smaller memory size, the variation of the key-sharing delay becomes much larger.
|
|
ICACT20220056 Slide.13
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
This figure depicts the key-sharing delay performances in the two scenarios.
Besides the encoding delay and the reconstruction delay, key-sharing delay also includes the communication delay between the publisher and the brokers.
As the number of brokers is increased, the key sharing delay also increases.
The primary reason behind this is the corresponding increase in the computational load of publishing n shares corresponding to n topics.
Publishing corresponding to topics requires the connecting, transmitting, and closing operations corresponding to each broker.
Thus, the required number of such operations increase in proportion to the number of brokers.
The key sharing delay of the Raspberry Pi Zero WH board is observed to be greater than that of Raspberry Pi 3 model B+ board due to the lower CPU performance and smaller memory size of the former.
|
|
ICACT20220056 Slide.12
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In the (k, n)-threshold scheme, it is reasonable to assume that both the encoding delay and the reconstruction delay increase when either n is constant, and k is increased, or k is constant and n is increased. Therefore, k and n are assumed to increase from (k, n) = (10,10) to (k, n) = (100,100) with k=n.
A 128-bit RSA secret key is used in this experiment.
The figure on the left depicts the encoding delay performances in the two scenarios.
As (k, n) is increased, the encoding delay is observed to increase exponentially.
Compared to that of the Raspberry Pi 3 model B+ board, the rate of increase of the encoding delay of the Raspberry Pi Zero WH board is significantly higher due to its lower CPU performance and smaller memory size.
The figure on the right depicts the reconstruction delay performances in the two scenarios.
As in the case of encoding delay, the reconstruction delay is observed to increase exponentially as (k, n) is increased.
From these figures, it is evident that the rate of increase of the encoding delay is much higher than that of the reconstruction delay.
Therefore, determination of the values of (k ,n) based on the encoding delay is essential.
|
|
ICACT20220056 Slide.11
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
In this experiment, the (k, n)-threshold scheme corresponding to (3, 5) is used in the proposed system.
The RSA algorithm is used to generate the secret key, whose key lengths are taken to be 128, 192, and 256 bits.
The figure on the left presents the encoding delay performances in the two scenarios.
The error bars in the figure capture the standard deviation corresponding to the 30 measurements.
As is evident from the figure, the encoding delay remains almost constant even when the key length is varied.
In the proposed system, the length of the secret key, S, does not affect the encoding delay significantly.
The encoding delay and the delay variance of the Raspberry Pi Zero WH board is observed to be greater than those of the Raspberry Pi 3 model B+ board owing to the lower CPU performance and smaller memory size of the former.
The figure on the right depicts the reconstruction delay performances in the two scenarios.
As in the case of encoding delay, the reconstruction delay of the Raspberry Pi 3 model B+ board is also observed to remain almost constant even when the key length is varied.
As the key length is increased, the reconstruction delay of the Raspberry Pi Zero WH board is observed to increase slightly.
The reconstruction delay and delay variance of the Raspberry Pi Zero WH board is greater than those of the Raspberry Pi 3 model B+ board.
|
|
ICACT20220056 Slide.10
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
This slide shows three quantitative metrics are used to measure system performance.
Encoding delay of secret sharing is the time taken by the publisher to encode the secret key into n shares.
That is the time taken to execute (A2) in the figure on the right.
Reconstruction delay of secret sharing is the time taken by the brokers to reconstruct the secret key from k shares.
That is the time taken to execute (A5).
Neither the encoding delay nor the reconstruction delay includes communication delays between the publisher and the brokers.
Further, these delays are purely dependent on computational resources, such as CPU and memory.
Key sharing delay is the time taken to share the secret key between the publisher and the subscribers.
This delay includes the communication delay between the publisher and the brokers.
In the case of the proposed system, this is equal to the duration between the encoding of the secret key into n shares by the publisher and the reconstruction of the secret key by the subscribers.
That is the time taken to execute steps (A2)-(A5).
In the case of the public key-based system, this is equal to the duration between encoding the prime numbers by the publisher and the decryption of the secret key by the subscribers.
That is the time taken to execute steps (B2)- (B6).
The network latency (B5) is assumed to be zero for the public key-based system.
Please note that this is an ideal environment for the public key-based system.
|
|
ICACT20220056 Slide.09
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
We evaluate the performance of our proposed system by conducting two experiments: with Raspberry Pi 3 Model B+ boards and Raspberry Pi Zero WH boards.
This slide shows the Emulated IoT Environment and technical specifications we’ve used.
As a target system for comparison, we use a simple public key-based system.
In a public key-based system, the publisher generates both a public key and a private key using the RSA algorithm.
This key generation process involves heavy computational requirements for prime number generation.
We use a simple public key-based system as a target system for comparison.
The publisher generates both a public key and a private key using the RSA algorithm in a public key-based system.
This key generation process involves heavy computational requirements for prime number generation.
For evaluation, a small and emulated IoT environment comprising a Raspberry Pi 3 Model B+ and Raspberry Pi Zero WH boards are constructed.
As is evident from the figure, one Raspberry Pi 3 Model B+ board or one Raspberry Pi Zero WH board is used as both the publisher and the subscriber.
Multiple Raspberry Pi 3 Model B+ boards are used as brokers.
They communicate with each other using the MQTT protocol. An open-source Mosquito-based MQTT broker is used.
The specifications of the publisher, brokers, and subscribers used in our experiments are shown in this table.
|
|
ICACT20220056 Slide.08
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
This slide shows the operations of a publisher and subscriber in the secure data delivery phase.
The publisher encrypts its data using the secret key shared during the key sharing phase and transmits the encrypted data to the broker corresponding to a specific topic.
Subscribers interested in this topic subscribe to it and receive the encrypted data from the broker.
The subscribers then decrypt the data received using the secret key.
If a subscriber is subscribed to a particular topic, the broker automatically transmits any new data on that topic to the subscriber.
|
|
ICACT20220056 Slide.07
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
This slide shows the operations of a publisher and subscriber in the key-sharing phase.
A publisher generates a secret key, S, for secure encrypted communication between itself and the subscribers.
This secret key is shared using the MQTT protocol.
The publisher encodes S into n shares by using the (k, n)-threshold secret-sharing scheme and publishes them corresponding to n topics on multiple brokers.
The publisher periodically updates the key to enhance security.
Subscribers interested in the data generated by the publisher
specifically subscribe to at least k topics corresponding to k
shares. They receive k shares on k topics from the brokers
and reconstruct S based on these k shares.
Please note that the maximum number of shares held by each broker must be less than or equal to k − 1 to prevent the reconstruction of the secret key by a malicious third party.
|
|
ICACT20220056 Slide.06
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
This slide shows the overview of our proposed secure secret key-sharing system.
Public key cryptosystems such as TLS/SSL are not suitable for IoT environments because of the heavy computational requirements of prime number generation.
Therefore, our proposed system uses a secret key cryptosystem for data encryption instead of an expensive public-key cryptosystem.
A secret key cryptosystem is lightweight cryptography with a low processing time variation.
Our proposed system uses a threshold secret-sharing scheme to share the secret key among a publisher and subscribers.
This secret-sharing scheme prevents an attacker from obtaining the secret key.
|
|
ICACT20220056 Slide.05
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
SSL/TLS solution is not suited to a resource-constrained IoT environment.
Therefore, a new resource-constrained IoT-friendly security solution is required.
An IoT-friendly security solution should have a low computational overhead.
It does not require significant memory usage and high processing capability.
It also should have a low communication overhead.
It should reduce the communication overhead associated with asymmetric (public key) encryption techniques.
This is why we propose a new lightweight security solution for resource-constrained IoT devices using the MQTT protocol.
|
|
ICACT20220056 Slide.04
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
This slide describes the MQTT security issues.
However, the MQTT protocol is not equipped with sufficient security mechanisms by default—it does not adopt any encryption mechanisms to protect the data being transmitted.
Instead, the MQTT protocols strongly recommend the use of secure socket layer/transport layer security (SSL/TLS) for encryption.
The SSL/TLS protocols provide a secure communication channel between pairs of hosts.
Although the use of SSL/TLS is recommended, most MQTT-based IoT systems do not use the SSL/TLS.
This is because that the SSL/TLS protocols entail a significant amount of additional communication and
computational overhead that cannot be supported by resource constrained IoT devices.
|
|
ICACT20220056 Slide.03
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
This slide shows an overview of the MQTT protocol.
The MQTT (Message Queue Telemetry Transport) protocol has gained significant attention as a communication
protocol for a variety of IoT applications.
The MQTT protocol is one of the most widely used protocols for IoT applications because it uses less bandwidth to send messages than other protocols.
The MQTT protocol is a lightweight application-layer messaging and bi-directional protocol based on the publish/subscribe (pub/sub) model.
The protocol header is a minimum of 2 bytes, reducing communication time and power consumption and making it suitable for resource-constrained IoT devices.
A publisher is a device such as sensors that sends messages to the broker. A subscriber (for example, applications interested in certain topics or sensory data) specifically subscribes to the topic on which the publisher publishes a message. A broker is an intermediary device (for example, a central server) that collects the message from the publisher and supplies it to the subscriber. The MQTT protocol allows bidirectional communication between a publisher and subscribers via a broker. This helps in data sharing and managing and controlling the participating devices.
|
|
ICACT20220056 Slide.02
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
The outline of my presentation is as follows.
First of all, I’d like to talk about the introduction and technical background of the present work.
Then, I’d like to explain our new Secure Secret Key-Sharing System for Resource-Constrained IoT Devices using MQTT and present experimental evaluations.
Finally, I’d like to conclude my presentation by summarizing my results.
|
|
ICACT20220056 Slide.01
[Big slide for presentation]
|
Chrome Text-to-Speach Click!! |
 |
My name is Taku Noguchi. I am from Ritsumeikan university.
Today, I’m going to talk about our new Secure Secret Key-Sharing System for Resource-Constrained IoT Devices using MQTT.
|
