Security Threats and Cryptographic Protocols for Medical Wearables

Abstract

In the past few years, the use of several medical devices is increasing. This paper will pay attention to a device developed to get measures of the temperature of diabetic foot. These wearables usually do not have cryptographic protocols to guarantee data security. This study analyzes the existing security in these devices, and simulate malware propagation taking into account the vulnerabilities and lack of security in these highly-constrained interconnected devices. A simulation of malware spreading in a network made by 10 and 15 individuals with 6 and 34 sensors each one, respectively, is included in this study. To avoid such attacks, a lightweight cryptographic protocol could be a satisfactory solution. Considering the quick development of quantum computers, several current cryptographic protocols have been compromised.

1. Introduction

In the past few years, “smart” objects and products have given rise to significant progress in industry production and its security. Advances in digitization that have occurred in the industry, combined with internet technologies and future-oriented technologies in the field of so-called “smart” objects (machines and products), have led to a new and fundamental paradigm shift in industrial production and in their security.

The purpose of using cyber-structures (including detection, computing, and communication hardware/software) is the monitoring and control of our physical world. Ciber-physical systems are the consequence of the integration of embedded systems, such are sensors and control systems [1]. In general, health care devices and wearable health-monitoring systems (WHMS), in particular, are emerging as one of the critical areas in Industry 4.0, specifically portable or wearable technological devices, which are the most attractive applications in the IoT area [2,3]. Medical devices for human use are articles with medical purposes such as diagnosis, investigation, monitoring, prevention, or treatment of a disease, or control of physiological or pathological processes. These devices are regulated by the Medical Devices Regulation [4].

Many wearable systems were developed for physiological monitoring. Some of these devices are a wristband to monitor and alert patients at high cardiac-respiratory risks [5]. A different wearable (BodyGuard) was developed to monitor several parameters in space and on the ground, which had the ability to continuously record the reading of electrocardiogram (ECG), heart rate, room or body temperature, and other variables [6]. The Georgia Tech Wearable Motherboard^TM characterized by a wearable motherboard allowed to measure numerous vital parameters and could be incorporated into clothing, and soldiers could wear it easily and comfortably [7,8].

The so-called MagIC (Maglietta Interattiva Computerizzata) is a fabric-based wearable system that took measures of cardiorespiratory signals in individuals with heart problems. This system was used on subjects in daily situations and collected results showed good quality data during most of the time. This allowed arrhythmia events identification in individuals using this wearable [9].

Since then, several health monitoring systems have been developed for patients homecare [10,11]. Recent developments have improved medical devices with an emphasis on characteristics of biosensors and materials such are stretchability (e.g., artificial limbs [12]), ultrathin and conformality (e.g., skin and implantable electronic products [13]), and biocompatibility and biodegradability (e.g., silicon sensors for the brain [14]).

There are several possible classifications of health monitoring systems. In this paper, the following three categories will be considered [15]:

• Remote health monitoring systems (RHMS) are devices situated far from the system receiving the collected data.
• Mobile health monitoring systems (MHMS) are mobile devices such as mobile phones, computers, pocket laptops, etc., that monitor health parameters.
• Portable health monitoring systems or wearables include WHMS, RHMS and/or MHMS. These devices can be carried by patients in such a way that the sensors are integrated into clothing or accessory. These are called wearables. Thus, these give rise to smart fabrics, smart-textiles, or e-textiles.

Mainly motivated by rising health care expenditures and because of the recent technological advances in microsensors, health monitoring systems can reduce hospitalization time, and the excessive workloads on healthcare personnel, consultation time, waiting lists, etc. An example of this case is people with diabetes, who are prone to some form of nerve damage or injury throughout their lives, especially if they suffer diabetes over a long time. The diabetic disease is considered an important health problem, due to its frequency and its enormous economic and social impact [16]. Diabetics affects the quality of life of people suffering this disease, because it causes ulcers on patients’ feet. Moreover, peripheral neuropathy and vascular insufficiency are the most common chronic complications of this disease. These healthy problems in diabetic patients made some research teams work in wearables to measure different variables in these patients’ feet, such as the temperature [17,18].

