a possible scenario in the SDA (static data) was that the chip presented a digital certificate. the terminal verified the issuers digital signature on the digital certificate ... which was used to validate the card. Since the digital certificate represents "static" data, the digital certificate might be skimmed (possibly even using some of the same technology that skims magstripe static data) and installed in counterfeit ("yes card").
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked

the upgrade to dynamic data possibly has terminal doing some sort of random data challenge/response, which the card now has to digitally sign (using private key) ... which could be verified using some supplied digital certificate (carried over from SDA) ... and any random data challenge/response is countermeasure to replay attacks (found in static data scenarios)

however, as looked at in some of the x9.59 work
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

in any card authentication (leaving the transaction naked, as opposed to transaction authentication), there still might be various kinds of MITM-attacks ... possibly similar to the "yes card" (replay attack) scenarios ... possibly using a pair of cards ... aka a "yes card" MITM-attack scenario
http://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked

French Banks Upgrade Security Of EMV Cards
http://www.cardtechnology.com/article.html?id=2006070569TSQ1WX

from above:

The card organization says its tests earlier this year show the extra time it takes for cards to create the unique signatures is "imperceptible" to cardholders. At the same time, CB says, the more-powerful smart card chips needed to generate the signatures have come down in price, so that DDA cards cost about the same as the less-secure cards in France.

... snip ...

This was something that we were looking at in '98 for the AADS chip strawman
http://www.garlic.com/~lynn/x959.html#aads

being able to have a chip be able to do a signature within the transit, contactless timing and power requirements ... be more secure than any DDA card and cost less than any SDA card ... somewhat referred to in this recent post
http://www.garlic.com/~lynn/aadsm24.htm#23 Use of TPM chip for RNG?

a few past references to aads chip strawman and being able to meet both powering and timing requirements in a transit contactless operation
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked

Are you saying they are using public key / asymmetric? This bit made me think they were using symmetric / hybrid:

"The card organization says its tests earlier this year show the extra time it takes for cards to create the unique signatures is "imperceptible" to cardholders. At the same time, CB says, the more-powerful smart card chips needed to generate the signatures have come down in price, so that DDA cards cost about the same as the less-secure cards in France."

I'd be surprised if you can do an "imperceptible" public key signature on a smart card???

when we were were looking at the issues in 98 for the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

... we were looking at ec/dsa in the 100-200 millisecond range with power requirements that allowed contactless operation.

possibly more about aads chip strawman than you really want to know ... but lot of it was based on having spent a couple decades working with on various hardware and/or sysetm issues. for distraction, all sort of collected posts on hardware and system subjects dating back four decades.
http://www.garlic.com/~lynn/subtopic.html

so at that time we are talking about 8in wafers in .6micron technology ... which was extremely borderline meeting the objectives ... however things were right in the transition to 12in/300mm wafers and .2micron technology.

so from cost standpoint ... manufactoring is basically per "wafer" .... and the per chip costs then become the number of chips per wafer. this has been a major justification for moving from 8in wafers to 12in/300mm wafers (larger number of chips per wafer) and even plans for moving to 400mm wafers.

while ec/dsa was enormously more economical in power and time than other digital signature technologies ... it had a prerequisite for reliable random number generator ... which some of the other digital signature technologies didn't have. most of the chips from the period had extremely poor random number generation capability ... so a big challenge for aads chip strawman was getting chip technology with acceptable random number generation. recent post on the subject.
http://www.garlic.com/~lynn/aadsm24.htm#23 Use of TPM chip for RNG?

So a big part of poor performance with some of the other digital signature technologies is using really big numbers (vis-a-vis ec/dsa) ... being stuck with 16bit math operations mean that you have to iterate a large number of times to approximate operations using really, really large numbers.

So part of the historical approach to somewhat reducing the time (for this other digital signature algorithms) is to implement really large number operations directly in circuits ... which can enormously increase the chip size (reducing the chips per wafer and therefor increasing the cost per chip) ... and also powering all those circuits simultaneously can drastically increase the power requirements. You get a modest decrease in elapsed time with significant increase in both chip size and power requirements (now talking about elapsed times in a couple second range ... less time or on the order of the time it takes to enter a PIN; you could even play games overlapping the two).

So the aads chip strawman hunt was for a really good random number generation technology ... and eliminate everything possible from the chip that wasn't absolutely necessary ... reducing the chip size by possibly 6-10 times (or even more) compared to some other chips ; which in turn can increase the number of chips per wafer by 6-10 times (and cut the per chip cost by 6-10 times). The much smaller chip and the economical ec/dsa implementation cut both the elapsed time and the power requirements (enabling being able to operate on power available in contactless operation).

