The algorithms and software components conforming to the current solution are explained in this section.
In this section, the mathematical fundamentals of the current authentication system are exposed. Consider the device Authenticator (A), whose access is desired to manage the Authentication Manager (AM) that generates the initial data, the Authentication Service (AS) and the Authentication Client (AC) that is used by the administrators to obtain passwords. These components are described in Section 4.2
. First, the value id
is defined to identify the device whose access is managed. The next parameters are required to be configured after the id
Key length (): The length in bits of the key pair generated for the current authenticator.
Password length (): The number of characters of the password requested by the authenticator.
Number of users (m): Number of required users to complete authentication.
Once time the configuration of the required parameters has been completed, the Authenticator Manager generates the values required by the Authenticator.
First, two primes, a and b, are generated considering the configured length . The prime number a is a strong prime. Thus, a’ = a− 1 has a large prime factor denoted by q.
The integer n
is obtained as
Thus, the Euler function of this value is obtained as
At same time, the value g
is obtained, which is a generator of a subgroup with order q
from the integers module n
. The generator g
exists because q
is a prime factor of (a
− 1) · (b
− 1). The value of q
must be large to avoid generating the same value in two authentication operations, as is explained below. The standard FIPS 186-4 recommends a length of 140 bits for q
to generate RSA key pairs of 1024 bits. Thus, we think this length is large enough for our purposes. From the values n
, and b
, a key pair similar to RSA keys is generated, which is an integer e
verifying the next expression is generated:
After that, an integer d
is obtained such that
These values are stored by the Authentication Manager associated to the current Authenticator identified by its id
value. The configuration parameters and the generated values are stored in a database which is accessible by the Authentication Service. The Authenticator receives the values [d
], as explained in Section 4.2
After the devices has been configured as Authenticator, m
system administrators must be registered at least for the current device. An identifier is assigned to each user, denoted by
, and the group of authorized users denoted by U
is defined as
Each user must introduce a password in Base 64, whose length is
. Each of those passwords is denoted as
, for the user
. A transformation function is applied for every password obtaining a new integer
, which it is the user final key. This function is implemented by a component that uses the PBKDF2 algorithm with HMAC-SHA1. The component is initialized with the parameters
as desired key length and 10,000 as the required algorithm iterations. This value has been chosen considering the recommendations in NIST guidelines published in June 2017. The generation function receives two parameters, a randomly generated initialization vector and the user password.
The value of the initialization vector
is selected such that
Thus, a value
could be obtained for each user such that
Once time these values have been generated, the corresponding value is stored for each user. All system administrators should load in their own AC the values .
The following steps are taken to perform the authentication process. When the command login is executed in the device A, the PAM module of this machine executes the following operations. A random password p
is generated. Then, a random integer r
is generated and the key k
of A is obtained as follows
A shows the password p and an access counter j, composing the challenge. No information about the value of k from the value p if the value e is not known can be obtained.
Each administrator receives these values and, introducing the corresponding password
, recovers the key
from the stored initialization vector
. AC generates a random value
bits and calculates
After the AC is authenticated in AS using its certificate, the system administrator sends to AS a request with the values
and AS returns the value
calculated as follows:
The system administrator applies a mask to the value
so that it obtains a value with length
bits denoted by
. Then, the system administrator introduces the values [
] in the A. Now, the authenticator knows the values [g
]. Thus, the authenticator can calculate
If A applies the same mask as the AC to the value , it obtains . If the equality is verified, then the identity of the user has been proven. The authentication process requires the knowledge of data only known by the administrator and data stored by the AS that checks the administrator permissions. A valid client certificate is required to access the AS. This aspect allows implementing revocation operation for users, because revoking the client certificate the user cannot access the AS. This capability can be easily implemented using operations commonly available in most of the existing PKIs.
4.2. Solution Architecture
Several components are required to implement an authentication based on the algorithm presented in the last section. In the current section, we describe the components of the system and their connections. The distributed authentication system is composed of several components that can be classified in three categories:
Workstations: The devices whose access control is managed using the distribution managed system. A workstation that has been registered is called Authenticator (A).
Client components: The devices hosting a client application used by the workstation administrators to solve authentication challenges and generate passwords. They connect to the server components to complete the authentication operation. The device is called Authentication Device (AD) and the application is called Authentication Client (AC).
Server components: The server components provide services to register new clients and workstations and to verify client permissions. The authentication services must be accessible by the client devices.
Since this solution uses digital certificates to perform some operations, a Public Key Infrastructure (PKI) must be available. A PKI is a set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public key encryption. It is composed of several applications that offer different capabilities required by the described authentication system:
Certification Authority (CA): Issues, signs, stores and manages digital certificates for the requesting entities.
Registration Authority (RA): Verifies the identity of entities requesting digital certificates. The RA application requests to CA to issue a new digital certificate.
Validation Authority (VA): Provides services to verify the status of digital certificates. A digital certificate can be revoked, suspended or expired. Thus, in those cases, the digital certificated is not valid and it cannot be used to perform public key operations.
The relationships among the mentioned components are shown in Figure 1
. Once the implemented and required components have been exposed, we describe the components implemented to build the authentication system.
The server side is divided in two components: the Authentication Manager (AM) and the Authentication Service (AS). The AM provides a web interface that is locally accessible by a set of system operators (Authentication Operator, AO). This component has two main responsibilities:
To add a new workstation, the owner of that device requests to the AO to register the device in the system. The AO verifies whether the owner is authorized to register device and then initializes the workstation. The device must be accessible from the AM and have an SSH server enabled. The AO introduces in the system the authentication parameters [
] and, then, the AM connects to the workstation to install and configure PAM. After that, it installs the authentication data [d
] described in the last section. The AM registers the new authenticator in the system and, finally, it disables SSH server and reboots the workstation. The workstation is now configured as authenticator. This process is shown in Figure 2
Once the authenticator has been registered, the authenticator administrators is associated to that workstation by the AO. The AO requests to the administrators their identities and passwords. Then, the AM connects to the RA to issue one client certificate for each administrator and generates a password to download the certificate and the client authentication data. Finally, the system administrators initializes their ACs in their ADs using the generated password. The procedure is shown in Figure 3
A service cluster called Authentication Server (AS) is available to perform authentication operation. The service AS allows solving the authentication challenge posed by the authenticator device A to the authorized users. The user uses the AC application where the client certificate of that should be loaded because the certificate is necessary to establish a secure connection with the service AS. The AC application reads the challenge data presented by the authenticator as QR code after the user has authenticated into the AC with the private password. Then, the AC application calculates an intermediate value, establishes a secure connection with the service AS and sends it the obtained value. The service AS returns a new value that is processed by application AC to calculate the authentication token. The final token is shown in the mobile device to the system administrator who introduces the value into teh login console of the authenticator device A. This operation is shown in Figure 4
4.3. Security Aspects
The algorithm security relies in the difficult to solve the problem of prime factorization of integer numbers. Find the factorization of the number n, for an integer enough large, it is not possible in a polynomic time for any known algorithm. The recommended minimum length is currently 2048 bits, but many authors recommend 4096 bits. However, much current hardware, such as smart cards, HSMs, etc., does not support this key length. Because this kind of algorithms offers only computational security, depending on computing time, the required key length of n could increase with the time. This variation would depend on the improvement of device performance and find more efficient algorithms. Thus, when choosing the key length, the duration of the keys offered should be considered. At present, NIST speculates that 2048 bits keys would be valid until 2030.
Continuing with the algorithm analysis, the authenticator device shows the value p and the counter n. To obtain some information about k and r, knowing the value of e should be needed. Even knowing the value d and n, it is not possible to obtain k and r if the prime factorization of n is not known.
Related to the value of g, if an attacker could impersonate the system administrator, he could not obtain information about the value of g, provided that counters such as would be used due to obtain g, which requires knowning the prime factorization of n.