| The problem is that _because there is an interface to poll the token for
| a code across the USB bus_, malicious software can *repeatedly* steal new
| token codes *any time it wants to*.  This means that it can steal codes
| when the user is not even attempting to authenticate....
I think this summarizes things nicely.  Moving to a higher level of
abstraction:  With a traditional token, if the correct value has been
entered, we can reasonably assume intent on the part of the human
being in possession of the token to identify himself, and thus take
responsibility for some set of actions.  With the additional "something
you know" password associated with the token, we can further reasonably
assume that the person in possession of the token is in fact the person
who has the right to possess that token.*

In the case of a software-readable USB token, *neither* assumption is
reasonable.  The resulting authentication is very different in kind.

| It is noteworthy that a token that requires *any* kind of intervention
| by the user -- even something as simple as a press of a button on the
| token which illuminates when the host presents the token-code request --
| is invulnerable to such an attack...
Pressing the button supplies exactly the confirmation of intent that
was lost.  (However, it can't get you to the assumptions about "the
right person" having possession of the token.  The fingerprint scanning
technologies that one sees in some USB drives today would probably be
reasonable for that purpose - not that one has much information about
their false positive rates or how hard they really are to attack.
I don't know what the costs are, however - low enough for ~$100 drives,
maybe not low enough for an ID token.)

                                                        -- Jerry

* Yes, there are attacks that render these assumptions invalid.
Nothing is perfect.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to