Confidential assets v1.1.4: keyless integration

[alinush]

Description

For Keyless accounts, we need to support recovering the decryption key (DK) while continuing to support the backup Ed25519 key option. This complicates things a little: using (a KDF of) the pepper as the DK will lock users out if they lost access to their OIDC account even if they still have their Ed25519 back up key.

The proposed solution is to encrypt the (pepper-derived) DK on-chain using their Ed25519 back up key. This will allow to recover the DK in both modes:

1. From the OIDC account by fetching the pepper and deriving the DK
2. From the Ed25519 backup key by fetching the on-chain ciphertext and decrypting it

We introduce new private entry function upsert_ed25519_backup_key_on_keyless_account_with_encrypted_payload for keyless accounts who have already registered a DK but are rotating their backup key and need to re-encrypt their DK on-chain.

TODOs:

• We will also need an extra private entry function for keyless accounts with backup keys who have not registered a DK. This should atomically register a DK & encrypt the DK on-chain. (This will require knowledge of the backup key.)
• What about supporting multiple confidential asset types? This may be easy: the DK is already encrypted $\Rightarrow$ we just call confidential_asset::register with it.

Minor changes

• Fix some comments in account.move and keyless.move

How Has This Been Tested?

• the trivial refactor has not been tested $\Rightarrow$ should be eye-checked
• a new private entry function is introduced $\Rightarrow$ wallets need to be aware of it & block it, or risk their users being tricked into calling it, rotating their keys and having their account stolen
• the testing is deferred to when we implement support in Petra

Key Areas to Review

Relevant changed files to review:

• https://github.com/aptos-labs/aptos-core/blob/alin/confidential-assets-v1.1.3/aptos-move/framework/aptos-framework/sources/account/account.move
• https://github.com/aptos-labs/aptos-core/blob/alin/confidential-assets-v1.1.3/aptos-move/framework/aptos-framework/sources/keyless_account.move

Some key Qs:

• The KeylessAccountStorage design presumes we have correctly thought through all scenarios for our Keyless users in Petra to be able to recover their DK (assuming no manual signing key rotation & no manual decryption key rotation, which are super-advanced features). This needs to be validated.
  • See all the scenarios for completeness here
  • This requires thinking through a lot of things
• Any bugs during the minor refactoring of upsert_ed25519_backup_key_on_keyless_account?

Type of Change

• New feature
• Bug fix
• Breaking change
• Performance improvement
• Refactoring
• Dependency update
• Documentation update
• Tests

Which Components or Systems Does This Change Impact?

• Validator Node
• Full Node (API, Indexer, etc.)
• Move/Aptos Virtual Machine
• Aptos Framework
• Aptos CLI/SDK
• Developer Infrastructure
• Move Compiler
• Other (specify)

Checklist

• I have read and followed the CONTRIBUTING doc
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I identified and added all stakeholders and component owners affected by this change as reviewers
• I tested both happy and unhappy path of the functionality
• I have made corresponding changes to the documentation