Re: [opensc-devel] The smart card reader is known as "VMware Virtual USB CCID 00 00" in linux ??!!
Hello and thanks for your complete and useful comment;
> (1) VMware remaps the card card name, and causes confusion with pcsc.
> If you could use a real machine that would eliminate this problem for
> now.
I've switched to linux just because of testing pkcs15-init (opensc-0.12.2) in
it as an alternative work, since I didn't success in windows (with
opensc-0.12.2 & 0.13.0).
I only want to initialize the card using pkcs15-init ( Windows or Linux? It's
not important. I can test on windows completely! )
Now, I'm going to test the card with opensc-0.13.0 on windows only.
> (2) You said:
> > installed Card Reader driver on fedora with name "ifdokccid.so"
> > (my Card Reader is Omnikey CardMan 3121).
> Is this really needed on unix? I thought pcscd would use its own
> libccid.so for this reader.
Apparently not!
> If this is a vendor provided library, what version are you using? Can you
> try without this file?
Version 3.7.0, I added smartcard-list.txt on Dr. Ludovic Rousseau site that
caused "pcsc_scan" recognizes my card (SmartCafe Expert 3.2 72k).
It seems there was no need to "ifdokccid.so" driver!
> (3) You said:
> > I've tested OpenSC-0.13.0 MSI on Windows7 and had the same problem in
> > pkcs15 initialization as 0.12.2 version!
> This would indicate that your real problem is with opensc most likely
> not recognizing the card. (The vendor's window driver works with windows
> but the vendor's unix driver may not work with the version of pcscd on
> fedora. The introduction of VMware just complicates the problems.
Yes, exactly.
> (4) You said the card is reported:
> > ATR: 3B F7 18 00 00 80 31 FE 45 73 66 74 65 2D 6E 66 C4
> > Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
> > 3B F7 18 00 00 80 31 FE 45 73 66 74 65 2D 6E 66 C4
> > SmartCafe Expert 3.2 72K
> I don't think this card is supported by OpenSC. In the OpenSC source, any
> version
> look at the src/libopensc directory. The supported cards all have a module
> names card-*.c It might be possible that the iso7816.c directly.
> Or you could add an entry in the opensc.conf to force the ATR to be mapped
> to a specific supported card.
Yes, I did it.
My entry in opensc.conf:
card_atr 3b:f7:18:00:00:80:31:fe:45:73:66:74:65:2d:6e:66:c4 {
name = "MyCard";
driver = "muscle";
}
> See the discussion from Aug 2011 on the OpenSC -devel lists:
> [opensc-devel] SmartCafe Expert 3.2 72K works fine in some versions but is
> an "unsupported card" in other versions.
> It is not clear if this was ever resolved.
I already had his problem too. I solved it by putting "muscle.profile" in
profiles folder of opensc installation directory.
Thanks again.
From: Douglas E. Engert
To: opensc-devel@lists.opensc-project.org
Sent: Monday, 10 December 2012, 19:24:53
Subject: Re: [opensc-devel] The smart card reader is known as "VMware Virtual
USB CCID 00 00" in linux ??!!
On 12/9/2012 9:56 AM, Ludovic Rousseau wrote:
> 2012/12/9 Rns Course :
>> Another request of you:
>> what's your opinion about windows version of opensc (0.12.2 or 0.13.0) and
>> the problem "File not found" in pkcs15 initialization?
Why use 0.13.0:
o 0.13.0 has many more fixes.
o You will get better responses from this list if you test with 0.13.0.
o Any fixes will be applied to 0.13.0,
You may be fighting 4 different problems:
(1) VMware remaps the card card name, and causes confusion with pcsc.
If you could use a real machine that would eliminate this problem for now.
(2) You said:
> installed Card Reader driver on fedora with name "ifdokccid.so"
> (my Card Reader is Omnikey CardMan 3121).
Is this really needed on unix? I thought pcscd would use its own
libccid.so for this reader. If this is a vendor provided library,
what version are you using?
Can you try without this file.
(3) You said:
> I've tested OpenSC-0.13.0 MSI on Windows7 and had the same problem in
> pkcs15 initialization as 0.12.2 version!
This would indicate that your real problem is with opensc most likely
not recognizing the card. (The vendor's window driver works with windows
but the venodor's unix driver may not work with the version of pcscd on
fedora. The introduction of VMware just complicates the problems.
(4) You said the card is reported:
> ATR: 3B F7 18 00 00 80 31 FE 45 73 66 74 65 2D 6E 66 C4
> Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
> 3B F7 18 00 00 80 31 FE 45 73 66 74 65 2D 6E 66 C4
> SmartCafe Expert 3.2 72K
I don't think this card is supported by OpenSC. In the OpenSC source, any
version
look at the src/libopensc directory. The supported cards all have a module
names card-*.c It might be possible that the iso7816.c directly.
Or you could add an entry in the opensc.conf to f
Re: [opensc-devel] Changing Admin PIN on PIV card
pkcs11's C_SetPin ? On Wed, Dec 12, 2012 at 3:06 AM, Ravneet Singh Khalsa wrote: > Hi, > > > > Does there any tool or API exists to change Admin PIN on Gemalto PIV Cards ? > > > > Thanks. > > > > > ___ > 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
[opensc-devel] Changing Admin PIN on PIV card
Hi, Does there any tool or API exists to change Admin PIN on Gemalto PIV Cards ? Thanks. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Wrong check for response APDU buffer
On 12/11/2012 3:27 PM, Frank Morgner wrote: > On Tuesday, December 11 at 09:59AM, Douglas E. Engert wrote: >> >> >> >> On 12/7/2012 5:15 PM, Frank Morgner wrote: >>> Hi! >>> >>> Currently, sc_check_apdu checks the length of an R-APDU buffer using >>> SC_MAX_APDU_BUFFER_SIZE, which defines the maximum length for a C-APDU. >>> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/apdu.c#L415 >>> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/apdu.c#L392 >> >> Yes this looks like a bug as SC_MAX_APDU_BUFFER_SIZE is for max size of ADPU >> that can be sent, not size of receive buffer: >> #define SC_MAX_APDU_BUFFER_SIZE 261 /* takes account of: CLA INS P1 >> P2 Lc [255 byte of data] Le */ >> >> >>> >>> A quick fix would be to use 0xff+1/0x+1 instead. However, in >>> multiple files I have seen this wrong usage of SC_MAX_APDU_BUFFER_SIZE >>> (eg, see `grep rbuf *.c | grep SC_MAX_APDU_BUFFER_SIZE`). Unfortunately >>> I dont have time to check libopensc in depth, so I leave this up to the >>> community. >>> >> >> Do you mean something like this: >> >> --- ,apdu.c Tue Dec 4 08:43:40 2012 >> +++ apdu.c Tue Dec 11 09:50:50 2012 >> @@ -389,7 +389,7 @@ >> if (apdu->resplen == 0 || apdu->resp == NULL) >> goto error; >> /* return buffer to small */ >> - if ((apdu->le == 0 && apdu->resplen < >> SC_MAX_APDU_BUFFER_SIZE-2) >> + if ((apdu->le == 0 && apdu->resplen < ((apdu->cse & >> SC_APDU_EXT) ? 65536 : 256)) >> || (apdu->resplen < apdu->le)) >> goto error; >> break; >> @@ -412,7 +412,7 @@ >> if (apdu->resplen == 0 || apdu->resp == NULL) >> goto error; >> /* return buffer to small */ >> - if ((apdu->le == 0 && apdu->resplen < >> SC_MAX_APDU_BUFFER_SIZE-2) >> + if ((apdu->le == 0 && apdu->resplen < ((apdu->cse & SC_APDU_EXT) ? >> 65536 : 256) >> || (apdu->resplen < apdu->le)) >> goto error; >> /* inconsistent datalen */ > > Yes, but I would use a define instead of hard coded values. The 65536 and 256 are also used in other places in the module, so I used the numbers. That not to say that defines could not be used. Did you just notice the code looked wrong or do you have a problem caused by the original code? Could you test a change? > Please have > in mind that the rest of the source code should be checked, too. The > following grep shows 65 hits which should be changed to use the new > define: > > grep -R SC_MAX * |egrep '(rbuf|recvbuf)' Fortunately these buffers are 261 bytes long, as the define was meant to define the max size that could be sent, and this is larger then the size that can be received. So although the 65 places could be changed, the use of the buffers in every instance would need to be reviewed. There may be other locations that use the SC_MAX_APDU_BUFFER_SIZE that don't use rbuf or recvbuf. Can you provide a change? > > > > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Wrong check for response APDU buffer
On Tuesday, December 11 at 09:59AM, Douglas E. Engert wrote: > > > > On 12/7/2012 5:15 PM, Frank Morgner wrote: > > Hi! > > > > Currently, sc_check_apdu checks the length of an R-APDU buffer using > > SC_MAX_APDU_BUFFER_SIZE, which defines the maximum length for a C-APDU. > > https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/apdu.c#L415 > > https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/apdu.c#L392 > > Yes this looks like a bug as SC_MAX_APDU_BUFFER_SIZE is for max size of ADPU > that can be sent, not size of receive buffer: > #define SC_MAX_APDU_BUFFER_SIZE 261 /* takes account of: CLA INS P1 > P2 Lc [255 byte of data] Le */ > > > > > > A quick fix would be to use 0xff+1/0x+1 instead. However, in > > multiple files I have seen this wrong usage of SC_MAX_APDU_BUFFER_SIZE > > (eg, see `grep rbuf *.c | grep SC_MAX_APDU_BUFFER_SIZE`). Unfortunately > > I dont have time to check libopensc in depth, so I leave this up to the > > community. > > > > Do you mean something like this: > > --- ,apdu.c Tue Dec 4 08:43:40 2012 > +++ apdu.c Tue Dec 11 09:50:50 2012 > @@ -389,7 +389,7 @@ > if (apdu->resplen == 0 || apdu->resp == NULL) > goto error; > /* return buffer to small */ > - if ((apdu->le == 0 && apdu->resplen < > SC_MAX_APDU_BUFFER_SIZE-2) > + if ((apdu->le == 0 && apdu->resplen < ((apdu->cse & > SC_APDU_EXT) ? 65536 : 256)) > || (apdu->resplen < apdu->le)) > goto error; > break; > @@ -412,7 +412,7 @@ > if (apdu->resplen == 0 || apdu->resp == NULL) > goto error; > /* return buffer to small */ > - if ((apdu->le == 0 && apdu->resplen < > SC_MAX_APDU_BUFFER_SIZE-2) > + if ((apdu->le == 0 && apdu->resplen < ((apdu->cse & SC_APDU_EXT) ? > 65536 : 256) > || (apdu->resplen < apdu->le)) > goto error; > /* inconsistent datalen */ Yes, but I would use a define instead of hard coded values. Please have in mind that the rest of the source code should be checked, too. The following grep shows 65 hits which should be changed to use the new define: grep -R SC_MAX * |egrep '(rbuf|recvbuf)' -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACEhttp://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc pgpxRR3Fm3mYi.pgp Description: PGP signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC Wiki in github
Hello, On Tue, Dec 11, 2012 at 5:08 PM, Toni Sjoblom - Aventra < developm...@aventra.fi> wrote: > I tried to find the page about MyEID but it seems to be missing in GitHub > wiki. > > Also several of the lists are missing/truncated (e.g. supported hardware, > just a link to create a new page is shown). > https://github.com/OpenSC/OpenSC/wiki/Aventra-MyEID-PKI-card The name of the migrated pages are constructed from the first h1 header of this page. This is because of the amazing feature of github wiki (or my own un-comprehension) to show as a page title the name of file and not the first h1 title. That's why the migration script changes the names and references. The conversion of the list of supported hardware is still to be scripted. > > > ** ** > > Kind regards, > > Toni > Kind wishes, Viktor. > > > ** ** > > *From:* opensc-devel-boun...@lists.opensc-project.org [mailto: > opensc-devel-boun...@lists.opensc-project.org] *On Behalf Of *Viktor > Tarasov > *Sent:* 11. joulukuuta 2012 17:18 > *To:* OpenSC Development > *Subject:* [opensc-devel] OpenSC Wiki in github > > ** ** > > Hello, > > ** ** > > for a while we have no news about migration of trac&wiki to the dedicated > platform. > > ** ** > > Meanwhile, waiting for better solution, I migrated OpenSC wiki to github > [1] . > > (Only wiki pages, not tickets.) > > ** ** > > The OpenSC Wiki pages in github are converted into 'textile' format. > > ** ** > > The rapid script used for this conversion, the archives with the dump of > the OpenSC sub-project wiki pages and > > wiki attachments are also present in wiki repository. (Files are not > accessible with GUI -- you need to clone repository. [2]) > > Using these files and archives the Wiki of the other OpenSC sub-projects > can be also migrated to github. > > ** ** > > I do not yet looked 'manually' through all the wiki pages to update > existing, suppress obsolete or add new information. > > ** ** > > I will do it gradually and invite you as well to participate in this > exciting activity, if you have will, possibility, time, etc... > > If you notice any 'systematic' conversion error, tell me please, I will > change the conversion script and re-submit the pages . > > ** ** > > Kind regards, > > Viktor. > > ** ** > > ** ** > > [1] https://github.com/OpenSC/OpenSC/wiki > > [2] git clone g...@github.com:OpenSC/OpenSC.wiki.git > ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC Wiki in github
Hello Andreas, On Tue, Dec 11, 2012 at 4:40 PM, Andreas Schwier < andreas.schw...@cardcontact.de> wrote: > What do we want to do about the automatic list generation that is not > working on GITHUB (e.g. SupportedHardware) ? > Thanks, I do not noticed it. > Do we copy the list as is from the old wiki ? > For a while yes. My intention is to script the conversion as close as possible to existing wiki, and then 'gradually' update the resulted pages manually. > > Andreas > Kind regards, Viktor. > > Am 11.12.2012 16:17, schrieb Viktor Tarasov: > > Hello, > > > > for a while we have no news about migration of trac&wiki to the > > dedicated platform. > > > > Meanwhile, waiting for better solution, I migrated OpenSC wiki to > > github [1] . > > (Only wiki pages, not tickets.) > > > > The OpenSC Wiki pages in github are converted into 'textile' format. > > > > The rapid script used for this conversion, the archives with the dump > > of the OpenSC sub-project wiki pages and > > wiki attachments are also present in wiki repository. (Files are not > > accessible with GUI -- you need to clone repository. [2]) > > Using these files and archives the Wiki of the other OpenSC > > sub-projects can be also migrated to github. > > > > I do not yet looked 'manually' through all the wiki pages to update > > existing, suppress obsolete or add new information. > > > > I will do it gradually and invite you as well to participate in this > > exciting activity, if you have will, possibility, time, etc... > > If you notice any 'systematic' conversion error, tell me please, I > > will change the conversion script and re-submit the pages . > > > > Kind regards, > > Viktor. > > > > > > [1] https://github.com/OpenSC/OpenSC/wiki > > [2] git clone g...@github.com:OpenSC/OpenSC.wiki.git > > > > > > ___ > > opensc-devel mailing list > > opensc-devel@lists.opensc-project.org > > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > > -- > > -CardContact Software & System Consulting >|.##> <##.| Andreas Schwier >|# #| Schülerweg 38 >|# #| 32429 Minden, Germany >|'##> <##'| Phone +49 571 56149 > -http://www.cardcontact.de > http://www.tscons.de > http://www.openscdp.org > > ___ > 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] OpenSC Wiki in github
Hi, I tried to find the page about MyEID but it seems to be missing in GitHub wiki. Also several of the lists are missing/truncated (e.g. supported hardware, just a link to create a new page is shown). Kind regards, Toni From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of Viktor Tarasov Sent: 11. joulukuuta 2012 17:18 To: OpenSC Development Subject: [opensc-devel] OpenSC Wiki in github Hello, for a while we have no news about migration of trac&wiki to the dedicated platform. Meanwhile, waiting for better solution, I migrated OpenSC wiki to github [1] . (Only wiki pages, not tickets.) The OpenSC Wiki pages in github are converted into 'textile' format. The rapid script used for this conversion, the archives with the dump of the OpenSC sub-project wiki pages and wiki attachments are also present in wiki repository. (Files are not accessible with GUI -- you need to clone repository. [2]) Using these files and archives the Wiki of the other OpenSC sub-projects can be also migrated to github. I do not yet looked 'manually' through all the wiki pages to update existing, suppress obsolete or add new information. I will do it gradually and invite you as well to participate in this exciting activity, if you have will, possibility, time, etc... If you notice any 'systematic' conversion error, tell me please, I will change the conversion script and re-submit the pages . Kind regards, Viktor. [1] https://github.com/OpenSC/OpenSC/wiki [2] git clone g...@github.com:OpenSC/OpenSC.wiki.git ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Wrong check for response APDU buffer
On 12/7/2012 5:15 PM, Frank Morgner wrote: > Hi! > > Currently, sc_check_apdu checks the length of an R-APDU buffer using > SC_MAX_APDU_BUFFER_SIZE, which defines the maximum length for a C-APDU. > https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/apdu.c#L415 > https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/apdu.c#L392 Yes this looks like a bug as SC_MAX_APDU_BUFFER_SIZE is for max size of ADPU that can be sent, not size of receive buffer: #define SC_MAX_APDU_BUFFER_SIZE 261 /* takes account of: CLA INS P1 P2 Lc [255 byte of data] Le */ > > A quick fix would be to use 0xff+1/0x+1 instead. However, in > multiple files I have seen this wrong usage of SC_MAX_APDU_BUFFER_SIZE > (eg, see `grep rbuf *.c | grep SC_MAX_APDU_BUFFER_SIZE`). Unfortunately > I dont have time to check libopensc in depth, so I leave this up to the > community. > Do you mean something like this: --- ,apdu.c Tue Dec 4 08:43:40 2012 +++ apdu.c Tue Dec 11 09:50:50 2012 @@ -389,7 +389,7 @@ if (apdu->resplen == 0 || apdu->resp == NULL) goto error; /* return buffer to small */ - if ((apdu->le == 0 && apdu->resplen < SC_MAX_APDU_BUFFER_SIZE-2) + if ((apdu->le == 0 && apdu->resplen < ((apdu->cse & SC_APDU_EXT) ? 65536 : 256)) || (apdu->resplen < apdu->le)) goto error; break; @@ -412,7 +412,7 @@ if (apdu->resplen == 0 || apdu->resp == NULL) goto error; /* return buffer to small */ - if ((apdu->le == 0 && apdu->resplen < SC_MAX_APDU_BUFFER_SIZE-2) + if ((apdu->le == 0 && apdu->resplen < ((apdu->cse & SC_APDU_EXT) ? 65536 : 256) || (apdu->resplen < apdu->le)) goto error; /* inconsistent datalen */ > > > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC Wiki in github
Hi Viktor, great job. I just looked through our page for the SmartCard-HSM and found only small issues. What do we want to do about the automatic list generation that is not working on GITHUB (e.g. SupportedHardware) ? Do we copy the list as is from the old wiki ? Andreas Am 11.12.2012 16:17, schrieb Viktor Tarasov: > Hello, > > for a while we have no news about migration of trac&wiki to the > dedicated platform. > > Meanwhile, waiting for better solution, I migrated OpenSC wiki to > github [1] . > (Only wiki pages, not tickets.) > > The OpenSC Wiki pages in github are converted into 'textile' format. > > The rapid script used for this conversion, the archives with the dump > of the OpenSC sub-project wiki pages and > wiki attachments are also present in wiki repository. (Files are not > accessible with GUI -- you need to clone repository. [2]) > Using these files and archives the Wiki of the other OpenSC > sub-projects can be also migrated to github. > > I do not yet looked 'manually' through all the wiki pages to update > existing, suppress obsolete or add new information. > > I will do it gradually and invite you as well to participate in this > exciting activity, if you have will, possibility, time, etc... > If you notice any 'systematic' conversion error, tell me please, I > will change the conversion script and re-submit the pages . > > Kind regards, > Viktor. > > > [1] https://github.com/OpenSC/OpenSC/wiki > [2] git clone g...@github.com:OpenSC/OpenSC.wiki.git > > > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- -CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 -http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC Wiki in github
Hello, for a while we have no news about migration of trac&wiki to the dedicated platform. Meanwhile, waiting for better solution, I migrated OpenSC wiki to github [1] . (Only wiki pages, not tickets.) The OpenSC Wiki pages in github are converted into 'textile' format. The rapid script used for this conversion, the archives with the dump of the OpenSC sub-project wiki pages and wiki attachments are also present in wiki repository. (Files are not accessible with GUI -- you need to clone repository. [2]) Using these files and archives the Wiki of the other OpenSC sub-projects can be also migrated to github. I do not yet looked 'manually' through all the wiki pages to update existing, suppress obsolete or add new information. I will do it gradually and invite you as well to participate in this exciting activity, if you have will, possibility, time, etc... If you notice any 'systematic' conversion error, tell me please, I will change the conversion script and re-submit the pages . Kind regards, Viktor. [1] https://github.com/OpenSC/OpenSC/wiki [2] git clone g...@github.com:OpenSC/OpenSC.wiki.git ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Aladdin eToken Pro 64k (regression?) - insecure keys and >1 User PIN configurations don't seem to work
Hi,
Summary: either I'm doing something wrong or with current (and
more generally >0.12.0) OpenSC, Aladdin eToken Pro 64k devices seem to
work only with a single User PIN and secure keys.
I have a bunch of Aladdin eToken Pro 64k USB tokens and have been using
one of them with OpenSC for a few years now.
My use-case settled on generally having one "secure" key with PIN and
one "convenience" key with no PIN, used as a second factor where no
authentication would've been used otherwise.
Unfortunately, it looks like I've locked it down yesterday, entering
too many PUK's for User PIN in a row (and I think I forgot the PUK).
(btw, I do remember SO PIN/PUK and they seem to work, am I correct in
the assumption that User PIN and related keys can't be recovered from it
with this token?)
Creating simiilar configuration with OpenSC 0.13.0 (and 0.12.2, though
due to different known issue, where OpenSC fails to query PINs from
non-pinpad) proved to be quite impossible - insecure keys don't seem to
work when created (I think I've created previous one with 0.11.x).
I can accept (though with much regret) that it's expected behavior now,
but wanted to confirm, especially since current toolkit operation
doesn't look right.
It's possible to work around the limitation, using second PIN with
static insecure password, but unfortunately it doesn't seem to work
anymore either.
I wrote a simple bash script (attached as "sc_test.sh",
https://raw.github.com/gist/4258342/ ), testing different permutations,
fully formatting and erasing token between these ops, following seem to
be the most relevant:
1. Init token with default profile and SO PIN.
2. Add User PIN.
3. Generate "secure" RSA key on-card, protected by User PIN.
4. Generate "insecure" RSA key on-card.
5. Decrypt using "insecure" key fails with the following:
"Decrypt failed: Security status not satisfied"
Workaround-way:
1. Init token with default profile and SO PIN.
2. Add User-1 PIN.
3. Generate "secure" RSA key on-card, protected by User-1 PIN.
4. Add User-2 PIN.
5. Generate "secure" RSA key on-card, protected by User-2 PIN.
And here I don't understand what happens:
% pkcs15-init -G rsa/2048 --public-key-label key2 -u decrypt -a 02
Using reader with a card: Aladdin eToken PRO 64k
User PIN [user1] required.
Please enter User PIN [user1]:
Security officer PIN [Security Officer PIN] required.
Please enter Security officer PIN [Security Officer PIN]:
Why ask for PIN of user1, if it's in the first slot and I
specifically asked it for a second (which I've just created in step
4):
PIN [user1]
Object Flags : [0x3], private, modifiable
ID : 01
Flags : [0x3A], local, unblock-disabled, initialized,
needs-padding
Length : min_len:4, max_len:8, stored_len:8
Pad char : 0x00
Reference : 3 (0x03)
Type : ascii-numeric
Path : 3f005015
PIN [user2]
Object Flags : [0x3], private, modifiable
ID : 02
Flags : [0x3A], local, unblock-disabled, initialized,
needs-padding
Length : min_len:4, max_len:8, stored_len:8
Pad char : 0x00
Reference : 5 (0x05)
Type : ascii-numeric
Path : 3f005015
Private RSA Key [Private Key]
Object Flags : [0x3], private, modifiable
Usage : [0x22], decrypt, unwrap
Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local
ModLength : 2048
Key ref: 16 (0x10)
Native : yes
Path : 3f005015
Auth ID: 01
ID : 942340b4ccd22a44561c9d951c67ff22d81b596d
GUID : {2756f23b-ea95-9daf-04dd-bfbbaeb21fb2}
Private RSA Key [Private Key]
Object Flags : [0x3], private, modifiable
Usage : [0x22], decrypt, unwrap
Access Flags : [0x1D], sensitive, alwaysSensitive, neverExtract, local
ModLength : 2048
Key ref: 17 (0x11)
Native : yes
Path : 3f005015
Auth ID: 02
ID : 70a81d1d8a0ba70b6b352f9171a9b282d41be24c
GUID : {9c42953c-32c4-703f-db7c-29083f4c7f90}
Why it didn't even ask for PIN of user2, whose key it should be (last
one above)?
6. Trying to decrypt with User-2 key yields the same as with insecure ones:
"Decrypt failed: Security status not satisfied"
7. Key, generated for User-1 works.
I'm far from an expert on such devices, but the step 5 above seem
very counter-intuitive and I'm inclined to think it's some kind of a
bug or maybe broken hardware, so any input on what happens there is
much appreciated.
I've also tired insecure keys with onepin profile (and different token)
to the same effect.
Hopefully I'm doing something wrong there, ot
