Re: [opensc-devel] Verification of send/receive Limits

2010-11-30 Thread Martin Paljak

On Nov 30, 2010, at 3:30 PM, Ludovic Rousseau wrote:

> 2010/11/25 Andre Zepezauer :
>> Thanks for help. Please remove these two lines:
>> http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-entersafe.c#L137
> 
> pkcs15-init: card-entersafe.c:383: entersafe_read_binary: Assertion
> `count <= card->max_recv_size' failed.
Production code should be compiled with --disable-assert. In that specific case 
the assert should take into account the "no restrictions" limit.




-- 
@MartinPaljak.net
+3725156495

___
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-30 Thread Ludovic Rousseau
2010/11/25 Andre Zepezauer :
> Thanks for help. Please remove these two lines:
> http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-entersafe.c#L137

pkcs15-init: card-entersafe.c:383: entersafe_read_binary: Assertion
`count <= card->max_recv_size' failed.

card->max_recv_size is set to 0. So the assertion fails.

So I used:
card->max_send_size = 255;
card->max_recv_size = 256;

And it worked. typescript attached.

Extract:
0xb73976c0 14:16:05.481 [pkcs15-init] card.c:500:sc_update_binary:
called; 255 bytes at index 0
0xb73976c0 14:16:05.481 [pkcs15-init]
card-entersafe.c:408:entersafe_update_binary: called
0xb73976c0 14:16:05.481 [pkcs15-init]
card-entersafe.c:326:entersafe_transmit_apdu: called
0xb73976c0 14:16:05.481 [pkcs15-init] apdu.c:187:sc_apdu_log:
Outgoing APDU data [  260 bytes] =
00 D6 00 00 FF 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 6D 70 2D 68 2A 0A 0A 2E 64 65 70 s.stamp-h*...dep
73 0A 2E 6C 69 62 73 0A 2E 23 2A 23 0A 2E 2A 2E s..libs..#*#..*.
62 61 6B 0A bak.
==
0xb73976c0 14:16:05.481 [pkcs15-init] apdu.c:527:sc_transmit_apdu: called

I can reread the object with no error and no corruption using:
$ pkcs11-tool --read-object --type data --login --pin  --label MyObject

Anything else I can do for you?

-- 
 Dr. Ludovic Rousseau


typescript.bz2
Description: BZip2 compressed data
___
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

[opensc-devel] Verification of send/receive Limits

2010-11-23 Thread 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.

Kind Regards
Andre Zepezauer

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel