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

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: 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).

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.

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

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

Reply via email to