Who cares about side-channel attacks?

Peter Gutmann pgut001 at cs.auckland.ac.nz
Mon Oct 6 00:51:50 EDT 2008

For the past several years I've been making a point of asking users of crypto 
on embedded systems (which would be particularly good targets for side-channel 
attacks, particularly ones that provide content-protection capabilities) 
whether they'd consider enabling side-channel attack (SCA - no, not that SCA) 
protection in their use of crypto.  So far I've never found anyone who's made 
an informed decision to trade off performance for SCA protection.  By 
"informed decision" I mean the following:

- SCA protection isn't enabled by default, i.e. they don't just get it whether 
  they want it or not.

- The SCA protection is more than just a token throw-some-blinding-at-the-RSA, 
  it extends to things like pubic/private key validation on load (for example 
  via MACs) to detect key-manipulation attacks, checksumming of key data after 
  each crypto op to detect memory-disturb attacks, and so on.

- There is a tangible cost/tradeoff in enabling SCA protection, i.e. it's not 
  just chicken-soup protection, "turn it on, it's a 2GHz multicore CPU it 
  can't hurt".

In other words the user has to make a conscious decision that SCA protection 
is important enough that performance/power consumption can be sacrificed for 
it.  Can anyone provide any data on users making this tradeoff?  And since 
negative results are also results, a response of "I've never found anyone who 
cares either" is also useful.  Since the information may be commercially 
sensitive, respond in private email if you'd rather not discuss it in public 
and I'll summarise if there's any interest.

(Pre-emptive response to the inevitable "OpenSSL/NSS/xyz smart card/... have 
had RSA blinding enabled by default since ...": Yes, I know, and now go back 
and re-read points 1 and 2 above).


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

More information about the cryptography mailing list