# HSM4 SSL: Leveraging HSMs for Enhanced Intra-Domain Security +
## 4 HSM4 SSL Performance  
To perform a valid performance evaluation of the HSM4 SSL architecture where three HSM simulators are deployed, it was compared with _OpenSSL_ version 3.0.11, a benchmarking tool for performing cryptographic operations. _OpenSSL_ is a comprehensive cryptographic software and command-line tool that is well known for its open-source implementation of the TLS protocol. Users and developers can use _OpenSSL_ to perform a wide range of cryptographic functions, such as generating key pairs, CSRs, and more [33]. Note that the sole usage of _OpenSSL_ in sensitive intra-domain environments being to act as a root of trust for certificate signing and generation introduces security risks, as there have been 177 vulnerabilities reported in OpenSSL through the period of 2002 to 2019 [34].  
The experimental setup involved testing on two separate PCs within the same network environment to ensure a consistent and controlled testing framework. The primary machine, acting as the server and used for hosting the HSM4 SSL architecture, had the specifications detailed in Table 2. The secondary machine, responsible for generating certificate requests and performing benchmarks, was equipped to emulate realistic operational conditions. The simulated environment used SoftHSM version 2.6.1, an open-source software implementation of a cryptographic store accessible through a PKCS#11 interface. This setup allowed for the testing of the HSM4 SSL architecture's integration with HSM capabilities and without the need for physical hardware. SoftHSM was configured with the default settings, such as its support for ECC, AES, and RSA for cryptographic algorithms,  
Figure 9: Captured handshake process.  
and non-paged memory was maintained in its enabled state to prioritize security over performance, ensuring that sensitive data were kept out of disk-based swap spaces, thus minimizing the risk of data leakage. Plus, P11-kit integration was enabled, facilitating the interaction of SoftHSM with PKCS#11 modules installed on the system to specify how to allow the user to communicate with the cryptographic tokens. Moreover, SoftHSM uses the Botan cryptographic library by default for its cryptographic operations.  
The network connecting these devices was configured with a bandwidth of 127 MB/s and a latency of 5 ms between the two devices, mimicking intra-domain network conditions that might impact performance metrics.  
As for the software tools, we used the _loadtest_ command line and Node.js module version 8.0.3, which simulates high volumes of traffic to web applications to assess their performance, identify bottlenecks, and understand how they handle various levels of load [35]. It operates in various modes, such as by specifying the requested RPS, the total number of requests to be processed, the total time to send as many requests as the API can handle, or the number of concurrent users. In addition, it provides detailed metrics and reporting, including RPS, mean latency, and error rates. The _loadtest_ tool was used to simulate real-world high traffic levels and interaction with the HSM4 SSL architecture to understand how it scales under stress. Additional tools, such as the _top_ (table of processes), which provides real-time insight into active processes and presents a system information view that includes resource utilization data, and _nload_, which monitors real-time network traffic, were employed to monitor performance metrics beyond what loadtest offers.