A wearable medical device to measure the temperature of the foot consists, fundamentally, of a series of sensors that continuously (in a given period of time) measure the temperature at different regions of interest (ROI) of the foot that have been previously selected. A sock with sensors located in specific ROI is a wearable capable of sending data to an external device and create an alarm in case of ulceration development. Furthermore, it is made up of conductive tissues that carry these measurements to a base station or sink. A health surveillance wireless sensor network designed to deliver personalized healthcare is also called a body area network (BAN) [19].

Figure 1 shows a representation of the connections of a wearable that takes measures of foot temperature, the architecture of a conventional wearable network and the main elements: the wearable itself, a base station/gateway, cloud servers, users, and their control tools. The wearable includes elements of the network that are responsible of creation, detection and (pre-)checking of basic information. On the other hand, routing protocols in a WHMS are established in four tiers: the first one is within the device, where sensors collect the data and send them to the controller through a thermal-aware routing protocol, such are ATAR [20] or WETRP [21]. Then, the controller processes the received information and send it to the gateway. Finally, collected data are transmitted to the user mobile phone by Bluetooth Low Energy (BLE), Wi-Fi or Radiofrequency (RF), and from here to his/her computer or the corresponding health-center through Internet [22,23].

The security needs for IoT-based healthcare solutions are similar to those considered in common communication scenarios: integrity (patient information cannot be altered or changed by unauthorized personnel), availability (data must be available to authorized persons upon request), confidentiality (sensitive information cannot be used by unauthorized individuals, entities or processes) and non-repudiation (individuals cannot deny an action they have carried out) [24,25].

The main limitation of medical applications is their constrained resources. This drawback makes several cryptographic protocols not appropriate for these devices with small size and memory, that require low computation power, short time battery, short memory, and low bandwidth. Lightweight cryptography (LWC) reduces computation time and complexity and assure security [26,27,28].

This paper is organized as follows: Section 2 includes a detailed description of the security in medical devices, with an emphasis on vulnerabilities in their design and functioning protocols. A simulation of a malware attack against medical devices is included in Section 3. As a solution to make the devices more secure, a proposal of lightweight cryptography protocol is included in Section 4. Finally, the conclusions of this study are stated.

2. Security in Medical Devices

Wearable health monitoring systems must adapt to strict medical criteria and consider ergonomic restrictions and hardware limitations [29]. Research in this field is focused on producing garments with functionalities that improve the lives of its users. These medical devices must be resistant to both natural or intrinsic failures and malicious attacks [30]. An intrinsic failure should be understood as a malfunctioning in the mechanism of the device, which could imply an incorrect reading in the sensing procedure or an error during the transmission of the data [31]. These situations are occasional and, in general, are either automatically solved in the next operation process or manually fixed by an expert. Hence, natural failures do not represent a threat, but just a momentary loss of usability. On the other hand, an attack executed on a WHMS by an adversary supposes a more dangerous scenario, even more critical than hacking any other device, such as a laptop or a mobile phone, as it can cause physical harm to the owner. For instance, hacking a diabetic smart contact sensor from false readings can lead to the wearer not receiving warning or danger signals [32].

The limitations caused by vulnerabilities create attack vectors that might be utilized by an attacker to gain access to the information of a particular individual or to control the device itself. Several of these attack vectors can be identified, being the most important the followings [33,34]:

• Firmware vulnerabilities: an inadequate development process of the software or the lack of authentication protocols in firmware updates facilitate the introduction of an altered, malicious firmware by an attacker. This vector is usually exploited by conducting inverse engineering to the original firmware, concretely in the cases in which there are no protection techniques as code obfuscating/packing [35]. Some authors defend that this attack vector is the most powerful, as it scales better than the others, and proportionates more benefits to the adversary, only requiring one interaction with the wearable [36].
• Communication protocols: most of the current WHMS transfer data to a database server or other electronic devices is done via BLE, Wi-Fi, and RF. These channels have been demonstrated in several studies to be vulnerable and leak the information of the patients [37,38]. Especially harmful is the scenario in which the transmitted data are not encrypted and can be directly interpreted [39].
• Applications and sensors: excessive privileged apps and sensors might be used by attackers to attack WHMS. This scenario can be conducted by substituting the original app by a malicious one, specifically designed by the adversary to perform concrete actions. Likewise, leaks of sensors readings can be used to infer the activity the patient was executing at a certain time [39].

