Re: [opensc-devel] #252
On Wed, 2010-11-03 at 18:54 +0100, Viktor TARASOV wrote: > Andre Zepezauer wrote: > > On Tue, 2010-11-02 at 09:05 +0100, Ludovic Rousseau wrote: > > > >> 2010/11/1 Andre Zepezauer : > >> > >>> Hello, > >>> > >>> the pkcs15init tool currently writes to cards, even when the profile > >>> indication (3F00/5015/4946) isn't found. That's bad, because it's highly > >>> possible that such a card was personalised with another library or has > >>> an unknown profile. In my opinion there are the following issues: > >>> > >>> 1. opensc isn't smart enough to do such things (see #252) > >>> 2. after a successful write operation the TokenInfo is overridden, which > >>> * is incomplete and > >>> * contains broken ASN1 encoding > >>> > >>> The attached patch prevents that behaviour and fixes #252. It is for > >>> current trunk. But should work for 0.11.13 too. > >>> > >> Fixed in revision 4853. > >> > >> I have not closed ticker #252 because I am not sure the problems are > >> related. (and I have not read ticket #252 in detail). > >> > Neither do I. > It would be nice to have full logs and to get know what's going on between > 'Please enter Unspecified PIN ...' > and > '... cardos_check_sw: function/mode not supported' > > > > > The user reporting the bug has a card manufactured by Siemens. > > Personalisation was done by the card vendors software (HiPath). > > Therefore the card doesn't have the file 3F00/5015/4946 on it. With this > > patch applied, the output of pkcs15-init looks like this: > > > > $pkcs15-init --generate-key rsa/1024 --auth-id 01 -v > > Using card driver Siemens CardOS. > > Couldn't bind to the card: File not found > > > > This is the correct behaviour, because the profile indication > > (3F00/5015/4946) is missing. And refusing to modify cards without > > knowing the exact profile, is good practise anyway. > > > > Imho, the main reason to use PKCS#15 is interoperability between different > card and middlewares in the card initialization and card using, and so, > OpenSC should operate with the cards initialized by other middlewares. Agreed. > Probably the on-card profile indication should be removed at all > (afais, it's main purpose is to distinguish 'one-pin' and 'normal' > pkcs15 profile). Yes, the *current* profile indication should be removed. It should be replaced with the mechanism according iso-7816 (CIAInfo.profileIndication). When doing it the right way, it would benefit interoperability. Let me explain: For example an implementation with full support of ACR (access control rules) could specify something like this: Access to an object X is granted, if A_01 && A_02 && not(A_03) has been verified. Where A_01 uses pin-authentication and A_02 uses external-authentication and A_03 must not have been verified at all. With different security environments it is even more complicated. Not every implementation would understand this, for sure. Therefore profile indication could be uses to indicate a specific coverage of features an implementation must understand. Do you know of any such use of profileIndication? I would assume that such things still exists. In example defined by national agencies. Regards Andre ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] #252
Andre Zepezauer wrote: > On Tue, 2010-11-02 at 09:05 +0100, Ludovic Rousseau wrote: > >> 2010/11/1 Andre Zepezauer : >> >>> Hello, >>> >>> the pkcs15init tool currently writes to cards, even when the profile >>> indication (3F00/5015/4946) isn't found. That's bad, because it's highly >>> possible that such a card was personalised with another library or has >>> an unknown profile. In my opinion there are the following issues: >>> >>> 1. opensc isn't smart enough to do such things (see #252) >>> 2. after a successful write operation the TokenInfo is overridden, which >>> * is incomplete and >>> * contains broken ASN1 encoding >>> >>> The attached patch prevents that behaviour and fixes #252. It is for >>> current trunk. But should work for 0.11.13 too. >>> >> Fixed in revision 4853. >> >> I have not closed ticker #252 because I am not sure the problems are >> related. (and I have not read ticket #252 in detail). >> Neither do I. It would be nice to have full logs and to get know what's going on between 'Please enter Unspecified PIN ...' and '... cardos_check_sw: function/mode not supported' > > The user reporting the bug has a card manufactured by Siemens. > Personalisation was done by the card vendors software (HiPath). > Therefore the card doesn't have the file 3F00/5015/4946 on it. With this > patch applied, the output of pkcs15-init looks like this: > > $pkcs15-init --generate-key rsa/1024 --auth-id 01 -v > Using card driver Siemens CardOS. > Couldn't bind to the card: File not found > > This is the correct behaviour, because the profile indication > (3F00/5015/4946) is missing. And refusing to modify cards without > knowing the exact profile, is good practise anyway. > Imho, the main reason to use PKCS#15 is interoperability between different card and middlewares in the card initialization and card using, and so, OpenSC should operate with the cards initialized by other middlewares. Probably the on-card profile indication should be removed at all (afais, it's main purpose is to distinguish 'one-pin' and 'normal' pkcs15 profile). Pkcs15init has to detect a valid pkcs#15 structure and bind card to the card profile (automatically detected or from command line argument). This card profile is used mostly when creating data (file or SDOs) of the new objects, the rest of the operations use an available on-card information (existing PKCS#15, ACLs). Kind wishes, Viktor. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4853] sc_pkcs15init_read_info(): do not call sc_pkcs15init_parse_info() if
On Wed, 2010-11-03 at 17:19 +0100, Andre Zepezauer wrote:
> On Wed, 2010-11-03 at 17:15 +0100, Ludovic Rousseau wrote:
> > 2010/11/3 Andre Zepezauer :
> > > On Wed, 2010-11-03 at 10:11 +0100, Viktor TARASOV wrote:
> > >> webmas...@opensc-project.org wrote:
> > >> > Revision: 4853
> > >> > Author: ludovic.rousseau
> > >> > Date: 2010-11-02 07:59:46 + (Tue, 02 Nov 2010)
> > >> >
> > >> > Log Message:
> > >> > ---
> > >> > sc_pkcs15init_read_info(): do not call sc_pkcs15init_parse_info() if
> > >> > sc_select_file() failed.
> > >> >
> > >> > Thanks to Andre Zepezauer for the patch
> > >> > http://www.opensc-project.org/pipermail/opensc-devel/2010-November/015216.html
> > >> >
> > >> > Modified Paths:
> > >> > --
> > >> > trunk/src/pkcs15init/pkcs15-lib.c
> > >> >
> > >> > Modified: trunk/src/pkcs15init/pkcs15-lib.c
> > >> > ===
> > >> > --- trunk/src/pkcs15init/pkcs15-lib.c 2010-11-01 15:44:17 UTC
> > >> > (rev 4852)
> > >> > +++ trunk/src/pkcs15init/pkcs15-lib.c 2010-11-02 07:59:46 UTC
> > >> > (rev 4853)
> > >> > @@ -3518,8 +3518,6 @@
> > >> > if ((mem = malloc(len)) != NULL) {
> > >> > r = sc_read_binary(card, 0, mem, len, 0);
> > >> > }
> > >> > - } else {
> > >> > - r = 0;
> > >> > }
> > >> >
> > >> > if (r >= 0)
> > >> >
> > >>
> > >> After this change non-initialized card cannot be initialized with
> > >> 'pkcs15-init' tool.
> > >>
> > >> At this line
> > >> http://www.opensc-project.org/opensc/browser/trunk/src/tools/pkcs15-init.c#L436
> > >> 'sc_pkcs15init_bind()' should not fail for the non-initialized card.
> > >
> > > Correct. Before binding the p15app it should be checked, if command line
> > > parameter -C was given. If it was:
> > >
> > > * given, then create a new p15app
> > > * not given, then bind the p15app which may fail if there is no p15app
> >
> > Can you propose a patch?
When creating new p15 data structures, the profile can be specified like
this: pkcs15-init -C -c cardos -p pkcs15
But should the following command be possible:
pkcs15-init -W data.bin -c cardos -p pkcs15 -a 01
In other words, should it be allowed to specify a specific profile even
when the card is still initialised?
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4853] sc_pkcs15init_read_info(): do not call sc_pkcs15init_parse_info() if
2010/11/3 Andre Zepezauer :
> On Wed, 2010-11-03 at 10:11 +0100, Viktor TARASOV wrote:
>> webmas...@opensc-project.org wrote:
>> > Revision: 4853
>> > Author: ludovic.rousseau
>> > Date: 2010-11-02 07:59:46 + (Tue, 02 Nov 2010)
>> >
>> > Log Message:
>> > ---
>> > sc_pkcs15init_read_info(): do not call sc_pkcs15init_parse_info() if
>> > sc_select_file() failed.
>> >
>> > Thanks to Andre Zepezauer for the patch
>> > http://www.opensc-project.org/pipermail/opensc-devel/2010-November/015216.html
>> >
>> > Modified Paths:
>> > --
>> > trunk/src/pkcs15init/pkcs15-lib.c
>> >
>> > Modified: trunk/src/pkcs15init/pkcs15-lib.c
>> > ===
>> > --- trunk/src/pkcs15init/pkcs15-lib.c 2010-11-01 15:44:17 UTC (rev
>> > 4852)
>> > +++ trunk/src/pkcs15init/pkcs15-lib.c 2010-11-02 07:59:46 UTC (rev
>> > 4853)
>> > @@ -3518,8 +3518,6 @@
>> > if ((mem = malloc(len)) != NULL) {
>> > r = sc_read_binary(card, 0, mem, len, 0);
>> > }
>> > - } else {
>> > - r = 0;
>> > }
>> >
>> > if (r >= 0)
>> >
>>
>> After this change non-initialized card cannot be initialized with
>> 'pkcs15-init' tool.
>>
>> At this line
>> http://www.opensc-project.org/opensc/browser/trunk/src/tools/pkcs15-init.c#L436
>> 'sc_pkcs15init_bind()' should not fail for the non-initialized card.
>
> Correct. Before binding the p15app it should be checked, if command line
> parameter -C was given. If it was:
>
> * given, then create a new p15app
> * not given, then bind the p15app which may fail if there is no p15app
Can you propose a patch?
Thanks
--
Dr. Ludovic Rousseau
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4853] sc_pkcs15init_read_info(): do not call sc_pkcs15init_parse_info() if
On Wed, 2010-11-03 at 17:15 +0100, Ludovic Rousseau wrote:
> 2010/11/3 Andre Zepezauer :
> > On Wed, 2010-11-03 at 10:11 +0100, Viktor TARASOV wrote:
> >> webmas...@opensc-project.org wrote:
> >> > Revision: 4853
> >> > Author: ludovic.rousseau
> >> > Date: 2010-11-02 07:59:46 + (Tue, 02 Nov 2010)
> >> >
> >> > Log Message:
> >> > ---
> >> > sc_pkcs15init_read_info(): do not call sc_pkcs15init_parse_info() if
> >> > sc_select_file() failed.
> >> >
> >> > Thanks to Andre Zepezauer for the patch
> >> > http://www.opensc-project.org/pipermail/opensc-devel/2010-November/015216.html
> >> >
> >> > Modified Paths:
> >> > --
> >> > trunk/src/pkcs15init/pkcs15-lib.c
> >> >
> >> > Modified: trunk/src/pkcs15init/pkcs15-lib.c
> >> > ===
> >> > --- trunk/src/pkcs15init/pkcs15-lib.c 2010-11-01 15:44:17 UTC (rev
> >> > 4852)
> >> > +++ trunk/src/pkcs15init/pkcs15-lib.c 2010-11-02 07:59:46 UTC (rev
> >> > 4853)
> >> > @@ -3518,8 +3518,6 @@
> >> > if ((mem = malloc(len)) != NULL) {
> >> > r = sc_read_binary(card, 0, mem, len, 0);
> >> > }
> >> > - } else {
> >> > - r = 0;
> >> > }
> >> >
> >> > if (r >= 0)
> >> >
> >>
> >> After this change non-initialized card cannot be initialized with
> >> 'pkcs15-init' tool.
> >>
> >> At this line
> >> http://www.opensc-project.org/opensc/browser/trunk/src/tools/pkcs15-init.c#L436
> >> 'sc_pkcs15init_bind()' should not fail for the non-initialized card.
> >
> > Correct. Before binding the p15app it should be checked, if command line
> > parameter -C was given. If it was:
> >
> > * given, then create a new p15app
> > * not given, then bind the p15app which may fail if there is no p15app
>
> Can you propose a patch?
I will try.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] fixes #220
Andre Zepezauer wrote: > On Wed, 2010-11-03 at 10:48 +0100, Viktor TARASOV wrote: > >> Andre Zepezauer wrote: >> >>> On Tue, 2010-11-02 at 21:54 +, Mr Dash Four wrote: >>> >>> > Opensc-explorer shows me the content of CIAInfo.bin without > pin-verification. Does that answer your question? > > > Yeah, just about. Why do you think that is? Could this be a manufacturer-related issue? >>> No, that's a new bug in OpenSC. Somewhere in the framework (especially >>> in pkcs15init), the access conditions are handled the wrong way. >>> >>> >> What card are you using? >> What card profile are you using? >> Can you post here the debug (=8) logs from your >> card initialization and 'create data object' sequence, please? >> >> >> With CardOS v4.3b I'm getting the expected results: >> >> # cardos-tool -f >> Using reader with a card: OmniKey CardMan 3121 00 00 >> card in administrative state, ok >> >> # pkcs15-init -E >> Using reader with a card: OmniKey CardMan 3121 00 00 >> >> # pkcs15-init -C --label "IDX-SCM" -P --auth-id 53434D --so-pin >> "12345678" --so-puk "123456" --pin "" --puk "" >> Using reader with a card: OmniKey CardMan 3121 00 00 >> >> # pkcs15-init -W ../tests/sha1.hex --label "MyLabel" --application-name >> "MyData" --application-id "1.2.3.4.5.6" --auth-id 53434D --pin "" >> Using reader with a card: OmniKey CardMan 3121 00 00 >> Security officer PIN [Security Officer PIN] required. >> Please enter Security officer PIN [Security Officer PIN]: >> >> # pkcs15-tool -C >> Using reader with a card: OmniKey CardMan 3121 00 00 >> Reading data object <0> >> applicationName: MyData >> Label: MyLabel >> applicationOID: 1.2.3.4.5.6 >> Path:3f0050153403 >> Auth ID: 53434d >> >> # opensc-explorer >> OpenSC Explorer version 0.12.0-rc1 >> Using reader with a card: OmniKey CardMan 3121 00 00 >> OpenSC [3F00]> cd 5015 >> OpenSC [3F00/5015]> cat 3403 >> read failed: Security status not satisfied >> ACL for operation: CHV3 >> OpenSC [3F00/5015]> verify CHV3 39:39:39:39:00:00:00:00 >> Code correct. >> OpenSC [3F00/5015]> cat 3403 >> : 66 37 65 34 30 63 32 30 34 39 66 39 34 32 66 33 f7e40c2049f942f3 >> 0010: 65 34 35 64 39 36 34 37 34 32 34 30 30 33 34 39 e45d964742400349 >> 0020: 64 36 64 30 63 65 37 34 0A d6d0ce74. >> OpenSC [3F00/5015]> >> > > $pkcs15-init -C -c cardos -p pkcs15 --so-pin=12345678 > Unblock Code for New User PIN (Optional - press return for no PIN). > Please enter User unblocking PIN (PUK): [[return]] > With such card initialisation it's quite natural to have non-protected 'private data'. File operations on the 'Private data' are protected by UserPIN: http://www.opensc-project.org/opensc/browser/trunk/src/pkcs15init/cardos.profile#L108 If UserPIN is not defined, then, when creating new file, the corresponding ACLs are set to 'NONE': http://www.opensc-project.org/opensc/browser/trunk/src/pkcs15init/pkcs15-lib.c#L3387 > $pkcs15-init -W CIAInfo.bin --application-id "1.2.3" -l "MyObject" -a ff > Security officer PIN [Security Officer PIN] required. > Please enter Security officer PIN [Security Officer PIN]: 12345678 > > Now use opensc-explorer. Yesterday I had this working with user-pins > too. Will try to reproduce that later. > -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Problem with 0.12.0 RC1
Hi, I have been testing the 0.12.0 RC1 and Im having problems with it when using MyEID cards. I traced the problem, and found out that the setting max_recv_size in opensc.conf file for the reader pcsc has no effect, the value seems to be always 0, and therefore the limitations wont apply. I think this is an issue only for T=1 cards. I created a new ticket for this, #269 (http://www.opensc-project.org/opensc/ticket/269) Regards, Toni ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] FW: Problem with 0.12.0 RC1
Retry, the previous message try apparently did not go through. From: Aventra development [mailto:developm...@aventra.fi] Sent: 3. marraskuuta 2010 15:38 To: 'OpenSC-devel' Subject: Problem with 0.12.0 RC1 Hi, I have been testing the 0.12.0 RC1 and Im having problems with it when using MyEID cards. I traced the problem, and found out that the setting max_recv_size in opensc.conf file for the reader pcsc has no effect, the value seems to be always 0, and therefore the limitations wont apply. I think this is an issue only for T=1 cards. I created a new ticket for this, #269 (http://www.opensc-project.org/opensc/ticket/269) Regards, Toni ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] fixes #220
On Wed, 2010-11-03 at 10:48 +0100, Viktor TARASOV wrote: > Andre Zepezauer wrote: > > On Tue, 2010-11-02 at 21:54 +, Mr Dash Four wrote: > > > >>> Opensc-explorer shows me the content of CIAInfo.bin without > >>> pin-verification. Does that answer your question? > >>> > >>> > >> Yeah, just about. Why do you think that is? Could this be a > >> manufacturer-related issue? > >> > > > > No, that's a new bug in OpenSC. Somewhere in the framework (especially > > in pkcs15init), the access conditions are handled the wrong way. > > > > What card are you using? > What card profile are you using? > Can you post here the debug (=8) logs from your > card initialization and 'create data object' sequence, please? > > > With CardOS v4.3b I'm getting the expected results: > > # cardos-tool -f > Using reader with a card: OmniKey CardMan 3121 00 00 > card in administrative state, ok > > # pkcs15-init -E > Using reader with a card: OmniKey CardMan 3121 00 00 > > # pkcs15-init -C --label "IDX-SCM" -P --auth-id 53434D --so-pin > "12345678" --so-puk "123456" --pin "" --puk "" > Using reader with a card: OmniKey CardMan 3121 00 00 > > # pkcs15-init -W ../tests/sha1.hex --label "MyLabel" --application-name > "MyData" --application-id "1.2.3.4.5.6" --auth-id 53434D --pin "" > Using reader with a card: OmniKey CardMan 3121 00 00 > Security officer PIN [Security Officer PIN] required. > Please enter Security officer PIN [Security Officer PIN]: > > # pkcs15-tool -C > Using reader with a card: OmniKey CardMan 3121 00 00 > Reading data object <0> > applicationName: MyData > Label: MyLabel > applicationOID: 1.2.3.4.5.6 > Path:3f0050153403 > Auth ID: 53434d > > # opensc-explorer > OpenSC Explorer version 0.12.0-rc1 > Using reader with a card: OmniKey CardMan 3121 00 00 > OpenSC [3F00]> cd 5015 > OpenSC [3F00/5015]> cat 3403 > read failed: Security status not satisfied > ACL for operation: CHV3 > OpenSC [3F00/5015]> verify CHV3 39:39:39:39:00:00:00:00 > Code correct. > OpenSC [3F00/5015]> cat 3403 > : 66 37 65 34 30 63 32 30 34 39 66 39 34 32 66 33 f7e40c2049f942f3 > 0010: 65 34 35 64 39 36 34 37 34 32 34 30 30 33 34 39 e45d964742400349 > 0020: 64 36 64 30 63 65 37 34 0A d6d0ce74. > OpenSC [3F00/5015]> $pkcs15-init -C -c cardos -p pkcs15 --so-pin=12345678 Unblock Code for New User PIN (Optional - press return for no PIN). Please enter User unblocking PIN (PUK): [[return]] $pkcs15-init -W CIAInfo.bin --application-id "1.2.3" -l "MyObject" -a ff Security officer PIN [Security Officer PIN] required. Please enter Security officer PIN [Security Officer PIN]: 12345678 Now use opensc-explorer. Yesterday I had this working with user-pins too. Will try to reproduce that later. Using reader with a card: OMNIKEY CardMan 5x21 (USB iClass Reader) 00 00 Using reader with a card: OMNIKEY CardMan 5x21 (USB iClass Reader) 00 00 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4853] sc_pkcs15init_read_info(): do not call sc_pkcs15init_parse_info() if
On Wed, 2010-11-03 at 10:11 +0100, Viktor TARASOV wrote:
> webmas...@opensc-project.org wrote:
> > Revision: 4853
> > Author: ludovic.rousseau
> > Date: 2010-11-02 07:59:46 + (Tue, 02 Nov 2010)
> >
> > Log Message:
> > ---
> > sc_pkcs15init_read_info(): do not call sc_pkcs15init_parse_info() if
> > sc_select_file() failed.
> >
> > Thanks to Andre Zepezauer for the patch
> > http://www.opensc-project.org/pipermail/opensc-devel/2010-November/015216.html
> >
> > Modified Paths:
> > --
> > trunk/src/pkcs15init/pkcs15-lib.c
> >
> > Modified: trunk/src/pkcs15init/pkcs15-lib.c
> > ===
> > --- trunk/src/pkcs15init/pkcs15-lib.c 2010-11-01 15:44:17 UTC (rev
> > 4852)
> > +++ trunk/src/pkcs15init/pkcs15-lib.c 2010-11-02 07:59:46 UTC (rev
> > 4853)
> > @@ -3518,8 +3518,6 @@
> > if ((mem = malloc(len)) != NULL) {
> > r = sc_read_binary(card, 0, mem, len, 0);
> > }
> > - } else {
> > - r = 0;
> > }
> >
> > if (r >= 0)
> >
>
> After this change non-initialized card cannot be initialized with
> 'pkcs15-init' tool.
>
> At this line
> http://www.opensc-project.org/opensc/browser/trunk/src/tools/pkcs15-init.c#L436
> 'sc_pkcs15init_bind()' should not fail for the non-initialized card.
Correct. Before binding the p15app it should be checked, if command line
parameter -C was given. If it was:
* given, then create a new p15app
* not given, then bind the p15app which may fail if there is no p15app
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CardOS 4.4
Hi Andre, JP, The default Factory FF startkey is not 0x... like with Cardos 4.3B. Kind Regards, Vital Schonkeren -Original Message- From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of JP Szikora Sent: woensdag 3 november 2010 11:55 To: Andre Zepezauer Cc: opensc-devel Subject: Re: [opensc-devel] CardOS 4.4 Hi Andre, Which software did you try? I have no problem with pkcs15-init -C, -S , -U or -X. Cheers, Jean-Pierre Andre Zepezauer a écrit : > Hello, > > today I have gotten some blank smart cards with CardOS 4.4. Sadly the > software to personalise 4.3b doesn't work for the newer cards. Does > anyone know, which software I need for personalisation? > > Regards > Andre > > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] CardOS 4.4
Hi Andre, Which software did you try? I have no problem with pkcs15-init -C, -S , -U or -X. Cheers, Jean-Pierre Andre Zepezauer a écrit : > Hello, > > today I have gotten some blank smart cards with CardOS 4.4. Sadly the > software to personalise 4.3b doesn't work for the newer cards. Does > anyone know, which software I need for personalisation? > > Regards > Andre > > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] [PATCH] [libp11] pkcs11_init_slot: Do not fail if a slot can't be initialized
In some case readers can be wired to always return
CKF_TOKEN_PRESENT even when there's no card (Because there's no
mechanical contacts for card insertion, like some SIMcard readers).
This patch fix the issue of PKCS11_enumerate_slots() failing because
one of the readers reported a token present but pkcs11_check_token
failed.diff --git a/src/p11_slot.c b/src/p11_slot.c
index 35a8cd1..d14a16a 100644
--- a/src/p11_slot.c
+++ b/src/p11_slot.c
@@ -309,19 +309,27 @@ static int pkcs11_init_slot(PKCS11_CTX * ctx, PKCS11_SLOT * slot, CK_SLOT_ID id)
int rv;
rv = CRYPTOKI_call(ctx, C_GetSlotInfo(id, &info));
- CRYPTOKI_checkerr(PKCS11_F_PKCS11_ENUM_SLOTS, rv);
priv = PKCS11_NEW(PKCS11_SLOT_private);
priv->parent = ctx;
priv->id = id;
- slot->description = PKCS11_DUP(info.slotDescription);
- slot->manufacturer = PKCS11_DUP(info.manufacturerID);
- slot->removable = (info.flags & CKF_REMOVABLE_DEVICE) ? 1 : 0;
slot->_private = priv;
-
- if ((info.flags & CKF_TOKEN_PRESENT) && pkcs11_check_token(ctx, slot))
- return -1;
+ if (!rv) {
+ slot->description = PKCS11_DUP(info.slotDescription);
+ slot->manufacturer = PKCS11_DUP(info.manufacturerID);
+ slot->removable = (info.flags & CKF_REMOVABLE_DEVICE) ? 1 : 0;
+ if ((info.flags & CKF_TOKEN_PRESENT) && pkcs11_check_token(ctx, slot))
+ slot->token = NULL;
+ }
+ else {
+ char desc[64];
+ snprintf(desc, sizeof(desc), "(GetSlotInfo failed, error %d)", rv);
+ slot->description = PKCS11_DUP(desc);
+ slot->manufacturer = PKCS11_DUP("Unknown");
+ slot->removable = 0;
+ slot->token = NULL;
+ }
return 0;
}
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] fixes #220
Andre Zepezauer wrote: > On Tue, 2010-11-02 at 21:54 +, Mr Dash Four wrote: > >>> Opensc-explorer shows me the content of CIAInfo.bin without >>> pin-verification. Does that answer your question? >>> >>> >> Yeah, just about. Why do you think that is? Could this be a >> manufacturer-related issue? >> > > No, that's a new bug in OpenSC. Somewhere in the framework (especially > in pkcs15init), the access conditions are handled the wrong way. > What card are you using? What card profile are you using? Can you post here the debug (=8) logs from your card initialization and 'create data object' sequence, please? With CardOS v4.3b I'm getting the expected results: # cardos-tool -f Using reader with a card: OmniKey CardMan 3121 00 00 card in administrative state, ok # pkcs15-init -E Using reader with a card: OmniKey CardMan 3121 00 00 # pkcs15-init -C --label "IDX-SCM" -P --auth-id 53434D --so-pin "12345678" --so-puk "123456" --pin "" --puk "" Using reader with a card: OmniKey CardMan 3121 00 00 # pkcs15-init -W ../tests/sha1.hex --label "MyLabel" --application-name "MyData" --application-id "1.2.3.4.5.6" --auth-id 53434D --pin "" Using reader with a card: OmniKey CardMan 3121 00 00 Security officer PIN [Security Officer PIN] required. Please enter Security officer PIN [Security Officer PIN]: # pkcs15-tool -C Using reader with a card: OmniKey CardMan 3121 00 00 Reading data object <0> applicationName: MyData Label: MyLabel applicationOID: 1.2.3.4.5.6 Path:3f0050153403 Auth ID: 53434d # opensc-explorer OpenSC Explorer version 0.12.0-rc1 Using reader with a card: OmniKey CardMan 3121 00 00 OpenSC [3F00]> cd 5015 OpenSC [3F00/5015]> cat 3403 read failed: Security status not satisfied ACL for operation: CHV3 OpenSC [3F00/5015]> verify CHV3 39:39:39:39:00:00:00:00 Code correct. OpenSC [3F00/5015]> cat 3403 : 66 37 65 34 30 63 32 30 34 39 66 39 34 32 66 33 f7e40c2049f942f3 0010: 65 34 35 64 39 36 34 37 34 32 34 30 30 33 34 39 e45d964742400349 0020: 64 36 64 30 63 65 37 34 0A d6d0ce74. OpenSC [3F00/5015]> Kind wishes Viktor. -- Viktor Tarasov ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4853] sc_pkcs15init_read_info(): do not call sc_pkcs15init_parse_info() if
webmas...@opensc-project.org wrote:
> Revision: 4853
> Author: ludovic.rousseau
> Date: 2010-11-02 07:59:46 + (Tue, 02 Nov 2010)
>
> Log Message:
> ---
> sc_pkcs15init_read_info(): do not call sc_pkcs15init_parse_info() if
> sc_select_file() failed.
>
> Thanks to Andre Zepezauer for the patch
> http://www.opensc-project.org/pipermail/opensc-devel/2010-November/015216.html
>
> Modified Paths:
> --
> trunk/src/pkcs15init/pkcs15-lib.c
>
> Modified: trunk/src/pkcs15init/pkcs15-lib.c
> ===
> --- trunk/src/pkcs15init/pkcs15-lib.c 2010-11-01 15:44:17 UTC (rev 4852)
> +++ trunk/src/pkcs15init/pkcs15-lib.c 2010-11-02 07:59:46 UTC (rev 4853)
> @@ -3518,8 +3518,6 @@
> if ((mem = malloc(len)) != NULL) {
> r = sc_read_binary(card, 0, mem, len, 0);
> }
> - } else {
> - r = 0;
> }
>
> if (r >= 0)
>
After this change non-initialized card cannot be initialized with
'pkcs15-init' tool.
At this line
http://www.opensc-project.org/opensc/browser/trunk/src/tools/pkcs15-init.c#L436
'sc_pkcs15init_bind()' should not fail for the non-initialized card.
> ___
> opensc-commits mailing list
> opensc-comm...@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-commits
>
>
--
Viktor Tarasov
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
