Towards Secure and Usable Certificate-Based Authentication System Using a Secondary Device for an Industrial Internet of Things

Abstract

As the number of controllers and devices increases in Industrial Internet of Things (IIoT) applications, it is essential to provide a secure and usable user authentication system for human operators who have to manage tens or hundreds of controllers and devices with his/her password. In this paper, we propose a formally verified certificate-based authentication system using a secondary network device for such IIoT applications. In the proposed system, a user’s sign key is encrypted with a secret key that can be computed with his/her password and a secret parameter in a secondary device to securely protect the sign key. To demonstrate the feasibility of the proposed system, we implemented a prototype with standard cryptographic algorithms (AES-256, RSA-3072, and ECDSA-256). The experiment results demonstrated that the execution time overhead of the sign key recovery process was 0.039 and 0.073 s, respectively, for RSA-3072 and ECDSA-256, which was marginal compared with the total execution time (0.383 s for RSA-3072 and 0.319 s for ECDSA-256) of the conventional system. We also verified the security of the proposed protocol using a formal verification tool called ProVerif.

1. Introduction

One of the key requirements for Industrial Internet of Things (IIoT) applications is to establish trust among things (e.g., industrial controllers, sensors, and actuators) and human operators [1]. Interestingly, secure authentication protocols using cryptographic primitives are generally used for things, whereas passwords are still popularly used for human operators. This is natural—human operators cannot remember random cryptographic keys with high entropy.

In IIoT applications, human operators often manage and monitor tens or hundreds of controllers. Therefore, it is inevitably required for them to create and remember passwords to securely access those controllers. This authentication burden often leads to bad security practices, such as using a weak (easy-to-remember) password [2]. Periodically changing passwords (e.g., every three months) is a further large burden as an operator must access every controller individually to change their passwords. Moreover, some controllers provide very limited ways of physically entering text (e.g., up and down buttons); and operators are expected to scroll up and down a given list of characters to select their passwords. Such limitations on the physical user interface make it difficult and inefficient for operators to create, update, and enter passwords.

To overcome the usability and management issues of passwords and authenticate operators in a secure and user-friendly manner, a certificate-based authentication protocol can also be considered for human operators. Basically, a user authentication process can briefly be summarized as follows. Suppose that a human operator’s sign key is installed on the operator’s client device such as a smartphone or smartwatch, where a client application for the user authentication process is installed. To communicate with a controller, a client application (instead of the operator) first obtains the sign key, computes an authenticated code with the sign key, and sends the authenticated code to the controller to prove the ownership of the sign key. The controller verifies the authenticated code received from the client with the corresponding verification key. We note that key protection is very important to ensure the security of the authentication protocol. However, most client devices do not have hardware support for protecting the user’s sign key. Again, passwords are still popularly used to encrypt the sign key (e.g., PBKDF2 [3]) and store only the encrypted sign key on the client device. This encryption key (used to encrypt the user’s sign key) should then only be recovered with the user password. In this case, the security of the key protection mechanism depends on the strength of the user’s password: an attacker who has access to the encrypted sign key stored in the client device would be able to perform an offline dictionary- and rule-based brute-force attack to guess the user’s password and then decrypt the sign key. If the attacker can obtain the user’s sign key, they can connect to all of the controllers the user has access to.

In this paper, we present a certificate-based user authentication system where a user’s sign key is encrypted with a key derived from both the user password and a specific secret value, without relying on special hardware. The proposed authentication method makes use of a secondary device (e.g., an honest-but-curious server or smartphone) that the user can connect to for protecting the user’s sign key. Our key protection idea works by storing the specific secret value, which is used to generate the encryption key, in a secondary device—making it infeasible for attackers to perform offline dictionary attacks even when the primary client device is stolen. To perform an offline dictionary attack against the proposed scheme, an attacker would have to break into both the primary and secondary devices at the same time to steal the encrypted sign key, as well as the specific secret value. We argue that such an attack would be computationally very expensive and difficult to perform. Our key contributions can be summarized as follows:

• We propose a formally verified certificate-based user authentication method that does not require additional secure hardware (e.g., ARM TrustZone) to mitigate offline password guessing attacks. The user’s sign key is encrypted and the encrypted key can only be decrypted when the primary device successfully communicates with a network-connected secondary device that assists in the decryption process. We proved that the proposed protocol is secure using ProVerif that is an automatic cryptographic protocol verifier in the formal model.
• We demonstrate the feasibility of the proposed certificate-based authentication method by implementing a prototype with popularly used cryptographic algorithms (AES-256, RSA-3072, and ECDSA-256). With this prototype, we analyze its communication overhead and demonstrate that the execution time overhead of the signing key recovery process is acceptable (0.039 s for RSA-3072, 0.073 s for ECDSA-256 on average compared with the total execution time of the conventional system) for the industrial controller application.

The rest of this paper is organized as follows. In Section 2, we provide an overview of the related work. In Section 3, we explain the conventional authentication method with a digital certificate. In Section 4, we describe possible attack scenarios against the authentication method. In Section 5, we present a certificate-based user authentication method using a secondary device. In Section 6, we analyze the security of the proposed system using a well-known verification tool called ProVerif. In Section 7, we evaluate the performance of our prototype implementation. Finally, the conclusions of the study are provided in Section 8.