Additionally, an attacker may be interested in accessing a particular WHMS for different reasons. Depending on the purpose of the adversary, the malware (malicious software) may perform an attack identified as a passive attack or an active attack [37]. Passive attacks are performed while routing the measured data, and the adversary tries to sniff the communications of the WHMS, which leads to the interception of the patient information. Changes in the destination of storage by the attacker also belong to this type of attack. On the other hand, active attackers are capable of modifying the patients’ data or introducing new, false data streams to compromise the WHMS records or control the device [40]. There exist other, more concrete attacks divisions depending on their nature, as exposed in [24,29]. The most critical and common attacks are explained below:

• Eavesdropping: this attack takes advantage of poor communication protocols to secretly stole the transmitted data [38]. By doing this, the attacker can not only obtain critical health-related information of the patient, but also know the activities he has performed, the places he has visited and the format in which the WHMS stores the data [41].
• Replay attack: the attacker can go one step further from eavesdropping, introducing previous, eavesdropped data to compromise WHMS readings or gain illegitimate access to the patient’s devices. For example, if a wearable device has the permission to unlock the patient’s smartphone, the adversary might be able to unlock it by replaying information that has previously eavesdropped [29].
• Data tampering/modification: this attack occurs when the attacker modifies the measured data without having the proper authorization. To do this, the attacker must know the format in which the WHMS reads and transmits information, therefore this type of attack starts with an eavesdropping attack [34].
• Denial of service (DoS): the purpose of this attack is to alter the correct functioning of the WHMS by collapsing it with continuous orders. In this way, the battery of the device will run out very rapidly, or the patient will be unable to use it. A distributed DoS (DDoS) attack performed by botnets could lead many nodes to be involved in the attack [38,42].
• Side-channel attack: in this type of attack, the adversary uses information from the implementation of a WHMS to gather critical details of the patient. For example, an electromagnetic analysis can be conducted to derive the power consumption of a WHMS and, hence, extract the activities it is executing [43]. Likewise, it has been shown that information acquired from motion sensors of wearable devices can be used to profile the patient [39].

The rest of this section was divided into three parts, one for each attack vector previously defined (firmware vulnerabilities, communication protocols, and applications and sensors). For each vector, the current literature was studied, and a brief description of the studies that have successfully executed an attack on a WHMS was included. Since some works use more than one attack vector in their methodology, each article was allocated in the group of its principal attack vector.

2.1. Firmware Vulnerabilities

Since the development of medical devices, wearables, and WHMS, several authors have claimed that security and privacy issues are not considered in the design and construction processes [29,44]. These weaknesses include the absence of software/firmware protection techniques (code obfuscating/packing) [35] and the lack of authentication processes in the gateway to update the server [33]. In fact, in [45] the authors investigate the security level of different smartbands and state that their firmware vulnerabilities enable the introduction of malicious versions, compromising the integrity of patients’ information and facilitating the remote control of the wearable. The authors identified that some devices did not implement a protocol to verify firmware updates, and, when included, were easy to bypass.

One example of firmware attack can be found in [44], where an attack is implemented on the wearable medical device Nike+Fuelband, which include a USB connector to be synchronized. The authors took advantage of the lack of read and write protection on the device and designed a process to obtain the original firmware. Then, they introduced a modified version of the firmware via the USB connector, which allow them to modify the texts displayed by the wearable. Similarly, in 2016, Rieck et al. [36] showed how to successfully attack the fitness tracker Withings’ Activité by introducing a false firmware update. They first located the local firmware address and performed reverse engineering to find the code structure in charge of firmware update verification. Once this was achieved, the authors introduced the modified firmware into the wearable as an update with the Health Mate app, gaining control of the device.

In the work presented in [46] the authors introduce several modified versions of the firmware by building a fake gateway on a PC. The developed methodology consisted on three steps: (1) reverse engineer of the gateway app of the device, (2) analysis of the BLE communication between both elements, and (3) reverse engineer of the original firmware.

