Misc AADS & X9.59 Discussions


AADS Postings and Posting Index,
next, previous, - home


FraudWatch - Chip&Pin, a new tenner (USD10)
UK Detects Chip-And-PIN Security Flaw
UK Banks Expected To Move To DDA EMV Cards
FraudWatch - Chip&Pin, a new tenner (USD10)
whole load of new RFCs announced yesterday on LDAP and SASL
New ISO standard aims to ensure the security of financial transactions on the Internet
Securely handling credit card transactions earns Blackboard kudos
Naked Payments IV - let's all go naked
Microsoft - will they bungle the security game?
Naked Payments IV - let's all go naked
Naked Payments IV - let's all go naked
FC++3 - Advances in Financial Cryptography, Number Three
Naked Payments IV - let's all go naked
On Leadership - negotiating the RTFM into the realm of forgotten schoolyard jokes
Naked Payments IV - let's all go naked
Apple to help Microsoft with "security neutrality"?
Apple to help Microsoft with "security neutrality"?
On Leadership - negotiating the RTFM into the realm of forgotten schoolyard jokes
On Leadership - tech teams and the RTFM factor
Use of TPM chip for RNG?
On Leadership - tech teams and the RTFM factor
Use of TPM chip for RNG?
Naked Payments IV - let's all go naked
Use of TPM chip for RNG?
It's official! SSH whips HTTPS butt! (in small minor test of no import....)
FraudWatch - Chip&Pin, a new tenner (USD10)
Naked Payments IV - let's all go naked
DDA cards may address the UK Chip&Pin woes
DDA cards may address the UK Chip&Pin woes
DDA cards may address the UK Chip&Pin woes
DDA cards may address the UK Chip&Pin woes
DDA cards may address the UK Chip&Pin woes
DDA cards may address the UK Chip&Pin woes
Threatwatch - 2-factor tokens attacked by phishers
Phishers Defeat 2-Factor Auth
Interesting bit of a quote
Interesting bit of a quote
DDA cards may address the UK Chip&Pin woes
Interesting bit of a quote
Interesting bit of a quote
Interesting bit of a quote
Naked Payments IV - let's all go naked
Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
DDA cards may address the UK Chip&Pin woes
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
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
More Brittle Security -- Agriculture
More Brittle Security -- Agriculture
more on FBI plans new Net-tapping push
Crypto to defend chip IP: snake oil or good idea?
DDA cards may address the UK Chip&Pin woes
Crypto to defend chip IP: snake oil or good idea?
Crypto to defend chip IP: snake oil or good idea?
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


FraudWatch - Chip&Pin, a new tenner (USD10)

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: June 7, 2006 02:52 PM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
Blog: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000673.html

news item yesterday implies that the UK chip&pin deployment corresponds to the yes card vulnerability described in 2002 about earlier chip&pin deployments.

UK Detects Chip-And-PIN SecurityFlaw
http://www.cardtechnology.com/article.html?id=20060606I2K75YSX

there was some amount of discussion about the chip&pin yes card vulnerability earlier in this thread.

a couple more recent comments
https://www.garlic.com/~lynn/2006l.html#32
https://www.garlic.com/~lynn/aadsm23.htm#55
https://www.garlic.com/~lynn/aadsm23.htm#56

UK Detects Chip-And-PIN Security Flaw

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: UK Detects Chip-And-PIN Security Flaw
Date: Thu, 08 Jun 2006 12:13:42 -0600
To: cryptography@xxxxxxxx
CC: jamesd@xxxxxxxx, fw@xxxxxxxx
Anne & Lynn Wheeler wrote:
for even more drift ... a news item from later yesterday

UK Detects Chip-And-PIN Security Flaw
http://www.cardtechnology.com/article.html?id=20060606I2K75YSX

APACS says the security lapse came to light in a recent study of the authentication technology used in the UK's new "chip-and-PIN" card system.

... snip ...

and some comment
https://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN Security Flaw

not too long after the exploit (from earlier deployments) being documented in 2002 ... it was explained to a group from the ATM industry ... leading somebody in the audience to quip do you mean that they managed to spend a couple billion dollars to prove that chips are less secure than magstripes.


......
the above from discussion on the subject in a different context
https://www.garlic.com/~lynn/2006l.html#33

the above reference goes into a little more detail of where the label yes card came for the counterfeit cards used in the "SDA" exploit.

as mentioned in earlier posting in this thread:
https://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw

part of the aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads

requirements in the 90s was to be able to do dynamic data authentication with higher security than the "DDA" chips (using the chip&pin terminology) with chip that cost less than the "SDA" chips (and also could meet the contactless transit power and timing profile requirements).

the x9a10 working group had already examined replay attack threat models (based on static data authentication) especially in light of the common skimming attacks that being used to harvest magstripes and PINs that were starting to become common at the time.

for little more drift, there are assumptions about multi-factor authentication being more secure (based on different factors being subject to independent threats) ... i.e. magstripes and PINs represent different factors. However, skimming attacks appearing by at least the mid-90s where capturing magstripes and PINs as part of the same operation (i.e. common threat, invalidating a basic multi-factor security assumption). PIN (something you know) is nominally considered countermeasure to lost/stolen magstripe (something you have). However, skimming can capture magstripe & PIN in same operation for production of counterfeit magstripe.

also previously mentioned, x9a10 was specifying transaction authentication as opposed to session-like authentication ... because transaction authentication reduced several kinds of vulnerabilities that were frequently related to session operation (end-point threats, mitm threats, insider threats).

there were a number of chip&pin "SDA" deployments in the 90s ... a partial reference here:
https://www.garlic.com/~lynn/2006l.html#33

... which had provided opportunities for the yes card type attacks to evolve. by the time of the 2002 article about yes cards ... the article also mentioned that information about building counterfeit yes cards was widely available on the internet.

however, the information about yes card kind of attacks (skimming "SDA" data for replay attacks against terminals) was relatively readily available by 2000. In late fall of 2000, there was a small conference in London with principles of the lloyd's of london syndicates involved in insuring (brick & mortar) point-of-sale retail payment fraud discussing numerous threat models and countermeasures.

however, a lot of chip&pin deployments have been by people that are extremely chip centric ... interpreting everything from the context of the produced chips. there were some chip&pin deployments in 2001 that interpreted the yes card vulnerability from the standpoint that valid cards could do offline transactions. their yes card countermeasure was to produce valid cards that always did online transactions.

Some of the chip&pin aficionados, when various of the yes card details were explained in more details ... tended to have trouble coming to grips with it being an attack on terminals and the rest of the infrastructure ... not attacks on valid chips ... and also thought that the crooks were not playing fair in how they programmed the counterfeit chips.

one of the references in the 2002 article was to yes cards never going away. this also was somewhat behind the cited comment from ATM industry in conference not too long after the 2002 article about proving chips are less secure than magstripe.

a cornerstone countermeasure to attacks on valid chips (like lost/stolen vulnerabilities) was infrastructure feature that when a card did an online transaction (as opposed to offline), the online infrastructure could instruct the card to self-destruct. the infrastructure allowed valid cards to instruct chip&pin terminals that they were doing offline transactions ... but valid cards were programmed to sporadically do online transactions. if a valid chip was reported as compromised (lost/stolen, etc), the account could be flagged (as happens with all magstripe transactions) and the chip also be scheduled for self-destruct command, the next time it went online.

since a counterfeit yes card could be programmed to never go online, flagging an account (as works with magstripe transactions) has no effect (which was part of what prompted the comment about proving that chips are less secure than magstripes, another part was that, in many cases, the same technology being used for skimming magstripes & pins would also skim "SDA" information). however, periodically some of the yes cards might be forced to go online ... but several of the chip-centric individuals were totally dismayed and felt it very unfair that crooks would go so far as to program the counterfeit yes cards to ignore the self-destruct commands.

in the 2001 chip&pin deployments with countermeasures to counterfeit yes cards, involving programming valid cards to always do online transactions, had no effect on yes card fraud. the yes card attack was (replay attack) on terminals (not an attack on valid cards). the countermeasure for counterfeit yes cards would have required the terminals to be programmed to always ignore instructions to do offline transactions ... forcing everything to online transactions ... so the operation would be subject to the same online account number flagging that has been used as countermeasure to magstripe fraud.

yes card posts:
https://www.garlic.com/~lynn/subintegrity.html#yescard

UK Banks Expected To Move To DDA EMV Cards

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: UK Banks Expected To Move To DDA EMV Cards
Date: Thu, 08 Jun 2006 13:21:00 -0600
To: cryptography@xxxxxxxx
CC: jamesd@xxxxxxxx,  fw@xxxxxxxx
UK Banks Expected To Move To DDA EMV Cards
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=11497625028614136145&block=

... from above ...

Of the 6.2 billion card transactions in the UK each year, one in five occurs offline, which increases the risk of cloned cards being used at a retailer's POS terminal. In short, a cloned credit or debit card may go unidentified if a transaction is not sent to a bank for approval.

... snip ...

re:
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw

note that the counterfeit yes card attack (from the late 90s) isn't on valid cards programmed to do offline (or online) transactions; the counterfeit yes card attack (built from skimmed "SDA" data) is on chip&pin terminals programmed to do what any authenticated card tells it to do (part of the chip&pin terminal standard):
https://www.garlic.com/~lynn/2006l.html#33

the countermeasure to counterfeit yes card attacks on chip&pin terminals is to program the terminal to ignore what the card tells it to do, and always do an online transcation. this makes chip&pin deployments subject to the same "account flagging" countermeasure that has been long used for magstripe cards. The counterfeit yes card exploit always doing offline transactions (making it immune to account flagging countermeasures) prompted somebody several years ago to make the comment about spending a couple billion dollars to prove that chips were less secure than magstripe

part of what had prompted the aads chip strawman effort
https://www.garlic.com/~lynn/x959.html#aads

in the 90s was the frequent comment about deployments were going to be forced into doing "SDA" chip deployments because technology cost for "DDA" chip deployments was going to be too uneconomical. Part of the aads chip strawman was to demonstrate technology doing dynamic data authentication (as countermeasure to skimming, harvesting and replay attacks) at the highest possible integrity ... for less cost than any "SDA" technology (as well as being able to meet transit contactless power and timing profile requirements).
https://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw

FraudWatch - Chip&Pin, a new tenner (USD10)

From: Lynn Wheeler lynn@xxxxxxxx
Date: June 9, 2006 12:18 AM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
Blog: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000673.html

some of the latest:

Millions at risk from chip and Pin
http://www.thisismoney.co.uk/saving-and-banking/article.html?in_article_id=409616&in_page_id=7
Millions in danger from chip and pin fraudsters
http://www.dailymail.co.uk/pages/live/articles/news/news.html?in_article_id=389084&in_page_id=1770&in_a_source=

and some comments
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards

whole load of new RFCs announced yesterday on LDAP and SASL

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: whole load of new RFCs announced yesterday on LDAP and SASL
Date: Fri, 09 Jun 2006 09:29:44 -0600
To: cryptography@xxxxxxxx
possibly fastest way of getting sense of all the new rfcs is to go to
https://www.garlic.com/~lynn/rfcietff.htm

and click on Date in the RFCs listed by section. Clicking on each individual RFC number (in the june section) will bring up that RFC summary in the lower frame. Clicking on the ".txt=nnnn" field will retrieve the actual RFC.

