> [EMAIL PROTECTED][SMTP:[EMAIL PROTECTED]] > > > "Trei, Peter" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
