Update on the OpenBSD IPSEC backdoor allegation [LWN.net] (original) (raw)

| From: | | Theo de Raadt <deraadt-AT-cvs.openbsd.org> | | ----------------- | | ---------------------------------------------------------------------------------------------- | | To: | | Kurt Knochner <cdowlker-AT-googlemail.com> | | Subject: | | Re: Allegations regarding OpenBSD IPSEC | | Date: | | Tue, 21 Dec 2010 12:34:54 -0700 | | Message-ID: | | 201012211934.oBLJYshp014050@cvs.openbsd.org | | Cc: | | tech-AT-openbsd.org | | Archive‑link: | | Article |

without a 'hint' (true or fake),

Well, the allegations came without any facts pointing at specific code.

At the moment my beliefs are somewhat along these lines:

(a) NETSEC, as a company, was in that peculiar near-DC business
    of accepting contracts to do security and anti-security work
    from parts of the government.
(b) For context: 1999-2001 was a period where lots of US govt
    departments pushed the boundaries, because crypto was moved
    from DOD to Commerce so that it could be exported "subject
    to some limits"; the result was that crypto use by private
interests was set to explode, and thus many justifications, not
    just technologies, were being invented to let the US Govt
    continue wiretapping (they have always been addicted to it). 
(c) Gregory Perry did work at NETSEC, and interviewed and hired Jason
    just out of school; by the time Jason started working there
    Perry had been "evicted" from the company, for reasons unknown.
(d) Jason did not work on cryptography specifically since he was
    mostly a device driver author, but did touch the ipsec layer
    because that layer does IPCOMP as well.  Meaning he touched the
    data-flow sides of this code, not the algorithms.
(e) After Jason left, Angelos (who had been working on the ipsec stack
    already for 4 years or so, for he was the ARCHITECT and primary
    developer of the IPSEC stack) accepted a contract at NETSEC and
    (while travelling around the world) wrote the crypto layer that
    permits our ipsec stack to hand-off requests to the drivers that
    Jason worked on.  That crypto layer contained the half-assed
    insecure idea of half-IV that the US govt was pushing at that time.
    Soon after his contract was over this was ripped out.  Soon after
    this the CBC oracle problem became known as well in published
    papers, and ipsec/crypto moved towards random IV generation
    (probably not viable before this, since we had lacked a high-quality
    speedy PRNG... arc4random).  I do not believe that either of
    these two problems, or other problems not yet spotted, are a
    result of clear malice.  So far the issues we are digging up are
    a function of the time in history.
(f) Both Jason and Angelos wrote much code in many areas that we all
    rely on.  Daily.  Outside the ipsec stack.  I forwarded the
    allegation which mentions them, but I will continue to find it
    hard to point my own fingers at them.  Go read my original mail
    for points (a) - (c).
(g) I believe that NETSEC was probably contracted to write backdoors
    as alleged.
(h) If those were written, I don't believe they made it into our
    tree.  They might have been deployed as their own product.
(i) If such NETSEC projects exists, I don't know if Jason, Angelos or
    others knew or participated in such NETSEC projects.
(j) If Jason and Angelos knew NETSEC was in that business, I wish
    they had told me.  The project and I might have adjusted ourself
    to the situation in some way; don't know exactly how.  With this
    view, I do not find Jason's mail to be fully transparent.
(k) I am happy that people are taking the opportunity to audit an
    important part of the tree which many had assumed -- for far too
    long -- to be safe as it is.

where would you start auditing the code? It's just too much.

Actually, it is a very small part of the tree. If we all do our part, it will get better. It still won't be perfect. It is just too big. But we've proven that if we start nibbling at a source tree looking for small bugs or unclear things which need improvement, the results always eventually pay off. So I can't suggest any specific place to start.

Now, as I have started with it, I will continue to do so, at least with the crypto code and PRNG code.

After you sent out your mail, at least 10 people went and studied this code. I've already found a small bug in a totally different side of the random subsystem, and am looking at cleaning up a truly ugly function.

That is the best process we can hope for.

But looked at from the half-glass-full side, it is refreshing to see people trying!

:-)

BTW: iTWire mentions, that two bugs have been found in the crypto code. Where can I find details on those bugs?

http://www.itwire.com/opinion-and-analysis/open-sauce/439...

These are the first two bugs which were found. The first one relates to the CBC oracle problem mentioned earlier (it got fixed by angelos in the software crypto stack, but the same problem was ignored in all the drivers jason maintained. Neither Jason nor Angelos were working for NETSEC at that time, so I think this was just an accident. Pretty serious accident).

CVSROOT: /cvs Module name: src Changes by: mikeb@cvs.openbsd.org 2010/12/15 16:34:23

Modified files: sys/arch/amd64/amd64: aesni.c via.c sys/arch/i386/i386: via.c sys/arch/i386/pci: glxsb.c sys/dev/pci : hifn7751.c hifn7751var.h safe.c safevar.h ubsec.c ubsecvar.h

Log message: Bring CBC oracle attack countermeasure from r1.32 of cryptosoft.c to the hardware crypto accelerator land. This fixes aes-ni, via xcrypt, glxsb(4), hifn(4), safe(4) and ubsec(4) drivers.

Original commit message by angelos:

Don't keep the last blocksize-bytes of ciphertext for use as the next plaintext's IV, in CBC mode. Use arc4random() to acquire fresh IVs per message.

with and ok deraadt, ok markus, djm

CVSROOT: /cvs Module name: src Changes by: jsg@cvs.openbsd.org 2010/12/16 09:56:08

Modified files: sys/crypto : cryptodev.h lib/libssl/src/crypto/engine: hw_cryptodev.c

Log message: move CRYPTO_VIAC3_MAX out of cryptodev.h and into the only file it will be used from.

requested by/ok mikeb@

Other more recent commits have come out of this as well. Just go look at the Changelog ..