another approach is to click on Term (term->RFC#) in the RFCs listed by section and then click on either "LDAP" (or "SASL") in the Acronym fastpath.

New ISO standard aims to ensure the security of financial transactions on the Internet

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: New ISO standard aims to ensure the security of financial transactions on the Internet
Date: Fri, 09 Jun 2006 21:17:07 -0600
To: cryptography@xxxxxxxx
New ISO standard aims to ensure the security of financial transactions on the Internet
http://continuitycentral.com/news02582.htm

from above:

ISO 21188:2006, 'Public Key Infrastructure for financial services - practices and policy framework', offers a set of guidelines to assist risk managers, business managers and analysts, technical designers and implementers and operational management and auditors in the financial services industry.

... snip ...

my two bits ... in part, in light of recent pin&chip vulnerability thread

another metaphor for viewing the session authentication paradigm is that they tend to leave the actual transaction naked and vulnerable.

we had worked on the original payment gateway for what become to be called e-commerce
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

which we also assert can be considered the first SOA implementation
https://www.garlic.com/~lynn/2006l.html#38 Token-ring vs Ethernet - 10 years later

to some extent part of the transaction vulnerability analysis for x9.59 transactions in the mid-90s was based on analysis and experience with the original payment gateway implemented with session oriented paradigm.
https://www.garlic.com/~lynn/x959.html#x959

work on x9.59 in the mid-90s, did what very few other protocols did, defined end-to-end transaction strong authentication. many of the other protocols would leave the transaction naked and vulnerable at various steps in the processing.

session oriented protocols leaving the actual transaction naked and vulnerable (or the actual transaction not having complete end-to-end transaction strong authentication and therefor naked and vulnerable for at least some part of the processing) ... implies that the complete, whole end-to-end business process has to be heavily armored and secured. Minor chinks in the business armoring will expose the naked transaction to potentional attack and fraud.

if outsider attacks aren't enuf, naked transactions are also extremely vulnerable to insider attacks. nominally, transactions will be involved in a large number of different business processes ... exposing them to insider attacks at every step. end-to-end transaction strong authentication armors the actual transaction (avoiding leaving the transaction naked and vulnerable at vast array of processing steps). the naked transaction paradigm also contributes to the observation that something like seventy percent of fraud in such environments involve insiders.
https://www.garlic.com/~lynn/aadsm17.htm#38 Study: ID theft usually an inside job

end-to-end transaction strong authentication (armoring the actual transaction) then also alleviates the need for enormous amounts of total business process armoring, where absolutely no chinks in the armor can be allowed (which is necessary for protecting naked and vulnerable transactions ... which don't have end-to-end transaction strong authentication).

the x9a10 working group (for what become the x9.59 financial standard) had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. this met not only having countermeasures to things like replay attacks (static data that could be easily skimmed), but also having end-to-end transaction strong authentication (eliminating the vulnerabilities associated with having naked and vulnerable transactions at various points in the infrastructure).

part of the x9.59 financial standard for all retail payments in armoring and protecting transactions included the business rule that account numbers used in x9.59 transactions could not be used in transactions that didn't have end-to-end transaction strong authentication. this eliminated the problem with knowledge leakage of the account number representing a vulnerability (i.e. a naked account number was no longer vulnerable for use in fraudulent transactions).
https://www.garlic.com/~lynn/subpubkey.html#x959

part of the theme of the post on security proportional to risk is that if the individual transactions aren't armored then it can be extraordinarily expensive to provide absolutely perfect total infrastructure armoring to protect naked and vulnerable transactions
https://www.garlic.com/~lynn/2001h.html#61

part of the issue with some of the payment oriented protocols in the mid-90s looking at providing end-to-end strong authentication based on digital signature paradigm was the mistaken belief regarding appending digital certificates as part of the implementation. typical payment transaction is on the order of 60-80 bytes. the various payment protocols from the period with appended digital certificates had a payload bloat of 4k to 12k bytes (or a payload bloat of one hundred times). it was difficult to justify an enormous end-to-end payload bloat of one hundred times for a redundant and superfluous digital certificate, so the protocols tended to strip the digital certificate off, leaving the transaction naked and vulnerable during subsequent processing. of course this was before I had demonstrated that it was possible to compress appended digital certificates to zero bytes (opening the way for x9.59 transactions with end-to-end strong authentication based on digital signatures).

rather than viewing x9.59 as using certificate-less digital signatures for end-to-end transaction strong authentication
https://www.garlic.com/~lynn/subpubkey.html#certless
just consider that x9.59 as having appended compressed zero byte digital certificates to address the severe payload bloat problem

the issue of SDA (static data authentication vulnerable to replay attacks) or DDA (countermeasure to replay attacks) is somewhat independent of using a session oriented implementation (still leaving transactions naked and vulnerable at various points in the infrastructure):
https://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#0 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
https://www.garlic.com/~lynn/aadsm24.htm#3 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/2006l.html#27 Google Architecture
https://www.garlic.com/~lynn/2006l.html#32 Google Architecture
https://www.garlic.com/~lynn/2006l.html#33 Google Architecture
https://www.garlic.com/~lynn/2006l.html#37 Google Architecture

session hiding cryptography is not able to absolutely guarantee that naked, vulnerable transactions have 100% coverage and/or protected from all possible attacks and exploits (including insider attacks)
https://www.garlic.com/~lynn/aadsm15.htm#21 Simple SSL/TLS - Some Questions
https://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
https://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
https://www.garlic.com/~lynn/aadsm23.htm#54 Status of SRP
https://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
https://www.garlic.com/~lynn/2006h.html#15 Security
https://www.garlic.com/~lynn/2006h.html#26 Security
https://www.garlic.com/~lynn/2006k.html#5 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop

aads chip strawman from the 90s, stronger than other DDA technologies while cheaper and faster than any SDA technology
https://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
https://www.garlic.com/~lynn/aadsm2.htm#strawm2 AADS Strawman
https://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech9 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech10 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm9.htm#carnivore2 Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
https://www.garlic.com/~lynn/aadsm10.htm#keygen Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm10.htm#boyd AN AGILITY-BASED OODA MODEL FOR THE e-commerce/e-BUSINESS ENTERPRISE
https://www.garlic.com/~lynn/aadsm11.htm#1 Basic credit-card payment question
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#46 Giuliani: ID cards won't curb freedoms
https://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
https://www.garlic.com/~lynn/aadsm13.htm#18 A challenge
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
https://www.garlic.com/~lynn/aadsm16.htm#10 Difference between TCPA-Hardware and a smart card (was: example:secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm16.htm#12 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm17.htm#0 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)<
https://www.garlic.com/~lynn/aadsm19.htm#38 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#21 Qualified Certificate Request
https://www.garlic.com/~lynn/aadsm21.htm#11 Payment Tokens
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#41 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://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
https://www.garlic.com/~lynn/aadsm23.htm#53 Status of SRP
https://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
https://www.garlic.com/~lynn/99.html#170 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#189 Internet Credit Card Security
https://www.garlic.com/~lynn/2000c.html#2 Financial Stnadards Work group?
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#5 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001n.html#94 Secret Key Infrastructure plug compatible with PKI
https://www.garlic.com/~lynn/2002.html#39 Buffer overflow
https://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002g.html#38 Why is DSA so complicated?
https://www.garlic.com/~lynn/2002h.html#9 Biometric authentication for intranet websites?
https://www.garlic.com/~lynn/2002h.html#71 history of CMS
https://www.garlic.com/~lynn/2002h.html#84 history of CMS
https://www.garlic.com/~lynn/2002i.html#71 TCPA
https://www.garlic.com/~lynn/2002j.html#55 AADS, ECDSA, and even some TCPA
https://www.garlic.com/~lynn/2002j.html#71 history of CMS
https://www.garlic.com/~lynn/2002l.html#4 why is Kerberos better than this simpler replacement
https://www.garlic.com/~lynn/2002m.html#14 fingerprint authentication
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#18 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2003d.html#18 Efficent Digital Signature Schemes
https://www.garlic.com/~lynn/2003e.html#57 Security in RADIUS (RFC2865)
https://www.garlic.com/~lynn/2003g.html#70 Simple resource protection with public keys
https://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
https://www.garlic.com/~lynn/2003i.html#29 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003j.html#30 How is a smartcard created?
https://www.garlic.com/~lynn/2003l.html#61 Can you use ECC to produce digital signatures? It doesn't see
https://www.garlic.com/~lynn/2003l.html#64 Can you use ECC to produce digital signatures? It doesn't see
https://www.garlic.com/~lynn/2003m.html#5 Cryptoengines with usage accounting
https://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
https://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005q.html#11 Securing Private Key
https://www.garlic.com/~lynn/2005u.html#32 AMD to leave x86 behind?

Securely handling credit card transactions earns Blackboard kudos

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Securely handling credit card transactions earns Blackboard kudos
Date: Sat, 10 Jun 2006 11:36:24 -0600
To: cryptography@xxxxxxxx
Securely handling credit card transactions earns Blackboard kudos
http://www.contactlessnews.com/library/2006/06/08/securely-handling-credit-card-transactions-earns-blackboard-kudos/

... from above
"These programs utilize the Payment Card Industry (PCI) data security standard as the foundation to assess third-party processors," he added. "This standard ensures that all third-party processes safely and securely store, process, and transmit sensitive credit card data across their network infrastructures. This is the second year that Blackboard has achieved this milestone in the payment card industry."

... snip ...

couple other refs
http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html
https://sdp.mastercardintl.com/

this can also somewhat be considered from the standpoint of my old security proportional to risk posting
https://www.garlic.com/~lynn/2001h.html#61

however, it can also be interpreted that "sensitive credit card data" is represented by an infrastructure with naked and vulnerable transactions:
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet

i.e. that when dealing with naked and vulnerable transactions then the overall infrastructure requires extensive armoring (as countermeasure to attacks on naked transactions that otherwise don't have any of their own protection)

one might be tempted to draw an analogy with the bubble boy reference
http://www.imdb.com/title/tt0074236/
http://www.imdb.com/title/tt0258470/

about the countermeasures needed for a boy that was w/o his own immune system to combat attacks.

a big contributer to "sensitive data" is that just knowing/skimming/harvesting
https://www.garlic.com/~lynn/subintegrity.html#harvest

account numbers may enable fraudulent transactions.

the x9a10 financial standards working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. one of the aspects of the resulting x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

was a business rule that account numbers used in x9.59 end-to-end strongly authenticated transactions, were not valid in non-authenticated transactions. currently, simply stealing or knowing an account number can be sufficient to allow the crook to perform a fraudulent transaction. that doesn't work for account numbers used in x9.59 transactions

misc. past posts mentioning eliminating the sensitive data harvesting vulnerability for x9.59 account numbers
https://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
https://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#28 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
https://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
https://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#18 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm23.htm#54 Status of SRP
https://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
https://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card Protocol on Web Site
https://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004m.html#9 REVIEW: "Biometrics for Network Security", Paul Reid
https://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005m.html#53 Barcode Email
https://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
https://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
https://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!

Naked Payments IV - let's all go naked

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler lynn@xxxxxxxx
Date: June 12, 2006 05:41 PM
Subject: Naked Payments IV - let's all go naked
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000749.html
and
http://financialcryptography.com/mt/archives/000745.html
http://financialcryptography.com/mt/archives/000744.html
http://financialcryptography.com/mt/archives/000747.html

"naked transactions" and their vulnerabilities make up a major portion of the data breaches that have been in the news (orthogonal to lost/stolen card issue or individual related attacks) ... this is also much of the source of the studies that claim something like 70% of the fraud involves insiders.
https://www.garlic.com/~lynn/aadsm17.htm#38 Study: ID theft usually an inside job

as i've previously claimed, x9.59, originally worked on in the mid-90s, goes a long way to eliminating such naked transactions and related vulnerabilities
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

and the subsequent aads chip strawman work
https://www.garlic.com/~lynn/x959.html#aads

was for hardware that was more secure that the most expensive DDA technology, less expensive than the cheapest SDA technology, and could meet the transit industry contactless transaction requirements for elapsed time and power consumption.

just for the fun of it:

UK bank card security flaws warning
http://euronews.net/create_html.php?page=detail_eco&article=363719&lng=1

from the above:

Fraud victim Alex Harvey, said she no longer trusts the system: "I am horrified and I think that banks are no longer secure; and that chip and pin certainly doesn't make cards more secure, it makes customers have to accept liability."

... snip ...

in any case, as previously mentioned, this yes card scenario was described in 2002 and possibly first appeared in various chip&pin trials as early as 1999.

past posts mentioning the yes card vulnerability:
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
https://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
https://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
https://www.garlic.com/~lynn/aadsm18.htm#20 RPOW - Reusable Proofs of Work
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
https://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
https://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
https://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#0 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
https://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
https://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#35 A quote from Crypto-Gram
https://www.garlic.com/~lynn/2004j.html#39 Methods of payment
https://www.garlic.com/~lynn/2004j.html#44 Methods of payment
https://www.garlic.com/~lynn/2005u.html#13 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006k.html#1 Passwords for bank sites - change or not?
https://www.garlic.com/~lynn/2006l.html#27 Google Architecture
https://www.garlic.com/~lynn/2006l.html#32 Google Architecture
https://www.garlic.com/~lynn/2006l.html#33 Google Architecture

Microsoft - will they bungle the security game?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler lynn@xxxxxxxx
Date: June 17, 2006 11:19 PM
Subject: Microsoft - will they bungle the security game?
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000752.html

a little cross-over from the naked transactions and chip&pin fraud series ....
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV

Ten reasons Chip 'n' Pin cards are bad
http://www.vigay.com/misc/chipandpin.html
The weakness in combo chip/mag stripe cards
http://bankwatch.wordpress.com/2006/05/06/the-weakness-in-combo-chip-mag-stripe-cards/
Chip and pin 'makes fraud even easier'
http://business.timesonline.co.uk/article/0,,9558-2178933,00.html
Fears over Chip and Pin
http://business.timesonline.co.uk/article/0,,9558-2170865,00.html
Eight arrested in chip and pin fraud racket
http://www.24dash.com/content/news/viewNews.php?navID=34&newsID=5478
Hundreds of drivers caught out by GBP1m chip-and-PIN sting
http://www.tmcnet.com/usubmit/2006/05/06/1639848.htm
CHIP AND PIN CARDS IN CHAOS
http://www.tmcnet.com/usubmit/2006/05/07/1639879.htm
Fraud, Phishing and Financial Misdeeds: Chip and PIN, Another Chapter in the Attack on Debit Cards
http://fraudwar.blogspot.com/2006/05/chip-and-pin-another-chapter-in-attack.html


can you say yes card? ...
https://www.garlic.com/~lynn/aadsm24.htm#1
https://www.garlic.com/~lynn/aadsm24.htm#2

some chip & pin trials in the UK as early as 1997 and the current chip&pin yes card vulnerability was well documented by at least 2002
https://www.garlic.com/~lynn/2006l.html#32
https://www.garlic.com/~lynn/2006l.html#33

by 1998, work on aads chip strawman was to have higher security than any DDA technology at a lower cost than any SDA technology (and be able to meet transit contactless requirements)
https://www.garlic.com/~lynn/aadsm23.htm#56

part of this was based on detailed vulnerability study that was part of x9.59 standards work started in the mid-90s
https://www.garlic.com/~lynn/aadsm23.htm#56
https://www.garlic.com/~lynn/x959.html#x959

the same aads chip strawman designed for both POS and internet financial transactions also did duty as authentication in RADIUS as well as Kerberos (the major authentication infrastructures deployed in the world today) ... i.e. not just the same technology ... but the objective was that a user's same, exact card (with no changes) ...
https://www.garlic.com/~lynn/aadsm23.htm#56
https://www.garlic.com/~lynn/subpubkey.html#radius
https://www.garlic.com/~lynn/subpubkey.html#kerberos

AADS Radius implementation was demonstrated spring of 1999 at PC EXPO in NYC by one of the participants of the AADS conference co-sponsored by Atalla and Tandem/Compaq held in Jan99 (radius is typically the authentication infrastructure used by ISPs world-wide)
https://www.garlic.com/~lynn/aepay3.htm#riskm

and the company that m'soft had contracted the original windows Kerberos implementation to (basis for the current/existing windows authentication infrastructure) demonstrated a number of different AADS chip strawman applications (financial and non-financial) at the world-wide retail banking (BAI) show Dec99 in Miami
https://www.garlic.com/~lynn/99.html#217
https://www.garlic.com/~lynn/99.html#224

and NACHA was gearing up to do the AADS internet trials about the same time
https://www.garlic.com/~lynn/x959.html#nacharfi

Naked Payments IV - let's all go naked

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Naked Payments IV - let's all go naked
Date: June 18, 2006 09:34 AM
Blog: Financial Cryptography
digitaltransactions June "paper" edition, available here as PDF file:
http://www.digitaltransactions.net/files/DTv3n5.pdf

has an article "The New Risk in PIN Debit" .. that mentions growing fraud involving PIN'ed transactions. PINs have been deemed more secure than signature transactions, but as "static data", they have been vulnerabilble to skimming/harvesting and replay attacks going back possibly nearly two decades.
https://www.garlic.com/~lynn/subintegrity.html#harvest

in fact, some of the skimming/harvesting technology used for skimming static data magstripe PIN'ed transaction is also applicable to the chip&pin static data yes card vulnerability. Related posting touching on some of the issues
https://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?

part of this has been that multi-factor authentication (PIN as something you know and card as something you have) has been considered to be more secure than single factor authentication ... based on implicit assumption that the different factors have different vulnerabilities/exploits; aka PIN has been considered countermeasure to lost/stolen card. misc. past posts mentioning 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor

However skimming/harvesting (going back possibly two decades) of "static" data has made the magstripe (as well as chip&pin SDA) and PIN vulnerable to a common exploit ... invalidating the assumption regarding multi-factor authentication being more secure (based on assumption that the different factors aren't vulnerable to common exploits).

The article also makes some comments about just focusing on securing any specific point in the infrastructure isn't going to make the problems go away. This could be construed as supporting the observation that naked transactions can be extremely vulnerable at a large number of different points in the infrastructure (requiring that the total end-to-end business process be heavily armored w/o even the smallest chinks in the protection).

ref:
http://financialcryptography.com/mt/archives/000749.html
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet

Naked Payments IV - let's all go naked

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Naked Payments IV - let's all go naked
Date: June 21, 2006 02:13 PM
Blog: Financial Cryptography
some recent news articles

Visa Says ATM Breach May Have Exposed Data (data breach)
http://www.washingtonpost.com/wp-dyn/content/article/2006/06/20/AR2006062001526.html
Visa says ATM breach may have exposed data (data breach)
http://www.businessweek.com/ap/financialnews/D8ICADK00.htm?sub=apn_news_down&chan=db
Visa acknowledges ATM security breach may have exposed consumer data (data breach)
http://news.moneycentral.msn.com/provider/providerarticle.asp?feed=AP&Date=20060620&ID=5812107
Data theft affects 88 million-plus Americans
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1195270,00.html
Data Theft | A Million Identities Stolen From Two Financial Services Firms
http://www.informationweek.com/showArticle.jhtml?articleID=189501128
Staff key to stealing your data
http://www.nzherald.co.nz/section/11/story.cfm?c_id=5&ObjectID=10387484


in the mid-90s, the x9a10 financial standards working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments.
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

some of the other efforts from the period were looking at providing heavy "hiding" armoring .... equivalent of something like 250lb body suit for use in infantry 120degree hostile battle zone, but w/o any power assist or air conditioning; aka 100 times payload bloat and possibly 100-1000 times processing bloat.

part of x9a10 activity was looking at a major threat model being replay attacks (involving static data; aka insiders or outsiders skimming existing transactions would have enough information to perform fraudulent transactions). x9.59 provided for changing the paradigm and eliminating replay attack vulnerability by providing complete end-to-end dynamic transaction authentication that was extrodinarily lightweight in both payload and processing.

for the replay attack threat ... that shows up in all sort of insider as well as outsider data breaches ... x9.59 instead of attempting the approach infantry 250lb body armor with no power assist and no heating/cooling ... to constantly hide the information (even recognizing that the body armor might have to be removed or opened periodically) .... changed the paradigm and eliminated the replay attack threat altogether. it was no long necessary to completely hide all transactions in order to be invulnerable to replay attacks ... since there was no information that an (insider or outsider) attacker could skim that would be sufficient to enable fraudulent transactions.

leaving the paradigm vulnerable to replay attacks can lead to the enormously heavily armoring requiring 100 times processing and payload bloat to complete hide the information. however, transaction processing still requires that the heavy armoring has to be removed frequently as part of standard business processing ... leaving the transaction exposed and vulnerable in the standard business processing points (studies that claim 70percent of fraud in these types of environments involve insiders; skimming and various sorts of breaches).

Do you trust chip and Pin payment systems?
http://www.computerweekly.com/Articles/2006/06/20/216501/Do+you+trust+chip+and+Pin+payment+systems.htm


... from above

A contractor working for a major high street bank pointed to banks' sensitivity on the issue. 'We got an e-mail telling us not to talk to anyone about the chip and Pin fraud issues,' he said.

... snip ...

misc.
https://www.garlic.com/~lynn/aadsm24.htm#5
https://www.garlic.com/~lynn/aadsm24.htm#6
https://www.garlic.com/~lynn/aadsm24.htm#7
https://www.garlic.com/~lynn/aadsm24.htm#9

FC++3 - Advances in Financial Cryptography, Number Three

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: FC++3 - Advances in Financial Cryptography, Number Three
Date: June 25, 2006 10:32 AM
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000757.html
http://financialcryptography.com/mt/archives/000702.html

I'm program cochair of track on security, authentication and virtualization

IEEE TC Computer Elements, Vail 2006, 25Jun2006

starting later today. Mark gives a talk ....

5.1 Virtualization/Security- Prog Lang Design Mark Miller, HP, erights@xxxxxxxx

http://www.unf.edu/ccec/ieee/index.html

Naked Payments IV - let's all go naked

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Naked Payments IV - let's all go naked
Date: June 28, 2006 10:52 AM
Blog: Financial Cryptography
Chip and SPIN; The switch to Chip and PIN may be for the benefit of banks rather than consumers, suggests Gervase Markham
http://business.timesonline.co.uk/article/0,,9075-2247493,00.html


from above ...

In reality, the clouds are gathering. One security research group at the University of Cambridge has successfully developed a prototype "skimmer", which could be miniaturised and built into any one of the hundreds of thousands of Chip and PIN terminals that UK consumers use every day.

... snip ...

... however, in the yes card scenario (from late 90s), the PIN doesn't actually have to be skimmed, just the chip equivalent of the magstripe information, since the terminal asks the (potentially counterfeit) card whether the entered PIN was correct or not (and if you were programming a counterfeit chip, what response would you be likely to program?).

note that the referenced article goes on to mention that the mechanics of liability has also changed in the switch to chip and pin.

article from 2002 about counterfeit (Chip and PIN) chips (yes cards) and mentions that information for creating yes cards was readily available on the internet skimming static data (see last paragraph)
https://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

earlier yes card comments, including reference to chip and pin trials in the UK as early as 1997.
https://www.garlic.com/~lynn/aadsm24.htm#8

recent posts in this thread:
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked

On Leadership - negotiating the RTFM into the realm of forgotten schoolyard jokes

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: On Leadership - negotiating the RTFM into the realm of forgotten schoolyard jokes
Date: June 29, 2006 08:43 PM
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000767.html

in past life they sent my wife to executive training school (a couple times, level I executive, level II executive, etc; something typically found in large corporations).

they gave Myers-Briggs personality tests and talked about different personality types frequently communicate differently and also frequently have different motivations and goals.

they also do things like break-up into teams and play games that involve win/win and win/loose strategies .... i.e. typically to learn about leaning towards win/win ... since it can provide best long term outcome.

however, my wife had her team play win/win up until the very last round ... and on the last round played win/loose. this nearly brought some grown men on the other team to tears complaining that she played unfair. part of the issue is that if it really is the last round ... it is possible to play win/loose and not worry about long term consequences. however, in real-life, there frequently is no definitive "conclusion", so playing win/loose (in real life) may result in long-term adverse consequences.

some people that are in the habit of playing win/loose ... may also be found to use cliches like "that is water under the bridge" ... in attempt to wipe the slate clean each time.

for even further drift there is always Boyd's talk on Organic Design for Command and Control ... where he eventually gets around to asserting that the preferred terms should be Leadership and Appreciation.

this is 1987 version
http://www.belisarius.com/

I had sponsored him at seminars in the early 80s and still have one of the original versions (hard copy) of the talk along with some number of subsequent versions as this particular talk evolved.

my past posts mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd

and misc. URLs from the around the web about Boyd, OODA-loops and/or other Boyd-related topics
https://www.garlic.com/~lynn/subboyd.html#boyd2

Naked Payments IV - let's all go naked

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Naked Payments IV - let's all go naked
Date: June 30, 2006 11:31 AM
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000749.html

'Banks Pass Buck On Fraud'
http://www.sky.com/skynews/article/0,,30100-13530753,00.html

from above ...

Chip and PIN was hailed as a breakthrough in card fraud but a Sky News investigation has shown the system may not be as secure as is claimed.

... snip ...

article from 2002 about counterfeit (Chip and PIN) chips (yes cards) and mentions that information for creating yes cards was readily available on the internet, skimming static data (see last paragraph)
https://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

recent posts mentiong yes card:
https://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
https://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#0 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked

Apple to help Microsoft with "security neutrality"?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Apple to help Microsoft with "security neutrality"?
Date: July 2, 2006 11:29 AM
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000772.html

http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/About/chapter_1_section_5.html

from above:
Mac OS X is based on the Mach 3.0 microkernel, designed by Carnegie Mellon University, and later adapted to the Power Macintosh by Apple and the Open Software Foundation Research Institute (now part of Silicomp). This was known as osfmk, and was part of MkLinux (http://www.mklinux.org). Later, this and code from OSF's commercial development efforts were incorporated into Darwin's kernel. Throughout this evolutionary process, the Mach APIs used in Mac OS X diverged in many ways from the original CMU Mach 3 APIs.

... snip ...

NeXT had started with the MACH kernel proior to Mac OS.

Mach was one of the CMU projects, along with stuff like Andrew File System (a lot of which you see later in Open Software Foundation/OSF), Andrew widgets, Camelot, etc.

IBM and DEC had jointly funded MIT's Project Athena to the tune of $25m each ... sort of from which came X-windows and stuff like Kerberos. Kerberos is now the basic authentication mechanism for a lot of things, including m'soft Windows. misc. past kerberos postings
https://www.garlic.com/~lynn/subpubkey.html#kerberos

IBM had funded similar activity at CMU to the tune of $50m.

Part of the idea of microkernels is that they are usually much smaller and easier to maintain and support; KISS contributing significantly to consistency, integrity and security.

One of the issues with traditional microkernels is that it can be hard to maintain KISS focus and discipline over span of decades.

This is one of the places that virtual machine hypervisors have sometimes played ... as a form of microkernel ... where it is easier to maintain focus on what feature/function is being provided by the microkernel ... helping control the feature creep, bugs, mistakes, etc that can occur in typical operating system development (especially when you are talking about periods spanning decades).

disclaimer ... i've been preaching advantages of KISS and microkernels since I started rewriting large amounts of virtual machine hypervisor code as an undergraduate back in the 60s ... and the vendor picking up the code and shipping it as part of the standard product.

Apple to help Microsoft with "security neutrality"?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Apple to help Microsoft with "security neutrality"?
Date: July 2, 2006 12:01 PM
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm24.htm#15 Apple to help Microsoft with "security neutrality"?

at conference last week ... mentioned in earlier thread
https://www.garlic.com/~lynn/aadsm24.htm#11 FC++3 - Advances in Financial Cryptography, Number Three

one of the vendors mentioned that they were moving SSL into the kernel ... in order to improve the performance (eliminating some number of buffer copies and other things).

followed was a discussion of microkernel philosiphy and trying to get everything out of the kernel than the bare minimum needed to provide things like authorized permissions.

Mark mentioned that this is a re-occuring theme for coyotos
http://www.coyotos.org/

where there has been ongoing attempts at trying to get the TCP/IP protocol stack out of the kernel (I think Mark mentioned that the current kernel, w/tcp/ip stack, is something like 230k lines of code).

This is sort of the evolution of capability operating system starting with GNOSIS, KeyKos, EROS, etc. a few recent posts on the subject:
https://www.garlic.com/~lynn/2006k.html#37 PDP-1
https://www.garlic.com/~lynn/2006m.html#34 PDP-1

On Leadership - negotiating the RTFM into the realm of forgotten schoolyard jokes

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: On Leadership - negotiating the RTFM into the realm of forgotten schoolyard jokes
Date: July 2, 2006 02:21 PM
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm24.htm#13 On Leadership - negotiating the RTFM into the realm of forgotten schoolyard jokes

Boyd had this story when he was head of light-weight fighter design at the Pentagon ... redoing the F15 & F18 designs (among other things significantly reducing the planes weight) and coming up with the F16 design.

The 1-star, he reported to, was visiting the area one day and found Boyd and some number of lieutenants in heated debate about technical design issues. The 1-star called Boyd on the carpet for allowing an unprofessional atmosphere (i.e. lieutenants should never be allowed to disagree with their superior officers).

A meeting was called in one of the pentagon's auditoriums where the 1-star publicly fired Boyd for allowing the unprofessional atmosphere. A couple weeks later a 4-star called a meeting in the same place with the same audience and publicly rehired Boyd and rebuked the 1-star, telling him to never mess with fighter design area (something he knew nothing about).

one of the tributes to Boyd:
Col. John R. Boyd, USAF (ret.) died in West Palm Beach Florida on Sunday, 9 March 1997.
http://www.belisarius.com/


The air force somewhat disowned him ... but at the end, he had been adopted by the Marines. His collected works are now at the Marine museum.

my collected past posts mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html#boyd

other URLs from around the web mentioning Boyd, OODA-loops and/or other Boyd related subjects
https://www.garlic.com/~lynn/subboyd.html#boyd2

On Leadership - tech teams and the RTFM factor

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: On Leadership - tech teams and the RTFM factor
Date: July 3, 2006 11:16 AM
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000765.html

this is a slightly different issue ... it is a lot easier to answer the question when it is a level 1 question ... when a level 1 person asks about some level 3 issue ... the person asking the question frequently doesn't have the context to understand any answer. i've periodically used the analogy of a five year old asking a question about some issue involving graduate school mathematics or physics.

there is also issue of whether they are trained professionals or somebody that has no professional experience or training in the area. a side issue is a lot of system programming being much more like a craft than a science (need long years of guild apprenticeship)

periodically when you attempt to gracefully explain to a grown person that they lack the context to understand the answer ... you get a response that claims their lack of understanding is because you aren't capable of explaining the answer (its your fault not their fault).

slightly related, in various usenet news groups there is sporadic antagonism ... not so much about the level 1 questions ... but when the questions appear to be blatent homework. in comp.arch (computer architecture) there use to be some correlation with homework questions and the start of a semester (entering freshman having their 1st exposure to online computing) ... but now it seems to be randomly distributed year around.

and of course, one of the ultimate authorities on "agile" was boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2

Use of TPM chip for RNG?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Use of TPM chip for RNG?
Date: Mon, 03 Jul 2006 10:41:05 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx, hal@xxxxxxxx
Peter Gutmann wrote:
You have to be pretty careful here. Most of the TPM chips are just rebadged smart cards, and the RNGs on those are often rather dubious. A standard technique is to repeatedly encrypt some stored seed with an onboard block cipher (e.g. DES) as your "RNG". Beyond the obvious attacks (DES as a PRNG isn't particularly strong) there are the usual paranoia concerns (how do we know the manufacturer doesn't keep a log of the seed and key?) and stupidity concerns (all devices use the same hardwired key, which some manufacturers have done in the past). There are also active attacks possible, e.g. request values from the device until the EEPROM locks up, after which you get constant "random" values. Finally, some devices have badly-designed challenge-response protocols that give you an infinite amount of RNG output to analyse, as well as helping cycle the RNG to lockup.

One of the issues for a long time, for that class of chips, is whether they perform on-chip key-gen and/or whether DSA (and/or ECDSA) were in use ... processes where reasonable good RNG are integral to the operation.

at one point there was tests for a collection of chips in that class that performed 65k power-cycle/RNG operations and found that something like 30 percent of the numbers were repeated.

however, at least some of the TPM chips have RNGs that have some level of certification (although you might have to do some investigation to find out what specific chip is being used for specific TPM).

On Leadership - tech teams and the RTFM factor

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: On Leadership - tech teams and the RTFM factor
Date: July 3, 2006 03:34 PM
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm24.htm#18 On Leadership - tech teams and the RTFM factor

to some extent guilds persisted over long period of time in relatively stable (stagnate) environments.

in rapidly changing and expanding domain ... a 20 year (or even five year) apprenticeship may leave you with a lot of obsolete skills.

some number of the tools, SDKs and development environments from the 90s ... especially object-oriented stuff ... where heavily laced with GUI capabilities that allowed toy demos to be turned out quickly and cheaply ... but rarely had any significant support for hard-core industrial strength data processing (and there frequently was a large gap between the toy demos and real deployable operations ... other than using the toy demos for entertainment value akin to games).

one example was the taligent stuff ... we had done a one week JAD (with dozen people from taligent) look and came up with a 30 percent hit to existing taligent base plus 30 percent new code ... in order to add any appreciable support for industrial strength data processing.

finally, in a rapidly changing and expanding domain ... the demand for "experts" can far exceed the supply ... and so many have to make do with what they can get.

this can lead to chicken and egg situation ... if the demand for experts far exceeds the supply, vendors will frequently try to adapt their products to the skill level that is available ... trying to make do w/o requiring real experts.

Use of TPM chip for RNG?

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Use of TPM chip for RNG?
Date: Tue, 04 Jul 2006 10:53:11 -0600
To: Travis H. <solinym@xxxxxxxx>
CC: Peter Gutmann <pgut001@xxxxxxxx>,  cryptography@xxxxxxxx,  hal@xxxxxxxx
Travis H. wrote:
http://www.usenix.org/publications/library/proceedings/smartcard99/technical.html
http://www.usenix.org/publications/library/proceedings/cardis02/tech.html


or even this ... having to resort to the wayback machine
https://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

includes mention of yes card attack (end of last paragraph). however, the yes card attack is really a repaly attack on the terminals (and the infrastructure implementation) ... not on cards. a few posts discussing yes card attacks:
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-AND-Pin Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV

Naked Payments IV - let's all go naked

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Naked Payments IV - let's all go naked
Date: July 5, 2006 11:07 AM
Blog: Financial Cryptography
French Banks Upgrade Security Of EMV Cards
http://www.cardtechnology.com/article.html?id=2006070569TSQ1WX
from above:

The DDA cards store an encryption key that generates a unique number, or signature, for each transaction. This signature is read by the point-of-sale terminal, which has a corresponding encryption key, so a transaction from a counterfeit card is unlikely to be approved. The DDA technology allows banks to more securely approve transactions at the terminal without having to send the transactions over the network for authorization.

... snip ...

this looks to close the yes card, replay attack scenario with existing static data (skim static data in manner similar to skimming magstripe static data, using it to create counterfeit card).

an issue raised in the naked transaction scenario ... is whether the actual transaction is signed ... ala x9.59
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

or is it an upgrade of the existing static-data card authentication to dynamic-data card authentication ... aka an end-point authentication ... but leaving the actual transaction otherwise naked ... and possibly vulnerable to things like man-in-the-middle attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

i.e. a yes card paired with some valid card, where the yes card transparently passes the card authentication interchange but handles all other operations.

misc. past yes card and/or naked transaction postings:
https://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
https://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
https://www.garlic.com/~lynn/aadsm18.htm#20 RPOW - Reusable Proofs of Work
https://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
https://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
https://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
https://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
https://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#35 A quote from Crypto-Gram
https://www.garlic.com/~lynn/2004j.html#39 Methods of payment
https://www.garlic.com/~lynn/2004j.html#44 Methods of payment
https://www.garlic.com/~lynn/2005u.html#13 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006k.html#0 Passwords for bank sites - change or not?
https://www.garlic.com/~lynn/2006l.html#27 Google Architecture
https://www.garlic.com/~lynn/2006l.html#32 Google Architecture
https://www.garlic.com/~lynn/2006l.html#33 Google Architecture
https://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
https://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt
https://www.garlic.com/~lynn/aadsm24.htm#0 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#6 Securely handling credit card transactions earns Blackboard kudos
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#21 Use of TPM chip for RNG?

Use of TPM chip for RNG?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Use of TPM chip for RNG?
Date: Wed, 05 Jul 2006 12:26:20 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: tls@xxxxxxxx,  cryptography@xxxxxxxx
Peter Gutmann wrote:
Exactly. The FIPS 140 (strictly speaking X9.17/X9.31 PRNG) tests test a generator's determinism, not its nondeterminism. In other word they generate a set of input/output pairs from a known-good generator and then make sure that the generator being certified produces the same output. Actually getting nondeterminism into the process is quite tricky, and involves extremely careful and creative reinterpretation of the "DT vector" (date-and-time) input. The non-creatively-interpreted generator depends for its strength entirely on the key chosen for the PRNG. If it's constant across all devices, it'll pass the certification but its strength will be close to zero.

i.e. you have to actually understand what is being tested; fips, common criteria, etc. there was a presentation a couple years ago on common criteria certification for the same EAL4 level ... supposedly something like 64 certifications had been done to the same protection profile ... but in the fine print, something like sixty (of the 64) evaluations had some sort of (unspecified) deviations ... so you didn't even know that two "things" evaluated to the same level with supposedly the same protection profile ... were in any way comparable (assuming you actually have access to protection profiles that being used for the evaluations).

i believe some of the earlier mention chips
https://www.garlic.com/~lynn/aadsm24.htm#19 Use of TPM chip for RNG?

had been FIPS140 evaluated ... even tho that the 64k power on/off tests followed by RNG were found to have something like 30percent of the values repeat of some previous generated value.

we started seriously looking at aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads

around '98 ...
https://www.garlic.com/~lynn/aadsm2.htm#strawm1

in part, for supporting x9.59 transactions ...
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

and mandated both on-chip keygen as well as EC/DSA ... both operations requiring fairly high integrity RNG. However, at the time, I somewhat facetiously claimed that we were going to take a $500 milspec part, cost reduce it by better than two orders of magnitude and at the same time improve its security/integrity. In any case, significantly higher RNG assurance was required than what was normally found in most chips.

I made somewhat the same claim in an assurance panel at spring 2001 IDF in the TPM track ... somewhat chiding the TPM people in the audience.

Another aspect of evaluation certification was that a lot of chips were evaluated straight out of the fab ... based on the characteristic of the chip at that moment. after that the appications and crypto were loaded onto the chip (so even for chips that might have some RNG capability, since the applications that might expose any RNG characteristics weren't yet loaded ... RNG wasn't part of the chip evaluation).

What we ran into with aads chip strawman ... was that key-gen and ec/dsa was built into the manufactured chip as it came from the fab. As a result key-gen and ec/dsa became part of the chip evaluation ... and formal definition of same, limited the evaluation level. this was even tho that other uses of very similar chips were able to claim much higher certification levels (since they were able to certify prior to loading various crypto and RNG related applications ... aka there were significant differences in the protection profiles that the certifications were based on).

It's official! SSH whips HTTPS butt! (in small minor test of no import....)

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: It's official! SSH whips HTTPS butt! (in small minor test of no import....)
Date: July 5, 2006 06:48 PM
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000769.html

slightly related news item from today

Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
http://www.linuxsecurity.com/content/view/123451/65/

this is actually RFC 4255 which was published last January ... from my RFC index, RFC4255 summary
https://www.garlic.com/~lynn/rfcidx14.htm#4255

4255 PS
Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, Griffin W., Schlyter J., 2006/01/03 (9pp) (.txt=18399) (Refs 1034, 1035, 2411, 2845, 2931, 3007, 4033, 4034, 4035, 4251, 4253)


... as always, clicking on the ".txt=nnnn" field retrieves the actual RFC.

Note that I've been claiming for years that something similar could be done for SSL ... eliminating requirement for the existing digital certificate process. lots of past ssl certificate postings
https://www.garlic.com/~lynn/subpubkey.html#sslcert
and various certificate-less digital signature postings
https://www.garlic.com/~lynn/subpubkey.html#certless

FraudWatch - Chip&Pin, a new tenner (USD10)

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 6, 2006 01:01 AM
Subject: FraudWatch - Chip&Pin, a new tenner (USD10)
Blog: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000673.html

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

Most EMV cards in circulation worldwide, including those in the UK, use less-secure "static" signatures, which can be copied onto cloned cards. Unless issuers send these transactions over the processing network for online authentication, terminals might not be able to detect fraudulent cards.

... snip ...

also
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked

see last paragraph on yes cards in the following
https://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html

Naked Payments IV - let's all go naked

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Naked Payments IV - let's all go naked
Date: July 6, 2006 11:43 AM
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000749.html

France To Prioritize EMV DDA Cards By Mid-2007
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=11521775048614134132&block=

from above
The mask in question supports all bank card applications in France, EMV and Moneo, and is certified to EAL 4+ level, the toughest card security standard in existence.

... snip ...

some comments about EAL4+ and higher evaluations
https://www.garlic.com/~lynn/aadsm24.htm#23 Use of TPM chip for RNG?

one of the issues for X9.59 standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

and "signing" the transaction directly and avoiding naked transactions involved various kinds of MITM-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

some that might even involve a pair of cards, one counterfeit and one valid.

a few past chip&pin posts happening to mention MITM-attacks
https://www.garlic.com/~lynn/aadsm23.htm#19 Petrol firm suspends chip-and-pin
https://www.garlic.com/~lynn/aadsm23.htm#34 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked

DDA cards may address the UK Chip&Pin woes

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 6, 2006 12:48 PM
Subject: DDA cards may address the UK Chip&Pin woes
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000776.html

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).
https://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
https://www.garlic.com/~lynn/x959.html#x959
https://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
https://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
https://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
https://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
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked

DDA cards may address the UK Chip&Pin woes

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 6, 2006 03:52 PM
Subject: DDA cards may address the UK Chip&Pin woes
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000776.html
https://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes

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

somewhat as part of supporting x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

... 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.
https://www.garlic.com/~lynn/subtopic.html

so in the 98 timeframe 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 ... manufacturing is basically per "wafer" .... and the per chip costs then become the number of chips you get 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.
https://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 some of these other digital signature algorithms) is to implement really large math/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 ... say on the order of the time it takes to enter a PIN; you could possibly 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 in transit time windows and 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 just little (from '98). 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 ... changes the area by pi*6sq/pi*4si = 36/16 = 2.25. The combination of the two results in approx. 20 times more chips per wafer (and therefor potentially 20 times reduction in the manufacturing cost per chip).
If we talk about comparing conventional chips in .6micron, 8in wafer timeframe to .2micron, 12in wafer aads chip strawman ... we can talk about on the order of 200 times more chips per wafer, with possibly corresponding decrease in 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 ... both width and length of chip were becoming about the same as width of saw cut). This met that possibly only something like 1/4th of a wafer surface actually would result in aads strawman chips.

What has actually 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 manufacturing 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.

DDA cards may address the UK Chip&Pin woes

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 6, 2006 07:05 PM
Subject: DDA cards may address the UK Chip&Pin woes
Blog: Financial Cryptography
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 commonly been done as part of personalization with an external key-gen facility and the keys injected into the chip.

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

and
https://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
https://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 manufactured 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 manufacturing science and technology ... highly optimizing the product manufacturing process to maximize operation/efficiency as well as minimizing costs.

DDA cards may address the UK Chip&Pin woes

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 7, 2006 11:06 AM
Subject: DDA cards may address the UK Chip&Pin woes
Blog: Financial Cryptography
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."

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

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.
https://www.garlic.com/~lynn/x959.html#x959
https://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
https://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 were readily available on the internet)
https://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
https://www.garlic.com/~lynn/subintegrity.html#mitm

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

DDA cards may address the UK Chip&Pin woes

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 9, 2006 12:12 PM
Subject: DDA cards may address the UK Chip&Pin woes
Blog: Financial Cryptography
threat/security taxonomy footnote ... as an aside, i recently updated our merged security taxonomy and glossary
https://www.garlic.com/~lynn/index.html#glosnote

with terms from NIST IR 7298.

re:
https://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 discussed in 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
https://www.garlic.com/~lynn/subintegrity.html#mitm

(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.
https://www.garlic.com/~lynn/x959.html#x959
https://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
https://www.garlic.com/~lynn/subpubkey.html#certless

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

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

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

DDA cards may address the UK Chip&Pin woes

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 10, 2006 03:54 PM
Subject: DDA cards may address the UK Chip&Pin woes
Blog: Financial Cryptography
... and more security/threat taxonomy footnote
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes

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

there is the three factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor 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 ... because 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)
https://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 ...
https://www.garlic.com/~lynn/subintegrity.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 issues raised in the various naked transation threads
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#6 Securely handling credit card transactions earns Blackboard kudos
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
https://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
https://www.garlic.com/~lynn/x959.html#x959
https://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.

Threatwatch - 2-factor tokens attacked by phishers

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 10, 2006 07:05 PM
Subject: Threatwatch - 2-factor tokens attacked by phishers
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000782.html

a couple old posts from more than a year ago mentioning that it appears vulnerable to MITM-attacks
https://www.garlic.com/~lynn/aadsm19.htm#20 Citibank discloses private information to improve security
https://www.garlic.com/~lynn/aadsm19.htm#21 Citibank discloses private information to improve security

and
https://www.garlic.com/~lynn/aadsm19.htm#23 Citibank discloses private information to improve security
https://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private information to improve security

... for some drift
https://www.garlic.com/~lynn/aadsm19.htm#25 Digital signatures have a big problem with meaning

and some discussion of browser/ssl operation
https://www.garlic.com/~lynn/aadsm19.htm#27 Citibank discloses private information to improve security

and
https://www.garlic.com/~lynn/aadsm19.htm#28 "SSL stops credit card sniffing" is a correlation/causality myth

and even this
https://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning

somewhat coincident ... but I had just appended some comments about multi-factor authentication
https://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes

in this thread
http://financialcryptography.com/mt/archives/000776.html

Phishers Defeat 2-Factor Auth

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Phishers Defeat 2-Factor Auth
Date: Tue, 11 Jul 2006 11:38:34 -0600
To: cryptography@xxxxxxxx
Lance James wrote:
Full article at http: // blog.washingtonpost.com / securityfix /

happen to mention more than a year ago ... that it would be subject to mitm-attacks ... recent comment on the subject
https://www.garlic.com/~lynn/aadsm24.htm#33 Threatwatch - 2-factor tokens attacked by phishers.

in thread from this mailing list more than year ago
https://www.garlic.com/~lynn/aadsm19.htm#20 Citibank discloses private information to improve security
https://www.garlic.com/~lynn/aadsm19.htm#21 Citibank discloses private information to improve security
https://www.garlic.com/~lynn/aadsm19.htm#22 Citibank discloses private information to improve security
https://www.garlic.com/~lynn/aadsm19.htm#23 Citibank discloses private information to improve security
https://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private information to improve security

... and so on

Interesting bit of a quote

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Interesting bit of a quote
Date: Tue, 11 Jul 2006 16:45:27 -0600
To: dan@xxxxxxxx
CC: leichter_jerrold@xxxxxxxx,  cryptography@xxxxxxxx
dan@xxxxxxxx wrote:
I can corroborate the quote in that much of SarbOx and other recent regs very nearly have a guilty unless proven innocent quality, that banks (especially) and others are called upon to prove a negative: X {could,did} not happen. California SB1386 roughly says the same thing: If you cannot prove that personal information was not spilled, then you have to act as if it was. About twenty states have followed California's lead. The surveillance requirements of both SEC imposed-regulation and NYSE self-regulation seem always to expand. One of my (Verdasys) own customers failed a SarbOx audit (by a big four accounting firm) because it could not, in advance, *prove* that those who could change the software (sysadmins) were unable in any way to change the financial numbers and, in parallel, *prove* those who could change the financial numbers (CFO & reports) were unable to change the software environment.

my slightly different perspective is that audits in the past have somewhat been looking for inconsistencies from independent sources. this worked in the days of paper books from multiple different corporate sources. my claim with the current reliance on IT technology ... that the audited information can be all generated from a single IT source ... invalidating any assumptions about audits being able to look for inconsistencies from independent sources. A reasonable intelligent hacker could make sure that all the information was consistent.

a counter example is the IRS, where individual reported income is correlated with other sources of reported financial information. however, i don't know how that could possibly work in the current environment where the corporation being audited is responsible for paying the auditors (cross checking information across multiple independent sources)

some past posts on the sox audit subject:
https://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
https://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley

Interesting bit of a quote

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Interesting bit of a quote
Date: Tue, 11 Jul 2006 20:18:39 -0600
To: dan@xxxxxxxx
CC: cryptography@xxxxxxxx
dan@xxxxxxxx wrote:
You're talking about entirely different stuff, Lynn, but you are correct that data fusion at IRS and everywhere else is aided and abetted by substantially increased record keeping requirements. Remember, Poindexter's TIA thing did *not* posit new information sources, just fusing existing sources and that alone blew it up politically. As a security matter relevant here, we can't protect un-fused data so fused data is indeed probably worse.

but this is the security issue dating back to before the 80s ... when they decided they could no longer guarantee single point of security ... in part because of insider threats ... they added multiple independent sources as a countermeasure. the crooks responded with collusion ... so you started to see countermeasures to collusion appearing in the early 80s.

the advent of the internet, sort of refocused attention to outsider attacks ... even tho the statistics continue to hold that the major source of fraud is still insiders ... including thru the whole internet era. the possibility of outsiders may have helped insiders obfuscate true source of many insider vulnerabilities.

the issue with auditing to prove no possible vulnerability for a single point ... leading to the extremes of having to prove a negative ... can possibly be interpreted within the context of attempting to preserve the current audit paradigm.

independent operation/sources/entities have been used for a variety of different purposes. however, my claim has been that auditing has been used to look for inconsistencies. this has worked better in situations where there was independent physical books from independent sources (even in the same corporation).

As IT technology has evolved ... my assertion is a complete set of (consistent) corporate books can be generated from a single IT source/operation. The IRS example is having multiple independent sources of the same information (so that you can have independent sources to check for inconsistencies).

The fusion scenarios tend to be having multiple independent sources of at least some different data ... so the aggregation is more than the individual parts (as opposed to the same data to corroborate).

misc. sox ref:
https://www.garlic.com/~lynn/aadsm24.htm#35 Interesting bit of a quote
https://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
https://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley

for reference to aggregation of different data ... as opposed to data corroboration (of the same data) ... there is an article written about data mining which happens to mention some knowledge management work we have done
https://www.garlic.com/~lynn/index.html

http://www.publicsectorinstitute.net/ELetters/EGovernment/v4n7/May13Articles.lsp#DataMining2 '

DDA cards may address the UK Chip&Pin woes

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 12, 2006 01:02 AM
Subject: DDA cards may address the UK Chip&Pin woes
Blog: Financial Cryptography
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 ...

a couple refs:
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes

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

Interesting bit of a quote

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Interesting bit of a quote
Date: Wed, 12 Jul 2006 13:08:11 -0600
To: Anton Stiglic <astiglic@xxxxxxxx>
CC: David Wagner <daw@xxxxxxxx>, dan@xxxxxxxx, cryptography@xxxxxxxx
Anton Stiglic wrote:
Does that mean that you (the company) are safe if all of the personal information in the database is simply encrypted with the decryption key laying right there alongside the data? Alot of solutions do this, some go to different lengths in trying to obfuscate the key.

note that a lot of the data breaches and financial fraud have involved things with payment card transactions ... where details of previous transactions is sufficient for crook to perform fraudulent transactions (and as a result one of the reasons that there is various concern of data breaches involving files containing payment card data).

also a lot of the identity theft incidents involve "account fraud", i.e. being able to perform a fraudulent transaction against an existing account with the use of minimal amount of harvested information
https://www.garlic.com/~lynn/subintegrity.html#harvest

there has been some attempt by the FTC and other organizations to differentiate account fraud from other forms of identity theft.

however, the information in the transactions is also required in dozens of business processes. this somewhat led to my old post on security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

and my frequent observation that the planet could be buried under miles of crypto and still not be able to stop the information leakage .... i.e. transaction details having diametrically opposed requirements ... openly available for all sorts of business processes and never divulged because it can lead to fraudulent transactions.

in the mid-90s, the x9a10 working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the result was x9.59 financial industry retail payment standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

one of the features of x9.59 standard was that it eliminated the leakage of transaction information as a financial fraud vulnerability (i.e. a crook could not perform a fraudulent transaction just from information from previous transaction or skimming).

as a result, the integrity of the financial infrastructure and x9.59 transactions are preseved for both transactions "in-flight" (say over the internet) as well as transactions "at-rest" (in databases and transaction logs), w/o having to resort to "hiding" the transactions with technology like encryption.

a thread/discussions about "naked transactions" and their vulnerabilities (i.e. unarmored, non-x9.59 transactions):
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes

series of blogs on "naked" payment (transaction) issue:
http://financialcryptography.com/mt/archives/000745.html
http://financialcryptography.com/mt/archives/000744.html
http://financialcryptography.com/mt/archives/000747.html
http://financialcryptography.com/mt/archives/000749.html

misc. past posts mentioning "at rest" and "in flight" transaction vulnerabilities
https://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
https://www.garlic.com/~lynn/2002d.html#39 PKI Implementation
https://www.garlic.com/~lynn/2002f.html#9 PKI / CA -- Public Key & Private Key
https://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
https://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card Protocol on Web Site
https://www.garlic.com/~lynn/2002n.html#14 So how does it work... (public/private key)
https://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003b.html#41 Public key encryption
https://www.garlic.com/~lynn/2003d.html#30 SSL questions
https://www.garlic.com/~lynn/2003j.html#53 public key confusion
https://www.garlic.com/~lynn/2003m.html#38 Questioning risks of using the same key for authentication and encryption
https://www.garlic.com/~lynn/2005g.html#51 Security via hardware?
https://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom
https://www.garlic.com/~lynn/2005t.html#34 RSA SecurID product
https://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!

Interesting bit of a quote

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Interesting bit of a quote
Date: Thu, 13 Jul 2006 11:23:52 -0600
To: John Kelsey <kelsey.j@xxxxxxxx>
CC: dan@xxxxxxxx, leichter_jerrold@xxxxxxxx, cryptography@xxxxxxxx
John Kelsey wrote:
It's interesting to me that this same kind of issue comes up in voting security, where computerized counting of hand-marked paper ballots (or punched cards) has been and is being replaced with much more user-friendly DREs, where paper poll books are being replaced with electronic ones, etc. It's easy to have all your procedures built around the idea that records X and Y come from independent sources, and then have technology undermine that assumption. The obvious example of this is rules for recounts and paper record retention which are applied to DREs; the procedures make lots of sense for paper ballots, but no sense at all for DREs. I wonder how many other areas of computer and more general security have this same kind of issue.

being slightly perverse ... there is the analogy with the new england net. at one point somebody went to the trouble to get nine(?) 56kbit circuits routed out of the new england area on nine distinct physical trunks (diverse routing, telco provisioning). however, over a period of years, nobody appeared to pay attention as the unique circuits were consolidated to fewer and fewer physical trunks. one day, someplace in conn., the new england net fell victim to a backhoe denial of service attack (and the new england net was partitioned from the rest of the world for a couple of days).

so one might conjecture that the sox approach to the opportunity is to retrofit the complete length of the single physical trunk (possibly a couple hundred miles) with a bunker, built to bank vault specifications ... as a countermeasure to the backhoe denial of service attack (and nickname it the big dig).

possibly the only "new" real countermeasure in sox is the part about informants ...

recently i was told that the typical sox bill for a small to medium size $25m corporation is running $800k.

misc. past sox references:
https://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
https://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley
https://www.garlic.com/~lynn/aadsm24.htm#35 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#36 Interesting bit of a quote

Interesting bit of a quote

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Interesting bit of a quote
Date: Sat, 15 Jul 2006 09:15:21 -0600
To: Travis H. <solinym@xxxxxxxx>
CC: David Mercer <radix42@xxxxxxxx>,  cryptography@xxxxxxxx
Travis H. wrote:
1) Some kind of physical authenticity, such as signing one's name on the media as they are produced (this assumes the signer is not corruptible), or applying a frangible difficult-to-duplicate seal of some kind (this assumes access controls on the seals).
2) Some kind of hash chain covering the contents, combined with publication of the hashes somewhere where they cannot be altered (e.g. publish hash periodically in a classified ad in a newspaper).


a lot of that has to do with whether you have an original and/or whether an original has been modified.

my view of audits for sox type stuff is whether the original is correct. that is where multiple independent sources of original information came in for purposes of cross checking (and possibility of any inconsistency is indication of something amiss) ... and where subsequently you have to start worrying about countermeasure to collusion.

however, if you have collapsed the originals to single source, you loose the ability to cross-check multiple independent originals for validity of the information. so you ask for a lot more detailed information in the originals ... hoping the level of detail is harder to make consistent (since you may have some sense that you have lost the capability of cross checking multiple independent sources for inconsistency). the counter argument is that with IT technology ... that any level of detail can be programmed to be consistent (if you are going to create incorrect information in an original ... you could make it incorrectly consistent to any level of detail).

So now you create significant threats and penalties for anybody (in charge) allowing incorrect information to appear in an audit (since you somehow realize that with only a single source, it isn't likely that an audit is going to turn up inconsistent information as an indication that something is incorrect).

So now you are potentially in a situation that audits are no longer an effective countermeasure to serious inconsistent or incorrect information ... its the threats and the penalties that are the countermeasure to serious inconsistent or incorrect information. At the same time there is some sense if audits previously had turned up inconsistency (from multiple independent sources) ... then there is some hope that possibly just increasing the level of audit detail might still provide some benefit.

misc. past sox references:
https://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
https://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley
https://www.garlic.com/~lynn/aadsm24.htm#35 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#36 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#39 Interesting bit of a quote

Naked Payments IV - let's all go naked

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Naked Payments IV - let's all go naked
Date: July 16, 2006 01:22 AM
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked

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


that the terminal can approve transactions at the terminal w/o having to send the transactions over the network.

however
https://www.garlic.com/~lynn/aadsm24.htm#24 Naked Payments IV - let's all go naked

references:
France To Prioritize EMV DDA Cards By Mid-2007
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=11521775048614134132&block=


mentions that the DDA card can be authenticated at the terminal w/o having to send a separate transaction over the network (leaving it open whether the terminal will authorize the transaction or the transaction is set over the network for authorization, separate from the card authentication).

this EMV DDA article:

Banks urged to use new technology for combating credit card frauds
http://www.gulf-times.com/site/topics/article.asp?cu_no=2&item_no=91869&version=1&template_id=36&parent_id=16


mentions the following:
However, the DDA technology would give the optimum results only if the transactions were done online

...
the issues about:
1) whether the transaction is authorized online or offline (at the terminal) and
2) pros & cons of having authentication of the card as opposed to transaction authentication

have been discussed in some detail in the various naked payment/transaction threads
http://financialcryptography.com/mt/archives/000745.html
http://financialcryptography.com/mt/archives/000744.html
http://financialcryptography.com/mt/archives/000747.html
http://financialcryptography.com/mt/archives/000749.html

and ...
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked

Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
Date: July 16, 2006 09:07 AM
Blog: Financial Cryptography
Dave writes:
On the other hand, if you use a pin, then that doesn't apply and currently, the new merchant agreements state that the risk falls squarely on the retailler, just like customer-not-present transactions always did.

re:
http://financialcryptography.com/mt/archives/000744.html

other subsequent posts also make reference to possible transfer of liability; re:
https://www.garlic.com/~lynn/aadsm24.htm#7

has this reference:
UK bank card security flaws warning
http://euronews.net/create_html.php?page=detail_eco&article=363719&lng=1


and
https://www.garlic.com/~lynn/aadsm24.htm#12

has this reference:
Chip and SPIN; The switch to Chip and PIN may be for the benefit of banks rather than consumers, suggests Gervase Markham
http://business.timesonline.co.uk/article/0,,9075-2247493,00.html


and now comes this more recent article that has been picked up in several places:
UK Banks Consider Making Customers Liable for Online Fraud
http://www.ecommercetimes.com/story/LW3h8x0sQjgTOW/UK-Banks-Consider-Making-Customers-Liable-for-Online-Fraud.xhtml
UK Banks Consider Making Customers Liable for Online Fraud
http://www.crmbuyer.com/story/LW3g1ZYzCnnQ88/UK-Banks-Consider-Making-Customers-Liable-for-Online-Fraud.xhtml
UK Banks Consider Making Customers Liable for Online Fraud
http://www.technewsworld.com/story/51732.html


