Integration of Cloud-Based Central Telemedicine System and IoT Device Networks

Abstract

The growing challenges in healthcare services, such as hospital congestion and a persistent shortage of medical personnel, significantly impede effective service delivery. This particularly presents significant challenges for the continuous monitoring of patients with chronic diseases. In comparison, Internet of Things (IoT) based telemonitoring systems offer a promising solution to alleviate these challenges. However, transmitting sensitive and confidential patient health data requires a strong focus on end-to-end security. This includes securing sensitive data within the patient’s home network, during internet transmission, at the endpoint system, and managing sensitive data. In this study, we propose a secure and scalable architecture for a remote health monitoring system that integrates telemedicine technology with the IoT. The proposed solution included a portable remote health monitoring device, an IoT Gateway appliance (IoT GW) in the patient’s home, and an IoT Application Gateway Endpoint (App GW Endpoint) on a cloud infrastructure. A secure communication channel was established by implementing a multi-layered security protocol stack that uses HTTPS over Quick UDP Internet Connection (QUIC), with a focus on optimal security and compatibility, prioritizing cipher suites for data confidentiality and device authentication. The cloud architecture is designed based on the Well-Architected Framework principles to ensure security, high availability, and scalability. Our study shows that storing patient health information is reliable and efficient. Furthermore, the results for processing and transmission times clearly demonstrate that the additional encryption mechanisms have a negligible effect on data transmission latency, while significantly improving security.

1. Introduction

From healthcare service challenges such as hospital congestion that impairs service delivery and medical personnel shortages, which affect not only hospitals but also chronic disease patients who require regular monitoring, including those with hypertension, diabetes, or heart disease. Medical personnel usually schedule regular follow-up appointments to monitor these conditions because medication dosages must be adjusted based on current symptoms, which require patients to travel to hospitals. The IoT is a transformative technology in healthcare, especially in telemedicine, by connecting medical devices and sensors to the internet for remote patient monitoring [1]. The combination of telemedicine technology and the IoT to create remote health monitoring innovations (tele-monitoring) by healthcare providers is now possible without requiring in-person visits, a development that has significantly changed the way healthcare services are delivered [2]. This technology can reduce waiting times, reduce travel requirements, reduce infection exposure risks, reduce medical personnel workload, and alleviate hospital congestion. The key advantages of IoT in telemedicine are its capacity for continuous 24/7 monitoring of patients, which in turn prevents avoidable hospitalizations and decreases the associated expenses and effort [3].

The IoT is comprised of smart devices and sensors that gather personal health metrics via internet connectivity [4], with the Internet of Medical Things (IoMT) developing as a specific application centered on medical care and telemedicine systems [5]. Therefore, medical staff can monitor patients’ health parameters through these developed devices that patients can use independently at home, including blood cholesterol measurements, pulse, blood oxygen levels, and body temperature. The blood pressure sensors can also be used for remote monitoring systems to track a vital sign that is essential for evaluating cardiovascular health [6]. Moreover, sensors constantly collect vital information such as electrocardiograms (ECG), electroencephalograms (EEG), body temperature, and blood glucose levels, which are then transmitted to handheld devices via edge routers [7]. In addition, several systems employ sensors to monitor levels of hemoglobin, glucose, white blood cells, urea nitrogen, and protein percentages [8].

Biomedical sensors send vital sign data to microcontrollers such as Arduino, ESP32, MSP432, or Raspberry Pi for processing [9]. Processed data is subsequently transmitted wirelessly to gateways that enable internet access. In several systems, smartphones often act as gateways connecting sensor networks to cloud-based platforms [10]. Gateway devices establish connections to the internet via WiFi, mobile networks, or other communication technologies to transmit data to cloud platforms [11]. Cloud transmission protocols use communication protocols like Message Queuing Telemetry Transport (MQTT) to guarantee reliable and efficient data exchange between IoT devices and cloud platforms [12].

However, integrating IoT and IoMT technologies into healthcare and telemedicine systems has resulted in complex digital ecosystems with significant security and privacy challenges. This study [13] aims to address the implications of data fusion in IoMT, increase privacy and security concerns about IoMT sleep trackers, and provide insight into how precise mechanisms or approaches can be used to prevent or mitigate such adversarial attempts. As a result, security has emerged as the most serious challenge that must be addressed with increasing IoT device usage in healthcare systems [14]. The inherent vulnerability of IoT systems comes from their use of traditional networks to wirelessly connect almost any device, making them vulnerable to attackers and manipulation. Moreover, large-scale deployment of remote healthcare IoMT devices presents multiple interconnected challenges beyond security, including extensive data management requirements, privacy concerns, system upgrades, scalability issues, energy consumption, latency problems, and interoperability concerns [15].

To meet our objectives, we proposed a secure solution for cloud-based telemedicine architecture, which includes the following contributions:

• Designed a cloud-based telemedicine architecture with an IoT GW for home health monitoring devices (IoT devices) and an App GW Endpoint for the central cloud telemedicine system.
• Implemented communication security mechanisms (encryption and authentication) to protect sensitive patient health data transmitted between the IoT GW and the central cloud telemedicine system.
• Analyzed IoT GW monitoring capabilities by examining system and network traffic logs.
• Provided practical guidelines for integrating IoT devices, cloud, and security mechanisms in patient health monitoring scenarios.

The rest of the paper is structured as follows. Section 2 reviews the cryptography-related literature for securing communication channels and the role of cloud computing in telemedicine systems. The proposed solution is detailed and described in Section 3. The end-to-end latency of the solution is subsequently assessed in Section 4. The paper concludes in Section 5.

