(once again) hidden private keys [u]

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

(once again) hidden private keys [u]

Andreas Jellinghaus-2
sorry to bring the subject up once again,
but the hidden private keys still bug me.

I don't know if it is possible to mark a private
key as non-hidden during creation, as far as I know
it is not.

So every private key is marked hidden and opensc-pkcs11.so
does not expose them unless you are logged in.

now the new part is libp11 which has a function
        PKCS11_enumerate_keys
which will not see them (p11_key.c). strange: the comment is:
 * Enumerate all keys on the card
 * For now, we enumerate just the private keys.

but the code is:
                priv->nkeys = 0;
                if (pkcs11_find_keys(token, CKO_PRIVATE_KEY)) {
                        pkcs11_destroy_keys(token);
                        return -1;
                }
                priv->nprkeys = priv->nkeys;
                if (pkcs11_find_keys(token, CKO_PUBLIC_KEY)) {
                        pkcs11_destroy_keys(token);
                        return -1;
                }


as you can see it searchs for public keys, too, but the result
returned is
        *countp = priv->nprkeys;

so even public keys found are not visible to the caller.
(or I missed how the sematics for the caller are supposed to work).
that code was written by Olaf so I don't know its internals.


so with libp11 we have no way to list the public keys. what shall we do?

on the topic of hidden keys:
I don't think there is much security in hidding details a user can find
out with command line tools or via apdu. so I wonder if hidding the
private keys is of any use.

also I think there is a security gain in asking the user for the pin
as late as possible and then giving as many details as possible.
for example "enter pin" is not as good as "key XYZ requires authentication.
please enter LABEL pin". the later is better from security point of view.
but - I'm not sure if we can do that with pkcs#12 - it requires the code
to see key XYZ, decide that this key will be used and find out the LABEL
to print wen asking the pin for it.

well the topic of hidden keys is of course more complicated when we consider
a card with two pins and a private key each. that would resolve to two
different slots, right? in that case only the private key associated with
that pin/user/slot should be visible.


the other topic is how to use libp11. I coded something which enumerates
the keys, then looks for a certificate for that key, and if so checks
if that certificate can be used (e.g. for authentication), and if so ask
for the pin to login and sign.

I could as well change the code to enumerate the certificates, but as CA
certificates are not important for the authentication taks, I would need
to decide cacert / usercert by either parsing the cert and a heuristic
or by looking for a key to match that cert - which might as well not work
with current code.

we could as wenn change the libp11 code to reveal the public keys in
PKCS_enumerate_keys. But I wonder how a user will decide that a key
is a private or public key. looking at the libp11 code, both are treated
the same.

so what kind of code flow do you recommend?

it would be quite helpful to agree on the direction we prefer, as I
wrote my small example app up to the point where I now either need
to change it or libp11 or opensc-pkcs11, and I'm not sure what the best
way is.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: (once again) hidden private keys [u]

Stef Hoeben
Andreas Jellinghaus [c] wrote:

>sorry to bring the subject up once again,
>but the hidden private keys still bug me.
>
>I don't know if it is possible to mark a private
>key as non-hidden during creation, as far as I know
>it is not.
>
>So every private key is marked hidden and opensc-pkcs11.so
>does not expose them unless you are logged in.
>
>now the new part is libp11 which has a function
> PKCS11_enumerate_keys
>which will not see them (p11_key.c). strange: the comment is:
> * Enumerate all keys on the card
> * For now, we enumerate just the private keys.
>
>but the code is:
>                priv->nkeys = 0;
>                if (pkcs11_find_keys(token, CKO_PRIVATE_KEY)) {
>                        pkcs11_destroy_keys(token);
>                        return -1;
>                }
>                priv->nprkeys = priv->nkeys;
>                if (pkcs11_find_keys(token, CKO_PUBLIC_KEY)) {
>                        pkcs11_destroy_keys(token);
>                        return -1;
>                }
>
>
>as you can see it searchs for public keys, too, but the result
>returned is
>        *countp = priv->nprkeys;
>
>so even public keys found are not visible to the caller.
>(or I missed how the sematics for the caller are supposed to work).
>that code was written by Olaf so I don't know its internals.
>
>
>so with libp11 we have no way to list the public keys. what shall we do?
>  
>
Make a new function, I'd say,. private and public keys are too different
to be returned together..

>on the topic of hidden keys:
>I don't think there is much security in hidding details a user can find
>out with command line tools or via apdu. so I wonder if hidding the
>private keys is of any use.
>  
>
This keeps comming back:-)
I'll change it to show the private keys by default (in the WE), and have
a config option to hide them
when not logged in. It's more secure, won't break with any existing app
and IMHO the pkcs11
standard is not 100% clean on the matter.

>also I think there is a security gain in asking the user for the pin
>as late as possible and then giving as many details as possible.
>for example "enter pin" is not as good as "key XYZ requires authentication.
>please enter LABEL pin". the later is better from security point of view.
>but - I'm not sure if we can do that with pkcs#12 - it requires the code
>to see key XYZ, decide that this key will be used and find out the LABEL
>to print wen asking the pin for it.
>
>well the topic of hidden keys is of course more complicated when we consider
>a card with two pins and a private key each. that would resolve to two
>different slots, right? in that case only the private key associated with
>that pin/user/slot should be visible.
>
>
>the other topic is how to use libp11. I coded something which enumerates
>the keys, then looks for a certificate for that key, and if so checks
>if that certificate can be used (e.g. for authentication), and if so ask
>for the pin to login and sign.
>
>I could as well change the code to enumerate the certificates, but as CA
>certificates are not important for the authentication taks, I would need
>to decide cacert / usercert by either parsing the cert and a heuristic
>or by looking for a key to match that cert - which might as well not work
>with current code.
>
>we could as wenn change the libp11 code to reveal the public keys in
>PKCS_enumerate_keys. But I wonder how a user will decide that a key
>is a private or public key. looking at the libp11 code, both are treated
>the same.
>
>so what kind of code flow do you recommend?
>  
>
If an application want the public key, they usually get the cert and
extract the pubkey from there,
so I don't think returning the public keys will be needed/usefull.

>it would be quite helpful to agree on the direction we prefer, as I
>wrote my small example app up to the point where I now either need
>to change it or libp11 or opensc-pkcs11, and I'm not sure what the best
>way is.
>
>Regards, Andreas
>

Cheers,
Stef
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: (once again) hidden private keys [u]

Andreas Jellinghaus-2
On Wednesday 13 July 2005 22:55, Stef Hoeben wrote:
> >so what kind of code flow do you recommend?
>
> If an application want the public key, they usually get the cert and
> extract the pubkey from there,
> so I don't think returning the public keys will be needed/usefull.

the aim is authentication, so the application needs usualy to find
some certificate and know whether or not a private key is available
for this certificate.

the only job of the public key so far is the assumption, that a certificate
with a public key will as wall have a private key.

I'd prefert to directly have certificates and private keys, so I can ignore
the public keys at all (I don't see much use for them on smart cards anyway).

but if I can't have the private key, I would need to assume that every
certificate is bundled with a private key. a very bad guess, but the only
one with no false negatives.

Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: (once again) hidden private keys [u]

Stef Hoeben
Andreas Jellinghaus [c] wrote:

>On Wednesday 13 July 2005 22:55, Stef Hoeben wrote:
>  
>
>>>so what kind of code flow do you recommend?
>>>      
>>>
>>If an application want the public key, they usually get the cert and
>>extract the pubkey from there,
>>so I don't think returning the public keys will be needed/usefull.
>>    
>>
>
>the aim is authentication, so the application needs usualy to find
>some certificate and know whether or not a private key is available
>for this certificate.
>
>the only job of the public key so far is the assumption, that a certificate
>with a public key will as wall have a private key.
>  
>
Guess that's not the case with pkcs11. In fact, many pkcs11 libs don't
show public keys; it's something
specific for our pkcs11 lib to extract the public key from each cert and
show it..

>I'd prefert to directly have certificates and private keys, so I can ignore
>the public keys at all (I don't see much use for them on smart cards anyway).
>
>but if I can't have the private key, I would need to assume that every
>certificate is bundled with a private key. a very bad guess, but the only
>one with no false negatives.
>
If you skip the CA certs and only remain the user certs, you have a very
big chance that there's a
corresponding key with the same CKA_ID.

Cheers,
Stef

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: (once again) hidden private keys [u]

Douglas E. Engert
In reply to this post by Andreas Jellinghaus-2


Andreas Jellinghaus [c] wrote:

> On Wednesday 13 July 2005 22:55, Stef Hoeben wrote:
>
>>>so what kind of code flow do you recommend?
>>
>>If an application want the public key, they usually get the cert and
>>extract the pubkey from there,
>>so I don't think returning the public keys will be needed/usefull.
>
>
> the aim is authentication, so the application needs usualy to find
> some certificate and know whether or not a private key is available
> for this certificate.
>
> the only job of the public key so far is the assumption, that a certificate
> with a public key will as wall have a private key.

Well if the assumption is correct, you could find a certificate, then
find if the card has a matching public key, which would assume there is
also a matching private key on the card.

>
> I'd prefert to directly have certificates and private keys, so I can ignore
> the public keys at all (I don't see much use for them on smart cards anyway).
>
> but if I can't have the private key, I would need to assume that every
> certificate is bundled with a private key. a very bad guess, but the only
> one with no false negatives.
>
> Andreas
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
>
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: (once again) hidden private keys [u]

Andreas Jellinghaus-2
In reply to this post by Andreas Jellinghaus-2
thanks to everyone for providing feedback.

I now changed by code once more to enumerate
all certificates and simply assue that a certificate
will have a private key. I also added code to libp11
so you can get the certificate if you have a key
(previously only the reverse was possible).

becase two lists are matched (certs on card / certs
in file), it is ok in this case to not exclude ca
certificates from the list of certs on cards.

the result is pam_p11, works fine over here
(but so far I only tried with a single certificate
on my card). see my other posting for details
on pam_p11.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel