<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 21 August 2013 08:35, Fabio Pietrosanti (naif) <span dir="ltr"><<a href="mailto:lists@infosecurity.ch" target="_blank">lists@infosecurity.ch</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>Hey Peter,<br>
      <br>
      thanks for your analysis!</div></div></blockquote><div><br></div><div><div style="font-family:"verdana",sans-serif;font-size:small" class="gmail_default">No worries</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div bgcolor="#FFFFFF" text="#000000"><div> <br>
      <br>
      I think we need to provide some additional input!<br>
      <br>
      In the context of GlobaLeaks where, stating from our Threat Model
      at
      <a href="https://docs.google.com/document/d/1niYFyEar1FUmStC03OidYAIfVJf18ErUFwSWCmWBhcA/pub" target="_blank">https://docs.google.com/document/d/1niYFyEar1FUmStC03OidYAIfVJf18ErUFwSWCmWBhcA/pub</a>
      , the Whistleblower can also be NON anonymous but approach a
      submission with "Confidential" level (over HTTPS over the
      internet) .<br></div></div></blockquote><div><br></div><div><div style="font-family:"verdana",sans-serif;font-size:small" class="gmail_default">Ok, but that wasn't the question you posted ;-)</div><br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
      <br>
      No anonymity, but forced disclaimer (
      <a href="https://github.com/globaleaks/GlobaLeaks/issues/260" target="_blank">https://github.com/globaleaks/GlobaLeaks/issues/260</a>) and
      acceptance to take the risk.<br>
      <br>
      So, let's say that whistleblower is already in a bad position, but
      he accepted this condition.<br>
      <br>
      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.<br></div></div></blockquote><div><br></div><div><br></div><div><div style="font-family:"verdana",sans-serif;font-size:small" class="gmail_default">Erm, that wasn't your scenario presented in your original email:</div>


<div style="font-family:"verdana",sans-serif;font-size:small" class="gmail_default"><br></div><div style="font-family:"verdana",sans-serif;font-size:small" class="gmail_default"><i>"<strong>Their goal is to find which user has performed a certain submission on a globaleaks node</strong>.</i><br>


<br><i>This adversary has the following capabilities:<br><br><br>They can read the content of notification messages.<br><br><br>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)<br>


<br><br><b>A log of traffic from N users they suspect to have blown the whistle. This log includes the timestamp of when </b></i><i><b>the request was made, the response was received and the size of the payload.</b>"</i></div>


<div style="font-family:"verdana",sans-serif;font-size:small" class="gmail_default"><br></div></div><div><br></div><div><div style="font-family:"verdana",sans-serif;font-size:small" class="gmail_default">

 So, which actor in this situation are you trying to protect, how and from what?</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div bgcolor="#FFFFFF" text="#000000">
<div>
      <br>
      Today if a Whistleblower make a submission, the system
      immediatelly send a notification to the Receiver.<br>
      <br>
      That's bad, because it leave a trace that allow time correlation.<br>
      <br>
      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) .<br>
      <br>
      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?<br></div></div></blockquote><div><br></div><div><div style="font-family:"verdana",sans-serif;font-size:small" class="gmail_default">Again, who are you trying to protect and against what?  Your original email was quite clear but you've moved the goal posts, so to speak.</div>


</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
      <br>
      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.<br></div></div></blockquote><div><br></div><div><div style="font-family:"verdana",sans-serif;font-size:small" class="gmail_default">Why, what does it prevent?</div></div><div><br></div><div> </div>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
      <br>
      However this does not work on very low-traffic globaleaks node.<br>
      <br>       What do you think<div style="font-family:"verdana",sans-serif;font-size:small;display:inline" class="gmail_default">?</div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div bgcolor="#FFFFFF" text="#000000"><div><div><br>
      <br>
      <pre cols="72">-- 
Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
<a href="http://logioshermes.org" target="_blank">http://logioshermes.org</a> - <a href="http://globaleaks.org" target="_blank">http://globaleaks.org</a> - <a href="http://tor2web.org" target="_blank">http://tor2web.org</a></pre>



      <br>
      <br></div>
      Il 8/21/13 4:17 AM, Peter Maxwell ha scritto:<br>
    </div><div><div>
    <blockquote type="cite">
      <div dir="ltr">
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small">Hi
          Fabio,</div>
        <div style="font-family:verdana,sans-serif;font-size:small">
          <br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small">While I
          don't mean to be dismissive, I suspect your threat model is
          flawed for the following reasons:</div>
        <div style="font-family:verdana,sans-serif;font-size:small">
          <br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small">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.</div>
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small">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.</div>
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small">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.</div>
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small">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).</div>
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small">
          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.</div>
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small">
          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:</div>
        <div style="font-family:verdana,sans-serif;font-size:small">
          <br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small">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.</div>
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small">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.</div>
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small">
          That's my tuppence-worth, hope that helps,</div>
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <div style="font-family:verdana,sans-serif;font-size:small">
          Peter</div>
        <div style="font-family:verdana,sans-serif;font-size:small"><br>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
cryptography mailing list<br>
<a href="mailto:cryptography@randombit.net" target="_blank">cryptography@randombit.net</a><br>
<a href="http://lists.randombit.net/mailman/listinfo/cryptography" target="_blank">http://lists.randombit.net/mailman/listinfo/cryptography</a><br>
<br></blockquote></div><br></div></div>