Another example of an attack exploiting firmware vulnerabilities is [47]. In this case, with the introduction of a personalized firmware, they were able to disturb the correct functioning of the device, eliminating the encryption process and eavesdropping on the patients’ information. Additionally, they were also capable of obtaining the user credentials to execute a replay attack.

2.2. Communication Protocols

WHMS usually transmit the measured data to database servers, update their configuration using a concrete smartphone app, and communicate with other devices for different purposes. These communications protocols are principally based on BLE, RF, or Wi-Fi [34], and the little attention given to these transmission options have created a critical attack vector. For example, in [48] two successful attacks against an insulin pump are executed by reverse engineering the wireless communication protocols of the delivery system. One of the attacks was passive and allowed to eavesdrop on the signals and obtain information of the insulin pump, such as the commands that it received. The second attack was active, and enabled the adversary to remotely control the insulin pump. Similar attacks are shown in [49].

In [50], Rahman et al. construct FitBite, a tool that exploits the vulnerabilities of the medical tracker Fitbit, and attack this device tracking private data, injecting and modifying the measured data in real time, and replaying the user’s account data. They demonstrated how these actions could be used to conduct DoS attacks, collapsing the functioning and draining the battery of the device. Another example of the vulnerability of BLE is included in [35], where the authors examine the security of nine different fitness trackers and explain the vulnerabilities of their communication protocols. In fact, they are able to eavesdrop and manipulate measured data and change the configuration of the devices, performing DoS attacks without changing any source code.

In 2016, several articles, such as [51,52,53], were published and demonstrated that BLE and Wi-Fi connections are vulnerable to eavesdropping, brute force, and man-in-the-middle (MITM) attacks. These attacks were performed on devices available in the market, such as Fitbit, Jawbone UP, Samsung smartwatches, and Pebble Watch. Apart from Fitbit, Xiaomi Huami, and Samsung Gear3 were also attacked in [54]. Although this work recognize security improvements in the Samsung Gear3, the authors are able to use the BLE connections of the wearables to eavesdrop on the information and track the identity of the patients.

Wood et al. [55] proposed a method based on Shannon entropy tests and Chi-squared tests to collect network traffic from WHMS, detecting plain messages transmission of the packet payload and compromising the security of sensitive medical information of the patients. Aliasgari et al. [56] analyzed in their research the safety of the transport layer security (TLS) protocol in 25 mHealth Android applications. Their results indicate that the majority of them present weak TLS configurations and are susceptible to MITM attacks. BLE communications between wearable devices and smartphone apps, and between these apps and servers using the Internet were examined in [57]. The authors found that these communications were not secure, sending patients credentials in clear text and allowing connections with unbounded devices. A work by Sethuraman et al. [58] uses unmanned aerial vehicles to interrupt Bluetooth and Wi-Fi data transmission of WHMS, leading to data interception, data corruption, and service unavailability (DoS).

The research presented in [59,60] execute eavesdrop, replay and DoS attacks on wearable devices, but also propose new tools based on Artificial Intelligence (AI) to find anomalies in the devices’ functioning, create an intrusion detection system, and protect the wearables.

2.3. Applications and Sensors

In this attack vector, patient’s critical information might be compromised by non-secure or malicious apps designed by adversaries that simulate the functioning of the legitimate ones. In this second case, the WHMS is forced to be connected to the fake app, which compromises the security of the data. In [61], different characteristics of several apps of several operating systems were analyzed, including tracker connectivity and personal information leakage. An example of a malicious app attack is included in [38], where the authors constructed a fake Android application to sniff packets, analyze commands and send fake commands. Their results showed that they were able to read and send messages between the Bong 3 HR wristband and a smartphone, perform fake authentication in MiBand2 and read messages and gain remote control of the TW64 and Mambo HR wearables.

Interestingly, the use of sensors recordings of wearable devices can lead to side-channel attacks that attacker might use to identify the activities performed or the applications employed by a concrete user. This type of attack is usually executed using AI tools, since they can identify patterns and correlate the sensorial data with the actions of a user. For example, in [62] the authors employ simple linear regression, random forests, and k-nearest neighbors to predict the words written by the user with his smartphone keyboard (keystroke dynamics) based on his wrist movements measured with a wristband. Similar attacks are proposed in [63], using a support vector machine, and [64], using tree-based key sequence inference and backward subpath integration.

