Thor Lancelot Simon wrote:
I don't get it. How is there "no increase in vulnerability and threat"
if a manufacturer of counterfeit / copy chips can simply read the already
generated private key out of a legitimate chip (because it's not protected
by a tamperproof module, and the "significant post-fab security handling"
has been eliminated) and make as many chips with that private key as he
may care to?
Why should I believe it's any harder to steal the private key than to
steal a "static serial number"?
there is no increased vulnerability and threat to existing situation
where attacker can copy the serial number as it is being read out by
normal functions. its static data ... along the lines of symmetric
password ... where the same information that is used to establish the
authentication is also used to validate the authentication.
the private key scenario doesn't export the private key as part of any
normal function ... it is generated within the added circuit core, not
available to processing outside of the added circuit core, and the only
thing that is normally exposed/exported outside the normal added circuit
core is the public key and digital signatures.
so the added circuit core is incremental cost for the chip real estate
for the incremental 20k-40k circuit core. the rest of the associated fab
and post-fab processing can be reduced to effectively zero ... changing
the paradigm from a serial number, pin, password symmetrical based
authentication to an asymmetrical based authentication (for essentially
no incremental cost).
so an attacker to retrieve the private key ... can't do it by trivial
evesdropping or readily available processor functions ... instead the
attacker has to resort to physical invasive techniques on the chip to
obtain the private key. right away that eliminates all the distance,
electronic attacks ... reducing the attacks that require physical
possession of the object.
so now the issue is countermeasure to physical invasive attacks
requiring physical possession of each chip. so in some of the scenarios
... one sufficient is to have sufficient physical invasive
countermeasures that the physical attack will take longer than the
nominal interval to report physical lost/stolen (invalidating the use of
the physical object).
another scenario from parameterized risk management ... is to make the
physical attack more expensive than the associated expected fraudulent
benefit to the attacker.
the issue is since the serial number is static (and requires symmetrical
authentication ... same value is used for both establishing
authentication and verifying authentication) ... and
symmetric authentication mechanisms are vulnerable to a large number of
attacks other than physical invasive attack on the physical chip
(the argument is nearly identical to the justification of using digital
signature authentication in lieu of static data pin/password
authentication which is subject to all sorts of evesdropping and replay
attacks) ... like peeling physical layers of the chip and using scanning
electron microscope .... i actually spent some time working at the los
gatos vlsi lab (bldg. 29) which claims to have pioneered use of scanning
electron microscope for chip analysis ... not for chip attacks ... but
as part of debugging initial chips.
so a physical vulnerability issue for something fips140-2 is whether
there is constant power and countermeasure to physical invasive attack
can trigger zeroization. there is cost and vulnerability trade-off
regarding not having constant power and can have a physical attack w/o
zeroization countermeasure. that is something that shows up as part of
parameterized risk management.
this is also somewhat related to the security proportional to risk topic
... one such discussion:
http://www.garlic.com/~lynn/2001h.html#61
past posts involving this thread:
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#53 Case Study: Thunderbird's
brittle security as proof of Iang's 3rd Hypothesis in secure design:
there is only one mode, and it's secure
http://www.garlic.com/~lynn/aadsm25.htm#0 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/2006n.html#57 The very first text editor
past posts discussing parameterized risk management issues:
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo3 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and
electronic signatures
http://www.garlic.com/~lynn/aepay3.htm#x959risk1 Risk Management in AA /
draft X9.59
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech9 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was
Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION
:draft-ietf-pkix-scvp-00.txt))
http://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment
standard issue
http://www.garlic.com/~lynn/aadsm12.htm#17 Overcoming the potential
downside of TCPA
http://www.garlic.com/~lynn/aadsm19.htm#15 Loss Expectancy in NPV
calculations
http://www.garlic.com/~lynn/aadsm19.htm#44 massive data theft at
MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#46 the limits of crypto and
authentication
http://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for
smartcards?
http://www.garlic.com/~lynn/aadsm21.htm#8 simple (&secure??) PW-based
web login (was Re: Another entry in the internet security hall of shame....)
http://www.garlic.com/~lynn/aadsm23.htm#1 RSA Adaptive Authentication
http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were
replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP:
snake oil or good idea?
http://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
http://www.garlic.com/~lynn/2000.html#46 question about PKI...
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2005k.html#23 More on garbage
http://www.garlic.com/~lynn/2006g.html#40 Why are smart cards so dumb?
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