and this article
Consumer groups, banks battle about components of ID theft legislation
http://www.daytondailynews.com/business/content/business/daily/071606identity.html
Consumer groups, banks battle over ID theft legislation
http://www.oxfordpress.com/business/content/shared/news/stories/IDENTITY_THEFT16_COX_W1718.html


DDA cards may address the UK Chip&Pin woes

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: DDA cards may address the UK Chip&Pin woes
Date: July 16, 2006 09:31 AM
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000776.html

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

which imply that chip&pin 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 any yes card, mitm-attacks)

misc. past posts mentioning possible yes card, mitm-attacks:
https://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
https://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://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
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: 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.
Date: July 22, 2006 09:01 PM
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000755.html

"I do know that the ISP is not the same name as my domain name, dammit!!!!" This is an old debate; in the PKI world, they do not subscribe to the theory that the user knows more than any CA

...

actually I think that the PKI position is that nobody knows more than the CA about anything ... otherwise it would start to erode the idea that the CA should be paid for knowing more than everybody else. misc. past certificate-less postings
https://www.garlic.com/~lynn/subpubkey.html#certless

and ...
Nobody can compete with SSH

...

earlier ssh related thread
http://financialcryptography.com/mt/archives/000769.html

and even more topic drift in that thread mentioning IETF RFC on using DNS to publish SSH key fingerprints
https://www.garlic.com/~lynn/aadsm24.htm#24

i.e. the equivalent feature/function provided by PKI CA digital certificates ... how do i know that a supplied public key really belongs to the associated entity (and not an attacker)

and pointing out that I've made large number of postings in the past that something similar could be done for an SSL implementation (relying directly on the domain name infrastructure rather than having a PKI certificate authority inserting themselves in the middle).

lots of past posts pointing at that PKI CAs have to rely on the domain name infrastructure as to the true domain name owner ... and potentially if public keys were registered directly with the domain name infrastructure ... then the PKI CA middlemen could be totally eliminated.

I've frequently raised the catch-22 issue where the PKI domain name certification industry has suggested direct public key registration with the domain name infrastructure as part of improving the reliability and integrity of PKI CA certified information (in PKI CA digital certificates). However this could also be viewed as sowing the seeds of their own demise.

a few of the past catch-22 posts:
https://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
https://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
https://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm18.htm#43 SSL/TLS passive sniffing
https://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
https://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
https://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
https://www.garlic.com/~lynn/aadsm22.htm#0 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/aadsm23.htm#47 Status of opportunistic encryption
https://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
https://www.garlic.com/~lynn/2006d.html#29 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
https://www.garlic.com/~lynn/2006h.html#27 confidence in CA
https://www.garlic.com/~lynn/2006h.html#34 The Pankian Metaphor

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: 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.
Date: July 22, 2006 09:43 PM
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000755.html

