Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Recently there is a bit of concern over encryption back doors in IPsec and while the status of this has not been confirmed, I don't know what impact something like this might have.
For instance, does this mean that, since encryption on this layer may be compromised, we have vulnerabilities on various platforms of internet technology (for example, SSL)?
What does a working back-door here permit in terms of Eve and Mallory attacks?
I think the biggest impacts will be on the public relations side.
On the plus side (from OpenBSD maintainers point of view), the idea that the FBI deemed OpenBSD important enough, back in 2000, to warrant money-backed insertion of backdoors, is a sure ego inflater. This alone could be a motive for public allegations of backdoors, whether they exist or not. Also, the apparent immediate and full disclosure is a nice PR job.
On the minus side, OpenBSD communication has long been about how much more secure OpenBSD was than any other system, thanks to proactive security auditing and numerous internal code reviews. Finding a ten-year old backdoor right in the middle of cryptographic network code would kind of deflate the myth a bit.
Now, on the technical side...
There are many ways a subtle alteration of the code could constitute a "backdoor". If I were to implement a backdoor myself, I would try to rig the pseudo-random number generator. It is relatively easy to make a PRNG look like it produces cryptographic-quality output, but with, in reality, low internal entropy (e.g. 40 bits). This would make IPsec-protected communications vulnerable to decryption with common hardware and a passive-only attacker (thus undetectable). Also, a flawed PRNG can be attributed to incompetence (because making a bad PRNG is easy, but making a good one is not), opening the road to plausible deniability.
Another backdooring method is data leakage. For instance, whenever you have some random bits in some network packet, you can arrange for these bits to actually contain data about the internal system state. A good backdoor can thus leak secret encryption keys, to be picked up by anybody aware of the existence of the leakage.
Potential buffer overflows are crude backdoors, since they can be exploited only by active attackers, which is risky. Spy agencies usually abhor risks. If such bugs are found in OpenBSD code, I think it is safe to state that they are "true" bugs, not malicious holes.
As I noted in comment, this is a very broad question. There are a wide variety of potential ramifications. One thing is clear though: Theo just got himself a whole bunch of free code reviews ;-).
Maybe the FBI did manage to get a backdoor into the 2001-era openbsd IPSec code. If they did, it means that there have been VPNs that US law enforcement could snoop on. Now whether they did depends on whether anyone deployed the VPN in its snoopable configuration, whether the FBI detected that deployment, and whether they cared.
Maybe the backdoor is still there. All this means is that you can increase the count of at-risk installations. Especially if any other operating systems took their IPSec code from OpenBSD...FreeBSD, Mac OS X and iOS all did.
Now, whether or not the story is true, it's interesting to note that no-one including the OpenBSD project lead can quickly deny it. This, along with the Linux backdoors that have existed over time, lead me to question Torvalds' Law: many eyes make bugs shallow. Apparently it's possible to hide vulnerabilities in plain sight, too.
Many *qualified* eyes can make bugs shallow. While this may or may not be true (interest and motivation still have importance), this at least makes a little more sense.
The answer to your question is easy: if anyone hid nasty code in privileged subsystems, the wrong people could have arbitrary control over systems running the code.
But note that no evidence has been presented (and Perry should have a lot of that), and he offers no apologies.
For more info see
and the humorous conspiratorial comments on the responses by those accused: http://blog.scottlowe.org/2010/12/14/allegations-regarding-fbi-involvement-with-openbsd/ http://marc.info/?l=openbsd-tech&m=129244045916861&w=2
This doesn't really answer your question, but circa 2001 code may have had major changes in the last decade-ish so it's hard to say whether the code would still be there anyway (if it was there in the first place).
Somewhat closer to a useable answer: Graham has a listed a few. The next question is when did they start consuming that code? Before or after the introduction ofthe potential backdoor? If after, was there a code review done by the company? If so, did they find it? If so, did they fix it? If so, did they merge it back into the original project?
The best evidence, as I read it, is that the allegations of a backdoor in OpenBSD are so much hot air. It looks to me like a scurrilous and unjustified smear of OpenBSD, in an attempt to spread FUD (fear, uncertainty, and doubt).
In my view, Gregory Perry's allegations have little credibility at this point. I'll list some of the evidence against his allegations:
I think it is possible that NETSEC conducted internal studies to look into how to modify OpenBSD to add a backdoor for their own internal use, but there is no reason to believe that any backdoor was ever introduced into the official OpenBSD distribution.
Bottom line: I consider Perry's letter, which you quoted, a baseless smear against OpenBSD. OpenBSD has long been highly respected for its dedication to security. I suggest that you treat avoid re-distributing Perry's allegations.
Full disclosure: I have no association with OpenBSD or any of the parties in this little exchange. I have no financial interest in this matter. Heck, I don't even run OpenBSD on my servers. I just hate to see a good product subjected to baseless accusations.
