[Cryptography] GHCQ Penetration of Belgacom

[Michael Kjörling]

On 18 Dec 2014 14:18 -0700, from jsd at av8n.com (John Denker):
> A hypothesis to consider:  Perhaps other economic forces could 
> be brought to bear.  The perception (whether entirely true or
> not) that Cisco's revenue is suffering from post-Snowden
> distrust might be enough to change behavior.  On the other
> hand, if you're in Belgium, buying tech from China instead 
> of the US doesn't seem like an improvement.  Commercial 
> advantage would accrue to the first vendor who could offer 
> products with a warranty, certified free of back doors.
> 
> I'm not sure exactly how it would work, but one could imagine
> independent certification laboratories, perhaps like UL.com
> or kaspersky.com.  The labs could test a random sample of the 
> company's products.  Certification by labs in two different
> countries would make life harder for the nation-state bad
> actors.

I strongly doubt that would work at all. Anyone with an ounce of
knowledge of system engineering and development knows how complex
something like the equipment involved is. Numbers from Wikipedia and
just one example, but Linux 1.0.0 (March 1994) was 176k SLOC
(graspable). Linux 2.6.0 (December 2003) was 5.9M SLOC. Linux 3.10
(2013) is _15.8M SLOC_ total. _And that is just the kernel itself._
Once you throw in even what runs on my perimeter router (some version
of Linux, a web server, some custom front-end software for
configuration, IPv4 and IPv6 DHCP client and server, ...) the attack
surface in terms of lines of code in use balloons. And that's even
before considering more obscure threats like compromised CPU microcode
or the fact that Postscript is Turing complete.

And beside the possibility of a deliberately inserted backdoor, there
are likely to be genuine mistakes lurking inside _any_ large code
base. Many of those are not going to create exploitable bugs, but some
might. Some languages are more prone to this than others; for example,
you are more likely to inadvertantly write code that may suffer from
buffer overruns in C than in Java. Indexing errors are perhaps more
likely to occur in Java than in Ada. And so on. You only need to find
one such exploitable bug to get the crowbar in, but the vendor (and
certification institution) needs to find and fix _all_ of them. Static
analysis can help, but still has a ways to go.

Then there is the fact that if someone wants to hide a backdoor, it's
fairly easy to make it such that even looking for things out of the
ordinary in the equipment's behavior during operation won't reveal
much. Port knocking for instance is a technique which is fairly widely
used legitimately to expose services only to believed authorized
users, and with a long enough sequence, can be made almost arbitrarily
difficult to crack open. (It's not a perfect comparison, but a
knocking sequence verifying both source and target port numbers can
get a few hundred bits' worth of security with only a handful of
knocks each carrying 32 bits of entropy, and to anyone else's
equipment is likely to just look like the background noise of the
Internet these days so is unlikely to draw much attention. Throw in
special values in other rarely-used IP or TCP/UDP header fields and
you can get even more.) Without source code access finding something
like that would likely be near impossible to simply stumble upon if
the sequence is long enough and the code is deliberately written to
obfuscate that feature, and even with source code access, you'd still
need to know where among the millions of lines of code to look and be
able to recognize the code as being something out of the ordinary.
(What if the vendor sells built-in port knocking support as a
_feature_?) Also, particularly in C on known hardware, it's fairly
easy to do rather insidious stuff.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)