There was a bunch of other things that contributed to cost reduction and economy for AADS chip strawman operation.

We move forward a little. Taking the same chip and reducing from .6micron to .2micron results in reducing the chip area by 4/36 or nine times (with corresponding increase of nine times in number of chips per wafer); as well as reducing overall power requirement. Increasing the wafer size from 8in to 12in ... increases the area by 144/64 or 2.25, which can translate in increasing the chips per wafer by 2.25. The combination of the two results in approx. 20 times more chips per wafer (and approx 20 times reduction in the manufactoring cost per chip).

The problem for aads chip strawman with the next reduction in technology below .2micron was that the saw cut (slicing and dicing the wafers into individual chips) was starting to be as big as the chip (aads chip strawman had extreme feature/function reduction as part of cutting power and also surface/size of the chip). This met that possibly only something like 1/4th of a wafer surface actually resulted in aads strawman chips.

What has happened is that some new fabrication technology for RFID chips (many that are even smaller than AADS chip strawman) has been developed ... in order to avoid loosing majority of wafer surface to saw cut. RFID chips aren't a whole lot smaller than AADS chip strawman ... but they are looking at getting the chip yield to the point where they are in the five cent (or less) per chip range.

The other contributing costs for chip-card deployment is the per chip/card post manufactoring handling ... stuff like personalization, mailing, etc. A lot of this may be the same for mailing a magstipe or a chip-card. However, other stuff may result in creating a large complex infrastructure ... if personalization can vary what has been loaded into chips ... then administrative operations have to be in place for remembering and dealing with each individual chip personalization.

note: minor, misc. word smith clean up of previous post here
http://www.garlic.com/~lynn/aadsm24.htm#28

more detail than you probably want to know ... but several vendors have started offering 1100bit multiplier for 1024 bit RSA. this is a big power hungry chip and are now in couple second range.

note if DDA is just doing challenge/response card authentication there still may be a vulnerability (as mentioned) involving "yes card" MITM-attack (possibly using a pair of cards, one perfectly valid, and one counterfeit).

> but several vendors have started offering 1100bit multiplier for 1024 bit RSA. this is a big power hungry chip and are now in couple second range.

Right, that's what I was thinking. When I was doing this in around 98 or so, the talk was of 3-6 seconds for a complete protocol with about 6 steps, using symmetric encryption. At the time, public key was considered unavailable, although vendors were promising...

(I should say I was working with a group that did it. I didn't do anything in that area, other than point out the flaws in basic assumptions, which amount to "you should implement online / signed tx because by the time you get there, it will all be online.")

So 2 seconds for a PK operation now would be about right. Still, too long, I suspect. It makes sense to look at EC/DSA, if you can get it down that far, and if you can escape the patent trap (I haven't kept up with it at all).

Was there anything difficult about doing the RNG to quality? Or was it just a matter of doing the shot/thermal circuits and being careful? As per recent discussions?

quick use of search engine turns up

http://www.iaik.tugraz.at/teaching/00_angewandte%20kryptografie/slides/PaymentSystemsSecurity.pdf

which has the following overview:

Pay Later: EMV

* Magstripe with PIN (on-line) or manual signature (off-line)

* Smart card with DES and RSA certificate

- off-line PIN verification
- off-line card verification above threshold (risk management)

* Smart card with RSA (dynamic)

- needs PKI (card scheme-issuer-card)
- off-line verfication in terminal
- on-line for high risk

... snip ...

In the "yes card" scenarios, once the terminal has verified the card, then the terminal/card protocol has the terminal asking the card a) if the entered PIN was correct, b) if the transaction should be offline, and c) if the transaction is within the account credit limit.

another reference found

Cryptography and the French Banking Cards: Past, Present, Future
http://www.di.ens.fr/~stern/data/St111.pdf

... and here is really old reference (96) about doing (RSA) key-gen for card issuing
http://www.interesting-people.org/archives/interesting-people/199610/msg00044.html

because of a combination of long time for key-gen and lack of reasonable random number generator, this was comingly done as part of personalization with an external key-gen facility and the keys injected into the chip.

by contrast for aads chip strawman,
http://www.garlic.com/~lynn/x959.html#aads

and
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#28 DDA cards may address the UK Chip&Pin woes

the ec keygen (as well as ec/dsa) was manufactored into the chip. the actual ec keygen was done as part of initial power/on test sequence (before the wafer was even sliced and diced) and the public keys exported as port of the test verification data.

the typical external keygen and injection adds additional steps, processing, and costs for the typical chip.

