[Cryptography] [FORGED] Attackers will always win, and it's getting worse!

[Arnold Reinhold]

On Mon, 10 Jul 2017 04:40 Peter Gutmann wrote:


> Henry Baker <hbaker1 at pipeline.com <mailto:hbaker1 at pipeline.com>> writes:
> 
>> User crypto software (the "attacked") has to run in such a way that:
>> a.  It produces the correct answer; and
>> b.  It does NOT LEAK SECRET INFORMATION through side-channels -- e.g., 
>>   timing/power/etc.
> 
> However, in virtually all situations a >>> b.  In fact, in most cases you 
> can safely ignore b, because such an attack is impossible/impractical/too 
> expensive/far easier attacks exist/etc.
> 
> In addition, even where b is a concern, it's often far easier to do the 
> crypto in whatever way is the most efficient and then deal with side-
> channels through shielding, power supply decoupling, etc.
> 
> OTOH you really do need to worry about a.  Look at the number of 0days and 
> other subversion mechanisms used by TLAs that have leaked in the last couple 
> of years.  Making sure your code has no holes in it is a far more serious 
> issue than side channels.
> 
>> Any thoughts on how to better engineer side-channel-secure systems?
> 
> That's asking the wrong question.  Well, unless it's a gedanken-experiment 
> style question to see what people will come up with.  The real question is, 
> which attack vectors are being exploited the most, and how do we deal with 
> those?
> 
> Incidentally, we already know how to make secure systems that are pretty
> side-channel-attack resistant.  There's a twenty-year-old HSM, IBM's 4758, 
> that was resistant to pretty much all of the side-channel attacks that came 
> along after it was developed, not because the developers were magically 
> aware of them but because they used good engineering practice, power supply 
> decoupling, filtering, etc.
> 
> The 4758 was attacked by the Cambridge folks, not via any side channels but
> through a basic software flaw in the CCA firmware.  You don't need to bother
> with b when a will always get you in.

This is a classic engineering pattern: we ignore b because a is a much more likely. Effort is successfully directed at a and eventually b becomes a major problem. 

A lot of effort is going into getting software that does produces the correct answer: new, safer languages such as Rust, Swift and Haskell, formal verification systems that Perry, at least, thinks are becoming real, better testing tools, etc. We may not there yet, or even close, but progress is being made. So I think it is appropriate to pay attention to b. 

Newer symmetric ciphers are already designed to minimize side channel leakage. Hardware security modules are a potential solution in some cases, but they have limitations, including size, cost, and the potential for hidden flaws, accidental or deliberate. It that power supply filter capacitor inside the protective mesh? If not it may be easy to disconnect. Can I update my HSM’s firmware? Is yes or no the better answer? 

One possible area for improvement is the tool chain. The C/C++ folks insist that they only make promises about final outputs of programs, not what happens to data while it is being processed.  Does anyone doubt that compilers and linkers could keep track of sensitive data and insure that it was handled in a way that minimized leakage to the extent possible? Do any of the newer languages do better? Do we need special languages for crypto, perhaps with fewer features but more predictable relationships between source and object code? Or maybe just configuration management tools that insure compiler optimization levels are never turned on? 

No doubt there are other areas worth looking at as well. 

Arnold Reinhold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170711/43e44db4/attachment.html>