Background
The old account structure was identified via two strings: the account's name and domain to which it belongs. As a consequence of the design of permissions, it was also necessary to have access to an account in order to register a new one in that same domain. This imposes many limitations on how Iroha could be used, particularly in the case where a generating an account offline is desirable.
The current account structure is also tied too heavily to specific strings. For example, if a user wants to change the name of their account or move it to a different domain, they cannot do it without creating a new account, transferring the keys, and then closing the old accounts.
In the interest of solving all of the above issues, as well as bringing Iroha closer to compatibility with substrate, we propose a re-structuring of the Iroha account in the following manner.
Overview
We propose identifying an account with a single key pair. The initial key exchange/generation algorithms are to be decided, however they are not to be fixed once and for the duration of the existence of the blockchain. Rather, the algorithms are to be versioned, and backwards compatible, so an account registered at genesis, can still be used 10-20 years after it was created.
The account's address is identified with the public key. As a consequence, users are not required to provide any personally identifying information at any point. Moreover, because of the way in which key generation algorithms are designed, it can be assumed that even offline-generated key pairs do not coincide.
As a result, we can accept transactions that mention a specific account's address even before that account is registered (by providing an alias) and accessed by its owner.
This opens several security issues, and entails a sweeping change across the code-base, which we shall discuss below.
Technical details
Key pair versioning
We want:
- backwards compatibility. An account registered near genesis should still work 10-20 years later if the network is still up.
- the ability to add new key pair exchange/generation algorithms.
- a method for upgrading key pairs.
As a result, Iroha must support more than one set of algorithms, and more than one kind of storage for accounts.
The versioning could be done either
- by tying the account version to the API version.
- by versioning the account with the key type/exchange algorithm
The first option has the advantage of making full backwards compatibility explicit. A user who registered an account early doesn't need to update the client in order to work with the blockchain.
The second option gives us more flexibility.
Account security upgrades
To upgrade the key pairs from an account using aliases, the user
- un-registers the alias for the original account;
- generates a new key pair with the new algorithm;
- registers the old alias to the new account;
- transfers assets from the old account to the new;
- (optional) archives the old account;
Note the following. Iroha must check for alias collisions, so step 1. is necessary. The vast majority of transactions are to use the alias rather than the public key of the account, so forwarding funds from the old account to the new is done automatically and without additional cost.
This process is either done by a single instruction, or explicitly with instructions for each step.
Custom instruction
Pros:
- Encourages frequent security updates.
- Good user experience.
- Eliminates client error in forming the transaction.
- Technically easier to do than transferring each asset one by one.
Cons:
- Complex.
- Adds ways to circumvent transaction fees in public blockchains.
Explicit
Pros:
- No extra tooling/permissions.
- Simple.
- Works well with the existing event infrastructure.
Cons:
- Discourages frequent security upgrades.
- Objectively harder to do.
- Is subject to user error.
- Can be more computationally expensive, since all assets are moved one by one.
Primary and secondary keys
One key-pair is used to identify the account, and is called the primary key. Users are advised to generate more key pairs, called secondary keys.
The primary public key is visible to everyone on the blockchain in full. As such, the primary private key can be obtained using prime factorisation and is thus vulnerable to attack. Hiding the secondary keys prevents cracking all keys in parallel, and mitigates brute force decryption attempts.
As such users are advised to opt into one or all of the following:
- Frequent and automatic expiry and replacement of secondary key pairs. Suitable for people with frequent access to the internet and a hardware wallet (Integration pending).
- Cascading encryption of secondary keys:
- The n-th private secondary key is used to encrypt the n+1-st, public key on-chain. The first secondary public key is encrypted by the first primary key.
- Bidirectional encryption of traffic.
- Restricted visibility: even knowing the primary key, but without any of the secondary keys, you cannotquery the public keys of the account.
Changes to the ISI execution
All instructions that accept an EvaluatesTo<Account> shall now not return a FindError if
- The account is specified via a public key
- The account doesn't exist; OR
- The account exists AND the account was not archived.
As a result, all instructions that check for the existence of an account before execution should check how the target account was specified, and adjust accordingly.
Account Archival
Security considerations, particularly related to identity theft must be taken into account. Specifically, one must be able to revoke access to an account temporarily, provided that the primary key had been compromised. While multi-signature transactions somewhat mitigate the problem of brute force cracking of the private key given a public key (to be able to send transactions on behalf of the account, one must crack all of the keys, not just the primary), social engineering is still a viable attack vector.
If your primary key got stolen, odds are that the secondary keys were also stored in accessible
As such, simply removing an account or de-registering it is not sufficient to guarantee that no funds will be transferred to or from said account. As a result it's necessary to introduce a new state for accounts: archived. It's a special marker state in which permissions for all operations on the account except for the de-archive instruction are forbidden. This serves two purposes.
- It's possible, however unlikely, that two generated key pairs might coincide. If there are smartcontracts which reference an account by key, rather than by alias, it is possible that someone generates a key pair and ends up having attached smart contracts.
- If the original user suspects a data breach and loss of access to a particular account, they might wish to limit access to that account. Aside from stealing funds, the account can be used for impersonating the original user.
This was not necessary originally, because the user was capable (in theory) of changing the public key of their account. As accounts are inseparable from the keys used to generate them. It is impossible to do so with the new architecture.
When an account is archived, it should be possible to reverse, provided a few conditions are met.
- the account that wishes to de-archive another account must retain the private key corresponding to the archived account. If the key is lost the account is archived permanently. To prevent a malicious actor from archiving multiple accounts, archival must also require knowing the (primary) private key of the archived account.
- During archival another account may be optionally nominated as a successor. If such an account exists, de-archival requires knowledge of both (primary) private keys. Losing either one locks the account permanently.
- After archival, smartcontracts involving the archived account fail with an error message. After de-archival smartcontracts resume operation as normal. Triggers must be given facilities to accumulate information about previously failed execution attempts. This is necessary, because archival can be used to avoid smart-contract-based payments.
- After archival, all pending transactions submitted from an archived account, but not executed at the time of archival are frozen: removed from the queue and added to a special section in the Archived account. When the archival is reversed the transactions are remembered, but not automatically submitted. Which transactions are to be re-submitted is chosen by the user after de-archival.
Changes to the Client API
The client must adapt to the new APIs of the Instructions. Additionally, since the client is likely to be the only program capable of generating a key offline, it is advisable to merge the functionality of iroha_crypto_cli into the client libraries/binaries.
The exact set of requirements to the client API is to be determined.
This RFC will be updated as soon as the RFC on offline transactions is also complete.
Offline key generation process
The key gets generated with the help of the client as discussed above. The public key is stored on-chain fully. And is fully public.
External actors are free to target the specified public key for transactions. The funds transferred to a key are debited from the sender and credited to the recipient immediately. Since the user no longer has the safety net of FindError to protect against errors in key-based transactions, users are encouraged to only use the keys as targets whenever using an alias is impossible, or impractical.
OPTIONAL: it may be worthwhile to add the option to revert a funds transfer if an account hadn't been claimed in a specified time period. At which point a smartcontract reverts the debit/credit and archives the account.