[Cryptography] Security clearances and FOSS encryption?

[ianG]

On 12/07/2014 20:13 pm, Rick Smith, Cryptosmith wrote:
> 
>> Date: Fri, 11 Jul 2014 11:41:10 +0100
>> From: ianG <iang at iang.org>
>>
>> On 8/07/2014 17:27 pm, Rick Smith, Cryptosmith wrote:
>>> It should be clear by now from the conversation that holding a security clearance doesn't in general qualify or disqualify someone from working on FOSS.
>>
>> I would say, unless your FLOSS project is specifically a target, this is
>> probably true.
> 
> Could you explain why you say this?


Anyone with a security clearance is vulnerable to being manipulated into
an attacker.  The reason for this is that a security clearance is more a
contract, they are more bound to the organisation;  e.g., it is their
duty to report activity to their security officer, which leads them
almost immediately into a breach of either security rules or your FLOSS
interests.

If your org is targetted, then the risk of this person being used goes
right up.    So, the existence of the security contract might place the
person in a position of vulnerability from both sides, which has to be
managed carefully.  Most FLOSS projects care about their people, and
would not want their contributors to be put in harm's way.

So in very general terms, I would say:  if your organisation is
targetted, and the person has a security clearance with an aggressive
agency, then the person should not be put in harm's way.  Disqualified
from working on security critical areas.


>>> ... If someone intentionally subverts a FOSS project as their job representing an intelligence agency, then the agent isn't going to be bragging about security clearances. At least, a competent agent won't.
>>
>> Right.  In at least one case I saw, the agent tried to keep the
>> relationship a secret, citing privacy concerns.  This was intentional.
> 
> Of course.
> 
> Do FOSS projects only admit participants whose identities can be verified? Or can they be vouched by previously trusted participants? (Transitivity again). 
> 
> Should we argue that people who keep elements of their life private shouldn't be trusted to participate in FOSS projects?


In order to avoid privacy being a weapon in this way, we place the
process before arbitration, which is typically 'sealed' that is recorded
but closed off to public view.


>>> In any case, it comes down to a single solution - assurance through multi-person control. Teamwork for system maintenance, teamwork for code review, teamwork for everything. Human error and incompetence are bigger risks, and we can reduce the risks with the same mechanism.
>>
>>
>> Yup, it comes down to modifying your existing systems to cope with a
>> novel attack vector, more or less.  If they don't already cope with the
>> approximate attack then that's likely because you don't care.
> 
> Is source code subversion a "novel attack vector" for FOSS projects?

Yes, I would say so.


> I thought it was a generally recognized one for all software development today. I acknowledge that there are novel ways to subvert crypto. It might be easier to do and harder to detect.


In my experience, a miniscule number of FOSS projects have a clue about
security.  And a miniscule number of those practice hard security.


iang