PaperlayerView exact revision on arXiv

Source-linked AI summary

Recent Advances in the Internet of Medical Things (IoMT) Systems Security

Ali Ghubaish, Tara Salman, Maede Zolanvari, Devrim Unal, Abdulla Al-Ali, Raj Jain

arXiv:2302.04439v1cs.CR

TL;DR

IoMT systems face security challenges across data collection, transmission, and storage, while individual techniques do not address most known attacks. This paper reviews security techniques and attacks, then proposes a combined framework that covers IoMT security requirements and 14 attacks.

  • Problem

    Individual security techniques do not provide comprehensive protection against most known IoMT attacks, despite the need to protect healthcare data across collection, transmission, and storage.

    Source: §I · pp. 1–2

  • Method

    The paper reviews IoMT security requirements, techniques, and attacks, then proposes a framework combining techniques across data collection, transmission, and storage.

    Source: §I · p. 2

  • Results

    The proposed framework is described as fulfilling IoMT security requirements and protecting against the 14 attacks discussed in the paper.

    Source: §VIII · p. 8

  • Takeaways & Limitations

    The authors conclude that combining security techniques is needed to meet IoMT requirements and mitigate most attacks.

    Source: §IX · p. 10

    The framework still needs a remotely secure initial setup and an alternative access method for lost-factor or emergency situations.

    Source: §IX · p. 10

Abstract

from arXiv · show

The rapid evolutions in micro-computing, mini-hardware manufacturing, and machine to machine (M2M) communications have enabled novel Internet of Things (IoT) solutions to reshape many networking applications. Healthcare systems are among these applications that have been revolutionized with IoT, introducing an IoT branch known as the Internet of Medical Things (IoMT) systems. IoMT systems allow remote monitoring of patients with chronic diseases. Thus, it can provide timely patients' diagnostic that can save their life in case of emergencies. However, security in these critical systems is a major challenge facing their wide utilization. In this paper, we present state-of-the-art techniques to secure IoMT systems' data during collection, transmission, and storage. We comprehensively overview IoMT systems' potential attacks, including physical and network attacks. Our findings reveal that most security techniques do not consider various types of attacks. Hence, we propose a security framework that combines several security techniques. The framework covers IoMT security requirements and can mitigate most of its known attacks.

I. INTRODUCTION

The paper reviews IoMT security requirements, techniques, and attacks, arguing that no single technique addresses most known attacks, and proposes a framework spanning data collection, transmission, and storage.

I. INTRODUCTION

  • IoMT security is a major challenge because healthcare data must be protected during collection, transmission, and storage, and IoMT systems can affect patients’ lives and raise privacy concerns.Nearly half of IoMT devices were vulnerable to exploits, according to the 2020 CyberMDX report. Healthcare data’s average cost was 50 times more than that of credit card information.Source: §I · p. 1
  • IoMT systems have 11 security requirements summarized as CIANA, but traditional solutions may not provide adequate guarantees given their power consumption and other system requirements.The paper groups IoMT security techniques into symmetric cryptography, asymmetric cryptography, and keyless non-cryptographic techniques.Source: §I · p. 1
  • Prior reviews classify IoMT and WBAN security techniques and countermeasures, discuss network issues such as emergency handling, and examine cloud security for wearable devices.Source: §I · p. 1
  • Machine learning, artificial intelligence, and blockchain are among techniques considered for IoMT security; machine learning reduced physical-layer authentication error by 64% versus traditional methods.Source: §I · pp. 1–2
  • The review covers IoMT security requirements and techniques, assesses resilience against attacks, and proposes a framework that accounts for device constraints across data collection, transmission, and storage.The authors argue that no single technique can provide comprehensive security against most known attacks targeting IoMT systems.Source: §I · p. 2

II. BACKGROUND · A. IoMT Types · B. IoMT Systems Architecture

The background introduces implantable and wearable IoMT devices and explains how a four-layer architecture moves biometric data from collection to clinical review and action.

II. BACKGROUND

  • This background establishes the IoMT system context needed to understand the paper’s later discussion of security requirements, attacks, and countermeasures.Source: §II · p. 2

