Lance James wrote:
Agreed, and since my research is focused on online banking I can see
yours and my point, either way, SecurID should not be the only concept
for dependence.
as i've mentioned serveral times, in the mid-90s, the x9a10 financial
standards working group was given the task of preserving the integrity
of the financial infrastructure for all retail payments. the result was
x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
which specified (end-to-end) authenticated transaction (and a business
rule that account numbers used in x9.59 transactions could not be used
in non-authenticated transactions) ... recent, related post:
http://www.garlic.com/~lynn/aadsm25.htm#24 DDA cards may address the UK
Chip&Pin woes
part of the issue was with the actual transactions being signed and
running end-to-end ... and account numbers no longer vulnerable to
"naked" exploits ... it was no longer necessary to hide the account
number (as countermeasure to prevent fraudulent "replay attack"
transactions).
http://www.garlic.com/~lynn/subpubkey.html#harvest
the issue then became end-point attacks; either the originating
end-point or the authorizing end-point. most infrastructure have had the
authorizing end-points pretty well armored for some time. that primarily
leaves vulnerabilities at the originating end-point.
part of the EU finread terminal work was to close off some of the
originating end-point vulnerabilities.
http://www.garlic.com/~lynn/subpubkey.html#finread
basically an independent, secure token terminal with its own display and
key-entry. the transactions is forwarded from the end-point to the
finread terminal ... the finread terminal displays a summary of the
transaction details ... and passes it to the token for digital signing.
any pin-entry (for two-factor authentication ... token "something you
have" and pin-entry "something you know") is performed at the finread
terminal (minimizing any pin evesdropping and associated pin replay
attack exploits).
while session encryption is useful for confidentiality and privacy of
the operations ... a lot of existing session encryption is primarily
because existing transactions don't have end-to-end armored
authentication ... leaving various pieces of information involved in the
actual transaction naked and vulnerable to various kinds of replay attacks.
the x9.59 standards approach was to provide end-to-end armoring of the
actual transactions ... eliminating numerous kinds of replay
vulnerabilities and some of the man-in-the-middle attacks
http://www.garlic.com/~lynn/subpubkey.html#mitm
... independent of any possible use of authentication for session purposes
note that while it isn't part of the x9.59 standard ... the standard was
carefully crafted such that end-point environments like the EU finread
would be allowed to also sign transactions.
the issue is that the responsible authorization end-point frequently
will be doing risk assessment (especially involving financial
transactions). it is easy to see that a eu finread terminal provides a
much higher integrity digital signing environment that many personal
computers (for instance, virus software than log the entered pin and
replay it to a connected hardware token w/o the person's knowledge) ...
it is useful to have some knowledge about the transaction originating
environment when doing risk assessment.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
