PaperlayerView exact revision on arXiv

Source-linked AI summary

Adaptive Lightweight Security for Performance Efficiency in Critical Healthcare Monitoring

Ijaz Ahmad, Faheem Shahid, Ijaz Ahmad, Johirul Islam, Kazi Nymul Haque, Erkki Harjula

arXiv:2406.03786v2cs.CRcs.NI

TL;DR

MQTT’s lack of basic security functionality and TLS’s resource demands complicate secure healthcare IoT messaging under device and latency constraints. The paper evaluates MQTT encryption options for remote patient monitoring and reports ASCON performance advantages for smaller messages, with limits for larger ones.

  • Problem

    MQTT lacks basic security functionality, while TLS is resource intensive for constrained devices and healthcare IoT requires low-latency, confidential communication.

    Source: §I · p. 1, C. Security in MQTT · p. 2

  • Method

    The study implements an MQTT remote patient monitoring experiment and compares TLS, AES-128-GCM, and ASCON encryption schemes.

    Source: §I · p. 1, B. The Experimental Setup · p. 3

  • Results

    ASCON-128 is reported as performance-efficient for smaller messages, but may not always surpass conventional security mechanisms for larger messages.

    Source: §IV · p. 5, §V · p. 6

  • Takeaways & Limitations

    The real-time experiment on the 5G Test Network provides practical insight into security-performance trade-offs and an approach described as adaptable to varying IoT device resources.

    Source: B. The Experimental Setup · p. 3, §V · p. 6

Abstract

from arXiv · show

The healthcare infrastructure requires robust security procedures, technologies, and policies due to its critical nature. Since the Internet of Things (IoT) with its diverse technologies has become an integral component of future healthcare systems, its security requires a thorough analysis due to its inherent security limitations that arise from resource constraints. Existing communication technologies used for IoT connectivity, such as 5G, provide communications security with the underlying communication infrastructure to a certain level. However, the evolving healthcare paradigm requires adaptive security procedures and technologies that can adapt to the varying resource constraints of IoT devices. This need for adaptive security is particularly pronounced when considering components outside the security sandbox of 5G, such as IoT nodes and M2M connections, which introduce additional security challenges. This article brings forth the unique healthcare monitoring requirements and studies the existing encryption-based security approaches to provide the necessary security. Furthermore, this research introduces a novel approach to optimizing security and performance in IoT in healthcare, particularly in critical use cases such as remote patient monitoring. Finally, the results from the practical implementation demonstrate a marked improvement in the system performance.

I. INTRODUCTION

MQTT supports lightweight healthcare messaging, but its basic configuration lacks key protections and TLS can burden resource-constrained devices. The paper evaluates TLS overhead and compares AES-128-GCM with ASCON for remote patient monitoring.

I. INTRODUCTION

  • MQTT clients publish messages to broker topics or subscribe to receive updates, but MQTT lacks basic security-related functionality.Source: §I · p. 1
  • MQTT provides guaranteed delivery for digital healthcare, while the study emphasizes end-to-end security under IoMT latency and resource constraints.The paper considers lightweight ASCON, a NIST standard cipher, for this setting.Source: §I · p. 1
  • The article implements an MQTT remote patient monitoring setup, analyzes TLS overhead, and investigates AES-128-GCM and ASCON implementations for remote healthcare.Source: §I · pp. 1–2
  • The study reports performance enhancements with ASCON and examines its feasibility for timely, secure communication in remote healthcare.The stated scenario spans communication from the incident site to the hospital.Source: §I · pp. 1–2

II. BACKGROUND AND RELATED WORK

MQTT is a lightweight publish-subscribe protocol with delivery options that trade acknowledgment and retransmission behavior against latency. Its use in healthcare motivates QoS 1 and protection of client-to-client data exchange.

A. MQTT for IoTs

  • QoS 1 is presented as a latency-sensitive healthcare option, while QoS 0 lacks acknowledgment and QoS 2 is described as too slow for healthcare latency requirements.Source: A. MQTT for IoTs · p. 2

