Threat model

Introduction

End-To-End handles key management and provides end-to-end encryption, decryption, signing and verification capabilities to Web users. As end-to-end encryption is implemented differently in various other solutions, it is necessary to precisely describe the threat model End-to-End operates in. This document lists End-to-End user assets that we protect, and identifies threat sources which might compromise the user’s privacy.

Assets

End-To-End deals with the following sensitive assets:

• Keyrings
  • Secret keyring - OpenPGP secret key(s), certifying user identities. Secret keys are used to decrypt received and sign the sent messages. These might also include one or more user OpenPGP identities (e-mail addresses), each certified by a secret key. The ownership of such keys implies the user is capable of assuming such identity (the validity of such identity is decided by other users).
  • Public keyring - List of OpenPGP Transferable Public Keys imported by the user into End-to-End. Keys in the public keyring are used to encrypt messages to other recipients and verify message signatures. Simply the presence of a key in the user's public keyring implies the user trusts it. This also includes all user identities for which a public key exists in the Public keyring. This contains identities of the recipients that the user has sent messages to and/or imported the OpenPGP keys of. This is analogous to the list of contacts of a user.
• Messages
  • Plaintext messages and drafts - Plaintext content of messages encrypted to user's public key(s) and the plaintext content of draft messages composed by the user.
  • Messages metadata - Subject and recipients of the encrypted messages, including OpenPGP key IDs of the message recipients, as well as encrypted message attachment filenames. Just like in other OpenPGP-in-webmail implementations the metadata is disclosed to the web application for convenience (Subject) and the purpose of routing the encrypted message to its intended recipients. RFC 4880 clients traditionally encrypt each message attachment separately, exposing number of attachments, their filenames and ciphertext length to the e-mail providers. We follow that approach. In the current version we do not remove the key IDs (gpg --throw-keyids) from the encrypted messages.

Threat sources

The following adversaries may interfere with End-to-End in order to get access to the protected assets:

1. Web application. Web application used to send and receive e-mail messages or other messages protected with OpenPGP. Client side code of the web application may be vulnerable or altered purposefully in order to attack End-to-End users. User may be using multiple web applications written by different providers (e.g. Gmail, Yahoo! Mail, Hotmail). It is assumed the web application needs the access to messages metadata in order to deliver the messages (e.g. recipient e-mails need to be exposed for the message to be sent over SMTP).

2. Keyserver. Malicious or compromised OpenPGP keyserver. For an in depth threat model of End-to-End keyserver integration, check this document.

3. Man-in-the middle. Attacker that has the ability to inspect and alter the SMTP/HTTP/HKP protocol traffic, circumventing or disabling the transport layer encryption. MITM attackers can modify the web application code to perform large scale or targeted attacks.

4. Other Chrome apps and extensions. All Chrome Extension installed in the same browser profile as End-to-End. Extensions may have different permissions listen upon extension installation. In this threat model we assume extensions have all the permissions available in the platform, including the permissions to alter any web application and tamper with HTTP traffic. Such Chrome extensions implicitly have the capabilities to act as a man-in-the-middle and web application threat source.

A lot of OpenPGP-in-the browser solutions do not include Chrome extensions in their threat model or assume that extensions architecture provides enough separation between different extensions and apps. We have found that it's unfortunately not the case. Since creating the first version of the extension we identified a few ways to exfiltrate assets protected by a Chrome extension using other malicious extension or Chrome App. Given that the extension will most likely be used in browser profiles with multiple other extensions and apps we have no control over, we feel that it is important to identify and address the threats originating from them as well. We understand that protecting End-To-End assets in this model will be a very challenging task both from a technical and UX perspective, nevertheless we feel that in this case benefits for the end users outweigh the costs.

