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

Peter Maxwell peter at allicient.co.uk
Tue Aug 20 22:17:45 EDT 2013


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/e93dfb2b/attachment.html>


More information about the cryptography mailing list