As part of Zbay’s Zcash Foundation grant from last year, I researched the communication needs of journalists and sources, to see if a messaging app built using Zcash encrypted memos could meet their needs better than, say, like SecureDrop.
We’ve created a threat model based on that work, and I’m looking for feedback on it. If anyone with experience in security would like to offer feedback, that would be amazing. @earthrise, @dconnolly, @chelseakomlo, @zebambam, and @mistfpga—I’ve learned a lot from your posts and publications, and this might be relevant to things you’re thinking about, so if you’d like to take a look I’d be super grateful!
Thanks again to @sarahjamielewis for the extremely helpful early guidance. I’ve never done any academic anthropology work (just informal user research) but thanks to Sarah’s guidance the methods and quantity of data seem at least loosely on par with the academic work I’ve seen on this subject. I think we succeeded at getting an accurate snapshot of peoples’ needs right now. (I certainly hope so, since a ton of product decisions will follow from this!) Due to funding and time constraints, and the complexity of privacy and safety concerns for interviewees, many of whom are leaders in their fields and do very sensitive work, we won’t be publishing anything beyond this overview. But I’d be happy to speak privately about the conclusions in more depth if anyone would like to do that.
Also thanks to @antonie and @acityinohio at Zcash Foundation for funding this research, and funding the basic work needed to act on it, like the work moving to a light wallet stack and using Tor for off-chain messaging.
To develop a threat model for our decentralized messaging app “Zbay” (a placeholder name that will change soon), we conducted ~18 user interviews with journalists, sources (specifically: activists or policy experts who communicate frequently with journalists), and security experts whose work includes advising and protecting journalists. We also reviewed the security properties of existing encrypted messaging apps, including centralized (e.g. Signal, WhatsApp), federated (Matrix), and decentralized (Ricochet, Cwtch, Session) approaches.
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, alongside the project’s stability, funding, longevity, and capacity to respond to vulnerabilities.
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, and often recommended tools that did not have properties like forward secrecy.
Given the above conclusions about the threat models and needs of the users we hope to serve, our goal is to achieve the following set of security invariants for the following scenario.
(We follow the “invariant-centric threat modeling” approach outlined here: GitHub - defuse/ictm: A user-first approach to threat modeling.)
A team uses Zbay as a Slack replacement for team chat, and all team members use full-disk encryption with user-controlled keys and a strong password.
DELETED means any data the app has declared “deleted,” to any user, and that users have not archived using other means, for example by screenshotting 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.
MEMBER is a user who has been invited to a group, with no other capabilities.
NON-MEMBER is a user who has never been invited to a group, or a user who was REMOVED, with no other capabilities.
HACKER 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.)
HACKER/ARCHIVER can intercept a team member’s network traffic, archive it for later decryption, and access keys on the device of a member VICTIM, but has no other capabilities.
A NON-MEMBER cannot:
- Read team messages.
- Send messages as any MEMBER.
- Degrade app functionality for any MEMBER, including by sending unwanted messages to any MEMBER that has disabled direct messages from NON-MEMBERS.
A MEMBER cannot:
- Read messages from private chats or DMs that did not include them.
- Read DELETED messages.
- Send messages as any other MEMBER.
- Add or remove MEMBERS unless authorized to do so.
A HACKER cannot:
- Send messages as any member except VICTIM.
- Read DELETED messages.
- Read messages from private chats or DMs that did not include VICTIM.
A HACKER/ARCHIVER cannot:
- Send messages as any member except VICTIM
- Access any private chats or DMs that did not include VICTIM.
- Access any DELETED messages from before they began intercepting and archiving messages.
A NON-MEMBER can:
- Send unwanted messages to a MEMBER who has not disabled messages from NON-MEMBERS.
A MEMBER can:
- Degrade app functionality for any MEMBER, e.g. by spamming.
- Prevent any message (or all messages) from being DELETED without the knowledge of other users, e.g. by screenshotting it, or by archiving app data.
A HACKER can:
- Send messages as VICTIM.
- Read all non-DELETED messages readable by VICTIM, including all future messages until VICTIM is REMOVED.
A HACKER/ARCHIVER can:
- Do anything a HACKER can do.
- Read any DELETED messages once readable by VICTIM, provided they were intercepted and archived by HACKER.
Note re: deletion:
Because messages are potentially stored by every member, it won’t be possible to delete messages on-demand (e.g. when users click a delete button) for members who are offline—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 address the need for a secure, usable team chat space, while meeting the security invariants above, we have identified the following milestones:
- Low-latency, theoretically-deletable public groups
- Online users can send and receive messages with low-latency
- Users can sync recent messages when they come online
- It is technically possible to delete message data, i.e. by all participants deleting all app data from their devices.
- Low-latency private groups
- A user can create a new team chat space
- That user, i.e. the owner, can securely invite members
- Messages in that space are end-to-end encrypted
- The owner can remove members
- Non-members do not know the Tor addresses of members, and so have no way to interfere with team conversations, e.g. by spamming or DoS’ing members.
- Private channels and direct messages
- Members can send and receive private direct messages, off-chain.
- Members can create private channels, and invite other members to join them
- Mobile support
- Users can access teams on Android and iOS
- Users can receive notifications of new messages.
- Note: some sacrifices in decentralization and metadata privacy may be required to build a working product, especially on iOS.
- Deletion and “disappearing” messages
- Owners can set a global message deletion policy (e.g. messages deleted in 1 month)
- Channels can have stricter settings (e.g. messages deleted daily)
- Users can delete individual messages
- It is clear to all users when messages selected for deletion have actually been deleted from all user devices.
- Low-latency, off-chain account registration
- Trust team owners to register accounts and distribute key/name bindings to all users.
- Mitigate potential harm if the owner’s device is compromised
- Update security invariants to reflect remaining weaknesses
- Research distributed identity approaches like CONIKS, ETHIKS, Bitforest, and the existing startup ecosystem for solutions that can address remaining weaknesses.
Many generally-desirable security properties did not surface as critical requirements in our interviews with journalists, sources, and security experts who work to protect journalists, so we leave achieving them for future work—even though we are already using tools that provide some of these properties:
- Security requirements for Zcash payments (we seek to follow the wallet app threat model but haven’t had outside review.)
- Metadata protection and anonymity
- Forward and backward secrecy
- Message ordering integrity
- Preventing accidental archiving of messages (e.g. through misconfigured cloud backup)
- Managing keys across multiple devices
- Tools for managing unwanted messages without disabling all messages from outside teams.