login
Search
I have received a mail regarding the early development of the OpenBSD
IPSEC stack. It is alleged that some ex-developers (and the company
they worked for) accepted US government money to put backdoors into
our network stack, in particular the IPSEC stack. Around 2000-2001.
Since we had the first IPSEC stack available for free, large parts of
the code are now found in many other projects/products. Over 10
years, the IPSEC code has gone through many changes and fixes, so it
is unclear what the true impact of these allegations are.
The mail came in privately from a person I have not talked to for
nearly 10 years. I refuse to become part of such a conspiracy, and
will not be talking to Gregory Perry about this. Therefore I am
making it public so that
(a) those who use the code can audit it for these problems,
(b) those that are angry at the story can take other actions,
(c) if it is not true, those who are being accused can defend themselves.
Of course I don't like it when my private mail is forwarded. However
the "little ethic" of a private mail being forwarded is much smaller
than the "big ethic" of government paying companies to pay open source
developers (a member of a community-of-friends) to insert
privacy-invading holes in software.
----
From: Gregory Perry <Gregory.Perry@GoVirtual.tv>
To: "deraadt@openbsd.org" <deraadt@openbsd.org>
Subject: OpenBSD Crypto Framework
Thread-Topic: OpenBSD Crypto Framework
Thread-Index: AcuZjuF6cT4gcSmqQv+Fo3/+2m80eg==
Date: Sat, 11 Dec 2010 23:55:25 +0000
Message-ID: <8D3222F9EB68474DA381831A120B1023019AC034@mbx021-e2-nj-5.exch021.domain.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Status: RO
Hello Theo,
Long time no talk. If you will recall, a while back I was the CTO at
NETSEC and arranged funding and donations for the OpenBSD Crypto
Framework. ...I wonder a lot about the motives of the original sender sending that message. Is it simply a way to spread FUD and discredit openbsd? Is it a personal gripe with the accused? Is it an attempt to manipulate what is used in the market? Is it outright lies Is it outright truth and genuine altruism? While I suspect we'll never know completely for sure, it makes an interesting point. Is it genuine? partially genuine? how much truth is in there? if it's true how much of this mattered and has it since been fixed? (as that code when through a lot of fixes since that time) Of course in these days of binary only blob drivers, I don't think the government need resort to this sort of tactic these days. Those nice binary-only drivers everyone loves running for video and wireless will ensure that there are nice places in your favorite Open Source project that can be coopted quietly by government organizations and have access to your entire kernel. No need to be subtle.
Ignoring motive, and looking at opportunity: We have never allowed US citizens or foreign citizens working in the US to hack on crypto code (Niels Provos used to make trips to Canada to develop OpenSSH for this reason), so direct interference in the crypto code is unlikely. It would also be fairly obvious - the crypto code works as pretty basic block transform API, and there aren't many places where one could smuggle key bytes out. We always used arcrandom() for generating random numbers when we needed them, so deliberate biases of key material, etc would be quite visible. So a subverted developer would probably need to work on the network stack. I can think of a few obvious ways that they could leak plaintext or key material: 1. Ensure that key bytes somehow wind up as padding. This would be pretty obvious, since current IPsec standards require deterministic padding. Our legacy random padding uses arc4random_buf(). 2. Arrange for particular structures to be adjacent to interesting data, like raw or scheduled keys and "accidentally" copy too much. 3. Arrange for mbufs that previously contained plaintext or other interesting material to be "accidentally" reused. This seems to me the most likely avenue, and there have been bugs of this type found before. It's a pretty common mistake, so it is attractive for deniability, but it seems difficult to make this a reliable exploit. If I was doing it, I'd try to make the reuse happen on something like ICMP errors, so I could send error-inducing probe packets at times I thought were interesting :) 4. Introduce timing side-channel leaks. These weren't widely talked about back in 2000 (at least not in the public domain), but have been well researched in the years since then. We have already introduced countermeasures against the obvious memcmp() leaks using timingsafe_bcmp(), but more subtle leaks could still remain. If anyone is concerned that a backdoor may exist and is keen to ...
If this type of thing really did happen and this actually is going on something as simple as systrace or dtrace would have found it correct? Surely folks have monitored and audited the actual function and traffic that goes across the wire... conversely amd has a "debugger" that'll get you access to more goodies than you could imagine and just recently I discovered a similar "debugger" on the wifi chip on my phone. Guess its better it doesn't work anyhow ;) Brandon
It's generally impossible to see from a datastream if it leaks key data. It can be pretty damn hard to verify code to show it does not leak key data
On Wed, 15 Dec 2010 07:48:46 +0100 I think if it leaks data, it must leak data somewhere, i.e. there must be a server somewhere, and this server must have an ip. so if you look at your traffic, and you will find an ip other then ip of your server, you will know where the leak goes. -- With best regards, Gregory Edigarov
Unless of course someone was capturing the entire stream as it traversed the internet and then simply extracted the keys later on.
That's not necessary, key data can be leaked in or alongside the encrypted datastream itself, there's no need to send it anywhere. And it doesn't have to be a whole key, just something that makes things cryptanalysis simpler. *If there's something there*. Remember these are still just allegations at this stage.
The IPSEC allegations have produced a flurry of blog posts and suchlike, mostly just rehashing the contents of Theo's original message. However, I've found two followups that are interesting for their own separate reasons: in http://blogs.csoonline.com/1296/an_fbi_backdoor_in_openbsd , there appears to be some additional veribage from Gregory Perry, but IMHO it does not really add much in the way of useful information. The other item, http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-allegations... is quite a bit more interesting, since it's a public challenge (with a cash bounty) to come up with actual evidence of backdoor code in the relevant parts of OpenBSD. There have been offers to match original 3 * USD 100 bounty, so with a little more circulation the bounty could turn into a good amount. I would say the second post here deserves more attention; if you agree, please make that URL visible via whatever news sites you can think of (yup, it's in the /. submissions queue). - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
On Wed, Dec 15, 2010 at 11:33 AM, Peter N. M. Hansteen <peter@bsdly.net> http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-al It is easy to shoot one's mouth off like that about bounty offered, given the ridiculously constrained "conditions" the bounty is offered under. He might as well offered a million USD. No one will be able to prove this under these restrictions. --patrick
I won't get into a discussion about DES' stated requirements, but I do think it's a good-faith effort. Then again, as Jason Dixon points out in his blog http://obfuscurity.com/2010/12/Updates-on-the-OpenBSD-IPsec-Gossip , making a donation to the OpenBSD project is likely to give you more bang for the buck. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
His conditions aren't "ridiculously constrained", they seem to be pretty much approproiate for the allegations. -d
The requirement that the bug still be exploitable in the current code is a little much. A hidden side channel might possibly be quite fragile and easily disarmed by accident without fixing the underlying flaw, but that wouldn't invalidate the allegation. That part did read a lot like hedging the bet. An exploit like this that only worked pre-4.4 (to pick a random older release for example) would still be very valuable.
seriously? # - that the OpenBSD Crypto Framework contains vulnerabilities # which can be exploited by an eavesdropper to recover plaintext # from an IPSec stream, There is a big assumption about the alleged backdoor or leak; i.e., that it is used to directly extract "plaintext" out of an IPSEC stream. OK. Maybe reasonable. # - that these vulnerabilities can be traced directly to code # submitted by Jason Wright and / or other developers linked # to Perry, and Do they really have to be linked back to Perry? Is that really the important factor in the alleged backdoor's existence? # - that the nature of these vulnerabilities is such that there # is reason to suspect, independently of Perry's allegations, # that they were inserted intentionally-for instance, if the # surrounding code is unnecessarily awkward or obfuscated and # the obvious and straightforward alternative would either not # be vulnerable or be immediately recognizable as vulnerable Oh, so the alleged backdoor if present _must_ be in the form of obfuscated code. Oooookay... # - Finally, I pledge USD 100 to the first person to present # convincing evidence showing that a government agency # successfully planted a backdoor in a security-critical # portion of the Linux kernel. So not only one has to find the alleged backdoor, but also link its author to a "government agency" .. via how I wonder, payroll stub, signed contract, confession? OK, Maybe not too unreasonable, but it still gives a nice loophole for blogger to recant on his bounty. # - In all three cases, the vulnerability must still be present # and exploitable when the evidence is assembled and presented # to the affected parties. Allowances will be made for the # responsible disclosure process. Must still exist? So proving that at some point the alleged backdoor existed and was placed in there by an FBI/NSA pawn isn't good enough, but the alleged backdoor must still exist. Nice... # - ...
I'm not going to comment on the mail itself, but I've seen a lot of incredibly dubious articles on the net over the last few days. - use your brains, people. Just because a guy does say so doesn't mean there's a backdoor. Ever heard about FUD ? - of course OpenBSD is going to check. Geeez!! what do you think ? - why would OpenBSD be in trouble ? where do you think *all the other IPsec implementations* come from ? (hint: 10 years ago, what was the USofA view on cryptography exports ? where is OpenBSD based. Second hint: Canada != UsOfA). - why would the FBI only target OpenBSD ? if there's a backhole in OpenBSD, which hosts some of the most paranoid Opensource developers alive, what do you think is the likelyhood similar backholes exist in, say, Windows, or MacOs, or Linux (check where their darn IPsec code comes from, damn it!) I know that a lot of the guys reading tech@ are intelligent enough to *know* all the rather obvious things I'm stating here, but it's looking like a lot of stupid, stupid web sites are using this as their *only* source of information, and do not engage their brain): if you read french, go check http://www.macgeneration.com/news/voir/180982/un-systeme-espion-du-fbi-dans-openbsd and be amazed at how clueless those writers are. Just on the off chance that those idiots will read this, and realize how stupid their generalizations are. Theo was careful enough to state facts, and I'm a huge fan of what he's done (he's decided to go fully open with this, which was a tough decision). I don't see why this would impact OpenBSD negatively without affecting any other OS... especially until we actually get proof...
I about talked myself out of believing that this happened after explaining this to a cow-orker today. They were quite surprised i'd buy into something this speculative and far fetched at all. After listening to him generalize it back to me it seems even sillier. Brandon
The item I find interesting in all this is one I have not seen
commented on:
"the FBI implemented a number of backdoors and
side channel key leaking mechanisms into the OCF,
for the express purpose of monitoring the site to
site VPN encryption system implemented by EOUSA"
Two things come immediately to mind:
1. If I legitimately need access to monitor traffic over
a VPN I either have access to an endpoint, or I have
the keys. Or a warrant.
2. OpenBSD was (is) by this report used by at least one US
agency. There are lots of other little reports and
snippets over time that suggest use by many other
US government agencies.
Therefore, over and above any technical security issues, we have
the allegation that:
1. An agency is (possibly illegitimately) trying to sniff the
traffic of another agency.
2. To do so, that agency deliberately weakened a tool used
by other US government agencies, thereby compromising
their security.
I call fantasy. (On the other hand: prove a backdoor, create a
political tempest where OpenBSD's involvement is almost incidental.)
Carson
--
Carson Harding - harding (at) motd (dot) ca
I'm really sorry to pitch in here, but... The centerpiece of this thread, besides technical details of how/whether to prove/disprove the so-called accusations, seems to be an argument on whether Perry's purely FUD'ing, promoting his company/pages, creating the buzz, or whether his words should be taken for their face value. I have to say that Perry here is credited with one thing he actually did not do -- publish this to the world. There has been talk of alterior motives here, but for any of these motives, Perry had to know or pretty damn well guessed that the second thing Theo (hi, Theo) would do to his email was to publish it. Would you plan anything based on a predicted behavior of a person you haven't communicated with in 10 years? This is not to point finger at Theo for creating all this commotion, of course; this commotion can, however, be, an unintended accident, but the fact that it came from Theo gave it a lot of credibility. [skipped]
Does anyone know if there was an ultimate outcome to the investigation of side channels supposedly put into DSA by the NSA?
On Tue, Dec 14, 2010 at 5:54 PM, Theo de Raadt <deraadt@cvs.openbsd.org> Funny how this happened right after the massive wiki leaks. It worked though, most people fell for it.