2. Related Works

Telemedicine provides medical care to patients remotely, with patients and healthcare providers frequently located in different locations. This process frequently involves the transmission of confidential patient information, such as medical images, over the Internet or cellular networks, which presents new security and privacy challenges. The paper [16] introduces a lightweight, chaos-based encryption method that is particularly suited for safeguarding medical images, which are susceptible to compromise both during transmission and storage. The proposed cryptosystem functions according to the principles of a symmetric key algorithm. Storing this type of sensitive data in cloud storage systems increases the risk of cyber attacks, particularly if the systems do not meet current security requirements. This paper [17] also explores the connection between healthcare advancements driven by technology and the necessity for strong cybersecurity measures, investigating emerging trends, AI-based security systems, and cooperative approaches to mitigate escalating threats and safeguard data confidentiality and integrity.

This survey [18] is comprehensive, investigating the various threats and vulnerabilities associated with cryptographic network protocols. Cryptographic network protocols, including Transport Layer Security (TLS), secure connections by combining asymmetric and symmetric encryption techniques. The initial phase of communication relies on asymmetric cryptography, which employs a pair of keys consisting of a public key and a private key. The primary functions of this mechanism involve authenticating the server’s identity by means of digital signatures and securely enabling the exchange of cryptographic keys using algorithms like Rivest-Shamir-Adleman (RSA) or Diffie-Hellman. Although highly secure, asymmetric encryption is computationally expensive and slow, therefore insufficient for encrypting an entire data session. This approach uses a single, shared session key for both encrypting and decrypting information, offering significantly faster speeds suitable for handling large volumes of data. The critical challenge of symmetric cryptography is how to securely distribute the shared key, which is solved by using the robust asymmetric process to exchange this session key at the beginning of the connection. This hybrid strategy ensures that the connection benefits from the strong authentication and key-exchange security of asymmetric cryptography while leveraging the efficiency of symmetric cryptography for ongoing data transfer, thus creating a robust and practical secure channel.

Encryption is an important part of securing telemedicine services because it ensures data confidentiality and integrity. Key cryptographic algorithms such as Advanced Encryption Standard (AES) and RSA are often implemented in telemedicine to protect e-health data, adapting to various security needs within the medical domain [19]. In addition, Elliptic Curve Cryptography (ECC) provides a more efficient alternative to traditional public-key systems, due to its reduced computational requirements and bandwidth usage, which is especially advantageous in environments with limited resources. Moreover, an end-to-end encryption method is used to secure communications of sensitive data between medical devices, sensors, and healthcare systems on the IoMT ecosystem. The encryption process ensures that data is only accessible to authorized parties, providing strong protection against unauthorized interception and tampering, while also improving system efficiency through lightweight cryptographic algorithms [20]. A proposed hybrid cryptography technique [21] combines ECC and AES for secure data storage and encryption in IoT-based telemedicine applications, addressing the need for secure electronic health record systems. The proposed technique also considers energy availability from solar power to implement the encryption technique, indicating a focus on energy efficiency. In double encryption, this paper [22] introduces a secure cloud-based healthcare system that leverages a Salable and Enhanced Key Aggregate Cryptosystem for data protection and double encryption to guarantee confidentiality, integrity, and scalability in medical data management.

In a detailed comparison, RSA and ECC are popular asymmetric cryptography algorithms that have been extensively compared in IoT scenarios [23]. An algorithm’s security level is measured by the number of operations required to break its trapdoor function. This study [24] shows that ECC is clearly a much more effective alternative to RSA because it provides comparable security levels with significantly shorter key lengths. For a 112-bit security level, RSA needs a 2048-bit key, whereas ECC only needs a 224-bit key. These differences increase at higher security levels. In terms of performance, ECC generally consumes less energy than RSA. Client-side power consumption for ECC is 15–20% lower than for RSA [24]. The difference is less dramatic on the client side because RSA’s signing and verifying operations are asymmetric, while Elliptic Curve Digital Signature Algorithm’s (ECDSA) are almost symmetric. AES is a block cipher used in symmetric cryptography algorithms. Its security relies on the mode of operation and key length. Galois/Counter Mode (GCM) provides message integrity (authentication) using a MAC value based on Counter (CTR) Mode. It retains CTR mode’s parallel computing characteristics, resulting in higher MAC generation efficiency and overall faster encryption/decryption [25]. GCM is recommended for system deployment because it is secure and efficient. Furthermore, because of its parallel nature [25], GCM typically outperforms Counter with CBC-Message Authentication Code (CCM) Mode in terms of efficiency (shorter encryption and decryption times). However, for all AES modes, increasing the length of the secret key increases encryption and decryption times.

In authentication methods for IoT and IoMT devices, authentication represents one of the most critical security challenges in IoMT systems, as these devices must verify user and device identities while operating under severe resource constraints [26]. Password and username pairs are insufficient for the complex security needs of medical environments, necessitating more sophisticated approaches such as biometric credentials, shared keys, and digital certificates. In addition, this research [27] focuses on improving IoT device security by identifying and prioritizing multi-criterial authentication features. It highlights authentication features from the existing literature and evaluates their significance using the COPRAS (Complex Proportional Assessment) method. This study [28] aims to protect IoT devices from security attacks by providing a methodology for identifying, evaluating, and ranking the most important security features. It utilizes a multi-optimization approach, specifically the entropy method for determining criterion weights and the EDAS (Evaluation Based on Distance from Average Solution) method for ranking alternatives.

Implementing IoT and cloud computing into telemedicine systems requires a multi-layered architecture to ensure efficient healthcare delivery. This architecture is typically composed of three key components [29]: the device layer, the Internet-connected gateways layer, and the cloud computing layer. The device layer comprises IoT devices, including wireless medical devices, sensors, and actuators, which collect patient health metrics like heart rate and pulse rate. The cloud computing layer is important for storing, processing, and analyzing data collected by IoT devices. It provides a robust platform for data storage and supports intelligent decision-making processes, which can offer appropriate medical treatments and improve user interaction through a dashboard interface [14].

Many real-world implementations indicate the practical advantages of combining IoT and cloud-based telemedicine systems. However, primary concerns in integrating IoT with telemedicine systems include ensuring the security and privacy of patient data [30]. The sensitive nature of health data requires secure cloud infrastructures and encrypted data-sharing protocols to safeguard against unauthorized access. This survey [31] provides a comprehensive overview of the security landscape in cloud computing, which is defined as the on-demand availability of computing resources without direct management by users. Data leakage is a major threat to confidentiality, while unreliable information distinction and access control put integrity at risk. Availability can be compromised by service interruptions and inefficient recovery processes. Key technological solutions emphasized include the use of encryption to protect data in transit and at rest, as well as the deployment of Intrusion Detection Systems (IDS) to monitor and flag malicious activity.

3. Proposed Solution and System Implementation

The proposed solution was implemented as a prototype physical and cloud-based telemedicine system. The central components of the system were implemented on a cloud platform, a design selected to facilitate services for medical devices used by patients in their own homes. As a result, the overall system’s protocol and architecture were designed with security, scalability, and high availability as their top priorities, in alignment with the principles of the Well-architected framework. The design also prioritizes cost-effectiveness, ensuring the environment closely resembles a practical, commercial-grade deployment.

The architecture is divided into multiple layers, each with its own specific functionality, ensuring scalability, security, and ease of maintenance. The solution includes a comprehensive cloud platform architecture that integrates data from IoT devices that transmit information via an IoT GW. The App GW Endpoint acts as the central entry point for controlling and authenticating. Establishing this controlled access point is a fundamental practice in modern cloud computing and computer networking, as it ensures security, reliability, and efficient resource allocation.

The system of the proposed solution can be explained in three parts: the network structure of the IoT devices, the hardware structure, and the cloud structure. The IoT network infrastructure consists of a Raspberry Pi directly connected to vital signs sensors. In our solution, the portable remote health monitoring device collects users’ vital signs, such as heart rate (ECG Module—AD8232, SparkFun Electronics, Boulder, CO, USA), blood pressure (MPS20N0040D-D, Shenzhen Ruised Technology Co., Ltd., Shenzhen, China), and blood oxygen saturation (MAX30102, Analog Devices, Inc., Wilmington, MA, USA), as explained in Section 3.2. The collected vital signs data is then transmitted to the IoT GW via the patient’s home network, which can be either a wired or a wireless local area network. The IoT GW can connect to the internet via an internet service provider, utilizing either a wired or portable 5G router, based on the patient’s home conditions. The IoT GW communicates with the central cloud system via an Application Gateway. This cloud component is designed for receiving connections from the IoT GW for vital sign measurements as well as from a website, such as one used by doctors to view relevant patient data. However, this paper focuses primarily on vital signs data received from the IoT GW. To prevent external access, connections in the cloud network are made primarily via a private endpoint subnet. For security reasons, each private endpoint subnet is assigned to connect with a specific, specified component. Following the above, the vital signs data is sent to a VM (the App GW Endpoint) via a specific private endpoint subnet.

3.1. Cloud Architecture

Our cloud network design for the development environment is shown in Figure 1, which uses a network Classless Inter-Domain Routing (CIDR) of 10.1.0.0/21. It offers an IP address range of 10.1.0.0 to 10.1.7.255. This has been further divided into multiple subnets, as shown below.

• App subnet: this subnet is assigned to private outbound IP addresses for our App Services. It uses the network CIDR 10.1.0.0/24.
• Database subnet: the cloud network uses this subnet to assign private inbound IP addresses for the private endpoints of our databases. Its Network CIDR is 10.1.1.0/24.
• IoT GW subnet: this subnet handles the private IP addresses for the virtual machines of our App GW Endpoint. The network CIDR for this is 10.2.0.0/24.
• Storage subnet: this is where we assign private inbound IP addresses for the private endpoints of our storage accounts. Its network CIDR is 10.1.3.0/24.
• Private endpoint subnet: the cloud network dedicated this subnet to assign private inbound IP addresses for various private endpoints. It has a network CIDR of 10.1.4.0/24.
• Data and ETL (Extract, Transform, Load) subnet: this subnet is specifically for assigning private outbound IP addresses to our Azure Function Apps. Its network CIDR is 10.1.5.0/24.

Our cloud computing system is composed of multiple components that operate together to ensure secure and efficient operations. This overview covers the key components it operates on:

• Azure virtual network: this is important in establishing our private virtual network, allowing all components to communicate securely.
• Azure network security group: Access Control List (ACL) that controls traffic flow by determining who can enter and exit. We use it to allow access to our virtual machines, specifically through Port 443.
• Azure public IP address: providing the public IP address for our App GW Endpoint. This IP address serves as the connection point for IoT GW coming from the internet into our cloud network.
• Azure virtual machine: this component is servers that provide services for our App GW Endpoint.
• Azure App Service: this is our web applications and API (Application Programming Interface) services.
• Azure Functions App: this component provides event-driven services, including time triggers for ETL processes.
• Azure PostgreSQL database: the primary database is used to store our system’s information.
• Azure storage account: this serves as both Blob storage and data lake storage, storing all our log data and several files.
• Application Gateway: this component provides our API gateway, organized and easily accessible.
• Azure container registry: used to store all the container images for our various applications.

3.2. Hardware Architecture for IoT Devices

The portable remote health monitoring device, shown in Figure 2, developed in this research, is intended to support telemedicine services. The main purpose is to collect vital signs from users, such as heart rate, blood pressure, and blood oxygen saturation. The information is sent to a centralized telemedicine system, where it is monitored and analyzed to support medical consultations. These devices can automatically send health information to a central telemedicine system, helping medical professionals to access the information remotely to provide care over long distances. The system is designed to measure vital signs, process the data, and securely transmit it to the centralized telemedicine system. The development procedure is separated into two major parts. The hardware development part is the process of developing and assembling the required controllers and sensors. A Raspberry Pi 5, with the Bookworm-based Raspberry Pi OS, was used in our hardware development. We developed the program in the software development part that is responsible for collecting and displaying data. Python 3.13 and Qt 6.9, cross-platform graphical user interfaces (GUIs), were used in the program’s development.

Our prototype system’s main controller is a Raspberry Pi 5 (with 8 GB of RAM), as shown in Figure 3. The Raspberry Pi 5 connects to various sensors for measuring and collecting vital signs. The main modules are listed below:

• Raspberry Pi 5: it controls the entire system, from reading sensor data and processing it to displaying the results on a 7-inch LCD touchscreen.
• ECG Module (AD8232): this module measures the electrical signals of the heart (ECG). The AD8232 sensor was selected due to its compact design, integrated features, and proven suitability for biomedical applications. The AD8232 functions as a single-lead ECG front-end. It is specifically designed to amplify, filter, and condition the small electrical signals generated by heart activity. To collect bio-signals from the AD8232 sensor, a Raspberry Pi 5 with 8 GB of RAM was used. The output from the AD8232 is a continuous analog signal. Since the Raspberry Pi 5 lacks native analog input capability, an external analog-to-digital converter (ADC) is required.
• SpO₂ and Heart Rate Module (MAX30102): this module measures blood oxygen saturation (SpO₂) and pulse rate using light-based sensors. The MAX30102 operates based on the principle of photoplethysmography (PPG), a non-invasive optical technique that measures volumetric changes in blood circulation. The sensor collects two vital health parameters: Heart Rate (PR) and SpO₂. The MAX30102 communicates with the Raspberry Pi 5 using the I²C protocol to transfer heart rate and SpO₂ data.
• Blood Pressure Module (MPS20N0040D-D): this module measures pressure within an inflatable cuff and calculates both systolic and diastolic blood pressure. In this research, we designed an electronic blood pressure monitor that uses the MPS20N0040D-D pressure sensor. It works with the oscillometric method, which is commonly used in digital blood pressure monitors. This sensor is affordable and accurate. It can measure pressure changes in the cuff in a range from 0 to 40 kPa (about 0 to 300 mmHg), which makes it suitable for portable use.
• Analog-to-Digital Converter (ADS1115): to convert analog signals from ECG and pressure sensors into digital data. With the ADS1115, the analog output from the AD8232 can be converted into digital data that the Raspberry Pi can efficiently process and analyze.

The portable remote health monitoring device can securely connect to a central telemedicine system using the IoT GW. This connection enables it to transmit health data to the centralized telemedicine system (the cloud). Once uploaded, the data can be accessed via a web application or a mobile app. It can be monitored from any location with an internet connection. The IoT devices send health parameters in the structured format JavaScript Object Notation (JSON). This format makes it simple to upload and manage data to the cloud. JSON data includes patient IDs and names, blood pressure readings (systolic, diastolic, and pulse), oxygen level data (SpO₂ value, heart rate, and raw waveform), and ECG data (heart rate and waveform).

3.3. Secure Communication for the Telemedicine Center System

We describe the components and their interactions. Each portable remote health monitoring device in the patient’s home collects sensor readings and sends them to an IoT gateway. Because IoT devices require secure connections to protect their data and prevent unauthorized attacks, the IoT GW is used as a gateway device for IoT devices. Therefore, the IoT GW runs a Go (Golang) service that ensures IoT GW confidentiality and authentication. The IoT GW service validates and decrypts incoming messages before sending secured messages to the cloud via TLS-protected connections. In the cloud, the App GW Endpoint is hosted on an Azure VM (Standard F4s v2-4 vCPUs, 8 GB) and includes the application gateway, persistent storage access, and logging processes. Key software packages used in development and testing are listed below: Golang 1.23.x; github.com/google/uuid (ID generation), accessed on 1 May 2025; github.com/quic-go/quic-go (QUIC transport), accessed on 1 May 2025; github.com/gin-gonic/gin (HTTP API), accessed on 1 May 2025; and golang.org/x/crypto (cryptographic primitives), accessed on 1 May 2025. As a result, the secure connection could improve the system to increase its robustness. We achieved this by establishing secure connections between the IoT GW and the App GW Endpoint, using HTTPS, QUIC, AES-GCM, and RSA-4096 encryption as shown in Figure 4. These technologies are used for both confidentiality and authentication of the IoT GW.

