[Cryptography] Security clearances and FOSS encryption?

[Jerry Leichter]

On Jul 17, 2014, at 7:59 AM, Theodore Ts'o <tytso at mit.edu> wrote:
> ... Companies ... are eagerly accepting interns from China, and/or have
> development centers in China, despite the fact that it's well known
> that the Ministry of State Security is trying their hardest to try to
> penetrate into American data centers.  Despite this, it's just not
> practical for companies to turn their backs on that much raw
> engineering talent, even if some of them could potentially be plants
> from the MSS.
> 
> The goal is to design systems so that even if you have some malcious
> actors, that you have enough auditing and multi-person control systems
> so that a single bad apple isn't going to be able to compromise
> whatever you consider to be most critical data....
What you are describing is another case of "attacking today's problem with yesterday's tools".  Yesterday's problem was the single bad actor who was out to steal data or modify systems to steal money.  The combination "bad actor competent enough to get and stay hired and not be readily detectable" was sufficiently rare that you didn't have to worry that you had two of them - and even if you did, the nature of what they were doing made it unlikely that they would cooperate.

Today's problem is concerted action by state intelligence agencies and, reportedly, organized crime.  The goals of the former include long-term data extrication and various forms of sabotage.  The goal of the later may include data extraction, but also large scale theft.  Certainly the former, and perhaps the latter, have access to large numbers of competent, motivated people who at least in the former case don't even see themselves as bad actors - they seem themselves as patriots.  There is no reason to assume you only have one of these guys on board.  Further, unlike the lone wolves of the past would might discover each other only by accident, and then would have no reason to trust each other, these attackers are coordinated and can work together.  Hell, given the competition for talent these days, every company makes a big deal of having its employees recommend friends.  Get one infiltrator on board, and you can be sure he'll recommend associates.

In the face of this kind of attack, code reviews lose their effectiveness.  Attackers will simply review each others' code.  Oh, sure, *most* of their development and review efforts will be directed toward company goals - but that little fix that opens a hole wide - but on its surface looks completely boring and unlikely to inspire others to have a look - is the one that will be reviewed by a co-conspiritor.

Theoretically, you can get around this by requiring more reviewers.  But in practice just getting a single competent review is usually a hard problem.  Spotting the planting of a security bug by someone who knows what they are doing is very difficult, often impossibly so without detailed knowledge of the code being reviewed.  In any large project, the number of people deeply familiar with any one piece of code will be small - often, there is just one person.  If that one person is the attacker, and he arranges for another attacker to review his attack code, the chance of anyone noticing is tiny.

I can't think of any reasonable defense against the "multiple attackers" problem - which makes me despair of ever getting the intelligence services out of our code bases.  The advantages are all theirs.

                                                        -- Jerry