NokNok Account Recovery Protocol.md

NokNok Account Recovery Protocol

Applications that implement the NokNok Authentication Protocol become central to authentication, PII sharing, and access to a plethora of systems, and thus especially vulnerable to physical attacks and loss of their PKKs

This paper addresses the safeguarding of a PKK and its potential recovery using an approach that will feel natural to users

Business Context

Reliance on a PK for authentication on foreign systems benefits users with the safest, most secure mechansim ever invented. On the basis of this new-found trust in authenticators, users are likely to depend more heavily on the technology, placing more and more critical information in the system under the conviction that it's safe. This means that authenticators across time will become rich honeypots

The safety of the PK itself, however, remains subject to the same set of physical security issues we currently face. In an increasingly hostile world, physical attacks on the authenticators become more attractive, which also remains an unsolved problem

Additionally, the reality of our world is that users lose things. The phone falls off the boat, it gets left behind in a club, it drowns in a toilet. To properly protect users we must device mechanisms that prevent loss of the digital identity the PK represents

Analysis

There are two primary scenarios we must consider, which vary in likelihood and require different approaches:

Accidental Loss

Users that lose access to their authenticators where one can be guaranteed these have not fallen into the hands of an attacker need not worry about the additional risk of compromised systems but will suffer from loss of service. In this case recovery of the PK is sufficient and the timing of such is less critical

Theft

In cases where the possibility of theft exists, there is also an urgency to revoke access to the lost authenticator, lest it be used to gain access to critical systems

Authenticators offer OS-level security measures such as PIN codes, fingerprinting and/or facial recognition. These methods present varying degrees of challenge to an attacker but with sufficient time and resources may be defeated. Additionally, autheticators ought to provide users with an additional layer of application-level security, which will also retard the efforts of an attacker

However, one must assume it is merely a matter of time before access to the PK is achieved, and thus the protocol must provide a mechanism for the victim to revoke the access the authenticator provides. Such a mechanism necessarily requires authentication of the user on a different device, or the authentication of an attorney

Recovery Mechanisms - Current Issues

At present, the sole recovery mechanism for a PK consists of saving the BIP-39 keyphrase used to generate the PK. This is the case, even and especially with, hardware wallets

But safeguarding this phrase represents in itself a security risk as anyone with said phrase will have access to the PK. Users therefore are at a quandary for how to store it and little to no guidance has been provided in the crypto space for how to properly secure this most valuable piece of information. Of course, access to the stored phrase may also represent a significant problem, as discussed below

Storing keyphrases

Several approaches are bandied about on the net about how to accomplish this:

• Password Managers - These applications are designed to keep secrets but are themselves accesible through the internet and thus the target of sophisticated attacks, which defeats the security hardware wallets are supposed to provide to begin with. For this reason their use is generally discouraged by crypto-savvy users
• Metal plate - Printing the keyphrase on metal plate seems better than writing it on a piece of paper as the latter burns, mildews and fades across time. However, anyone with access to the plate can read it and gain access to the PK. Also, a metal plate can be lost
• Multiplicity - The printing of several metal plates stored at different locations would seem better in case of the loss of one but merely increases the risk of exposure
• Word orders - Rather than printing the words in the BIP-39 phrase in the correct order, a rearranging of the order may be done, such as printing the words in reverse order, swapping two words in the phrase, or swapping blocks of words. This would make the phrase inaccessible to an unauthorised party but may also deny access to the owner, lest the method used to rearrange the order is also noted or remembered, neither of which are good solutions
• Segmenting - Rather than printing the entire passphrase on a single plate, the phrase should be segmented and printed on multiple plates. Many copies of these sets could then be made and scattered in safe places such that upon need for the original phrase, they can be reassembled. This, of course, presents the problem that any one missing piece prevents the reassembly of the phrase and thus access to the PK may be lost
• Encryption - Encrypting the phrase is feasible but merely pushes the can down the road as the encryption key itself now needs to be safely stored and retrievable

As is evident from the above, attempts at safeguarding the BIP-39 phrase in the physical world present significant challenges and are ultimately insecure. The natural solution would, of course, be the use of cryptographic methods

Accessing keyphrases

Presuming safe storage of the keyphrase, its access may also become problematic, given physical accessibility issues

Consider that a user losing his authenticator whilst travelling abroad will not have access to the phrase stored in the safe at home. At that point reliance on a possibly untrustworthy third party may become necessary, also granting access to other valuables

In cases where metal plates were stored in secret places, disclosure of such locations to third parties also creates risk where communications have been compromised. Of course, storing the plates in itself poses the risk of surveillance, as does retrieving them