A. IoMT Types

  • IoMT devices divide into implantable medical devices (IMDs) that provide necessary assistance and wearable devices (IoWDs) that mainly improve healthcare monitoring.Examples include pacemakers for heart conditions and smartwatches for monitoring biometrics.Source: A. IoMT Types · p. 2
  • Because IMDs are mostly very small and must stay inside the body for a long time, low power consumption, small storage space, and long-lasting small batteries are essential.Pacemaker implants tend to last 5 to 15 years. Wireless IMDs have been proposed to address problems associated with wired IMDs, such as infection and cable breakage.Source: A. IoMT Types · p. 2
  • IoWDs monitor biometrics using devices such as smartwatches and ECG monitors, but sensor-accuracy and battery-life limits make them unlikely to replace IMDs in critical conditions,.Smartwatches can monitor heart rate and movement, detect falls, and take ECG readings; they are widely used for non-critical patient monitoring.Source: A. IoMT Types · p. 2

B. IoMT Systems Architecture

  • IoMT systems use four layers to carry biometric data from collection through storage and analysis to visualization and physician-guided action.Patients can also view their health status through the cloud.Source: B. IoMT Systems Architecture · pp. 2–3, Figure 2 · p. 3
  • Sensors collect patient biometrics and transmit them wirelessly to gateways, which can validate data, store it briefly, perform simple AI-based analysis, and forward it to the cloud.Sensors may use Wi-Fi, Bluetooth, or the MedRadio spectrum reserved for IMDs; gateways include smartphones and dedicated access points.Source: B. IoMT Systems Architecture · pp. 2–3
  • The cloud stores and analyzes gateway data, supports secure access and remote sensor management, and uses a key generation server to generate node IDs and keys.The visualization/action layer presents health information to physicians and patients and supports recommended care, such as prescribing or adjusting medication doses.Source: B. IoMT Systems Architecture · p. 3

III. IOMT SECURITY MODEL · A. IoMT Threats at Different Stages · B. IoMT Security Requirements

The paper organizes IoMT security around protecting patient data during collection, transmission, and storage, then sets out system-wide security requirements and countermeasure categories. These categories are detailed in subsequent sections.

III. IOMT SECURITY MODEL

  • The security model covers three data stages, presents system requirements, and categorizes countermeasures for detailed treatment in later sections.Source: §III · p. 3

A. IoMT Threats at Different Stages

  • Collection-stage software tampering and sensor hardware manipulation can threaten patients’ lives, making protection of sensor data vital to system operation.Collection occurs in the sensor layer.Source: A. IoMT Threats at Different Stages · p. 3
  • During transit across the four architecture layers, attacks can manipulate or block sensor data, so protection must prevent alteration during transfer.The passage gives sensor-to-access-point communication as an example.Source: A. IoMT Threats at Different Stages · p. 3
  • Stored data face credential theft, DoS, and DDoS attacks; unauthorized access to the cloud and visualization layers is a particular concern because data rest there most of the time.Source: A. IoMT Threats at Different Stages · p. 3

B. IoMT Security Requirements

  • Derived from CIANA considerations, the 11 requirements include confidentiality/privacy, integrity, availability, non-repudiation, and authentication.Examples include encryption and access control for privacy, digital signatures for non-repudiation, and mutual authentication before secure data or key exchange.Source: B. IoMT Security Requirements · p. 3
  • Authorization limits authenticated users to permitted commands, while anonymity hides patient and physician identities from unauthorized users [24, 25].The passage identifies encryption and access controls for authorization, and smart cards for anonymity.Source: B. IoMT Security Requirements · pp. 3–4
  • The remaining requirements are forward/backward secrecy, secure key exchange, key-escrow resilience, and session key agreement [24, 25].The passage gives time-based keys, Diffie-Hellman, asymmetric keys with a cryptographic hash function, and symmetric/asymmetric keys with a hash function as example mechanisms, respectively.Source: B. IoMT Security Requirements · p. 4

C. IoMT Systems Security Techniques … B. Wireless Signal Characteristics

The paper organizes IoMT security techniques into cryptographic and non-cryptographic approaches, then describes symmetric-key uses and a wireless-signal method for generating shared keys without prior connections.

