Daniel Kahn Gillmor | 1 Aug 15:44 2008
Face
Picon

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

On Fri 2008-08-01 01:32:36 -0400, Alon Bar-Lev wrote:

> The public key object is not always available on smartcards.

Could you identify some cards that have this behavior?  It's certainly
*not* true on the Axalto cryptoflex eGate using debian's packaged
version of OpenSC.  If you add an X.509 certificate to the eGate, it
automatically creates both the certificate object *and* the public key
object, according to pkcs15-tool(1).

> Basic configuration is having private key + X.509 certificate on
> card.

Could you point me toward documentation for this?  I'd love to read up
on it more.

> This is why the PKCS#11 patch also don't assume public key
> existence.

Well, for PKCS#11, you clearly are *interested* in the X.509
certificate, right?  In that case, it wouldn't make sense to care
about a bare public key (unless you had some external mechanism to
retrieve the relevant certificate), so you're doing the right thing in
that patch.  But for regular OpenSSH purposes, where X.509 is *not*
relevant, the bare public key is the thing that matters.

Help me understand: for a user whose smartcard:

 * allows storage of two private keys, but

(Continue reading)

Alon Bar-Lev | 1 Aug 17:16 2008
Picon

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

On 8/1/08, Daniel Kahn Gillmor <dkg-openssh.com <at> fifthhorseman.net> wrote:
>  Well, for PKCS#11, you clearly are *interested* in the X.509
>  certificate, right?  In that case, it wouldn't make sense to care
>  about a bare public key (unless you had some external mechanism to
>  retrieve the relevant certificate), so you're doing the right thing in
>  that patch.  But for regular OpenSSH purposes, where X.509 is *not*
>  relevant, the bare public key is the thing that matters.

No... You you interested in making ssh work...
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.
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 am hoping to push the PKCS#11 implementation forward, and then there
is no reason to keep the OpenSC specific one.

