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 existence of a digital signature then demonstrates possession of "something you have" token a
Re: FINREAD ... and as an aside
with regard to finread operation for inferring intention and/or non-repudiation from previous posts: http://www.garlic.com/~lynn/aepay11.htm#53 http://www.garlic.com/~lynn/aepay11.htm#54 is a characteristic of the disconnect between the "something you have" token and the technology needed for secure display and input. there has been quite a bit of work translating the requirements for inferring intention and/or non-repudiation into a "something you have" device that integrates the attributes of personal token with secure display and input (aka some form of PDA or cellphone). This somewhat reflects the claim that (7816) smartcards went thru a period where there was some thought that they would be the PDAs of the 1980s i.e. the technology didn't yet exist to integrate portable computing that fit in a pocket along with portable display and input. The solution was to have ubiquitous input/output stations with people carrying the portable computer (smartcard) in their pocket. In the early 90s, there was advances in technology that allowed that the portable computing devices (aka smartcards) and input/output capability to be integrated into a single device (evidence PDAs and cellphones). This effectively began the obsoleting of that target market for smartcards. >From an asuretee standpoint: http://www.asuretee.com/ embedding an asuretee chip in a personal portable computing device with integrated input/output (aka PDA/cellphone) can provide both the indication of "something you have" authentication along with proof of a business process that supports intention and/or non-repudiation. Of course the specific personal, portable computing device with integrated input/output will need to be appropriately certified as meeting the (equivalent finread) security requirements in support of demonstrating intention and/or non-repudiation. This requires a high level of assurance that the value of the transaction that is displayed, is in fact the value that a digital signature is applied to ... and that there is some sort of human input in conjunction with the value displayed that can be taken as representing human intention and agreement. this is similar to past threads relating to the asuretee chip being the equivalent of the trusted computing platform module. Depending on the business process followed and the exact certification, an embedded asuretee chip could be taken as 1) authenticating a hardware device, 2) authentication as part of "something you have" paradigm, 3) authentication in conjunction with other inferred events supporting two/three factor authentication and/or intention and non-repudiation. The original references to FINREAD wasn't whether or not it was applicable to PDAs and cellphones, but what were the characteristics of the requirements in the FINREAD standard necessary for establishing intention and/or non-repudiation. Using the implementation details of a FINREAD terminal as an example along with the original requirements, it is then possible to translate the requirements to other implementations. I relatize that the specifics of the FINREAD terminal represent the 80s disconnect between technology available for a personal, pocket-sized portable computing device and the 1980s input/output technology needed to support a pocket-sized portable computing device. However, it is also possible to translate requirements for supporting "intention" into 1990s technology where the personal pocket-sized portable computing device has its own integrated input/output technology. lots of past threads related to FINREAD and/or intention. http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof 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/aadsm11.htm#7 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI? http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA) 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/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM] http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses "Authority-stamp-signatures" http://www.garlic.com/~lynn/aepay10.htm#53 First International Conference On Trust Management http://www.garlic.com/~lynn/2000f.html#79 Cryptogram Newsletter is off the wall? http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking http://www.garlic
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
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 that the signature actually occurred using such a certified terminal/environment. The cosigning for X9.59 transactions was different than the FSTC e-check cosigning. The FSTC e-check cosigning wanted two (or more) entities authenticating the transaction. The X9.59 cosigning work wanted proof that a certified signing environment (process required for inferring intention and/or non-repudiation) was used (by the environment/terminal cosigning the transaction). Slightly related recent announcement from asuretee: http://www.assuretee.com/ aka instantiation of the aa
