Why isn't it sufficient? (Quick: when was the last time anyone on this list authenticated by signing unread random data?)
The way the industry is going, user keypairs live in a desktop keystore, and are used for very few applications. I'd bet the vast majority of usages are client-side SSL, signing, and encryption.
If this de facto universal usage suite contains exactly one authentication protocol that has a built-in countermeasure, then when this becomes solid, we're done.
so if digital signing is used for nothing else than authentication ... with signing of challenge data (with or with/out client-side modification) ... then there is no concern that something signed might be a document or authorization form. it is a non-problem.
EMV chipcards are supposed to be doing dynamic data RSA signing of authorized transactions ... at some point, real soon now ... and the financial industry is writting some number of apps to be able to use the EMV cards for other applications.
this is from yesterday http://www.smartcardalliance.org/industry_news/industry_news_item.cfm?itemID=1316
which talks about additional applications (in addition to expected RSA signing at EMV point-of-sale terminals)
* OneSMART MasterCard Authentication – ensures a higher level of security for online shopping and remote banking
* OneSMART MasterCard Web – allows cardholders to securely store and manage a wide range of personal data (such as names, addresses, URLs, log-on passwords) on the smart card chip
* OneSMART MasterCard Pre-Authorised – a new chip-based payment solution suitable for new markets and off-line payment environments
===
it doesn't give any details but possibly if the expected RSA signing at EMV point-of-sale terminals is an example of aggreement/approval ... then the authentication application may be RSA signing of some sort of challenge data .... and i would guess that few, if any people make it a habit to examine presented challenge data.
part of the issue is creating an environment where all authentication protocols and all authentication implements are required to have countermeasures against dual-use attack on signing of documents or transactions ... means that loads of stuff have to be perfect in the future.
the other is requiring more proof regarding the signing environment to be carried when the signing is associated with approval, agreement, and/or authorization (more than simple authentication) .... for instance that for some of the non-repudiation features (that supposedly address such issues) .... that they have to also sign in some manner to indicate non-repudiation features in in place.
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
