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 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
