# Challenge-Response Pair Mechanisms and Multi-Factor Authentication Schemes to Protect Private Keys
## 1 Introduction  
Developing methods to protect private keys for signing or decrypting messages in public key infrastructure (PKI) applications is a vibrant field in the cyber security space. The asymmetrical cryptography underneath PKI enables two essential functions: the secure transfer of digital information through a public network, or the signing of electronic messages [1, 2, 3, 4, 5, 6]. The early cryptography methods such as RSA and elliptic curve cryptography (ECC) will be replaced over time by post-quantum cryptographic (PQC) algorithms such as CRYSTALS Dilithium and Kyber [7, 8, 9, 10]. These methods are leveraging known mathematical methods such as lattices or code computations [11, 12, 13, 14]. The generation, distribution, and storage of the public-private key pairs needed in asymmetrical cryptographic schemes is a difficult set of tasks, as the private key shouldremain totally secret. These private keys are used to decrypt the digital information encrypted with the public key, or to sign electronic messages that can be verified with the public key. Traditional applications of PKI are broad; they include securing banking cards, peer-to-peer information sharing, and electronic transactions. When combined with blockchains, PKI-based solutions enable a new class of important applications such as signing transactions with crypto currencies [15; 16; 17; 18; 19; 20; 21; 22] and blockchains [23; 24; 25; 26; 27; 28; 29]. One of the main roles of crypto wallets is to protect private keys, without risking losing them [30; 31; 32; 33; 34; 35]; existing crypto wallets are prone to security breaches [36]. By contrast, our proposed protocols are zero-knowledge and prevent opponents finding the factors sequentially. This allows the implementation of recovery protocols, mitigating the loss of one factor without weakening security. Refs. [37; 38; 39; 40; 41; 42] present various multi-factor authentication (MFA) schemes to protect private keys in PKI networks, including the use of blockchains. Our implementation integrates blockchains as part of the non-fungible token, creating a reference table that is combined with the tables generated from other factors of authentication. In addition to MFA, solutions include the use of blockchains, fragmenting and encrypting the private keys, and combining hardware with software remedies [43; 44; 45; 46; 47; 48; 49; 50; 51]. In our implementation, we elected to encrypt the private keys with an ephemeral key that we erase after the encryption cycle and can only recover with the MFAs. Encrypting the private key with a key that we store on a terminal device is not secure enough when the opponent has access to the terminal device. One method to enhance MFA security is to use Physical Unclonable Functions (PUFs), which can offer reliable authentication, and on-demand key generation [52; 53; 54; 55; 56; 57]. Rather than storing the key encrypting the private keys in the device, the key is generated with the PUF and a challenge-response pair mechanism. However, storing both the challenges and the PUF in the terminal device offers limited security, as the opponent can generate the responses, and use them to decrypt the private keys. We propose mounting the PUF on a removable token that is kept separate from the terminal device, while only the challenges are stored in the terminal device. The users have to plug the token into the device to retrieve the private key, which enhances security. The use of MFA to protect crypto wallets and other terminal devices storing private keys could be risky for users because a loss of these factors could have catastrophic effect [58; 59; 60]. In this paper, we propose methods to recover the loss of one factor of authentication. Another issue with PKI is the generation of the key pairs, which are currently controlled by service providers such as Keystores, and Hardware Security Module (HSM) providers. Here, we worry about insider attacks, and various other attacks [61; 62; 63].