• Communication between IoT devices and the IoT GW would concern protecting against Man-in-the-Middle attacks; we need to guarantee that IoT devices only communicate to the IoT GW via HTTPS. This is because the IoT devices in this system primarily communicate with the IoT GW using HTTP. We established TLS with ECC-256 (Elliptic Curve Cryptography 256-bit) certificates issued by the IoT GW. We preferred ECC-256 according to its high security and suitability for resource-constrained IoT devices, as it uses a smaller key size than RSA while offering the same level of security. In TLS 1.3 handshake, ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) is always used as a key exchange protocol, which also enables forward secrecy, ensuring ephemeral key exchange mechanisms that generate a new, unique session key for each secure communication session. For communication between IoT devices and the IoT GW, [32] the ECDHE and ECDSA, which are the mechanisms used for authentication and verifying the identity of the IoT GW, are performed. Therefore, the elliptic curve in Equation (1) is defined by the constants a and b, which determine its shape. The symbols used for all equations are as shown in

  Table 1. Table of symbols.

  Symbol	Description
  M	Original message M from the IoT devices
  C	Cyphertext
  IDiot_gw	Identification data of IoT GW
  D	Device Identity
  iot_gw	IoT GW
  gw_end	App GW Endpoint
  k-aes	256-bit AES key
  pk-ep	Ephemeral public key pk-ep–pk-epiot, pk-epiot_gw
  sk-ep	Ephemeral private key sk-ep–sk-epiot, sk-epiot_gw
  pk	ECC Public key pk-pkgw_end, pkiot_gw
  sk	ECC Private key sk–skgw_end, skiot_gw
  pk-rsa	RSA-4096 Public key pk–pk-rsagw_end
  sk-rsa	RSA-4096 Private key sk–sk-rsagw_end
  H(M)	Cryptographic hash function

  . A particular point on the elliptic curve that is the generator point G. The order n of the subgroup generated by the elliptic curve points is a prime number defining the length of the ephemeral private key sk-ep_{iot_gw}. The ephemeral private key sk-ep_{iot_gw} is randomly produced as an integer within the interval from [0 … n − 1]. The ephemeral public key pk-ep_{iot_gw} is calculated as a point on the elliptic curve, resulting from the elliptic curve point multiplication of the ephemeral private key sk-ep_{iot_gw} and the generator point G in Equation (2). The IoT device also generates an ephemeral public key pk-ep_iot and an ephemeral private key sk-ep_iot in Equation (3). The IoT GW and the IoT device then exchange their ephemeral public key, and the pre-master secret (shared secret) will then be calculated in Equation (4).

$$y^2=x^3+ax+b (mod p),$$

(1)

$${pk\mathit{-e}p}_{iot\_gw}={sk\mathit{-ep}}_{iot\_gw}·G$$

(2)

$${pk\mathit{-e}p}_{iot}={sk\mathit{-ep}}_{iot}·G$$

(3)

$${sk\mathit{-ep}}_{iot\_gw}· {pk\mathit{-e}p}_{iot}={sk\mathit{-ep}}_{iot\_gw}·{sk\mathit{-ep}}_{iot}· G={sk\mathit{-ep}}_{iot}·{pk\mathit{-e}p}_{iot\_gw}$$

(4)

Like Equation (4), the private key sk_{iot_gw} is randomly produced as an integer within the interval from [0 … n − 1]. The public key pk_{iot_gw} is calculated as a point on the elliptic curve in Equation (5). In Equation (6), the IoT GW would generate a digital signature using the ECDSA [33] that provides an authentication function. It enables the IoT GW to verify its identity to the IoT devices by showing that it owns the private key that is associated with the public key specified in its SSL/TLS certificate. A certificate data contains information about the IoT GW and the public key pk_{iot_gw}. The IoT GW signs the certificate data with the private key sk_{iot_gw}, and then proves it with the related public key. The signature is the pair (r, s), which is used with the certificate data to provide the signature.

$${pk}_{iot\_gw}={sk}_{iot\_gw}·G$$

(5)

$$signature(r, s)={ECDSA}_{sign}({sk}_{iot\_gw} ,H( {certificate}_{data}\left)\right) ,$$

(6)

In ECDHE and ECDSA, the IoT GW sends its ephemeral ECDH public key along with a curve specification. These parameters must be signed with ECDSA using the private key that corresponds to the public key in the IoT GW certificate. After receiving the certificate, the Equation (7) describes the algorithm that the IoT devices use to verify ECDSA signature takes as input the certificate data, the signature produced from the signing algorithm and the public key pk_{iot_gw}, which corresponds to the IoT GW’s private key sk_{iot_gw}. The IoT devices calculate the hash h in Equation (7), using the same cryptographic hash function employed during the signing process (6). It then calculates the modular multiplicative inverse of s with respect to the curve order n and subsequently uses the hash h and signature component r to compute two scalar values, u1 and u2, in Equation (9). Next, it calculates the curve point (x, y) in Equation (10). If (x, y) = 0, then the signature is invalid. For final validation conditions, the signature is valid if and only if x (mod n) is congruent to the r of the signature in Equation (11). As a result, the IoT device uses ECDHE, which handles the key exchange, to compute the pre-master secret (the shared secret), which they encrypt with the IoT GW’s ECDSA public key and send back to the IoT GW.

$$h=H\left( {certificate}_{data}\right) ,$$

