Hi Marc,
thanks for your bug report.
> When I read data on Linux (Ubuntu 09.04) using the libsiecap11.so provided
> by Siemens and onepin-opensc-pkcs11.so from OpenSC, I get completely
> different results. Why?
what exactly are you doing? pkcs11-tool for example? IIRC not everything
we show on pkcs#11 api is 100% defined where it comes from on pkcs#15 card
format level. so opensc has to improvise in some cases.
opensc is written to be quite generic. looking at the text files, I see
don't expose some information exposed by the siemens software. while we
could find a way to expose most of that, as I often know how to get that
informaiton from a card with cardos, it would be much harder to make it
generic and implement those parts for many cards.
for example low level information like the card version or the memory
situation of the card - you can have a look at cardos-tool --info to
see these. but we didn't create the infrastructure to expose those
via pkcs#11 api and change the card drivers to gather such data.
wouldn't be hard I guess, but there was no demand to do that so far.
what I see with a quick look at the text files is that some lowlevel
card info is passed on via pkcs#11 api, and that many information is
in a different order in the text files, but not necessarily different.
a small flag here and there is different, we would need to debug those
in details and find out why.
I know opensc lacks detailed code in at least one section: card drivers
set capabilities per card, e.g. what keys you can create and algorithms
it supports. if you have several keys, they could be restricted, e.g.
to allow only signing but no decryption (even though you can create keys
that can do both). opensc doesn't track that properly, so the pkcs#11
information is not 100% accurate.
> E.g. I cannot even get the token's serial number. In fact, using my
> library, I can get the serial number by sending an APDU: {{{serial =
> reader.transmit(0x00, 0xCA, 0x01, 0x81).substr(8, 8);}}} But the serial
> number in tokeninfo is empty.
does cardos-info show the serial number? if it does, the same number
should show up via pkcs#11 api. I know we have some simulations, for
example some cards have not serial number, but we extract the serial
from a certificate on the card. but IIRC that isn't active for cardos
cards.
you could run these tests to get some data:
a) cardos-tool --info
b) opensc-tool -f
c) the application that created the *.txt files uses pkcs#11 api?
then please use pkcs11-spy.so to create a log file for each run,
so we have a standard log file we are used to with details on
pkcs#11 level. warning: might include PIN, but for a test card
that shouldn't be an issue.
this could help to debug the situation further.
> I can login to the token using onepin-opensc-pkcs11.so. Then I see the
> private keys. But as soon as I try to create or delete an object, or even
> when I want to decrypt a text, I get an error.
the card wasn't initialized by opensc, right?
as far as I know, pkcs#15 standard is good enough to use card initialized by
some other software (e.g. read certs and public keys and directory
information, provice pin, sign and decrypt data with rsa, change pin,
unblick pin). but if you want to modify some card, you always have to use
the same software that initialized the card in the first place.
even if pkcs#15 is good enough for that in theory, I'm not aware that anyone
tried in practice or even managed to reach that goal, to make any two smart
card libraries compatible enough. but I'm no expert on other peoples software,
so maybe I simply didn't hear.
> C_CreateObject results in CKR_USER_NOT_LOGGED_IN (even though the login
> was successful!) and in the console, I get the folloeing message in
> unfriendly red letters:
> {{{
> [opensc-pkcs11] card-cardos.c:255:cardos_check_sw: required access right
> not granted
> [opensc-pkcs11] card-cardos.c:917:cardos_lifecycle_set: Card returned
> error: Security status not satisfied
> [opensc-pkcs11] card.c:678:sc_card_ctl: returning with: Security status
> not satisfied
> }}}
yes, I don't like the coloring and the debug messages to stderr either, but
it was implemented that way years ago and had enough fans to keep it that way.
most likely we will change it in 0.12 release.
> With other PKCS#11 drivers, it works better: Using the Siemens driver, I
> can create and delete objects. Problems here: Application crashes because
> of the driver, when no slot is available and it crashes also when I try to
> decrypt a secret. With a CryptoVision driver, also the tokeninfo and
> mechanisms are differernt. But I can create and delete objects. When I try
> to decrypt, I get a wrong mechanism error (even though the mechanism is
> here and works with Siemens driver, but only on Windoze).
>
> The onepin-opensc-pkcs11.so driver works at least partially. Firefox
> client authentication on a SSL apache webserver works with no problem.
>
> If there's any way, how I can help you, please let me know.
we are interested in improving our compatibility, both using card initialized
with other peoples software with opensc, as well as improving opensc format
if it has some error, so it works with third party applications, and so that
other libraries implementing pkcs#15 on cardos understand cards initialized
with opensc.
but for modifications of cards initialized with other software: not sure,
I thought noone tried that so far, at least not with success.
also one more cardos specific issue: cardos cannot have rsa keys for both
signing and decryption. each software has a different workaround. opensc
created the key twice, once as signing key and once as decryption key,
and switches around. other software libraries create a decryption key,
and use that one for signing too (by doing the padding etc. for signing
in the library). so different workarounds lead to different solutions,
that might show up via pkcs#11 api in some details, too.
Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
