Skip to content

Latest commit

 

History

History
38 lines (21 loc) · 2.16 KB

encryption.md

File metadata and controls

38 lines (21 loc) · 2.16 KB
Raw

Encryption

Communication

All data transferred between MetaMask Desktop and the MetaMask extension is encrypted, specifically all the background JSON-RPC requests and responses.

This is primarly achieved using AES-GCM with a 256-bit key provided by the Web Crypto API in the browser, and the node:crypto implementation in the Electron application.

The symmetric keys are initially transferred using ECIES provided by eciesjs.

All related code resides in the @metamask/desktop package so it can be defined only once. The core class performing the encryption is the Encrypted Web Socket Stream.

Handshake

Whenever the MetaMask extension connects to the WebSocket server within MetaMask Desktop, it first performs a handshake process to initialise the encryption by generating the required keys.

This includes the following steps, each performed by the extension and then the Electron application:

  1. Send HSK.
  2. Send randomly generated ECIES public key.
  3. Send randomly generated AES-GCM 256 bit key encrypted with the received ECIES public key.
  4. Send DNE encrypted with AES key.

Both of the WebSocket streams are corked and paused until the handshake is complete.

Each step is automatically retried after 1 second.

The handshake process times out after 10 seconds.

Storage

While paired with the MetaMask extension, MetaMask desktop stores all MetaMask state in the filesystem in the application data directory.

All private keys remain encrypted as in the extension, but as a further security measure, the entire file is encrypted again using AES-CBC with a 256-bit key.

The encryption itself is powered by electron-store, but the key is stored securely using safeStorage which uses the operating system keychain to prevent unauthorised access.

This code is found in the Obfuscated Store class.