(7)

$$w=s^{-1} \left(mod n\right) ,$$

(8)

$$u1=h·w· \left(mod n\right) , u2=r·w·(mod n) ,$$

(9)

$$(x,y)=u1·G+u2·{pk}_{iot\_gw},$$

(10)

$$r\equiv x (mod n)$$

(11)

2.

The IoT GW subsequently decrypts the pre-master secret to derive the TLS master secret (which is calculated from random string data sent by the IoT device, random data sent by the IoT GW, and the pre-master secret). Both the IoT device and the IoT GW have those three messages; consequently, the master secret should be the same for both. The master secret is then used by the IoT device and IoT GW to generate session keys, which are symmetric cryptographic keys (such as AES-GCM, etc.) that are used to encrypt only one communication session. As a result, IoT devices and IoT GW can generate a session key (AES 256-bit key). Our solution utilizes AES-GCM because it provides both confidentiality (encryption) and integrity (authentication), both of which are required for Authenticated Encryption with Associated Data (AEAD) in TLS 1.3. Let’s simplify Equation (12) by replacing it with a static nonce for clarity. The nonce is then encrypted with an AES 256-bit key, resulting in a keystream from the AES_CTR function. Finally, we use that keystream to perform a bit-wise exclusive OR operation on the original message (plaintext) to generate the cipher text. In addition, AES-GCM requires producing an authentication tag T to ensure data integrity and authentication. This step requires the ciphertext obtained from Equation (12). The GHASH function [34] generates the authentication tag T in Equation (13). Here, ‘H’ is the hash key (which is 128 zero bits encrypted by the cipher algorithm), and ‘A’ is any additional authenticated data (AAD), which is only authenticated and not encrypted. When the receiving end receives the ciphertext C and authentication tag T, they can verify the message’s integrity.

$$C=M ⨁ AES\_CTR(\mathit{k}\mathit{-aes}, nonce)$$

(12)

$$T=\mathit{GHASH}(H, A, C)$$

(13)

The IoT GW has two primary functions, which are providing security to secure data transmission and communicating with the App GW Endpoint in the cloud network. The most essential step before a connection is established for data transmission. The IoT GW needs to authenticate itself to the App GW Endpoint using a device identity, as shown in Figure 5, which is an important security function. This authentication method ensures the identity of the App GW Endpoint by using RSA signatures. It also determines whether the IoT GW is authorized by checking its device identity, which is unique to each IoT GW.

This device identity is generated using the ID of each IoT GW obtained during the initial registration with the central system. It is then encrypted with the RSA 4096-bit private key (asymmetric key) of the App GW Endpoint. In the RSA algorithm, we provide N and d as large integers (e.g., 4096 bits). Meanwhile, e represents the encryption value, which is typically set to 65,537. This provides the App GW Endpoint’s private key sk-rsa_{gw_end} = (d, N) and public key pk-rsa_{gw_end} = (e, N). The App GW Endpoint calculates a hash value from the IoT GW’s ID. It then encrypts this hash value using its RSA 4096-bit private key (an asymmetric key), as shown in Equation (14). The generated device identity is stored in a private database that only the App GW Endpoint has access to, since there is strict access control that prevents data leaks by restricting access to the local devices. Following creation, the device identity is exported from this private database and transmitted to the IoT GW.

$$Sig={\left[H\left(\mathit{ID}\mathit{iot}\mathit{\_gw}\right)\right]}^d mod N$$

(14)

$$H\left(\mathit{ID}\mathit{iot}\mathit{\_gw}\right)={Sig}^e mod N$$

(15)

On the other hand, the App GW Endpoint’s encryption requires asymmetric encryption (RSA-4096) to authenticate the IoT GW’s device Identity (device identity verification) and prevent spoofing. This process begins when the IoT GW sends its device Identity for the first time over a secure channel via HTTPS, as shown in Figure 6. After receiving and verifying the identity, the App GW Endpoint sends a shared key and a nonce to the IoT GW for AES-GCM encryption. Messages from an IoT device will be transmitted by encrypting them with AES-GCM and transmitting them via QUIC over HTTPS to the previously verified App GW Endpoint. This communication, therefore, receives protection by an additional layer of AES-256-GCM-SHA384 encryption (KeyExchange-CertificateKey-Transport Cipher-Integrity), which provides confidentiality, integrity, and authentication in an offering step. All messages are transmitted as if through a secure tunnel, which has been created.

3.

For the IoT GW, another important function is to send data from IoT devices to the App GW Endpoint. This data is encrypted with AES-GCM 256 bits and a randomly generated shared key and Nonce (Number Used Once), both provided by the App GW Endpoint. To prevent replayed attacks, the system changes the shared key and nonce on a regular basis, resulting in increased security by avoiding repeated values. This encrypted data is then sent by QUIC from the IoT GW to the App GW Endpoint. We chose QUIC because it supports TLS 1.3, lowers connection setup latency with 0-RTT handshakes, and enables multiplexing multiple streams within a single TCP/IP session. This QUIC connection is secured with an SSL certificate issued by a certificate authority (such as Let’s Encrypt). Let’s Encrypt is a public certificate authority (CA) that provides standard X.509 certificates that are valid for 90 days. The certificate and its private key (stored at the Application GW Endpoint) are used with a hash function to verify the certificate’s authenticity. After verification, a key exchange uses ECDHE to create a shared secret key. This shared secret key then encrypts the data with AES-256 in Galois/Counter Mode and SHA384. The steps in this cipher suite are similar to how IoT devices and the IoT GW communicate, as shown in Equations (6) and (11).