B. MQTT in healthcare

  • MQTT supports remote monitoring of vital information, and prior work recommends QoS 1 as a balance between minimal end-to-end latency and unpredictability,.Source: B. MQTT in healthcare · p. 2
  • For securing MQTT QoS 1 data exchange, the text proposes symmetric encryption between MQTT clients, as shown in Fig. 2.Source: B. MQTT in healthcare · p. 2

C. Security in MQTT

MQTT’s unencrypted default leaves broker-client health-data exchanges without confidentiality, while adding security can affect performance. The paper investigates ASCON-128 for remote patient monitoring in light of that trade-off.

C. Security in MQTT

  • MQTT’s default broker-client message exchange uses no encryption, despite confidentiality being a core IoMT requirement, and security and performance are inversely correlated,.Source: C. Security in MQTT · p. 2
  • Prior MQTT security work includes Fernet, Hummingbird-2, XXTEA, and practical ASCON assessment.Source: C. Security in MQTT · p. 2
  • The study explores ASCON-128 in MQTT for remote patient monitoring by investigating the trade-off between security and efficiency.Source: C. Security in MQTT · p. 2

A. Use-Case: Remote Patient Monitoring in Healthcare

The remote patient monitoring scenario follows continuous monitoring from an incident site through transfer to hospital, with a Raspberry Pi intermediary in the experimental design. The experiment compares encryption schemes in an MQTT setup over the University of Oulu 5G Test Network.

A. Use-Case: Remote Patient Monitoring in Healthcare

  • RPM monitoring begins at the incident site and continues during transfer to hospital; a Raspberry Pi serves as intermediary when resource-constrained devices cannot connect directly under SSL-based TLS.Source: A. Use-Case: Remote Patient Monitoring… · p. 3
  • Sensors collect vital signs at the incident site, and a Raspberry Pi edge device publishes the data to an MQTT broker for subscribers using shared keys or X.509 certificates.Source: A. Use-Case: Remote Patient Monitoring… · p. 3

B. The Experimental Setup

  • The real-time experiment compares ASCON, AES, and MQTT-native TLS for encrypted health data in the remote patient monitoring use case.The setup uses Python, Paho MQTT, and a Mosquitto broker.Source: B. The Experimental Setup · p. 3
  • A Raspberry Pi publishes patient information to a Jetson Xavier broker over a Quectel 5G modem connected to the University of Oulu 5G Test Network.Source: B. The Experimental Setup · p. 3

C. Test Cases

The test cases compare encryption options in an MQTT-based remote patient monitoring system, with software and hardware specifications provided in Tables I and II.

C. Test Cases

1) No Cipher:

The test cases contrast plaintext MQTT messages with AES-128-GCM and ASCON-128 encryption, examining conventional and lightweight cipher options.

1) No Cipher:

  • Plaintext MQTT messages provide the baseline for measuring encryption overhead in time and computational resources.This case sends messages without an encryption scheme.Source: 1) No Cipher · p. 4

2) AES-GCM-128:

  • AES-128-GCM encrypts MQTT messages with a 128-bit AES key, using CTR mode for encryption and Galois mode for authentication.Source: 2) AES-GCM-128 · p. 4

3) ASCON-128:

  • ASCON-128 uses a 128-bit key and is designed for efficiency in resource-constrained environments.The test case examines its performance trade-offs in MQTT.Source: 3) ASCON-128 · p. 4

4) SSL/TLSv1.2:

The TLSv1.2 case secures MQTT messages for comparison with other test cases. The evaluation measures round-trip time across message sizes and uses a performance-efficiency index to compare ASCON with other ciphers.

4) SSL/TLSv1.2:

  • TLSv1.2 secures MQTT messages as a comprehensive security-protocol comparison case.The paper notes its use in MQTT applications including Eclipse Mosquitto, EMQ, and Apache’s ActiveMQ.Source: 4) SSL/TLSv1.2 · p. 4

