Multiprotocol Authentication Device for HPC and Cloud Environments Based on Elliptic Curve Cryptography

: Multifactor authentication is a relevant tool in securing IT infrastructures combining two or more credentials. We can ﬁnd smartcards and hardware tokens to leverage the authentication process, but they have some limitations. Users connect these devices in the client node to log in or request access to services. Alternatively, if an application wants to use these resources, the code has to be amended with bespoke solutions to provide access. Thanks to advances in system-on-chip devices, we can integrate cryptographically robust, low-cost solutions. In this work, we present an autonomous device that allows multifactor authentication in client–server systems in a transparent way, which facilitates its integration in High-Performance Computing (HPC) and cloud systems, through a generic gateway. The proposed electronic token (eToken), based on the system-on-chip ESP32, provides an extra layer of security based on elliptic curve cryptography. Secure communications between elements use Message Queuing Telemetry Transport (MQTT) to facilitate their interconnection. We have evaluated di ﬀ erent types of possible attacks and the impact on communications. The proposed system o ﬀ ers an e ﬃ cient solution to increase security in access to services and systems.


Introduction
Servers and services define authentication schemes to avoid unauthorised access. Accordingly, they are essential elements to implement a secure system. A large number of computer attacks take advantage of vulnerabilities in authentication systems. The Common Vulnerabilities and Exposures (CVE) is an updated and growing list of known security vulnerabilities. In particular, among them are those related to authentication [1]. It is important to implement mechanisms to strengthen and guarantee the authentication of users and systems.
A first approach is to use passwords to control access, but this is insufficient as they may be susceptible to attacks based on dictionaries, social engineering, or access to databases where credentials are stored [2].
Some systems have been proposed to avoid the use of user keys, such as Pico [3], where a secure authentication protocol is established.
Adding additional elements to a password allows an extra security component. Systems with multifactor authentication are often used to improve authentication, ensuring that if the security of an element is compromised, the other one can ensure that access remains secure.
Cryptographic resources such as symmetric and asymmetric encryption, hashing, and public key signing are strong elements for solving mathematical authentication. Besides, it is vital the use of true random number generators. the authorisation server. According to Li et al. [30], real-world implementations of both schemes are often vulnerable to attack, and in particular to cross-site request forgery (CSRF) attacks.
OpenID Connect and OAuth 2.0 do not include a multifactor authentication but an external solution to provide it exists such as SAASSPASS [31], with a mobile app. Also, SecSign [32] provides an extension for two-factor authentication using a mobile phone. However, as it was commented before, users are reluctant to install applications in their phones to access work resources.
Another solution is to combine different elements like single sign-on (SSO) with two-factor authentication and Security Assertion Markup Language (SAML). We can use SAML for exchanging user authentication data as Extensible Markup Language (XML) between identity providers and service providers. SSO is a scheme that uses a single authentication to allow access to multiple applications by passing an authentication token seamlessly to configured applications.
However, at the end, if you need to implement a solution you have to use different layers provided by diverse developers, so it could be critical the compatibility of the different version of each component to get a stable solution. We should avoid using a sledgehammer to crack a nut.
In an HPC environment, we can find a very diverse ecosystem of applications. Not only we have web access to a platform, but also we need to access resources and applications located internally in the cluster, so there is usually no direct access to facilitate authentication on computers and users that are on the private intranet network.
These computing environments are continually growing with new massive data storage systems, computing models such as map/reduce, or new paradigms that arise when trying to tackle complex computing problems that can be more easily solved by new communication models. Many of these systems are based on a user and password scheme as the first level of authentication.
There are specific solutions for Hadoop such as the one proposed by Khalil et al. [33], based on Trusted Platform Module (TPM), but this solution cannot be used in other applications and depends on the TPM installed in each client node, so it locks the user to a specific client node.
In addition, another general problem in multiple protocols is that they do not include a centralised system that can easily control the revocation of communications in real-time. Typically, when client-server communication has been authorised and established, there is no direct way to cancel it. In these cases, different rules can be set at the firewall level, but these require superuser permissions.

