[cryptography] Preventing Time Correlation Attacks on Leaks: Help! :-)

Fabio Pietrosanti (naif) lists at infosecurity.ch
Tue Aug 20 15:31:40 EDT 2013

Hi all,

at GlobaLeaks we are going to implement a feature that want to mitigate
time correlation attacks between a Whistleblower submitting something
and a Receiver, receiving a notification that there's a new leak
outstanding to be accessed.

We already had a internal discussion and received some valuable
suggestions and comments available here
https://github.com/globaleaks/GlobaLeaks/issues/264 .

However being the argument possibly tricky, we would like to subject to
suggestion, criticism and review the proposal.

That's a summary of the context:


When a whistleblower submits to a globaleaks node all receivers that
they have selected as recipients for their submission will receive a
notification informing them that a new submission has occurred. Other
whistleblower interactions also trigger a notification (that should
therefore be protected from timing attacks) and such interactions are:


    A new comment is added to an existing submission by a WB


    A new comment is added to an existing submission by a Receiver


    A new file is uploaded to an existing submission by a WB


We are interested in mitigating correlation attacks based on the
dispatching of notifications for interactions performed by a
whistleblower. It should not be possible (or harder) for an attacker to
determine which person is a whistleblower for a certain submission based
on their capabilities (more on that below).

      Adversary model A

Their goal is to find which user has performed a certain submission on a
globaleaks node.

This adversary has the following capabilities:


    They can read the content of notification messages.


    They can perform a new submission to a globaleaks node and therefore
    trigger notifications (i.e. they are capable of doing
    a /flooding/ /blending/ attack)


    A log of traffic from N users they suspect to have blown the
    whistle. This log includes the timestamp of when the request was
    made, the response was received and the size of the payload.


    The log of the notification traffic. This includes the timestamp of
    when the notification was dispatched and the size of it. The content
    of the notification will be either encrypted (model A) or plaintext
    (model B).

      Adversary model B

This adversary has all the capabilities of the above adversary, but they
do not have the ability of reading the content of the notification messages.

      Adversary model C

All of the above except the receiver is not trusted: their goal is to
de-anonymise the WB.

Is this any different from Adversary A, that is an adversary that has
the ability to read the notification emails because they are not encrypted?

        Example real world scenario

The GL node is a GL node for a private company. The adversary is a
Manager of The Company that wants to find out who blew the whistle on
the fact that he is recycling money through a shell company in the
island of mann.
Since they are on the receiver list, because the globaleaks node was
configured to have a plurality of receivers, they will be able to read
the content of the notification emails.

The whistleblower decided to blow the whistle on from their office and
the office network has a proxy that logs every HTTP request being done.

When the Manager receives a notification that a new submission has been
done to the globaleaks site they take the timestamp of such notification
and look at the traffic logs for that period of time to see who was
generating traffic during that period of time and based on this they
should not be able to distinguish normal Tor user (or people loading the
cover traffic widget) from the whistleblower.

Thanks in advance for opinion!

Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
http://logioshermes.org - http://globaleaks.org - http://tor2web.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130820/080bab7f/attachment.html>

More information about the cryptography mailing list