# Challenge-Response Pair Mechanisms and Multi-Factor Authentication Schemes to Protect Private Keys
## 3 Description of a Protocol for PKI Enhancing Privacy with MFA
### Enrollment Cycle with Private Key Generation  
After completion of the enrollment cycle described in Section 1, both the Keystore and the user concurrently generate the same combined reference table CT. During this operation, the client is physically present in the office of the Keystore and downloads the \"Crypto Wallet\" on to their smartphone. An in-person cycle like that described can be carried out through video conferencing. In this case, the visual image of the user is captured during the conference, while the token is shipped to the physical address of the user. A virtual session could, for example, facilitate the replacement of a lost token. A second part of the enrollment cycle to generate the public-private key pair is shown in Figure 4. In this example, the standardized post-quantum cryptographic (PQC) Dilithium was implemented. At the end of the enrollment cycle, the Keystore makes the user ID and the public key Pk of the user \"public\" by posting it online. The user needs to keep in storage the random numbers RN\({}_{1}\) and RN\({}_{2}\), as well as C, and indeed the encrypted private key Sk. The step-by-step operations are shown below:  
* _Initial operations driven by the Keystore corporation KSC:_
* Generation of the reference table **CT**:
* **RN1\({}^{\prime}\leftarrow\)****RN1\(\oplus\)PW**: with random number **RN1**, and password **PW*
* \(n\) challenges \(\leftarrow\)****RN1\({}^{\prime}\)**: with XoF function.
* With CRP mechanisms, they generate 4 \(n\times n\) reference tables
* (1) **CT-bio\(\leftarrow\)**\(n\)*
* challenges: CRP from the facial image
* (2) **CT-T\(\leftarrow\)**\(n\)*
* challenges: CRP from a token
* (3) **CT-VT\(\leftarrow\)**\(n\)*
* challenges: CRP from a virtual token
* (4) **CT\(\leftarrow\)(CT-bio)\(\oplus\)(CT-T)\(\oplus\)(CT-VT)**: concatenation
* Generation of **Seed-a**:
* **RN2\({}^{\prime}\leftarrow\)****RN2\(\oplus\)PW**: with random number **RN2**, and password **PW*
* \(n\) challenges \(\leftarrow\)****RN2\({}^{\prime}\)**: with XoF function.
* challenges: CRP mechanism with table **CT*
* KSC transmit **RN1*
* and **RN2*
* by email to the client's smartphone
* _Operations driven by the \"Crypto Wallet\" apps in the client's phone:_
* Generation of _Seed-a_ following the same steps as above:
* _Seed-a\(\leftarrow\)__RN1_, **RN2**, **PW**, image, token, and virtual token.
* Generate a public/private key pair with Dilithium and sign M:
* Matrix-A \(\leftarrow\)_Seed-a_: with XoF function
* Vectors \(\mathbf{V_{1}}\) and \(\mathbf{V_{2}}\leftarrow\)_Seed-b_: Private key _Sk:_ {**V1\({}^{\prime}\)****V2\({}^{\prime}\)****V2\({}^{\prime}\)****V3\({}^{\prime}\)****V4\({}^{\prime}\)****V5\({}^{\prime}\)****V6\({}^{\prime}\)****V7\({}^{\prime}\)****V8\({}^{\prime}\)****V9\({}^{\prime}\)****V10\({}^{\prime}\)****V11\({}^{\prime}\)****V2\({}^{\prime}\)****P10\({}^{\prime}\)****V12\({}^
\(C\gets Encrypt(Sk,\ K)\)**:**: Encrypt **Sk** with AES and **K**  
\(\circ\) Transmit by email the message **M**, the signature **S** and vector \(t\) to KSC  
\(\circ\) Store **RN2**; **RN3**; and \(C\)  
\(\bullet\) **Final verification, and posting of the public keys**  
\(\circ\) Between seed-a that was generated from the table CT, and \(t\) from the user, KSC is in possession of the full public key **Pk: [Seed-a; t]**  
\(\circ\) KSC can verify the signature **S** of message **M** with **Pk**  
\(\circ\) KSC transmits to a Certificate Authority, or the cloud, client's ID and **Pk**  
\(\circ\) KSC only keeps record of the crypto-table of the token **CT-T**