3. Simulation of a Malware Attack against Medical Devices

Attacks to WHMS are possible because of vulnerabilities in their design and functioning protocols. An attack executed on a WHMS can disturb functionality, lead the user not to receive information about vital signals and may cause severe injury or death. As users data are sensitive, attacks suppose a dangerous scenario, even more critical than hacking any other device, such as a laptop or a mobile phone [32,65].

Medical devices and their connections are similar to a wireless sensor network [24]. Figure 2 represent the scenario of a malware attack against a WHMS.

A simulation of a malware attack against medical devices with an SEIRS-D agent-based model [66] was developed. Agent-based models (ABM) are models where individuals (agents) are entities that are unique and autonomous, which interact with their neighbours and with their near environment. An ABM can be made up of different agents that represent different individuals within the system under analysis. Generally, these models are suitable for systems with heterogeneous, autonomous, and proactive actors in which individual characteristics cannot be neglected.

In this model, in each time t, the sensor nodes can assume one of the following states:

• Susceptible: the sensor has the characteristics for been infected by malware.
• Exposed: the malware has attacked the sensor, but the sensor cannot be transmitted to the sensors neighbors.
• Infected: the computational characteristics of the sensor allows it to be infected by malware and a sensor is capable of transmitting malware to its neighbors and the gateway.
• Recovered: the malware has been removed from the sensor, either by updating or fixing.
• Dead: the sensor battery life may be exhausted faster because of the infection of malware, and the sensor is no longer useful.

The states of SEIRS-D model can be determined from the characteristics of the agents involved in the transmission and infection of malware (see

Table 1. Agents with their characteristics.

Type of Agents	Characteristics
WHMS sensors	Type: Sensor or sink nodes
	Computational capacity: Low
	Energy consumption: Low or medium
	Capacity of transmission and reception of information: Low
	Security level for nodes: Low or medium
	Data collection method: Periodical or requested
	Duty cycle: Active or inactive
Malware	Type: IoT based malware
	Spreading mechanisms: Self-replication, exploit, or user interaction
	Target: DoS/DDoS or botnet attack, or information exfiltration
Network topology	Type: BAN
	Routing protocols: ATAR/WETRP, BLE/Wi-Fi/RF or Internet
Phenomenon of interest	Risk of malware attack: medium or high
Human action	Level: medium or high
External devices	Risk of devices infected with malware: Low, medium or high

). The agents and their characteristics involved in this process are as follows:

• WHMS sensors: are responsible for measuring various vital signs of a person, such as foot temperature.

  –

  Type of sensors: can be sensor, sink, and cluster-head nodes. Each one performs a particular function within the device.

  –

  Computational capacity: each WHMS can have computational capabilities, such as a microprocessor, memory, and storage, which allow performing different measurements.

  –

  Energy consumption: depends on the number and the frequency of measurements.

  –

  The capacity of transmission and reception of information: is related to the computational capacity; for example, a device with higher computational capacity will process more data and, in turn, transmit that information to its neighbours.

  –

  Security level: is critical, as the health data handled by these sensors are sensitive.

  –

  Data collection method: refers to the technique and periodicity in which a sensor performs measurements.

  –

  Duty cycle: when the sensor is not taking measurements, it may be in a inactive state, while its state is active when it is taking measurements.

• Malware: are those malicious codes that seek to perform unauthorized actions on the devices.

  –

  Type of malware: WMHS sensors may be affected by IoT-based malware.

  –

  Spreading mechanism: malware can use self-replication, exploit, or user interaction to perform malicious actions.

  –

  Target: the most common attacks for WHMS are DoS/DDoS or botnet attacks.

• Network topology: represents the form of communication of the sensors.

  –

  Type of topology: WHMS is based on a body area network.

  –

  Routing or communication protocols: depending on the tier, the communication is established through different protocols.

• The phenomenon of interest: the environment where these devices are located is outside hospitals to monitor patients during their daily activities.

  –

  Risk of malware attack: can range from low to high according to exposure to unsafe networks.