Design and Implementation
The proposed system offers a multifactor authentication system that can be used in various configurations; for instance, a basic client/server model, an HPC environment where it is possible to access multiple services and servers, or in a cloud environment taking advantage of various resources such as sending messages or virtualised servers.
Although it could itself be used as a single authentication element, it is recommended to have multiple elements that strengthen authentication due to the increase in the number of cyberattacks. That is why this system is proposed as an additional element of authentication that can work transparently.
This model allows that security can be increased on critical systems with combined authentication, that is, not only authenticating with a user but also with a second user to validate access.
The proposed system allows any application based on TCP/IP (network databases, big data systems, browsers) to use this authentication model. Besides, it supports remote authentication; that is, the user that authorises does not need to be directly connected to the service server. Other systems like U2F are mainly oriented to be used with browsers and session authentication.
This system monitors communications in real-time, keeping a record of active communications, so if necessary, a specific communication can be cut instantly. Additionally, the system can be installed and configured without the need for root privileges, making it easy to deploy the system. It is highly scalable because it is based on the Message Queuing Telemetry Transport (MQTT) model, with diverse broker implementations offering high availability and redundancy. MQTT servers are widely used in IoT infrastructures, and various cloud providers also offer MQTT-based services so they can take advantage of the services they offer.
The gateway server prevents denial of service attacks because the ports are closed and only activated when the request is required.
The protocol is open, allowing the development and implementation of various solutions, with different public/private key models.
Our eToken can verify the context; that is, it can detect which Bluetooth or WiFi resources are closed for the eToken in order to authorise in a valid environment. This operation can be remotely activated by the administrator who can control which resources are valid.
The system separates the authentication service from the system being accessed, as Kerberos does, although in our proposal, we do not need time stamps and the authentication is based on public key algorithms. In general, other authentication systems require direct access from client to authentication servers, but in our scheme, communications go through the MQTT broker, which avoids direct connections facilitating global connectivity among all the elements.
This eToken is based on ESP32 [34], a low-cost device with a 2-core processor at 240 MHz, which has support for cryptographic functions and includes WiFi and Bluetooth communications. This circuit has been used in other ECC-based cipher suites for IoT, such as [35]. Although it has a USB connection, it can work independently and does not need to be connected to USB, so it is ideal for carrying it in a portable way and working with equipment that does not have access to USB ports.
Systems based on smartcards require some type of reader, either contact or recently NFC. The proposed system is independent, so it does not need any additional reader because it uses WiFi connection.
One of the advantages of our system over cryptographic circuits or security keys that cannot update is that if a vulnerability is detected, our system can be reprogrammed and updated. The idea is to have a low-cost open system that can be used for secure authentication, and that can even be extended with the use of cryptographic circuits like ATECC608A [36].

System Overview
The proposed system consists of a set of functional elements configured on physical or virtual resources. The functional elements are: • Users: who access the system; • Services: offered by the programs through TCP connections; • Servers: computers where the services are installed; • Clients: computers from which services are accessed; • eToken: devices that authenticate the request by the user.
All these elements can be gathered into groups to facilitate configuration. We can define some access control list (ACL) rules on these elements. Each item has a 128-bit UUID and a public/private key pair that allows the system to authenticate the requests. Each element generates its keys, so the private key never leaves its environment.
The system is hybrid because each element authenticates other elements using public keys, and is combined with a centralised model that authorises access. Since authorised public keys can be added and removed, the configuration server can send messages for all items, including eTokens, to update the list of authorised items.
There are other additional elements that are: • Configuration server: this allows to modify the configuration of each element remotely; • Authentication server: this authorises the request for access to services based on ACLs; Some of these resources can be implemented on the same node but have been independently designed, allowing a distributed model. These can be separated according to the needs of the implementation. Table 1 shows a comparison between different authentication schemes, including our model.

System Architecture
The proposed system is oriented to be distributed and scalable, allowing the control of elements that can be placed in private infrastructures, cloud environments, or hybrid models. Furthermore, it allows any application to use this authentication scheme. Hence, it acts as a bridge between client and server, avoiding having to modify the original applications and offering a reduced impact on global performances, as described in Section 5.
The communication system is implemented with the following elements: The advantage of a centralised authentication server is that it simplifies the management of access rules and avoids the management of certificate revocation. Furthermore, AS can force the cancellation of the communication instantly, informing the SG that it must close a specific connection.
CRS, AS, GS, and GC are written in Golang. It is a language that allows applications to be portable, fast, robust, and optimised for concurrency in each architecture. Besides, the system can work with containers like Docker. ESP32 code is written in C++, using the PlatformIO toolset [37]. Figure 1 shows how the different elements are interconnected. access rules and avoids the management of certificate revocation. Furthermore, AS can force the cancellation of the communication instantly, informing the SG that it must close a specific connection.
CRS, AS, GS, and GC are written in Golang. It is a language that allows applications to be portable, fast, robust, and optimised for concurrency in each architecture. Besides, the system can work with containers like Docker. ESP32 code is written in C++, using the PlatformIO toolset [37]. Figure 1 shows how the different elements are interconnected.

Algorithms Used
The algorithms we use are mainly based on: one-way hash functions, elliptic curve cryptography, Elliptic Curve Integrated Encryption Scheme (ECIES), and true random number access rules and avoids the management of certificate revocation. Furthermore, AS can force the cancellation of the communication instantly, informing the SG that it must close a specific connection. CRS, AS, GS, and GC are written in Golang. It is a language that allows applications to be portable, fast, robust, and optimised for concurrency in each architecture. Besides, the system can work with containers like Docker. ESP32 code is written in C++, using the PlatformIO toolset [37]. Figure 1 shows how the different elements are interconnected.

Algorithms Used
The algorithms we use are mainly based on: one-way hash functions, elliptic curve cryptography, Elliptic Curve Integrated Encryption Scheme (ECIES), and true random number

