Am Freitag 11 Dezember 2009 17:20:04 schrieb Douglas E. Engert:
> Andreas Jellinghaus wrote:
> > running these commands would still help:
> >>> openssl dgst -md5 -binary -out digest_file < message_file
> >>> pkcs15-crypt -s --md5 --pkcs1 -i digest_file -o signature_file
> >>> openssl dgst -verify public_key_file -md5 -signature signature_file \
> >>>   < message_file
> 
> As another data point, On my Ubuntu Karmic with opensc 0.11.8-1ubuntu1
> using a PIV card to do a signature has worked directly with pkcs11-tool
> and the above commands:
> 
>   echo "foobar" > message_file
>   openssl dgst -md5 -binary -out digest_file < message_file
>   pkcs15-crypt -s --md5 --pkcs1 -i digest_file -o signature_file
>   pkcs15-tool -r 01 > cert.pem
>   openssl x509 -noout -pubkey < cert.pem > public_key_file
>   openssl dgst -verify public_key_file -md5 -signature signature_file <
>  message_file
> 
>   pkcs11-tool -s -m MD5-RSA-PKCS -l < message_file > signature_2_file
>   openssl dgst -verify public_key_file -md5 -signature signature_2_file <
>  message_file
> 
> So the problem may be in the card-starcos.c driver.

The card-starcos.c didn't change from 0.11.4 to 0.11.8, nor the starcos
related files in pkcs15init. 

so I wonder if we changed some default parameter somewhere, at least
I guess card-starcos.c gets wrong information about the data to be signed
(it should get information that an RSA signature is wanted and the data
is a MD5 hash. but it seems to get something else - no idea where it
comes from).

Or maybe we broke initialization, i.e. blank cards initialized with the
latest opensc will work, but cards initialized with some old opensc
won't work with the new opensc code. but I'm not aware of any incompatible
change. (well, except fixing the privdata bug, but it shouldn't affect
anything except privdata...)

the set security environment APDU contains payload 80 01 01, and
the only code to create that is:
        if (operation == SC_SEC_OPERATION_SIGN && (
            env->algorithm_flags & SC_ALGORITHM_RSA_PAD_PKCS1 ||
            env->algorithm_flags & SC_ALGORITHM_RSA_PAD_ISO9796)) {
                if (env->flags & SC_SEC_ENV_ALG_REF_PRESENT) {
                        *p++ = 0x80;
                        *p++ = 0x01;
                        *p++ = env->algorithm_ref & 0xFF;

source of the "env" variable is sc_pkcs15_compute_signature
function in libopensc/pkcs15-sec.c

but the code in pkcs15-sec.c doesn't set algorithm_ref at all.


ah pkcs15-sec.c has this code:
        senv.operation = SC_SEC_OPERATION_SIGN;
        senv.flags = 0;
        /* optional keyReference attribute (the default value is -1) */
        if (prkey->key_reference >= 0) {
                senv.key_ref_len = 1;
                senv.key_ref[0] = prkey->key_reference & 0xFF;
                senv.flags |= SC_SEC_ENV_KEY_REF_PRESENT;
        }
        senv.flags |= SC_SEC_ENV_ALG_PRESENT;

so the prkey->key_reference is ">= 0". hmm, they key_reference is stored
as key_ref, and a flag is set that leads to reading algorithm_ref instead?
sounds wrong to me.

if that would be "-1" instead, the right code path would be taken.

but I have no clue where that problem might come from.

anyone else any idea how things got wrong here?

dominik, if you have time for some hacking, you might add a debug lines
to pkcs15-sec.c to print prkey->key_reference and set it to "-1" for
testing if that solves the problem.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to