Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.



Image Modified


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).

Most attacks on the Ethereum chain happen as a result of social engineering and user error. So we should protect against 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.It would

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.

...

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.

...