[opensc-devel] pkcs11-tool
Hello, I would like to commit the attached patch. It modifies the method of public key retrieval in pkcs11-tool. Currently the non standard attribute CKA_VALUE is uses. With the patch applied, only attributes defined by PKCS#11 are used for public key retrieval. Tested with OpenSSL 0.9.8. Regards Andre Index: src/tools/pkcs11-tool.c === --- src/tools/pkcs11-tool.c (revision 4880) +++ src/tools/pkcs11-tool.c (working copy) @@ -1930,6 +1930,7 @@ VARATTR_METHOD(ID, unsigned char); VARATTR_METHOD(OBJECT_ID, unsigned char); VARATTR_METHOD(MODULUS, unsigned char); +VARATTR_METHOD(PUBLIC_EXPONENT, unsigned char); VARATTR_METHOD(VALUE, unsigned char); VARATTR_METHOD(GOSTR3410_PARAMS, unsigned char); @@ -2490,13 +2491,14 @@ #ifdef ENABLE_OPENSSL static EVP_PKEY *get_public_key(CK_SESSION_HANDLE session, CK_OBJECT_HANDLE privKeyObject) { - unsigned char *id; - CK_ULONGidLen; + unsigned char *id, *modulus, *exponent; + CK_ULONGidLen, modLen, expLen; CK_OBJECT_HANDLE pubkeyObject; unsigned char *pubkey; const unsigned char *pubkey_c; CK_ULONGpubkeyLen; EVP_PKEY *pkey; + RSA*rsa; id = NULL; id = getID(session, privKeyObject, &idLen); @@ -2512,6 +2514,39 @@ } free(id); + switch(getKEY_TYPE(session, pubkeyObject)) { + case CKK_RSA: + pkey = EVP_PKEY_new(); + rsa = RSA_new(); + modulus = getMODULUS(session, pubkeyObject, &modLen); + exponent = getPUBLIC_EXPONENT(session, pubkeyObject, &expLen); + if ( !pkey || !rsa || !modulus || !exponent) { +printf("public key not extractable\n"); +if (pkey) + free(pkey); +if (rsa) + free(rsa); +if (modulus) + free(modulus); +if (exponent) + free(exponent); +return NULL; + } + rsa->n = BN_bin2bn(modulus, modLen, NULL); + rsa->e = BN_bin2bn(exponent, expLen, NULL); + EVP_PKEY_assign_RSA(pkey, rsa); + free(modulus); + free(exponent); + return pkey; + case CKK_DSA: + case CKK_ECDSA: + case CKK_GOSTR3410: + break; + default: + printf("public key of unsupported type\n"); + return NULL; + } + pubkey = getVALUE(session, pubkeyObject, &pubkeyLen); if (pubkey == NULL) { printf("couldn't get the pubkey VALUE attribute, no validation done\n"); ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Verification of send/receive Limits
On Thu, 2010-11-25 at 09:28 +0100, Ludovic Rousseau wrote: > 2010/11/23 Andre Zepezauer : > > Dear OpenSC developers, > > > > it seems to me that there are some myths in the OpenSC community about > > the send/receive limitations of cards and readers. > > > > In OpenSC there are two places where limitations on send/receive sizes > > could be imposed. These are based on capabilities of cards and readers. > > Maybe there are cards with limitations, but at least ACOS5 and STARCOS > > shouldn't have. The ACOS5 manual states that it supports PUT DATA with > > Lc=255 (Section 5.28) and in the driver Le=256 is used several times. > > The STARCOS 1.2 manual (published in 1996) doesn't state anything on > > send/receive limitations. Other candidates are westcos, which isn't a > > PKI card anyway and entersafe with manual available only under NDA. > > > > Complete list of effected cards looks like this: > > acos5, akis, atrust-acos, entersafe, gpk, miocos, starcos, westcos > > > > My assumption is, that some of the limitations are artificial and > > effected cards could send/receive more than they do at the moment. But I > > don't have one of these cards and therefore can't verify it myself. > > > > That's why I need your help. If you have one of these cards, then please > > remove the lines card->max_send_size, card->max_recv_size in the driver > > and run some tests afterwards. I.e. opensc-tool -f would be fine. Or > > just write some data objects with: > > pkcs15-init -W [file] --application-id "1.2.3" --label "MyObject" -a 01 > > > > Please include log-files with APDU sequences in your reply. Vendor and > > Model of reader would be helpful too. > > Log using a Feitian card and a GemPC Twin reader [1]. > I also join the file I wrote on the card. It is the "svnignore" file > from the SVN repository :-) > > I am not sure the test is useful. I get: > 0xb74486c0 09:15:20.036 [pkcs15-init] apdu.c:187:sc_apdu_log: > Outgoing APDU data [ 229 bytes] = > 00 D6 00 00 E0 4D 61 6B 65 66 69 6C 65 0A 4D 61 .Makefile.Ma > 6B 65 66 69 6C 65 2E 69 6E 0A 63 6F 72 65 0A 61 kefile.in.core.a > 72 63 68 69 76 65 0A 61 63 69 6E 63 6C 75 64 65 rchive.acinclude > 2E 6D 34 0A 61 63 6C 6F 63 61 6C 2E 6D 34 0A 61 .m4.aclocal.m4.a > 75 74 6F 6D 34 74 65 2E 63 61 63 68 65 0A 63 6F utom4te.cache.co > 6D 70 69 6C 65 0A 63 6F 6E 66 64 65 66 73 2E 68 mpile.confdefs.h > 0A 63 6F 6E 66 69 67 2E 2A 0A 63 6F 6E 66 69 67 .config.*.config > 75 72 65 0A 63 6F 6E 66 74 65 73 74 0A 63 6F 6E ure.conftest.con > 66 74 65 73 74 2E 63 0A 64 65 70 63 6F 6D 70 0A ftest.c.depcomp. > 69 6E 73 74 61 6C 6C 2D 73 68 0A 6C 69 62 74 6F install-sh.libto > 6F 6C 0A 6C 69 62 74 6F 6F 6C 2E 6D 34 0A 6C 74 ol.libtool.m4.lt > 2A 2E 6D 34 0A 6C 74 6D 61 69 6E 2E 73 68 0A 6D *.m4.ltmain.sh.m > 69 73 73 69 6E 67 0A 6D 6B 69 6E 73 74 61 6C 6C issing.mkinstall > 64 69 72 73 0A 73 6F 5F 6C 6F 63 61 74 69 6F 6E dirs.so_location > 73 0A 73 74 61 s.sta > == > 0xb74486c0 09:15:20.036 [pkcs15-init] apdu.c:527:sc_transmit_apdu: called > 0xb74486c0 09:15:20.036 [pkcs15-init] card.c:295:sc_lock: called > 0xb74486c0 09:15:20.036 [pkcs15-init] reader-pcsc.c:231:pcsc_transmit: > reader 'Gemalto GemPC Twin 00 00' > 0xb74486c0 09:15:20.036 [pkcs15-init] apdu.c:187:sc_apdu_log: > Outgoing APDU data [ 229 bytes] = > 00 D6 00 00 E0 4D 61 6B 65 66 69 6C 65 0A 4D 61 .Makefile.Ma > 6B 65 66 69 6C 65 2E 69 6E 0A 63 6F 72 65 0A 61 kefile.in.core.a > 72 63 68 69 76 65 0A 61 63 69 6E 63 6C 75 64 65 rchive.acinclude > 2E 6D 34 0A 61 63 6C 6F 63 61 6C 2E 6D 34 0A 61 .m4.aclocal.m4.a > 75 74 6F 6D 34 74 65 2E 63 61 63 68 65 0A 63 6F utom4te.cache.co > 6D 70 69 6C 65 0A 63 6F 6E 66 64 65 66 73 2E 68 mpile.confdefs.h > 0A 63 6F 6E 66 69 67 2E 2A 0A 63 6F 6E 66 69 67 .config.*.config > 75 72 65 0A 63 6F 6E 66 74 65 73 74 0A 63 6F 6E ure.conftest.con > 66 74 65 73 74 2E 63 0A 64 65 70 63 6F 6D 70 0A ftest.c.depcomp. > 69 6E 73 74 61 6C 6C 2D 73 68 0A 6C 69 62 74 6F install-sh.libto > 6F 6C 0A 6C 69 62 74 6F 6F 6C 2E 6D 34 0A 6C 74 ol.libtool.m4.lt > 2A 2E 6D 34 0A 6C 74 6D 61 69 6E 2E 73 68 0A 6D *.m4.ltmain.sh.m > 69 73 73 69 6E 67 0A 6D 6B 69 6E 73 74 61 6C 6C issing.mkinstall > 64 69 72 73 0A 73 6F 5F 6C 6F 63 61 74 69 6F 6E dirs.so_location > 73 0A 73 74 61 s.sta > == > 0xb74486c0 09:15:20.036 [pkcs15-init] > reader-pcsc.c:164:pcsc_internal_transmit: called > 0xb74486c0 09:15:20.074 [pkcs15-init] apdu.c:187:sc_apdu_log: > Incoming APDU data [2 bytes] = > 90 00 .. > == > > The file is 658 bytes but sent in chunk of 229 bytes. > > $ grep max_ /etc/opensc/opensc.conf > #max_send_size = 252; >
Re: [opensc-devel] Verification of send/receive Limits
2010/11/23 Andre Zepezauer : > Dear OpenSC developers, > > it seems to me that there are some myths in the OpenSC community about > the send/receive limitations of cards and readers. > > In OpenSC there are two places where limitations on send/receive sizes > could be imposed. These are based on capabilities of cards and readers. > Maybe there are cards with limitations, but at least ACOS5 and STARCOS > shouldn't have. The ACOS5 manual states that it supports PUT DATA with > Lc=255 (Section 5.28) and in the driver Le=256 is used several times. > The STARCOS 1.2 manual (published in 1996) doesn't state anything on > send/receive limitations. Other candidates are westcos, which isn't a > PKI card anyway and entersafe with manual available only under NDA. > > Complete list of effected cards looks like this: > acos5, akis, atrust-acos, entersafe, gpk, miocos, starcos, westcos > > My assumption is, that some of the limitations are artificial and > effected cards could send/receive more than they do at the moment. But I > don't have one of these cards and therefore can't verify it myself. > > That's why I need your help. If you have one of these cards, then please > remove the lines card->max_send_size, card->max_recv_size in the driver > and run some tests afterwards. I.e. opensc-tool -f would be fine. Or > just write some data objects with: > pkcs15-init -W [file] --application-id "1.2.3" --label "MyObject" -a 01 > > Please include log-files with APDU sequences in your reply. Vendor and > Model of reader would be helpful too. Log using a Feitian card and a GemPC Twin reader [1]. I also join the file I wrote on the card. It is the "svnignore" file from the SVN repository :-) I am not sure the test is useful. I get: 0xb74486c0 09:15:20.036 [pkcs15-init] apdu.c:187:sc_apdu_log: Outgoing APDU data [ 229 bytes] = 00 D6 00 00 E0 4D 61 6B 65 66 69 6C 65 0A 4D 61 .Makefile.Ma 6B 65 66 69 6C 65 2E 69 6E 0A 63 6F 72 65 0A 61 kefile.in.core.a 72 63 68 69 76 65 0A 61 63 69 6E 63 6C 75 64 65 rchive.acinclude 2E 6D 34 0A 61 63 6C 6F 63 61 6C 2E 6D 34 0A 61 .m4.aclocal.m4.a 75 74 6F 6D 34 74 65 2E 63 61 63 68 65 0A 63 6F utom4te.cache.co 6D 70 69 6C 65 0A 63 6F 6E 66 64 65 66 73 2E 68 mpile.confdefs.h 0A 63 6F 6E 66 69 67 2E 2A 0A 63 6F 6E 66 69 67 .config.*.config 75 72 65 0A 63 6F 6E 66 74 65 73 74 0A 63 6F 6E ure.conftest.con 66 74 65 73 74 2E 63 0A 64 65 70 63 6F 6D 70 0A ftest.c.depcomp. 69 6E 73 74 61 6C 6C 2D 73 68 0A 6C 69 62 74 6F install-sh.libto 6F 6C 0A 6C 69 62 74 6F 6F 6C 2E 6D 34 0A 6C 74 ol.libtool.m4.lt 2A 2E 6D 34 0A 6C 74 6D 61 69 6E 2E 73 68 0A 6D *.m4.ltmain.sh.m 69 73 73 69 6E 67 0A 6D 6B 69 6E 73 74 61 6C 6C issing.mkinstall 64 69 72 73 0A 73 6F 5F 6C 6F 63 61 74 69 6F 6E dirs.so_location 73 0A 73 74 61 s.sta == 0xb74486c0 09:15:20.036 [pkcs15-init] apdu.c:527:sc_transmit_apdu: called 0xb74486c0 09:15:20.036 [pkcs15-init] card.c:295:sc_lock: called 0xb74486c0 09:15:20.036 [pkcs15-init] reader-pcsc.c:231:pcsc_transmit: reader 'Gemalto GemPC Twin 00 00' 0xb74486c0 09:15:20.036 [pkcs15-init] apdu.c:187:sc_apdu_log: Outgoing APDU data [ 229 bytes] = 00 D6 00 00 E0 4D 61 6B 65 66 69 6C 65 0A 4D 61 .Makefile.Ma 6B 65 66 69 6C 65 2E 69 6E 0A 63 6F 72 65 0A 61 kefile.in.core.a 72 63 68 69 76 65 0A 61 63 69 6E 63 6C 75 64 65 rchive.acinclude 2E 6D 34 0A 61 63 6C 6F 63 61 6C 2E 6D 34 0A 61 .m4.aclocal.m4.a 75 74 6F 6D 34 74 65 2E 63 61 63 68 65 0A 63 6F utom4te.cache.co 6D 70 69 6C 65 0A 63 6F 6E 66 64 65 66 73 2E 68 mpile.confdefs.h 0A 63 6F 6E 66 69 67 2E 2A 0A 63 6F 6E 66 69 67 .config.*.config 75 72 65 0A 63 6F 6E 66 74 65 73 74 0A 63 6F 6E ure.conftest.con 66 74 65 73 74 2E 63 0A 64 65 70 63 6F 6D 70 0A ftest.c.depcomp. 69 6E 73 74 61 6C 6C 2D 73 68 0A 6C 69 62 74 6F install-sh.libto 6F 6C 0A 6C 69 62 74 6F 6F 6C 2E 6D 34 0A 6C 74 ol.libtool.m4.lt 2A 2E 6D 34 0A 6C 74 6D 61 69 6E 2E 73 68 0A 6D *.m4.ltmain.sh.m 69 73 73 69 6E 67 0A 6D 6B 69 6E 73 74 61 6C 6C issing.mkinstall 64 69 72 73 0A 73 6F 5F 6C 6F 63 61 74 69 6F 6E dirs.so_location 73 0A 73 74 61 s.sta == 0xb74486c0 09:15:20.036 [pkcs15-init] reader-pcsc.c:164:pcsc_internal_transmit: called 0xb74486c0 09:15:20.074 [pkcs15-init] apdu.c:187:sc_apdu_log: Incoming APDU data [2 bytes] = 90 00 .. == The file is 658 bytes but sent in chunk of 229 bytes. $ grep max_ /etc/opensc/opensc.conf #max_send_size = 252; #max_recv_size = 252; #max_send_size = 252; #max_recv_size = 252; So no maximum size is configured in my OpenSC configuration. Should I configure something special for the test? Bye [1] http://pc