## 5 Results and Discussion  
The system is developed using the principle of security by design so that the security mechanisms and aspects are not added later, but incorporated during the system development process. As a result, the system interacts and engages securely between the IoMT client, the IoMT server, and the web server. The system communicates securely, the integrity of the data is preserved, there is strong authentication and access control, accounting and logging of every exception and error are conducted for incident response and recovery, client system recovery after network failure is provided, and a secure network design is incorporated to protect the system from DoS and DDoS attacks. The following is a discussion of the security features incorporated into the IoMT system. 1. Data confidentiality: It is crucial to maintain data confidentiality since it deals with health and/or well-being-related data. The proposed system interacts and engages with the client node and the IoMT server using an AES session key, which is generated and provided by the server to the IoMT client. The session key is securely delivered using RSA public key cryptography, and the key is signed to guarantee the source of the generation and maintain the integrity of the information. The client and the server are both capable of generating keys. To maintain freshness and preserve security, the session keys are generated for every new connection and each session. Table 2 provides the security method's overhead in terms of time of execution, and these results are tested using the IoMT client (Raspberry Pi 4) with the following configuration: Broadcom BCM2711 SoC with a 1.8 GHz, 64-bit quad-core ARM Cortex-A72 processor with 4 GB RAM, and the IoMT server executing with 64-bit, Intel Core i7, CPU @2.6 GHz with 32 GB RAM. The system is tested with various  
Figure 8: User authorisation process. Figure 9: Connection establishment, identification, and authentication. key sizes (standard and above) to select the best key sizes for performing real-time communication. The results of Table 2 are average values of executing over 10 rounds for each key size. The key generation and the key file generation take exponentially more time as the key size increases. The AES key generation time, encryption time, and decryption time take only a few milliseconds irrespective of the key sizes (128 bits, 192 bits, or 256 bits), while the RSA takes a little less than a second only for key sizes below 2048 bits for key generation, but takes some seconds to minutes for key sizes of RSA 4096 and above. However, the RSA method of encryption takes from around 0.01 s to 0.07 s when the key size increases from RSA 1024 bits to RSA 8192 bits. On average, the decryption time takes more than the encryption time. To meet the real-time requirement of interaction between the client and the server, the best option is the use of the AES encryption method while the secure session key transfer is conducted by RSA. To meet real-time requirements, this paper uses RSA 2048, AES 256, and SHA 256. * Data Integrity: All data generated by the IoMT client are signed, and the integrity of the data is preserved using SHA 256 along with the privacy of the sender to avoid any form of non-repudiation attack. Creating a digital signature of the IoMT data takes 0.0011 s to 1.03 s when the RSA 1024-bit key and RSA 8192-bit key are used, respectively. As expected, as the key size increases, the digital verification takes longer, but it is more linear and not exponential. Since this paper uses an RSA 2048-bit key, it takes 0.04 s for signing and 0.0008 s for the verification, which is ideal for real-time communication.