opensc-devel — discussion of developement of OpenSC and related projects

Re: [Opensc-devel] distributing openpgp-tool

[Martin P. <ma...@ma...>]

On Tue, Feb 26, 2013 at 3:28 PM, Crypto Stick
<cry...@pr...> wrote:
> Hi!
> The openpgp-tool is very useful to administrate OpenPGP Card or Crypto
> Stick. Unfortunately it is not part of the OpenSC 0.13 installer for
> Windows, even though other tools are included. Any plans to include
> openpgp-tool in the future?

It is probably missing from the installer description file (and other
scripts that deal with install/uninstall) due to a simple oversight.

Martin

[Opensc-devel] distributing openpgp-tool

[Crypto S. <cry...@pr...>]

Hi!
The openpgp-tool is very useful to administrate OpenPGP Card or Crypto
Stick. Unfortunately it is not part of the OpenSC 0.13 installer for
Windows, even though other tools are included. Any plans to include
openpgp-tool in the future?

Regards,
Jan

Re: [Opensc-devel] Project Website

[Martin P. <ma...@ma...>]

On Mon, Feb 25, 2013 at 12:15 PM, Ludovic Rousseau
<lud...@gm...> wrote:
>
> Trac is not working on the server.

Apparently non-https site has been misconfigured ever since and
smoketesting with Chrome seems to be misleading, meaning that removing
the S from the https URL still somehow automagically loads up the
secure version of the site (which has been Trac all the time). This is
fixed.

Martin

Re: [Opensc-devel] Project Website

[Ludovic R. <lud...@gm...>]

2013/2/20 Martin Paljak <ma...@ma...>:
> Hello,
>
> On Fri, Feb 15, 2013 at 6:19 PM, Ludovic Rousseau
> <lud...@gm...> wrote:
>> Hello Martin,
>>
>> The webpage at http://www.opensc-project.org/ just says: "It works!".
>
> Strange, that should not be the case, the last trac snapshot should be
> there instead.

Now the web server reports the directory index with only one entry: a
"downloads" directory.
The downloads directory contains only the file build-10.6.tar.gz.

This is not very helpfull to users looking for OpenSC.
Please use the attached index.html file.

>> Martin, what are your plan regarding the domain name?
>> Can you replace the web home page to redirect to
>> https://github.com/OpenSC/OpenSC/wiki/OpenSC-Services?
>
> It makes sense to revise it accordingly with links to up to date
> information where necessary, but it should be well-justified to remove
> a) existing links and search b) wiki functionality (tags, links etc).
>
> Any OpenID should grant sufficient write access, if not, let me know.

Trac is not working on the server.
Bye

-- 
 Dr. Ludovic Rousseau

Re: [Opensc-devel] Use case of some pkcs15 functions?

[Martin P. <ma...@ma...>]

On Mon, Feb 25, 2013 at 11:04 AM, Nguyễn Hồng Quân <qua...@mb...> wrote:
> In pkcs15-init layer, there are some functions whose emulation is not
> implemented yet by OpenPGP binding.
> Do you know any use case that these functions will be used:
>
> erase_card

This *might* be relevant in the context of erasing a blocked 2.0 card
with the APDU-s documented somewhere on the web.

For others: if all the needed functionality is available, don't worry
about "implementing everything".


Martin

[Opensc-devel] Use case of some pkcs15 functions?

[Nguyễn H. Q. <qua...@mb...>]

Hello,

In pkcs15-init layer, there are some functions whose emulation is not
implemented yet by OpenPGP binding.
Do you know any use case that these functions will be used:

erase_card
create_dir
select_pin_reference
create_pin
select_key_reference
delete_object
emu_update_dir
emu_write_info
sanity_check

There are functions I implemented because I know how they are used, when
I test with Firefox, Thunderbird (signing, decrypting, authentication).
I want to know if there are any software which need to use the other
functions, to implement more.

Thank you.

-- 
Regards,
Quân

Y!IM: ng_hquan_vn
GTalk: ng.hong.quan

[Opensc-devel] Missing Keyset Error

[Sushma <sus...@gm...>]

Dear All,

I'm developing smart card mini driver based on Open-SC mini driver.
I'm using certutil in Windows 7 x64 to test the mini driver. As I use
the command, I get the following error in console window "Missing
stored keyset". I'm using an empty smart card to test. I would like to
know if there should be any certificates or key set available on card
before I can test using the certutil or using WinLogon. I can provide
more information on certutil output if required.

Any help is highly appreciated.

Thanks in Advance.

Regards,
Sushma

Re: [Opensc-devel] BCM5880?

[Martin P. <ma...@ma...>]

Probably not.
-- 
Sent from a device without a proper keyboard...
On 23 Feb 2013 16:01, "Benjamin Henrion" <bh...@ud...> wrote:

> On Sat, Feb 23, 2013 at 2:31 PM, Martin Paljak <ma...@ma...>
> wrote:
> > http://bitvapor.com/blog/node/2
> >
> > You need to update the firmware, there is a README in the package, so
> > please follow that.
>
> I do not have M$ Windows on my laptop, is there any way to update the
> firmware under linux?
>
> --
> Benjamin Henrion <bhenrion at ffii.org>
> FFII Brussels - +32-484-566109 - +32-2-3500762
> "In July 2005, after several failed attempts to legalise software
> patents in Europe, the patent establishment changed its strategy.
> Instead of explicitly seeking to sanction the patentability of
> software, they are now seeking to create a central European patent
> court, which would establish and enforce patentability rules in their
> favor, without any possibility of correction by competing courts or
> democratically elected legislators."
>

Re: [Opensc-devel] BCM5880?

[Benjamin H. <bh...@ud...>]

On Sat, Feb 23, 2013 at 2:31 PM, Martin Paljak <ma...@ma...> wrote:
> http://bitvapor.com/blog/node/2
>
> You need to update the firmware, there is a README in the package, so
> please follow that.

I do not have M$ Windows on my laptop, is there any way to update the
firmware under linux?

--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

Re: [Opensc-devel] BCM5880?

[Martin P. <ma...@ma...>]

http://bitvapor.com/blog/node/2

You need to update the firmware, there is a README in the package, so
please follow that.

Martin
On Sat, Feb 23, 2013 at 3:01 PM, Benjamin Henrion <bh...@ud...> wrote:
> BCM5880

[Opensc-devel] BCM5880?

[Benjamin H. <bh...@ud...>]

Hi,

I own a Dell E4200 laptop with a BCM5880 smart card reader.

I have read here that it might be supported by adding some firmware:

http://www.mail-archive.com/mu...@li.../msg07952.html

I have downloaded this EXE:

http://ftp.dell.com/Control%20Point/dell_controlvault_a08_r214858.exe

Which unzips files:

======================================================
C:\dell\drivers\4200>dir
 El volumen de la unidad C no tiene etiqueta.
 El número de serie del volumen es: 189C-C567

 Directorio de C:\dell\drivers\4200

23/02/2013  13:32    <DIR>          .
23/02/2013  13:32    <DIR>          ..
23/02/2013  13:32    <DIR>          DOS
23/02/2013  13:32    <DIR>          firmware
23/02/2013  13:32    <DIR>          ODM
11/03/2009  10:19             6.200 readme.txt
10/03/2009  16:33            16.199 release.txt
11/11/2008  15:38                31 UPDATE.BAT
23/03/2009  15:01               761 Version.txt
               4 archivos         23.191 bytes
               5 dirs  64.952.975.360 bytes libres

C:\dell\drivers\4200>cd firmware

C:\dell\drivers\4200\firmware>dir
 El volumen de la unidad C no tiene etiqueta.
 El número de serie del volumen es: 189C-C567

 Directorio de C:\dell\drivers\4200\firmware

23/02/2013  13:32    <DIR>          .
23/02/2013  13:32    <DIR>          ..
09/03/2009  22:59           176.128 172Kfile
10/03/2009  16:33           646.320 bcmC07.otp
10/03/2009  16:33           646.320 bcmC0ff.otp
09/03/2009  22:59             1.024 clearscd.bin
09/03/2009  22:59               512 clr512.bin
10/03/2009  16:33         2.097.152 fsbC07.otp
10/03/2009  16:33         2.097.152 fsbC0ff.otp
09/03/2009  22:59            69.632 fwupgrdtool.exe
09/03/2009  22:59             3.736 fwupgrdtool.txt
09/03/2009  22:59           657.516 pbaapp.bin
09/03/2009  22:59             6.191 readme.txt
10/03/2009  16:33            15.376 release.txt
09/03/2009  22:59             1.717 rfid233.cfg
09/03/2009  22:59             1.853 rfid24d.cfg
09/03/2009  22:59             1.851 rfid251.cfg
09/03/2009  22:59             1.284 rfiddflt.cfg
09/03/2009  22:59            55.152 sbiC07.otp
09/03/2009  22:59            51.808 sbiC0ff.otp
09/03/2009  22:59            36.864 tpm.dll
09/03/2009  22:59           184.320 ushupgrade.exe
09/03/2009  22:59             6.959 ushupgrade.txt
09/03/2009  22:59           205.824 ushupgrade64.exe
              22 archivos      6.964.691 bytes
               2 dirs  64.952.975.360 bytes libres

C:\dell\drivers\4200\firmware>dir
 El volumen de la unidad C no tiene etiqueta.
 El número de serie del volumen es: 189C-C567

 Directorio de C:\dell\drivers\4200\firmware

23/02/2013  13:32    <DIR>          .
23/02/2013  13:32    <DIR>          ..
09/03/2009  22:59           176.128 172Kfile
10/03/2009  16:33           646.320 bcmC07.otp
10/03/2009  16:33           646.320 bcmC0ff.otp
09/03/2009  22:59             1.024 clearscd.bin
09/03/2009  22:59               512 clr512.bin
10/03/2009  16:33         2.097.152 fsbC07.otp
10/03/2009  16:33         2.097.152 fsbC0ff.otp
09/03/2009  22:59            69.632 fwupgrdtool.exe
09/03/2009  22:59             3.736 fwupgrdtool.txt
09/03/2009  22:59           657.516 pbaapp.bin
09/03/2009  22:59             6.191 readme.txt
10/03/2009  16:33            15.376 release.txt
09/03/2009  22:59             1.717 rfid233.cfg
09/03/2009  22:59             1.853 rfid24d.cfg
09/03/2009  22:59             1.851 rfid251.cfg
09/03/2009  22:59             1.284 rfiddflt.cfg
09/03/2009  22:59            55.152 sbiC07.otp
09/03/2009  22:59            51.808 sbiC0ff.otp
09/03/2009  22:59            36.864 tpm.dll
09/03/2009  22:59           184.320 ushupgrade.exe
09/03/2009  22:59             6.959 ushupgrade.txt
09/03/2009  22:59           205.824 ushupgrade64.exe
              22 archivos      6.964.691 bytes
               2 dirs  64.952.975.360 bytes libres