2. Related Work

Local storage protection has been actively studied in academia. Most issues relating to the encryption of local data have been addressed using a key that is derived from a user password [3]. Canetti et al. [4] proposed an approach for limiting offline dictionary attacks by additionally requiring the user to solve a puzzle, such as CAPTCHA during the process of deriving a key from the user password. Catuogno et al. [5] proposed a secret key sharing scheme in which a user’s master key is reconstructed with two partial secrets that are stored and managed, respectively, in two separate devices. At first glance, this approach seems similar to ours in the sense that a user’s master key has to be obtained only through the cooperation of multiple devices. However, the proposed system requires a centralized administration entity’s persistent intervention and management, whereas in our approach the centralized administration entity is only needed for initial access policy configurations for industrial controllers. In addition, they presented the design of a system only without the actual implementation of their system while we implemented a fully working system and evaluated its performance under various conditions. Catuogno et al. [6] proposed a secure storage architecture based on the TrustZone technology [7] in mobile devices to protect sensitive files from unauthorized access. However, the proposed technique can only be used with TrustZone enabled devices. One of our design goals is to provide a secure certificate-based user authentication scheme without relying on additional special hardware components such as TrustZone. To achieve this goal, we develop a secure user authentication scheme and evaluate its efficiency and security through experiments under various conditions. Unlike previous studies, we formally verified the security of our system.

The National Institute of Standards and Technology (NIST) published a document for securing Industrial Control Systems (ICS) [8]. This document analyzes potential threats and vulnerabilities to ICS and recommends suitable countermeasures against the identified threats. In particular, with respect to user authentication, this document discusses five methods that could be applied to ICS environments and their pros and cons: password, challenge/response, physical token, smart card, and biometric authentication. This document also discusses specific considerations of ICS when applying each of these authentication methods. Borisov et al. [9] proposed a user authentication scheme based on QR codes and one-time passwords for industrial control systems, and Plaga et al. [10] further improved the scheme in [9] by taking advantage of the TLS channel binding technique [11]. Huh et al. [1] proposed generic system architecture for user authentication and access control to industrial controllers in distributed industrial control systems. In their proposed architecture, a centralized authentication server and a centralized policy management server are employed for more efficient and flexible access control. Despite many benefits provided by such architectures with centralized servers, centralized identity management systems can be attractive targets for attackers, becoming a single point of failure.

Abidin et al. [12] and Peeters et al. [13], respectively, proposed collaborative authentication protocols based on threshold cryptography, where multiple user devices jointly perform user authentication to remote verifiers. These approaches commonly use a secret sharing technique to split a secret key for user authentication into multiple shares and distribute them over multiple user devices. Due to the nature of the secret sharing technique in these approaches, the security of the collaborative user authentication process can be improved as the number of user devices sharing the secret key increases. However, the maintenance cost of secret shares over multiple user devices also increases because the maintenance operation requires communication among the user devices; according to [12], the maintenance cost of sharing a secret takes about $t^2$ to ${(n-1)}^2$ under the assumption of $(t,n)$-threshold scheme, where at least t out of n user devices are required for user authentication. In this paper, we considered a more realistic and practical deployment achieving a balance between the security and the convenience. In our system, we particularly design a secret sharing scheme using PBKDF (Password-based key derivation function). Specifically, our approach encrypts a user’s sign key and physically separates the secret parameters used to generate the encryption key into the primary and the secondary user devices. With this simplified system model, the proposed system can reduce the management cost while achieving a reasonable level of security. In addition, unlike previous studies, we implemented a fully working system and evaluated its performance in real network settings.

Certificate-based authentication has been still widely used in a variety of applications. Hiltgen et al. [14] presented a certificate-based user authentication method of leveraging smart cards to mitigate the threats on user authentication in Internet banking applications. Certificate-based authentication is also commonly used by open source IoT frameworks (e.g., AllJoyn [15], OCF (Open Connectivity Foundation) specification [16], IoTivity [17], etc.) to establish secure sessions between devices while minimizing user intervention. To the best of our knowledge, no previous study has presented an offline guessing attack scheme against certificate-based authentication with the goal of obtaining a user’s private key from the password-protected private key file. As such, we analyzed this type of threat in the context of user authentication to industrial controllers, and developed a countermeasure to mitigate the threat.

3. Certificate-Based Authentication

In this section, we explain how a digital certificate can be used for user authentication in an industrial controller application. A conventional certificate-based user authentication scheme [18] can be described at a high level as follows.

Suppose that a user u uses a device d (e.g., smartphone or laptop) with a hardware token holding the digital certificate ${cert}_u$, and its corresponding sign key ${sk}_u$ for an industrial controller c. To protect ${sk}_u$ in d, d stores ${sk}_u$ in an encrypted form (i.e., $ENC(k,{sk}_u)$). An encryption key k is generated by using a key-derivation function $KDF(·)$ with the user’s password ${pass}_u$ (i.e., $k=KDF({pass}_u)$). Figure 1 shows the basic user authentication procedure.

