...
- The easiest address to implement is exposing the full public key
- For security might prefer to expose a subset of the public key. If we use the first half of the bytes as the address, the probability of two accounts sharing an address is astronomically small (1 in 1024).
- Also for security we can use the RsDSA25519 key exchange algorithm which doesn't expose the public key at the cost of performance.
- For maximum compatibility with Substrate, we should choose the SS58 format.
...
We should also consider delineating in-code the difference between stash keys (which are attached to highly secure accounts with most if not all of an individual's assets) and controller keys.
Session keys are part of the staking infrastructure. We should support this use case, but we might want to consider deviating from the uses of sessions keys only as part of staking and not in cases of handling large lump sums in general.
Account security upgrades
...
This process is either done by a single instruction, or explicitly with instructions for each step.
Alias security
It is assumed that changing the alias of an account requires knowledge of primary and secondary keys, so gaining control of the alias is equivalent to gaining full control of the account. Security measures largely overlap, which includes account archival (freezing).
While a lot of attention is paid to software security in Ethereum, most attacks on the Ethereum chain happen as a result of social engineering and user error.
For example, one attack vector we can protect against is account aliases that are sufficiently similar, but not identical in terms of name resolution. Compare:
alice@wonderland
аliсе@wоndеrlаnd
the strings look identical, but have different UTF-8 representation: the а and е, characters are taken from the Cyrillic code page, and the two accounts have different on-chain representations.
A potential solution would be to warn the user whenever they send funds to a new address, which crosses a (dynamically computed) Levenstein distance threshold from the known recipients. We need to have a low false-positive rate, so that users are not tempted to turn off the annoying notification.
Using a new custom instruction: MigrateAccount<Account, Account>
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.
...
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 and secondary keys should not have any common source. We should allow users to use the same passphrase to generate the primary and secondary keys, but encourage users to generate a new key.
The If 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:
- Using RsDSA instead of EdDSA for the primary key. This brings us closer to Ethereum than to substrate in terms of compatibility.
- 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.
...
In the 3-rd case of data breach, the identity thief is indistinguishable from the original owner. As such it is preferable to reduce the likelihood of data breaches, rather than trying to mitigate the consequences of a tier 3 data breach. We should consider non-technical factors as well: encouraging good security practices, opting-in to features that trade security for convenience, providing good middle-grounds between security and convenience and so on.
Key collision is not a factor: It is astronomically unlikely that two ed2559 keys coincide. Specifically, it's 1 in 2256 or 1 in 1077. The probability of no two keys coinciding given that the ed25519 algorithm works as advertised is 10-69 (due to the birthday paradox) exp[-10-69 ], if there are 108 or one hundred million accounts on the same network. Even assuming that the number of historical accounts is larger, it is practically impossible to generate the same key twice.
...
- 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. Only the owner of the primary key can request archival.
- Before or 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
- It's possible to remove smartcontracts from an archived account. It's not possible to add any.
- In case 3.c, a thief gains nothing from archiving an account with a pre-nominated successor. Financial gain can still be extracted from deleting accounts (blackmail).
For point 3 to work, triggers must be given facilities to accumulate information about previously failed execution attempts (e.g. special metadata). This is necessary, because archival can be used to avoid smart-contract-based payments
...
. In principle, this would allow people to purposefully archive their accounts after benefiting from a specific arrangement (e.g. default on their loan payments). There is no blanket solution to this, however. It's
...
all up to the specific case where default occurred. For example:
- Defaulting on a loan happens outside of blockchain contexts. It is the responsibility of the loan provider to handle default.
- Recurring payments for recurring services may automatically cancel the smartcontract after a set number of failed payments.
- If the user archives the account tactically, so as to avoid specific payments it is the responsibility of the smartcontract to exchange resources atomically.
Transaction rollback
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 re-submitted. Which transactions are to be re-submitted is chosen by the user after de-archival.
...
We can freeze the transactions that are still in the pipeline and submitted from a potentially compromised and archived account and that is in line both with what banks can offer, and relatively easy to implement.
In a blockchain setting, services like Kirobo offer the option to reverse unclaimed transactions only. Claimed transactions cannot be reversed unless both parties agree to a transfer (which in case of a malicious actor is unlikely). Kirobo also uses a weak password system that is prone to user error. Reverting already committed transactions is not something that even banks do, so the utility of first-party support on Iroha networks is dubious.
Changes to the Client API
...
Offline key generation process
We might consider integrating with the pre-existing infrastructure from substrate. We should consider adding our own guide to generating key pairs; substrate has a lot of features that trade security for convenience, which might not be worth encouraging.
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 or partially 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. Most transfers should be done through aliases, and not directly through addresses.
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.
...