There are very good reasons for having hardware tokens as part of 2/3 factor authentication ... i.e. the hardware token is a "something you have" .... and very good reason for such hardware tokens to become ubiquitous. Now if there is USB plub&play for things like PC/SC ... there is much lower dependency on what the form factor that hardware token needs to take (modulo some of the EU finread standards issues) that it would be transparent to software whether it is talking USB to dongle hardware token or usb reader+card.
As mentioned previously .... the issue regarding divulging the private key is a business issue. Using public/private key in an authentication business scenario has a real requirement that the private key not be known to minimize impersonation issue. However, public/private key in encryption business scenario involving valuable corporate assets could lead to "loss" of those assets of there is a token/private-key failure/loss/stollen. Where private key is being used in business scenario involving protection of valuable corporate assets .... there is real requirement for high level of redundancy ... and the "impersonation" scenario doesn't apply as it does in the authentication business scenario; aka while the technology may be the same ... the different requirements are driven from the business needs & applications. it is possible to establish business practices and audit procedures to significantly increase confidence in the operation of hardware tokens. ... misc. aads chip strawman discussions http://www.garlic.com/~lynn/index.html#aads impresonation refs: http://www.garlic.com/~lynn/aadsm10.htm#keygen Welome to the Internet, here's your private key http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate? http://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?) misc. eu finread discussions http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern" http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe??? http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible? http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure? http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market 1/2/3 factor authentication http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack http://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re: Rubber hose attack http://www.garlic.com/~lynn/aadsm7.htm#rhose14 when a fraud is a sale, Re: Rubber hose attack http://www.garlic.com/~lynn/aadsm7.htm#rhose15 when a fraud is a sale, Re: Rubber hose attack http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI http://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000) http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall? http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001g.html#1 distributed authentication http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates http://www.garlic.com/~lynn/2001g.html#38 distributed authentication http://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything? http://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure? http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure? http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords http://www.garlic.com/~lynn/2001k.html#61 I-net banking security jaap-henk hoepman <[EMAIL PROTECTED] on 2/8/2002 9:12 am wrote: I think there _are_ good business reasons for them not wanting the users to generate the keys all by themselves. Weak keys, and subsequent compromises, may give the CA really bad press and resulting loss of reputation (and this business is built on reputation anyway). So: there are good reasons not to let the CA generate the private key, but also good reasons to not let the user generate the keys all by himself. So the question is: are there key generation protocols for mutually distrustful parties, that would give the CA the assurance that the key is generated using some good randomness (coming from the CA) and would give the user the guarantee that his private key is truly private. Also, the CA should be able to verify later that the random data he supplied was actually used, but this should not give him (too much) advantage to find the private key. A smartcard based system might be useful here (as suggested by other subscribers here). But a software only solution is preferred because it would maker the application area much broader (because the user does not have to be supplied with special hardware - terminals + smartcards). Jaap-Henk -- Jaap-Henk Hoepman | Come sail your ships around me Dept. of Computer Science | And burn your bridges down University of Twente | Nick Cave - "Ship Song" Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman Phone: +31 53 4893795 === Secr: +31 53 4893770 === Fax: +31 53 4894590 PGP ID: 0xF52E26DD Fingerprint: 1AED DDEB C7F1 DBB3 0556 4732 4217 ABEF --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
