OpenSC smartcard access should use raw public keys, not X.509 certificates

[Douglas E. Engert]

[Sorry for jumping in late on this.]

Daniel Kahn Gillmor wrote:
> On Fri 2008-08-01 11:16:01 -0400, Alon Bar-Lev wrote:
> 
>> No... You you interested in making ssh work...
> 
> ?? i'm afraid i don't understand this sentence.
> 
>> The PKCS#11 spec does not enforce the types of objects stored, so in
>> order to save space many vendors choose not to store the public key
>> object.
> 
> Perhaps i'm confused about the PKCS#11 specification: it is my
> understanding that an X.509 certificate is actually a superset of the
> public key object itself [0].  Therefore, if you're storing the X.509
> certificate, you're already storing the public key.  (and in fact, the
> public key itself is already stored in the private key object, as
> well.   For RSA, it is usually represented as the first two components
> of the 5-tuple key).  Why would being able to produce the public key
> consume *more* space -- wouldn't the public key already be present?
> 
Yes, but on the card there may be a pubkey object as well as a cert
object, (which should match), but stored separately thus taking
up more space.

>> So the minimal configuration is having private key (from which you
>> can extract public key) as a protected object and X.509 certificate
>> (from which you can extract public key) as public object.
> 
> I'm afraid i don't see this reasoning either.  The minimal
> configuration for an RSA smartcard, it would seem, is an RSA private
> key. 

Yes. But there needs to be some way to associate the private key
with the the pubkey. The minimal would be the user has to entry in
some assoication manually. In practice, a certificate is
usually stored on a card.

> Since the private key is a superset of the public key, the
> public key itself would be already present. 

Yes, but the card may not allow you to read modulus and exponent.

>  X.509 certificates are
> (sort of) nice, but they're just gravy if your goal is just a hardware
> implementation/offload of RSA.
> 
> (the same is true of other certificate formats, fwiw, such as those
> specified by RFC 4880 [1].  I don't want this discussion to turn into
> a debate on the merits of the X.509 certificate format itself; the
> point is that *any* certificate is superfluous if you're interested in
> using a hardware token as a raw RSA engine.  Certificates can be
> stored and distributed in many other ways.)
> 
>> I am hoping to push the PKCS#11 implementation forward, and then there
>> is no reason to keep the OpenSC specific one.
> 
> If your PKCS#11 implementation excludes the ability to use raw RSA
> keys on hardware tokens, then i certainly hope OpenSSH doesn't remove
> the OpenSC-specific one.
> 
>> Oh... you truly got a problem.... I understand why you discuss this
>> now... I would recommend choosing a different smartcard.
> 
> I've provided an example of a relatively recent, widely-deployed card
> (still currently available at retail, fwiw [2]) that behaves
> reasonably under all circumstances we've discussed (at least with my
> patch applied).  But the card doesn't have enough on-board memory to
> store the data associated with an extra X.509 certificate.  I really
> don't think that "you need to get new hardware" is an appropriate
> response.
> 
> I asked earlier for an example of a card that can store (and emit)
> X.509 certificates, but is incapable of producing a public key.  Could
> you provide a concrete example?  If i can find (or get remote access
> to) such a card, i'd be happy to adjust my patch to be able to pull
> From both the X.509 certificates and the raw public keys on the card.
> Would that seem reasonable to you?  Can you identify such a card?

But you are mixing up what is on the card and what OpenSC (or some other
middleware) can do for you. An example of a card which does not store the
pubkey seperatly on the card is the PIV card. It stores objects, including
cert objects and private keys.

But pkcs15-piv.c uses the OpenSC pkcs15 emulation code sc_pkcs15emu_*
to simulate a a pubkey object. It does this be reading the cert, and
extracting the pubkey.  So from  PKCS#11 or PKCS#15 it appears the card
does have a pubkey object.

With other cards, it is up to the author of the libopensc/card-<CARD>.C
and pkcs15-<CARD>.c modules to implement this if needed for their card.

Your patch would be better if it tried for a cert, and if not available,
then try for a pubkey.

> 
> Regards,
> 
>         --dkg
> 
> [0] http://tools.ietf.org/html/rfc5280#section-4.1.2.7
> [1] http://tools.ietf.org/html/rfc4880#page-20
> [2] http://www.usasmartcard.com/component/page,shop.product_details/flypage,shop.flypage/product_id,19/category_id,22/manufacturer_id,0/option,com_virtuemart/Itemid,26/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444