[Haskell-cafe] ANNOUNCE: secure-sockets version 1.0

[David Anderson]

On Mon, Sep 6, 2010 at 2:08 PM, Thomas DuBuisson <thomas.dubuisson at gmail.com
> wrote:

> >> You could have gone to Hackage and checked your protocols correctness
> >> using CPSA, not that the side-channel attacks would be discovered by
> >> such a tool.
> >
> > Interesting. I had seen CPSA announced at one point, but there appears to
> be
> > no documentation whatsoever. Did I miss the doc links?
>
> There's lots of documentation:
>
> $ cabal unpack cpsa
> $ cd cpsa*
> $ cd doc
> $ ls *.pdf -- or you might have to build from .tex, I can't recall.


Right, I discovered that shortly after sending my email and making a fool of
myself.


> > The two large families of side-channel attacks that I know of and that
> have
> > been popular (== successful) recently are:
> > ... timing and cache miss attacks ...
> > Am I making sense?
>
> So much sense it's painful.  (that's a 'yes')
>
> > Another of my tentative projects was to write a C library that implements
> > popular crypto building blocks, with a large battery of tests for
> > correctness and resistance to timing attacks.
>
> But how does that prevent a timing-based information flow if the
> consuming Haskell application is the one performing the branch?  Are
> you assuming all information flow in the Haskell program is so
> high-level its not cryptographically important, thus protecting these
> low-level primitives is sufficient?


Good question. No, not necessarily. In theory all the code of a program that
performs crypto, including the "user code" that generates the data being
encrypted (in the case of a transport protocol) needs to be hardened against
side-channel analysis.

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. "TLS renegociations are not cryptographically bound to the
enclosing channel, allowing an attacker to inject arbitrary prefixes to
victim transmissions") or a direct implementation error (e.g. "OpenSSL omits
to check the well-formedness of the server certificate in certain
situations, leading to arbitrary code execution").

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.

So, if you can ensure that those have good timing properties, you'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., "If I present an invalid
cert, the server responds with latency A, whereas a valid cert results in
latency B" vs. "latency is a function of the key bits, a function that I can
use to compute a valid key!".

Of course, I'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.

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!).

Also, if you feel any of these
> tests would fit into the Test.Crypto module (or a submodule) then
> please feel free to send in a patch or start some discussion.
>

Once I reach the point of implementing crypto code, I'll certainly add to
the common test suite rather than roll my own.

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100906/0754cfa1/attachment.html