12
IoT Use Cases and Implementations: Healthcare
Mehrnoosh Monshizadeh Vikramajeet Khatri Oskari Koskimies and Mauri Honkanen
12.1 Introduction
Recently, there has been considerable global interest in exploiting digital healthcare solutions, often known as eHealth in order to improve traditional healthcare mechanisms. Currently, fewer physicians are taking care of more patients than ever; doctors do not have enough time to educate patients about their condition or care plans which causes uncertainty, stress, non‐adherence to care plans, and unnecessary hospitalization. On the other hand, global healthcare spending is projected to reach $8.7 trillion by 2020 with an annual growth rate of 4.1% in 2017–2021. This growth is driven by a number of factors such as, chronic diseases (becoming more common), aging, increasing population, expansion in developing markets, new though costlier medical treatments, and rising labor costs [1,2].
Certain chronic conditions, such as hypertension, excess weight and diabetes, are risk factors for stroke. A stroke is a condition where the flow of blood carrying oxygen and nutrients to a portion of the brain is reduced or blocked. Stroke is the second most common cause of death worldwide and ranks third most Disability Adjusted Life Years (DALY) [3].
As seen in Figure 12.1, in Finland with a population of 5.5 million, there are about 82 000 stroke patients and every year about 25 000 new people are impacted by stroke. As many as 17% of patients suffer a new stroke within a year, 10–20% develop dementia and one‐third have aphasia (speech difficulties). About 50% of these patients have permanent damage of some sort while every fourth patient is of working age. Almost half of these patients require active rehabilitation following a stroke which has a relatively high impact on the economy. According to statistics, stroke is the third most expensive chronic condition in Finland with the first year of treatment costing over €20 000, lifetime cost greater than €85 000 and approximately 1.8 M in patient days caused every year. It is estimated that in Finland there will be a need for at least 100 new hospital wards by 2020 because of the increased number of stroke patients [4].
Figure 12.1 Stroke care in Finland.
Stroke can be a lethal or a severely disabling event. Stroke patients have multiple problems with memory, normal movement, speech, and the fear of recurring strokes. One typical reason for stroke is occasional malfunction of the heart (typically in the left atrial part of the heart) that causes clotting. This clot exits the heart after physical exercise, for example, when the heart pumps heavily and ends up blocking narrow blood vessels in the brain causing the stroke. The medical challenge is that most of these atrial fibrillation cases causing the clotting are not traceable after the event and some are not even noticed by the patient. There is, nevertheless, high risk of recurrent strokes in cases where blood flow through the heart is not functioning correctly. This creates a high interest to monitor the heart of stroke patients until normal heart functionality or dysfunctionality can be verified. Once validated, the monitoring of the impact of medication and/or functionality of a pacemaker becomes important.
There are two methods to prevent stroke: primary and secondary. Primary prevention is used for those who have not suffered from stroke previously, whereas secondary prevention applies to the patients who have already been affected by stroke. Although there are challenges such as poor adherence to medication, failed care plan and cryptogenic causes, still approximately 80% of reccurrences could be prevented with early and fast diagnosis [5].
To overcome some of the secondary prevention challenges and to expand geographical responsibility areas of healthcare providers, in this chapter, a secure digital remote patient monitoring solution is introduced. With this solution, a patient could be monitored and served remotely; health services could be provided to people far away from hospitals and by experts not necessarily available in the nearest hospital. In addition, the proposed solution applies the concept of eHealth to increase information sharing about the disease and patient awareness regarding their risk factors to improve self‐care. This solution extends ElectroCardioGram (ECG) monitoring from a typical 24–48 hour holtering case to multiple 48 hour sessions across a post‐discharge care plan of several months [5].
The rest of the chapter is organized as follows. Section 12.2 describes the remote patient monitoring platform in general. Section 12.3 discusses the security concerns related to digital health technologies and briefly reviews available safeguard and authentication techniques to secure a digital health system. Section 12.4 introduces a security architecture for the proposed remote patient monitoring platform and finally, and conclusions are presented in the last section.
12.2 Remote Patient Monitoring Architecture
The remote patient monitoring solution is a healthcare Internet of Things (IoT) system that can be implemented on Virtual Machines (VMs) in the cloud. The system can be orchestrated to other digital services or network modules via Network Functions Virtualization (NFV). In the current use case, Docker and Amazon Application Programming Interfaces (APIs) are used for orchestration.
The remote patient monitoring platform consists of patient monitoring devices, a patient smartphone application, a cloud backend (docker containers in multiple VMs, orchestrated with Docker Swarm) and a web‐based clinician application. The cloud backend could also utilize NFV for security and anomaly detection purposes.
As shown in Figure 12.2, the platform includes three main parts: patient, cloud, and hospital side.
Figure 12.2 Architecture of remote patient monitoring platform.
At the patient side, wearables are provided to patients to measure parameters such as Blood Pressure (BP), weight, and ECG. The information is collected periodically, based on a care plan. Collected information is transferred via Bluetooth to a mobile device that has the Patient App. Then, information from the Patient App will be transferred to the cloud. In the cloud, there are different modules, for example, database (DB), data analytics and security and data visualization. The cloud has also an interface to electronic health records (EHRs) databases for storing patient data. The Data Analytics and Security module will classify data in predefined clusters either for anomaly detection or for future investigation by doctors. The data visualization module will transform classified data to be visualized by doctors. The doctors can log in and view the patient information through the Clinician App [5]. The Patient App and Clinician App are shown in Figure 12.3.
Figure 12.3 Patient App and Clinician App of remote patient monitoring platform.
12.3 Security Related to eHealth
Digital health technologies may include critical and strategic services such as connected hospitals, remote surgery, patient care and preventive health plans where an anomaly in the original function can mean the difference between life and death. An attack on such devices and services could also be stealing or modifying patient health information which violates privacy and could compromise patients' health.
Wearables include personal devices such as smart watches, health monitors, and medical devices including wireless pacemakers and insulin pumps. These devices collect and transmit detailed health information about the person. If an attacker gains remote access or remote control of a wearable medical device, then an attacker could potentially harm or kill the person e.g. by causing a pacemaker to malfunction or an insulin pump to overdose or under‐dose the insulin supplied to the person [6].
Users may prove their identity to a device using a password, Personal Identification Number (PIN) or fingerprints. Wearable devices like watches might serve as proxy devices with more natural interactions than a smartphone. As each user will perform a gesture differently, gestures can also serve as a form of authentication and therefore be used to identify a person. Furthermore, the proximity of a wearable device is helpful in identifying several contextual factors, including user location and people nearby [7].
In order to perform safe and secure data exchange between patients and their healthcare providers, different security aspects must be considered in a digital health platform:
- Technical safeguards such as encryption, authentication, and intrusion‐detection methods.
- Physical safeguards such as security enclosures for workstations, media disposal procedures and asset tracking.
- Administrative safeguards such as risk analysis, access rights reviews and security training.
This chapter only concentrates on the technical safeguards. The current section surveys available authentication and cryptography methods, and the next section describes security measures in general. In addition, the next section also proposes an anomaly detection module to efficiently detect and prevent intrusion on the proposed platform.
12.3.1 IoT Authentication
To overcome the identification challenges, authentication protocols must be strong enough to be resilient against many different attacks, such as eavesdropping, replay attacks, where an attacker keeps the result of a previous authentication made by an authorized user to abuse it at a later date, man‐in‐the‐middle attacks, dictionary attacks where an attacker tries the most probable secret keys such as names and birth dates for a password, or brute‐force attacks where an attacker tries all possible password combinations [6].
To verify the identity of an IoT device, authentication can be performed in multiple ways e.g. authentication of IoT device on the cloud service and authentication of the IoT device to IoT gateway [8]. Some authentication mechanisms include: password, PIN, signature, token, voice pattern, smart card and fingerprint [9]. To transmit the authentication parameters over the network, encryption is recommended to avoid eavesdropping and credentials theft.
Authentication can be achieved using symmetric or asymmetric (public‐key) cryptography. In case of symmetric cryptography authentication mechanisms, both sender and receiver share the same key, which must be delivered to IoT devices over a secure channel. Distribution of symmetric keys is often difficult to accomplish in a secure and convenient manner. One commonly used approach is to generate the keys at manufacture time and deliver them together with the device in a machine‐readable form such as a QR code, so that the keys can easily be entered into the system when the IoT device is enrolled in the system.
Traditional authentication mechanisms are based on Public Key Infrastructure (PKI), where public and private keys are generated for encryption and decryption. The widely used digital signature mechanism utilizes PKI. A one‐way hash of the data (or secret key of IoT device) will be created to be signed (or verified) and will then be encrypted with the private key of the IoT device. The recipient (IoT device, IoT gateway, user, cloud) uses the sent IoT device's public key to decrypt the hash and verify whether it was created with the sent IoT device's private key. This procedure performs a successful authentication [10]. A PKI‐based authentication server has been proposed for authentication across multiple EHR systems [6]. However, PKI may be unfit for IoT devices as these mechanisms require significant processing, memory, storage, communication, and management overheads [11].
The following lightweight authentication algorithms are feasible for IoT devices:
A Message Queuing Telemetry Transport (MQTT) protocol identifies an IoT device by its unique device identifier, user ID, or digital certificate. Every IoT device in MQTT will have a unique client identifier based on a username and password that acts as an identifier in the authentication process. Based on client identity, the MQTT server authenticates the IoT device (client) either by using the Secure Sockets Layer (SSL) protocol or by using a password specified by the IoT device. At the transport layer, a Transport Layer Security (TLS) takes care of data encryption and avoids eavesdropping. In addition, the IoT device can utilize an X.509 certificate during the MQTT TLS handshake process for authentication [12].
The Advanced Message Queuing Protocol (AMQP) applies Simple Authentication and Security Layer (SASL) to authenticate IoT device connections to the broker. Typically, the used mechanism is PLAIN, where authentication parameters include a username and password. This PLAIN mechanism is vulnerable to eavesdropping and man‐in‐the‐middle attacks, so it is recommended to use SSL or turn off the PLAIN mechanism [12].
Extensible Messaging and Presence Protocol (XMPP) uses SASL to offer an extensible set of authentication methods that the IoT device can use. If unsecure authentication mechanisms are offered, then the IoT device may select an unsecure authentication mechanism from offered authentication mechanisms that then allows credential theft. Therefore, it is recommended that systems are configured so that IoT devices can only use secure authentication mechanisms [12].
Message Authentication Code (MAC) algorithms are much faster than digital signatures and offer good security if a shared key is exchanged between two parties prior to the communication session establishment. Hash‐based Message Authentication Code (HMAC) is an enhanced MAC consisting of a hash function and cryptographic key. HMAC typically runs fast over constrained devices such as IoT devices. However, HMAC uses the same key for encryption and decryption so all those IoT devices who have access to the secret key would be able to sign and verify the communication [12].
In [13], an IoT object‐authentication framework is proposed that uses device‐specific information (e.g. fingerprints), together with a transfer learning tool to detect changes in that specific information. The proposed framework includes five modules: feature extraction, fingerprint generation, similarity measure, environment estimation, and transferring knowledge. It is considered that IoT devices transmit data to a gateway, who later forwards it to a security service provider (SP) in the cloud. SP authenticates the transmitted data based on IoT device fingerprints. Considering Radio Frequency Identification (RFID) tags, possible IoT device fingerprints include wavelet‐based features such as mean, variance, and skewness of electronic codes. Another example of fingerprint is environmental changes for IoT devices, such as changes in temperature, humidity, wind, physical displacement, or any physical changes. Such fingerprints make it hard to impersonate a legitimate IoT and perform successful authentication in the network.
According to [14], user authentication is divided into two categories: static authentication and continuous authentication. Static authentication is invoked at the beginning of a session. Communication begins once the user is authenticated. The user remains authenticated for a longer or indefinite time as configured at the server (i.e. session timeout). Static authentication does not offer protection against session hijacking attacks. Continuous authentication can repeatedly authenticate the legitimacy of a user during the device usage time. Continuous authentication is not a substitute for static authentication, but it complements static authentication mechanisms for enhanced security.
A lightweight continuous authentication protocol can be used for IoT devices to perform mutual authentication. This method utilizes lightweight computations such as HMAC, hash function and bitwise eXclusive‐OR (XOR) functions. Initially, static authentication takes place as part of this method and an initial token for both parties is generated during the authentication period. In the continuous authentication phase, the initial authenticated token, together with IoT device data, is transferred to the IoT gateway (the receiver). The proposed protocol selects a valid authentication period and adapts the token technique according to the dynamic features of the IoT device such as remaining battery of the IoT device for enhanced security. Later, the IoT gateway checks whether the received data from the IoT device is generated in the authentication period or not. In addition, the IoT gateway verifies the Message‐Digest 5 (MD5) value for integrity purposes. If all parameters are correct, then the IoT gateway sends an acknowledgement message to the IoT device [14].
In [15], a lightweight authentication scheme for eHealth application has been proposed that authenticates each object and establishes a secure channel between IoT devices and IoT gateway. HMAC ensures the integrity of communications. The proposed scheme has three phases: registration, authentication, and key establishment. Initially, a device is registered in the registration phase. In the authentication phase, mutual authentication is performed between an IoT device and IoT gateway. The IoT device generates a random value and sends a message to the IoT gateway consisting of generated value, masked identity and HMAC code. Upon receiving the message, the IoT gateway verifies the content with an associated HMAC. If verification is successful, then the IoT gateway generates a random value, and sends the message consisting of received value, generated random value and HMAC code to the IoT device. Upon receiving the message, an IoT device verifies its integrity with a supplied HMAC code; and if verification is successful then mutual authentication is carried out. After successful mutual authentication, a shared symmetric key is established for securing the communication channel. At the end, an encrypted message with a session key is sent to the IoT gateway to indicate the termination of key establishment process.
To improve the standard of life for elderly people, recently Ambient Assisted Living (AAL) systems are deployed as IoT applications. In order to protect sensitive health data generated by AAL and to establish a secure communication between medical devices and remote hosts, a proxy‐based authentication with key establishment protocol has been proposed in [16]. In the proposed proxy‐based approach, the resource constrained IoT medical devices, delegates the costly computational cryptographic operations to computationally rich devices located in the neighborhood of the medical sensor. The IoT sensor sends a request message (that contains identity of the source) to the responder. Upon receiving the request, the nearby computationally rich device (responder) checks the source (IoT device) of the message. If all preceding checks are successful, the key establishment session will be initiated, and data will be exchanged securely via the proxy over the TLS or IPSec (Internet Protocol Security).
To provide a secure authentication mechanism between the server and the IoT device, in [17], a multi‐key (multi‐password) based mutual authentication method has been proposed, as single password‐based authentication mechanisms are vulnerable against side‐channels and dictionary attacks. In this mechanism, the key is changed after every successful session between the server and the IoT device. The secure vault, which is a secret between the server and IoT device, is a collection of equal‐sized keys. In this study, a three‐way mutual authentication scheme is used; an IoT device sends a connection request to IoT gateway. Upon receiving the request, the IoT gateway sends a challenge to an IoT device; Upon receiving the challenge, the IoT device responds to the challenge from the IoT gateway and sends back an authentication challenge. If the IoT gateway verifies that the reply from the IoT device is valid, the IoT gateway responds to the challenge from the IoT device. This completes the three‐way mutual authentication phase, and a session key will be produced to encrypt the exchanged communication between the IoT device and IoT gateway. Upon termination of a session, the session key will expire and later will be regenerated based on a three‐way mutual authentication handshake process.
And finally, OAuth2 is a token‐based authentication; where the user logs into a system and the system requests authentication in the form of a token. The user forwards the request from system to the authentication server, where the request is either rejected or accepted. If the request is allowed, the authentication server provides the token to the user and then to the requester [18].
Figure 12.4 Remote patient monitoring system.
12.4 Remote Patient Monitoring Security
The following figure illustrates the overview of security features of the remote patient monitoring platform (Figure 12.4).
12.4.1 Mobile Application Security
The mobile application (gateway service and Patient App) is secured through standard security features, namely using full disk encryption and screen lock. A different default PIN code is set for each patient and securely communicated to that patient (e.g. via text message to a personal phone or in a sealed envelope). The patient may change the PIN code to a more suitable one. Instructions must be provided to the patient on choosing a secure PIN code. The patient may also use fingerprint authentication to open the screen lock, if the phone supports it. Security credentials must be provided to the device the mobile application is running on before the device is given to the patient.
The mobile application includes a configuration user interface that is password protected. At the clinician side, the password is hardcoded into the application and only provides weak security; it is meant to prevent the patients from modifying the configuration, not to withstand a skilled attacker. It could easily be retrieved by rooting the device and decompiling the application. The cloud must treat all settings of the configuration UI as untrusted.
The application is also protected with DexGuard to protect it against modification and to detect if the patient (or someone else) roots the device. Use of DexGuard will also somewhat increase the security of configuration UI password, but not enough to trust the configuration data entered through it.
12.4.2 Communication Security
Sensor data transmitted from sensors to the patient's phone are protected by standard Bluetooth or Bluetooth Low Energy (BLE) (depending on sensor) encryption. The phones are pre‐paired with the sensors.
All other communications are secured through use of TLS. A server‐side TLS certificate is always used. A client‐side TLS certificate is always used for the mobile application and for cloud management related HyperText Transfer Protocol (HTTP) connections. For the Clinician App, a TLS client certificate can be used if one can be installed on the devices used by the clinicians. If two‐factor authentication is used for clinicians, a TLS client certificate is not required. Clinician App related connections without TLS client certificate or two‐factor authentication are only accepted if they originate from the hospital network.
Administrator connections to the cloud must use two‐factor authentication. This is enforced by a bastion host through which all administration connections must be routed.
Connections between cloud servers are secured through Docker Swarm, which establishes an encrypted overlay network between the containers it orchestrates.
The ID (name) of the TLS client certificate ID used by the mobile gateway application must be unique for the device, and it should be the same as the device ID of the device the mobile application is running on. The client certificate ID is used by the cloud to determine the patient ID for the data uploaded by the device, based on the patient currently assigned to that device.
12.4.3 Data Integrity
Patient‐specific credentials for creating digital signatures are provisioned to the gateway during patient provisioning. The data collected by the gateway is digitally signed using these credentials. If built‐in full‐disk encryption cannot be used in the mobile phone, then the collected data must also be encrypted using a public key for which the corresponding private key is only available to the cloud. This guarantees that the encrypted data is safe, even if the phone is stolen and rooted.
Upon receiving data, the cloud must verify that the digital signature of the data was created by the patient to whom the device is currently allocated to. This verification prevents errors in patient allocation logic caused by data being allocated to the wrong patient. The signature and data must be retained by the cloud to make it possible to verify, at a later date, that all the data the cloud has stored or generated, based on that uploaded data, is valid.
12.4.4 Cloud Security
The two central security components are the perimeter server and authentication server. The perimeter server is a hardened server that faces the internet on one side and the cloud internal network on the other. It verifies validity of client certificates, terminates TLS connections, and sends authentication requests for authenticating incoming Representational State Transfer (REST) requests. The authentication server validates username and password credentials, grants OAuth2 access tokens based on them, and handles access token authentication requests from the perimeter server.
The authentication server will also verify two‐factor authentication. If TLS client certificates are used as two‐factor authentication, this means verifying that the clinician TLS client certificate matches the clinician username (for username and password credential) or the device from where an access token was originally requested (for access token credential). For mobile applications, the authentication server will map TLS client certificates to patient IDs.
12.4.5 Audit Logs
Access logs are generated when any of the REST services are used, or when data is uploaded. The access logs are stored securely on a separate server with its own set of access credentials. Additionally, on the patient side, a request identifier is generated for all incoming requests, and that identifier is added to all related requests and logs. If a service uses other services to fulfill the original request, the request identifier can be used to keep track of all logs related to an original request.
12.4.6 Intrusion Detection Module
In addition to a traditional intrusion detection system, the system also uses an experimental Hybrid Anomaly Detection Model (HADM) for intrusion detection. In HADM, different linear and learning algorithms are combined in a wide range to investigate a hybrid model for achieving high‐detection performance and yet relatively low detection time, and will be deployed to detect intrusion attempts on IoT devices. In principle, it would be possible to use the data‐mining mechanisms to detect different types of attacks such as corrupting and tampering data, platform configuration corruption or overloading it. In general, attacks on a remote patient monitoring platform include any kinds of malicious behaviors that cause unavailability or degradation of services, or stealing and corrupting patient information. A concrete example is the Denial of Service (DoS) attack on eHealth platform through a burst of signaling messages.
In order to secure a remote patient monitoring platform, HADM is introduced to detect and prevent previously mentioned attacks. The platform uses a combination of linear and learning algorithms combined with protocol analyzer as shown in Figure 12.5. The linear algorithms filter and extract distinctive attributes and features of the cyber‐attacks while the learning algorithms use these attributes and features to identify new types of cyber‐attacks [19].
Figure 12.5 Hybrid anomaly detection model (HADM).
As is shown in Figure 12.6, the HADM functionality is divided into three phases: protocol analyzer, dynamic machine learning and validator and database.
Figure 12.6 HADM on operational level in brief.
12.4.6.1 Protocol Analyzer
The first phase of the proposed HADM is called the protocol analyzer which filters vulnerable protocols. The protocol refers to communication protocol over which the traffic is carried on such as HTTP and Transmission Control Protocol (TCP). As is shown in Figure 12.7, a protocol analyzer consists of five modules.
- i. Decision module
This module includes a list of vulnerable protocols which are predefined and also dynamically updated based on the received feedback from log files via the database. Some protocols such as HTTP and TCP are well‐known vulnerable protocols while others like Real Time Streaming Protocol (RTSP) could be a safe protocol. RTSP checks whether traffic is carried on any of the listed vulnerable protocol.
- ii. Counter and Prioritization module
The function of this module is based on the occurrence threshold (n) and prioritization. It means that if the vulnerable protocol carries suspected traffic for n times, then this module will forward the suspicious traffic to the next layer for detection and labeling. The idea is to cycle all possible vulnerable protocols over an agreed time window (one hour, one day, etc.). The module only keeps a certain number of vulnerable protocols in the list which is based on prioritization. For example, if we already have 20 vulnerable protocols and a 21st comes up, then the counter must prioritize only 20 of these protocols. The prioritization is based on the counting occurrence over the time window. The sole purpose of this technique is to reduce the computation load of traffic analysis.
- iii. Feature Extraction
This extracts the best features from the suspicious protocol. This module is utilized in second phase as well.
- iv. Learning Algorithm I
If the protocol (that carries the input traffic) is not listed as vulnerable, traffic is still sent to this learning algorithm for analysis and reconfirmation. The learning algorithm I will check whether the protocol is vulnerable or not. Our proposed platform is tested with Extreme Learning Machines (ELM), Self‐Organizing Map (SOM) and MultiLayer Perceptron (MLP) algorithms.
- v. Log file
Every time the learning algorithm I in the protocol analyzer detects a new vulnerable protocol, it is recorded into the log file and feedback will be sent to the decision module via a database. The log file records packet features such as time stamp, packet size, Internet Protocol (IP) header and information on other layers (Ethernet, TCP, application layer).
Figure 12.7 Protocol analyzer.
12.4.6.2 Dynamic Machine Learning
The second phase of the proposed HADM combines linear and learning algorithms for efficient attack detection. As is illustrated in Figure 12.8, dynamic machine learning consists of the following modules, in addition to feature extraction, that was explained earlier.
- i. Linear Algorithm I
This module analyzes User Datagram Protocol (UDP) traffic to detect UDP DoS attacks. Therefore, a separate algorithm such as a Decision Tree (DT) is considered for this module in order to avoid overloading the rest of the proposed hybrid model. However, the decision‐tree algorithm can be replaced based on the operator demand, we have considered it because of its low processing time.
- ii. Rule Extractor and Deduplicator
This module filters the known attacks that the system is already protected against, by using other deployed security mechanisms and forwards other attacks to learning algorithm II for labeling. A set of rules are extracted from those deployed security mechanisms in the network, the extracted information is compared with received attacks from linear algorithm I and is dropped if it is similar. Rules in this module are updated dynamically, based on input from the parallel security mechanisms.
- iii. Learning Algorithm II
This module is the last detection layer. Initial features and clusters are defined for the algorithm during the training process in order to cluster different attacks such as Botnet attack (B) and Malicious codes (M). At first, the traffic is labeled to one of the clusters based on their similarity or distance. As the traffic that arrives to this module has been already identified as an attack, if it does not belong to any of the mentioned clusters then it is considered as new type of attack (N) and a cluster will be created for it. The features of the new type of attack (N) must be added to the algorithm accordingly. The implementation of the proposed platform with Artificial Neural Networks (ANNs) and Genetic Algorithm (GA) is already ongoing by authors and results will be presented in a future paper. Other potential unsupervised algorithms can be SOM and hierarchical clustering.
Figure 12.8 Dynamic machine learning.
12.4.6.3 Validator and Database
The last phase of the proposed HADM validates detected attacks, stores them into the database and shares the updates to all relevant modules. It consists of the following modules as shown in Figure 12.9.
Figure 12.9 Validator and database.
The validator acts similarly to the error detection module in order to decrease False Positive (FP) and False Negative (FN) rates. If the actual result differs from the expected result, then the result is considered as error and is not registered in the database (DB). Validator should be always updated with labeled data and output from detection algorithms. The database saves all the results of detection algorithms; from each algorithm, a sample of the outcome (feedback) is sent to the database that will be used in future detection. A database contains known attacks, new attacks and dropped attacks.
12.4.7 Authentication Architecture
There are multiple types of authentication being used:
- i. Browser Authentication without TLS Client Certificates
This authentication mechanism is used for browser connections if a form of two‐factor authentication is used that does not make use of personal TLS client certificates. The validation of two‐factor authentication may require calling an external service.
- ii. Browser Authentication with Personal TLS Client Certificates
This form of authentication is used if personal TLS client certificates are used for two‐factor authentication.
- iii. Device Authentication
This form of authentication is used for connections from the Patient App. Patient diary upload is authenticated in the same way but uses a different cloud endpoint and does not use Kafka.
12.4.7.1 Authentication Logic
Table 12.1 describes the authentication logic in more detail. Note that a specific method for implementing the validation is not mandated. One possibility is that the OAuth2 token is simply a random string and the authentication server keeps a database of valid and recently expired tokens. A token can then be validated with a simple database lookup. A session timeout can then be easily implemented with a last‐access timestamp; if the timestamp is too old, the token is invalid.
Table 12.1 Authentication logic.
| Request type | Credentials included | Auth server validation logic | Additional validation | Side effects | Return value from Auth server |
| Login request from browser |
|
|
Perimeter server verifies request is originating from hospital network or has valid TLS client certificate |
|
OAuth2 access token (one day validity period) |
| Web page request from browser | None (static web pages do not contain confidential material) | None | Perimeter server verifies request is originating from hospital network or has valid TLS client certificate |
|
None |
| REST API request from browser |
|
|
Perimeter server verifies request is originating from hospital network or has valid TLS client certificate |
|
Internal token to specify the access rights according to request and security policy |
| Data upload request from patient app |
|
|
|
|
Internal token corresponding to the patient user ID or patient ID |
| Authorization request from a microservice |
|
|
TLS client certificate is valid |
|
User or patient details for the token if requesting microservice is entitled to them |
If TLS‐client certificates are used for clinician web app, then browser connections lacking a TLS‐client certificate are rejected unless they are originate from the hospital network. In addition to the above, data encryption at rest is used in the cloud.
12.4.8 Attacks on Remote Patient Monitoring Platform
Table 12.2 shows some of the potential attacks, their impact on the platform and their detection method, if applicable.
Table 12.2 Attacks on remote patient monitoring platform.
| Description | Impact | Controls |
| Attacker tap into connection between sensor and mobile app |
|
|
| Attacker access to device |
|
|
| Patient fakes data by generating ECG pulses via heart rate simulator or puts device on someone else |
|
|
| Attack on mobile network |
|
|
| Illegally create “app” that device thinks is a legal app |
|
|
| Update, reset or clear patient id |
|
|
| Listen link between device and app |
|
|
| Fake or change own user ID or authorization to either app or device |
|
|
| Buffer overflow or other vulnerability to change the SW inside device |
|
|
| Fake cloud, make the device to connect to a malicious server |
|
|
| Eavesdrop the device – cloud connection |
|
|
| TLS misconfigured or broken |
|
|
| Malware attack on system or admin devices |
|
|
| Denial of service attacks on perimeter and other server in unsecure hospital environment servers |
|
|
12.5 Conclusion
Replacing traditional health systems with digital health has gained global attention due to the numerous advantages for both patients and healthcare providers. Digital health reduces healthcare costs because there are fewer hospital visits for patients and home visits by nurses. It also provides patients with easy access to physicians and health centers; remote monitoring involves patients in their care plan, treatment, and self‐testing via medical devices provided to them; they are more informed about their disease risk factors, their treatment progress and care plan. Remote patient monitoring also helps physicians to improve the diagnosis via continuous monitoring and for critical diseases such as stroke that require immediate detection.
In this chapter, we briefly reviewed the challenges that patient and care providers have for chronic disease in a traditional healthcare system. To overcome some of the aforementioned challenges, we introduced a remote patient monitoring platform that consists of three main parts: patient monitoring devices, cloud backend and hospitals' clinician application. The system has been implemented as a pilot project and in joint research with neurological and cardiology departments of Helsinki University Hospital (HUS). The pilot was conducted in the Uusimaa region of Finland with approximately 30 patients monitored at the same time. The duration of the pilot was three months but from an individual patient point of view it could also be shorter (approx. one week minimum, but typically might be from two weeks up to one month). The technical target of the pilot was to provide remote vital signs monitoring and patient engagement for those in post‐acute stroke phase and with minimal setup or intervention required from medical personnel. This efficient and continued monitoring led to medication adjustments in 40% of the patients.
The outcome of the pilot project is summarized in Figure 12.10.
Figure 12.10 Results from pilot project.
And finally, we introduced some techniques to protect the proposed platform against attacks. While the majority of related studies discuss sole methods for eHealth security, our proposed digital health platform not only introduces a novel intelligent architecture to guarantee the platform and patient data security against the intrusions, but it also applies a combination of different authentication methods to protect the system from unauthorized access. The HADM applies several machine learning algorithms together with a traffic‐filtering mechanism to detect anomalies on control planes such as DoS or an attack on administrative interfaces; also, to detect attacks on the user plane such as corrupting patient data (ECG and BP) and stealing patient data, etc.
References
- 1 Global health care sector outlook. (2017). Deloitte. https://www2.deloitte.com/content/dam/Deloitte/global/Documents/Life-Sciences-Health-Care/gx-lshc-2017-health-care-outlook-infographic.pdf (accessed 16 July 2019).
- 2 Global health care outlook. (2018). Deloitte. https://www2.deloitte.com/content/dam/Deloitte/global/Documents/Life-Sciences-Health-Care/gx-lshc-hc-outlook-2018.pdf (accessed 16 July 2019).
- 3 Hankey, G.J. (2013). The global and regional burden of stroke. The Lancet Global Health 1 (5): 239–240.
- 4 AVH in Figures. (2013). Association of brain diseases in Finland. https://www.aivoliitto.fi/files/1091/avh_lukuina2013_web.pdf (accessed 16 July 2019).
- 5 Ijäs, P. and Honkanen, M. (2017). Teknologia tehokkaaseen käyttöön: Stroke remote care ‐projekti HUS:n neurologisella osastolla, Aivosairaudet‐symposium.https://www.slideshare.net/MauriHonkanen/teknologia-tehokkaaseen-kyttn-stroke-remote-care-projekti-husn-neurologisella-osastolla (accessed 16 July 2019).
- 6 Saleem, K., Tan, Z., and Buchanan, W. (2017). Security for cyber‐physical systems in healthcare. In: Health 4.0: How Virtualization and Big Data Are Revolutionizing Healthcare (eds. C. Thuemmler and C. Bai), 233–251. Springer.
- 7 He, W., Golla, M., Padhi, R. et al. (2018). Rethinking access control and authentication for the home internet of things (IoT). In: 27th USENIX Security Symposium. Baltimore, USA (15–17 August 2018): USENIX.
- 8 Chahid, I. and Marzouk, A. (2017). A secure IoT data integration in cloud storage systems using ABAC control policy. International Journal of Advanced Engineering Research and Science 4 (8): 34–37.
- 9 Maksimović, M. and Vujović, V. (2017). Internet of things based E‐health systems: ideas, expectations and concerns. In: Handbook of Large‐Scale Distributed Computing in Smart Healthcare (eds. S.U. Khan, A.Y. Zomaya and A.M. Abbas), 241–280. Springer.
- 10 Miller, L. (2016). Choosing the right IoT solutions. In: IoT Security for Dummies, INSIDE Secure Edition (ed. L. Miller), 27–37. Wiley.
- 11 Neto, A.L.M., Souza, A.L.F., Cunha, I. et al. (2016). AoT: authentication and access control for the entire IoT device life‐cycle. In: Proceedings of the 14th ACM Conference on Embedded Network Sensor Systems (SenSys). Stanford, USA (14–16 November 2016): ACM.
- 12 Manzoor, A. (2016). Securing device connectivity in the industrial internet of things (IoT). In: Connectivity Frameworks for Smart Devices the Internet of Things from a Distributed Computing Perspective (ed. M. Zaigham), 3–22. Springer.
- 13 Dabbagh, Y.S. and Saad, W. (2018). Authentication of Everything in the Internet of Things: Learning and Environmental Effects. http://arxiv.org/abs/1805.00969 (accessed 17 July 2019).
- 14 Chuang, Y., Lo, N., Yang, C., and Tang, S. (2018). A lightweight continuous authentication protocol for the internet of things. Sensors 18 (4): 1104.
- 15 Khemissa, H. and Tandjaoui, D. (2015). A lightweight authentication scheme for E‐health applications in the context of internet of things. In: 9th International Conference on Next Generation Mobile Applications, Services and Technologies, Cambridge, UK (9–11 September 2015). Cambridge, UK: IEEE.
- 16 Porambage, P., Braeken, A., Gurtov, A. et al. (2015). Secure end‐to‐end communication for constrained devices in IoT‐enabled ambient assisted living systems. In: IEEE 2nd World Forum on Internet of Things (WF‐IoT), Milan, Italy (14–16 December). Milan, Italy: IEEE.
- 17 Shah, T. and Venkatesan, S. (2018). Authentication of IoT device and IoT server using secure vaults. In: 17th IEEE International Conference on Trust, Security and Privacy in Computing and Communications/12th IEEE International Conference on Big Data Science and Engineering (TrustCom/BigDataSE), New York, USA (1–3 August 2018). New York, NY: IEEE.
- 18 OAuth, 3 Common Methods of API Authentication Explained. Nordic APIs. https://nordicapis.com/3-common-methods-api-authentication-explained (accessed 17 July 2019).
- 19 Monshizadeh, M., Khatri, V., Atli, B., and Kantola, R. (2018). An intelligent defense and filtration platform for network traffic. In: IFIP 16th International Conference on Wired/Wireless Internet Communications (WWIC), Boston, USA (18–20 June 2018). Boston: Springer.