Finally, whereas in the case of PK loss, recovery is sufficient, in the case of theft it isn't as an attacker may access critical systems and user recovery does not imply revocation of such access for the attacker

Proposed Solution

How does any system know that I am who I say I am?

The answer: it doesn't. When using public-key cryptography, all systems know is that a PK is responsible for a signature, irrespective of who may have agency over its creation. This problem is equally true of the username/password approach, where no system can know the person entering the information is the actual owner of the account. For example, sharing one's credentials with a secretary means they can access an account without the system being aware of that fact

So if the private key is the ultimate determinant of identity and it is lost, is there a way to recover identity?

The answer: yes. Since identity is a real-world concept, what we need are oracles -- entities that will represent to the system that a given user is bound to a given private key and the ultimate arbiter of its use

The solution therefore is to create a web of trust whereby the responsibility for determining ownership of a PK is decentralised and granted to trusted oracles. This, of course, is something only the user can and should determine

Protocol Specification

The solution can be described as two separate workflows:

• the authenticator app ("App") performs an initial setup during which the PK is segmented and distributed to partners ("Oracles") known and trusted by the user ("User"), and
• the App reassembles the PK from said Oracles

Initial Setup

1. During the install and configuration process, the App will conduct a discovery process of System users ("Contacts") connected to the User. This could be achieved via access of the local directory of contacts, integration with Facebook, LinkedIn and other social media networks, or merely by allowing the user to enter in the identification of such contacts
2. The App will request User to nominate at least {SEGMIN} of the contacts found, as Oracles
3. The PK will be segmented into the lesser of {SEGMAX} and the number of Oracles available, the {NOS}
4. Each segment will be assigned to one Oracle
5. When more than {SEGMAX} Oracles are nominated, each segment is assigned to more than one Oracle in round-robin manner
6. Segments will be stored on the blockchain, encrypted using the public keys of the Oracles assigned to them

Key Reassembly

1. In case of loss of the App, User may acquire a new hosting device, and reinstall the App
2. Upon installation, App will present User with the choice to recover identity
3. To manage recovery the App will message one Oracle for each of the PK segments, requesting that each verify the identity of the User via direct personal contact e.g. a phone call or e-mail querying whether the request for recovery is legitimate
4. For each segment, if the corresponding Oracle does not reply within {RLEN} minutes, the next Oracle assigned to the segment is contacted
5. Upon verification, Oracles will certify their knowledge of the need for recovery to their Apps, which will decrypt their stored key segment and transmit it securely to the User's new App
6. When all the segments have been received, the PK can be reassembled and service restored to User

NOTES

• The value {SEGMIN} represents the minimum number of segments allowed for a key. It is set to 2 since allowing a single Oracle to hold the entire key represents a security risk where the holder can access User accounts. At 2, a risk of collusion between the holders exists but that is sufficient low due to allegiance to User and this risk is reduced as the value increases
• The value {SEGMAX} represents the number of key segments. As key recovery requires contacting the segment holders, this number should not be too large but cannot be less than {SEGMIN}
• {NOS}: number of segments
• {RLEN}: reply length, the number of minutes to wait for an Oracle to reply. A reasonable value would be about 10min

Key Revocation

1. In the case of a compromised key, the User may contact at least {NRO} of his Oracles and request that the key be revoked
2. The App will present Oracles with a mechanism to attest to the need for a revocation
3. Oracles may only revoke keys for which they hold a segment
4. The System will revoke a key when the minimum of {NRO} attestations are made
5. Revocation is accomplished by changing the Hash of the public key stored in IPFS associated with the User's NokNok ID identifier
6. Websites and other authenticating clients are tasked with verifying, before granting access, that public keys in their possession are valid, which may be done by retrieving the Hash associated with the NokNok ID received and replacing the local copy when needed

NOTES

• {NRO}: number of revocation oracles. The User should be able to set this value but a setting of 1 would allow any Oracle to revoke the User's access, which poses a risk in case of changing allegiances. For this reason, a minimum value of 2 is recommended as revocation requires collusion

Conclusion

The safeguarding of keys will become, in the new world of web3, the single most important problem to solve. It represents trillions of dollars worth of possible losses and the destruction of confidence in systems. It is key that it be solved and NokNok holds the solution

Glossary

The terms listed below are used in this document to mean the following:

Term	Definition
Attorney	a person acting on behalf of another
OS	operating system
PII	personal identification information
PK	private key
PKK	private-public keypair
System	the NokNok infrastructure