About Project Phoenix
Individuals living in repressive information regimes have a strong need for secure and private messaging. However, there is currently a void in the secure messenger field that properly caters to at-risk users in these authoritarian contexts. OTF recently supported Phoenix R&D to develop a technology stack around OpenMLS, an open source implementation of the new Messaging Layer Security (MLS) protocol (the latest evolution in secure messaging). This technology stack not only complements MLS but also minimizes the need for metadata on the infrastructure side, providing stronger privacy and data protection.
OTF’s latest round of support is helping other developers integrate this technology stack into their applications, making state-of-the-art, end-to-end encryption technology more accessible. It is also supporting the development of a new messaging service built on top of the technology stack.
Audit Description
OTF’s Security Lab partner, Security Research Labs performed a security assessment of the Phoenix architecture between June and October 2024, reviewing the Phoenix protocol documentation and the key interactions between users and the Phoenix services (such as registering an account and sending a message). The audit included threat modeling, security design review, and remediation support. The auditors’ feature review was based on the STRIDE framework, which assesses for risks including Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. They also included two additional threat categories—privacy breaches, and spam and annoyances—for a more comprehensive analysis.
Scope
The audit covered the Phoenix protocol documentation, with a focus on the main services of the Phoenix home server: the Authentication service, the Delivery service, and the Queuing service. The review also covered the following client interactions with the server: registering an account, creating a group, creating a connection, adding a user to a group, and sending a message, along with the cryptographic protection of messages exchanged during these interactions.
The scope of this audit did not include network-related issues such as DNS hijacking or the delay, reordering, or retransmission of packets. While this audit focused on Phoenix documentation, Security Research Labs plans to conduct a subsequent review of the Phoenix implementation.
Findings
Auditors did not find any vulnerabilities considered to be “critical.” They did detect three “high-severity” vulnerabilities:
- Malicious use of friendship tokens: Auditors observed that because the friendship tokens that create trust between members are static (“each connection partner receives the same token”), one user could pass another’s token to a third, malicious user who can then add the first user to a group without their consent—exposing that user to unwanted messaging, among other privacy risks. To mitigate this, auditors recommended stronger documentation directing users to ignore unsolicited messages and group invitations, and a change from “long-lived” friendship tokens to per-connection tokens.
- User identity confusion for client credential authenticated calls: For certain user actions that require authentication, the system needs two user IDs: one that names the entity/user account on which to perform the action, and another value —called ClientCredential—for authenticating the call. Auditors noted the risk of “identity mix-ups” where, for instance, the server receives instructions for mismatched IDs, or takes an authorized action on an account when ID values are duplicated. Auditors recommended further guidance in the Phoenix specifications and suggested having a “single source of truth,” by not requiring the user ID for calls authenticated via ClientCredential.
- Linking users to Privacy Pass token redemption: The system creates privacy pass tokens to provide unlinkable rate limitation of clients, but auditors found that a malicious server could link the unique private keys that get created with the individual users, by retrieving a user at the time that their privacy pass token gets redeemed. Auditors suggested making this operation more visible to users, which makes the risk more transparent, even if not preventable.
In addition to these three “high-severity” risks, Security Research Labs also identified four vulnerabilities flagged as “medium” (1) and “low” (3), related to potential misuses of friendship tokens and degrees of exposure based on inference or on links between federated servers.
Remediation
Retests conducted by auditors confirmed that all of the high-severity issues, as well as the medium-severity issue, had been fixed by the time of the audit report’s release in October 2024. Phoenix R&D considered the low-severity issues acceptable.