End to end encrypted incident chat

Notes about how we might implement a simple and usable end-to-end encrypted (E2E) chat for Buoy. See issue #51 for ongoing discussion.

Scope and disclaimer

This document specifically addresses how a desire for privacy of message contents between incident responders using the Buoy system might be realized. It is not an encryption algorithm nor does it aim to mitigate against all possible attack scenarios.

For example, this document does not address the possibility of exposing information about which Buoy users are communicating with which other Buoy users through passive network monitoring. The appropriate defense against this attack is to use a Buoy server equipped with TLS (such as through Let's Encrypt).

For more general information about security threats and how to mitigate them while using Buoy, see Security advice.

Objectives

• Text chat messages transmitted via the built-in chat room are encrypted and decrypted only on client devices, never the server
• Feasible to implement in a cross-device way without writing any crypto code today
• Zero additional UI/UX friction or overhead

Threat model

End-to-end encrypted chat through Buoy is designed to protect end users from the following threats.

Server compromise

If a Buoy server is itself compromised, an attacker could potentially monitor all outgoing alerts and incident response coordination.

E2E Chat mitigates the damage a successful server compromise could do by ensuring that the log of chat messages sent among responders remain unreadable by the attacker, keeping the chat messages private among the set of responders themselves. Notably, of course, this only applies to messages sent before the server was compromised.

Buoy further protects against a sever compromise by automatically deleting old incident data at regular intervals (defined by a Site Administrator).

Machine-in-the-Middle (MITM)

If a Buoy server does not enforce TLS, or if a client is inside a network environment that proxies HTTPS requests (such as many corporate or large academic networks), E2E chat ensures that message contents are still private.

Note: An additional defense against this attack is HTTP Public Key Pinning (HPKP). We are discussing its merits for Buoy in issue #85.

Malicious responder

If an attacker is able to impersonate a legitimate responder to the Buoy server, they can gain access to a Buoy Incident Chat room and infiltrate a particular incident's responder group.

E2E chat mitigates the risk to these responders by ensuring that the attacker will not be able to read messages sent from other responders. Further, messages the attacker sends to the legitimate responders will be detected as impersonation attempts and will not be accepted for display to end users.

Note: In this scenario, the attacker can still observe location movements on the real-time map. The same technology that can protect chat messages in this attack scenario can theoretically be used to protect the location data, too, but due to limited programmer power, this draft does not explicitly discuss an implementation for that defense.

Implementation

⚠️ This section is (obviously) far from complete.

This is my current proposal for accomplishing the objectives. Note especially that feasibility of this implementation in a timescale of "today" is a strong driving force. Additional resources contributed from the community would be more than welcome. :)

1. When the "Respond" button is pressed on a review alert screen, the client:
2. Generates a new OpenPGP keypair (using OpenPGP.js) unique to that alert. The PGP identity shall be: "{$WP_User->display_name} <{$WP_User->user_email}> ({$WP_Buoy_Alert->incident_hash})"
3. Stores this OpenPGP keypair in its HTML5 LocalStorage or an equivalent client-side storage mechanism.
4. Sends the public key to the Buoy server.
5. The server stores the public key along with the alert data.
6. The server responds with the Incident Chat screen/data along with the public keys of any existing responders.
7. The client stores the other responders' public keys in its local storage, too, associated with this alert.
8. When a user sends a chat message:
9. The client signs the cleartext of the user's input with its private key.
10. The client encrypts the user's signed cleartext to all the public keys it received from the server.
11. The client sends the ciphertext to the server as the content of the chat message.
12. The server relays this content as per normal.
13. When a client receives an encrypted chat message:
14. The client decrypts the ciphertext with its private key.
15. The client verifies that the signature of the message matches one of the public keys it has.

• How do existing clients securely receive the public keys of responders who join later?
• Is it better to have longer-lived keypairs, i.e., device+domain instead of alert to address late arrivals? This could also further protect clients in the event of a server compromise because they would be more likely to have cached a fellow responder's public key from before the intrusion.