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

Fabio Pietrosanti (naif) lists at infosecurity.ch
Wed Aug 21 03:35:07 EDT 2013

Hey Peter,

thanks for your analysis!

I think we need to provide some additional input!

In the context of GlobaLeaks where, stating from our Threat Model at
, the Whistleblower can also be NON anonymous but approach a submission
with "Confidential" level (over HTTPS over the internet) .

No anonymity, but forced disclaimer (
https://github.com/globaleaks/GlobaLeaks/issues/260) and acceptance to
take the risk.

So, let's say that whistleblower is already in a bad position, but he
accepted this condition.

We are not considering in any way to add actions/protection on
Whistleblower-Side but only on Receiver-Side that is where the "bad guy"
would be able to read Notification information sent and apply Time
Correlation on the Whistleblower-Action.

Today if a Whistleblower make a submission, the system immediatelly send
a notification to the Receiver.

That's bad, because it leave a trace that allow time correlation.

Who can read Receiver's email and traffic, can make a correlation on
other data source where the whistleblower may leave traffic-traces (like
a proxy, but also internet traffic dump, phisical badge/access logs,
surveillance camera, etc) .

Which kind of logic / algorithm to apply on the Receiver's notification
timing in order to prevent / reduce the likelihood that a time
correlation pattern is possible?

A random delay between a lower bounday and an upper boundary seems like
the most simple and effective approach to defeat this kind of correlation.

However this does not work on very low-traffic globaleaks node.

What do you think?

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

Il 8/21/13 4:17 AM, Peter Maxwell ha scritto:
> Hi Fabio,
> While I don't mean to be dismissive, I suspect your threat model is
> flawed for the following reasons:
> i. Most mid to large companies would not permit the use of Tor within
> their infrastructure and even if the hypothetical company did, it
> doesn't take a whole lot of effort to track down the handful of users
> within a company using Tor/stunnel/ssh/VPN.  For that matter, I
> understand some companies even install private CA certificates into
> the browsers on company computers and decrypt outgoing SSL/TLS traffic
> at their web-proxy/firewall... in that situation, you're WB is going
> to stand out like a sore thumb as they'll be the only TLS connection
> that isn't being decrypted (because it's Tor).  So unless you want
> your whistle-blowers to literally advertise their presence as worthy
> of attention, they aren't going to do the leak from an company system
> directly.
> ii. So, presuming i. is valid - and I suspect anyone who has worked
> within a competent security operations team will tell you the same -
> then you must assume the whistle-blower will do the leak from either
> their personal systems, a burn computer or a public system.  If we
> make the assumption that the WB has taken the data out of the
> company/organisation on removable media or otherwise made it available
> to themselves outside the company infrastructure in a secure manner
> (while sometimes difficult, that is still far easier than i.) then
> your attacker can only see the WB's traffic if they are actively
> monitoring the WB's use of computers outside the company, in which
> case said WB has far bigger problems to worry about.  If the attacker
> cannot monitor the timing of the leak, your problem is not framed in
> the manner you've presented.
> iii. Even if your model was realistic, you cannot adequately defend
> against traffic analysis for such a low-traffic network: you need
> other traffic to hide in, lots of it, from other users within the same
> company - it's not realistic for this type of service.
> iv. There are more subtle problems you are going to come across, not
> least of which are issues such as document
> tagging/water-marking/document versioning and the ability for the
> attacker - your hypothetical manager - to correlate leaked documents
> against the access rights and access patterns of potential
> whistle-blowers.  For that matter, simple forensic analysis of staff
> computers is usually more than sufficient (and yes, organisations do
> this).
> It's also Isle of Man that people like hiding their ill-gotten-gains
> in, not "Island of Mann" ;-)  Interestingly, I think anyone who has
> used Isle of Man accounts for tax avoidance are scuppered as the HMRC
> has signed an agreement with the authorities there for automatic
> disclosure.
> Anyway, as far as I can see it, you have two different scenarios to
> consider with one being significantly more difficult to solve than the
> other:
> A. The scenario where the whistle-blower is able to take the data out
> the company on removable media or paper-copy.  This is the easy one to
> solve.  Personally I would favour a combination of asymmetric
> encryption with single-use keypairs and USB sticks in the post, but
> I'm old fashioned that way.
> B. The scenario where the whistle-blower has to leak from the
> company/organisation's network.  This is extremely difficult indeed.
>  If I were approaching this problem myself, my first considerations
> would be: how to make the traffic look like normal web-traffic; how to
> ensure no forensic traces are left; and how to do that without
> installation of third-party software as that is a dead give-away.  If
> the quantity of data is larger than a few hundred Mb, the problem is
> probably not solvable.
> That's my tuppence-worth, hope that helps,
> Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130821/f88c6205/attachment-0001.html>

More information about the cryptography mailing list