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

Ben Laurie ben at links.org
Wed Aug 21 05:51:38 EDT 2013


On 21 August 2013 03:35, Fabio Pietrosanti (naif) <lists at infosecurity.ch>wrote:

>  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
> https://docs.google.com/document/d/1niYFyEar1FUmStC03OidYAIfVJf18ErUFwSWCmWBhcA/pub, 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?
>

I think that if you want to send messages that are hard to trace, there's
an existing technology: mixmaster, with an existing server network.

Or, better yet, finish off mixminion,

Even better: implement Minx (the fixed version).


>
>
> --
> Fabio Pietrosanti (naif)
> HERMES - Center for Transparency and Digital Human Rightshttp://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
>
>
>
>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20130821/1f42f4f0/attachment-0001.html>


More information about the cryptography mailing list