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
Refed: **, - **, - **, - **
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
- something you have
- something you know
- something you are
there is implicit assumption that the point of having different
authentication factors is that they have independent vulnerabilities.
cards represent something you have authentication. pins represent
something you know authentication. pins were an indepentent
authentication as countermeasure to early 70s lost/stolen (static
data, magstripe) cards (modulo the supposedly 30percent of the
population that write their pin on their cards ... 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