• Human action refers to human intervention in the device functioning.

  –

  Human action level on the network: may vary according to the required patient interaction with the device or sensors.

• External devices: connections to external devices for manual data download may expose the sensors to malware.

  –

  Risk of devices infected with malware: those external devices that can connect to unsecured networks are at higher risk of exposure to malware, and therefore, if a WHMS connects to this external device, it may have a high probability of malware infection.

The following values have been used for the agent characteristics in both scenarios: the computational capacity is low, the energy consumption is medium, the information transmission capacity is low, the security level ranges from low to medium, and a periodical data collection.

The propagation of IoT-based malware has been simulated, using self-replication to turn the devices into a botnet. The network type for medical devices is always a personal area network; in addition, connection via BLE/Wi-Fi/RF is used for these cases. Finally, the interaction of humans with devices is high, so the risk of malware attacks is high, too, and the risk of infecting devices is also high.

Considering a scenario of 10 diabetic patients using a wearable to collect temperature data from their feet, with 6 sensors (3 per foot) distributed in specific regions of interest [18], the simulation is shown in Figure 3. This simulation was made with MESA framework, Apache2 licensed agent-based modeling environment [67]. After 168 h, the number of susceptible devices decrease, and susceptible individuals increase.

This behavior is even more drastic when the network is bigger. More sensors could be added to the wearable to get more measures and analyze the results. In the case of 15 diabetic patients with 17 sensors in each foot, the graph shows that the malware invades all the network. This fact can be appreciated in Figure 4, where the number of susceptible sensors decrease and after 24 h, exposed, recovered, and death sensors are bigger than susceptible ones.

4. Cryptographic Protocols to Secure Medical Devices

Healthcare systems have reduced computation and storage capabilities and they are highly-constrained interconnected devices where current cryptographic algorithms, designed for desktop/server environments, are not suitable. Apart from the device capabilities, the implementation of a cryptographic protocol considers the hardware and software characteristics and possibilities [65].

In 2015, the national institute of standards and technology (NIST) initiated a process to find a suitable standard lightweight cryptographic algorithm to be used in constrained and restricted environments where the current NIST cryptographic standards are not acceptable or are inadequate [68]. This process is called Competition for Authenticated Encryption: Security, Applicability, and Robustness (CAESAR). During the evaluation process, three criteria were considered to accept or discard algorithms: cryptographic security, performance, and cost in its implementation. For the second-round selection of candidates, other characteristics where analyzed: functionality, underlying components, design approaches, and supported key and tag sizes [69]. In March 2021, from the initial list of 57 proposals, a list of the following 10 finalists was announced: Ascon, Elephant, GIFT-COFB, Grain128-AEAD, ISAP, Photon-Beetle, Romulus, Sparkle, TinyJambu, and Xoodyak [70,71]. Several authors performed different analysis to the NIST candidates. The modes of operation and the efficiencies of the schemes were provided in [72]; the costs, performance and security were analyzed in [73]; the metrics considered in [74] were performance, area, energy, and area × energy; and the area, the time the number of cycles to encrypt one block, the energy, the block size, and power coefficients were used as input parameters for a general metric whose purpose was a comparison of lightweight algorithms [75].

In the proposal of a new LWC system, quantum threats should be considered. During the NIST selection of candidates, the post-quantum security property was considered in case multiple candidates had similar characteristics about security and performance. Integer factorization, discrete logarithm, and elliptic-curve discrete logarithm problems, which are the robustness of public key cryptography, can be efficiently broken with a quantum computer [76]. Quantum resistant algorithms are able to reduce the computation time to break symmetric cryptosystems and make their security similar to the same protocols with half-length keys [77]. In the case of asymmetric cryptography, the NIST is in the process of selecting quantum-resistant cryptographic algorithms that are not vulnerable to quantum computers [78]. In any case, LWC is based on symmetric-key cryptography with the goal of as low as possible implementation costs of hardware and the implementation efficiency as high as possible, assuring security [79].