in the aads chip strawman, the keygen as part of standard initial power-on/test sequence (validating a "good" chip) increasing test coverage w/o increasing elapsed test time (and in fact, the increased test coverage could have actually been used to decrease the initial power-on/test sequence elapsed time).

doing the initial power-on/test while still in the wafer ... makes it possible for a test jig to do a large number chips simultaneously ... and then mark chips that fail (marked chips typically are destroyed when the wafer is sliced and diced later).

as implied in previous post in this thread ... part of this was having spent a couple decades in a product house ... where it was common to spend a lot of time on manufactoring science and technology ... higly optimizing the product manufactoring process to maximize operation/efficiency as well as minimizing costs.

Asymmetric key generation is a big problem in my project (mobile secure messaging), too. Generating a DSS key is substantially faster than RSA; it is just on exponentiation.

As for the authentication itself, it depends on how it is done, but discrete log based schemes tend to have an advantage, too.

The fastest version of RSA is the so-called multi-prime RSA (described in detail in the newest version of PKCS#1), which seems to be patented by Compaq (but this patent is probably impossible to enforce), whereby the modulus is the product of several primes. E.g. a 1024 bit key would be the product of 4 256-bit primes. It speeds up the private decryption and signature operations. The decryption speed-up is most significant, when the encrypted message is shorter than either prime factor of the modulus; then you can do the following for decryption:
Precalculated: take one prime factor (say p), calculate the modular inverse d of the public exponent (e) modulo (p-1).
Decryption: calculate the remainder of the encrypted message modulo p, raise the result to the dth power modulo p.
One can win a few cycles by picking p such that d has least 1 bits in it.

The auth session can be as follows: the verifier encrypts a secret with the card's public key and sends the encrypted message. The card then returns the transaction protected by a MAC keyed with the secret.

However, even this is slower than DSS done properly (with pre-calculated random powers).

http://feeds.feedburner.com/PaymentsNews?m=3864

http://www.zdnet.com.au/news/hardware/soa/MasterCard_dispels_RFID_payment_security_fears/0,2000061702,39261775,00.htm

Steven Deare reports for ZDNet Australia about comments made by MasterCard consultant Robert White at a smartcard conference in Sydney earlier this week regarding MasterCard's PayPass contactless card technology saying "In actual fact, the security is in the application. We don't rely on channel security, we don't rely on protocol security to secure a payment that's in the application."

PaymentNews wrote:
> Steven Deare reports for ZDNet Australia about
> comments made by MasterCard consultant Robert
> White at a smartcard conference in Sydney
> earlier this week regarding MasterCard's
> PayPass contactless card technology saying
> "In actual fact, the security is in the
> application. We don't rely on channel
> security, we don't rely on protocol security
> to secure a payment that's in the application."

this might also be considered somewhat from the stand point of the x9.59 financial standard protocol. in the same time frame as the chip&pin specification was being published, most of the x9.59 financial standard had finished coalescing. the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

the aads chips strawman (from '98) was then to identify the technology components that would provide the highest possible security at the lowest possible deployed cost
http://www.garlic.com/~lynn/x959.html#aads

while most of the other protocols and specifications being done in the 90s only considered a very small part of the total threat model, x9.59 looked at providing end-to-end coverage ... something that has been discussed recently in the naked transaction threads. for x9.59 transactions "in-flight" (i.e. like on the internet), they could be done "in the clear", w/o affecting the integrity of the financial infrastructure. for x9.59 transactions "at-rest" (i.e. in various databases or transaction logs), there could be all sort of security and data breaches w/o affecting the integrity of the financial infrastructure.

the "yes card" is an attack on the terminal and infrastructure business rules (not a card attack). once the card has been authenticated, the terminal/card protocol has the terminal asking the card: a) was the entered PIN correct, b) should the transaction be done offline, and c) is the transaction within the account limit. old "yes card" article from 2002 about earlier "yes card" attacks (and mentioning details for building "yes card" was readily available on the internet)
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

a "yes card", "replay attack" has card static authentication data (possibly even using similar technology used for magnetic strip static data) being skimmed and loaded into a counterfeit "yes card". a possible "yes card", "MITM-attack" has a fraudulent "yes card" paired with a valid card, where the "yes card" passes the authentication to some valid card, and then handles all subsequent interactions. misc. MITM-attack postings
http://www.garlic.com/~lynn/subpubkey.html#mitm

misc. recent postings related to "naked transaction" thread
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#6 Securely handling credit card transactions earns Blackboard kudos
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
http://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt

security taxonomy footnote ... as an aside, i recently updated our merged security taxonomy and glossary
http://www.garlic.com/~lynn/index.html#glosnote

with terms from NIST IR 7298.

re:
http://www.garlic.com/~lynn/aadsm24.htm#30

In any case, the taxonomy is sort of end-point authentication or transaction authentication (is each individual operation authenticated). This is sort of the them of the earlier naked-transactions threads.

The "yes card" attacks on the terminals & infrastructure business rules ... is based on end-point authentication.

In the "yes card" "replay attacks" ... it is based on the end-point using static data authentication, being able to skim that data and "replay" the information. This has been the compromised and/or counterfeit terminal skimming magstripe data that has been going on for a couple decades.

In any "yes card" "mitm-attacks" (say a "yes card" paired with a valid card) ... it is based on having a valid end-point doing the authentication, but the man-in-the-middle then taking over and doing all the subsequent operations/transactions.

As mentioned in the naked transaction threads ... doing any end-point authentication ... and not transaction authentication ... then the actual transaction may have various vulnerabilities for the rest of its life-time.

some transactions may be very short lived ... like the questions the terminal asks the card (the things that a "yes card" replies "yes" to ... like whether the PIN is correct).

and as mentioned in the naked transaction threads, the x9.59 transaction standard work from the mid-90s considered numerous of the trade-offs of end-point vis-a-vis transaction authentication.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

during that period, it appeared that much of the world was extremely enamored with PKIs and digital certificates. Those attempts at doing payment transaction authentication which included digital certificates resulted in payload bloats of one hundred times (i.e. PKI infrastructure overhead would increase payment transaction payload by 100 times). as a result, the PKI afflected parties appeared to think that they had to drop back to end-point authentication (to mitigate horrible transaction payload bloat) ... as opposed to coming up with the concept of dropping the digital certificate as redundant and superfluous.

another recent mention of going certificate free
http://www.garlic.com/~lynn/subpubkey.html#certless

I pointed out in the SSH whips https thread:
https://financialcryptography.com/mt/archives/000769.html

where there was recent mention of SSH publishing public keys in DNS
http://www.garlic.com/~lynn/aadsm24.htm#24

and noting that is very similar to my oft repeated comments about changing SSL to use public keys published in DNS (and doing away with the SSL server digital certificates).
http://www.garlic.com/~lynn/subpubkey.html#sslcert

... and more security/threat taxonomy footnote
http://www.garlic.com/~lynn/aadsm24.htm#31

looking at multi-factor authentication from multiple facets ... a boyd thing
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

there is the three factor authentication model
http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have
* something you know
* something you are

there is implicit assumption that the point of having different authentication factors is that they have independent vulnerabilities.

cards represent "something you have" authentication. pins represent "something you know" authentication. pins were an indepentent authentication as countermeasure to early 70s lost/stolen (static data, magstripe) cards (modulo the supposedly 30percent of the population that write their pin on their cards ... but it is becoming increasingly difficult to keep track of all the pins, passwords, etc, in ones life)

going into the late 70s and early 80s, you start seeing skimming attacks ... collecting static data at some transaction point. the issue with skimming vulnerability of static data was that they represented a common threat to both the static magstripe data and the static pin data (i.e. invalidating the basic premise behind having multi-factor authentication).

what you then see with the chip&pin deployments for nearly a decade is that the "yes card" "replay attacks" have been around for just about as long as the chip&pin deployments However, the twist in the skimming of chip&pin static data is that they weren't actually required to also skim the pin ... all that was needed was that the card static authentication data be skimmed (corresponding to the mastripe static data) and installed in a counterfeit "yes card".

once the terminal had "authenticated" a counterfeit "yes card", the terminal relied on the answers from the card: 1) was the pin correct, 2) is it an offline transaction, 3) is the transaction within the credit limit (the counterfeit card answering "yes" to all such questions gave rise to its "yes card" label)
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

a possible issue in card dynamic data authentication ... is that while it may be immune to skimming attacks ("yes card", "replay attacks"), there may still be a "yes card", "mitm-attack" vulnerability ...
http://www.garlic.com/~lynn/subpubkey.html#mitm

i.e. pairing a "yes card" with some valid card, where the "yes card" passes the authentication operation thru to the valid card ... and then handles all the rest of the operations.

this is small part of the issue raised in the various naked transation threads
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#6 Securely handling credit card transactions earns Blackboard kudos
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
http://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt

the issue for the x9a10 financial standards working group was that in the mid-90s, it was given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... resulting in the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

rather than attempting to just address the threats and vulnerabilities from the 60s and 70s ... it attempted to address the 2000 and going forward vulnerabilities.

