Welome to the Internet, here's your private key

[Trei, Peter]

> pgut001 at cs.auckland.ac.nz[SMTP:pgut001 at cs.auckland.ac.nz]
> 
> 
> "Trei, Peter" <ptrei at rsasecurity.com> writes:
> 
> >One other scheme I've seen, and which, while it doesn't give me warm
> fuzzies,
> >seems reasonable, is to issue the the enduser a smartcard with a keypair
> on
> >it. The SC generates the pair onboard, and exports only the public half.
> The
> >private half never leaves the SC (there is no function on the card to
> export
> >it).
> >
> >If you trust the above, then the only copy of the private key is on the
> SC,
> >despite it having been generated without the end users participation.
> 
> This also causes problems, because it's really, really hard to spread the
> key
> around if the only copy is on the card.  Solutions I've seen are to
> multiplex a
> single card + reader across multiple machines, or (more commonly) to
> generate
> the key in software and then load it onto the card, with copies kept
> active on
> the host PC.  This combines the benefits of smart card security and the
> flexibility of software crypto keys which can be copied and distributed as
> required.
> 
> Peter.
> 
We're generally talking about a 'is a person' or an 'is an employee' key, in
an enterprise situation. Having a single copy of the private key is usually
acceptable. If it's lost/destroyed then a new one can be issued. Since it's
so closely bound to a single person (typically for access/ email or Single 
Signon applications), having a private key that can't operate without the
presence
of the owner (and the card) is usually a feature, not a bug.

Peter T


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com