It looks like you're using an Ad Blocker.
Please white-list or disable AboveTopSecret.com in your ad-blocking tool.
Thank you.
Some features of ATS will be disabled while you continue to use an ad-blocker.
(visit the link for the full news article)
In an e-mail sent to BSD project leader Theo de Raadt, former NETSEC CTO Gregory Perry has claimed that NETSEC developers helped the FBI plant "a number of backdoors" in the OpenBSD cryptographic framework approximately a decade ago.
Perry says that his nondisclosure agreement with the FBI has expired, allowing him to finally bring the issue to the attention of OpenBSD developers.
Allegations that the FBI may have smuggled back doors or weaknesses into openBSD's cryptography have created uproar in the security community.
In an e-mail sent to BSD project leader Theo de Raadt, former NETSEC CTO Gregory Perry has claimed that NETSEC developers helped the FBI plant "a number of backdoors" in the OpenBSD cryptographic framework approximately a decade ago.
Perry says that his nondisclosure agreement with the FBI has expired, allowing him to finally bring the issue to the attention of OpenBSD developers. Perry also suggests that knowledge of the FBI's backdoors played a role in DARPA's decision to withdraw millions of dollars of grant funding from OpenBSD in 2003.
Former government contractor Gregory Perry, who helped develop the OpenBSD crypto framework a decade ago, claims that contractors were paid to insert backdoors into OpenBSD's IPSec stack around 10 years ago. Perry recently warned the openBSD's Theo de Raadt of the development, years after the event, via an email that de Raadt has published in the spirit of openness.
Perry said he had waited until his ten year NDA with the FBI had expired before coming forward with the claims, which remain unsupported by secondary sources. If true the allegations mean that would have an easy way to tap into supposedly secure VPN links and other technologies based on OpenBSD's crypto stack.
"I wanted to make you aware of the fact that 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, the parent organization to the FBI," wrote Perry. "This is also probably the reason why you lost your DARPA funding, they more than likely caught wind of the fact that those backdoors were present and didn't want to create any derivative products based upon the same."
The e-mail became public when de Raadt forwarded it to the OpenBSD mailing list on Tuesday, with the intention of encouraging concerned parties to conduct code audits. To avoid entanglement in the alleged conspiracy, de Raadt says that he won't be pursuing the matter himself. Several developers have begun the process of auditing the OpenBSD IPSEC stack in order to determine if Perry's claims are true.
De Raadt said he had published Perry's email so that those who use potentially affected code can carry out an audit, as well as offering the opportunity for those named in the email to come forward and give their version of events.
In his email, Perry alleges that virtualisation guru Scott Lowe is on the FBI payroll, suggesting this may be behind his recent advocacy of OpenBSD at a technology for VPN and firewall installation in virtualised environments. Lowe denies the charge, saying he never worked for the Feds.
Let’s get right to the point and set the record straight: I am not, nor have I ever been, affiliated with or employed by the FBI or any other government agency.
That’s why I was surprised when word surfaced that I had been implicated in some sort of conspiracy regarding a plan to place secret backdoors into an OpenBSD cryptographic framework, and that my recent advocacy of OpenBSD was based on my alleged involvement with the FBI.
I don’t know where the person who started this rumor got his information, but he is sadly mistaken regarding my involvement. Perhaps the other Scott Lowe is involved; I don’t know.
The other Scott Lowe writes for TechRepublic.com, and currently works for either Elmira College or Westminster College; I’m not sure which. (I’ve seen both; I think it’s Westminster.)
The prospect of a federal government agency paying open source developers to inject surveillance-friendly holes in operating systems is also deeply troubling. It's possible that similar backdoors could potentially exist on other software platforms. It's still too early to know if the claims are true, but the OpenBSD community is determined to find out if they are.
In an email exchange with reporter Robert McMillan, Perry said that attempts to plant backdoors in open source code were made by the Clinton administration to "counter to their supposed relaxation of the Department of Commerce encryption export regulations".
Perry's allegations are being taken seriously even though they don't come alongside anything substantial by way of evidence. Whether true or not, the charge of an OpenBSD backdoor has spawned a debate.
By the way, anybody want to elaborate how Theo de Raadt has been hiding 2 donations accounts from Canadian Tax Revenue Services for years now?
(Paypal and the German account IBAN: DE91 7007 0024 0338 1779 00
BIC: DEUT DE DBMUC
Name: Theo de Raadt
Address: Deutsche Bank, Marienplatz 21
80331 München, Germany
Inside Germany, instead use:
Name: Theo de Raadt
Bank: Deutsche Bank München
BLZ: 70070024
Konto: 338177900
From outside Europe:
SWIFT: DEUTDEDBMUC
Account: 7007 0024 0338 1779 00
Name: Theo de Raadt
Address: Deutsche Bank, Marienplatz 21
80331 München, Germany
.
Many, many commercial security products and real time embedded systems are derived from the OpenBSD Project, due to Theo's liberal BSD licensing approach contrasted with other Linux-based operating systems licensed under the GPL. Many, many commercial security products and embedded systems are directly and proximately affected by any lapse in security unintentional or otherwise by the OpenBSD Project. Almost every operating system on the planet uses the OpenSSH server suite, which Theo and his team created with almost zero remuneration from the many operating systems and commercial products that use it without credit to the OpenBSD Project. Given the many thousands of lines of code that the IPSEC stack, OCF, and OpenSSL libraries consist of, it will be several months before the dust settles and the true impact of any vulnerabilities can be accurately determined; it's only been about 96 hours since their source code audit commenced and your recent article points to at least two vulnerabilities discovered so far.
first of all i have to mention that netsec involvement was indirectly one of the first financial successes of theo de raadt (later mr.t for short) as the sale of 2500 cds through the EOUSA project (one for each us-ins office in the country) brought openbsd to profitable state and allowed mr.t to finance his living by means of the openbsd project.
The INS no longer exists. U.S. Citizenship and Immigration Services (USCIS) is the current name of the agency that administers immigration and naturalization services in the U.S. On March 1, 2003, after the Homeland Security Act of 2002 came into law, former INS functions were placed under three agencies within the newly-created Department of Homeland Security: USCIS, Immigration and Customs Enforcement (ICE), and Customs and Border Patrol (CBP).
When the Defense Department became aware of the backdoors, they simply pulled all their developmental funding from the project, rather than openly identify the flaw. Clearly the EOUSA (Executive Office for United States Attorneys) mandated the FBI to work to insert the backdoors into the system, intended for privacy encryption.
This seems to indicate that the insertion of the backdoors was classified at the Justice Department level, who apparently had the common sense to let the Defense Department know of the engineered inadequacies of the cryptographic subsystem.
....perry mentioned the parts involved were ipsec(4)) and crypto(4)) framework and the "gigabit ethernet stack." but see? there is no such thing as "gigabit ethernet stack." moreover back then all the gigabit ethernet drivers came from freebsd....
...primary goal was to hack on the OCF (crypto framework in openbsd). this does not affect crypto algorithms you'd say right? but why try to plant subtle and enormously complicated to develop side channels into math (encryption and hashing) when it's way easier to just make the surrounding framework misbehave and leak bits elsewhere? why not just semioccasionally send an ipsec(4)) packet with a plain text key appended to it? the receiver will drop it as broken (check your ipsec stats!) and the sniffer in the middle has the key! how would one do it? a little mbuf(9)) underflow combined with a little integer overflow. not that easy to spot if more than just one line of code is involved. but this is just a really crude example. leaking by just tiny bits over longer time period would be even more subtle.
here are just some observations i had made during ipsec hacking years later... some parts of ipsec code were to say at least strange looking. in some places tiny loops were used where normally one would use a function (such as memcpy(3)) or a bulk random data fetch instead of fetching byte by byte. one has to know that to generate 16 bytes of randomness by the random(4) driver (not the arc4 bit) it would take an md5 algorithm run over 4096 bytes of the entropy pool. of course to generate only one byte 15 bytes would have to be wasted. and thus fetching N bytes one-by-one instead of filling a chunk would introduce a measurable time delay. ain't these look like pieces of timing weaknesses introduced in ipsec processing in order to make encrypted data analysis easier? some code pieces created buffer underflows leaving uninitialised data or in other words leaking information as well.
meanwhile in calgary... wasting no time netsec was secretly funnelling "security fixes" through mr.t that he was committing "stealth" into openbsd tree.
"stealth" means that purpose of the diffs was not disclosed in the commit messages or the private openbsd development forums except with a few "trusted" developers. it was a custom to hide important development in the openbsd project at that time due to a large netbsd-hate attitude
after all "security" was one of the main important keywords that were separating openbsd from netbsd back then. as we can see holding this funnel for netsec is putting mr.t on the payroll also.
actually it would be all too easy to spot the malicious code if it all be in the publicly-available sources. this leads us to believe that bits of the solution were in the hardware. unsurprisingly netsec was producing their own version of hifn(4) crypto accelerator. unfortunately hifn was refusing to disclose full docs for their their hifn7751 chip and that prevented the driver from being included in the openbsd base system.
...it was without any help from anybody else except for mr.t ... and that worked. this was to show hifn that their "protection" is crap on the stack. the driver for the devices was written by mr.j who had access to public docs that lacked the "unlocking" sequence. this allowed netsec to start deploying their hifn(4)-based cards which by no doubt were a part of the side-channel scheme.
about the same time at the bazaar show in nyc i was contacted by a representative of us-ins and a ukrainian millitary attache at un. both investigating my involvement with openbsd. a few months later i was offered an interview for a position at the fbi office for cyber-warfare in nyc who as well offered to fix my immigration status (or none thereof at the time
soon enough due to professional contacts of mr.a the darpa grant for the openbsd was materialised. this was for two years work on various crypto technologies to be integrated in openbsd.
alot of the code resulting from the work sponsored by the grant still is in the repository except for parts that were done just for the noise and uncommitted later. of course no wander that darpa grant was spent primarily on mr.t and mr.j. i would expect mr.a was on benefit indirectly. three other developers on the payroll i suppose had to be there such it would not look completely obvious as a payment to mr.t and mr.j. initially mr.t offered me a position on it too but due to upenn.edu restrictions i could not be involved legally (as you can remember i had an expired immigrant status in the country of u.s. of a.).
... this was slightely disappointing as i had to spend money for coming all the way to philly for the meeting and as it seems for nothing. at least my trip to the following usenix anu-tech in monterey was payed by the moneys from the grant. at the time it only looked kinda funny to travel on the enemy capitalist government's budget monterey by itself has not much of excitement but for the beach scenery and the cia agents for eastern-europe training camp. that would explain body search at the grayhound bus boarding (this was before the post-2001 scare) which ignored the knife and a whisky bottle i had in my pockets.
before going to monterey and while exploring the beauty of san francisco i was contacted once by a us navy intelligence officer who seemingly unintentionally appeared next to me at the bar. later on my way back during a short stay in chicago also randomly appearing fbi agent. fellow was ordering food and beer for me and just like his navy pal gave me a warning to keep my mouth shut!