One of the NIST LWC CAESAR competition finalists was explicitly designed for quantum resistance, and it is permutation-based lightweight, which makes the proposal to have a simple structure and fast running speed. Ascon (its variant Ascon-80pq) is resistant to side-channel attacks, with a key size $k\le$ 160 bits and a 320-bit permutation, and provides authenticated encryption with associated data (AEAD) and hashing functionality. Two more candidates from the second round provided security against quantum adversaries: Gimli (permutation-based) and SATURNIN (block cipher based), but these were not considered as finalists. Thus, Ascon is the only one that can be considered as the best option for a quantum-resistant algorithm [70].

The Mirai botnet attacked many IoT devices in 2016 and caused several damage to smart devices since infected devices were used as a launch platform for DDoS attacks [80,81]. The Ascon AEAD scheme can mitigate such vulnerabilities by improving throughput and security with a field-programmable gate array platform, which provides higher speed, lower cost, faster development time, flexibility and configurability [82]. This improvement prevents attacks and secure the hardware from attacks [83].

In Ascon cipher suite, the authenticated encryption algorithm, $\mathcal{E}$, and the decryption algorithm, $\mathcal{D}$, are parameterized by the rate (data block size) r, two internal round numbers, a and b, and the key length, k. The inputs are a k-bits secret key K, a nonce (public message number) N with 128 bits, associated data A of arbitrary length, and a plaintext M of arbitrary length, the authenticated encryption procedure output is

$$\begin{array}{c}\mathcal{E}:\mathcal{K}\times \mathcal{N}\times \mathcal{A}\times \mathcal{P}⟶\mathcal{C}\times \mathcal{T}\\ {\mathcal{E}}_{k,r,a,b}(K,N,A,M)\mapsto (C,T),\end{array}$$

where C is the authenticated ciphertext with the same length as M, and a 128-bits authentication tag, T, which can authenticate the associated data and the encrypted message.

The decryption procedure takes the same parameters, $K,N,A$, and adds the authenticated encryption procedure output, i.e.,

$$\begin{array}{c}\mathcal{D}:\mathcal{K}\times \mathcal{N}\times \mathcal{A}\times \mathcal{C}\times \mathcal{T}⟶M\cup \{\perp \}\\ {\mathcal{D}}_{k,r,a,b}(K,N,A,C,T)=\{M,\perp \},\end{array}$$

and it obtains the plaintext when the tag is correctly verified or an error, ⊥, in case the tag verification fails.

Moreover, ${\mathcal{E}}_{k,r,a,b}(K,N,A,M)\mapsto (C,T)$ if and only if ${\mathcal{D}}_{k,r,a,b}(K,N,A,C,T)=M$. For encryption and decryption procedures, just one pass over the data is required.

On the other hand, the family of hash functions for Ascon is defined by parameterizing the extendable output function X with the rate, r, numbers a and b as defined before, and an output length limit h.

$$X_{h,r,a,b}(M,l)=H.$$

Thus, this function maps an input message, M, to a hash output, H, with length $l\le h$.

Most symmetric-key protocols under NIST consideration use permutation as underlying primitive, this is also the case of Ascon Cryptosystem [84,85]. The rest of candidate algorithms are based on block-cipher, tweakable block cipher and stream cipher in less percentage.

Figure 5 shows how the Ascon suite operates. Four stages are part of this flow [84,86]:

• Initialization: The algorithm starts with the key, K, the nonce, N, the rate, r, and the round numbers a and b as 8-bit integers. During this phase, a rounds of the round transformation $\pi$ are applied to the initial state.
• Processing associated data: during this state the data A is processed in r-bits blocks.
• Processing plaintext/ciphertext: the plain text, P and the ciphertext, C, are processed in blocks of r bits.
• Finalization: The encryption algorithm output consist on the tag, T, and the ciphertext blocks, $C_i$, and the decryption one returns the plaintext blocks, $P_i$ (if T matches the calculated tag from the secret key).