sorry, couldn't resist

IBM Virtualization Achieves One of Industry's Highest Security Levels, Says Government Evaluator
http://www.marketwire.com/mw/release_html_b1?release_id=146570

the more things change, the more things stay the same, some reference to doing this same stuff nearly 40 years ago (building secure systems)
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

recent posts building secure systems going back only 20-30 years
https://www.garlic.com/~lynn/2006n.html#44
https://www.garlic.com/~lynn/2006n.html#47

More Brittle Security -- Agriculture

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: More Brittle Security -- Agriculture
Date: July 23, 2006 09:30 AM
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000788.html

can you say naked transactions? .... leaving a bunch of valuable stuff laying around fairly unprotected.

in a past life, there was a situation involving legal action over theft of trade secrets ... claiming several billion dollars damage. the judge made some ruling that something worth several billion dollars is an attractive, irresistible target ... and therefor it was necessary to demonstrate that there were protection processes and countermeasures in place that were proportional to the value.

i've commented in the past that this is somewhat akin to the swimming pool as an attractive nuisance, owners of swimming pools can be held liable if tresspasers drawn in their pool unless they can show they've fortified the area (and most people can't resist stealing something worth a couple billion if it is just left laying around).

this is somewhat the security proportional to risk theme
https://www.garlic.com/~lynn/2001h.html#61

and of course the naked payments/transaction threads
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#21 Use of TPM chip for RNG?
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#37 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
https://www.garlic.com/~lynn/aadsm24.htm#43 DDA cards may address the UK Chip&Pin woes

More Brittle Security -- Agriculture

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: More Brittle Security -- Agriculture
Date: July 23, 2006 11:33 AM
Blog: Financial Cryptography
and related to this thread drift:
https://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture

'House to Vote on Bill to Weaken Current Identity Theft Protections...'
http://releases.usnewswire.com/GetRelease.asp?id=69606

Groups Slam Data Breach Notification Bill
http://www.internetnews.com/bus-news/article.php/3592416

The Financial Data Protection Act of 2005 Introduced; Would Require Tighter Store Level Security
http://www.rtoonline.com/Content/article/Oct05/ConsumerIdentityTheftLegislation100705.asp

Specter, Leahy Introduce Personal Data Privacy And Security Act Of 2005
http://leahy.senate.gov/press/200506/062905a.html

FINANCIAL INFORMATION PRIVACY PROTECTION ACT
http://www.ncoil.org/other/financial_information_privacy_pr.htm

more on FBI plans new Net-tapping push

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: more on FBI plans new Net-tapping push
Date: Sun, 23 Jul 2006 12:51:48 -0600
At 11:56 AM 7/10/06, you wrote:
There's a big problem with attacking strong crypto. Internet e- commerce *depends* on it. If people discover when they make purchases at "secure" websites, that their credit card and other ID info is getting regularly grabbed in transit and decrypted on the fly, e- commerce will come to a sudden end.

actually the long-term before, during, and presumably after, internet is that the majority of information is being grabbed at-rest ... not in-flight. some study claims that something like 70percent of account fraud involves insiders.

a fundamental problem is that existing transaction infrastructure involves account numbers which are required in dozens of business process ... while at the same time, knowledge of the account number can be sufficient to enable fraudulent transactions. this is my oft repeated theme that the planet could be buried under miles of data hiding encryption and it still wouldn't prevent information leakage that enables fraud aka diametrically opposing requirements for account and transaction information; generally & widely available for business processes and at the same time kept securely confidential and can never be divulged.

old posts about doing consulting with this small client/server startup that wanted to do payment transactions on their server
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

we did the original payment gateway with them. they had this technology called SSL and the results is now frequently referred to as e-commerce. as an aside, i've also periodically referred to that payment gateway as being the original soa ... which drew heavily on having previously done ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp
and having come up with 3-tier architecture
https://www.garlic.com/~lynn/subnetwork.html#3tier

however, shortly afterwards we were in the x9a10 financial standards working group which had been given the requirement to preserve the integrity of the financial infrastructure for ALL retail payments. the result was x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

one of the things done in the x9.59 financial standard was change the paradigm and eliminate knowledge of (x9.59) account numbers as a vulnerability. strong authentication was required for all transactions using (x9.59) account numbers ... and therefor it was no longer necessary to hide the account numbers (and other transaction details) to preserve the integrity of the financial infrastructure for ALL retail payments (i.e. strong authentication w/o encryption preserves the integrity of the financial infrastructure for ALL retail payments ... whether the transaction is in-flight or at-rest).

misc related recent posts vis-a-vis security breaches, data breaches and knowledge of previous transactions being an account fraud vulnerability
https://www.garlic.com/~lynn/2006n.html#40 Identity Management Best Practices
https://www.garlic.com/~lynn/aadsm24.htm#46 Brittle Security
https://www.garlic.com/~lynn/aadsm24.htm#47 Brittle Security

There are separate issues with the current way that SSL is commonly used. The original SSL process for e-commerce was that it was to verify that the webserver you thot you were talking to, was in fact, the webserver you were talking to. That met that it validated that the URL you provided to the browser corresponded to the URL provided in the webserver's SSL digital certificate. Very quickly merchants found that SSL was cutting their thruput by something like 80-90% so they turned off SSL and only used it for the checkout/purchase portion. You now click on a "checkout" button at some website ... which now results in the URL provided by the webservers checkout button being crosschecked against the URL in the webservers provided digital certificate (aka it would take a really dumb crook to have the URL in the provided digital certificate not match the URL that they generated from a checkout button). As a result, a major security provision of the whole SSL infrastructure has pretty much been negated/compromised.

a similar analysis was done more than a year ago about other variations of webserver authentication operations ... recent comment:
https://www.garlic.com/~lynn/aadsm24.htm#33 Threatwatch
https://www.garlic.com/~lynn/aadsm24.htm#34 Phishers Defeat 2-Factor Auth

Crypto to defend chip IP: snake oil or good idea?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Crypto to defend chip IP: snake oil or good idea?
Date: Tue, 25 Jul 2006 15:49:11 -0600
To: Perry E. Metzger <perry@xxxxxxxx>
CC: cryptography@xxxxxxxx
References: <873bcp21bz.fsf@xxxxxxxx>
Perry E. Metzger wrote:
EE Times is carrying the following story:
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=190900759

It is about attempts to use cryptography to protect chip designs from untrustworthy fabrication facilities, including a technology from Certicom.

Unlike ordinary DRM, which I think can largely work in so far as it merely provides a (low) barrier to stop otherwise honest people from copying something they find inexpensive in the first place, it seems to me that efforts like this are doomed.

It is one thing if you're just trying to keep most people honest about something that doesn't cost much money, and another if you're trying to protect something worth millions of dollars from people with extremely sophisticated reverse engineering equipment. In particular, people who operate fabs are also in possession of exquisitely good equipment for analyzing the chips they've made so they can figure out process problems, and the "key injection" equipment Certicom is making could easily be suborned as well.


disclaimer ... although our names are on the patents ... they are assigned and we currently have no association with the patents or the company that owns the patents (the most recent allowed happens to be out in todays regular tuesday update):
https://www.garlic.com/~lynn/x959.html#aads

which basically puts keygen and minimal number of other circuits in the chip. keygen is executed as part of standard initial power-on/test ... before the chips are sliced and diced from the wafer. the public key is exported along with the other power-on/test data and is retained along with the other standard chip inventory information. no increase in chip processing and/or handling.

some past posts mentioning the process:
https://www.garlic.com/~lynn/2003i.html#29 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003j.html#30 How is a smartcard created?
https://www.garlic.com/~lynn/2003o.html#63 Dumbest optimization ever?
https://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
https://www.garlic.com/~lynn/aadsm20.htm#21 Qualified Certificate Request
https://www.garlic.com/~lynn/aadsm24.htm#29 DDA cards may address the UK Chip&Pin woes

basically it adds dynamic information to static (data) serial number (which can be easily skimmed and replayed) w/o adding any additional handling or processing steps (other than incorporating the additional circuits into the base chip design). not necessarily defending chip IP ... just slight addition to existing chip serial number convention processing ... somewhat dating back to part of the original aads chip strawman concepts
https://www.garlic.com/~lynn/x959.html#aads

somewhat related among them:
6,892,302: Incorporating security certificate during manufacture of device generating digital signatures
6,915,430: Reliably identifying information of device generating digital signatures
6,978,369: person-centric account-based digital signature system
6,983,368: Linking public key of device to information during manufacture
7,047,414: Managing database for reliably identifying information of device generating digital signatures

DDA cards may address the UK Chip&Pin woes

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 25, 2006 06:44 PM
Subject: DDA cards may address the UK Chip&Pin woes
Blog: Financial Cryptography
recent update related to previous comments on AADS chip strawman in this thread:
https://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:
https://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#28 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#29 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes

old reference to it be countermeasure to gray market and/or counterfeit copy chip:
https://www.garlic.com/~lynn/aepay3.htm#x959risk4 Risk Management in AA / draft X9.598

Crypto to defend chip IP: snake oil or good idea?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Crypto to defend chip IP: snake oil or good idea?
Date: Tue, 25 Jul 2006 18:50:22 -0600
To: Perry E. Metzger <perry@xxxxxxxx>
CC: cryptography@xxxxxxxx
Crypto model plugs leaky fabs
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=190900759

from above ...

San Jose, Calif. -- Security specialist Certicom Corp. this week will roll out a hardware-based approach to protecting silicon intellectual property using its elliptic-curve cryptography (ECC) technology and a 20,000-gate embedded core.

... snip ...

in 1999, there some estimate as much as 40,000-gate embedded core ... but that also included the key-gen and public key export as part of initial power-on/test.

ref:
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#50 DDA cards may address the UK Chip&Pin woes

Crypto to defend chip IP: snake oil or good idea?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Crypto to defend chip IP: snake oil or good idea?
Date: Wed, 26 Jul 2006 08:07:22 -0600
To: Perry E. Metzger <perry@xxxxxxxx>
CC: cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#50 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/2006n.html#36 The very first text editor
https://www.garlic.com/~lynn/2006n.html#57 The very first text editor

a little more background ....

the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments .... that included ALL ... aka, internet, non-internet, point-of-sale, credit, debit, stored-value, ... ALL. the result was x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

which reguired strong authentication of every transaction. part of this was business rule that account numbers used in x9.59 transactions couldn't be used in non (strongly) authenticated transactions. this went a long way to closing the security breaches and data breaches associated with account fraud (i.e. it was no longer necessary to encrypt and hide account numbers and transactions since any "skimmed" information couldn't be used in replay attacks). a recent post
https://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push

