Crypto dongles to secure online transactions

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com