feat: persist UserStorage e2e content keys using an encrypted keyStore

[mirceanis]

⚠️ Tentative PR for early feedback gathering

Explanation

The UserStorageController e2e encryption keys are derived from a storageKey that is specific to the user profile. The key derivation function used is scrypt, with parameters recommended for password inputs. This means that it's a very costly operation (on the order of seconds on a 2024 mobile device).
These derived keys are cached in memory for the lifetime of the controller instance, but a better approach would be to use a Key Store, to persist the derived keys in a safe manner. This would avoid the rerun of the costly key derivation operation on every app restart.

This set of changes also comes at a time when we're preparing for a multi-device/multi-srp user profile, so the implementation of the KeyStore relies on the new encryption capabilities of the message-signing-snap. The snap is already used for auth and is a key component of the UserStorageController, but we are introducing some defaults here that create even more coupling between the controller and the snap.
The proposed KeyStore implementation relies on the persistable state properties and the messagingSystem available to MM controllers, so externalizing this would create some overhead, but feedback is very welcome about the approach.

References

fixes #5128

Changelog

@metamask/profile-sync-controller

• : KeyStore persistence for e2ee keys

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've highlighted breaking changes using the "BREAKING" category above as appropriate
• I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

[socket-security]

New dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/@noble/hashes@1.6.0	None	0	859 kB	paulmillr

View full report↗︎