>  Help me understand: for a user whose smartcard:
>
>   * allows storage of two private keys, but
>
>   * is not capable of storing two full X.509 certificates (due to space
>    constraints), but
>
>   * is capable of storing one X.509 cert and one additional raw public
>    key (i'm in this situation right now),
>
>  how do you propose for OpenSSH to be able to make use of both keys?

(Continue reading)

Alon Bar-Lev | 1 Aug 07:32 2008
Picon

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

This is incorrect.
The public key object is not always available on smartcards.
Basic configuration is having private key + X.509 certificate on card.
This is why the PKCS#11 patch [1] also don't assume public key existence.

Alon.

[1] http://alon.barlev.googlepages.com/openssh-pkcs11

On 8/1/08, Daniel Kahn Gillmor <dkg-openssh.com <at> fifthhorseman.net> wrote:
> > The OpenSC smartcard framework supports access to both raw public
>  > keys and X.509 certificates on crypto tokens.  When OpenSSH is
>  > compiled --with-opensc, it currently looks for X.509 certificates on
>  > any smartcard it uses.  But OpenSSH itself uses raw public keys (and
>  > not X.509), so requiring the presence of an X.509 cert on the
>  > smartcard is unnecessary and potentially problematic.
>
>  Any word on the patch i offered to fix this problem?  The original
>  message can be found here:
>
>   http://marc.info/?l=openssh-unix-dev&m=121394687518903&w=2
>
>  I've now opened it as a bug in the mindrot bugzilla as well:
>
>   https://bugzilla.mindrot.org/show_bug.cgi?id=1498
>
>  The patch is a narrow one, and affects only those folks who compile
>  --with-opensc.  Is there anything i can do to encourage adoption of
>  it?
>
(Continue reading)

Peter Stuge | 1 Aug 23:18 2008

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

On Fri, Aug 01, 2008 at 06:16:01PM +0300, Alon Bar-Lev wrote:
> >  how do you propose for OpenSSH to be able to make use of both keys?
> 
> Oh... you truly got a problem.... I understand why you discuss this
> now... I would recommend choosing a different smartcard.

The problem is that this is a reality even for Cryptoflex eGate
users. Since it used to be the gold standard OpenSC card I would
appreciate a good solution for it. Granted, it has been unavailable
for a while, but I expect many to still have them in use.

//Peter
Daniel Kahn Gillmor | 2 Aug 01:04 2008
Face
Picon

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

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?

> 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.  Since the private key is a superset of the public key, the
public key itself would be already present.  X.509 certificates are
(sort of) nice, but they're just gravy if your goal is just a hardware
implementation/offload of RSA.

(Continue reading)

Peter Stuge | 2 Aug 02:09 2008

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

On Fri, Aug 01, 2008 at 07:04:45PM -0400, Daniel Kahn Gillmor wrote:
> Since the private key is a superset of the public key, the public
> key itself would be already present.

Of course, but I don't think (m)any card OS will create a virtual
file EF for the public key that actually fetches from the private
key. That would have to be done in higher level software, but that
code is not allowed to read the private key. (For good reason.)

//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev <at> mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Daniel Kahn Gillmor | 2 Aug 02:39 2008
Face
Picon

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

On Fri 2008-08-01 20:09:07 -0400, Peter Stuge wrote:

> On Fri, Aug 01, 2008 at 07:04:45PM -0400, Daniel Kahn Gillmor wrote:
> 
>> Since the private key is a superset of the public key, the public
>> key itself would be already present.
>
> Of course, but I don't think (m)any card OS will create a virtual
> file EF for the public key that actually fetches from the private
> key.  That would have to be done in higher level software, but that
> code is not allowed to read the private key. (For good reason.)

I understand why the code accessing the card itself shouldn't be
allowed to read the private components of the secret key.  But surely
storing the parameters separately and providing access to the public
ones would be reasonable?

I'm aware that i don't know much about the on-card formats for these
devices, though, so i'm probably wishing for things that seem
reasonable from a higher level but might run up against implementation
limitations.  I appreciate your pointing out some of the more nuanced
concerns.

At any rate, i think my point still stands for any stored
certificates: Is there any reason that the card itself (or the drivers
accessing the card) couldn't extract the public key information from a
stored certificate?

       --dkg
(Continue reading)

Peter Stuge | 2 Aug 03:04 2008

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

On Fri, Aug 01, 2008 at 08:39:01PM -0400, Daniel Kahn Gillmor wrote:
> I understand why the code accessing the card itself shouldn't be
> allowed to read the private components of the secret key.  But
> surely storing the parameters separately and providing access to
> the public ones would be reasonable?

It's an idea, but no cards I've seen work like that.

> I'm aware that i don't know much about the on-card formats for
> these devices, though, so i'm probably wishing for things that seem
> reasonable from a higher level but might run up against
> implementation limitations.  I appreciate your pointing out some of
> the more nuanced concerns.

Sorry - I thought you were more familiar with on-card storage.

ISO 7816-4 card OSes implement a quite simple file system with
directories (DF) and files (EF), which can be navigated and accessed
depending on the various security features implemented by the card
OS. (every card does this differently)

> At any rate, i think my point still stands for any stored
> certificates: Is there any reason that the card itself (or the
> drivers accessing the card) couldn't extract the public key
> information from a stored certificate?

No reason in theory, but in practice cards can't parse certificates.

As for drivers - yes, if the public key components are actually
available in the certificate then of course they could be extracted.
(Continue reading)

Alon Bar-Lev | 2 Aug 07:10 2008
Picon

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

On 8/2/08, Peter Stuge <stuge-openssh-unix-dev <at> cdy.org> wrote:
> On Fri, Aug 01, 2008 at 07:04:45PM -0400, Daniel Kahn Gillmor wrote:
>  > Since the private key is a superset of the public key, the public
>  > key itself would be already present.
>
>
> Of course, but I don't think (m)any card OS will create a virtual
>  file EF for the public key that actually fetches from the private
>  key. That would have to be done in higher level software, but that
>  code is not allowed to read the private key. (For good reason.)

For achieving sane user experience there is a need to access a public
object holding the public key. This allows to enumerate keys without
login each time the smartcard is inserted.

Alon.
Alon Bar-Lev | 2 Aug 07:13 2008
Picon

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

On 8/2/08, Peter Stuge <stuge-openssh-unix-dev <at> cdy.org> wrote:
> On Fri, Aug 01, 2008 at 06:16:01PM +0300, Alon Bar-Lev wrote:
>  > >  how do you propose for OpenSSH to be able to make use of both keys?
>  >
>  > Oh... you truly got a problem.... I understand why you discuss this
>  > now... I would recommend choosing a different smartcard.
>
>
> The problem is that this is a reality even for Cryptoflex eGate
>  users. Since it used to be the gold standard OpenSC card I would
>  appreciate a good solution for it. Granted, it has been unavailable
>  for a while, but I expect many to still have them in use.

Maybe a better solution is to implement on disk storage for public
objects which will be available as if they were on token?
This will allow the users to use their token with other
applications... We discuss here OpenSSH, but please keep in mind that
it is only one application with not-so-good smartcard support
built-in.
Users would like to use Firefox, OpenVPN, PSI and other software. All
require a certificate on token.

Alon.

Gmane