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 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 aads chip strawman http://www.garlic.com/~lynn/index.html#aadsstraw regarding trusted token acceptor device for ACH transactions: http://www.asuretee.com/company/releases/030513_hagenuk.shtm .... and as an aside the merged security taxonomy and glossary is at http://www.garlic.com/~lynn/index.html#glossary Note that otherwise similar tokens may come with three different types of personalities: 1) no PIN required .... frequently found in low-value, high traffic transit locations. Single factor ("something you have") authentication is sufficient 2) PIN required after power up ..... frequently found in two-factor authentication access applications, the token is powered up, the correct PIN entered, and the token may digitally sign an arbitrary number of authentication messages while powered up. The operation of the hardware token implies correct "something you know" PIN as part of two-factor authentication. 3) PIN required for every message .... found in financial transaction applications and typically assumed to be used in an authentication environment that allows intention and/or non-repudiation to be inferred. The PIN, in addition to implying "something you know" authentication also implies some human physical event (entering the PIN) occurred as part of a non-repudiation process. Note that there is a significant difference in the shared-secret paradigm and the non-shared secret paradigm. In the shared secret paradigm, the "something you know" is recorded at some central location and used to establish authentication. In the shared secret paradigm, the secret can be recorded in a private hardware token, and the knowledge of the secret can be inferred from the operation of the token; w/o actually requiring the secret to ever be divulged. As a footnote, X9.59 doesn't (directly) address the privacy part of security. There is current situation where credit-card transaction have encryptd transmission on the internet using SSL; in part because the account numbers are a form of shared secret (divulging the account number can result in fraudulent transactions). X9.59 as part of the original requirement "preserve the integrity of the financial infrastructure for all retail payments", specifies 1) authentication transactions and 2) account numbers that can only be used in authenticated transactions. As a result, X9.59 account numbes by themselves can't be used in fraudulent transactions and therefor no longer have to be treated as shared-secrets. It was observed, that in any transition, financial institutions could use existing business processes that map multiple different account numbers to the same account. Furthermore, the claim is that with strong two factor authentication ("something you have" and "something you know") operation, it would be possible to remove names from tokens and as part of transactions. While X9.59 doesn't directly address financial privacy issues (via mechanisms like encryption), it indirectly aids privacy by eliminating account numbers as shared secrets and no longer requiring identification as part of transactions. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm