RE: FINREAD was. Authentication white paper
scott guthery <[EMAIL PROTECTED]> on 6/8/2003 4:29 pm wrote: Yep, everybody's going to instantly stop doing business on the Internet until they can rent a $150 card reader from a bank that uses the device to block transactions with businesses that won't pay it PIN handling fee and use their network and clearing services. there seems to be a little exaggeration. none of the finread terminals i've seen come anywhere close to $150/terminal. also, in most cases, the issue is security/integrity proportional to the risk. the specific example quoted in the original posting was a terminal for secure ACH transactions, not something that you currently find being done on the internet. the original posting also gave the example of single-factor "something you have" authentication (as in transit, not requiring two-factor authentication) aka internet-payments doesn't necessarily limit things to consideration for only existing consumer/merchant e-commerce operations. the existing consumer internet based infrastructure is heavily based on the original work that my wife and I were involved with for payment gateway with a small client/server startup (originally in menlo park, subsequently moved to mountain view and since been bought by AOL): http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 the current, existing infrastructure is oriented to shared-secrets and single-factor "something you know" authentication that has been heavily exploited for fraud. One case would be to look at the various cost/benefit trade-offs for improving the existing fraud situation (past postings to these mailing lists have it at 30-50 times higher than similar transactions not done on the internet). Also the existing scenario makes little or no attempt at non-repudiation it is assumed that the consumer can readily and easily repudiate all internet-originated transactions. Non-repudiation may not be a requirement for internet transactions; something you have and something you know, two-factor authentication may be sufficient. Presumably, the PIN handling fee refers to the transition from shared-secret based infrastructure (aka PIN) to non-shared-secret digital signature based infrastructure ... where the public key is registered in lieu of the PIN and a digital signature authentication is done in lieu of a PIN comparison. A possible X9.59 cost/benefit then potentially is the possible significantly reduced fraud-related fees to the merchant being significantly larger than the PIN (or digital signature) handling fee. Somewhat as a total aside in the case of X9.59 standard, the protocol specification is the same regardless of whether or not a token is used. Any requirement for a token becomes a business process assurance issue, not a protocol issue. The requirement for signing environment that supports intention also is a business process assurance issue, not a protocol issue. It is possible to use the same x9.59 protocol standard across a broad range of varying business process assurance and integrity implementations. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
RE: FINREAD was. Authentication white paper
Yep, everybody's going to instantly stop doing business
on the Internet until they can rent a $150 card reader
from a bank that uses the device to block transactions
with businesses that won't pay it PIN handling fee and
use their network and clearing services.
Has anybody seen the code that runs inside FINREAD?
I don't mean the interfaces. I mean the source code.
I'm starting to think that software that handles value
bearing traffic should be as open to inspection and
analysis as cryptographic algorithms.
Nobody (I hope) would use cryptograhy that was
shrouded in magic and "I can't tell you because of
security concerns" fog. Why isn't all value bearing
software subject to same arguments as cryptography?
You just know that what is inside FINREAD is a
software mess scrambled together with a laundry
list of everybody's favorite hidden agenda and nickle
and dime fee schedule.
IMHO, as always.
Cheers, ScottG
-Original Message-
From: Anders Rundgren [mailto:[EMAIL PROTECTED]
Sent: Sun 6/8/2003 3:54 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc:
Subject: FINREAD was. Authentication white paper
regarding the references to FINREAD I believe the vision as
represented by the following document
http://www.finread.com/pages/finread_initiatives/ec_funded_projects/02_embedded.html
has little foundation in reality. I.e. reading current "king-sized"
smart credit cards in mobile phones or PDAs seems like a rather
complex idea taking in consideration the proliferation in the
card sector.
AR
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, June 08, 2003 21:23
Subject: Authentication white paper
I'm in the process of finishing up an authentication white paper for an
international financial "best practices" security book. Much of it reflects
the various deliberations that went on in the x9a10 committee for the x9.59
standard (requirement given the x9a10 committee to preserve the integrity
of the financial infrastructure for ALL electronic retail payments; aka ALL
as in not just internet, not just point-of-sale, not just credit, not just
ACH, etc). Some specific issues related to the X9A10 committee work:
A taxonomy for security is PAIN
P ... privacy
A ... authentication
I ... identification
N ... non-repudiation
A taxonomy for authentication is 3-factor authentication.
something you have (aka hardware token)
something you know (either shared-secret or non-shared secret)
something you are (biometrics, again either shared-secret or non-shared
secret)
While x9.59 primarily deals with strong authentication for financial
transactions, the original chair (Tom Jones) of X9A10, put a lot of early
work into non-repudiation for financial transactions. This effectively took
the form of cosigning the early X9.59 work went on contemporary with
the fstc/echeck work on people authentication cosigning (and FSML encoding,
a lot of which has been folded into XML digital signature work). While
neither kind of cosigning actually show up in the x9.59 standard, the
standard was carefully written in such a way as to not preclude either form
of cosigning.
The concept behind Tom's work on consigning is synergistic with the EU
FINREAD (financial reader) standard. In the past, there had been quite a
bit of confusion generated somewhat assuming that non-repudication and
authentication could possibly be equivalent. This was possibly something of
semantic confusion with the term "digital signature" somehow taken to be
the equivalent of a human physical signature and all that it implies with
respect to intention, agreement and non-repudiation.
The FINREAD standard has a token acceptor device that is certified to
display the value of the financial transactions followed by the entry of
the hardware token PIN/Password (prior to the token performing
authentication; as well as guaranteeing the value displayed is what is sent
to the token for authentication).
The simple design of a two-factor authentication system involves a
PIN/Password that activates a hardware token performing a digital signature
for authentication. The hardware token has been certified to not perform a
signature unless the correct PIN has been entered. The exis
Re: FINREAD was. Authentication white paper
andes rundgren <[EMAIL PROTECTED]> on 6/8/2003 1:54 pm wrote: regarding the references to FINREAD I believe the vision as represented by the following document http://www.finread.com/pages/finread_initiatives/ec_funded_projects/02_embedded.html has little foundation in reality. I.e. reading current "king-sized" smart credit cards in mobile phones or PDAs seems like a rather complex idea taking in consideration the proliferation in the card sector. the press release at url http://www.asuretee.com/company/releases/030513_hagenuk.shtm from the original posting: http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper does make reference to the use of an asuretee chip http://www.asuretee.com/ makes reference to a finread compliant terminal ... as well as embedded asuretee chip for signing in terminal devices for secure ACH transactions in conjunction with: http://www.hagenukscs.com/ -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
FINREAD was. Authentication white paper
regarding the references to FINREAD I believe the vision as represented by the following document http://www.finread.com/pages/finread_initiatives/ec_funded_projects/02_embedded.html has little foundation in reality. I.e. reading current "king-sized" smart credit cards in mobile phones or PDAs seems like a rather complex idea taking in consideration the proliferation in the card sector. AR - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, June 08, 2003 21:23 Subject: Authentication white paper I'm in the process of finishing up an authentication white paper for an international financial "best practices" security book. Much of it reflects the various deliberations that went on in the x9a10 committee for the x9.59 standard (requirement given the x9a10 committee to preserve the integrity of the financial infrastructure for ALL electronic retail payments; aka ALL as in not just internet, not just point-of-sale, not just credit, not just ACH, etc). Some specific issues related to the X9A10 committee work: A taxonomy for security is PAIN P ... privacy A ... authentication I ... identification N ... non-repudiation A taxonomy for authentication is 3-factor authentication. something you have (aka hardware token) something you know (either shared-secret or non-shared secret) something you are (biometrics, again either shared-secret or non-shared secret) While x9.59 primarily deals with strong authentication for financial transactions, the original chair (Tom Jones) of X9A10, put a lot of early work into non-repudiation for financial transactions. This effectively took the form of cosigning the early X9.59 work went on contemporary with the fstc/echeck work on people authentication cosigning (and FSML encoding, a lot of which has been folded into XML digital signature work). While neither kind of cosigning actually show up in the x9.59 standard, the standard was carefully written in such a way as to not preclude either form of cosigning. The concept behind Tom's work on consigning is synergistic with the EU FINREAD (financial reader) standard. In the past, there had been quite a bit of confusion generated somewhat assuming that non-repudication and authentication could possibly be equivalent. This was possibly something of semantic confusion with the term "digital signature" somehow taken to be the equivalent of a human physical signature and all that it implies with respect to intention, agreement and non-repudiation. The FINREAD standard has a token acceptor device that is certified to display the value of the financial transactions followed by the entry of the hardware token PIN/Password (prior to the token performing authentication; as well as guaranteeing the value displayed is what is sent to the token for authentication). The simple design of a two-factor authentication system involves a PIN/Password that activates a hardware token performing a digital signature for authentication. The hardware token has been certified to not perform a signature unless the correct PIN has been entered. The existence of a digital signature then demonstrates possession of "something you have" token and implies that the correct "something you know" PIN was entered. However, just because two-factor authentication was demonstrated, it hasn't demonstrated that a person has read and agreed with something. Intention and non-repudiation becomes a process that includes some human interaction. The EU FINREAD standard certifies a token acceptor device that implements a process that provides some degree of assurance that the process for non-repudiation/intention has been met, aka the correct amount was presented on the display, followed by explicit human interaction (typing the correct PIN on the pad immediately below the display), and that the value presented to the token for signing matched what was on the display. In the case of a certified token, two-factor authentication can be inferred because the token will not have been performed w/o the correct PIN having been entered. In the case of certified FINREAD terminal, non-repudiation process can be inferred because the FINREAD terminal requires the PIN to be entered after the transaction has been displayed, and the FINREAD terminal guarantees what was sent to the token for signing is what is displayed and is sent after then PIN has been entered. The big difference between the current EU FINREAD standard (certified terminal attempting to establish the basis for inferring intention and/or non-repudiation) and the early X9A10 work by Tom Jones, was that Tom wanted the certified terminal/environment to cosign the transaction thereby proving that the signing actually took place using a certified terminal/environment. The existing FINREAD standard establishes the criteria for a certified signing environment/terminal (required for inferring intention/non-repudiation) but doesn't (yet) require proof