3.4. Log Management System on Azure Cloud for IoT GW and Application GW Endpoint

We implemented a log management system that meets the system’s requirements for monitoring the devices in IoT GW’s network, as shown in Figure 7. To achieve a modern and flexible log management system, we aim to simplify data management by unifying data storage and processing. The Lakehouse architecture framework is adopted to develop the system, which monitors and tracks IoT device usage and connections. This architecture utilizes a three-tiered data layer framework similar to the Medallion architecture for data landing zones, categorized into bronze (raw ingestion), silver (filtered, augmented), and gold levels. This approach provides more efficient log management, from raw data collection to final processing for analysis. Logs have been collected and separated from mainly two sources: the IoT GW and the App GW Endpoint. Particularly, logs collected at the IoT GW must be transmitted via a secure tunnel. The operational approach of this tunnel is similar to that of the secure tunnel used for message transmission, but it is limited to accepting log data.

To provide a clear explanation, we first consider the operations on the IoT GW side of this log management system. The procedure starts with the collection of logs from IoT devices in the IoT GW’s network connections and activities. These logs capture key parameters such as type, MAC address, IP address, timestamp, operation, and data size, which are initially stored in a temporary buffer on the IoT GW. The logs are then transmitted to the App GW Endpoint via the secure tunnel. This transmission is scheduled to take place once per minute, a parameter selected based on an optimal balance between real-time monitoring expectations and cost efficiency.

On the cloud network side, the log management system concurrently gathers data. The system captures connection logs from the IoT GW to the App GW Endpoint, documenting the source IP address, timestamp, and connection status (OK/NG) as shown in

Table 2. Log parameters capturing.

Data Source	Parameters
IoT Device	Type, MAC address, IP address, timestamp, operation, data size
App GW Endpoint	Appliance ID, IP address, timestamp, operation status, destination URL, data size, note
Establish Connection	Appliance ID, IP address, timestamp, connection status

. The system also generates operation logs for requests to the App Service, which include appliance ID, IP address, timestamp, operation status, destination URL, data size, and a note temporarily stored in a buffer. Every minute, an Azure Functions App collects all logs, including those sent by the IoT GW and those produced at the App GW Endpoint, and then feeds them into the bronze (raw ingestion) data layer.

Log consolidation is also an important function of the log management system, which we implemented based on the previously described three-tiered data layer framework. The bronze layer (raw ingestion) serves as the first storage tier, using Azure Data Lake Storage (DFS) to store raw data in JSON Lines (JSONL) format. At this stage, no data transformations are performed in order to preserve the validity of the original data. In addition to security concerns, access to the data in this layer is restricted to Azure Functions only. The silver layer (filtered and augmented) utilizes Azure Data Lake Storage, a cloud-based service based on a standard ETL process. It takes 30 min to consolidate logs stored in bronze. The extract phase begins the process, which involves reading logs from the bronze layer. The transformation phase then begins, which involves data cleaning, enrichment, and schema standardization to convert the logs to CSV format. Logs are separated into three categories: IoT device log, app gateway log, and establish connection log. In the load phase, the processing results are stored in the silver storage, which then serves as the primary source of data for analytics and machine learning workloads.

The implementation of the gold layer is being left for future development. The primary goal of this layer is to store work related to cybersecurity components and aggregated data processed by analytics or machine learning models. This information is intended for direct use in publications, metrics, and dashboard reports.

4. Results and Discussion

This section provides a detailed evaluation of the proposed solution’s IoT GW device identity verification, encryption, and decryption functions. The IoT GW runs on a Raspberry Pi 5 with 8 GB of RAM, which is the same hardware as the portable remote health monitoring device. The IoT GW connects to an Internet Service Provider (ISP) with 1 Gbps/1 Gbps bandwidth. The App GW Endpoint is hosted in the cloud on an Azure VM (Standard F4s v2 with 4 vCPUs and 8 GB RAM). The results presented in this section are from two important processes. The first is the device identity verification process, which is the case when an IoT GW boots up. The timer starts when the IoT GW sends its device identity to the App GW Endpoint for verification. Once the identity is confirmed, the App GW Endpoint sends a response back to the IoT GW, at which point the timer stops. The second process measures the end-to-end latency between the IoT GW and the App GW Endpoint. During this test, the IoT GW sends a message of approximately 30 KB containing data from its connected IoT devices. The timer starts when the IoT GW encrypts and sends the message and ends when the App GW Endpoint successfully receives and decrypts the message into plaintext.

To implement cryptography to achieve system confidentiality, authentication, and data integrity, the primary consideration revolves around the duration of these cryptographic operations. This is significant due to the fact that the authentication, encryption, and decryption processes take excessive time. The entire system can be impacted significantly. We will discuss more details about these results next.

4.1. Device Identity Verification

The results in terms of computation time for the order of testing of the device identity verification process are presented in Figure 8. We will now discuss the procedure used to assess these results. It all started with the IoT GW. The IoT GW initiates the device identity verification process by sending its device identity, which is encrypted using the App GW Endpoint’s RSA-4096 private key. This full exchange takes place over a secure QUIC connection protected by HTTPS, as shown in Figure 6. After receiving this, the App Gateway Endpoint decrypts the message using its own RSA-4096 public key. The result provides the IoT GW’s device identity, which it then compares to its private database to ensure it’s original.