Algorithms Used
The algorithms we use are mainly based on: one-way hash functions, elliptic curve cryptography, Elliptic Curve Integrated Encryption Scheme (ECIES), and true random number generators (TRNG). In order not to extend the length of this work, the mathematical base of these algorithms is not included, since it is described in the bibliography here included.

Hash Functions
One-way hash functions are widely used in cryptographic systems [38,39]. They offer a deterministic value for an input sequence. Given an output value, it is computationally impossible to find the original input value. By default, the system uses the SHA-256 hash function that is considered cryptographically robust, but it can work with SHA-384 and SHA-512 as well. According to Lu et al. [40], some implementations of SHA-256 are vulnerable to attacks, so it is recommended to use stronger hash functions. In any case, other secure one-way functions could be implemented and used thanks to the reprogramming capability of the eToken.

Elliptic Curve Cryptography
Public key algorithms grounded on elliptic curve are also frequently used in robust cryptographic communication systems such as Transport Layer Security (TLS) [41]. In particular, the Elliptic Curve Digital Signature Algorithm (ECDSA) [4] is a variant of the Digital Signature Algorithm (DSA) based on elliptic curve cryptography. These algorithms are an appealing alternative that are replacing Rivest, Shamir, and Adleman (RSA)-based systems, in part because smaller key sizes are used in the elliptic curve to provide an equivalent level of security. In symmetric key algorithms, there is a direct correspondence between the level of security and the size of the key used. In contrast, in the asymmetric key algorithms it can change depending on the algorithms used. Table 2 shows a comparison of different key sizes for the RSA and elliptic curve algorithms and their references according to the Espressif IoT Development Framework [42]. One difference between RSA and ECDSA is that RSA allows signing and encryption, while ECDSA only allows signing. Alternatively, elliptic-curve Diffie-Hellman (ECDH) is based on the Diffie-Hellman algorithm [43] using elliptic curve and allows the exchange of a safe value between two elements that can be used later in symmetric encryption between both.
The Standards for Efficient Cryptography Group recommends the domain parameters for each curve [44]. The signature function used is based on any of the currently used elliptic curves implemented in MBED TLS [45] such as: We can find some implementations of elliptic curve algorithms as described by Liu et al. [46] using a TI MSP430. It is a 16-bit microcontroller with a top speed of 25 MHz. Our low-cost eToken, based on a dual core 32-bit microcontroller at 240 MHz, outperforms this implementation with reduced execution times even with larger bit sizes. In Section 4.1, we study the times of different functions for these elliptical curves used in the eToken.

Elliptic Curve Integrated Encryption Scheme
Elliptic Curve Integrated Encryption Scheme (ECIES) is a hybrid system that combines symmetric encryption with elliptic curve-based public key cryptography for secure message delivery. The secret key used for symmetric encryption is hidden using a key derivation function (KDF) and a key agreement (KA) key exchange function (ECDH). In Reference [47], it is shown in detail how these schemes work. Figure 3 illustrates how a session key (SKk) is encrypted using this scheme. The secret key used for symmetric encryption is hidden using a key derivation function (KDF) and a key agreement (KA) key exchange function (ECDH). In Reference [47], it is shown in detail how these schemes work. Figure 3 illustrates how a session key (SKk) is encrypted using this scheme.

True Random Number Generator
The ESP32 includes a hardware random number generator. If Bluetooth or WiFi are enabled (as in our case), it uses RF noise as an entropy source and values obtained can be considered true random numbers. Besides, random number generator functions used by all the elements pass the Dieharder random number test suite [48].

Combining Algorithms
The hash function is calculated for all sent messages and signed with the private key by the sender element so that the receiver can validate it.
Since the system is based on public key, it is not necessary to store symmetric encryption keys that could compromise the security of the system. Furthermore, authentication does not require multiple messages between client and server as authentication is verified at each step.
We use the notation shown in Table 3 to identify elements and primary functions used during different stages. Each of the phases involved is described below. Table 3. Relation of the notation of the components used.

Symbol Meaning SKk
Sesion key Token t Tt2 Possible 2nd token Sj Server GWCgc Gateway client gc GWSgs Gateway server gs Pub(Ei) Public key element i

True Random Number Generator
The ESP32 includes a hardware random number generator. If Bluetooth or WiFi are enabled (as in our case), it uses RF noise as an entropy source and values obtained can be considered true random numbers. Besides, random number generator functions used by all the elements pass the Dieharder random number test suite [48].

Combining Algorithms
The hash function is calculated for all sent messages and signed with the private key by the sender element so that the receiver can validate it.
Since the system is based on public key, it is not necessary to store symmetric encryption keys that could compromise the security of the system. Furthermore, authentication does not require multiple messages between client and server as authentication is verified at each step.
We use the notation shown in Table 3 to identify elements and primary functions used during different stages. Each of the phases involved is described below.

Resource Registration
The system works under a trust model based on a public key scheme, so it is essential to store the secret keys safely and correctly. To create a new configuration, we define three steps.

