-
Notifications
You must be signed in to change notification settings - Fork 88
Threat Model
Given the key takeaways from our research into the needs of the users we hope to be able to serve, our goal is to achieve the security invariants below for the following usage scenario. We follow the invariant-centric threat modeling approach, so any security invariant that is not actually met by Quiet, or that is misunderstood by users, will be added as a security bug and either fixed in Quiet or in this document.
A team uses Quiet as a Slack replacement for team chat. The team has an existing secure communications channel for sending and receiving initial invitations (e.g. a Signal group). Every team member has an authentic, non-malicious version of the Quiet app, and all team members use full-disk encryption with user-controlled keys and a strong password.
Deletion and removal are not yet possible in alpha releases of Quiet, so the following definitions in this document refer to future versions of Quiet that have this capability:
- DELETED means any data the app has declared "deleted," to any user, and that users have not archived using other means, for example by taking a screenshot of chats, by inadvertently backing up app data with cloud backup tools, or by tampering with the app to block deletion.
- REMOVED means any team member the app has declared "removed," to any user.
- OWNER is the creator of a group. A group cannot have multiple OWNERS.
- MEMBER is a user who has been invited to a group by a non-malicious OWNER, with no other capabilities.
- NON-MEMBER is a user who has never been invited to a group, or a user who was REMOVED by an OWNER, with no other capabilities.
- DRAGNET can intercept a team’s network traffic, archive it for later decryption, and perform traffic analysis attacks against Tor at the limit of what is theoretically possible.
- MALWARE can access keys or messages on the device of a member VICTIM, but has no other capabilities (such as recovering deleted data from a device.)
- MALWARE + DRAGNET can do everything MALWARE and DRAGNET can do, but has no other capabilities.
- NETWORK ACTIVE ATTACKER can both monitor and actively attack the network (for example by blocking access to the network entirely for everyone or certain users, blocking specific pieces of data from reaching their destination, or altering data in transit) but has no other capabilities. This includes attackers who can successfully degrade or disable the Tor network.
- UPDATE PROVIDER includes the Quiet team and the infrastructure providers used for building and distributing Quiet: Github/Microsoft (all platforms), Amazon (Desktop), Google ("Play Services"-enabled Android), and Apple (iOS).
OWNER cannot:
- Read messages from private chats or direct messages that did not include them, or cause these messages to be DELETED.
- Read DELETED messages.
- Learn the IP address of other MEMBERS.
- Learn which MEMBERS are communicating to each other, and when, in private chats and direct messages that do not include them.
- Cause the contents of messages sent by other MEMBERS to appear incorrectly in any way.
- Cause any message to appear as if it was sent twice when it was only sent once.
- Crash the app or device of MEMBERS.
- Learn the private keys of any MEMBER.
- Learn if a MEMBER in one group is also a MEMBER of another group.
MEMBER cannot:
- Do anything OWNER cannot do.
- Send messages that appear to be from any other MEMBER, or cause the sender of any message to appear incorrectly in any way.
- Add or remove MEMBERS, or make anyone else the OWNER.
MALWARE cannot:
- Do anything VICTIM cannot do. (VICTIM can be either MEMBER or OWNER.)
MALWARE + DRAGNET cannot:
- Access any private chats or direct messages that did not include VICTIM.
- Access any DELETED messages from before they began intercepting and archiving messages.
- Send messages that appear to be from any MEMBER except VICTIM, or cause the sender of any message to appear incorrectly in any other way.
- Cause the contents of messages sent by other MEMBERS to appear incorrectly in any way.
- Cause any message to appear as if it was sent twice when it was only sent once.
- Crash the app or device of other MEMBERS.
- Learn the private keys of any other MEMBER.
NETWORK ACTIVE ATTACKER cannot:
- Read any group messages.
- Send messages that appear to be from any MEMBER.
- Send messages to any MEMBER.
- Learn the usernames of MEMBERS.
- Crash the app or device of MEMBERS.
- Learn the private keys of any MEMBER.
- Alter the contents, sender, or timestamp of any message a MEMBER sees, in any way, including by causing any message to appear as if it was sent twice when it was only sent once.
DRAGNET cannot:
- Do anything NETWORK ACTIVE ATTACKER cannot do.
- Degrade app functionality for any MEMBER.
NON-MEMBER cannot:
- Do anything DRAGNET cannot do.
- Do anything OWNER cannot do.
- Determine when any MEMBER is online/active, unless the NON-MEMBER was REMOVED. (See: #689)
- Degrade app functionality for any MEMBER, unless the NON-MEMBER was REMOVED. (See: #690)
A MEMBER who was REMOVED can:
- Degrade app functionality for any MEMBER. (See: #689)
- Learn when any MEMBER is online/active. (See: #690)
MEMBER can:
- Degrade app functionality for any MEMBER, e.g. by spamming, or failing to relay messages to or from a MEMBER–potentially in a way that is hard or impossible for another MEMBER to attribute.
- Prevent the owner from removing them.
- Prevent any mesage (or all messages) from being DELETED without the knowledge of other users, e.g. by screenshotting it, or by archiving app data.
- Provide an inaccurate record of their own messages to other MEMBERS, for example by altering message contents or timestamps. [2]
OWNER can:
- Do anything a MEMBER can do.
- Add and remove MEMBERS.
- Send messages that appear to be from any other MEMBER, or cause the sender of any message to appear incorrectly in any way. (Once #119 is complete, OWNER will only be able to impersonate a MEMBER to other MEMBERS who were not online when MEMBER joined and have never seen an authentic message from MEMBER.)
DRAGNET can:
- Learn who is using the app.
- Learn the IP address of any MEMBER.
- Learn which groups any MEMBER belongs to.
- Learn which MEMBERS are communicating to each other, and when.
- Intercept and archive messages for later decryption by MALWARE (see MALWARE + DRAGNET.)
MALWARE can:
- Do anything a MEMBER can do, as VICTIM.
- Do anything OWNER can do, if VICTIM is OWNER.
- Send messages as VICTIM.
- Read all non-DELETED messages readable by VICTIM, including all future messages until VICTIM is REMOVED.
- Learn the IP address of VICTIM.
MALWARE + DRAGNET can:
- Do anything MALWARE or DRAGNET can do.
- Read any DELETED messages once readable by VICTIM, provided they were intercepted and archived by MALWARE.
NETWORK ACTIVE ATTACKER can:
- Do anything DRAGNET can do.
- Degrade app functionality for any user.
UPDATE PROVIDER can:
- Do anything MALWARE can do.
- Ensuring the consistency and integrity of the conversation transcript (including messaging ordering and timestamps) across users in a distributed system is a hard problem in a non-threaded conversation like a typical group chat, since different users could receive messages at different times, or receive a message second-hand from another user. You might see a message for the first time long after it was sent, and the sender can lie about a timestamp. Most approaches seek to constrain the degree to which a timestamp can be wrong by linking messages to previously sent messages, to create a graph of relative ordering. We will treat any failure of transcript integrity or inconsistency as a security vulnerability, but because it’s difficult to make strict guarantees that are informative to users, we leave them out of this threat model. The library we’re using for storing and syncing messages (https://github.com/orbitdb/orbit-db) attempts to achieve transcript consistency and integrity. The one guarantee we can and do make is eventual consistency, though this term is unlikely to be clear to most users.
- Because messages are potentially stored by every member, it will not be possible to delete messages on-demand (e.g. when users click a delete button) for members who are offline, simply because there is no way to communicate to these users that messages should be deleted. This means there will inevitably be UX challenges in ensuring deletion matches user expectations. However, we can strictly adhere to the threat model above by making each client automatically report successful deletion to all members, and by telling a user that a message has been deleted only once all other member clients claim to have deleted that message. (Once all clients report deletion we can rely on the explicit assumption, in our Usage Scenario, that deletion did in fact occur.)
To develop a threat model for our decentralized messaging app "Quiet" we conducted ~18 user interviews with people in the following categories:
- Journalists
- Activists or policy experts who communicate frequently with journalists
- Security experts whose work includes advising and protecting activists and journalists
We also reviewed the security properties of existing encrypted messaging apps, including centralized approaches such as Signal and WhatsApp, federated approaches such as Matrix, and decentralized approaches such as Ricochet, Cwtch, and Session. This threat model follows from that work.
Our hypothesis going into the study was that journalists needed a cheaper tool for anonymous tips than SecureDrop, but we found a greater need for secure team chat.
Indeed, many journalists affirmed that the cost of running SecureDrop was indeed prohibitive. However, in our interviews, both journalists and sources were far more concerned about the security of their internal communications (i.e. conversations within their own organization or with close collaborators at other organizations) than with journalist/source communication.
While many use Signal and/or voice communication for sensitive conversations, most still use insecure channels like Slack and email, and they worried about exposure to a large-scale breach or a targeted attack. Users cited missing features like themed channels as to why Signal was not an option for team chat, and expressed a general wariness as to whether other Slack alternatives were sufficiently usable and reliable.
Experts named account compromise via phishing or guessing of insecure passwords as the most common threat, followed by the risk of devices being compromised physically, e.g. by being lost or seized. Malware attacks were mentioned, but noted by multiple experts as being much less common.
Usability, features, high availability, and "software that just works" were experts' top recommendation criteria, above any specific security features. Several experts said something to the effect of, "if software isn't easy to use or interferes with work, users will misuse it or avoid it entirely."
The next highest recommendation criteria was the trustworthiness of the team behind a given piece of software, followed by whether the software was open source. Timed deletion of messages came next, tied with the project's stability, funding, longevity, and capacity to respond to bugs.
-
Among the journalists and sources we interviewed, the primary and most motivating concern about communications security was the breach of written internal communications by an adversary or in a public leak accessible to adversaries.
-
The core need was not just encrypted messaging, since most interviewees use Signal, but rather a suitable encrypted replacement for Slack or Discord, which Signal is not because it lacks necessary team chat features such as themed channels.
-
Usability, end-to-end encryption, timed deletion, and resistance to account credential phishing were the most important security requirements, according to the experts we interviewed, and this was consistent with responses from users (sources and journalists). Neither users nor security experts mentioned specific properties of end-to-end encryption like forward or backward secrecy as requirements
We are grateful to the Zcash Foundation for the grant that supported this research, to Sarah Jamie Lewis for her generous feedback on the original research proposal, and to Benjamin Winston and Taylor Hornby for their generous feedback on this document.