RSA SecurID SID800 Token vulnerable by design

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com