Configuration Server Registration
Initially, we initialise the configuration server. This is the only one that can modify the system configuration of any system resource. It is responsible for: • Creating a public and private key pair to sign the configuration messages. The public key is installed on all elements and is, therefore, the only one authorised to make changes; • Creating the root certification authority to sign the certificates used in accessing the MQTT broker.
The public key of this certification authority (CA) must be installed on all computers and eTokens to establish secure TLS communication between the elements.

MQTT Broker Registration
Communications between the different elements are made through MQTT messages using secure TLS-based communications and avoiding possible man-in-the-middle (MitM) attacks.
This MQTT broker needs a certificate that must be signed by the CA, that is, by the configuration server. MQTT communications can be based on two models:

•
Using only the MQTT server certificate, which is verified by clients who must have the public key; • Using client and server certificates both signed by the CA.

Registration of Functional Elements
All functional elements (servers, clients, users, and eTokens) have to follow the next step to be included in the authentication system:

•
Generate a unique 128-bit UUID; • A public/private key pair to sign the messages. The private key must be stored safely in each of them; • Each element has a configuration profile created by the configuration server to access the MQTT broker with a user defined for each one. This control mechanism allows cancelling access if necessary, by deleting the user associated with that element; • Each resource sends its UUID and public key to the configuration server. Thus, each element has a set of authorised public keys. So, any request that does not come from any of these keys is directly discarded.
In the case of the eToken, the USB connection can act as an initial gateway to configure it, and the initial authorisation is only possible when the device deletes all the keys or is completely restarted, leaving it empty.
The configuration server must also store the information safely, mainly to prevent false elements from being modified or added. Thus, when the system starts, the configuration server generates the configuration of the nodes to connect using the MQTT broker.
When the configuration is changed, the configuration server sends the changes to the elements that update their information. All elements only need to store the basic configuration and keep it correctly updated.
In the case of a public cloud, we can have the authentication server and the configuration server in a safe place, outside the cloud if necessary, so we can physically implement some additional security measures.

Service Request
Once the configuration is established, the system is now available to establish communications securely. Thus, the service request process can be divided into five steps.

The User Requests eToken to Access Service
The client creates a new session (Sn) identified with a UUID, with a sequence number (SEQq) to the service (SVCs), and with the corresponding request hash validation signatures. This request is signed by the user (Ui) (1) and by the client node (CLc) (2) requesting access: A robust hash function is used to get a unique value for each request. In addition, each request has a serial number, which has two advantages: The number is incremental, so the same number cannot be used again.
When an element starts, the configuration server sends a random number from which the count continues. If the number is less than the previous value or greater than a small window, it sends an access revocation message informing the configuration server, so the element must identify itself again.
The new request for access to a service is sent to the eToken (Tt). This is an important difference from the U2F model, where the hardware key does not identify the user. Thus, an eToken that is not recognised by an authorised user will reject the request.

The Etoken Requests Access to the Authentication Server
After a power-up condition or after a period of time, the user has to log into the eToken to enable it sending a password as an extra security level.
The eToken has a list of authorised public keys so it can confirm if a user (Ui) from a node (CLc) has access to the system. This simplifies the configuration of the eToken since it only requires the list of authorised public keys.
The eToken verifies the signature from the node (CLc) using Vf (msg, pub (CLc)), and if it is valid, it displays on the screen the request for the user to validate it by pressing a button or by using the fingerprint sensor if it is enabled. The times required for signature validation are shown in Section 4, based on the selected elliptic curve.
Additionally, the eToken can verify the context; that is, it can detect which Bluetooth or Wifi resources are nearby. It must detect a valid environment to authorise. This operation can be remotely activated by the configuration server which can control which resources are valid.
Since the session identifier (Sn) is unique using a 128-bit UUID, the information is not repeated on every signature. It is only necessary to sign Sn.
Once authorised by the user and the context, the eToken signature is added (3): If we define a configuration with multi-user and multi-eToken authentication, the request authorised by the first eToken is sent to the second eToken to be validated by the second user. In this case, an additional signature of the second eToken is also included (4).
This request is sent to the authentication server for global authorisation and to check all ACLs.

The Authentication Server Requests Access to the Gateway
The eToken sends the request to the authentication server. This has all the ACL rules that allow deciding if the Ui user from the CLc node with the eToken Tt has access to the SVCs service. Possible rules are described later in Section 3.8.
The authentication server verifies all signatures so it can confirm that is a valid request. Then, the authorisation process checks the ACL rules and, when it validates the request, it signs with its private key (5): This request is sent to the gateway server to enable access.

The Gateway Server Enables the Service
Create a random 256-bit session key (SKk) that will be valid for a configurable time that by default is set to 60 s. Since the server is the one that generates the session key, there is no need to timestamp, so it avoids the problem of time synchronisation between nodes.
The server opens the communication port that allows access to the service and sends the SKk session key using the ECIES hybrid encryption scheme (6) to the gateway client that is integrated with the initial service request system.
The message includes an ephemeral ESk key for a secure exchange using ECIES. The gateway client receives the message (6) to obtain the SKk session key (7). 3.

