metamask-extension icon indicating copy to clipboard operation
metamask-extension copied to clipboard

wip - experiment with a secure use state encrypted

Open weizman opened this issue 2 years ago • 1 comments

Inspired by a thought introduced to me by @NicholasEllul

useStateEncrypted

Motivation

Not that this is an actual current threat, but rather a potential one:

Sensitive information (along with non-sensitive) is being stored into React states within the app, under the assumption that:

  1. We write our code so that sensitive info isn't leaked outside of the scope of our functions;
  2. React isn't breached;
  3. React legitimately manipulates the information we pass it using intrinsics that aren't "tamperable" thanks to LavaMoat+SES.

However, why pass a third party code such sensitive information if we don't have to? Yes - even when that third party is as trusted as React.

Implementation

The idea is really simple (and works rather smoothly with MetaMask as-is), just create a wrapper useState that encrypts the information before passing it on to the real useState and decrypts it back only when is popped back to the component by React.

In this implementation we use a simple XOR for encryption with a static fake key we declare in the component level as a PoC.

To make this implementation complete, we need to:

  1. Consider a better encryption function to eliminate the possibility for breaking it, but most importantly:
  2. Think of a way to communicate a key to the useStateEncrypted hook safely

Regarding section(2), the key obviously must change among different MetaMask instances but constant for each instance. I assume it would be best to store it somewhere in the backend and allow the frontend access to it only once, for the first requester. Also, the key will be fetched and stored in a mechanizm that does not make use of any third party code - not React neither anything else, for security reasons.

That way, when the app first loads, it immediately obtains control over the encryption key before compromised code within the runtime gets access to it too.

The key should be generated and stored to the storage of the extension at its first ever run, and be naturally disposed when the app is uninstalled (they key isn't important and therefore is highly disposable, it's just a 2nd line of defense for runtime)

weizman avatar Dec 19 '23 14:12 weizman

This PR has been automatically marked as stale because it has not had recent activity in the last 60 days. It will be closed in 14 days. Thank you for your contributions.

github-actions[bot] avatar Feb 17 '24 16:02 github-actions[bot]

This PR was closed because there has been no follow up activity in the last 14 days. Thank you for your contributions.

github-actions[bot] avatar Mar 02 '24 18:03 github-actions[bot]