5. Compromised Google account. Adversary who has access to End-to-End user Google account either via successful phishing for account credentials, or breaking into the account e.g. via exploiting account recovery flows or weak passwords. Additionally, the attacker might compromise user account by exploiting a vulnerability in one of devices associated with that account but without the key material (e.g. a malware installed on user's Android device). Compromised Google account may give the adversary possibilities to install arbitrary Chrome apps and extensions into the browser profile with End-To-End through Chrome sync.

Threat sources outside the threat model:

Perhaps even more importantly, we enumerate threat sources considered not in scope for our threat model. As we don't provide any countermeasures for threats originating from the following sources, high-risk users may wish to use additional countermeasures against adversaries controlling them.

• Browser. In our threat model Chrome browser is equivalent to a root user, so it has the capabilities to circumvent all security mechanisms employed in End-to-End. Users concerned with adversaries able to backdoor Chrome browser may use End-to-End with open-source Chromium.

  Chrome/Webkit 0-day vulnerabilities may result in various levels of browser compromise. Adversaries exploiting Chrome sandbox escape vulnerabilities are explicitly outside our threat model.

• Native applications. Various native applications installed alongside the browser can access End-to-End assets directly via e.g. file system or memory inspection. Asset compromise might also happen by an accidental flaw. For example, improperly configured backup solution may leak the secret keys stored in Chrome profile to a network adversary or cloud storage provider.

• Malware. Malicious code running with the full local user privileges on the operating system (e.g. keyloggers). We do not implement any mitigations or speedbumps against malware and assume that no application can reliably protect its assets if the host they're running on is compromised. This is in line with model adopted e.g. by GnuPG. For high-risk users we recommend using a Chrome OS operating system that provides strong protections against malware by design.

• Operating system. Operating system kernel, together with all device drivers. While some types of malware could be isolated via Operating System security mechanisms (e.g. different OS user accounts), if the Operating System itself is compromised, all bets are off for End-to-End. As such, keeping your Operating system up-to-date and configured correctly is critical.

• Hardware. Vulnerabilities or backdoors in device hardware, including hard drives, SSD, memory chips, CPU or peripherals. For example, hardware keyloggers, TEMPEST, or even potentially a phone could be used to steal information from a user. Finally, Chrome considers hardware/physical attacks outside of their threat model.

• Human error. Confused or social engineered users might involuntarily expose the protected assets to the adversary, e.g. by giving access to keyring files, or interacting with untrusted UI elements without noticing the lack of required trust indicators. While software should do it's best effort to prevent these types of attacks, humans always remain in control of their software and can make mistakes.

Threats

The following threats against the protected assets have been identified:

UI threats

Note that Chrome only provides trusted UI when a user interacts with websites, but Apps and Extensions are capable of taking complete control over the user's browser look and feel. This means that the threats identified below can't be feasibly defended against other apps and extensions (for instance, a Chrome App can always create a window on top of other Chrome Apps).

When we discuss UI threats in this section we talk exclusively about defending against websites, for which both Chrome and End-to-End intend to provide UI security guarantees.

Encrypting message to an additional key

If the attacker has a possibility to encrypt a message to an additional public key, it would allow him to read the contents of the message. This could be done in multiple ways, e.g. overlaying the compose message UI element with CSS to cover an additional key or exploiting differences in e-mail address formatting.

We mitigate that threat by always displaying the compose message dialog in a trusted, top-most UI element (Chrome extension page action). In this trusted UI we display e-mail addresses certified to use the OpenPGP public key the message would be encrypted to. Contrary to other OpenPGP-in-webmail solutions we never display the compose dialog in the browser tab, alongside the web application.

Identity verification flaws

Since encryption only uses recipients public key, it's trivial for the adversaries to spoof an encrypted message contents sent to End-to-End user. For example, a webmail application may pretend that arbitrary message has been sent from given e-mail address as a reply to End-to-End user message. To prove message sender identity OpenPGP signing needs to be used, and End-to-End supports that.

Upon decryption of the OpenPGP message we display signature verification results of a lack thereof in a notification. Signature verification errors are displayed as an error message.

Spoofed parts of End-to-End user interface

Web application or MITM attacker can spoof elements of the End-to-End UI, if that elements are displayed within the browser tab displaying the web application. For example, the compose message frame could be spoofed or overlayed, disclosing the text of the composed message to the adversary.

We mitigate this by providing a trusted UI and non-spoofable trust indicators. Current design of the End-to-End extension exposes all the actions in the extension browser action that provides the trusted UI that cannot be spoofed by the malicious web application.

We are unable to protect against Web applications using HTML5 fullscreen API, as even the trust indicators may be spoofed then. However, browsers supporting the fullscreen API display a warning when a web application activates fullscreen mode.

Spoofed End-to-End

Malicious Chrome extension (installed e.g. through a compromised user account) can reuse End-To-End icon in order to trick the user into thinking she's interacting with a legitimate End-To-End extension. The extension can then exfiltrate draft message contents and message recipient identities. Because spoofing extension does not have access to secret key material, secret keys cannot be leaked, past messages cannot be decrypted and the messages created in the spoofing extension could not be signed. We do not mitigate that threat.

Message threats

Message plaintext leaks

Users might involuntarily disclose plaintext of the message e.g. by composing them inside Web applications (e.g. composing a draft of the message in a webmail application). We mitigate this threat by:

• not exposing an API for message decryption
• providing our own compose and read message interface in a trusted UI (Chrome extension page action)
• using various timing sidechannel preventions (constant-time BigInteger operations, RSA blinding)

Users might enable an optional, disabled by default, feature of End-To-End ("looking glass") that displays the plaintext of a message the user has clicked on in a Web Application document. We protect the plaintext of the decrypted message in the following ways:

• Same Origin Policy - Message is displayed in an IFRAME of End-To-End chrome-extension:// origin, so Web Applications cannot inspect the context of the iframe.
• Constant-size. We do not leak the dimensions of the decrypted text by setting the size of the iframe before decryption.
• Throttling. We throttle the requests for displaying the IFRAME, to prevent side-channel attacks requiring multiple accesses to the oracle.
• Timing sidechannel prevention. Random delay for displaying an iframe is added on top of our standard timing sidechannel countermeasures.

Nevertheless, we'd like to also mention the following side channels that might still leak the plaintext of the messages.

• Recipient actions. End-To-End cannot guarantee the confidentiality of the message as it is processed by its intended recipients. The recipient might disclose the message in various ways. For example, commonly e-mail message replies contain quoted contents of the original message. The reply message can be encrypted to a different set of keys (including the key an adversary has control of), or might not even be encrypted at all.

• Clipboard. Plaintext of the message can be leaked by the user involuntarily via the OS clipboard. For example, web applications may use social engineering to entice user to paste into a textarea ("Press CTRL, and press V"). Alternatively, Chrome extensions may use the clipboardRead permission to exfiltrate messages.

• Files. When using End-To-End to encrypt files, the plaintext version of the file is always stored on the filesystem. Adversaries having direct access to files are outside our threat model.

• Screenshots. Chrome extensions can also use chrome.tabs.captureVisibleTab to take a screenshot of current tab in any browser window. Screenshot will also include rendered contents of cross-origin iframes, potentially leaking the message plaintext displayed in iframes added to Web Application document ("looking glass" feature). High risk users should make sure that a "looking glass" feature is disabled, at the expense of End-To-End usability.

Access to the decryption oracle

Similar to message plaintext leaks, the adversary could get access to a decryption oracle, allowing them to decrypt multiple messages without user interaction.

Countermeasures against this threat are already mentioned in Message plaintext leaks section, it's worth noting though that a malicious Chrome extension may abuse the enabled "looking glass" feature to take screenshots of arbitrary messages in the background window without user interaction. The speed of the attack is limited only by API throttling and the time of the actual decryption. Users at high risk should double check that the "looking glass" feature is disabled.

Tampering of encrypted messages

OpenPGP message format allows for limited tampering with the messages if Symmetrically Encrypted Data Packets (Tag 9) lacking integrity protection are used.

In accordance to RFC 4880, End-To-End uses Symmetrically Encrypted Integrity Protected Data Packets (Tag 18) when composing messages and verifies the MDC code when processing messages with Tag 18 packets. Messages using the tag 9 packet are still accepted due to compatibility reasons.

Additionally, messages created with End-To-End are signed with user's private key by default (user has an option to choose the signing key or disable the signature for an individual message).

Altered message order and delivery

Mail provider can reshuffle encrypted messages or not deliver them to End-To-End user or any of the recipients. Though it is possible to introduce additional metadata to maintain message order integrity, it falls outside the scope of OpenPGP, so we do not mitigate this threat.

Key-related threats

Public keyring identities leakage

Identities present in a public keyring carry the information who End-To-End user has communicated with in the past. While this information is may be considered private, it is worth noting that some information leaks are inevitable, as the information can be obtained from other sources.

For example, End-To-End does not remove the Key IDs from outgoing OpenPGP messages, so they are accessible to relevant web application and man-in-the-middle adversaries. In general, we believe that short of generating a throwaway OpenPGP key for every message exchange, users cannot reliably protect themselves from these adversaries observing message metadata to discover communication participants.

Nevertheless, we recognize the need to limit access to all keyring identities to all components interacting with End-To-End. For example, user (e.g., a journalist) might manually import recipient (e.g., a whistleblower) public key into his keyring and intends to use End-To-End only for encryption, exchanging messages with this recipient using a non-web-based third-party application. In this case the presence of the key should not be disclosed to the keyserver or various web-applications.

We mitigate this threat by not exposing the API to reveal identities in user's public keyring to web applications, and only user's own public key is uploaded to the keyserver upon key generation.

Web applications can initiate a message compose flow using an API, specifying various initial intended recipients of a message. Compose dialog is displayed in the trusted UI, allowing the user to review and modify the list of recipients (only e-mail addresses are displayed). Upon encryption, user can transfer the encrypted message and reviewed recipient list back to the web application. Potentially this allows the web application to extract unintended identities through the compose flow, but this attack would be visible to the user.

Public key leaks

Public keys imported into user's keyring are not exported into the keyserver. Public keys can be exported into a file by using "Export public key" or "Export keyring" functionality in End-To-End settings page. We do not expose an API to web applications to export public keys.

Secret key leakage

Keys are stored in the extension's Local Storage. If the user has set a passphrase, the keys are encrypted. We use AES128 with a random per-installation salt and the string-to-key function uses SHA1 with 65,536 iterations. A SHA256 HMAC with a random IV is used to ensure integrity. Keys are never exposed to the web application or other extensions. We do not expose an API to export secret keys; they are not uploaded to Keyservers. However, Local storage can be potentially accessed by Chrome extensions able to use debugging APIs.

User impersonation

If an attacker inserts a secret key into the user's secret keyring, the user could then be accused of owning a given identity. As such, ownership of a secret key doesn't imply the user owns such an identity. To mitigate the threat of impersonation, secret key import to End-To-End requires user confirmation.

Cryptographic threats

Side-channel attacks expose secret key material or plaintext messages

This threat is mitigated by providing the cryptographic operations using the End-to-End library designed to minimize timing side-channels. All secret key-based computations are performed in the extension background page, providing process separation (in Google Chrome, extensions are executed in a separate OS process).

Flaws in cryptographic algorithms

Adversary might exploit a vulnerability in cryptographic primitive or the protocol. We mitigate this threat in the following ways:

• End-To-End uses the standard OpenPGP (RFC 4880) protocol with the ECC extensions defined in (RFC6637).
• For random number generation End-To-End uses cryptographically secure RNG (WebCrypto getRandomValues)
• End-To-End only generates ECC keys, and accepts keys with OpenPGP-compatible algorithms.
• All cryptographic code has been rewritten from scratch and reviewed multiple times. We do not depend on third-party crypto libraries.
• We use only chosen message digest, symmetric and asymmetric encryption algorithms. End-To-End reject keys with weak key parameters. For example, RSA keys with moduli length < 1022 bits are rejected.
• All cryptographic code is open-source, subject to a public review.
• End-To-End is in-scope for the Google Vulnerability Reward Program that rewards security researchers for responsibly disclosing vulnerabilities. Two vulnerabilities were reported and rewarded in the past.

Other threats

Compromise through browser debugging APIs

Various Chrome extensions and apps can request debugging permissions that allow them to attach to End-To-End background page, option page or iframes and execute code to exfiltrate or modify protected assets. We identified two dangerous APIs in that regard: Debugger API, DevTools API, both of them allowing the adversaries to compromise End-To-End. Some of the potential security issues with Debugger API have been already addressed in the current Chrome version. In turn, allowing a malicious DevTools API to run in a context of End-To-End document requires user interaction (opening DevTools). However, we are aware that this attack vector is still present. Unfortunately, from within End-To-End we can offer no mitigations against this threat.

Backdoor in End-to-End source code

End-to-End code (or the code of it's dependencies) may be backdoored to leak assets to the adversaries. We mitigate this threat by open-sourcing End-To-End. All the dependencies used in End-To-End are also open-source. Additionally, any code added to the extension undergoes an internal peer review process.

The final version of End-To-End will be available on Chrome Web Store, signed with our internal developer key. Code signing prevents man-in-the-middle attackers from altering the code while it's being downloaded from the Chrome Web Store.

Extension source code and build tools are publicly available at our GitHub code repository. High-risk users may wish to download the code, build and package the extension without relying on the build provided by the team, keeping in mind though that downloading the build toolchain may introduce additional risks. End-To-End is written in JavaScript with no binary code components, so the code can also be inspected client-side.

Additionally, we plan to add remote private key support in the future. When support for that is ready, high-risk users could protect their secret keys (stored, e.g., in a hardware USB device) from compromise even when the adversary introduces a backdoor in the source code.

Denial of service

Adversaries might launch a Denial-of-Service attack against End-To-End using various vectors, e.g. by triggering decryption of large, compressed messages, import of large keyrings, blocking HTTP traffic or abusing the Chrome messaging API. We do not mitigate this threat.