[16399] in cryptography@c2.net mail archive
Re: "Scan design called portal for hackers"
daemon@ATHENA.MIT.EDU (david koontz)
Wed Nov 3 09:55:29 2004
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Wed, 03 Nov 2004 17:01:12 +1300
From: "david koontz" <david.koontz@alliedtelesyn.co.nz>
To: <dahonig@cox.net>, <pgut001@cs.auckland.ac.nz>,
<cryptography@metzdowd.com>
Cc: <cypherpunks@al-qaeda.com>
>>> 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 IC=
s
>>makes them vulnerable to attacks. =20
>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. Th=
is is
>why some security devices let you disconnect it using a security-fuse ty=
pe
>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=
=20isn't
>sufficiently motivated/funded to use something like microprobing or a FI=
B
>workstation to bypass the disconnect.
Historically BIST has been more attractive for crypto hardware because=20
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 in=
ternal=20
scan you could have a zeroize on entering test mode. This prevents scan=
=20chains
from being capable of being used to save as well as restore state. =20
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 secti=
on:
4.5.1 General Physical Security Requirements
=20...
SECURITY LEVEL 1
The following requirements shall apply to all cryptographic modules for=20
Security Level 1.
* The cryptographic module shall consist of production-grade components=20
that shall include standard passivation techniques (e.g., a conformal coa=
ting=20
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=20
shall be zeroized. Zeroization shall either be performed procedurally by =
the operator or automatically by the cryptographic module.
=20
---
Meaning for a cryptographic module boundary at the chip level, the
keys should have been zeroized before physical access.
----
=20...
SECURITY LEVEL 3
In addition to the general requirements for Security Levels 1 and 2, the
=20following requirements shall apply to all cryptographic modules for=20
Security Level 3.
* If the cryptographic module contains any doors or removable covers=20
or if a maintenance access interface is defined, then the module shall=20
contain tamper response and zeroization circuitry. The tamper response=20
and zeroization circuitry shall immediately zeroize all plaintext secret =
and=20
private keys and CSPs when a door is opened, a cover is removed, or=20
when the maintenance access interface is accessed. The tamper response=20
and zeroization circuitry shall remain operational when plaintext secret =
and=20
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=20
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
