Anonymous Traceback for End-to-End Encryption

Abstract

As secure messaging services become ubiquitous, the need for moderation tools that can function within these systems without defeating their purpose becomes more and more pressing. There are several solutions to deal with moderation on a local level, handling harassment and personal-scale issues, but handling wider-scale issues like disinformation campaigns narrows the field; traceback systems are designed for this, but most are incompatible with anonymity.

In this paper, we present Anonymous Traceback, a traceback system capable of functioning within anonymous secure messaging systems. We carefully model security properties, provide two provably secure and simple constructions, with the most practical construction able to preserve anonymity for all but the original source of a reported abusive message. Our implementation shows integration to messaging systems such as Signal is feasible, with client-side overhead smaller than Signals’ sealed sender system, and low overhead overall.

A 6 Proof Sketches

1.1 A.1 6.1 Anonymous Path Traceback

Trace Confidentiality. For trace confidentiality, both user and platform, we can refer back to [13] for their original proofs, as we add no additional information that could be used to distinguish forwarded messages from original messages. This is fairly straightforward to see, while we add (depending on the system), a Signature, Timestamp, and/or Anonymous Blacklisting Authentication Token, these components do not vary between original or forwarded messages. The only difference remains the value of the previous key encrypted as $C_K$, just as it was in the original Traceback paper, and so we can inherit their security here.

Theorem 1

With APT as the anonymous path traceback scheme defined in Sect. 3.1: For any AnonTrUNF adversary $\mathcal {A}$, there are corresponding adversaries $\mathcal {B}$ and $\mathcal {C}$ running in the same time as $\mathcal {A}$ such that:

$$\begin{aligned} \textbf{Adv}^{AnonTrUNF}_{APT}(\mathcal {A}) \le \textbf{Adv}^{cr}_{F}(\mathcal {B}) + \textbf{Adv}^{forge}_{Sig}(\mathcal {C}) \end{aligned}$$

For any $PreAnon$ adversary $\mathcal {A}$, there is a corresponding adversary $\mathcal {B}$ running in the same time as $\mathcal {A}$ such that:

$$\begin{aligned} \textbf{Adv}^{PreAnon}_{APT}(\mathcal {A}) \le \textbf{Adv}^{cpa}_{ENC}(\mathcal {B}) \end{aligned}$$

Trace Unforgeability. As seen in Theorem 1, the adversary’s advantage against anonymous trace unforgeability is a sum of the advantage against the PRF’s collision resistance and the advantage for forging a signature. This means their advantage should be negligible, as otherwise the probability of breaking one of the two secure building block schemes would be non-negligible.

Proof Sketch. For anonymous trace unforgeability, the same four failure cases still form the basis of the proof:

• Case 1: An empty trace.

• Case 2: The identified honest original sender never sent the message.

• Case 3: The reporter never received the message they reported.

• Case 4: An honest user identified as a forwarder did not forward the message.

However, we must also account for the adversary’s additional capabilities; specifically, it is no longer guaranteed that the identity stored matches the identity of the user who actually sent the message. To model this the $\textbf{SendMal}$ Oracle now allows much more freedom to the adversary. In addition, we model the possibility of a change in the sliding window with the $\textbf{ClearDB}$ oracle.

To account for the adversary’s new capabilities we add a game transition; $\textbf{SendMal}$ sets BadSend when the sender identity does not match the tag. This separates out the situations where the original traceback security proof’s assumptions fail. Regardless of why the identities do not match, for the message to have been accepted means a signature must have been forged.

The remaining failure cases are handled as they are in the original [13] proof, with one exception. Cases 1 and 3 are impossible because they require an honest user to report a message they never received; the $\textbf{Send}$ and $\textbf{SendMal}$ oracles both set WasRec. Case 2, $U_j$ falsely identified as original source for a message they did not send, cannot happen in absence of signature forgeries due to PRF collision resistance: a trace for a different plaintext or key must result in the same mid as a different message $U_j$ sent.

Case 4 is similar to Case 2, $U_j$ is falsely identified as a forwarder, and in absence of signature forgery this also requires a PRF collision. Either in the exact same manner as Case 2, or in a special case where $U_j$ is actually the original source. In the original proof this is designated “problematic” and several game transitions are used to isolate it, but on second inspection this is still the result of a PRF collision between the plaintext and fake $k_{prev}$ with some unrelated message and key.

Pre-trace Anonymity. Anonymous path traceback aims for pre-trace anonymity for both the originators and forwarders of its messages, therefore in both cases the $\textbf{Send}$ oracle tracks forwards of the challenge message and $\textbf{Trace}$ oracles disallow tracing those messages.

