<div class="gmail_quote">On Mon, Sep 6, 2010 at 2:08 PM, Thomas DuBuisson <span dir="ltr">&lt;<a href="mailto:thomas.dubuisson@gmail.com">thomas.dubuisson@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">&gt;&gt; You could have gone to Hackage and checked your protocols correctness<br>
&gt;&gt; using CPSA, not that the side-channel attacks would be discovered by<br>
&gt;&gt; such a tool.<br>
&gt;<br>
&gt; Interesting. I had seen CPSA announced at one point, but there appears to be<br>
&gt; no documentation whatsoever. Did I miss the doc links?<br>
<br>
</div>There&#39;s lots of documentation:<br>
<br>
$ cabal unpack cpsa<br>
$ cd cpsa*<br>
$ cd doc<br>
$ ls *.pdf -- or you might have to build from .tex, I can&#39;t recall.</blockquote><div><br></div><div>Right, I discovered that shortly after sending my email and making a fool of myself.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
&gt; The two large families of side-channel attacks that I know of and that have<br>
&gt; been popular (== successful) recently are:<br>
</div>&gt; ... timing and cache miss attacks ...<br>
&gt; Am I making sense?<br>
<br>
So much sense it&#39;s painful.  (that&#39;s a &#39;yes&#39;)<br>
<div class="im"><br>
&gt; Another of my tentative projects was to write a C library that implements<br>
&gt; popular crypto building blocks, with a large battery of tests for<br>
&gt; correctness and resistance to timing attacks.<br>
<br>
</div>But how does that prevent a timing-based information flow if the<br>
consuming Haskell application is the one performing the branch?  Are<br>
you assuming all information flow in the Haskell program is so<br>
high-level its not cryptographically important, thus protecting these<br>
low-level primitives is sufficient?</blockquote><div><br></div><div>Good question. No, not necessarily. In theory all the code of a program that performs crypto, including the &quot;user code&quot; that generates the data being encrypted (in the case of a transport protocol) needs to be hardened against side-channel analysis.</div>
<div><br></div><div>In practice, aside from greatly increasing the cost of developing the software, there is somewhat less to be gained: when considering attacks against higher level protocols, it usually comes down to finding a design flaw (e.g. &quot;TLS renegociations are not cryptographically bound to the enclosing channel, allowing an attacker to inject arbitrary prefixes to victim transmissions&quot;) or a direct implementation error (e.g. &quot;OpenSSL omits to check the well-formedness of the server certificate in certain situations, leading to arbitrary code execution&quot;).</div>
<div><br></div><div>Timing attacks additionally require that you are aiming squarely at a fairly small piece of code, to avoid confounding your measurements with other changes in codepath. In theory it is possible to perform a timing attack on large pieces of code, but in practical attacks it comes down to varying the execution path of a small subset of the whole stack, while keeping the rest as constant as possible. And the small building blocks of protocols are, roughly speaking, basic crypto ops and comparisons.</div>
<div><br></div><div>So, if you can ensure that those have good timing properties, you&#39;re in rather good shape. An attacker might still be able to time the higher level protocol, but the outcome would be useless, e.g., &quot;If I present an invalid cert, the server responds with latency A, whereas a valid cert results in latency B&quot; vs. &quot;latency is a function of the key bits, a function that I can use to compute a valid key!&quot;.</div>
<div><br></div><div>Of course, I&#39;m handwaving slightly. Of course, in a perfect world, the higher level protocol should be treated with the same attention to timing attacks as the basic blocks. However, it seems to me that in the real world, basic crypto blocks are more susceptible to timing attacks, whereas high level protocols are more susceptible to design flaws or simple implementation errors.</div>
<div><br></div><div>Haskell is a strong ally to eliminate the latter kinds of flaws, while C is a better ally to produce code that executes with specific timing properties. At least, this is my perception of the situation, and the reasoning behind having a C library for basic blocks, but implementing high level protocols in Haskell. Perhaps more experienced Haskell hackers will disagree (much to my delight, if it means I can write more Haskell and less C!).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Also, if you feel any of these<br>
tests would fit into the Test.Crypto module (or a submodule) then<br>
please feel free to send in a patch or start some discussion.<br></blockquote><div><br></div><div>Once I reach the point of implementing crypto code, I&#39;ll certainly add to the common test suite rather than roll my own.</div>
<div><br></div><div>- Dave</div></div>