A mighty fortress is our PKI, Part II

[Anne & Lynn Wheeler]

On 07/28/2010 11:52 PM, Pat Farrell wrote:
> A lot of the smart card development in the mid-90s and beyond was based
> on the idea that the smart card, in itself, was the sole authorization
> token/algorithm/implementation.

some ssl, payment, smartcard trivia ...

those smartcards were used for the offline authorization (not just authentication) ... which, in at least one major product, led to the "YES CARD" ... relatively trivial to skim & replicated a static digital certificate for a counterfeit card ... then the counterfeit card was programmed to answer "YES" to 1) was the correct PIN entered, 2) should the transaction be performed offline, and 3) was the transaction approved. Once the static digital certificate was skimmed, it was no longer even necessary to know the PIN, since the counterfeit card accepted every possible PIN as valid. misc. past posts mentioning "YES CARD"
http://www.garlic.com/~lynn/subintegrity.html#yescard

In a 2003, at an ATM Integrity task force meeting ... there was presentation by some LEO explaining the "yes card" ... and how there was little or no countermeasure once a "YES CARD" was in existence ... somebody in the audience loudly observed that billions were spent on proving smartcards are less secure than magstripe. In the "YES CARD" timeframe there was even a rather large pilot of the cards in the US ... but seemed to disappear after the "YES CARD" scenario was publicized (it was actually explained to the people doing the pilot, before the pilot started ... but apparently they didn't appreciate the significance).

much earlier, we had been working on our ha/cmp product and cluster scaleup. we had meeting on cluster scaleup meeting during jan92 sanfran usenet (in ellison's conference room) ... past posts mentioning the jan92 meeting
http:www/garlic.com/~lynn/95.html#13

this was just a few weeks before cluster scaleup was transferred (announced as supercomputer for numerical intensive only) and we were told we couldn't work on anything with more than four processors. some old email from the period on cluster scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa

we then leave a couple months later. two of the other people named in the jan92 meeting also leave and show up at small client/server startup responsible for something called "commerce server". we get brought in to consult because they want to do payment transactions on the server ... the small client/server startup has also invented some technology called "SSL" they want to use. The results is now frequently called "electronic commerce".

Then apparently because of the work on electronic commerce ... we also get invited to participate in the x9a10 financial standard working group ... which had been given the requirement to preserve the integrity of the financial infrastructure  for all retail payments.

About the same time there is a pilot program for magstripe-based online stored-value cards  (uses existing POS magstripe terminals but the payment network routes the transactions to different backend processor, original program of its kind in the US). At the time, the US didn't have the telco connectivity availability and cost issues that many places in the rest of the world were dealing with ... and therefor didn't have that requirement to move to offline smartcard payment paradigm. However, it turns out their backend, high-availability, no-single-point-of-failure platform developed a glitch ... and even tho it was from a different vendor (than our ha/cmp product) we were asked to investigate at the various failure modes.

Somewhat as a result of all of the above, when one of the major offline, smartcard, european, stored-value payment operators was looking at making an entry into the US in the 90s ... we were asked to design, size, and cost their backend dataprocessing infrastructure. Along the way, we took an indepth look at the business process and cost structure of such payment products. Turns out that the major financial motivation for that generation of smartcard stored-value payment products ... was that the operators got to keep the float on the value resident in the stored-value cards. Not too long later ... several of the major european central banks announced that the smartcard, stored-value operators would have to start paying interest on value in the smartcards (eliminating the float financial incentive to those operators). It wasn't too long after that most of the programs disappeared.

The major difference between that generation of smartcard payment products and the AADS chip strawman ... was that rather than attempting to be a complex, loadable, multi-function issuer card .... the objective was changed to being a person-centric, highest-possible integrity, lowest-possible cost, hard-to-counterfeit authentication ... which could be registered (publickey) for arbitrary number of different environments ("something you have" authentication registered in manner analogous to how "something you are" biometric might be registered).

-- 
virtualization experience starting Jan1968, online at home since Mar1970

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com