This proposal is part of a white paper that I am working on which I call
Accountable Blockchain.
Protection of Account By Multi-Factor Authentication over the BlockchainMulti-Factor Authentication (MFA) is not needed for the most part in decentralized currency. A secured private key is sufficient for signing transactions and as proof for identity.
The proposal provides a feature that has not previously been available for a blockchain: to be able to change the public key associated with a user account on the fly. This situation is needed potentially for three use cases:
(1) A private key has been lost because of inadequate backups.
(2) A private key has been accidentally shared or there is fear that untrusted third parties have gained access.
(3) A person prefers to change their private key on a regular basis to minimize the risk of exposure.
It is clear that adding this option, if done incorrectly, will make it significantly easier for user accounts to be compromised. This approach only makes sense if the MFA is secure and misuse of the MFA is sufficiently disincentivized.
AssumptionsThis proposal makes the following assumptions:
(1) a trusted Client Application that is private to a user, which serves as storage for private keys, and can send requests to a public network of registered nodes which manage the blockchain.
(2) a public network of registered nodes that accept requests from client applications or other registered nodes. Each node has a private key which is not shared and a public key which is publicly available. The public key can be used to validate any digital signature from the node.
(3) a reputation system that provides incentive for registered nodes to be well-behaved and which can be used to select highly-reputable nodes to do special functions for a fee. I will not detail the reputation system in this proposal. I will detail my assumptions about reputation in a future post. For purposes of this proposal, it is assumed that the proposal is ONLY workable if the reputation system is sufficiently effective.
(4) a script repository where scripts can be run by name/version with the following property. A script can be generate a public/private key in the fly without leaking the private key. The script can reliably send the private key through a channel (email or SMS), publishes the public key as a transaction in the blockchain, and loses all information about the private key when it stops running.
Identity by User Account represented by a Public KeyThe User Account is a non-fungible token that is associated with a timeline of public keys (each public key is qualified by a starting timestamp which corresponds to a blockchain id in the blockchain, the point in time where the public key was set up) and a set of at least 3 (name, hash) pairs. The hash does NOT correspond to a password. It will correspond to the value of the channel used for validation. It will include a prefix, the exact value, and suffix. The prefix and suffix are needed to complicate a dictionary attack.
The timeline will grow each time the public key is changed. In this way, the timeline can be used to validate all transactions that have already been completed in the blockchain.
The set of pairs will be used to validate ownership of the account. More details on this later in this proposal.
There are three flows that I will detail: (1) Setting up a user account, (2) Changing a Validation Channel, and (3) Changing the current Public Key. After this, I will end the discussion with (4) Implications and Security
Setting up a User AccountThe client application will send an Account Set Up Request to a known node in the public network of registered nodes.
The Account Set Up Request will include the IP address of the client (to receive the response), a uniquely generated account id (NFT), a newly generated public key which will be active once the account is created, and a set of at least 3 name/hash pairs, and a minimal payment that has been signed by an existing public key to pay for the set up.
If for any reason the NFT already exists, the request will fail. If the signed payment is not valid, the request will fail. The user account is set up when a transaction succeeds. The block id for the block will be serve as the timestamp for the first public key in the timeline. The name/hash pairs will also be saved in the transaction.
The client application receives a receipt which either indicates that the request failed or a receipt that the transaction has been accepted into the blockchain.
The name should not signify the type of channel, the prefix, or the suffix.
Adding a new Validation ChannelThe client application can add a new validation channel with an Account Add Channel Request.
The Account Add Channel Request will include the Account Id (NFT), the new name, the hash of the new channel signed by the current private key associated with the account, and a minimal fee signed by a public key.
As long as the hash of the channel is signed by the current private id, the channel is added as a transaction added to the blockchain.
Changing or Deleting a Validation ChannelThe client application will send an Validation Channel Update Request to a known node in the public network of registered nodes.
The Validation Channel Update Request will include IP address, the account id (NFT), the name of the channel to changed signed by the current private key, and a minimal payment that has been signed by an existing public key to pay for the change.
The node receiving the request now forwards the received information to a highly reputable node. The highly reputable node initiates a short-running script that will do the following:
(1) Generate a private key/public key on the fly that identifies the script context and a second private key/public key that will validate the user over the channel.
(2) The script now publishes a transaction that includes the signed fee, the public key identifying the script (so the client application can validate a request to satisfy the hash as legitimate), the signed name of the channel to change, and the public key that can be used to validate the change.
(3) The script provides a prompt to the client application with a signed hash of the prompt showing that prompt is from the legitimate script. The prompt asks for the prefix, exact channel, and the suffix.
(4) The user must respond within a short period of time or the client application will need to make a second request with a new minimal payment. The user now enters the prefix, exact channel, and suffix. The script can now validate the user inputs against the hash. If the channel details validate, then the script sends the validation private key over the channel. Once the private key is sent, the script completes.
(5) The user using the private key received can use the client application to submit an Update Channel Request. The Update Channel request includes the account id (NFT), the name of the channel (which can stay the same or be a new name), a new channel hash signed by the private key received and signed by the current private key of the user, and a minimal fee for the change signed by the private key. It is also possible if there is more than 4 channels, that the channel can be removed without being replaced.
(6) The request is then validated against the public key in the transaction associated with the channel validation and the current public key associated with the account.
Changing the current Public KeyThe client application will send an Validate All Channels Request to a known node in the public network of registered nodes.
The Validate All Channels Request will include IP address, the account id (NFT), and a minimal payment that has been signed by an existing public key to pay for the change. The payment schedule should limit the frequency of these attempts. The price should go up significantly if the next request occurs too soon.
The node receiving the request now forwards the received information to a highly reputable node. The highly reputable node initiates a short-running script that will do the following:
(1) Generate a private key/public key on the fly that identifies the script context and private keys/public keys for each channel.
(2) The script now publishes a transaction that includes the signed fee, the public key identifying the script (so the client application can validate a request to satisfy the hash as legitimate), the name and public key generated for each channel that needs to be validated.
(3) The script provides a prompt to the client application with a signed hash of the prompt showing that prompt is from the legitimate script. The prompt asks for prefix, exact channel, and the suffix for each channel that needs to be validated.
(4) The user must respond within a short period of time or the client application will need to make a second request with a new payment. The user now enters the prefix, exact channel, and suffix for each channel. The script can now validate each of the the user inputs against each of the hashes. If the channel details validate, then the script sends each validation private key over each channel. Once all the private key are sent, the script completes.
(5) The user gathers all the private keys and can now issue the Update Public Key request. This request includes the account id (NFT), the new public key to be used with the account, the name of each channel signed by the private key received over that channel, and a minimal fee signed by a private key of an account that can pay the fee. If a user has lost their private key, then they will need to use another account to pay for the fee.
(6) The request is then validated against the public keys in the transaction associated with the channel validation. If all the signatures validate against the public keys added in the validation transaction, then the transaction proceeds. Once the transaction is successful, the new public key has been added to the timeline of public keys.
Implications and Security Because changing the public key is done in the blockchain itself, the changing of the public will not occur right away. The process is designed to occur after any transaction that was signed before the Validate All Channels Request. Any transaction signed with the old private key after Update Public Key Request, should be treated the same as any time a person uses an invalid private key for a transaction.
There are numerous assumptions in this proposal. Can a highly reputable node be trusted to run a script without peaking at the private keys generated? Can the reputation system be trusted to identify highly reputable nodes? It is not my purpose in this proposal to answer these cases. I will work on them at a future time. My goal here is to propose that if a reputation system can be trusted, if scripts can be run without leaking the private key, and if the user uses only secure channels (which may be a big if), then this approach will allow a user to change the public key (and hence, the private key) in a secure way.
All comments and questions are welcome. Thanks very much for reading through this proposal.
