G'day,
Stef Hoeben wrote:
not sure where the problem is: "pkcs11-tool --show-info" and
"pkcs11-tool --list-slots" don't ask for a PIN because they don't
look for keys.
I included the output of pkcs11-tool to provide further info on the
reader and the card used in each case.
If you use other tools, like kinit, you may have to enter your PIN if
those tools are programmed to ask your PIN..
(Sorry if I overlooked something..)
The problem is the engine_pkcs11.c will prompt for a PIN if I use one
library/card, but not prompt for a PIN if I use a different
library/card, even though a PIN is required in both cases.
A little debugging shows that the pkcs11_load_key function [*] in
engine_pkcs11.c has the following loop:
while (1) {
if (PKCS11_enumerate_keys(tok, &keys, &count))
fail("unable to enumerate keys\n");
if (count)
break;
...
... ask for pin and login ...
...
}
This loop checks if any private keys can be found -- if so, there's no
need to ask for a PIN since private information is already obtainable.
The problem here is that I have not yet provided a PIN, so it looks like
the muscle PKCS11 library is returning handles to private objects during
searches, which means that a PIN is never requested.
This can be demonstrated by using pkcs11-tool:
(a) gemsafe PKCS#11 library, no PIN specified
$ pkcs11-tool --module /usr/lib/gemsafe/libgemsafe.so --slot 0 \
--list-objects
Certificate Object, type = X.509 cert
label:
ID: 1234
(b) gemsafe PKCS#11 library, PIN specified
$ pkcs11-tool --module /usr/lib/gemsafe/libgemsafe.so --slot 0 \
--pin 1234 --list-objects
Certificate Object, type = X.509 cert
label:
ID: 1234
Private Key Object; RSA
label:
ID: 1234
Usage: decrypt, sign, unwrap
(c) muscle PKCS#11 library, no PIN specified
$ pkcs11-tool --module /usr/local/lib/libmusclepkcs11.so \
--slot 1 --list-objects
Certificate Object, type = X.509 cert
label: DC=vas, DC=sc, CN=Users, CN=Matlock
ID: 49cb2686266fbb61b612bc3950bdc3099a1e5354
Private Key Object; RSA
label: DC=vas, DC=sc, CN=Users, CN=Matlock
ID: 49cb2686266fbb61b612bc3950bdc3099a1e5354
Usage: decrypt, sign, unwrap
(d) muscle PKCS#11 library, PIN specified
$ pkcs11-tool --module /usr/local/lib/libmusclepkcs11.so \
--slot 1 --pin 00000000 --list-objects
Certificate Object, type = X.509 cert
label: DC=vas, DC=sc, CN=Users, CN=Matlock
ID: 49cb2686266fbb61b612bc3950bdc3099a1e5354
Private Key Object; RSA
label: DC=vas, DC=sc, CN=Users, CN=Matlock
ID: 49cb2686266fbb61b612bc3950bdc3099a1e5354
Usage: decrypt, sign, unwrap
For the gemsafe PKCS#11 library, if the PIN is not specified, then a a
search returns no private keys at all. For the muscle PKCS#11 library, a
search returns a handle to the private key, whether the PIN is specified
or not (note, however, that the values of this private object are not
visible, even if the existence of the private object itself is exposed).
Section 10.4 of the PKCS#11 version 2.2 standard mentions the following
for the CKA_PRIVATE attribute:
"When the CKA_PRIVATE attribute is CK_TRUE, a user may not access
the object until the user has been authenticated to the token."
This is kinda vague, but I understand it to mean that, until a PIN has
been specified, any private object is hidden from the application. It is
not returned in any searches, and its attribute values are not revealed.
Until a PIN is presented, private objects effectively are not visible to
the application.
This is consistent with how the gemsafe PKCS#11 library operates, and in
what the opensc PKCS#11-enabled crypto engine expects.
My thoughts are that muscle PKCS#11 should be modified to not return any
private objects in searches until a PIN has been presented. Does anyone
disagree?
-- Geoff
[*] Oddly, the pkcs11_load_key function (used for both public and
private keys) has code that enumerates the *certificates* on the token,
and fails if a problem occurs:
if (PKCS11_enumerate_certs(tok, &certs, &count))
fail("unable to enumerate certificates\n");
if(verbose) {
fprintf(stderr,"Found %u certificate%s:\n", count,
(count <= 1) ? "" : "s");
for (n = 0; n < count; n++) {
... dump certificate info ...
}
}
Why certificates should be searched when loading a private key, and
causing the pkcs11_load_key function to fail if a problem occurs doing
this, is not explained.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