however, it did mean that some sort of chip technology was going to be needed for at least point-of-sale operation. there was some grappling at the time (mid-90s) with the cost of high integrity chips. we approached it from the standpoint of KISS ... making a semi-facetious statement that we were going to take $500 mil-spec technology, and aggresively cost-reduce it by better than two orders of magnitude while at the same time improving the integrity. The other comparison was that it was going to be significantly more secure than any existing "DDA" technology while costing much less than any "SDA" technology.

so the AADS chip strawman was looking at such aggresive KISS and cost reduction
https://www.garlic.com/~lynn/x959.html#aads

so part of it was that institutions were also claiming that each had to issue their own chip token ... since it was only by taking possesion of the chip at the fab and maintaining strong security thru-out all its personalization and delivery to the individual, that they could guarantee they weren't dealing with copy chips (or chips that failed to meet the institutions requirement for any number of reasons). this possibly implied that if hardware token paradigm ever took off, individuals would be issued (at least) scores of hardware tokens (i.e. somewhat analogous to the current password management nightmare).

so the opportunity was could a person choose to present their own hardware token for institutional use (and what would it require for an institution to accept a foreign token) ... rather than have to be issued a unique token by each institution. this got back to how could the institution know that it wasn't a copy chip (or other issues that would preclude the institution accepting the token)

