Welome to the Internet, here's your private key

Fri Feb 8 12:14:50 EST 2002

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 <hopeman at cs.utwente.nl 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: hoepman at cs.utwente.nl === 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 majordomo at wasabisystems.com