Card meters hit by scam
http://www.autoexpress.co.uk/news/autoexpressnews/200805/card_meters_hit_by_scam.html

from above:

A spokesman admitted the hi-tech meters could be open to a type of con called “skimming”, where crooks fit a special reader over the card slot to copy users’ bank details. This scam has already forced oil giant Shell to remove 600 chip and pin card readers which it had installed in its UK petrol stations.

... snip ...

past posts:
http://www.garlic.com/~lynn/aadsm23.htm#17 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#26 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm23.htm#32 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm24.htm#3 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
http://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked

re:
https://financialcryptography.com/mt/archives/000776.html

this references a couple of DDA articles
http://www.garlic.com/~lynn/aadsm24.htm#41

which imply that chip&pinthe card is authenticated separately from the transaction process ... leaving open the possibility of "yes card", "mitm-attacks".

while one of the referenced DDA articles state that transactions could be authorized at the terminal (as mentioned in previous posts about possible "yes card", "mitm-attacks") another one of the referenced DDA articles states: "the DDA technology would give the optimum results only if the transactions were done online".

the original "yes card" attacks were against terminal infrastructure that relied on business rules in an "authenticated" card to decide whether to do online or (local terminal) offline transaction authorization. forcing online transactions imply that terminals are changed to limit the ability of authenticated cards to dictate regarding online vis-a-vis offline (which somewhat mitigates the vulnerability of "yes card", "mitm-attacks")

misc. past posts mentioning possible "yes card", "mitm-attacks":
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes

recent update related to previous comments on AADS chip strawman in this thread:
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defined chip IP: snake oil or good idea?

previous posts in this thread mentioning aads chip strawman:
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#28 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#29 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes

Hackers clone e-passports
http://www.wired.com/news/technology/0,71521-0.html

sounds somewhat akin to the "yes card" clones of sda chip&pin that started to show up in the 90s.
http://www.garlic.com/~lynn/aadsm24.htm#32
http://www.garlic.com/~lynn/aadsm24.htm#43

somewhere in a study for aads chip strawman in the early 99 time-frame ... there was test about doing ecdsa signature in well under a second using contractless chip (drawing power from the air) ... and work on a custom circuit design that would do it under .1 second drawing much less power

slightly related set of posts
http://www.garlic.com/~lynn/aadsm24.htm#51 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/aadsm25.htm#2 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#6 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#10 Crypto to defend chip IP: snake oil or good idea?

and for other topic drift;

New PCI DSS is out
http://www.emergentchaos.com/archives/2006/09/new_pci_dss_is_out.html
Credit Card Giants Modify Security Specs
http://www.darkreading.com/document.asp?doc_id=103292

** one more time, can you say security proportional to risk?
http://www.garlic.com/~lynn/2001h.html#61

Credit card companies forge security alliance
http://www.tgdaily.com/2006/09/08/credit_card_security/
Credit card companies forge security alliance
http://www.silicon.com/financialservices/0,3800010322,39162214,00.htm
Credit Card Brokers Launch Security Effort
http://www.extremetech.com/article2/0,1697,2013829,00.asp

Laptop Larceny, First Possible Case of Fraud
http://www.firstcoastnews.com/news/local/news-article.aspx?storyid=64422
Second Life Database Suffers Huge Security Breach
http://www.playfeed.com/index.php/playfeed/article/second-life-database-suffers-huge-security-breach-09081814/
Theft of 900 bank customer files prompts e-privacy primer
http://www.cbc.ca/story/news/national/2006/09/08/laptop-privacy.html
At a Loss Over Data Loss
http://www.spot-on.com/archives/spinney/2006/09/at_a_loss_over_data_loss.html

** can we bury the planet under miles of cryptography?
http://www.garlic.com/~lynn/2006k.html#17
http://www.garlic.com/~lynn/2006k.html#18

Ponemon Institute Study Shows Lack of Accountability, Resources at Root of U.S. Corporate Data Loss Problem
http://www.portauthoritytech.com/news/releases/pr_082806_ponemon.html
Privacy Trust Studies
http://www.ponemon.org/privacytrust.html
Information Security Policy
http://www.ponemon.org/policy.html
Statement From Scott & Scott LLP In Response to Ponemon Institute's Data Breach Prevention Findings
http://biz.yahoo.com/bw/060908/20060908005296.html?.v=1
Rising Security Threats Require Tougher Notification Laws, But At What Price?
http://www.processor.com/editorial/article.asp?article=articles%2Fp2836%2F30p36%2F30p36.asp&guid=&searchtype=&WordList=&bJumpTo=True