On 11/21/2009 04:56 PM, John Levine wrote:
we claimed we do something like two orders magnitude reduction in
fully-loaded costs by going to no personalization (and other things)
...
My concern with that would be that if everyone uses the the same
signature scheme and token, the security of the entire industry
becomes dependent on the least competent bank in the country not
leaking the verification secret.
For something like a chip+pin system it is my understanding that the
signature algorithm is in the chip and different chips can use
different secrets and different algorithms, so a breach at one bank
need not compromise all the others.
R's,
John
there is no shared secret ... there is unique chip private/public key generated at power-on/test
and the public key was included/transmitted with the test result data as part of the initial power-on/test
cycle (this is process that occurs while the chips are still in wafer ... before
being sliced & diced).
the silicon is designed to never (volunteerly) divulge the private key (modulo
some extremely heavy duty physical attacks).
the patent stuff was all done for employer as assigned patents quite awhile ago
(we've been gone for several yrs and the patent stuff keeps going on).
initially there was a large number of claims and had gotten to packaged as over
60 patents and looked to be 100 before we were done. about that point, the
employer looks at filing costs in the US and international ... and directs that
all the claims be packaged as nine patents. Later, the patent office comes back
and makes some comment about getting tired of huge patents where the filing fee
doesn't even cover the cost of reading all the claims ... and directed that the
claims be packaged as larger number of claims.
http://www.garlic.com/~lynn/aadssummary.htm
while there are claims related to unique devices with unique digital signatures
in other applications ... there was a patent application (in our name ... years
after we are gone) this year
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220090158029%22.PGNR.&OS=DN/20090158029&RS=DN/20090158029
all the initial chips were ec/dsa (each chip with its own unique public/private
key) ... all done in fab that had security certified by US, EU & other gov.
institutions and also financial institutions (no compromised chips substituted for
real ones) ... I even got to walk the fab in bunny suit doing my own certification.
if you want different algorithms (or key lengths) ... you have to cut a new
mask and make different wafer runs. if the number of wafers in wafer runs are
too small ... you would start to drive the cost/chip above a few cents. There
is no single-point-of-compromise. Compromising a single chip is equivalent to
skimming a single magstripe ... can do fraudulent transactions against the
accounts for that chip/token (and chip compromise significantly more difficult
than magstripe skimming).
In theory there might be weakness found in specific chip or specific algorithm
... but design allows for a large number of different chips and algorithms to
interoperate in the same environment. For the initial chips ... I got a EAL4+
common criteria certification (by accredited lab in germany). I wanted a higher
certification ... but had a problem that EC/DSA verification suite had been
withdrawn. There were some higher certifications on similar chips by others
...but their design involved loading the crypto after the certification (they
got certification done on chip before any software loaded). My chip had
everything in silicon (all feature/functions) ... and so the certification was
done on everything that would be in actual use.
in the "person-centric" scenario ... each chip's private key becomes somewhat akin to fingerprint
or iris pattern ... a unique "something you have" ... as opposed to unique "something you
are" (and much easier to replace/change if there is a specific compromise).
some of the patents cover not only recording public key for each account the
corresponding token is authorized for (and multiple different tokens might be
authorized for same account) ... but also knowledge about the assurance level
of the related chip. Real-time updates are then available about chip assurance
level ... and real-time authorizations can not only take into account whether
the transaction is within the account balance ... but potentially is the
assurance level of the chip is high enough for authorizing the transaction.
X9.59 financial standard transaction protocol also allows for the environment
that the transaction is performed in to also sign the transaction (in addition
to the person's chip). Real-time authorization then may take into account both
the assurance level (potentially updated in real-time) of the user's chips as
well as the assurance level of the transaction environment (in determining if
there is sufficient assurance for the transaction in question). Some of the
people responsible for the V3 extensions for X.509 overlooked the issue of
assurance characteristics ... when they were originally defining the V3
extensions (of course the whole x.509 is based on static information ... and
disappears in a real-time environment).
there are different issues with other chip implementations. there was rather large pilot deployment
of such a chip in the US for point-of-sale early part of this decade ... it had a "yes
card" problem ... the last paragraph of this cartes 2002 trip report ... includes mention of
presentation on it being trivial to make a counterfeit "yes card" (chip)
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
... in any case, all evidence of that pilot appeared to subsequently evaporate (we had considered/documented
such problem several yrs earlier). Current status in the US is possibly somewhat consequence of that
("yes card") pilot (a presentation at the time ... noted that "yes card" vulnerability
actually made fraud worse than exists with magstripe; somebody in the audience asking how billions of dollars
could be spent to prove that chips are less secure than magstripe) ... not so much the cost of a single
deployment ... but there might turn out to be the cost of several deployments. misc. past posts mentioning
the "yes card"
http://www.garlic.com/~lynn/subintegrity.html#yescard
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