C:\dell\drivers\4200\firmware>
======================================================

Any idea how to use those firmware images to make opensc work under linux?

Best,

-- 
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

Re: [Opensc-devel] Need for simple C_Initialize [was: Issues connecting to OpenVPN with Smartcard]

[Martin P. <ma...@ma...>]

On Wed, Feb 20, 2013 at 10:13 PM, Douglas E. Engert <dee...@an...> wrote:
> The way I read these, we could move the call for the card_detect out of
> C_Initialize.  A 2.11 caller does not know if C_Initialize has done
> anything with slots until a call is made that needs to get slots
> and at that time the 2.11 caller expects the number of slots will be fixed
> and would not be trying to use the 2.20 requirement to call C_GetSlotList
> with a NULL pSlotList to get a new list of slots.
>
> The issue is then if any internal OpenSC code depends on the card_detect being
> called early.

That seems like a safe choice. In fact, I did not understand why the
card detection was not made a conditional depending on the 2.20 mode
in the first place.

This is far from the original problem (C_Finalize in C_Inititialize) though :)

Martin

Re: [Opensc-devel] Need for simple C_Initialize [was: Issues connecting to OpenVPN with Smartcard]

[Douglas E. E. <dee...@an...>]

On 2/20/2013 11:56 AM, Martin Paljak wrote:
> On Wed, Feb 20, 2013 at 5:53 PM, Nikos Mavrogiannopoulos
> <n.m...@gm...> wrote:
>> And that looks like a very good reason why C_Initialize should be
>> simple in OpenSC and not take several seconds (e.g., by trying to probe
>> the inserted cards). Consider enabling smart card support with opensc in
>> a forking server and then realize that each child would wait 4-6 seconds
>> for C_Initialize on creation, irrespective whether smart cards are used
>> on it.
>
> True, I can only think of some forgotten specifics for 2.11 why slots
> are created on C_Initialize rather than C_GetSlotList.

Yes there is a difference.


PKCS #11 2.11, revision 1, November 2001

Section 11.5 Slot and token management functions

   All slots which C_GetSlotList reports must be able to be queried as valid slots by
   C_GetSlotInfo.  Furthermore, the set of slots accessible through a Cryptoki library
   is fixed at the time that C_Initialize is called.  If an application calls C_Initialize
   and C_GetSlotList, and then the user hooks up a new hardware device, that device cannot
   suddenly appear as a new slot if C_GetSlotList is called again.  To recognize the new
   device, C_Initialize needs to be called again (and to be able to call C_Initialize
   successfully, C_Finalize needs to be called first).  Even if C_Initialize is
   successfully called, it may or may not be the case that the new device will then be
   successfully recognized.  On some platforms, it may be necessary to restart the entire
   system.


PKCS#11 2.20

Section 11.5 Slot and token management functions

   All slots which C_GetSlotList reports must be able to be queried as valid slots by
   C_GetSlotInfo. Furthermore, the set of slots accessible through a Cryptoki library is
   checked at the time that C_GetSlotList, for list length prediction (NULL pSlotList
   argument) is called. If an application calls C_GetSlotList with a non-NULL pSlotList,
   and then the user adds or removes a hardware device, the changed slot list will only be
   visible and effective if C_GetSlotList is called again with NULL. Even if C_
   GetSlotList is successfully called this way, it may or may not be the case that the
   changed slot list will be successfully recognized depending on the library
   implementation. On some platforms, or earlier PKCS11 compliant libraries, it may be
   necessary to successfully call C_Initialize or to restart the entire system.


The way I read these, we could move the call for the card_detect out of
C_Initialize.  A 2.11 caller does not know if C_Initialize has done
anything with slots until a call is made that needs to get slots
and at that time the 2.11 caller expects the number of slots will be fixed
and would not be trying to use the 2.20 requirement to call C_GetSlotList
with a NULL pSlotList to get a new list of slots.

The issue is then if any internal OpenSC code depends on the card_detect being
called early.

>
> Martin
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

-- 

  Douglas E. Engert  <DEE...@an...>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

Re: [Opensc-devel] Need for simple C_Initialize [was: Issues connecting to OpenVPN with Smartcard]

[Martin P. <ma...@ma...>]

On Wed, Feb 20, 2013 at 5:53 PM, Nikos Mavrogiannopoulos
<n.m...@gm...> wrote:
> And that looks like a very good reason why C_Initialize should be
> simple in OpenSC and not take several seconds (e.g., by trying to probe
> the inserted cards). Consider enabling smart card support with opensc in
> a forking server and then realize that each child would wait 4-6 seconds
> for C_Initialize on creation, irrespective whether smart cards are used
> on it.

