Closing the Gap between Sender Anonymity and Abuse Mitigation

You just can’t win with the Internet! At its best, it is the greatest machine ever constructed and can spread knowledge to every single…

Photo by Viktor Talashuk on Unsplash

Closing the Gap between Sender Anonymity and Abuse Mitigation

You just can’t win with the Internet! At its best, it is the greatest machine ever constructed and can spread knowledge to every single person on the planet. At its worse, it is a cesspit of evil doing and abuse.

So now a new paper aims to tread this fine line, and try and support privacy, whilst supporting abuse mitigation [here]:

Figure 1

With sender-anonymous end-to-end encrypted messaging, an abusive person could send messages to a user, without revealing their identity. For this Signal has added a feature that integrates an abuse mitigation mechanism which will block users who send abuse to other users. The paper outlines that it is a weakly defined method in terms of its anonymity features, and also that an abusive person can drain the battery of a victim — defined in the paper as a griefing attack.

To overcome these problems, the research team propose Orca, and which allows users to create a privacy-preserving blocklist. The user then never learns the identity of the person, but the platform can check if someone is on this list. This involves a group signature scheme.

Signal mechanism

A user on the Signal platform has a long-term secret key (sk_s) and a long-term public key (pk_s). They then receive a receiver public key for the recipient: pk_r. After this, Signal uses a double ratchet mechanism to preserve the privacy of the conversation. The platform can then check users when they connect to the platform through the authentication phase and thus block them from the platform or from contacting certain users. But, this type of checking does not support user anonymity.

Signal supports a Sealed sender approach, and where the identity of the sender can remain anonymous. For this, they send their public key (pks) to the platform, and it generates a short-term sender certificate (cert) for the user. This contains the digital signature of the platform, and can then be trusted by other users. In order to receive sealed messages, a recipient generates a 96-bit access key (ak). They will then register pk_r and ak with the platform. In order to send a sealed message, the sender must send ak to the recipient. If they want, a user can bar the acceptance of these for anyone who is not in their contacts list. It will then not be possible for a user to receive a sealed message.

Signal sealed sender attacks

The paper outlines three attacks on Signal’s sealed sender approach:

  • Traffic analysis of sender-anonymous messages.
  • Traffic analysis of non-sender-anonymous messages.
  • Griefing attack by evading identification.

With the griefing attack, the sender continually sends malformed ciphertext as spamming messages to the recipient, and which continually have to be checked. As the double racket is used, the platform cannot check for these errors, and thus cannot be blocked. The continual checking will then drain the target’s battery. The researchers found that there was a nine-fold increase in battery drain in a Google Pixel phone running Android 9 for just one message sent every 10 seconds.

Privacy-preserving Outsourced blocklist

The paper describes a privacy-preserving outsourced blocklist. This is illustrated in Figure 2, and where the sender’s anonymity is preserved, but the recipient can verify the sender. Each recipient can then register a blocklist and which contains the identities of the senders to block, but where these identities cannot be revealed to anyone. In the case of a grieving attack, the user can inform the platform to drop messages from a specific user, without revealing their identity.

Figure 2

One of the core contributions of the paper is the creation of a group signature approach. This type of method has been used in the past with zCash, and which allows a user to add their private key signature to an overall signature. The public key of other users is then added to the group signature, in order to hide the specific user. A full version of the code can be found here:

Figure 3

Conclusions

We are entering a new phase of the Internet, and one which will aim to respect privacy. But with this approach the opportunities for abuse could thus increase, and where we need to carefully design our system to overcome this. Orca, at least, opens up this debate and outlines a technical solution to a world that increasingly reveals almost every part of someone's life.