IV. RESULTS AND EVALUATION

  • The test vectors use repeated-X plaintext, 16-byte keys and IVs/nonces for AES and ASCON, and 16-byte associated data for ASCON.Source: §IV · p. 4
  • Round-trip time is timed from before encryption until decryption after receipt, with the Raspberry Pi serving as publisher and subscriber.The algorithm doubles message size and runs ten iterations for each size, covering encryption, transmission, and decryption.Source: §IV · p. 4
  • ASCON’s Performance Efficiency Index compares its mean round-trip time with the mean round-trip times of other ciphers.Mean round-trip times are plotted against message size for MQTT QoS 1, from 0 to 4096 bytes and 0 to 1000 milliseconds.Source: §IV · p. 5

1) Symmetric results on laptop and Raspberry Pi:

The laptop and Raspberry Pi results are described as closely symmetric, but ASCON’s round-trip time rises sharply at the largest message size.

1) Symmetric results on laptop and Raspberry Pi:

2) Baseline case (No cipher):

The unencrypted MQTT round-trip time serves as a baseline for comparing encryption schemes. In Fig. 7, it is not the shortest for messages below 4 KB, while round-trip time tends to normalize and improve above 4 KB.

2) Baseline case (No cipher):

  • The unencrypted MQTT round-trip time is the baseline for comparing the performance of encryption schemes.The passage says this case may not seem significant on its own, but provides a comparison point.Source: 2) Baseline case (No cipher) · p. 5
  • In Fig. 7, the baseline mean MQTT round-trip time without encryption is not the shortest for messages smaller than 4 KB, although it tends to normalize and improve above 4 KB.Source: 2) Baseline case (No cipher) · p. 5
  • As message size increases, round-trip time tends to normalize and improve for sizes greater than 4 KB.Source: 2) Baseline case (No cipher) · p. 5

3) ASCON is performance-efficient for smaller messages:

ASCON-128 performs especially well for smaller messages, but the paper cautions that lightweight ciphers do not always outperform conventional mechanisms as messages grow. It also compares AES-128-GCM and TLSv1.2 and relates the results to remote patient monitoring message sizes.

3) ASCON is performance-efficient for smaller messages:

  • At 8 bytes, ASCON is approximately 11x better than others and 8x more efficient than AES; at 1 KB, it is twice as efficient as others.The passage reports these comparisons for ASCON-128 in Fig. 5; the supplied Fig. 7 caption identifies laptop cipher performance.Source: 3) ASCON is performance-efficient for… · p. 5, Figure 7 · p. 6

4) Cipher efficiency and larger messages:

  • For messages exceeding 2 KB, ASCON starts to degrade on Raspberry Pi with MQTT, so cipher choice depends on message size.The paper notes that lightweight ciphers do not always surpass conventional or transient security mechanisms.Source: 4) Cipher efficiency and larger messages · p. 6

5) Performance of AES-128 and TLSv1.2:

  • AES-128 and TLSv1.2 have similar mean round-trip times; TLSv1.2 also requires X.509 certificate generation and distribution as client numbers grow.TLSv1.2 performs marginally better on a laptop, while AES-128-GCM performs better on the Raspberry Pi client.Source: 5) Performance of AES-128 and TLSv1.2 · p. 6
  • Because remote patient monitoring messages are generally under 2 KB, the paper identifies ASCON-128 as a more applicable choice for that use case.Source: 5) Performance of AES-128 and TLSv1.2 · p. 6

V. CONCLUSION AND FUTURE WORK

The conclusion presents ASCON-128 as efficient for smaller messages while cautioning that it may not outperform conventional mechanisms for larger ones. The authors report a real-time 5GTN experiment and propose further testing and adaptive-security research.

V. CONCLUSION AND FUTURE WORK

  • ASCON-128 is performance-efficient for smaller messages, but may not surpass conventional security mechanisms for larger messages.Source: §V · p. 6
  • The real-time experiment on the 5G Test Network provided practical insight into performance trade-offs and an adaptable solution for varying IoT resource constraints.The authors position this adaptability as suitable for healthcare IoT applications with highly variable device resources.Source: §V · p. 6
  • Future work will extend the research to a Proof of Concept environment and test it through a commercial 5G network.The authors anticipate that AI and machine learning integrated with 6G may advance real-time adaptivity and decision-making with minimal human intervention.Source: §V · p. 6

Related papers

Loading 2406.03786v2…