Communication through the Gateway
When the client receives the session key (SKk) (7), it requests communication with the server through the gateway.
The gateway server checks the session key in the list of valid keys and decides whether the connection is accepted. Invalid connections are rejected after a few seconds, preventing a brute force attack. If the session key is valid, it establishes communication with the service and the session ID (Sn) is included in the list of active communications.
If the authentication server receives a communication revocation request, it can send the message to the gateway server to immediately cut the communication. This revocation can come from the global supervisor.
The Figure 4 shows the message sequence chart (MSC) between the different elements:

Multiservice Authorisation
One of the advantages of this model is that it allows multiple communication channels to be opened simultaneously with authentication.
In this case, the client requests the service as usual. Thanks to the MQTT model, the authentication server sends multiple requests to different gateway servers. Thus, each server forwards an opening message from its communication channel, confirming client access for TCP sockets.
Suppose a Hadoop-based big data application where a client accesses multiple Hadoop servers. The client creates multiple requests for accessing the servers. In this case, multiple session keys SKk1, SKk2, ... are created, one for each gateway client that accesses the system.
Sessions can be kept open for a time, which avoids having to authenticate repeatedly. Figure 5 shows how the system performs a multiservice request with multiple servers. Yellow messages have the session keys that the client receives to access to different services.

Message Format
The messages are sent in JSON format to facilitate communication through MQTT and are processed quickly by the elements.

Multiservice Authorisation
One of the advantages of this model is that it allows multiple communication channels to be opened simultaneously with authentication.
In this case, the client requests the service as usual. Thanks to the MQTT model, the authentication server sends multiple requests to different gateway servers. Thus, each server forwards an opening message from its communication channel, confirming client access for TCP sockets.
Suppose a Hadoop-based big data application where a client accesses multiple Hadoop servers. The client creates multiple requests for accessing the servers. In this case, multiple session keys SKk1, SKk2, ... are created, one for each gateway client that accesses the system.
Sessions can be kept open for a time, which avoids having to authenticate repeatedly. Figure 5 shows how the system performs a multiservice request with multiple servers. Yellow messages have the session keys that the client receives to access to different services.

Multiservice Authorisation
One of the advantages of this model is that it allows multiple communication channels to be opened simultaneously with authentication.
In this case, the client requests the service as usual. Thanks to the MQTT model, the authentication server sends multiple requests to different gateway servers. Thus, each server forwards an opening message from its communication channel, confirming client access for TCP sockets.
Suppose a Hadoop-based big data application where a client accesses multiple Hadoop servers. The client creates multiple requests for accessing the servers. In this case, multiple session keys SKk1, SKk2, ... are created, one for each gateway client that accesses the system.
Sessions can be kept open for a time, which avoids having to authenticate repeatedly. Figure 5 shows how the system performs a multiservice request with multiple servers. Yellow messages have the session keys that the client receives to access to different services.

Message Format
The messages are sent in JSON format to facilitate communication through MQTT and are processed quickly by the elements.

Message Format
The messages are sent in JSON format to facilitate communication through MQTT and are processed quickly by the elements.
Every request has a sequence number that increases with each request. The verification confirms that the number must be greater than the last one received and within a window of 16 values. Values outside this window are considered anomalous.
One of the configuration parameters is the level of sequence control. In the relaxed security model, a warning message is generated to the administrator. In strict mode, the administrator must accept the restart of the numbering.
Thus, after each verification and authorisation, the elements add new JSON fields with the corresponding signature.
Since each element has its UUID, it is used to distribute the information in the topic hierarchy used in the MQTT broker. Each service request also has a unique UUID, so there is no overlap in uniquely determined requests, and there is no collision in messages sent through MQTT. The MQTT broker is in charge of sending the corresponding message to each node.
The primary communications are made using the following topic scheme: anb/domain/dst_element_uuid/request/src_element_uuid/ Thus, the element that receives the messages has access to all the subtopics: anb/domain/dst_element_uuid/ Instead, the sending item only has access to the subtopics: anb/domain/dst_element_uuid/request/src_element_uuid/ The configuration server is responsible for managing the MQTT broker configuration, MQTT users, and topic access rules in the MQTT broker. It also informs the elements of the new topics they must subscribe, allowing the setting to change dynamically.

Definition of Access Rules
Flexible rules for accessing services can be established based on various combinations of the clients, users, and eToken nodes. Groups of elements can be defined to facilitate configuration. The YML configuration file consists of three main parts: • Element definition (authentication process); • Group and combined element definition (authentication process); • Access rule definition (ACL) (authorisation process).
Each element is identified by an alias: its UUID and the name of the file that contains the public key in PEM format. New aliases can be created and they can contain any combination of other aliases with the "AND" and "OR" operators.
In the access rules, on the one hand, there are the elements that access: users, client nodes, and eTokens, and on the other hand, the elements access: servers and services.
It is possible to set any combination of rules that are evaluated in order to authorise access to a service on a server. As previously mentioned, multiple eTokens can be combined to define a cascading authorisation in which two users must authorise access to a service, increasing security in the system.
Authentication and authorisation processes work independently, and if necessary, can be separated in different servers and contexts. YML can be divided into each part, but for practical reasons, client requests can be solved by the same server.

