Written by: Colin, and special thanks to Suneal for the comprehensive discussions.
In today's digital world, maintaining the privacy of messages is a major concern for everyone. MetaMail has developed a new email encryption method that is tailored for users with wallets compatible with Ethereum sign-in.
Our focus while making this protocol was to make it secure and easy for anyone to use. We made sure that your emails are fully protected from one end to the other, and we also made it simple so that using secure email doesn't feel complicated. You can send and receive safe emails without a hassle.
Email Protocol Layer End-to-End Encryption:
Aim to incorporate encryption directly within the email protocol.
Going beyond transport layer security like HTTPS, our method ensures email privacy even on insecure networks or servers.
Email Integrity Verification: We focus on two critical aspects:
Consistency: Ensuring emails remain unchanged from sender to recipient.
Authentication: Verifying that only the sender can claim to have sent an email, preventing forger by others.
Challenge: The primary challenge is to develop a protocol that is both universal and effective, securing communications within the email protocol layer while also maintaining the integrity of the message content.
Solution: Acknowledging the complexities of traditional designs like the Pretty Good Privacy (PGP), which is too complicated for lightweight email providers (e.g., public goods or personal email servers) to support, we are taking inspiration from the robust signature mechanisms found in Ethereum's ecosystem (e.g., transaction signatures, validator signatures, and as well as Ethereum Improvement Proposals (EIPs) including EIP-191, EIP-712, EIP-4361) alongside the tricks of modern protocols such as Signal. In MetaMail, users leverage their Ethereum or Ethereum-compatible blockchain wallets to sign emails, ensuring the integrity of the message. They also use a unique set of message encryption keys derived from their wallets for end-to-end encryption.
Ethereum key format compatibility for seamless integration with user wallets.
Support for various wallet clients like MetaMask, Phantom, and Coinbase Wallet.
Streamlined email viewing and sending with fewer wallet pop-ups.
Challenge: As far as we know, there's no widely-used Ethereum Improvement Proposal (EIP) for straightforward end-to-end email encryption. EIP-5630, which attempts to support address-to-address encryption and decryption, remains stagnant and lacks widespread adoption among wallet clients. In addition, its implementation necessitates frequent pop-up interactions for each email encryption or decryption action, which is inconvenient for users who want to browse through numerous unread emails quickly.
Solution:
Standard Wallet Features and EIP Integration: Design a protocol that leverages basic wallet signing capabilities and integrates with existing Ethereum Improvement Proposals (EIPs) such as EIP-712 (structured data hashing and signing) and EIP-4361 (sign-in with Ethereum) for secure message signing and encryption processes.
Enhanced Security through Decoupling: Message encryption keys are fully segregated from the wallet's private key, bolstering security measures.
Independent Key Generation: The message encryption keys are independently generated using elliptic-curve Diffie-Hellman (ECDH). These keys have no derivative link to the wallet's private key, ensuring a secure and independent key creation process.
Public Accessibility and Secure Storage: The public key is stored in publicly accessible storage, allowing anyone to retrieve and use it for encryption purposes. The private key is also stored in an encrypted form to prevent unauthorized access. Note that this is a convenience provided to the user and it is not mandatory — users can manage their message encryption private keys on their own theoretically.
Key Encryption and Operational Security: The encryption key that encrypts and decrypts the message encryption private key is transiently derived from the user's wallet private key. It's used solely for decrypting the message encryption private key as needed and not stored in any persistent storage, maintaining its confidentiality and security.
Asset Security: By isolating the message encryption keys from the wallet's private key, user assets remain secure and are not jeopardized by potential message key exposure. This separation ensures that the wallet's private key, which authorizes asset transactions, is never at risk.
Challenge: Facilitate end-to-end encrypted messaging that is compatible across different protocols, allowing for the secure exchange of encrypted messages among various email service providers, even for personal email servers.
Solution: Develop a framework to enable secure message exchange across mail services.
Public Key Sharing Mechanism: Set up a public key distribution system that allows other mail services to easily obtain MetaMail users' public keys for message encryption.
Sufficient Metadata: Ensure the recipient can access the necessary metadata from the mail header or the sender's keystore to decrypt the message properly.
Interoperability Guide: Offer a guide to assist other services in sending encrypted emails to MetaMail users and in processing encrypted emails received from MetaMail.
Now, let's dive into the technical solution that MetaMail employs to address these challenges and provide a secure, user-friendly encrypted email service.
When users sign in, the server will generate a random challenge. Users need to sign the random challenge to prove they truly own the private key of the wallet. This random challenge is updated each time to prevent eavesdropping and replay attacks.
After sign-in, a crucial component of MetaMail's secure email system is the use of two types of encryption keys: message encryption keys and storage encryption keys.
Message Encryption Keys: This key pair is generated locally within the user's browser when signing into MetaMail for the first time, users can also update these keys and publish new keys. In the current implementation, the generated key pair is a point on an elliptic curve that conforms to the ECDH standard for secure key exchange.
Storage Encryption Key: This symmetric key is also generated within the browser. The generation process includes:
Salt Generation: A random salt is created locally in the browser.
Signing the Message: The wallet's eth_signTypedData (EIP-712 signature) interface is used to sign a hint message that includes the generated salt.
Key Derivation: The storage encryption key is derived using a keccak256 hash of the above signature, which can be represented as keccak256(eth_signTypedData(hint-message-with-salt)).
To safeguard the private key while allowing for convenient storage access, the private key is encrypted by the storage encryption key, which ensures that only the user with the wallet's private key can generate the storage encryption key by signing the hint message with salt, then can decrypt the message encryption private key and use it. The keystore contains plaintext public key, encrypted private key, salt (used to generate storage encryption key locally), and metadata that describes the keys. It can be stored in publicly accessible storage (e.g., Ethereum, IPFS, or cloud storage). This approach facilitates access for both the keystore owner and other individuals to access the key info.
Users must sign the uploaded keys to provide a verification mechanism. This signature allows other users to confirm the authenticity of the public key, ensuring that it was indeed uploaded by the claimed owner. The keystore owner can also use this signature to verify that the content is not changed when fetching it from storage.
In the current implementation, MetaMail's backend is the repository for the messaging-related keys, storing the salt, public key, encrypted private key, and metadata. When a user initiates an email, the frontend system retrieves the intended recipient's public key via the backend's accessible interface, enabling the sender to encrypt the message.
Metadata for Cross-Protocol Compatibility Consideration: The above-mentioned metadata includes information such as the key generation algorithm, curve type (if using an elliptic curve), key format, encoding method, and intended uses of the keys. For instance, the metadata may specify the use of the Elliptic Curve Diffie-Hellman (ECDH) algorithm with the P-384 curve, pkcs#8 and spki formats for private and public keys respectively, hexadecimal encoding for both key types, and the application of the keys for operations like deriveKey. Furthermore, it identifies the resulting derived encryption algorithm, such as AES-GCM. Submitting this metadata aims at facilitating integration with third-party services, allowing them to accurately recognize and utilize the key pair according to the defined cryptographic standards.
First-Time Sign-In: New accounts encounter specific restrictions due to the absence of encryption keys.
Receiving Encrypted Emails: Since other users cannot access the new user's public key, they are unable to send encrypted emails to the new user.
Sending Encrypted Emails: Without the ability to perform Elliptic Curve Diffie-Hellman (ECDH), new users cannot send encrypted emails to others.
To address these challenges, users are required to generate their message encryption keys during the initial sign-in with two extra wallet signatures. The procedure is as follows:
Local Key Generation: Users create their message encryption keys within their browsers.
Storage Encryption Key Creation (First Signature): Users perform the first signing operation to create a storage encryption key. This involves signing an EIP-712 formatted message containing a salt, followed by processing with the keccak256 hash algorithm. The formula used is keccak256(eth_signTypedData(hint-message-with-salt)).
Keystore Upload (Second Signature): To confirm the authenticity and integrity of the keys, users perform a second signing operation. This procedure ensures that any users (including the signer at a future time) can verify the signer and integrity of the keystore contents.
Subsequent Sign-Ins and Keystore Access: When keystore access is required (e.g., for reading or sending encrypted emails), the user's browser requests the keystore from the backend, which includes:
Plaintext Public Key: For encrypting messages.
Ciphertext Private Key: For decrypting messages.
Salt: The seed to generate the storage encryption key.
Signature: Verify the content integrity of the keystore.
Other Info: Details such as keystore submit date, keystore metadata, etc.
The user then signs the hint message with salt to produce the storage encryption key, decrypts the ciphertext private key for use, and enjoys the benefit of "zero wallet interaction" regarding encryption and decryption. The user can also verify the integrity of the keystore using the signature.
If a user's message encryption keys or storage encryption key is leaked, they can mitigate the issue by generating a new set of keys:
For message encryption keys, the user would create a new key pair and upload a new keystore. This effectively revokes the old key pair and establishes the newly generated keys as valid for future encrypted communications.
For the storage encryption key, the user can generate a new salt and sign a new hint message to derive a new key. They would then use the new storage encryption key to re-encrypt their message encryption private key and upload new message encryption keys.
It's important to note that if the storage encryption key is leaked, it should be assumed that the message encryption keys are also compromised. This is because the storage encryption key is used to encrypt the message encryption private key, and a leaked storage encryption key could allow an attacker to decrypt and obtain the message encryption private key. Therefore, in the event of a storage encryption key leak, it is crucial to generate and upload new message encryption keys along with updating the storage encryption key.
Above all, with the secure message encryption keys in place, MetaMail enables users to send and receive encrypted emails. Let's explore how MetaMail handles encryption and signing during the email sending and receiving processes.
When sending an email to Bob:
Alice generates a one-time encryption key locally, unique for each email.
Alice uses the one-time encryption key to encrypt the email content through Advanced Encryption Standard (AES).
Alice engages in an Elliptic Curve Diffie-Hellman (ECDH) key exchange using Bob's publicly available message encryption public key and her message encryption private key, deriving the symmetric key.
Alice uses the key derived from the above ECDH process to encrypt the one-time encryption key using AES and writes the encrypted key in the meta_header field of the sending email.
In cases where an email has multiple recipients and CC'd individuals, the process can be considered as Alice sending emails to Bob1, Bob2, ..., Bobn, but adding related information within one email.
Alice signs the email using eth_signTypedData (EIP-712) to ensure the integrity and authenticity of the email.
eth_signTypedData?eth_signTypedData offers a more user-friendly display of structural information, making it easy for users to recognize the fields being signed. Common fields when signing an email include from, to, date, subject, text_hash, html_hash, attachment_hashes, encrypted_encryption_key_hashes, encryption_public_key_hashes, etc.
Upon receiving an email from Alice, Bob uses the verify function of EIP-712 to recover the signer's address. This confirmation ensures that Alice genuinely sent the email, and the mail content has not been changed during transmission.
When receiving an email from Alice:
Bob locates the encrypted encryption key corresponding to himself in the meta_header field.
Bob engages in an Elliptic Curve Diffie-Hellman (ECDH) key exchange using his message encryption private key and Alice's publicly available message encryption public key to derive the symmetric key.
Bob decrypts the encryption key using the symmetric key derived from the above ECDH process.
Bob uses the decrypted encryption key to decrypt the email content.
In summary, MetaMail's technical solution provides a comprehensive, secure, and user-friendly end-to-end encrypted email system. As MetaMail continues to evolve, there are several points to consider for future improvements and enhancements.
Evaluate the user experience in MetaMail of Sign-In with Ethereum (EIP-4361) and decide on whether and how to integrate support for it.
Provide support for shared email accounts among multiple users with their signing keys, such as an account abstraction (AA) wallet. Some shallow considerations include:
Any owner of AA wallet should be able to sign in with the AA wallet address, and then decrypt and view emails.
During the signing process, consider threshold signatures (M out of N) that represent an email sent from the AA wallet. It should allow for the AA wallet to set such thresholds, or reuse the wallet's threshold in some sense.
The email can be encrypted using one of the wallet holder's signing keys and by default CC the other wallet owners, ensuring that the email can be decrypted and seen by all AA wallet owners.