## 5 Proposed User Authentication System
### 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 \(\mathit{pass}_{u}\) to generate the encryption key \(k=\mathit{KDF}(\mathit{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:  
1. The user \(u\) enters his or her password, \(\mathit{pass}_{u}\), through the application installed on the device \(d\).
2. 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.
3. After \(d\) connects to all of the servers, an additional two random salts, \(salt^{1}\) and \(salt^{2}\), are generated.
4. \(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 \(\mathit{pass}_{u}\), and system generated (random) parameter \(salt^{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(\mathit{pass}_{u})\), \(\mathit{salt^{1}}\)) into its user database. In a similar manner, the triple (\(id_{u}\), \(HASH(\mathit{pass}_{u})\), \(salt^{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 \(cert_{u}\) to controller \(c\) (see Step 4c--1 in Figure 2). \(c\) then stores the received certificate \(cert_{u}\).
5. Using \(\mathit{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}=\mathit{KDF}(\mathit{pass}_{u},salt^{1})\) and \(k^{2}=\mathit{KDF}(\mathit{pass}_{u},salt^{2})\), respectively (see Steps 5a and 5b in Figure 2).
6. After generating \(k^{1}\) and \(k^{2}\), \(sk_{u}\) is encrypted with them, i.e., \(\mathit{ENC}(k^{1},sk_{u})\) and \(\mathit{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.