IP: Fault-induced crypto attacks and the RISKS of press

[Dave Farber <farber () cis upenn edu>]

Date: Fri, 1 Nov 1996 05:59:54 -0800
From: "Paul C. Kocher" <pck () best com>
Subject: Fault-induced crypto attacks and the RISKS of press releases


I've been watching the recent announcements about fault-induced
cryptanalysis with interest [e.g., RISKS-18.50,52,54,55,56].  Whereas the
attacks are extremely powerful tools, they aren't at all new to the crypto
community -- there has been widespread discussion for years about these,
they've been implemented by criminals and security system evaluators, and
they are reasonably well documented.


For example, NIST specifically discuss such attacks and the need to prevent 
them.  FIPS PUB 74-1 (see http://csrc.nist.gov/fips), "Guidelines for 
Implementing and Using the NBS Data Encryption Standard," was published way 
back in 1981 and says in section 5.2.2 on Error Handling: 


>       Errors associated with the primary encryption device should be 
> detected and handled by the secondary device. Physical tampering detectors 
> (vibration or intrusion sensors) may be used to detect physical tampering 
> or unauthorized access to the encryption unit. Sensors which detect 
> abnormal changes in the electrical power or the temperature may be used to 
> monitor physical environment changes which could cause a security problem. 
> However, the major requirement for error detection or correction involves 
> the application itself. The type of error control utilized will depend on 
> the sensitivity of the data and the application. The method selected may 
> range from no error handling capability for some systems to full redundancy 
> of encryption devices in other systems. Errors may be ignored when detected 
> or the entire system may be immediately shutdown.  Errors which could 
> compromise the plaintext or key should never be ignored. 


Anyone interested in issues relating to secure hardware design should also
study FIPS 140-1, "Security Requirements for Cryptographic Modules."  It's
the best public document I know of for anyone designing tamper resistant
hardware and does a great job of covering the basics and also describes
measures to prevent these attacks, suggests using "two independent
cryptographic algorithm implementations whose output are continually
compared in order to ensure the correct functioning of the cryptographic
algorithm," etc.  In general, these attacks are fairly straightforward to
implement once the appropriate errors are available.


In addition to published sources, I've had many discussions with other
cryptographers error attacks and other hardware issues.  (Ross Anderson in
particular is extremely knowledgeable about hardware attacks and has done
much to raise awareness about them.  [See RISKS-18.52]) It's also important
to note that there are also quite a few other attacks which haven't been
published but which are widely known to the community.  (For example, I've
discussed widely my work on using timing attack math to analyze power
consumption, use of error analysis to reverse-engineer secret algorithms,
implementations of attacks using software pointer errors to damage secret
keys and encryption function tables, etc.)


With the timing attack I was alarmed by the amount of confusion and 
misinterpretation that followed my initial release of the paper (though I 
didn't send out any press releases or contact any reporters), even though 
it been reviewed by many cryptographers prior to its release and was 
available online.  I haven't seen the actual Bellcore paper yet and don't 
know whether it was reviewed before they sent press releases to the media, 
but in general I worry about the consequences of the public trying to 
evaluate the importance, novelty, and quality of unreviewed work. 


Paul Kocher  pck () cryptography com (or http://www.cryptography.com)