Security Analysis
This section studies the resistance of different elements in the proposed system to frequent attacks in authentication environments.

Resistance in the MQTT Broker
In the MQTT-based message delivery model, only the MQTT broker has a listening TCP port, and all the elements connect to it using two-way TCP sockets. This design allows that the elements do not have a listening port, and therefore there is no direct way to get into them.
In any case, it is the MQTT broker that must be more robust against attacks. The MQTT protocol is quite secure and reliable; although MQTT can be considered robust because several MQTT broker implementations have their security well evaluated, the way it is implemented and configured can cause issues.
In the proposed model, we use MQTT with certificates, TLS communications, and users with access rules, which offers several advantages:

•
Communications are encrypted; • Only certificates signed by the CA are accepted. In our case, the certificates are generated by the configuration server; • MQTT users for each element allow communication control; • ACLs are used to access the topics of the MQTT broker so that each element has limited access only to its information.
All these resources add an extra security level to the communication between all the elements. Even if the MQTT broker is compromised, and an attacker has access to read all messages or can send new ones, the system is still reliable because: (1) If the attacker can read all messages, they know the service requests from the users, but these messages have irrelevant information. Related to the session key SKk, it is encrypted using the ECIES scheme, so the attacker cannot get it to access to the gateway server in a later phase. SKk can only be decrypted with Priv(GWCgc).
(2) If the attacker can send messages, they also need a valid private key Priv(Ei) to sign their false requests, but all messages with invalid signatures are rejected.

Tamper Resistance of the EToken
The eToken stores the private key and authorised public keys in its ESP32 flash memory through the non-volatile storage (NVS) library and using 256-bit AES-XTS-based NVS encryption.
ESP32 uses internal partition tables for flash memory. Since the partition is marked encrypted and the flash encryption option is enabled, the bootloader will encrypt this partition using the flash encryption key on the first boot.
When ESP32 runs the eToken program, it saves the information in encrypted form, so only the program can correctly interpret the content. So, any external attempt to modify the configuration in the eToken NVS is not possible.
If ESP32 is partially reprogrammed to try later to access the flash partition that stores the keys, it is not readable since it is encrypted.
Changing the ESP32 configuration is only possible if it receives the messages signed by the configuration server.

Theft Resistance of EToken
In the proposed scheme, if an eToken is stolen by an adversary A, the latter cannot extract any information from the memory of the stolen devices, as described in Section 4.2.
Moreover, a stolen eToken can be locked at various levels: • After a power-on condition or an established time, a password is needed to login into the eToken and enable it. After several failed tries, the device is blocked; • Context validation: (When it is active) The eToken only works within the detection range of validated WiFi or Bluetooth devices. So outside of its location, the eToken is not active; • On the MQTT server: deleting the access account; • On the authentication server: cancellation of authentication permissions; • In the eToken WiFi access: The eToken can only communicate with the preconfigured WiFi networks.
The eToken can be reprogrammed, but as mentioned in the previous section, the operational configuration is encrypted and cannot be used to access the secure environment.

Resistance of MitM Attacks
MQTT establishes communications between nodes through TLS communications. The MQTT broker and MQTT clients use certificates signed by the CA, thus preventing a node from impersonating the MQTT broker.
TLS includes integrity checks, so communication at the TCP/IP level cannot be modified. Even, if the MQTT is compromised, messages cannot be modified because they are signed with the respective private keys in each stage.
Related to the session key SKk, it cannot be obtained by the attacker because even if he can obtain the message, it is encrypted with the ECIES scheme, and a private key Priv(GWCgc) is needed to decrypt.
The sequence number SEQq avoids the use of previous requests, so it needs to create new ones adequately signed.
In the case of communication between gateways, if the service offers secure communications such as SSH, it is the service itself that can detect a MitM attack, thus avoiding adding an additional layer of integrity check that could slow down communications.

Resistance of Attacks to the Client Node
Suppose a system with an SSH client where we use public/private key to access a server. If an attacker accesses the client node, they could access the SSH server in a typical configuration, but with the proposed system, access to the SSH server requires the eToken authorisation.
Furthermore, the proposed model can use a private key for the client node and a private key for the user. The administrator can select what keys can be used, one of them or both, if needed.
To tighten the private key to the client node, the client application stores the node private key encrypted with a key that is partly derived from CPU properties, such as: model, family, cache lines, and extensions. So, this private key can work only in a platform with the same physical characteristics, which makes it difficult for the private key to be used in another client node.
Thus, if an adversary accesses the client node, they could use the private key, but they need to know the password to enable the eToken and have to access it to validate the service request. If the user has the eToken in his possession, he will not authorise the request, and therefore access to the service is not possible.
Credentials used to access MQTT are encrypted, so the attacker does not have direct access to the MQTT broker. Further, due to the segmentation of the topics used, this node has access to a limited number of topics, so the MQTT is not compromised.
Likewise, if there is an attack on the client node copying the private key, this alone is not sufficient to access the server, since eToken authorisation is required.

Resistance of Attacks on the Authentication Server
The authentication server is a vital element because it decides if a request is valid, and it can request to GS a new connection. In the proposed model, the AS is safer than other systems because it does not need to have open ports outside. This is a significant difference because it is protected for direct attacks from the outside. AS must be properly isolated, as it is responsible for admitting authorisations. The proposed system has two advantages: • Requests arrive through MQTT messages, so the authentication server does not have an explicitly open port for receiving requests.

•
This model allows having the server in a different and much safer location.
Thus, in an HPC configuration, the authentication server may be in another location with a higher level of security. Likewise, in a cloud configuration, the instances can be virtualised, and the authentication server can be outside the cloud, in a secure physical environment.

Resistance of Attacks on the Configuration Server
The configuration server, like the authentication server, is an essential element since it is the only one that establishes the chain of trust in all the elements. So, it is recommended that it should be placed in a safe location.
Likewise, the configuration server communicates by MQTT messages, so it does not have an open port to receive attacks either. It stores its private key encrypted with a key that is partly derived from CPU properties, as clients do with their private keys, and partly from the administrator password. Moreover, the administrator can use his own eToken to validate modifications in the global configuration, so a direct attack without that eToken is not possible.

Resistance of Attacks Accessing Gateways
Gateway servers only accept requests through MQTT messages signed by AS and have ports closed. Only when access between gateways is requested, the access port on the server is temporarily opened.
The session key SKk guarantees that only a client with that value can establish a communication with the server. The ECIES scheme allows to send it from the gateway server to the gateway client in a safe way. Neither the administrator nor configuration server can access that value.
This port can remain fixed to facilitate firewall rules, or it can be dynamic, that is, in different requests, it can open different ports, so an attacker would not know which port to use to access the system. This information is transmitted in the message that the gateways have exchanged.
When the gateway server receives a request, the port listens for a limited time, and after receiving the start of a communication, the session key SKk is verified. If it is incorrect or not received in a while, the communication is closed.

Resistance of Denial of Service Attacks
As previously mentioned, there are only two entry points: the MQTT broker and the gateway server that is only open after a request.
If the gateway server is open for a while because a service has been requested, the server waits for the session key SKk, and if it is not valid, it closes the connection after a few seconds, avoiding repeated access to the system. So, the element that can bear the most pressure is the MQTT broker, but these servers are also designed to avoid denial-of-service (DoS) attacks. Additionally, other measures can be taken at the firewall level to limit the number of access attempts per second, or block IP addresses after some failed access attempts.

Resistance of Network Outages
Although current local networks are very robust, they can experience unexpected outrages during short periods. It is also essential to consider these scenarios to avoid possible attacks in conditions of network instability.
All communications with the MQTT broker use TLS, so an attacker cannot take advantage of sending false messages due to the integrity included in TLS communications. MQTT is a protocol quite robust, even under unreliable networks. In our case, all the elements, including the authentication and configuration servers, are MQTT clients and include auto reconnection, so as soon as the network re-establishes, they are ready to transmit and receive. The system uses quality of service (QoS) 1 in MQTT messages, which guarantees that a message is sent at least once to the receiver, so packets are not lost, and the sender knows if it has to retransmit the message due to loss of connection.

Real-Time Selective Block Communication
The proposed system makes it easy to control all the sockets that are in use. If unauthorised access is discovered, it is possible to cut any of the communications that are in progress, thanks to the real-time control of all communications. If necessary, the configuration server can send updated configuration messages blocking ACL access rules and preventing subsequent access to the system to the element involved.
In other systems, once access is authorised, the communication is established. To cancel the communication, the socket that has the communication has to be identified, or detect the IP address and port number to block the connection with firewall rules.

Performance Analysis
In our tests, we have studied the runtime of the main cryptographic functions used in different environments, and the impact of the gateway in some data transfers.

ECC Execution Times in the EToken
The eToken is based on ESP32, a low-cost system that incorporates a 240 MHz dual-core processor, with cryptographic acceleration resources and integrated communications.
An important issue is knowing if this device could process the required elliptic curve cryptographic functions at a reasonable time.
We have evaluated different elliptic curves with the MBed TLS library. Table 4 shows the runtimes obtained for key generation, signature, and verification. The SECP256R1 curve offers reasonable response times below 0.35 s for verifying and 0.1 s for signing.

Execution Times of ECDSA Functions
Various architectures have been evaluated to obtain the runtimes of key generation, verification, and signing key of a 256-bit hash value used in different client and server functions. We prefer this way to analyse because our model can be implemented with any combination of elements placed in different architectures and operating systems. Tables 5-8 show the average times obtained in microseconds using the Golang ECIES library [49] with different processors, such as: Intel i7-4980HQ @ 2.80 GHz, Intel Xeon Silver 4116 CPU @ 2.10 GHz, AMD EPYC 7571 @ 2.4 GHz, and ARMv7 on Raspberry PI 4 model B.    In general, the elliptical curve P256 requires less processing time. Besides, Intel and AMD architectures have considerably lower execution times due to hardware optimisations.