Proof Sketch. For both $OriginAnon$ and $ForwarderAnon$ the proofs are nearly identical. In both cases security is guaranteed by encryption; the only useful information the adversary has is the server’s view of the challenge messages. When looking at that view, all relevant information is encrypted, so breaking encryption is necessary to learn the sender’s identity. There is one extra wrinkle for $ForwarderAnon$; the adversary can choose the key that will be encrypted by $U_b$ as their $C_K$ value, which the adversary has access to through the $\textbf{DB}$ oracle. However, attempting to recover the key in this way corresponds to a chosen plaintext attack, which would also break the encryption’s security.

1.2 B.2 6.2 Anonymous Source Traceback

Theorem 2

With AST as the anonymous source traceback scheme defined in Sect. 4.1: For any AnonTrUNF adversary $\mathcal {A}$, there are corresponding adversaries $\mathcal {B}$ and $\mathcal {C}$ running in the same time as $\mathcal {A}$ such that:

$$\begin{aligned} \textbf{Adv}^{AnonTrUNF}_{AST}(\mathcal {A}) \le \textbf{Adv}^{cr}_{F}(\mathcal {B}) + \textbf{Adv}^{forge}_{Sig}(\mathcal {C}) \end{aligned}$$

For any $FPostAnon$ adversary $\mathcal {A}$, there are corresponding adversaries $\mathcal {B}$ and $\mathcal {C}$ running in the same time as $\mathcal {A}$ such that:

$$\begin{aligned} \textbf{Adv}^{FPostAnon}_{AST}(\mathcal {A}) \le \textbf{Adv}^{cpa}_{ENC}(\mathcal {B}) + \textbf{Adv}^{forge}_{Sig}(\mathcal {C}) \end{aligned}$$

Originator Pre-trace Anonymity. This aims for pre-trace anonymity for originators, so as in path traceback, the $\textbf{Send}$ oracle tracks forwards of the challenge message and $\textbf{Trace}$ oracles disallow tracing those messages.

Proof Sketch. As the amount of information in the hands of the adversary has slightly shrunk as compared to anonymous path traceback, things remain largely the same as the previous pre-trace anonymity proof.

Just as before, the only useful things here are $C_{PK}$ and $C_{sig}$, which must be decrypted to utilize, and whose key is unavailable and generated independent of any other information. Therefore, breaking the encryption remains necessary.

Theorem 3

With AST as the Anonymous Source Traceback scheme defined in Sect. 4.1, for any $OPreAnon$ adversary $\mathcal {A}$, there is a corresponding adversary $\mathcal {B}$ running in the same time as A such that:

$$\begin{aligned} \textbf{Adv}^{OPreAnon}_{AST}(\mathcal {A}) \le \textbf{Adv}^{cpa}_{ENC}(\mathcal {B}) \end{aligned}$$

Forwarder Post-trace Anonymity. Anonymous source traceback aims to give forwarders post-trace anonymity, so unlike the previous anonymity definitions, the $\textbf{Send}$ and $\textbf{Trace}$ oracles do not limit tracing in any way. However, to account for the new avenue the message server has in gathering information, we also add the $\textbf{Request}$ oracle to allow querying the tracing server.

Proof Sketch. The new $\textbf{Request}$ oracle allows the adversary to attempt to gain information on forwarders of a message after a trace is complete, however to do so would require forging the ephemerally keyed signature meant to ensure the Message Server’s honesty. We use a game transition to isolate this possibility. Outside of that new possibility, the adversary cannot learn path information from the Tracing Server. While we now allow tracing messages downstream from the forwarder whose identity we want to protect, this gives no real advantage without the path information, so breaking encryption is still required to learn the forwarder’s identity.

Anonymous Trace Unforgeability. The primary difference from the anonymous path traceback proof is that no tracing information can be verified at the time of tracing aside from the final result’s. For most of that information, there is no real benefit to providing bad entries; the signature will fail to verify and honest recipients will drop the message. The one interesting case is $C_K$, which is no longer included in the signature. If $C_K$ could be chosen properly, it would redirect a trace in a completely different direction, but that still requires violating the collision resistance property of the PRF. As we no longer have to worry about the full message path remaining accurate, only two failure conditions remain: an empty trace, and a misidentified source. These reduce in the same way as the previous unforgeability proof; if the identities mismatch a signature was forged, and otherwise a PRF collision occurred.