C. IoMT Systems Security Techniques

  • IoMT security techniques are symmetric, asymmetric, or keyless; cryptographic methods include one-factor authentication, while two-factor authentication adds a second factor such as biometrics.Keyless techniques are non-cryptographic.Source: C. IoMT Systems Security Techniques · p. 4

IV. SYMMETRIC-KEY ALGORITHMS

  • Symmetric cryptography uses a secret key shared by communicating nodes, which must be generated and distributed before use or during a prior communication stage.Source: §IV · p. 4
  • In IoMT systems, symmetric algorithms can enable hierarchical patient-data access, secure connections without prior setup, and first-factor authentication paired with techniques such as facial recognition.Source: §IV · p. 4

A. Hierarchical Access

  • A hierarchical role-based model encrypts patient data and decrypts only the portions authorized for each user's role, such as nurses administering medicines and doctors prescribing them.Source: A. Hierarchical Access · p. 4
  • Belkhouja et al. use the Chinese remainder theorem to support hierarchical access: higher-privilege users can access any patient's data, while lower-privilege users access role-related portions.Source: A. Hierarchical Access · p. 4

B. Wireless Signal Characteristics

  • RSS variation inside versus outside the body supports shared-key generation between a headless cardiac pacemaker and a subcutaneous implant without prior key knowledge.At an average heart rate of 64 bpm, the technique extracts two bits per cardiac cycle and generates a 128-bit key in 60 seconds.Source: B. Wireless Signal Characteristics · p. 4

C. CHF with XOR … V. ASYMMETRIC-KEY ALGORITHMS

The sections describe cryptographic and behavioral methods for IoMT key generation, authentication, and communication security. They also explain asymmetric cryptography and its use with hashes, homomorphic encryption, signatures, and second-factor authentication.

C. CHF with XOR

  • CHF and XOR combine sensor IDs and shared keys into hashed initialization parameters for nodes to generate keys, but administrators must manually provision them.The combination with symmetric keys supports authenticated key-agreement protocols and unique node identification, as illustrated by Alzahrani et al. and Xu et al..Source: C. CHF with XOR · pp. 4–5

D. Gait-Based Technique

  • An ANN-based gait system generates a 128-bit key in 10 gait-cycles at 13 b/gait-cycle, and its authors claim three times more bits per gait cycle than similar techniques.It uses body-mounted IoMT sensors and generates keys for securing communication with the access point or mobile gateway without direct user interaction.Source: D. Gait-Based Technique · p. 5

E. Facial Recognition

  • Facial recognition can act as a second factor after shared-key authentication, continuously enforcing role-based access between users and the medical controller.It can prevent lower-privileged staff from accessing patient data when a higher-privileged user has authenticated but not logged out.Source: E. Facial Recognition · p. 5

F. Pattern-Based Technique

  • After first-factor authentication, a controller can send a random tab pattern as a second factor before a sensitive command, or keep an IMD sensor off until the pattern is performed.Source: F. Pattern-Based Technique · p. 5

V. ASYMMETRIC-KEY ALGORITHMS

  • Asymmetric cryptography uses public/private keys for encryption/validation and decryption/signature; in IoMT, ECC is the most common technique for its lightweight characteristics, with a 160-bit ECC key as good as 1024-bit RSA and 15 times faster.In IoMT, asymmetric keys can integrate with CHF, homographic encryption (HE), or digital signatures, and can act as a first factor with smart cards as a second.Source: §V · p. 5
  • A 160-bit ECC key is as good as a 1024-bit RSA key and is 15 times faster, and ECC is commonly used for IoMT security.Source: §V · p. 5

A. CHF with ECC · B. Homomorphic Encryption (HE)

The sections describe CHF with ECC for secure IoMT key sharing and data exchange, and homomorphic encryption for confidential cloud-side computation with patient-controlled access. They also report energy and computation-related benefits for these approaches.

A. CHF with ECC

  • CHF combines ECC keys and hashed KGS public-key parameters to let IoMT nodes generate asymmetric keys, providing a secure certificateless channel without symmetric secret-key sharing.Source: A. CHF with ECC · p. 5
  • CHF with ECC and CHF consumes around 30% less average energy than similar techniques.Source: A. CHF with ECC · p. 5
  • Dividing patient data into subsets and converting them with ECC keys and CHF enables secure sharing among system entities while overcoming cloud certificate-management overhead.Source: A. CHF with ECC · p. 5

B. Homomorphic Encryption (HE)

  • HE stores patient data as ciphertext in the cloud for limited operations such as integrity checks, while access is restricted to patients except during emergencies.Source: B. Homomorphic Encryption (HE) · pp. 5–6
  • PHE permits one operation an unlimited number of times, SHE permits a limited number of operations, and FHE permits unlimited operations for confidential aggregation; AdaptableSDA consumes only 10% more power with privacy than without it.The paper identifies FHE as suitable for hospital monitoring.Source: B. Homomorphic Encryption (HE) · pp. 5–6
  • OHE uses SFFO to select the key with maximum breaking time, reducing computation time and increasing breaking time by 2% to 8% versus other HE and non-HE techniques, respectively.OHE is a modification of FHE.Source: B. Homomorphic Encryption (HE) · p. 6

C. Digital Signatures … A. Biometrics

The merged sections describe authentication options for IoMT, from key-based signatures and smart cards to keyless approaches such as biometrics. They outline how these methods work and, for fingerprint biometrics, report lower transmission and computational overhead than ECG-based techniques and stronger performance for Delaunay features.

C. Digital Signatures

  • Digital signatures verify data or command authenticity with the sender’s private and public keys, and can use a firmware shim to validate wireless communications,.The sensor firmware must store authorized medical staff’s public keys.Source: C. Digital Signatures · p. 6

D. Smart Cards

  • Smart cards add a physical-key second factor to ECC-key authentication, helping resist cyber-breaks if one factor is stolen or lost.Medical staff enter a key before using their smart cards to access the system.Source: D. Smart Cards · p. 6

VI. KEYLESS ALGORITHMS

  • Keyless algorithms provide security without pre-shared keys and include biometrics, token-based and proxy-based techniques, blockchain, and AI.Source: §VI · p. 6

A. Biometrics

  • Biometrics are commonly used in IoMT because they are easy to use, letting medical staff or patients access records through fingerprint or ECG-based sensors.Fingerprint sensors read fingerprint images; ECG-based sensors record heartbeat activity to encrypt data.Source: A. Biometrics · p. 6
  • Fingerprint sensors reduce message size during transmission and computational overhead compared with ECG-based techniques.Source: A. Biometrics · p. 6
  • Delaunay Triangulation-based feature representation performs better and is less complicated than the other listed fingerprint algorithms, according to Zheng et al..The other listed algorithms are Pair-polar coordinate-based and Minutia Cylinder-Code-based feature representation.Source: A. Biometrics · p. 6
  • Fingerprint biometrics have a longer history and greater credibility than face recognition-based systems.Source: A. Biometrics · p. 6

B. Token-Based Security … A. Physical Attacks

These sections describe token-, proxy/light-, blockchain-, and AI-based protections, then map IoMT risks and physical attacks to violated security requirements and possible mitigations.

B. Token-Based Security

  • Physical tokens such as browser x-auth-token fields and RFID support authentication for cloud-node connections and secure hospital sensor logistics.The cited examples use software tokens for cloud-to-node connections and RFID as a hardware token for sensor logistics in a hospital information system.Source: B. Token-Based Security · p. 6

C. Proxy-Based and Light-Based Systems

  • Proxy middleware enables full-duplex secure communication between sensors and devices, while Li-Fi avoids hospital-network interference and offers short-range monitoring security.Proxy middleware may use microprocessors embedded in a patient’s jacket or belt; Li-Fi provides a substantial free operating frequency.Source: C. Proxy-Based and Light-Based Systems · p. 6

D. Blockchain Technology and AI

  • Blockchain can share patient data with doctors and insurers, while AI detects anomalous network flows and patient data; both are adopted mainly in the cloud layer.Public blockchains may incur latency, storage, and communication overhead, so private blockchains may suit real-time systems; AI’s data needs may make rare attacks difficult to detect.Source: D. Blockchain Technology and AI · pp. 6–7

