## 5 Proposed User Authentication System
### 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:  
1. For the user authentication, the user \(u\) should first enter his/her password \(\mathit{pass}_{u}\) through the application installed on the device \(d\) (see Step 1 in Figure 3).
2. To decrypt the encrypted user's sign key \(sk_{u}\), \(d\) has to obtain either one of the salts (\(salt^{1}\) or \(salt^{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}\).
3. If \(d\) is successfully connected with \(s\), \(d\) sends the salt request message containing the tuple (\(id_{u}\), \(\mathit{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 \(\mathit{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.
4. If the received \(\mathit{pass}_{u}\) is valid, \(s\) replies to the salt request message by returning the stored salt \(salt^{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 \(\mathit{pass}_{u}\) is valid, \(m\) replies to \(d\) with the stored  
Figure 2: Encryption key generation procedure.  
salt \(salt^{2}\). Without loss of generality, we assume here that \(s\) is available because further processes are the same in both cases.
5. After receiving \(salt^{1}\) (or \(salt^{2}\)), \(d\) computes \(k^{1}=KDF(pass_{u},salt^{1})\) (or \(k^{2}=KDF(pass_{u},salt^{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.
6. 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).
7. 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.