...

...

Peter Gutmann <pgut001@cs.auckland.ac.nz> 2/11/2004 11:30:36 p.m. >>> David Honig <dahonig@cox.net> writes:

...

EETimes 25 Oct 04 has an article about how the testing structures on ICs makes them vulnerable to attacks.

A link ) would have been useful...

...

The basic idea is that to test a chip, you need to see inside it; this can also reveal crypto details (e.g., keys) which compromise the chip.

The JTAG interface is your (that is, the reverse engineer's) friend. This is why some security devices let you disconnect it using a security-fuse type mechanism before you ship your product. Of course that only works if (a) the device allows it, (b) you remember to activate it, and (c) your attacker isn't sufficiently motivated/funded to use something like microprobing or a FIB workstation to bypass the disconnect.

Historically BIST has been more attractive for crypto hardware because you can also use it for assurance testing prior to use. Invoking it can be hard coded into device initialization. If JTAG is present, you don't have to have internal scan. If you have internal scan you could have a zeroize on entering test mode. This prevents scan chains from being capable of being used to save as well as restore state. If and when is it a problem? If you were to examine FIPS PUB 140-2, 4.5 'Physical Security', 'Table 2 Summary of physical security requirements' and section: 4.5.1 General Physical Security Requirements ... SECURITY LEVEL 1 The following requirements shall apply to all cryptographic modules for Security Level 1. * The cryptographic module shall consist of production-grade components that shall include standard passivation techniques (e.g., a conformal coating or a sealing coat applied over the module's circuitry to protect against environmental or other physical damage). * When performing physical maintenance, all plaintext secret and private keys and other unprotected CSPs contained in the cryptographic module shall be zeroized. Zeroization shall either be performed procedurally by the operator or automatically by the cryptographic module. --- Meaning for a cryptographic module boundary at the chip level, the keys should have been zeroized before physical access. ---- ... SECURITY LEVEL 3 In addition to the general requirements for Security Levels 1 and 2, the following requirements shall apply to all cryptographic modules for Security Level 3. * If the cryptographic module contains any doors or removable covers or if a maintenance access interface is defined, then the module shall contain tamper response and zeroization circuitry. The tamper response and zeroization circuitry shall immediately zeroize all plaintext secret and private keys and CSPs when a door is opened, a cover is removed, or when the maintenance access interface is accessed. The tamper response and zeroization circuitry shall remain operational when plaintext secret and private cryptographic keys or CSPs are contained within the cryptographic module. --- Meaning that physical access will cause zeroization. This would imply zeroization on test mode activation on a JTAG interface on a single chip cryptographic module. You start getting real security at levels 3 and 4, the certification criteria comes from the Commercial COMSEC Evaluation Program (CCEP). Am I worried someone is producing chips that aren't protected? No. I'm more concerned that implementations (systems) aren't properly designed, tested and certified. "They got AES, we got AES" is just a form of snake oil. NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesyn Research Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesyn Research. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com