Recommended parameters for the Ascon-80pq scheme are a key size $k=160$ bits, a nonce and tag size $n=t=128$ bits (lowercase letters represents the size and capital letters the corresponding parameters), a rate $r=64$ bits, and $a=b=12$ for the permutations (both initialization and finalization), $p^a$, and the intermediate permutation, $p^b$, respectively. For both encryption and decryption procedures, these permutations are just only evaluated in one direction, which significantly reduces the computational costs. Ascon-80pq provides 128-bit security in the AEAD, i.e., the confidentiality of the plaintext and the integrity of ciphertext are protected. The encryption algorithm protects $2^{67}$ bytes of processed plaintext, which make this system adequate for a lightweight application, secure against classical attacks [86].

Figure 6 shows the simulation of a secure WHMS network when the security level for nodes is medium, the phenomenon of interest (risk of malware attack) is medium, and the external devices (risk of devices infected with malware) is low. In this case, there is a first stage where infected devices increase (between 46 and 120 h). After this time, some infected devices become death until 160 h, and then an equilibrium is reached.

5. Discussion

With the massive use of wearable health–monitoring systems, security challenges are increasing rapidly. Cybercriminals use malware as their main weapon to carry out security attacks, causing significant damage and loss to IoT users. The main objectives of cybercrimes against WHMS are firmware vulnerabilities, communication protocols and applications and sensors to get users’ sensitive information or to damage devices.

The analysis of the vulnerabilities of a device has the purpose of mitigating or reducing the risks to which the system is exposed, with the purpose to protect the information that is stored in the servers or transmitted through different routing protocols to the network. For this reason, cybersecurity studies for different environments are becoming more and more frequent, as is the case of medical devices, made up of microsensors whose purpose is to monitor different physical phenomenon. In this study, the physical phenomena is the temperature that is measured in diabetic foot.

In this study, the spread of malware in a medical network is simulated using an agent-based model to improve the cybersecurity mechanisms that can be applied to this type of network. One of the advantages of ABM is that it considers individual characteristics, which is particularly useful in the case of wearable health-monitoring systems because a failure in a component could cause serious health problems. This is not the case of global models, that include general characteristics of the network. Malware spreading depends on the environment; the spread is different in the military, industrial or medical sectors, Internet, Wi-Fi, BLE, or thermal-aware routing protocols, etc. Some studies suggest implementing security tools such as Honeypots for wireless sensor networks, which allow real-time data collection of a malicious attack in a controlled environment.

Three different environments were considered for this simulation. In the first one, 10 individuals wear a device made of six sensors, three per foot (considering a medical device to take foot temperature measures). In this case, the simulation showed that the malware was spreading slowly. After 168 h, there were still 45 sensors (corresponding to 7 persons) that were not infected. In the second simulation the number of devices was considerably increased. It considered 15 individuals with 34 sensors each one, i.e., a total amount of 510 sensors distributed in the corresponding regions of interest. The malware spreads rapidly. In 21.6 h, the number of susceptible are equal to the number of exposed sensors, so, these sensors will not spread the malware. Moreover, from the 11th hour, infected and exposed increase together until the 18th, where infected decrease and exposed and recovered increase. As dead sensors do not increase, devices will recovered from the malware attack. The recovery begins when infected decrease under recovered and exposed. The third simulation considered a secure network. In this case, the risk of malware attack and devices infected is medium and low, respectively. An equilibrium is reached in this simulation after 160 h. Moreover, the malware spreading is slow, with a maximum of infected nodes at 76 h.

Most medical devices do not have sufficient resources to provide complex cryptography. Limitations in their computational capacity, energy consumption, capacity of transmission and reception of information, etc., make traditional cryptographic algorithms not suitable for them. A cryptographic protocol for constrained resources is considered an acceptable solution to secure health devices. The primary choice for the NIST protocol that could be used with all security considerations is the Ascon-80pq from the Ascon cipher suite. No weakness was found for this protocol of excellent implementation characteristics. Ascon is highly appropriate for wearable health-monitoring lightweight systems where several communications protocols are involved, it can be efficiently used for these systems where side-channel resistance is essential. Moreover, Ascon is a simple algorithm, as it only uses bitwise Boolean functions.

The security provided by all Ascon family members protects the plaintext confidentiality and the plaintext, the associated data and the public message number integrity. The use of the same underlying permutation for authenticated encryption and hashing reduces the area requirements for hardware implementations and restrict the code base and thus, the workload is reduced.