[cryptography] Design Strategies for Defending against Backdoors

ianG iang at iang.org
Mon Nov 18 04:39:11 EST 2013


On 18/11/13 10:27 AM, ianG wrote:
> In the cryptogram sent over the weekend, Bruce Schneier talks about how
> to design protocols to stop backdoors.  Comments?


To respond...

> https://www.schneier.com/blog/archives/2013/10/defending_again_1.html
>
> Design Strategies for Defending against Backdoors
>
> With these principles in mind, we can list design strategies. None of
> them is foolproof, but they are all useful. I'm sure there's more; this
> list isn't meant to be exhaustive, nor the final word on the topic. It's
> simply a starting place for discussion. But it won't work unless
> customers start demanding software with this sort of transparency.
>
>      Vendors should make their encryption code public, including the
> protocol specifications. This will allow others to examine the code for
> vulnerabilities. It's true we won't know for sure if the code we're
> seeing is the code that's actually used in the application, but
> surreptitious substitution is hard to do, forces the company to outright
> lie, and increases the number of people required for the conspiracy to
> work.


I think this is unlikely.  The reasons for proprietary code are many and 
varied, it isn't just one factor.  Also, efforts by companies to deliver 
"open reference source" and pre-built binaries have not resulted in 
clear proof of no manipulation;  it's often too difficult to reproduce a 
build process.

One of the slides indicated how many google protocols that the NSA had 
built engines for;  a big operation does have a lot of internal 
protocols.  There are reasons for this, including security reasons.


>      The community should create independent compatible versions of
> encryption systems, to verify they are operating properly. I envision
> companies paying for these independent versions, and universities
> accepting this sort of work as good practice for their students. And
> yes, I know this can be very hard in practice.


This is the model that the IETF follows.  They require two independent 
versions.  Yet, with that requirement comes a committee and a long 
debate about minor changes;  which many have criticised does more harm 
than good.

This argument was used to wrest control of SSL away from Netscape.  Did 
the result make us any safer?  Not really, even though there were bugs 
in the internal SSL v1, it rested heavily on opportunistic encryption, 
which would have given us a much bigger defence against the NSA's mass 
surveillance programme.

The jury's not yet out on the question of whether the CA/PKI thing is a 
benefit or a loss.  What would happen if the next set of Snowden 
revelations were to show evidence that the NSA promoted the PKI as a 
vulnerability?

What would happen if we just handed the change management of SSL across 
to google (as a hypothetical pick) ?  Would they do a worse job or a 
better job than PKIX ?


>      There should be no master secrets. These are just too vulnerable.

OK.

>      All random number generators should conform to published and
> accepted standards. Breaking the random number generator is the easiest
> difficult-to-detect method of subverting an encryption system. A
> corollary: we need better published and accepted RNG standards.


But:  the RNG is typically supplied by the OS, etc.

What seems more germane would be to include usage of both the OS's RNs 
and also to augment those in case of flaws.  Local randomness exists, 
and it typically available at an application level, in ways it is not 
available at OS level.

If we had a simple mixer and whitener design, that did not disturb the 
quality of the OS nor the local source, surely this would be far better 
than what we got from NIST, et al?


>      Encryption protocols should be designed so as not to leak any
> random information. Nonces should be considered part of the key or
> public predictable counters if possible. Again, the goal is to make it
> harder to subtly leak key bits in this information.


Right, that I agree with.  Packets should be deterministically created 
by the sender, and they should be verifiable by the recipient.



But, overall, when it comes down to it, I think the defence against 
backdoors is not really going to be technical.  It think it is more 
likely to be attitude.

The way I see things, the chances of a backdoor in say Silent Circle are 
way down, whereas the chances of a backdoor in Cisco are way up.  Cisco 
could do all the things above, and more, and would still not increase my 
faith.  SC could do none of the things above, and I'd still have faith.

I think we are still waiting to see which companies in the USA are 
actually going to stand up and fight.  Some signs have been seen, but in 
the aggregate we're still at the first stage of grief -- denial.  In the 
aggregate, it seems that the Internet has just slipped back to the old 
international telco days -- every operator is a national champion, and 
is in bed with their national government.

Pure tech or design can't change that.  Only people can change it, by 
making deployment decisions.



iang


More information about the cryptography mailing list