so the process was to do key-gen and export as part of initial power-on/test (at the fab). this met that no additional business processes were needed. the exported public key went into the standard fab inventory/manifest. when a person presented a hardware token, the institution could take the public key and validate a digital signature from the token and then request that the public key and hardware integrity characteristics be corroborated by the original fab manifest for the chip.

the idea was to enable transition from institution-centric token paradigm to a person-centric token paradigm. instead of a person being weighed down with a hundred or more tokens, they could get by with one or possibly a very small number. this could reduce the costs of any pervasive token-based infrastructure by a hundred (by reducing the number of required tokens by a hundred). since it was no longer necessary to have huge amounts of personalization and security between the fab and delivery to the individual ... up to another factor in one hundred in processing costs could be eliminated (per token).

a combination of possibly a factor of one hundred times reduction in the number of required tokens plus a possible reduction of one hundred times in per token processing costs ... could represent an overall factor of ten thousand times reduction in infrastructure costs for a pervasive hardware token deployment (i.e. one hundred times one hundred).

sometime in the late 1999 or early 2000 time-frame ... if the AADS chip strawman scenario could address the hardware token copy chip opportunity, then it concievably could also be used to address the general copy chip opportunity.

this is were the initial estimate came from for being able to do a general chip core for around 40,000 gates ... and possibly a complete secure hardware token using total custom chip design for around 100,000 gates.

I had raised the subject about dealing with copy chips during my talk at the assurance session in the TPM track at the spring 2001 Intel Developers Forum

misc. past posts mentioning person-centric
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
https://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
https://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005m.html#37 public key authentication
https://www.garlic.com/~lynn/2005p.html#6 Innovative password security
https://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
https://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
https://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"

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

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: 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.
Date: July 27, 2006 10:42 AM
Blog: Financial Cryptography
another kind of digital signature certificate-less operation
https://www.garlic.com/~lynn/subpubkey.html#certless

where characteristics of each chip is recorded in the fab manufacturing standard manifest (countermeasure to copy chips):
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?

basically extending chip manufacturing serial number with digital signatures and private key that is never divulged ... as countermeasure to things like copy chips (akin to copy/counterfeit watches, copy/counterfeit DVDs, copy/counterfeit jeans, etc).

so the chip claims to be an original, provides a digital signature and a public key as evidence supporting the assertion ... and then the serial number and public key can be used to lookup the chip in the fab's manifest and obtain the associated information (like integrity characteristics of the chip). Trivial information is binary condition whether the chip is original (or possible copy/counterfeit).

Standard serial number is static and vulnerable to skimming and replay attack. Public key and digital signature is dynamic and countermeasure to simple impersonation replay attack.

Another variation is public key for kerberos,
https://www.garlic.com/~lynn/subpubkey.html#kerberos

the original PK-init draft for kerberos just specified certificate-less public key operation ... where a public key was registered for a userid in lieu of registering a password. under various pressures, the kerberos pk-init draft was extended to include PKI certificate-mode of operation.

now, if the certificate was sufficient, by itself ... then anybody with a valid certificate could connect to every system (that supported kerberos authentication ... like all the windows systems).

however, instead ... a PKI kerberos infrastructures now will have redundent and duplicated administrative infrastructures ... one for the registration and issuing of a digital certificate and one for registration and specification of allowed userids .... along with matching a digital certificate to userids .... compared to the certificate-less pk-init which simply added public key registration (in lieue of password) to the existing, single kerberos administration infrastructure.

so i typically want to register my list of friends (or other entities with specific characteristics meaningful to me) ... and I could do it by having a local repository (various kinds of address or phone book) where i register their public key (and other meaningful personal context information)

Any sort of generic digital certificate may aid in validating that whoever some entity claims to be, was able to provide some proof to a certification authority that appeared to substantiate a similar claim. However, that would fail to provide a local context ... i.e. just because somebody is authenticated within the context of a generic digital certificate might still fail to indicate whether they should be allowed to enter my house, drive my car, or use my computer.

previous post in this thread:
https://www.garlic.com/~lynn/aadsm24.htm#44

past posts mentioning copy chips and countermeasures (not only determining whether original or copy chip, but also integrity characteristics of an original)
https://www.garlic.com/~lynn/aadsm3.htm#cstech12 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature
https://www.garlic.com/~lynn/aepay3.htm#x959risk4 Risk Management in AA / draft X9.59
https://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation

AADS Postings and Posting Index,
next, previous - home