Defending Against Attack on the Cloned: In-Band Active Man-in-the-Middle Detection for the Signal Protocol

TL;DR

The paper tackles the rising risk of active Man-in-the-Middle attacks on end-to-end encrypted messaging by automating in-band key confirmation within the Signal protocol. It introduces server-assisted envelope protocols that detect powerful attackers who can clone a device's state, while preserving Signal's guarantees such as perfect forward secrecy and post-compromise security. The authors implement a Rust-based proof-of-concept and demonstrate that the new protocols incur only minimal performance overhead compared to the original Signal protocol, making the approach practical for real-world deployment. This work provides a concrete, end-to-end security enhancement that reduces reliance on user-driven authentication ceremonies and strengthens resilience against state-level adversaries, without requiring additional trusted parties. The solution thus offers a viable path toward robust, automated MitM detection in mainstream secure messaging systems.

Abstract

With Signal's position as one of the most popular secure messaging protocols in use today, the threat of government coercion and mass surveillance, i.e., active Man-in-the-Middle (MitM) attacks, are more relevant than ever. On the other hand, studies [29, 33, 37, 38] have shown that user awareness is very poor when it comes to authenticating keys in instant messaging applications, e.g., comparing key fingerprints out-of-band. The ideal solution to this problem should not require the active participation of the users. Our solution to active MitM attacks builds directly on Signal. We automate the process of key confirmation without relying on the intervention of users, and without using an out-of-band communication channel, at the cost of slightly altered trust assumptions on the server. We consider a powerful active MitM that not only controls the communication channel, but also has (one time) access to all secrets on one of the clients, i.e., can perform a key compromise attack. Our solution utilises the server to keep track of the changes in the clients key fingerprint as ratcheting is performed. Given that the server can keep a message log already, we find that any impact on deniability is minimal in practice. We present our detailed modifications to Signal, and document the new security guarantees while preserving the existing security guarantees of Signal. Our proof-of-concept implementation, which is based on the open-source Signal library used in real-world instant messaging applications, shows that our solution is practical and integrates well with the library. Our experimental results further show that our solution only has a tiny performance overhead when compared to Signal.

Figures (8)

• Figure 1: Sequence of algorithm execution throughout the four communication phases in the Signal protocol, namely, registration ($\mathtt{reg}$), session establishment ($\mathtt{sessEst}$), symmetric ratcheting ($\mathtt{symRatch}$), and asymmetric ratcheting ($\mathtt{asymRatch}$). Each of the three algorithms, namely, $\mathtt{PkbGen}$, $\mathtt{EphKeyGen}$, and $\mathtt{MessKeyGen}$, changes the state of a sender represented by the tuple depending on the phase of the communication.
• Figure 2: Our system and adversary model. The system model is identical to that of Signal's. It consists of three parties, a sender $A$ and a recipient $B$ communicating via an honest server $S$ that forwards envelopes. The adversary model consists of adversary $\mathcal{E}$ capable of manipulating the messages on the communication channels between $A$ and $S$, and between $S$ and $B$. The adversary has the additional ability to clone the state of $A$ at most one time, thereby accessing all $A$'s secrets.
• Figure 3: An overview of the phases of registration ($\mathtt{reg}$) and session establishment ($\mathtt{sessionEst}$) integrated with our solution. Our modifications are applied in the Registration Protocol and the first envelope sent and received in the session establishment (and subsequent asymmetric ratcheting) where using the Envelope Sending Protocol and the Envelope Fetching protocol respectively. Symmetric ratcheting proceeds identically with the original Signal protocol. Recall from \ref{['sec:sysAdvModel']} that due to the asynchronicity of Signal, the communicating pair of clients are not required to be online at the same time.
• Figure 4: The Registration Protocol where a client $A$ generates and sends its prekey bundle to the server $S$. The client and and the server both calculate and store the client's initial keychain computed from the generated public keys.
• Figure 5: The Envelope Sending Protocol in the session establishment phase and the asymmetric ratcheting phase of the Signal protocol. In this protocol, a sender $A$ sends the first envelope of the epoch intended for a recipient $B$ to the server. If the protocol is successful, the server accepts and stores the sender's envelope for the recipient. ①: Parameters for session establishment. ②: Parameters for asymmetric ratcheting.