True, I can only think of some forgotten specifics for 2.11 why slots
are created on C_Initialize rather than C_GetSlotList.

Martin

[Opensc-devel] Need for simple C_Initialize [was: Issues connecting to OpenVPN with Smartcard]

[Nikos M. <n.m...@gm...>]

On 02/20/2013 02:50 PM, Martin Paljak wrote:


> Looking at PKCS#11 v2.20, 6.6.1 Applications and processes
> It tells:
> In the scenario specified above, C should actually call C_Initialize
> whether or not it needs to use Cryptoki; if it has no need to use
> Cryptoki, it should then call C_Finalize immediately thereafter. This
> (having the child immediately call C_Initialize and then call
> C_Finalize if the parent is using Cryptoki) is considered to be good
> Cryptoki programming practice, since it can prevent the existence of
> dangling duplicate resources that were created at the time of the
> fork() call; however, it is not required by Cryptoki.


And that looks like a very good reason why C_Initialize should be
simple in OpenSC and not take several seconds (e.g., by trying to probe
the inserted cards). Consider enabling smart card support with opensc in
a forking server and then realize that each child would wait 4-6 seconds
for C_Initialize on creation, irrespective whether smart cards are used
on it.

regards,
Nikos

Re: [Opensc-devel] [Muscle] Issues connecting to OpenVPN with Smartcard

[Martin P. <ma...@ma...>]

On Tue, Feb 19, 2013 at 10:19 AM, Ludovic Rousseau
<lud...@gm...> wrote:
> 2013/2/19 Chris J Arges <chr...@gm...>:
> We need to understanf why the code you removed is causing problems. It
> is supposed to solve problems :-)
>
> Alon, it looks like you wrote this code. Any idea?
> Maybe call C_Finalize() only if initialized_pid has been set (!= -1)?
>
> commit 1875a25c4090b261d9eeb419beeb74bae9735650
> Author: alonbl <alonbl@c6295689-39f2-0310-b995-f0e70906c6a9>
> Date:   Thu Mar 6 14:56:31 2008 +0000
>
>     PKCS#11 "Application and processes" instructs the sequence
>     that should be taken after fork().
>     Applications should call C_Initialize() immediately after fork()
>     to reinitialize the provider.
>
>     The change monitor the pid that calls C_Initialize(), if it is
>     different than previous C_Finalize() is called.

Looking at PKCS#11 v2.20, 6.6.1 Applications and processes

It tells:

In the scenario specified above, C should actually call C_Initialize
whether or not it needs to use Cryptoki; if it has no need to use
Cryptoki, it should then call C_Finalize immediately thereafter. This
(having the child immediately call C_Initialize and then call
C_Finalize if the parent is using Cryptoki) is considered to be good
Cryptoki programming practice, since it can prevent the existence of
dangling duplicate resources that were created at the time of the
fork() call; however, it is not required by Cryptoki.


So maybe "helping" the cryptoki application is actually not a good
idea, better report some error or print some fat warning to stderr/out
"misbehaving PKCS#11 application".

Martin

Re: [Opensc-devel] Project Website

[Martin P. <ma...@ma...>]

Hello,

On Fri, Feb 15, 2013 at 6:19 PM, Ludovic Rousseau
<lud...@gm...> wrote:
> Hello Martin,
>
> The webpage at http://www.opensc-project.org/ just says: "It works!".

Strange, that should not be the case, the last trac snapshot should be
there instead.


> Martin, what are your plan regarding the domain name?
> Can you replace the web home page to redirect to
> https://github.com/OpenSC/OpenSC/wiki/OpenSC-Services?

It makes sense to revise it accordingly with links to up to date
information where necessary, but it should be well-justified to remove
a) existing links and search b) wiki functionality (tags, links etc).

Any OpenID should grant sufficient write access, if not, let me know.

Martin

> 2013/2/15 Andreas Schwier <and...@ca...>:
>> Hi,
>>
>> under the URL http://www.opensc-project.org the server just displays a
>> "It works!" message.
>>
>> The URL http://www.opensc.org doesn't show anything.
>>
>> Is that intentional ?
>>
>> I guess with dropping the website and stopping the mailing list we
>> probably lost the last members of the community. I guess we need to
>> improve the OpenSC marketing.
>>
>> Sigh...
>>
>> Andreas
>
> --
>  Dr. Ludovic Rousseau

[Opensc-devel] sc_get_response() behavior with multiple GET RESPONSE?

[Nguyễn H. Q. <qua...@mb...>]

Hello,

I have difficulty geting response data from card when the card only
support shorts APDU and have to use multiple GET RESPONSE commands, done
internally by sc_transmit_apdu and sc_get_response functions.

Because I don't know how big returned data will be, I set apdu.resplen
to a maximum number (say 2048), but after getting enough data (actual
length is less than 2048), the sc_get_response() still try to acquire
more and fall to "6D 00" error.

If I set apdu.resplen = 256, sc_get_response() stop when 256 bytes data
was got, regardless there is still more data.