To perform the authentication, the user u should enter his/her password through the application installed on the device d (see Step 1 in Figure 1). Next, d sends a login request message containing the user’s digital certificate ${cert}_u$ (again containing the user identity ${id}_u$ and its public (verification) key ${pk}_u$) to the controller c (see Step 2 in Figure 1). After receiving the login request message, c extracts ${cert}_u$ from the message and verifies its validity by checking whether it was issued by a trusted certificate authority and has not expired or been revoked. If the received ${cert}_u$ is valid, c replies to the request message by returning a random nonce n (see Steps 3 and 4 in Figure 1). After receiving n, d computes the encryption key k; if the entered password in Step 1 in Figure 1 is the same as ${pass}_u$, k is successfully generated by computing $KDF(·)$ with the entered password, and k is then used to decrypt $ENC(k,{sk}_u)$. Therefore, ${sk}_u$ is loaded into the memory in d during runtime (see Step 5 in Figure 1). Next, d digitally signs ${id}_u$ and n with the user’s sign key ${sk}_u$ (i.e., $SIGN({sk}_u,{id}_u,n)$) and replies to c (see Step 6 and 7 in Figure 1). After receiving $SIGN({sk}_u,{id}_u,n)$ from d, c verifies its validity with the user’s public key ${pk}_u$. If the received message is valid, the user u can login to c for a transaction (see Step 8 in Figure 1).

4. Threat Model

We consider an attacker who can access the data stored in the user device d, for example, by stealing d, and the attacker can obtain the encrypted $s{k}_u$ from d. In addition, the attacker can obtain the nonce n from controller c and the corresponding signature generated by device d by monitoring the traffic between d and c. However, we assume that the attacker does not know the user’s password $pas{s}_u$. The attacker is also assumed to be computationally bounded to polynomial time, which in particular prevents the attacker from breaking computationally-secure cryptographic primitives (e.g., AES [19]). However, the attacker fully understands the description of all procedures for user authentication and key protection. In practice, such assumptions are often valid (e.g., [20]).

The attacker’s goal is to obtain the user’s sign key ${sk}_u$. Since ${sk}_u$ is encrypted with key k, which is generated with the user’s password ${pass}_u$ alone, the security of ${sk}_u$ is only as good as the user’s password, ${pass}_u$, which is inherently susceptible to offline password guessing attacks. That is, if the attacker holds any password-related data, they can then try to iteratively guess the user’s password and check whether the guess is correct by trying to calculate the password-related data from the guess. Even though password complexity policies (e.g., requirements for minimum length, symbols, numbers, and upper/lowercase letters) or password strength meters are used to encourage users to choose strong passwords, advanced attackers are still developing methods to efficiently crack such passwords offline using various forms of hybrid password guessing attacks [21]. The basic attack procedure is as follows:

• An attacker captures a nonce n and signed message $SIGN({sk}_u,{id}_u,n)$ by observing the traffic between the device d and controller c.
• The attacker also accesses d and obtains the user’s certificate ${cert}_u$ and encrypted user’s sign key $ENC(KDF({pass}_u),{sk}_u)$; the attacker then extracts the user identity ${id}_u$ from ${cert}_u$.
• With a candidate password $\widehat{p}$, the attacker calculates $\widehat{k}=KDF(\widehat{p})$ and then tries to decrypt $ENC(KDF({pass}_u),{sk}_u)$ with $\widehat{k}$. We use the notation $\widehat{sk}$ to represent the decrypted result. Finally, the attacker checks whether $SIGN(\widehat{sk},{id}_u,n)$ is the same as $SIGN({sk}_u,{id}_u,n)$, which means that the candidate password $\widehat{p}$ is correctly guessed. This procedure is repeated with a new candidate password $\widehat{p}$ until $SIGN(\widehat{sk},{id}_u,n)$ is the same as $SIGN({sk}_u,{id}_u,n)$.

5. Proposed User Authentication System

Under the threat model described in Section 4, we showed that the existing certificate-based authentication system could be vulnerable to offline password guessing attacks. This is because the stored key data are encrypted only with the user’s password in such systems.

We suggest a new method to protect the user’s sign key, ${sk}_u$, from offline guessing attacks. The encryption key can only be generated with the assistance of a secondary device. To develop a fully working system, we considered two types of secondary devices: (1) an Internet server and (2) another user device that is nearby via a short-range network channel (e.g., Bluetooth or ZigBee).

We assume that the user device d is connected to the Internet in most cases through Wi-Fi or the mobile device’s LTE/4G connection. In some situations, however, d cannot be connected directly to the Internet. First, even though LTE/4G connection can cover most places in which controllers are located, the cost of LTE/4G data service plans is not widely in favor of end users; hence, they may resist using the LTE/4G service. Second, many client devices such as laptops do not directly support LTE/4G radios and hence rely on Bluetooth or Wi-Fi to send/receive data. Third, the service coverage is not guaranteed in certain areas (e.g., rural or underground buildings). Therefore, we considered a secondary device equipped with short-range communication as a backup plan in case an Internet server is unreachable from device d, for example, while it is being restored.

The proposed user authentication system consists of five components: user u, device d, controller c, salt server s, and mobile phone m. Device d could be a mobile phone or laptop of user u and refers to a separate device from m. Salt server s and mobile phone m in the proposed system provide two complementary options to obtain the additional parameters, i.e., ${salt}^1$ and ${salt}^2$, which are required to generate the encryption keys, i.e., $k^1$ and $k^2$, respectively. The only difference between s and m is that s is connected with d via the Internet and m is connected with d via short-range communication. It is assumed that d has secure network sessions with s and m via, for example, SSL/TLS and Bluetooth protocols. The proposed system also has two phases: (1) encryption key generation and (2) user authentication. We present the detailed procedure of each phase in the following sections.

