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
http://www.garlic.com/~lynn/2006l.html#32
http://www.garlic.com/~lynn/aadsm23.htm#55
http://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
http://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
http://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:
http://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
part of the aads chip strawman
http://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:
http://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.
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:
http://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):
http://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
http://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).
http://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 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
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
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
http://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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
which we also assert can be considered the first SOA implementation
http://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.
http://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.
http://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).
http://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
http://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
http://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):
http://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#0 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
http://www.garlic.com/~lynn/aadsm24.htm#3 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/2006l.html#27 Google Architecture
http://www.garlic.com/~lynn/2006l.html#32 Google Architecture
http://www.garlic.com/~lynn/2006l.html#33 Google Architecture
http://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)
http://www.garlic.com/~lynn/aadsm15.htm#21 Simple SSL/TLS - Some Questions
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"
http://www.garlic.com/~lynn/aadsm23.htm#54 Status of SRP
http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006h.html#26 Security
http://www.garlic.com/~lynn/2006k.html#5 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
http://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
http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#strawm2 AADS Strawman
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech9 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech10 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm9.htm#carnivore2 Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm10.htm#keygen Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm10.htm#boyd AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE
http://www.garlic.com/~lynn/aadsm11.htm#1 Basic credit-card payment question
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#46 Giuliani: ID cards won't curb freedoms
http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
http://www.garlic.com/~lynn/aadsm13.htm#18 A challenge
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm16.htm#10 Difference between TCPA-Hardware and a smart card (was: example:secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm16.htm#12 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#0 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)<
http://www.garlic.com/~lynn/aadsm19.htm#38 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#21 Qualified Certificate Request
http://www.garlic.com/~lynn/aadsm21.htm#11 Payment Tokens
http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#41 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
http://www.garlic.com/~lynn/aadsm23.htm#53 Status of SRP
http://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
http://www.garlic.com/~lynn/99.html#170 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#189 Internet Credit Card Security
http://www.garlic.com/~lynn/2000c.html#2 Financial Stnadards Work group?
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#5 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001n.html#94 Secret Key Infrastructure plug compatible with PKI
http://www.garlic.com/~lynn/2002.html#39 Buffer overflow
http://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002g.html#38 Why is DSA so complicated?
http://www.garlic.com/~lynn/2002h.html#9 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002h.html#71 history of CMS
http://www.garlic.com/~lynn/2002h.html#84 history of CMS
http://www.garlic.com/~lynn/2002i.html#71 TCPA
http://www.garlic.com/~lynn/2002j.html#55 AADS, ECDSA, and even some TCPA
http://www.garlic.com/~lynn/2002j.html#71 history of CMS
http://www.garlic.com/~lynn/2002l.html#4 why is Kerberos better than this simpler replacement
http://www.garlic.com/~lynn/2002m.html#14 fingerprint authentication
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
http://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#18 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2003d.html#18 Efficent Digital Signature Schemes
http://www.garlic.com/~lynn/2003e.html#57 Security in RADIUS (RFC2865)
http://www.garlic.com/~lynn/2003g.html#70 Simple resource protection with public keys
http://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003i.html#29 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003j.html#30 How is a smartcard created?
http://www.garlic.com/~lynn/2003l.html#61 Can you use ECC to produce digital signatures? It doesn't see
http://www.garlic.com/~lynn/2003l.html#64 Can you use ECC to produce digital signatures? It doesn't see
http://www.garlic.com/~lynn/2003m.html#5 Cryptoengines with usage accounting
http://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
http://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
http://www.garlic.com/~lynn/2005q.html#11 Securing Private Key
http://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
http://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:
http://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
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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
http://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#28 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#18 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm23.htm#54 Status of SRP
http://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
http://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card Protocol on Web Site
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004m.html#9 REVIEW: "Biometrics for Network Security", Paul Reid
http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005m.html#53 Barcode Email
http://www.garlic.com/~lynn/2005u.html#3 PGP Lame question
http://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
http://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:
https://financialcryptography.com/mt/archives/000749.html
and
https://financialcryptography.com/mt/archives/000745.html
https://financialcryptography.com/mt/archives/000744.html
https://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.
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
and the subsequent aads chip strawman work
http://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:
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
http://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
http://www.garlic.com/~lynn/aadsm18.htm#20 RPOW - Reusable Proofs of Work
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naïve use of TLS and/or tokens
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
http://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
http://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#0 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
http://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#35 A quote from Crypto-Gram
http://www.garlic.com/~lynn/2004j.html#39 Methods of payment
http://www.garlic.com/~lynn/2004j.html#44 Methods of payment
http://www.garlic.com/~lynn/2005u.html#13 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006k.html#1 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006l.html#27 Google Architecture
http://www.garlic.com/~lynn/2006l.html#32 Google Architecture
http://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:
https://financialcryptography.com/mt/archives/000752.html
a little cross-over from the naked transactions and chip&pin fraud
series ....
http://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? ...
http://www.garlic.com/~lynn/aadsm24.htm#1
http://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
http://www.garlic.com/~lynn/2006l.html#32
http://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)
http://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
http://www.garlic.com/~lynn/aadsm23.htm#56
http://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) ...
http://www.garlic.com/~lynn/aadsm23.htm#56
http://www.garlic.com/~lynn/subpubkey.html#radius
http://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)
http://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
http://www.garlic.com/~lynn/99.html#217
http://www.garlic.com/~lynn/99.html#224
and NACHA was gearing up to do the AADS internet trials about the same
time
http://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.
http://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
http://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
http://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:
https://financialcryptography.com/mt/archives/000749.html
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://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.
http://www.garlic.com/~lynn/x959.html#x959
http://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.
http://www.garlic.com/~lynn/aadsm24.htm#5
http://www.garlic.com/~lynn/aadsm24.htm#6
http://www.garlic.com/~lynn/aadsm24.htm#7
http://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:
https://financialcryptography.com/mt/archives/000757.html
https://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)
http://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.
http://www.garlic.com/~lynn/aadsm24.htm#8
recent posts in this thread:
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://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
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:
https://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
http://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
http://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:
https://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)
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
recent posts mentiong yes card:
http://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
http://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#0 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
Apple to help Microsoft with "security neutrality"?
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:
https://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
http://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
consistancy, 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 rewritting 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"?
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:
http://www.garlic.com/~lynn/aadsm24.htm#15 Apple to help Microsoft with "security neutrality"?
at conference last week ... mentioned in earlier thread
http://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:
http://www.garlic.com/~lynn/2006k.html#37 PDP-1
http://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:
http://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
http://www.garlic.com/~lynn/subboyd.html#boyd
other URLs from around the web mentioning Boyd, OODA-loops and/or
other Boyd related subjects
http://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:
https://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
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
Use of TPM chip for RNG?
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Use of TPM chip for RNG?
Date: Mon, 03 Jul 2006 10:41:05 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx, hal@xxxxxxxx
Peter Gutmann wrote:
You have to be pretty careful here. Most of the TPM chips are just
rebadged smart cards, and the RNGs on those are often rather
dubious. A standard technique is to repeatedly encrypt some stored
seed with an onboard block cipher (e.g. DES) as your "RNG". Beyond
the obvious attacks (DES as a PRNG isn't particularly strong) there
are the usual paranoia concerns (how do we know the manufacturer
doesn't keep a log of the seed and key?) and stupidity concerns (all
devices use the same hardwired key, which some manufacturers have
done in the past). There are also active attacks possible,
e.g. request values from the device until the EEPROM locks up, after
which you get constant "random" values. Finally, some devices have
badly-designed challenge-response protocols that give you an
infinite amount of RNG output to analyse, as well as helping cycle
the RNG to lockup.
One of the issues for a long time, for that class of chips, is whether
they perform on-chip key-gen and/or whether DSA (and/or ECDSA) were in
use ... processes where reasonable good RNG are integral to the
operation.
at one point there was tests for a collection of chips in that class
that performed 65k power-cycle/RNG operations and found that something
like 30 percent of the numbers were repeated.
however, at least some of the TPM chips have RNGs that have some level
of certification (although you might have to do some investigation to
find out what specific chip is being used for specific TPM).
On Leadership - tech teams and the RTFM factor
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: On Leadership - tech teams and the RTFM factor
Date: July 3, 2006 03:34 PM
Blog: Financial Cryptography
re:
http://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
http://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:
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-AND-Pin Security Flaw
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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
http://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:
http://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
http://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#42 Article on passwords in Wired News
http://www.garlic.com/~lynn/aadsm18.htm#20 RPOW - Reusable Proofs of Work
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#23 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#29 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#34 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#39 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm22.htm#47 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naïve use of TLS and/or tokens
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
http://www.garlic.com/~lynn/aadsm23.htm#20 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#27 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
http://www.garlic.com/~lynn/aadsm23.htm#55 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/2003o.html#37 Security of Oyster Cards
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#35 A quote from Crypto-Gram
http://www.garlic.com/~lynn/2004j.html#39 Methods of payment
http://www.garlic.com/~lynn/2004j.html#44 Methods of payment
http://www.garlic.com/~lynn/2005u.html#13 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2006d.html#31 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?
http://www.garlic.com/~lynn/2006k.html#0 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006l.html#27 Google Architecture
http://www.garlic.com/~lynn/2006l.html#32 Google Architecture
http://www.garlic.com/~lynn/2006l.html#33 Google Architecture
http://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
http://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt
http://www.garlic.com/~lynn/aadsm24.htm#0 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#6 Securely handling credit card transactions earns Blackboard kudos
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
http://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
http://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
http://www.garlic.com/~lynn/x959.html#aads
around '98 ...
http://www.garlic.com/~lynn/aadsm2.htm#strawm1
in part, for supporting x9.59 transactions ...
http://www.garlic.com/~lynn/x959.html#x959
http://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:
https://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
http://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
http://www.garlic.com/~lynn/subpubkey.html#sslcert
and various certificate-less digital signature postings
http://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
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
see last paragraph on yes cards in the following
http://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:
https://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
http://www.garlic.com/~lynn/aadsm24.htm#23 Use of TPM chip for RNG?
one of the issues for X9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
and "signing" the transaction directly and avoiding naked
transactions involved various kinds of MITM-attacks
http://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
http://www.garlic.com/~lynn/aadsm23.htm#19 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#34 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#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:
https://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).
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
the upgrade to dynamic data possibly has terminal doing some sort of
random data challenge/response, which the card now has to digitally
sign (using private key) ... which could be verified using some
supplied digital certificate (carried over from SDA) ... and any
random data challenge/response is countermeasure to replay attacks
(found in static data scenarios)
however, as looked at in some of the x9.59 work
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
in any card authentication (leaving the transaction naked, as opposed
to transaction authentication), there still might be various kinds of
MITM-attacks ... possibly similar to the yes card (replay attack)
scenarios ... possibly using a pair of cards ... aka a yes card
MITM-attack scenario
http://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
French Banks Upgrade Security Of EMV Cards
http://www.cardtechnology.com/article.html?id=2006070569TSQ1WX
from above:
The card organization says its tests earlier this year show the extra
time it takes for cards to create the unique signatures is
"imperceptible" to cardholders. At the same time, CB says, the
more-powerful smart card chips needed to generate the signatures have
come down in price, so that DDA cards cost about the same as the
less-secure cards in France.
... snip ...
This was something that we were looking at in '98 for the AADS chip strawman
http://www.garlic.com/~lynn/x959.html#aads
being able to have a chip be able to do a signature within the
transit, contactless timing and power requirements ... be more secure
than any DDA card and cost less than any SDA card ... somewhat
referred to in this recent post
http://www.garlic.com/~lynn/aadsm24.htm#23 Use of TPM chip for RNG?
a few past references to aads chip strawman and being able to meet
both powering and timing requirements in a transit contactless
operation
http://www.garlic.com/~lynn/aadsm22.htm#40 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#56 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
http://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
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:
https://financialcryptography.com/mt/archives/000776.html
http://www.garlic.com/~lynn/aadsm24.htm#28 DDA cards may address the UK Chip&Pin woes
when we were were looking at the issues in 98 for the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads
somewhat as part of supporting x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
http://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.
http://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.
http://www.garlic.com/~lynn/aadsm24.htm#23 Use of TPM chip for RNG?
So a big part of poor performance with some of the other digital
signature technologies is using really big numbers (vis-a-vis ec/dsa)
... being stuck with 16bit math operations mean that you have to
iterate a large number of times to approximate operations using
really, really large numbers.
So part of the historical approach to somewhat reducing the time (for
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 comingly 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,
http://www.garlic.com/~lynn/x959.html#aads
and
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#28 DDA cards may address the UK Chip&Pin woes
the ec keygen (as well as ec/dsa) was 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:
https://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.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
the aads chips strawman (from '98) was then to identify the technology
components that would provide the highest possible security at the
lowest possible deployed cost
http://www.garlic.com/~lynn/x959.html#aads
while most of the other protocols and specifications being done in the
90s only considered a very small part of the total threat model, x9.59
looked at providing end-to-end coverage ... something that has been
discussed recently in the naked transaction threads. for x9.59
transactions in-flight (i.e. like on the internet), they could be
done "in the clear", w/o affecting the integrity of the financial
infrastructure. for x9.59 transactions at-rest (i.e. in various
databases or transaction logs), there could be all sort of security
and data breaches w/o affecting the integrity of the financial
infrastructure.
the yes card is an attack on the terminal and infrastructure
business rules (not a card attack). once the card has been
authenticated, the terminal/card protocol has the terminal asking the
card: a) was the entered PIN, correct, b) should the transaction be
done offline, and c) is the transaction within the account limit. old
yes card article from 2002 about earlier yes card attacks (and
mentioning details for building yes card were readily available on
the internet)
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
a yes card, replay attack has card static authentication data
(possibly even using similar technology used for magnetic strip static
data) being skimmed and loaded into a counterfeit yes card. a
possible yes card, MITM-attack has a fraudulent yes card paired
with a valid card, where the yes card passes the authentication to
some valid card, and then handles all subsequent interactions.
misc. MITM-attack postings
http://www.garlic.com/~lynn/subintegrity.html#mitm
misc. recent postings related to "naked transaction" thread
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
http://www.garli