How can I make sc_get_response() stop right after it receives "90 00"
from card?

I'm working with OpenPGP card in Gnuk device.

-- 
Regards,
Quân

Y!IM: ng_hquan_vn
GTalk: ng.hong.quan

Re: [Opensc-devel] Issues connecting to OpenVPN with Smartcard

[Chris J A. <chr...@gm...>]

On 02/19/2013 02:19 AM, Ludovic Rousseau wrote:
> 2013/2/19 Chris J Arges <chr...@gm...>:
>> Ok I've found a workaround that allows me to connect and it is related
>> to OpenSC.
>>
>> It seems that _WIN32 is being defined (on a Linux system) when I build
>> OpenSC from the latest git source. And this was causing an issue in
>> C_Initialize that made it immediately C_Finalize. I used the following
>> patch to hack around this, and now OpenVPN connects using a smartcard
>> via OpenSC.
> 
> _WIN32 is NOT defined.
> What your patch does is to remove code used when _WIN32 is not defined.
> 
> Look at the ! (negation) in:
> #if !defined(_WIN32)
> 
> 

You are correct, sorry about the confusion. This is behaving correctly
and I verified in config.log and grepping.

>> diff --git a/src/pkcs11/pkcs11-global.c b/src/pkcs11/pkcs11-global.c
>> index 5652975..bbf897b 100644
>> --- a/src/pkcs11/pkcs11-global.c
>> +++ b/src/pkcs11/pkcs11-global.c
>> @@ -199,6 +199,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
>>         sc_context_param_t ctx_opts;
>>
>>         /* Handle fork() exception */
>> +#if 0
>>  #if !defined(_WIN32)
>>         if (current_pid != initialized_pid) {
>>                 C_Finalize(NULL_PTR);
>> @@ -206,6 +207,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
>>         initialized_pid = current_pid;
>>         in_finalize = 0;
>>  #endif
>> +#endif
>>
>>         if (context != NULL) {
>>                 sc_log(context, "C_Initialize(): Cryptoki already
>> initialized\n");
>>
>> However, it seems the larger problem would be disabling _WIN32 from
>> being defined on Linux systems. I'm not sure if this is a function of
>> autotool versions or what.
> 
> We need to understanf why the code you removed is causing problems. It
> is supposed to solve problems :-)
> 
I agree.

What I did was instrument this code to print out the pids, I get:
[opensc-pkcs11] pkcs11-global.c:203:C_Initialize: current_pid 4432,
initialized_pid 4417

So they are clearly different, and this makes sense because I think
OpenVPN is forking. Looking at ps I see:
 4417 pts/2    SL+    0:00 /src/openvpn/.libs/lt-openvpn --config
sc.conf --verb
 4432 pts/2    S+     0:00 /src/openvpn/.libs/lt-openvpn --config
sc.conf --verb

> Alon, it looks like you wrote this code. Any idea?
> Maybe call C_Finalize() only if initialized_pid has been set (!= -1)?
> 
> commit 1875a25c4090b261d9eeb419beeb74bae9735650
> Author: alonbl <alonbl@c6295689-39f2-0310-b995-f0e70906c6a9>
> Date:   Thu Mar 6 14:56:31 2008 +0000
> 
>     PKCS#11 "Application and processes" instructs the sequence
>     that should be taken after fork().
>     Applications should call C_Initialize() immediately after fork()
>     to reinitialize the provider.
> 
>     The change monitor the pid that calls C_Initialize(), if it is
>     different than previous C_Finalize() is called.
>

Yes, any suggestions to test that openvpn+opensc is doing this properly
would be good. I can try to trace through the code, but perhaps there is
a more simple test.

Thanks,
--chris

[Opensc-devel] Undeletable MF and 3F00/2F00 file, can't create new files due to ACL on ePass2003

[Ondrej M. <ond...@ni...>]

Hi,

I got one ePass2003 token in a strange state where it can't be erased
(via pkcs15-init -E) and no new files can be created. I can't seem to
find a way to reset/erase the token.

Any erase or file create attempt returns 69 82 "Security status not
satisfied".

Even the Feitian's fix_tool [1] doesn't work, the proprietary INS 0xE3
fails to install new PIN/key, instruction fails also with 69 82:

====
 Enc APDU :
 80 50 00 00 08 BF C3 29 11 C7 18 C3 40 1C
 SCardTransmit		: Command successful.
 card response: 90 00

 Enc APDU :
 84 82 03 00 10 FC C4 17 D6 DC 54 83 AF FD 64 DA 2F 23 06 B8 04
 SCardTransmit		: Command successful.
 card response: 90 00


 Install PIN...
 Enc APDU :
 8C E3 00 00 2D 87 21 01 02 7B 4B 2B 34 B1 D5 C4 03 8F A0 73 43 8E 00 91
F9 E6 98 BC 15 ED 8A 99
 E5 05 8B 37 55 EB 63 89 8E 08 CC 8C 9F 77 41 8B 19 B9 00
 SCardTransmit		: Command successful.
 card response: 69 82


 Verify PIN...
 Enc APDU :
 0C 20 00 01 2D 87 21 01 40 F0 5D C2 7C C7 17 5F 85 9B 5F DD 86 BD FF 04
F4 D8 34 48 94 2F 15 4C
 5B 5C E2 C3 5E C7 6E 07 8E 08 6F E0 31 6C 23 9F 88 D9 00
 SCardTransmit		: Command successful.
 card response: 94 03


 Erase MF file ...
 Enc APDU :
 0C E4 00 00 1D 87 11 01 1C A9 3B C0 96 4D 25 40 BF 36 46 40 F9 52 A1 A0
8E 08 6A AD 1E 2D D4 ED
 C7 DD 00
 SCardTransmit		: Command successful.
 card response: 69 82
===

List of files with ACL on the card is below. Notice that pin object file
3F00/5015/4401 is missing, as are missing the ODF, TokenInfo and
UnusedSpace files (3F00/5015/503[1-3]). File list from opensc-tool
--list-files:

===
3f00 [entersafe-fips] type: DF, size: 0
select[N/A] lock[N/A] delete[N/A] create[N/A] rehab[N/A] inval[N/A]
list[N/A] sec: 90:96:FF:96:FF:FF:FF:FF
prop: 00:7F

  3f002f00 type: wEF, ef structure: linear-fixed, size: 0
  read[N/A] update[N/A] erase[N/A] write[N/A] rehab[N/A] inval[N/A] sec:
90:96:96:96:FF:FF:FF:FF

  3f005015 [\xA0\x00\x00\x00cPKCS-15] type: DF, size: 0
  select[N/A] lock[N/A] delete[N/A] create[N/A] rehab[N/A] inval[N/A]
list[N/A] sec: 90:96:FF:96:FF:FF:FF:FF
  prop: 00:7F

    3f0050159f00 type: wEF, ef structure: transparent, size: 2
    read[N/A] update[N/A] erase[N/A] write[N/A] rehab[N/A] inval[N/A]
sec: 90:90:FF:90:FF:FF:FF:FF

00000000: 06 06 ..
===

The ACLs above seem to be card-specific and I haven't find any
documentation on them anywhere. From cardctl.h, 0x90 ==
EPASS2003_AC_MAC_NOLESS, 0x6 == EPASS2003_AC_USER and 0x0 ==
EPASS2003_AC_EVERYONE.

Any idea how to erase or "unbrick" the token? There seems to be no
documentation on INS 0xE3 except for its use in
card-epass2003.c:install_secret_key().


[1] http://www.gooze.eu/forums/support/epass2003-recovery-tool


Ondrej Mikle

Re: [Opensc-devel] Last minute patching

[Andreas S. (ML) <and...@ca...>]

Hi Toni,

I've marked the change in [1] / pkcs15-pubkey.c / 658.

Your modification to the code is correct, but it breaks existing code as
it changes the format of the public key stored in ecpointQ. Before your
change it used to contain an OCTET-STRING, now it contains just the
plain public key (04|X|Y).

My point is not that we should not do this kind of fixes, we just should
allow a little more time for other to check implications of large code
changes. And we should certainly not introduce such large changes after
we verified 2 release candidates - I mean, what's the purpose of a
release candidate, if the final code looks completely different ?

Andreas


[1]
https://github.com/OpenSC/OpenSC/commit/457426543dfa02597895d57013dde94cc9e7d038

Am 18.02.2013 21:00, schrieb Toni Sjoblom - Aventra:
> Hi,
> 
> First of all, I'm sorry for the problems you got due to a change we did.
> 
> At the time, it seemed for me that the OpenSC's ECC parts were very
> incomplete,
> especially key generation. We added these parts and tried to interpret
> standards to get everything right.
> 
> I tried to look at the actual problem you got, but I cannot find the patch
> you mentioned.
> Could you post a direct link to the pull request?
> 
> Kind regards,
> Toni
> 
>> -----Original Message-----
>> From: Andreas Schwier (ML) [mailto:and...@ca...]
>> Sent: 15. helmikuuta 2013 19:01
>> To: Viktor Tarasov
>> Cc: ope...@li...
>> Subject: Re: [Opensc-devel] Last minute patching
>>
>> Dear Viktor,
>>
>> the patch is attached to the pending pull request for
>> CardContact/OpenSC.
>>
>> Andreas
>>
>> Am 15.02.2013 15:31, schrieb Viktor Tarasov:
>>> Hello,
>>>
>>> On Fri, Feb 15, 2013 at 2:41 PM, Andreas Schwier (ML)
>>> <and...@ca...
>>> <mailto:and...@ca...>> wrote:
>>>
>>>     while doing some regression testing we've come across a problem
>> that
>>>     once working code broke apart immediately before the 0.13 release
>> was
>>>     finished.
>>>
>>>     We traced the problem down to a code change introduced by the
>> MyEID
>>>     ECDSA patch [1] that went into the 0.13 version as one of the
>> very final
>>>     patches.
>>>
>>>     Even though the code change is valid, it breaks existing code,
>> rendering
>>>     the ECDSA key generation for the SmartCard-HSM in the 0.13
>> release
>>>     pretty much useless.
>>>
>>>
>>> Sorry, for these problems.
>>>
>>>
>>>
>>>     Can we for the future agree, that we don't squeeze such a large
>> code
>>>     change in right before doing a release ?
>>>
>>>
>>>
>>> Yes, in the future we'll be less hazardous.
>>>
>>> This release was not as like the others -- first train after the long
>>> interruption of traffic: many passengers, new locomotive, equipage
>>> without experience, ...
>>>
>>>
>>>
>>>     We tested all the release candidates and they worked up and until
>> the
>>>     very last patch.
>>>
>>>     Andreas
>>>
>>>
>>> Kind regards,
>>> Viktor.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> https://github.com/OpenSC/OpenSC/commit/457426543dfa02597895d57013dde9
>>> 4cc9e7d038
>>>
>>>     --
>>>
>>>         ---------    CardContact Software & System Consulting
>>>        |.##> <##.|   Andreas Schwier
>>>        |#       #|   Schülerweg 38
>>>        |#       #|   32429 Minden, Germany
>>>        |'##> <##'|   Phone +49 571 56149 <tel:%2B49%20571%2056149>
>>>         ---------    http://www.cardcontact.de
>>>                      http://www.tscons.de
>>>                      http://www.openscdp.org
>>>
>>>
>>>     -----------------------------------------------------------------
>> -------------
>>>     Free Next-Gen Firewall Hardware Offer
>>>     Buy your Sophos next-gen firewall before the end March 2013
>>>     and get the hardware for free! Learn more.
>>>     http://p.sf.net/sfu/sophos-d2d-feb
>>>     _______________________________________________
>>>     Opensc-devel mailing list
>>>     Ope...@li...
>>>     <mailto:Ope...@li...>
>>>     https://lists.sourceforge.net/lists/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
>>
>>
>> -----------------------------------------------------------------------
>> -------
>> Free Next-Gen Firewall Hardware Offer
>> Buy your Sophos next-gen firewall before the end March 2013 and get the
>> hardware for free! Learn more.
>> http://p.sf.net/sfu/sophos-d2d-feb
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/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

Re: [Opensc-devel] Issues connecting to OpenVPN with Smartcard

[Ludovic R. <lud...@gm...>]

2013/2/19 Chris J Arges <chr...@gm...>:
> Ok I've found a workaround that allows me to connect and it is related
> to OpenSC.
>
> It seems that _WIN32 is being defined (on a Linux system) when I build
> OpenSC from the latest git source. And this was causing an issue in
> C_Initialize that made it immediately C_Finalize. I used the following
> patch to hack around this, and now OpenVPN connects using a smartcard
> via OpenSC.

_WIN32 is NOT defined.
What your patch does is to remove code used when _WIN32 is not defined.

Look at the ! (negation) in:
#if !defined(_WIN32)


> diff --git a/src/pkcs11/pkcs11-global.c b/src/pkcs11/pkcs11-global.c
> index 5652975..bbf897b 100644
> --- a/src/pkcs11/pkcs11-global.c
> +++ b/src/pkcs11/pkcs11-global.c
> @@ -199,6 +199,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
>         sc_context_param_t ctx_opts;
>
>         /* Handle fork() exception */
> +#if 0
>  #if !defined(_WIN32)
>         if (current_pid != initialized_pid) {
>                 C_Finalize(NULL_PTR);
> @@ -206,6 +207,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
>         initialized_pid = current_pid;
>         in_finalize = 0;
>  #endif
> +#endif
>
>         if (context != NULL) {
>                 sc_log(context, "C_Initialize(): Cryptoki already
> initialized\n");
>
> However, it seems the larger problem would be disabling _WIN32 from
> being defined on Linux systems. I'm not sure if this is a function of
> autotool versions or what.

We need to understanf why the code you removed is causing problems. It
is supposed to solve problems :-)

Alon, it looks like you wrote this code. Any idea?
Maybe call C_Finalize() only if initialized_pid has been set (!= -1)?

commit 1875a25c4090b261d9eeb419beeb74bae9735650
Author: alonbl <alonbl@c6295689-39f2-0310-b995-f0e70906c6a9>
Date:   Thu Mar 6 14:56:31 2008 +0000

    PKCS#11 "Application and processes" instructs the sequence
    that should be taken after fork().
    Applications should call C_Initialize() immediately after fork()
    to reinitialize the provider.

    The change monitor the pid that calls C_Initialize(), if it is
    different than previous C_Finalize() is called.

Bye

-- 
 Dr. Ludovic Rousseau

Re: [Opensc-devel] Issues connecting to OpenVPN with Smartcard

[Alon Bar-L. <alo...@gm...>]

This is strange, can you please send config.log?


On Tue, Feb 19, 2013 at 1:54 AM, Chris J Arges
<chr...@gm...>wrote:

> On 02/17/2013 09:42 AM, Ludovic Rousseau wrote:
> > 2013/2/13 Chris J Arges <chr...@gm...>:
> >> On 02/13/2013 10:15 AM, Alon Bar-Lev wrote:
> >>> Can you please attach the opensc debug log as well?
> >>>
> >>
> >> Attached is a log from a different run, but the results were the same. I
> >> can recollect all logs if necessary.
> >
> > The PKCS#11 functions from OpenSC all returned CKR_OK. In particular
> > C_Sign() also returned CKR_OK.
> > So at the OpenSC level everything looks fine.
> >
> > I have no idea what is wrong.
> >
> > Bye
>
> Ok I've found a workaround that allows me to connect and it is related
> to OpenSC.
>
> It seems that _WIN32 is being defined (on a Linux system) when I build
> OpenSC from the latest git source. And this was causing an issue in
> C_Initialize that made it immediately C_Finalize. I used the following
> patch to hack around this, and now OpenVPN connects using a smartcard
> via OpenSC.
>
> diff --git a/src/pkcs11/pkcs11-global.c b/src/pkcs11/pkcs11-global.c
> index 5652975..bbf897b 100644
> --- a/src/pkcs11/pkcs11-global.c
> +++ b/src/pkcs11/pkcs11-global.c
> @@ -199,6 +199,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
>         sc_context_param_t ctx_opts;
>
>         /* Handle fork() exception */
> +#if 0
>  #if !defined(_WIN32)
>         if (current_pid != initialized_pid) {
>                 C_Finalize(NULL_PTR);
> @@ -206,6 +207,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
>         initialized_pid = current_pid;
>         in_finalize = 0;
>  #endif
> +#endif
>
>         if (context != NULL) {
>                 sc_log(context, "C_Initialize(): Cryptoki already
> initialized\n");
>
> However, it seems the larger problem would be disabling _WIN32 from
> being defined on Linux systems. I'm not sure if this is a function of
> autotool versions or what.
>
> Thanks,
> --chris j arges
>
>
>

Re: [Opensc-devel] Issues connecting to OpenVPN with Smartcard

[Chris J A. <chr...@gm...>]

On 02/17/2013 09:42 AM, Ludovic Rousseau wrote:
> 2013/2/13 Chris J Arges <chr...@gm...>:
>> On 02/13/2013 10:15 AM, Alon Bar-Lev wrote:
>>> Can you please attach the opensc debug log as well?
>>>
>>
>> Attached is a log from a different run, but the results were the same. I
>> can recollect all logs if necessary.
> 
> The PKCS#11 functions from OpenSC all returned CKR_OK. In particular
> C_Sign() also returned CKR_OK.
> So at the OpenSC level everything looks fine.
> 
> I have no idea what is wrong.
> 
> Bye

Ok I've found a workaround that allows me to connect and it is related
to OpenSC.

It seems that _WIN32 is being defined (on a Linux system) when I build
OpenSC from the latest git source. And this was causing an issue in
C_Initialize that made it immediately C_Finalize. I used the following
patch to hack around this, and now OpenVPN connects using a smartcard
via OpenSC.

diff --git a/src/pkcs11/pkcs11-global.c b/src/pkcs11/pkcs11-global.c
index 5652975..bbf897b 100644
--- a/src/pkcs11/pkcs11-global.c
+++ b/src/pkcs11/pkcs11-global.c
@@ -199,6 +199,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
        sc_context_param_t ctx_opts;

        /* Handle fork() exception */
+#if 0
 #if !defined(_WIN32)
        if (current_pid != initialized_pid) {
                C_Finalize(NULL_PTR);
@@ -206,6 +207,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
        initialized_pid = current_pid;
        in_finalize = 0;
 #endif
+#endif

        if (context != NULL) {
                sc_log(context, "C_Initialize(): Cryptoki already
initialized\n");

However, it seems the larger problem would be disabling _WIN32 from
being defined on Linux systems. I'm not sure if this is a function of
autotool versions or what.

Thanks,
--chris j arges

Re: [Opensc-devel] C_Initialize

[Nikos M. <n.m...@gm...>]

On 02/18/2013 09:37 PM, Douglas E. Engert wrote:

> Your solution below might work, but I would like others
> to comment on your proposal as well.
> On a different point, your first note says:
> "This causes quite a problem in gnutls which has transparent smart card
> support and calls C_Initialize on startup."
> How transparent is this?


You may want to check the manual to get an idea about how that works:
http://www.gnutls.org/manual/html_node/Smart-cards-and-HSMs.html#Smart-cards-and-HSMs

> How does gnutls find a PKCS#11 implementation?


We use p11-kit and additionally a configuration file.

> Wll gnutls try and load any and all PKCS#11 modules it finds?


depending on p11-kit configuration.

> Can it load more then one PKCS#11 module?


yes.


> I ask this as just loading another PKCS#11 may include
> loading more libraries, placing more of a dependency on
> all these libraries loading correctly even when they are
> not used.


So far they load correctly. We have this support quite some time. The
main issue we have is the initialization delay due to opensc (and
sometimes other modules as well).

> The OpenSC PKCS#11 will include OpenSSL for example.


I don't like that, but I don't always get what I like. Nevertheless,
this is dynamic loading so I'm not really concerned.

> OpenSC will try and use pcscd as well.
> I am asking this as adding "transparent smart card support"
> may not be as transparent as you think.


I don't understand what you mean here.

> I see in:
> http://www.gnu.org/software/gnutls/manual/gnutls.html#Smart-cards-and-HSMs
> is using /etc/pkcs11/modules a system wide file?


Yes. This is the p11-kit configuration file.

p11-kit: http://p11-glue.freedesktop.org/p11-kit.html

regards,
Nikos