ECIES Execution Times on Diverse Clients and Servers
Server and client gateways exchange a 256-bit secret key (SKk) to guarantee later access between both elements. This key is sent securely with a message with the ECIES scheme. Table 9 shows the encryption and decryption runtimes of the 256-bit token using the ECIES library [28] with Golang. In this case, the secp256k1 curve is used in the ECIES functions related to the private/public key functions. We have evaluated different architectures.

Processing Time
As we have seen in the previous tables, the average time depends of the selected resources used. It also depends on the network topology. In order to obtain an estimated global runtime, we have used a configuration based on Intel Xeon E5-2676 v3 @ 2.40 GHz, with the MQTT broker Eclipse Mosquitto [50] version 1.6.9, widely used in Linux and other platforms, although this model allows the use of any other MQTT broker compatible with the 3.1 standard. Table 10 shows the average times for each of the stages described in Section 3.5 with a 1 Gbps network interconnection. Although the process involves several stages, and the signature verification time is longer in ESP32, the central time is due to waiting for the user to validate the access. In general, authentication times are reasonable in user context and server requirements.
For these measurements, the elliptical SECP256R1 curve has been used, which offers a high security level and optimal execution times.
One of the advantages of this model is that it can work in parallel so that multiple authentication processes can be established simultaneously.

Direct Bandwidth and Latency Overhead
In this case, we use two programs written in Golang: a TCP echo, which retransmits everything it receives, and another program that transmits and receives packet sequences of different sizes. In this way, latencies and bandwidths can be evaluated considering symmetric communication. Table 11 shows the roundtrip time divided by 2 for different packet sizes with direct connection and compared using the client and server transparent gateway.

Impact on SSH Communications
We have also studied the impact on SSH communications. In our case, we have defined an SSH tunnel with the TCP echo program at the end. We have measured the roundtrip time divided by 2, as the previous test with direct connection and using our gateway. Table 12 shows that we get an effective bandwidth better than 80% in all cases using the gateway with SSH communications.

Impact on Accessing Data in Hadoop HDFS
Some HPCs use Hadoop for big data processing and analytics computing. We have studied the impact of accessing data stored in a Hadoop cluster using HDFS. Hadoop is in version 3.2.1, and the computer nodes have Intel E5-2620 v4 @ 2.10 GHz, CentOS 7.7, 500 GB HDDs and are connected with a 1 Gbps network. The client node uses a Golang client for HDFS [51].

Metadata Access
We have tested four basic functions: create file, create directory, remove file, and remove directory. All functions have almost the same execution time and vary from 3.37 ms to 4.01 ms depending on the server load and internal Hadoop processes. The penalisation due to the gateway is only 0.05 ms, that is practically hidden in the normal fluctuation of the times obtained. It only represents 1.25%. So, the gateway has a reduced impact on these operations.

Data Access
As we have mentioned before, Hadoop has some fluctuations in execution time due to how it handles internal flush buffers and its disk access policy. In this case, we have executed each test 100 times and obtained the median value to avoid extreme values. The execution time includes: create/open, write/read, and close operations. Table 13 shows the execution time obtained with these tests for direct connection and using the gateway. We can observe that the times obtained for a file with sizes from 1 byte up to 10,000 bytes are almost the same, due to remote functions overhead, so buffers cannot work properly and optimise their data transfers. We can observe that the impact of the gateway is reduced with different file sizes, and read and write operations.

Discussion
It is necessary to analyse the impact of the main cryptographic functions implied to determine if the proposed model can work in a real HPC environment and the overhead of the gateways. As already discussed, our model can be implemented with any combination of elements placed in different architectures and operating systems.
The results obtained confirm that the functions used in client and servers based on elliptic curve cryptography have a reduced execution time on different architectures. Moreover, our eToken can also execute them in tenths of seconds.
Concerning the gateways, they simplify the integration process with different programs and services. In general, they have a reduced overhead as we can observe in the communications test performed.

Conclusions
The use of security keys is as proliferating as multifactor authentication systems for secure system access. The advantage of these systems is that the user "physically" has a non-duplicable element to authorise access. Although there are standards such as those proposed by FIDO, these are subject to possible improvements.
In this work, we present a different approach to the authentication process that can be applied to HPC and cluster environments. Our proposed model is based on ESP32, a low-cost system-on-chip that allows the execution of cryptographic functions based on elliptic curve and various communication interfaces. In combination with this eToken, we propose a communication system that transparently allows authentication in client-server programs, facilitating integration in current systems. This system offers an extra level of security, flexibility in configuration, scalability in distributed systems, reduced time in the authentication process, and the gateway has a reduced impact on cluster communications.
We continue improving our system adding compatibility with other authentication methods like the Linux Pluggable Authentication Module (PAM) or authentication protocols.

Conflicts of Interest:
The authors declare no conflict of interest. The funders had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript, or in the decision to publish the results.

Abbreviations
The following abbreviations are used in this manuscript: