## 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.