VII. IOMT SYSTEMS RISKS AND LIST OF ATTACKS

  • 11 of 14 listed attacks have keyless countermeasures, and more than half of countermeasures use two-factor authentication, favored for implementation and management simplicity.The paper summarizes IoMT security requirements, attacks, and countermeasures in Table I.Source: §VII · p. 7

A. Physical Attacks

  • Physical attacks require access to an IoMT component and can target patient data or security keys through token theft, impersonation, or tampering.Smart-card theft can be mitigated by combining ECC with the card, since the stolen card alone is insufficient to hijack the system; impersonation can be addressed with symmetric/asymmetric techniques or biometrics. Tampering across collection, transit, or storage can be mitigated with symmetric keys and facial recognition or keyless methods.Source: A. Physical Attacks · p. 7
  • Side-channel attacks leak cryptographic-operation information during device communications, while RF jamming and desynchronization threaten availability and can deplete sensor batteries.Keyless cryptography and DTLS are suggested against side channels; blockchain and AI can detect or mitigate them, and can reduce jamming effects by finding alternative routes or terminating the attacker’s channel.Source: A. Physical Attacks · p. 7

B. Network Attacks

Network attacks target communication between IoMT layers to steal or fabricate patient data or block connections. They threaten availability, confidentiality, authorization, authentication, and secure key exchange.

B. Network Attacks

  • Attacks on inter-layer communication may steal or fabricate patient data or block connections between IoMT system layers.Bluetooth and Internet links are examples of the communication paths targeted.Source: B. Network Attacks · p. 7
  • DoS/DDoS attacks can overwhelm IoMT communication links, fragment networks, and make cloud services unavailable to patients and medical staff.Fragmentation is described as a special type of DDoS; blockchain and AI may reduce impacts by finding alternative routes or terminating attacker connections.Source: B. Network Attacks · pp. 7–8
  • Sniffing exposes transmitted patient data, while MITM attacks can alter it; relay and replay attacks forward or resend intercepted data without alteration.Sethuraman et al. describe a UAV-based drone-in-the-middle attack; encryption or two-factor authentication can mitigate MITM, asymmetric keys can mitigate relay, and timestamps can mitigate replay.Source: B. Network Attacks · p. 8
  • Clock-synchronization attacks can hide relay, replay, and MITM activity, while parallel-session, brute-force, and stepping-stone attacks violate authentication or authorization.Two-factor techniques such as ECC with smart cards address clock synchronization and parallel sessions; biometrics can mitigate brute force, and AI can help avoid stepping-stone attacks.Source: B. Network Attacks · p. 8

VIII. PROPOSED SECURITY FRAMEWORK FOR IOMT · A. Securing Data Collection

The authors propose a three-part framework intended to meet IoMT security requirements and protect against 14 attacks. For data collection, it combines authentication with sensor monitoring and alerts, while noting setup and second-factor availability limitations.

VIII. PROPOSED SECURITY FRAMEWORK FOR IOMT

  • The proposed three-part framework is designed to fulfill IoMT security requirements and protect systems from 14 attacks.The framework follows the IoMT security model stages.Source: §VIII · p. 8, Figure 6 · p. 9

A. Securing Data Collection

  • Collection security combines ECC first-factor authentication with biometric patient authentication as a second factor.The two factors provide protection if one is compromised; biometrics are described as convenient for everyday use and emergencies.Source: A. Securing Data Collection · p. 8
  • Role-based hierarchical access with ECC secures sharing with medical staff, while proxy techniques can protect existing unsecured sensors.The hierarchical access technique requires a key-generation server (KGS) in the cloud layer.Source: A. Securing Data Collection · p. 8
  • For hardware attacks, a gateway access point should alert the patient and physician if it cannot connect to an IoMT sensor for a specified period, such as one hour.This alert is intended to reduce or eliminate the effects of the attack.Source: A. Securing Data Collection · p. 9
  • Gateway-layer edge computing can analyze sensor-reading changes for confidentiality and integrity violations, warn the patient, and alert the physician if the patient does not respond.The proposed AI model provides initial analysis of the readings.Source: A. Securing Data Collection · p. 9
  • The collection-stage techniques provide confidentiality, integrity, authentication, authorization, anonymity, forward/backward secrecy, key-escrow resilience, and session-key agreement against listed attacks.The listed threats include physical-security-token, impersonation, tampering, side-channel, sniffing, MITM, relay, replay, clock-synchronization, parallel-session, and brute-force attacks.Source: A. Securing Data Collection · p. 9
  • The collection techniques assume pre-shared keys or initial parameters, requiring manual KGS setup and risking unusability if the second factor is lost or inaccessible during an emergency.The manual setup prepares the KGS for hierarchical access.Source: A. Securing Data Collection · p. 9

