[opensc-devel] pkcs11-tool

2010-11-25 Thread Andre Zepezauer
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

2010-11-25 Thread Andre Zepezauer
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-25 Thread Ludovic Rousseau
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