5.1. Encryption Key Generation

We assume that the user u initially holds his/her digital certificate ${cert}_u$ and its corresponding sign key ${sk}_u$ for an industrial controller c. To securely protect ${sk}_u$, we encrypt ${sk}_u$, which is the same as conventional certificate-based authentication systems (see Section 3). However, unlike conventional systems, we introduce an additional secret parameter called random salt that is randomly chosen. The parameter $salt$ is used together with ${pass}_u$ to generate the encryption key $k=KDF({pass}_u,salt)$. To securely protect k against offline password guessing attacks, $salt$ is stored in another device (e.g., semi-trusted server or smartphone) that the user u can connect to. The steps of this procedure are illustrated in Figure 2 and are explained as follows:

• The user u enters his or her password, ${pass}_u$, through the application installed on the device d.
• To register the encryption key, d needs to connect to the salt server s, mobile device m, and controller c. If any of these are not connected, the encryption key registration process fails.
• After d connects to all of the servers, an additional two random salts, ${salt}^1$ and ${salt}^2$, are generated.
• u stores ${salt}^1$ and ${salt}^2$ in separate places (e.g., the salt server s and mobile device m) rather than their own device d to mitigate offline guessing attacks against the user’s sign key ${sk}_u$. For this, d sends the user account registration message to s. The user account registration message contains the user identity ${id}_u$, password ${pass}_u$, and system generated (random) parameter $sal{t}^1$ (see Step 4a—1 in Figure 2). We assume here that s is available and can be connected from device d. After receiving the user account registration message, s stores the triple (${id}_u$, $HASH({pass}_u)$, $sal{t}^1$) into its user database. In a similar manner, the triple (${id}_u$, $HASH({pass}_u)$, $sal{t}^2$) is registered to the user’s other mobile device m under the assumption that m is available and can be connected from device d via short range communication technology (e.g., Bluetooth or ZigBee). d sends the certificate $cer{t}_u$ to controller c (see Step 4c—1 in Figure 2). c then stores the received certificate $cer{t}_u$.
• Using ${pass}_u$ along with the random salts ${salt}^1$ and ${salt}^2$, the device d generates two encryption keys $k^1$ and $k^2$ by calculating $k^1=KDF({pass}_u,{salt}^1)$ and $k^2=KDF({pass}_u,{salt}^2)$, respectively (see Steps 5a and 5b in Figure 2).
• After generating $k^1$ and $k^2$, ${sk}_u$ is encrypted with them, i.e., $ENC(k^1,{sk}_u)$ and $ENC(k^2,{sk}_u)$, respectively, and stored in the device d.

If d fails to connect to both s and m, the proposed system can rollback the committed transactions for the key generation procedure.

5.2. User Authentication

After finishing the steps described in Section 5.1, the user authentication procedure can be performed for the user u to obtain access to the controller c. The user authentication procedure is illustrated in Figure 3. An explanation of each step of this procedure is as follows:

• For the user authentication, the user u should first enter his/her password ${pass}_u$ through the application installed on the device d (see Step 1 in Figure 3).
• To decrypt the encrypted user’s sign key ${sk}_u$, d has to obtain either one of the salts ($sal{t}^1$ or $sal{t}^2$) from the salt server s or mobile device m. Therefore, to obtain a salt, d first tries to connect to s (See Figure 3). If s does not respond to d, d sequentially tries to connect to m. If any of these are not connected, the authentication process fails because d cannot decrypt ${sk}_u$.
• If d is successfully connected with s, d sends the salt request message containing the tuple (${id}_u$, ${pass}_u$) to s (see Step 3a in Figure 3). After receiving the salt request message, s retrieves the user record matching with ${id}_u$ from its user database and checks the validity of ${pass}_u$ by comparing its hash value with the stored password hash value in the matching record. To mitigate password guessing attacks, we recommend the use of a security policy to limit the number of failed password attempts and/or impose a time interval between failed attempts. After a maximum number of consecutive salt request attempts with invalid passwords, further attempts are blocked completely. Thus, this feature ensures that offline password guessing attacks are infeasible, unlike existing certificate-based authentication methods.
• If the received ${pass}_u$ is valid, s replies to the salt request message by returning the stored salt $sal{t}^1$ (see Step 4 in Figure 3). Here, the communication channel between d and s is assumed to be a secure and authenticated channel (e.g., SSL/TLS). If s is unavailable, the user’s mobile device m can be alternatively used instead of s. If the received ${pass}_u$ is valid, m replies to d with the stored salt $sal{t}^2$. Without loss of generality, we assume here that s is available because further processes are the same in both cases.
• After receiving $sal{t}^1$ (or $sal{t}^2$), d computes $k^1=KDF({pass}_u,sal{t}^1)$ (or $k^2=KDF({pass}_u,sal{t}^2)$) to extract the encryption key $k^1$ (or $k^2$) from $ENC(k^1,{sk}_u)$ (or $ENC(k^2,{sk}_u)$). Again, d decrypts $ENC(k^1,{sk}_u)$ with $k^1$ (or $ENC(k^2,{sk}_u)$ with $k^2$) to obtain the user’s sign key ${sk}_u$ for user authentication.
• The device d sends a login request message containing the user u’s digital certificate ${cert}_u$ (again containing user identity ${id}_u$ and its public key ${pk}_u$) to the controller c (see Step 6a in Figure 3). After receiving the login request message, c extracts ${cert}_u$ from the message and verifies its validity by checking whether it was issued by a trusted certificate authority and has not expired or been revoked. If the received ${cert}_u$ is valid, c replies to the request message by returning a random nonce n (see Steps 6b and 6c in Figure 3).
• After receiving the nonce n, d digitally signs the user identity ${id}_u$ and n with the user’s sign key ${sk}_u$ (i.e., $SIGN({sk}_u,{id}_u,n)$) and replies to c (see Steps 7a and 7b in Figure 3). After receiving $SIGN({sk}_u,{id}_u,n)$ from d, c verifies its validity with the user’s public key ${pk}_u$. If the received signed message is valid, the user (u) can login to c for a transaction.

6. Security Evaluation with ProVerif

We present a brief formal security evaluation of the proposed protocols described in Section 5 by ProVerif [22] that is popularly used for verifying cryptographic protocols (e.g., [23,24]). Under an active Dolev–Yao adversary [25], ProVerif can verify the confidentiality and authenticity of the compromised participant, Mallory, that is also allowed to initialize sessions and exchange messages with network entities.

To simplify our model in ProVerif, we use a private channel to represent secure sessions based on SSL/TLS and BLE.

6.1. Key Enrollment Procedure

We modeled a set of cryptographic primitives $F_c$ that are used in our proposed key protection system (see the ProVerif code in Listing 1).

Listing 1. List of functions required for the key enrollment process.

Functions:

Fc = {HASH, KDF, ENC}

HASH(data) = hashed value.

KDF(data, salt, HASH, iteration) = hashed value.

ENC(Encryption key, data) = ciphertext.

Listing 1. List of functions required for the key enrollment process.

Functions:

Fc = {HASH, KDF, ENC}

HASH(data) = hashed value.

KDF(data, salt, HASH, iteration) = hashed value.

ENC(Encryption key, data) = ciphertext.

In the salt server s or mobile device m, a random salt value (i.e., either $sal{t}^1$ or $sal{t}^2$) is stored along with the user’s ID and password. The corresponding ProVerif expression is provided in Listing 2.

Listing 2. Procedure performed on the salt server s or mobile device m for the key enrollment.

Store (idu, HASH(passu), salt1 or salt2)

Listing 2. Procedure performed on the salt server s or mobile device m for the key enrollment.

Store (idu, HASH(passu), salt1 or salt2)

In the device d, the user’s sign key $s{k}_u$ is stored after being encrypted with a key-value derived from the user’s password and random salt value. The corresponding ProVerif expression is provided in Listing 3.

Listing 3. Procedure performed on device d for the key enrollment.

k1 = KDF(passu, salt1, HASH, 10000)

k2 = KDF(passu, salt2, HASH, 10000)

Store ENC(k1, sku), ENC(k2, sku), certu

Listing 3. Procedure performed on device d for the key enrollment.

k1 = KDF(passu, salt1, HASH, 10000)

k2 = KDF(passu, salt2, HASH, 10000)

Store ENC(k1, sku), ENC(k2, sku), certu

For these settings, the proposed system can successfully defeat an attacker who is unable to compromise both the user device d and salt server s (or the mobile device m), simultaneously. For example, if only d is stolen, the attacker can only obtain the ciphertext of the user’s sign key $s{k}_u$, but neither the user’s password $pas{s}_u$ nor a salt value $sal{t}^1$ (or $sal{t}^2$). Therefore, it is infeasible for the attacker to obtain $s{k}_u$ from the ciphertext. Similarly, if only s or m are stolen, the attacker can only obtain the user id $i{d}_u$, the hash value of the password HASH($pas{s}_u$), and a salt value $sal{t}^1$ (or $sal{t}^2$). This knowledge is also insufficient for obtaining $s{k}_u$ from the ciphertext.

6.2. User Authentication

When the user tries to access the controller c, the user’s sign key $s{k}_u$ is needed. We modeled a set of cryptographic primitives $F_c$ and $F_d$ that are used in our key protection system, and are defined in Listing 4.

The user’s sign key $s{k}_u$ is encrypted with the key derived from the user’s password and random salt value, and the encrypted key is then stored in d. The user only knows their ID and password, but not the salt value. Therefore, d should request the salt value for the salt server s if the device is connected to the Internet or mobile device m.

After receiving the salt value from s or m, d computes the decryption key by performing the key-derivation function ($KDF$) for the user’s password $pas{s}_u$ and salt and decrypts the ciphertext of $s{k}_u$ with the decryption key.

To obtain the access permission to the controller c, d receives the nonce n from c, signs the user’s ID and n with the decrypted user’s sign key $s{k}_u$, and then sends the signed value to c. If the received signature is verified successfully, c responds d with the symmetric key which will be used to secure subsequent communication between them. A brief representation in ProVerif is shown in Listing 5.

Listing 4. List of functions required for the user authentication process.

Functions:

Fc = {GetPKey, ENC, SIGN, GenCert, KDF, HASH}

HASH(data) = hashed value.

KDF(data, salt, HASH, iteration) = hashed value.

ENC(Encryption key, data) = cipher text.

GetPKey(Private key) = Public key.

GenCert(Public key, Private key) = Certificate.

SIGN(Private key, data) = signed value.

Fd = {DEC, CheckSIGN, ExtractPKey}

DEC(Key, cipher text) = data.

CheckSIGN(Signed value, Public key) = True or False.

ExtractPKey(Certificate) = Public key.

Listing 4. List of functions required for the user authentication process.

Functions:

Fc = {GetPKey, ENC, SIGN, GenCert, KDF, HASH}

HASH(data) = hashed value.

KDF(data, salt, HASH, iteration) = hashed value.

ENC(Encryption key, data) = cipher text.

GetPKey(Private key) = Public key.

GenCert(Public key, Private key) = Certificate.

SIGN(Private key, data) = signed value.

Fd = {DEC, CheckSIGN, ExtractPKey}

DEC(Key, cipher text) = data.

CheckSIGN(Signed value, Public key) = True or False.

ExtractPKey(Certificate) = Public key.

Listing 5. Procedure performed on device d for the user authentication.

Stored information:

ENC(k1, sku)

ENC(k2, sku)

Certificate certu

Process: Device$\widehat{=}$

out(cpriv, (idu, passu)).

in(cpriv, ${\widehat{salt}}^1$ or ${\widehat{salt}}^2$.

let $\hat{k}$ = KDF(passu, salt, HASH, 10000) in

let dec_sku = DEC($\hat{k}$, ENC(k1 or k2, sku)) in

out(c, Certificate).

in(c, n).

out(c, SIGN(dec_sku, (idu, n))).

in(c, encrypted value).

let key = DEC(dec_sku, encrypted value) in

out(c, ENC(key, m)).

Listing 5. Procedure performed on device d for the user authentication.

Stored information:

ENC(k1, sku)

ENC(k2, sku)

Certificate certu

Process: Device$\widehat{=}$

out(cpriv, (idu, passu)).

in(cpriv, ${\widehat{salt}}^1$ or ${\widehat{salt}}^2$.

let $\hat{k}$ = KDF(passu, salt, HASH, 10000) in

let dec_sku = DEC($\hat{k}$, ENC(k1 or k2, sku)) in

out(c, Certificate).

in(c, n).

out(c, SIGN(dec_sku, (idu, n))).

in(c, encrypted value).

let key = DEC(dec_sku, encrypted value) in

out(c, ENC(key, m)).

In the salt server s or mobile device m, the user credential information and salt value were registered in the key enrollment procedure. These are ready to receive the user ID $i{d}_u$ and password $pas{s}_u$ from d. If s or m find a match with the received information from d, they respond to d with the stored salt value $sal{t}^1$ (or $sal{t}^2$). The ProVerif expression is shown in Listing 6.

Listing 6. Procedure performed on the salt server s or mobile device m for the user authentication.

Stored information:

(idu, HASH(passu), salt1 or salt2)

Process: Salt$\widehat{=}$

in(cpriv, ($\widehat{{id}_u}$, $\widehat{{pass}_u}$.

if $\widehat{{id}_u}$ = idu then

if HASH($\widehat{{pass}_u}$) = HASH(passu) then

out(cpriv, salt1 or salt2).

Listing 6. Procedure performed on the salt server s or mobile device m for the user authentication.

Stored information:

(idu, HASH(passu), salt1 or salt2)

Process: Salt$\widehat{=}$

in(cpriv, ($\widehat{{id}_u}$, $\widehat{{pass}_u}$.

if $\widehat{{id}_u}$ = idu then

if HASH($\widehat{{pass}_u}$) = HASH(passu) then

out(cpriv, salt1 or salt2).

In the user authentication process, c receives a certificate from d and checks the validity of the certificate. If the received certificate is valid, c sends a random nonce n to d as a challenge and waits for a response from d. Once receiving the signature of n from d, c verifies the signature with the user’s public key. If the signature is valid, c sends the symmetric key to d for securing subsequent communication. The brief ProVerif expression is provided in Listing 7.

Listing 7. Procedure performed on controller c for the user authentication.

Stored information:

Certificates

Process: Controller$\widehat{=}$

in(c, Certificate).

New n.

out(c, n).

let Public key = ExractPKey(Certificate) in

in(c, signed value).

if CheckSIGN(signed value) then

New key.

out(c, ENC(Public key, key)).

Listing 7. Procedure performed on controller c for the user authentication.

Stored information:

Certificates

Process: Controller$\widehat{=}$

in(c, Certificate).

New n.

out(c, n).

let Public key = ExractPKey(Certificate) in

in(c, signed value).

if CheckSIGN(signed value) then

New key.

out(c, ENC(Public key, key)).

6.3. ProVerif Results

To verify the security and correctness of our proposed protocols, we ran ProVerif on the codes described in Section 6.1 and Section 6.2. We set the attacker as an active Dolev–Yao adversary [25]. In addition, to verify that our protocols are safe under the threat model described in Section 4, we assumed four cases: standard, information leakage from d, information leakage from m, and information leakage from both d and m.

Standard case. As we mentioned at the beginning of Section 6, we used the private channel when communicating between the mobile and user devices, and used the public channel when communicating between the user’s device and controller. As a result, ProVerif showed that the attacker cannot obtain the user’s sign key $s{k}_u$.

Information leakage from the user’s device d alone. In this case, we assumed that an attacker could access the data stored in d such as $i{d}_u$, encrypted user’s sign key ENC(k, $s{k}_u$), and $cer{t}_u$. To mimic this data leakage, we sent the data over the public channel. According to ProVerif results, the attacker cannot still obtain the user’s sign key $s{k}_u$.

Information leakage from the mobile device, m, alone. In this case, we assumed that an attacker could access the data stored in m such as $i{d}_u$, HASH($pas{s}_u$), and $sal{t}^1$ or $sal{t}^2$. To mimic this data leakage, we sent the data over the public channel. The ProVerif results show that the attacker still cannot obtain the user’s sign key $s{k}_u$.

Information leakage from both d and m. In this case, we assumed that an attacker can access the data stored in both d and m, including $i{d}_u$, ENC(k, $s{k}_u$), HASH($pas{s}_u$), $sal{t}^1$ or $sal{t}^2$, and $cer{t}_u$. To mimic this case of data leakage, we sent the data over the public channel. The results of ProVerif show that the attacker can successfully obtain the user’s sign key $s{k}_u$. The detailed process for obtaining $s{k}_u$ is shown in Listing 8.

Listing 8. Attack trace for information leakage from both the user and mobile devices, d and m, respectively.

d → ATTACKER : ENC(k, sku)

m → ATTACKER : HASH(passu), salt

By dictionary attack, ATTACKER get passu from HASH(passu)

ATTACKER : generate k using KDF function with passu and salt

ATTACKER : With k, get sku from ENC(k, sku) using DEC function

Listing 8. Attack trace for information leakage from both the user and mobile devices, d and m, respectively.

d → ATTACKER : ENC(k, sku)

m → ATTACKER : HASH(passu), salt

By dictionary attack, ATTACKER get passu from HASH(passu)

ATTACKER : generate k using KDF function with passu and salt

ATTACKER : With k, get sku from ENC(k, sku) using DEC function

Even without active intervention, the attacker can obtain the user’s sign key $s{k}_u$, but only if the attacker can access the data stored in both d and m to obtain ENC(k, $s{k}_u$), HASH($pas{s}_u$), and $salt$ together. The attacker can use the dictionary attack to successfully guess $pas{s}_u$ from HASH($pas{s}_u$). Using $pas{s}_u$ and $salt$, the attacker can then make the encrypted key k using the key-derivation function KDF($pas{s}_u$, $salt$, HASH, 10,000). Using $s{k}_u$, the attacker can mimic the user with the user’s digital certificate and freely access the controller c.

7. Implementation and Evaluation

To show the feasibility and effectiveness of the proposed user authentication system, we implemented a prototype and performed several experiments with the prototype implementation. The implementation and performance evaluation of the proposed system is described in this section. As a baseline for the comparison, we also implemented the conventional system (described in Section 3) and performed the same experiments.

7.1. Implementation

For digital signature algorithms, we used RSA and ECDSA with SHA-256 and respectively used 3072 bits and 256 bits for the length of a public key ${pk}_u$ which achieve the same level of security according to the recommendation of NIST [26]. To securely store the user’s sign key ${sk}_u$, ${sk}_u$ was encrypted using the AES-256 algorithm in Galois/Counter Mode (GCM) without padding. We note that padding is not required because random keys are encrypted. To derive the AES encryption key, PBKDF2 with HMAC-SHA256 was used where the number of iterations was 10,000, and the salt was generated by a cryptographically secure pseudorandom number generator (CSPRNG). Similarly, CSPRNG was also used to generate the initial vector for the AES encryption in GCM. We used a SHA3-256 hash function to compute the hash value of the user password.

As shown in Figure 2, the proposed user authentication system consists of three communication channels between the user device and salt server, ‘$d-s$’, user device and mobile device, ‘$d-m$’; and user device and controller, ‘$d-c$’. For the salt server implementation, we used Spring Boot (https://spring.io/projects/spring-boot) to build the Representational State Transfer (REST) architecture. Therefore, HTTPS was used for the channel ‘$d-s$’. For the channels ‘$d-m$’ and ‘$d-c$’, short-range communication based on Bluetooth with Serial Port Profile (SPP) was used.

For further information, the source codes of our implementation are available in the public GitHub repository (https://github.com/rymuff/keyprotection, see Supplementary Materials).

7.2. Times Taken for Key Enrollment and Authentication

As described in Section 5, our user authentication system consists of four components; user device d, salt server s, mobile device m, and controller c. In the following experiments, we used a MacBook Pro with Intel Core i7-7920HQ (3.10 GHz) running on macOS Catalina for the user device, a desktop with AMD Ryzen Threadripper 1950X (3.40 GHz) running on Windows 10 Pro for the controller, a desktop with Intel Core i7-9700 (3.00 GHz) running on Ubuntu 18.04 for the salt server, and a Google Pixel 3a running on Android 9 (Pie) as the mobile device. The evaluation results are presented in the following sections.

7.2.1. Key Enrollment Overhead

To evaluate the latency caused by the key enrollment procedure in our system, we measured the execution time of the entire procedure described in Figure 2 including the key generation time. We also performed the same measurements on the conventional user authentication system described in Section 3 to compare the overheads. For the key enrollment procedure in the conventional system, the user’s sign key was generated and simply encrypted with the user’s password. For both systems, we repeated the same experiments 100 times.

Table 1. Times (seconds) for key enrollment and authentication (C: Conventional System, P: Proposed System, S: Salt Server, M: Mobile Device).

Procedure	Key Enrollment				Authentication
Method	C		P		C		P with S		P with M
Algorithm	RSA	ECDSA	RSA	ECDSA	RSA	ECDSA	RSA	ECDSA	RSA	ECDSA
Avg.	0.326	0.014	0.658	0.279	0.383	0.319	0.422	0.392	0.634	0.437
Std.	0.209	0.002	0.295	0.038	0.140	0.030	0.051	0.038	0.344	0.222
Min.	0.086	0.011	0.324	0.235	0.294	0.270	0.355	0.331	0.303	0.266
Max.	1.133	0.025	1.849	0.469	1.646	0.400	0.688	0.530	1.624	1.278
Med.	0.282	0.013	0.597	0.262	0.359	0.320	0.416	0.393	0.506	0.344

summarizes the results.

For the proposed system, the average execution times were 0.658 s for RSA-3072 and 0.279 s for ECDSA-256 with respective standard deviations of 0.295 s and 0.038 s. For the conventional system, on the other hand, the average execution times were 0.326 s for RSA-3072 and 0.014 s for ECDSA-256 with respective standard deviations of 0.209 s and 0.002 s. Even though the execution times of our system were about 2 and 20 times longer than the conventional system, the absolute values of the performance gap were as small as 0.333 s and 0.266 s on average. Furthermore, the enrollment procedure was performed only once and can be amortized over the subsequent authentication procedures.

To find a more suitable digital signature algorithm for our system, we implemented both RSA-3072 and ECDSA-256 and compared the execution times of both implementations. As shown in Table 1, the execution time for the key enrollment procedure of the implementation using ECDSA-256 was 0.379 s shorter than the implementation using RSA-3072.

7.2.2. Authentication Overhead

We also evaluated the performance of the user authentication procedure in the proposed system. For the user authentication, the user device, d, tries to obtain the salt value either from the salt server, s, or mobile device, m, depending on the connectivity to the salt server.

We first assumed that the user device has Internet connectivity so that it can be connected to the salt server. Under this assumption, we measured the execution time of the authentication procedure using the salt server described in Figure 3. The ‘P with S’ column of Authentication in Table 1 summarizes the results of 100 measurements. The average execution times of the proposed system were 0.422 s and 0.392 s with a standard deviation of 0.051 s and 0.038 s, respectively, for RSA-3072 and ECDSA-256. As shown in Table 1, the execution time of the user authentication procedure in the proposed method was slower than that of the user authentication procedure in the conventional system, without requiring any extra communication to obtain a salt (see Figure 1). However, the execution time overhead incurred by the user authentication procedure for the proposed system was comparable to that of the conventional system, indicating that most casual users cannot recognize such a time difference.

Next, we assumed that the user device, d, has no connectivity to the salt server. In this case, the user device provides the user with a notification that the connection to the salt server has failed, and then tries to retrieve the salt value $sal{t}^2$ from the mobile device, m, via the Bluetooth connection. The authentication procedure using the mobile device instead of the salt server in Figure 3 corresponds to this case. In this case, d performs the steps from 2a to 5b with the mobile device in Figure 3. Again, we measured the execution time of this procedure 100 times. The ‘P with M’ column of Authentication in Table 1 summarizes the measurement results. The execution times of the proposed system were 0.634 s for RSA-3072 and 0.437 s for ECDSA-256 on average, which are slower than the execution times of the conventional system. In fact, this extra overhead mainly came from the Bluetooth connection setup time. In addition, this overhead is incurred only when the user device had no connectivity to the salt server, and we claim that this is a rare case in practice.

Again, for the user authentication procedure, we compared the execution times of both implementations using RSA-3072 and ECDSA-256. For the proposed system, the ECDSA-256 based implementation (0.392 s for the salt server case and 0.437 s for the mobile device case) showed a slightly better performance than the RSA-3072 based implementation (0.422 s for the salt server case and 0.634 s for the mobile device case). According to these evaluation results, ECDSA-256 would be a more preferable recommendation for our system.

8. Conclusions

We present a formally verified certificate-based user authentication method using a secondary network device to protect a user’s sign key. In the proposed method, the user’s sign key is encrypted and can only be decrypted with the assistance of a secondary device. To show the feasibility of the proposed method, we implemented a prototype with popularly used cryptographic algorithms (AES-256, RSA-3072, and ECDSA-256). Through the security evaluation using ProVerif and the performance evaluation of the prototype implementation, we confirmed that the proposed method can bring significant benefits with respect to security with only a slight sacrifice in performance (0.073 s increase with respect to the execution time for the user authentication procedure).

As part of future work, we plan to conduct real-world experiments through the deployment of the proposed method with a company that is developing industrial controller solutions, and analyze its usability issues (e.g., user satisfaction and network stability) in real-world settings.