B. Securing Data in Transit · C. Securing Data in Storage

The section recommends layered communication security and certificateless authentication for IoMT data in transit, alongside cloud-based attack detection, logging, and backup routing. It also notes that initial manual setup and sufficient meaningful data remain important considerations.

B. Securing Data in Transit

  • CoAP is recommended between sensor and gateway layers, with HTTPS or TLS 1.3 connecting the remaining layers.The layered protocol arrangement is illustrated in Fig. 7.Source: B. Securing Data in Transit · p. 9
  • Certificateless cryptography can reduce cloud-layer certificate-management overhead, while CLAE provides authentication without central key management.Nodes generate keys using the KGS public key and initial parameters.Source: B. Securing Data in Transit · p. 9
  • CoAP and IBC help counter impersonation, tampering, sniffing, MITM, relay, replay, and clock-synchronization attacks while supporting confidentiality, integrity, non-repudiation, authentication, and secure key exchange.These protections nevertheless require an initial manual setup similar to that described in Subsection VIII.A.Source: B. Securing Data in Transit · pp. 9–10
  • The system requires an initial manual setup similar to that described in Subsection VIII.A.This is a condition of the proposed transit-security approach.Source: B. Securing Data in Transit · p. 10

C. Securing Data in Storage

  • AI models can detect DoS/DDoS, RF jamming, and stepping-stone attacks; DNN-based detection can trigger termination of compromised connections and cloud warnings for administrators.Cloud warnings can help verify early warnings, if present, from edge-computing nodes in the gateway layer.Source: C. Securing Data in Storage · p. 10
  • Collecting enough meaningful data is a critical challenge for AI techniques because it affects their error rate.Source: C. Securing Data in Storage · p. 10
  • Cloud logging of connected gateways or edge-computing nodes can reveal compromises, while backup gateways can provide alternative routes to IoMT sensors after attacks, breaks, or gateway loss.Source: C. Securing Data in Storage · p. 10

IX. CONCLUSIONS AND FUTURE WORK · Author Biographies:

The paper concludes that combining security techniques is necessary to meet IoMT requirements and address attacks across data collection, storage, and sharing. It identifies remotely secure initial setup and alternative access methods for lost factors or emergencies as future needs.

IX. CONCLUSIONS AND FUTURE WORK

  • A combined framework is proposed to meet IoMT security requirements and cover data and device security from collection through storage and sharing.The paper notes that no single technique can meet all requirements and mitigate most attacks.Source: §IX · p. 10
  • Future work should support remotely secure initial setup and alternative access when a factor is lost or an emergency occurs.Source: §IX · p. 10

Author Biographies:

  • Ali Ghubaish is pursuing a computer engineering Ph.D. at Washington University in St. Louis, where his research interests include network and system security, IoMT, and UAV communications.Source: Author Biographies · p. 13
  • Tara Salman is pursuing a computer engineering Ph.D. at Washington University in St. Louis and researches network security, distributed systems, IoT, and financial technologies.Source: Author Biographies · p. 13
  • Maede Zolanvari researches machine learning and deep learning for Industrial IoT network security, while Devrim Unal’s interests include cyber-physical systems and IoT security.Source: Author Biographies · p. 13
  • Abdulla Al-Ali researches cognitive radios for smart cities and vehicular ad-hoc networks and heads Qatar University’s Computer Science and Engineering department.Source: Author Biographies · p. 13
Loading 2302.04439v1…