Let’s examine Figure 8, which presents the results of five device identity verification tests. Figure 8, Figure 9, Figure 10 and Figure 11 shows a box plot with the horizontal solid line representing the median, the dashed line representing the sample mean, and the plotted dots representing individual observations. The device identity verification process was run 10 times within each test, which was conducted two hours apart to measure latency in milliseconds (ms). For these tests, the IoT GW was in Bangkok, Thailand, with the endpoint in Azure’s Southeast Asia region (Singapore). Upon examining the results, it is obvious that tests numbers 4 and 5 had the lowest median latency. However, test number 3 showed the greatest variability and featured the most outliers. This could be due to an unstable network connection between the source and destination. Despite this, all the outcomes remained within an acceptable range (180–260 ms). This is not a significant delay because this operation occurs only when the IoT GW first connects. If the connection fails but the device remains operational, this step does not need to be repeated.

4.2. End-to-End Latency for Secure Communication

We measured the end-to-end latency from an IoT GW in Bangkok to an App GW Endpoint (Azure cloud’s Southeast Asia region). The process was run 10 times within each test using messages approximately 30 KB in size. The data in the message contains physiological measurements for a single subject. The data is structured into three primary categories: blood pressure, SpO₂, and ECG readings. Figure 9’s results include the following main procedures: 1. AES256-GCM encryption, 2. transmission via HTTPS over QUIC, which uses TLS 1.3 symmetric key encryption, and 3. upon receipt, the App GW Endpoint must decrypt the HTTPS symmetric key encryption and then further decrypt it with AES256-GCM. In contrast, Figure 10’s results represent only the network latency, excluding any encryption overhead.

Figure 9 shows end-to-end latency measures that vary between 179 and 195 ms, with the median values consistently falling between 186 and 188 ms for all test sets. While test number 4 had the narrowest data distribution, on the other hand, test number 3 had a slightly wider spread of data. Furthermore, as is typical in real-world network measurements, outliers were present in all test sets. Examining Figure 10, the latency measurements vary between 164 and 180 ms, with a median of 167–171 ms. Test number 3 had the highest median latency and the most significant fluctuation in latency, indicating that its data was widely distributed. Test number 4 demonstrated the least variability and data distribution.

A comparison of the two results indicates a difference of approximately 15–20 ms in end-to-end latency. The discrepancy in performance can be attributed to the processing overhead of encryption and decryption, which involves several procedures that can impact overall latency. The additional security layer cost corresponds to an overhead of approximately 8–12%. This added security layer does not result in a significant increase in system jitter. Consequently, the proposed solution’s improved security is justifiable due to its relatively low and stable overhead, despite the extra measures involved. Moreover, the 30 KB message size from IoT devices does not negatively impact the end-to-end latency to the Central Telemedicine System on the cloud, thereby enabling real-time processing for services that depend on it.

For a more thorough comprehension of performance, we evaluated the impact of increasing the number of IoT GWs that communicate data from IoT devices to the central cloud system. The tests measured both the device identity verification process and the end-to-end latency using symmetric keys. Each test included 20 IoT GWs running simultaneously, and each test was run 10 times.

Figure 11 shows the results of both tests. The mean execution time for device identity verification was around 260 ms, with high jitter and frequent spikes. This is a consequence of concurrent testing, which causes higher tail latency because each IoT GW requires time to complete the verification process. Nonetheless, all 20 IoT GWs were successfully authenticated, and the extra time is still acceptable. On the other hand, the mean end-to-end latency increased by approximately 45% compared to the one IoT GW test. This is because the majority of the IoT GWs are attached to the same network, leading to congestion on the networking devices in the IoT GWs’ network. In addition, each of the 20 IoT GWs established a connection with the App GW Endpoint on the cloud network simultaneously. Despite this, all 20 IoT GWs successfully transmitted all data.

In addition, the App GW Endpoint used a small-scale tier of resources for these tests because the system is still in development and testing. However, once the system moves into production, we would implement a load balancer component along with serial VM scaling, a process that alters the number of VM instances to increase the application’s capacity based on specific requirements.

5. Conclusions

In conclusion, this work directly addresses the pressing healthcare service challenges posed by hospital overcrowding and the ongoing care needs of patients with chronic conditions. A secure and scalable architecture for a remote health monitoring system that integrates telemedicine with the IoT has been proposed and validated. We have prioritized data confidentiality and device authentication by establishing a secure communication channel using a multi-layered security protocol stack that features HTTPS over QUIC. The system’s cloud infrastructure, built in line with the well-architected framework, provides a secure, highly available, and scalable solution.

The results indicate that implementing these robust encryption mechanisms has a negligible impact on data processing and transmission times. This critical finding demonstrates that significant security improvements can be made without sacrificing the performance required for real-time remote monitoring. As a result, this work provides a practical and effective framework for deploying remote health technologies, reducing the strain on healthcare facilities and personnel while improving patient access and quality of care.

In addition to our focus on designing and developing a network infrastructure, various directions could be investigated in future research to improve the system’s practical application. The proposed solution in this paper focuses on implementing a network infrastructure for both IoT devices and the cloud network to enable telemedicine services. A key consideration before the design and development of this research was the implementation of robust cloud and network security. This infrastructure has previously enabled services such as an artificial intelligence system for analyzing chronic diseases, which continues to develop into a system that uses artificial intelligence for predicting preeclampsia risk in pregnant women. This system uses IoT devices to measure vital signs, which allows for identifying risk factors and classifying a patient’s risk level.