OK, the requirement for X9.59 was to "insure the integrity of the financial
infrastructure for all electronic retail payments" ... that is ALL as in
ALL. So there was a demo of X9.59 at 1999 BAI in webstore configuration:
http://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI
(world-0side retail banking) show
so lets say there are paranoid people that don't trust the merchant
terminal .... then I assert the operation of X9.59 with cellphone/PDA with
the cellphone/PDA using BLUETOOTH or WI-FI (or other wireless interface) to
the merchant terminal ... has exactly the same process steps as a personal
computer at home using the Internet (aka personal device to merchant,
merchant device to financial infrastructure).
the two issues with regard to merchant terminal have been covered in past
posts 1) is what you see, what you sign and 2) skimming any entered "what
you know" or "what you are" authentication information. This is also
referenced is some number of FINREAD relateds previous posts (appended).
I wasn't referring to whether or not banks were used as trusted providers
... the refernece and the accompanying description was about the actual
flow of the transaction and the actual flow of the authentication and
integrity information.
Of course banks can be trusted providers
The original statement (and subsequent statements) were with respect to
security protcool analysis and elementary security guidelines.
The original statement (and subsequent statements) was that (all other
things being equal), that if the process isn't an integral end-to-end
operation then it is
less KISS
more complex
less secure
more prone to failures
more prone to fraud
The above assertions about elementary security principles are independent
of whether banks as trusted providers are involved or not. To that extent,
comments about banks as trusted providers are somewhat orthogonal and
obfuscation with respect to elementary security principles.
minor reference some EMV stuff
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
past threads (that you participated in) which involved FINREAD
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative
to PKI?
http://www.garlic.com/~lynn/aadsm15.htm#38 FAQ: e-Signatures and Payments
http://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication
white paper
http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication
white paper
other related threads mentioning FINREAD:
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet,
here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and
their users [was Re: Cryptogram: Palladium Only for DRM]
http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has
conspicuously failed to fix
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip
Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip
Market
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security
requested
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security
requested
http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet
Banking
http://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet
Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
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#26 Help! Good protocol for national
ID card?
http://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
http://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN
Encryption security, possibly
http://www.garlic.com/~lynn/2003h.html#29 application of unique signature
http://www.garlic.com/~lynn/2003j.html#25 Idea for secure login
http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd
authentication?
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
[EMAIL PROTECTED] on 11/13/2003 12:45 am wrote:
Sure, X9.59 or EMV is problably just fine at least as long as you trust the
terminal where you insert your chip-card. However, on the Internet
using a web-store X9.59 end-to-end is anything but ready for prime-time.
And the interesting thing is that the Internet approach (3D) MAY one day
find its way down to the brick-and-mortar shop as it makes no sense to
long-term have multiple infrastructures for payments.
I guess we can agree on this last line at least? And then agree on that
it will be "the battle of the payment systems". Or has somebody already
won? I don't think so.
>I would assert that any change that you would make to the above
>description makes it less KISS, more complex, and less secure.
To me using banks as trusted providers, authenticators and archievers
seems like KISS as this is what banks have been doing since day #1.
/anders
