Re: [opensc-devel] Segmentation fault in pkcs11-tool
On 12/20/2012 8:04 AM, Anna Pavlova wrote: > Hi Douglas, > > >Something completely different to try is to test use your libPkcs11.so > >module with FireFox or Thunderbird: > > it runs fine under Firefox - it shows the slots and the slotInfo. Thunderbird > I don't have so I didn't try it. > > >Can you do a ldd pkcs11-tool > >and ldd libPkcs11.so > > yes, for some strange reason I get > > anna@anna:~/OpenSC/src/tools$ ldd pkcs11-tool > not a dynamic executable You are running it out of the build directory? That may be a shell script. The install will get the real pkcs11-tool from src/tools/.libs/pkcs11-tool If you are building, can you use the OpenSC-0.13.0 On Wed, Dec 5, 2012 at 6:23 PM, Greg Troxel wrote: https://github.com/OpenSC/OpenSC/tags https://sourceforge.net/projects/opensc/files/OpenSC/ https://opensc.fr/jenkins/ > > That doesn't seem right. I try to find out what's going on. > > With my module: > > anna@anna:~/PKCS11_Project$ ldd libPkcs11.so > > linux-gate.so.1 => (0xb76f1000) > libpcsclite.so.1 => /usr/local/lib/libpcsclite.so.1 (0xb73bd000) > libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb72d2000) > librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb72c8000) > libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb72aa000) > libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7128000) > libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb710d000) > libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb70e3000) > /lib/ld-linux.so.2 (0xb76f2000) > > > >OK, then lets step back a bit, > >and set a breakpoint at C_LoadModule > >Its in OpenSC ./common/libpkcs11.c > > > I made a debug log to show the steps I've done - it's in the attached file (I > left some printouts in the code of a type "Test text" - please ignore that). > So to summarize, I can access > C_GetFunctionList and it appears I get the correct function list. The address > of p11 in openSC is identical with the one in my module. C_Initialize in > OpenSC and in my module are also identical. > > But I agree it could be a linking problem in my module, i just can't put my > finger on it what am I dong wrong :-(. I'm getting kind of deperate on this. > Thanks for staying in this with me! > You are using C++, are your functions declared as C? I use of the RTLD_LAZY vs RTLD_NOW may make a difference. Your C_GetFunctionList may be picking up something in the pkcs11-tool or one of its libraries, when it should be picking up the version in your library. > I try it with libtool as you suggested and let's see what happens. > > And tomorrow has to be the end of the world.. *sigh*.. this week is pretty > bad :-(. > > Cheers, > Anna > > On Wed, Dec 19, 2012 at 4:27 PM, Douglas E. Engert <mailto:deeng...@anl.gov>> wrote: > > ldd pkcs11 > > -- 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] Openssl pkcs11-engine using s_client with PIV card
On 12/20/2012 7:54 AM, Matthew Zimmerman wrote: > I'm trying to debug an SSL connection to a webserver utilizing my PIV > Authentication Certificate and the associated private key on my card > and I believe I've found a bug in mechanism.c > > I *think* I'm doing everything correctly, although documentation on > the engine in openssl are *very* sparse. Here's how I'm setting up > the connection. > > openssl > engine -t dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre > ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre > MODULE_PATH:src/pkcs11/.libs/opensc-pkcs11.so -pre VERBOSE > s_client -engine pkcs11 -connect webserver:443 -CAfile ca.crt -cert > pivauth.crt -certform PEM -key 1:01 -keyform engine -prexit > > According to the opensc tools, my card is in slot 1 and my key is id > 01. I'm fairly certain I'm using the -key and -keyform parameters > correctly but I'm not sure of -cert and -certform. Should I instead > be telling openssl how to pull the cert from my card instead of the > local file (which corresponds with the key?) How do I do that? (I've > tried a few ways.) The OpenSC engine can pull the cert from the card, but it looks like the OpenSSL c_client does not support using an engine for the cert. It calls load_cert. Look at the load_cert (vs the load_key) routines in the OpenSSL src/apps/apps.c It does not recognize FORMAT_ENGINE. So you have to get the cert off the card in a separate step: pkcs15-tool -r 01 > cert.01.pem For the -key parameter, I have always used slot_1-id_01 for the auth cert. I had not looked to see if 1:01 works too. An examples: openssl << EOT engine dynamic - -pre SO_PATH:$OPENSC_ENGINE/engines/engine_pkcs11.so -pre ID:pkcs11 -pre NO_VCHECK:1 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:$OPENSC_PATH/opensc-pkcs11.so dgst -engine pkcs11 -keyform engine -sign slot_1-id_02 -c -out /tmp/test.ec.sig.out fake.ec.key/ec.msg.txt EOT > > This will prompt me for my pin, but then segfaults on line 428 of > mechanism.c -- seemingly data is pointing to an address but has no > member buffer_len (this could be wrong, my c and gdb experience is > highly lacking) > > Found slot: Broadcom Corp 5880 [Contacted SmartCard] (0123456789ABCD) 00 00 > Found token: PIV_II (PIV Card Holder pin) > Found 4 certificates: > 1Certificate for PIV Authentication > 2Certificate for Digital Signature > 3Certificate for Key Management > 4Certificate for Card Authentication > PKCS#11 token PIN: > Found 4 keys: > 1 P PIV AUTH key > 2 P SIGN key > 3 P KEY MAN key > 4 P CARD AUTH key > > Program received signal SIGSEGV, Segmentation fault. > 0x2c155660 in sc_pkcs11_signature_final (operation=0x6cb7d0, > pSignature=0x7fffda30 "", pulSignatureLen=0x0) at mechanism.c:428 > 428 sc_log(context, "data length %li", data->buffer_len); > (gdb) print data > $1 = (struct signature_data *) 0x30 > (gdb) print data->buffer_len > Cannot access memory at address 0x248 > (gdb) backtrace > #0 0x2c155660 in sc_pkcs11_signature_final > (operation=0x6cb7d0, pSignature=0x7fffda30 "", > pulSignatureLen=0x0) at mechanism.c:428 > #1 0x2b036e3d in look_str_cb () from /usr/lib/libcrypto.so.1.0.0 > #2 0x2b04722c in lh_doall_arg () from /usr/lib/libcrypto.so.1.0.0 > #3 0x2b03565c in engine_table_doall () from > /usr/lib/libcrypto.so.1.0.0 > #4 0x2b037203 in ENGINE_pkey_asn1_find_str () from > /usr/lib/libcrypto.so.1.0.0 > #5 0x2b071fa3 in EVP_PKEY_asn1_find_str () from > /usr/lib/libcrypto.so.1.0.0 > #6 0x2ad179d7 in ssl_create_cipher_list () from > /usr/lib/libssl.so.1.0.0 > #7 0x2ad10964 in SSL_CTX_new () from /usr/lib/libssl.so.1.0.0 > #8 0x0043d07e in ?? () > #9 0x00419587 in ?? () > #10 0x0041927d in ?? () > #11 0x2b363725 in __libc_start_main () from /usr/lib/libc.so.6 > #12 0x0041934d in ?? () > #13 0x00007fffffffe598 in ?? () > #14 0x in ?? () > > Thanks for any advice/patches/help :) > Matt > ___ > 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] Segmentation fault in pkcs11-tool
On 12/19/2012 3:59 AM, Anna Pavlova wrote: > Hello Douglas, > Something completely different to try is to test use your libPkcs11.so module with FireFox or Thunderbird: FireFox: Tools-> Options-> Advanced -> Security Devices -> Load Then give it a name, and the /path/to/libPkcs11.so. The if it loads, it will show up in the left hand column, and list the readers it can see. If you put a card in the reader it will show some info about it. If that fails, then the problem is in your module for sure and not OpenSC, and the problem may be in the way you link the module. I also see you module is C++. I don't think this is a problem but could be. Can you do a ldd pkcs11-tool and ldd libPkcs11.so There might be some share lib that both use but different versions. > >It sounds like opensc is compiled with the -g but not your module. > > you're right I didn't use the -g option while compiling my module, I added > the -g option into my project and now when I compile my module I do > (simplified): > > gcc -fpermissive -Wall -g -c -O2 -I../foo/includes -fPIC -MMD -MP -MF > build/Release/GNU-Linux-x86/source/foox.o.d -o > build/Release/GNU-Linux-x86/source/foox.o source/foox.cpp > > gcc -fpermissive -Wall -g -shared -o ../../../libPkcs11.so -fPIC > build/Release/GNU-Linux-x86/source/foos.o -L../../../ -lbase > -lboost_date_time -lboost_serialization -lboost_system -lboost_thread > -lpkcs11crypto -lpcsclite -lstdc++ -lrt > > > When I try to debug the p11->C_Initialize(NULL) line it doesn't allow me to > go into the call. I used > > (gdb) break pkcs11-tool.c:670 > (gdb) run > Breakpoint 1, main (argc=5, argv=0xb294) at pkcs11-tool.c:670 > 670rv = p11->C_Initialize(NULL); > (gdb) step > > which immediately returns: > > Program received signal SIGSEGV, Segmentation fault. > 0xd810b787 in ?? () OK, then lets step back a bit, and set a breakpoint at C_LoadModule Its in OpenSC ./common/libpkcs11.c step through it (using s command) step into the sc_dlopen, sc_dlsym function (using n command) Then step into the line: rv = sc_get_function_list(func) This should be the C_GetFunctionList command in your module. Then print out the funcs: p *funcs > > > I can give OpenSC-0.13.0 a try but I don't think with a newer version my > problem disappears... > > > >In the OpenSC ./src/pkcs11/Makefile.am has: > > > >opensc_pkcs11_la_LDFLAGS = $(AM_LDFLAGS) \ > > -export-symbols "$(srcdir)/opensc-pkcs11.exports" \ > > -module -shared -avoid-version -no-undefined > > I'm sorry, but I don't really know what the -module and -no-undefined options > are :-(. Are these gcc options? No they are libtool options, and it looks like on Ubuntu -module -no-undefined are not required. But the -export-symbols tells the linker to only export the functions as listed in opensc-pkcs11.exports which is one function C_GetFunctionList. Consider using libtool to build your module. > > Cheers, > Anna > > On Tue, Dec 18, 2012 at 4:38 PM, Douglas E. Engert <mailto:deeng...@anl.gov>> wrote: > > module > > -- 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] Segmentation fault in pkcs11-tool
On 12/18/2012 8:01 AM, Anna Pavlova wrote:
> Hello Douglas and Anthony,
>
> sorry for late reply and cool, thanks you for helping me with gdb :-).
>
> Thanks to you help I was able to run with my loaded library in debug mode.
> Anyway, the crash (in the debug mode) looks as follows:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xd810b787 in ?? ()
>
> where 0xd810b787 is p11->C_Initialize (checked with printf("p11 = 0x%0x,
> p11->C_Initialize = 0x%0x\n", p11, p11->C_Initialize);)
>
> >OK, but is 0x5810b6fa in your module?
>
> This I am not completely sure about. But I don't really know how can I find
> out if this is in my module or not.
> I suspect that there is C_Initialize defined also somewhere else and the
> pkcs11-tool picks it from somewhere else and not from my library.
>
>
> >I will ask again, does your module define the C_GetFunctionList, and does it
> >return a valid function list?
>
> Yes it has - in the upper layer of the library I defined it as
>
> CK_DEFINE_FUNCTION(CK_RV, C_GetFunctionList)
> (
>CK_FUNCTION_LIST_PTR_PTR ppFunctionList // receives pointer to function
> list
> )
> {
> try
> {
> API_ENTRY();
> API_PARAM_PTR_EX("ppFunctionList", ppFunctionList);
>
> if (ppFunctionList == NULL)
> API_EXIT(CKR_ARGUMENTS_BAD);
>
> *ppFunctionList = &functionList;
>
> API_EXIT(CKR_OK);
> }
> catch(...)
> {
> TRACE_ERROR("Catching top-level exception", "");
> API_EXIT(CKR_FUNCTION_FAILED);
> }
> }
>
> And it should return a valid function list. In fact I have my own small test
> tool that uses dlopen(libname, RTLD_NOW) to open the library and GetFuncList
> = (C_GetFunctionListPtr)dlsym(lib,
> "C_GetFunctionList") to get the correct address of the functions.
The OpenSC ./common/libscdl.c uses dlopen(filename, RTLD_LAZY)
and dlsym(handle, symbol)
I suspect that it has something to do with how your module is linked,
and your use of RLTD_NOW vs RTLD_LAZY.
In the OpenSC ./src/pkcs11/Makefile.am has:
opensc_pkcs11_la_LDFLAGS = $(AM_LDFLAGS) \
-export-symbols "$(srcdir)/opensc-pkcs11.exports" \
-module -shared -avoid-version -no-undefined
Libtool uses the -module and -no-undefined to make sure that your module
will only reference symbols from itself and its dependent libraries,
and in effect does what RTLD_NOW would do, but does it when creating
the module rather then when it is being loaded.
>
> I believe this is the same thing as done with pkcs11-tool, but somehow it
> works in my small test tool, I can do C_Initialize and other pkcs11 functions
> and in pkcs11-tool it crashes.
>
> I have Ubuntu11.10, 32bit and the OpenSC version is very recent -
> opensc0.12.1-1ubuntu1
> I took it from here: http://apt.gooze.eu/ubuntu/dists/oneiric/
Actually that is not that new but should work.
To get the most out of gdb, you need to compile and link with the -g option
It sounds like opensc is compiled with the -g but not your module.
You may also want to try the OpenSC-0.13.0
> The next release is tagged on the github OpenSC/OpenSC project,
> thanks to all of you for your contributions.
>
> Tarball and MSI installers can be found on github, sourceforge or the CI
> server:
> https://github.com/OpenSC/OpenSC/tags
> https://sourceforge.net/projects/opensc/files/OpenSC/
> https://opensc.fr/jenkins/
> The packages for the other OSs will be added.
>
>
> Cheers,
> Anna
>
>
> On Mon, Dec 17, 2012 at 8:59 PM, Douglas E. Engert <mailto:deeng...@anl.gov>> wrote:
>
> gdb --args pkcs11-tool
>
>
--
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] Segmentation fault in pkcs11-tool
On 12/17/2012 11:37 AM, Anna Pavlova wrote:
> Hello Douglas,
>
>
> > Sounds like p11 == NULL, or p11->C_Initialize is NULL or not valid.
>
> I did:
>
> printf("p11 = 0x%0x, p11->C_Initialize = 0x%0x\n", p11, p11->C_Initialize);
>
> in pkcs11-tool.c, just after C_LoadModule and before p11->C_Initialize(NULL)
>
> and got:
>
> p11 = 0xb7214060, p11->C_Initialize = 0x5810b6fa
OK, but is 0x5810b6fa in your module?
What version of OpenSC are you running?
On what OS?
>
> so it is not null.
>
>
> >Can you run this under gdb?
>
> Unfortunately I'm not very good in gdb :-(
>
> anna@anna:~/OpenSC/src/tools$ export LD_LIBRARY_PATH=`ls ../*/.libs -d | tr
> '\012' :`
> anna@anna:~/OpenSC/src/tools$ cd .libs/
> anna@anna:~/OpenSC/src/tools/.
> libs$ gdb 'pkcs11-tool --module /home/anna/PKCS11_Project/libPkcs11.so'
>
> the last command returns:
> pkcs11-tool --module /home/anna/PKCS11_Project/libPkcs11.so: No such file or
> directory.
One way is to use the --args
gdb --args pkcs11-tool --module /home/anna/PKCS11_Project/libPkcs11.so -l -O
break pkcs11-tool.c:558
run
If it crashes, It should show a back trace.
If it does not then to print out the p11 structure:
p *p11
I will ask again, does your module define the C_GetFunctionList, and does it
return a valid function list?
How did you link it?
>
> Of course, when I run only:
> anna@anna:~/OpenSC/src/tools/.libs$ gdb pkcs11-tool
>
> that one runs and I can run in debug mode, but I'm afraid that then I'm not
> loading my module.
>
> Do you know how can I run gdb and also use my own library? Sorry, I'm not
> really used to work with gdb :-(
>
>
> >Did you define a C_GetFunctionList in the module?
>
> Yes I did. In fact when I printed out in pkcs11-tool.c
>
> printf("%d \n",p11->version.major);
> printf("%d \n",p11->version.minor);
>
> it printed out the correct values. This is also the only thing that I can
> call with p11. But yes, C_GetFunctionList is defined in my library.
>
>
>
> >You must make sure the you module is linked as a module
> >and not just a shared library, so that functions returned by
> > C_GetFunctionList points at the functions in your module,
> >and not ones that may be defined by the caller.
>
> This is an interesting point, thank you. Actually no, I have built and linked
> it just like a shared library. I thought what's written as 'module' in the
> code and 'shared library' are the same things.
>
> Thanks,
> Anna
>
>
> On Mon, Dec 17, 2012 at 4:18 PM, Douglas E. Engert <mailto:deeng...@anl.gov>> wrote:
>
>
>
> On 12/17/2012 7:01 AM, Anna Pavlova wrote:
> > Hello,
> >
> > I am new to OpenSC but I was looking for a 3rd party tool with which I
> could test my self-developed pkcs11 library and I came across the OpenSC
> pkcs11-tool.
> >
> > I installed OpenSC under Ubuntu11.10, following
> http://www.gooze.eu/howto/smartcard-quickstarter-guide/opensc-installation-under-gnu-linux
> > everything went fine, but when I wanted to run the pkcs11-tool:
> >
> > > pkcs11-tool --module /home/anna/PKCS11_Project/libPkcs11.so -l -O
>
>
> >
> > I got segmentation fault.
> >
> > I was able to find the place where the code crashed. In pkcs11-tool.c
> the line (558):
> >
> > rv = p11->C_Initialize(NULL);
>
> Sounds like p11 == NULL, or p11->C_Initialize is NULL or not valid.
> It should point at your C_Initialize routine.
>
> Can you run this under gdb?
>
> >
> > seem to crash. The message is just "Segmentation fault"
> >
> > The module loads apparently fine.
> > module = C_LoadModule(opt_module, &p11); //no error here
> >
> > The problem is, that in my pkcs11 library I put an error message at
> the very beginning of the C_Initialize function, but not even this is printed
> out. So I don't think the crash comes from my
> library.
> > I turned on the creation of a log file in my pkcs11 library, but not
> even my pkcs11 library log file is created.
> >
>
> Did you define a C_GetFunctionList in the module?
>
> You must make sure the you module is linked as a module
> and not just a shared library, so that functions returned by
>C_GetFunctionList points at the functions in your module,
> and not ones that may be defined by the caller.
>
> Have a look at t
Re: [opensc-devel] Segmentation fault in pkcs11-tool
On 12/17/2012 7:01 AM, Anna Pavlova wrote: > Hello, > > I am new to OpenSC but I was looking for a 3rd party tool with which I could > test my self-developed pkcs11 library and I came across the OpenSC > pkcs11-tool. > > I installed OpenSC under Ubuntu11.10, following > http://www.gooze.eu/howto/smartcard-quickstarter-guide/opensc-installation-under-gnu-linux > everything went fine, but when I wanted to run the pkcs11-tool: > > > pkcs11-tool --module /home/anna/PKCS11_Project/libPkcs11.so -l -O > > I got segmentation fault. > > I was able to find the place where the code crashed. In pkcs11-tool.c the > line (558): > > rv = p11->C_Initialize(NULL); Sounds like p11 == NULL, or p11->C_Initialize is NULL or not valid. It should point at your C_Initialize routine. Can you run this under gdb? > > seem to crash. The message is just "Segmentation fault" > > The module loads apparently fine. > module = C_LoadModule(opt_module, &p11); //no error here > > The problem is, that in my pkcs11 library I put an error message at the very > beginning of the C_Initialize function, but not even this is printed out. So > I don't think the crash comes from my library. > I turned on the creation of a log file in my pkcs11 library, but not even my > pkcs11 library log file is created. > Did you define a C_GetFunctionList in the module? You must make sure the you module is linked as a module and not just a shared library, so that functions returned by C_GetFunctionList points at the functions in your module, and not ones that may be defined by the caller. Have a look at the pkcs11-spy too which is a PKCS#11 module that loads a second PKCS#11 module. > > I tried to google this problem and found this old thread: > http://www.opensc-project.org/pipermail/opensc-devel/2003-April/000831.html > > But it didn't really help me (rebuilding openssl didn't solve the problem..). > Could anyone help? > > Thanks for any help, > Anna > > > ___________ > 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] Changing Admin PIN on PIV card
Two more things: The command should be "24" not "2C". 2C is to reset the user pin if the pin is locked. "24" is to reset one of the pins if the pin is known. The script I sent you has an error. Sorry about that. piv-tool -s 00:24:00:81:10:31:32:33:34:FF:FF:FF:FF:31:31:31:31:FF:FF:FF:FF BUT: NIST 800-73-2 part 2 Section 3.2.2 says: "The ability to change reference data associated with key references '81' and '00' using the PIV Card Application CHANGE REFERENCE DATA command is optional." Thus you need to consult the Gemalto manuals to see if this is implemented On 12/12/2012 8:01 PM, Ravneet Singh Khalsa wrote: > Hi Douglas, > > Thanks for your suggestion. I tried the following command. > > piv-tool -s 00:2C:00:81:10:31:32:33:34:FF:FF:FF:FF:31:31:31:31:FF:FF:FF:FF > (changing Admin Pin from 1234 to ) > > It didn't work for me. The output of the command above is attached. See if > there is something that you can figure out. > > Thanks. > > > -Original Message- > From: opensc-devel-boun...@lists.opensc-project.org > [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of Douglas > E. Engert > Sent: Wednesday, December 12, 2012 7:31 AM > To: opensc-devel@lists.opensc-project.org > Subject: Re: [opensc-devel] Changing Admin PIN on PIV card > > > > On 12/11/2012 8:06 PM, Ravneet Singh Khalsa wrote: >> Hi, >> >> Does there any tool or API exists to change Admin PIN on Gemalto PIV Cards > ? > > If the card is following NIST 800-73-3 The piv-tool can do it. > > 800-73 leaves a lot of card management commands up to the vendor, so check > the vendor docs on this and what is the initial PUK. The PUK is not used be > the end user, and some commands to the card may require the global pin vs > the PIV application PIN or PUK as defined in 800-73-3. > > >piv-tool -s 00:2C:00:81:10:$OLDPUK:$NEWPUK > > Where $OLDPUK is the current and $NEWPUK is the new one Both are hex > representation of the numbers padded to 8 with FF > > So to change from 1234567 to 112233 >piv-tool -s > 00:2C:00:81:10:31:32:33:34:35:36:37:ff:31:31:32:32:33:33:ff:ff > > On some cards the previous PUK may have been all hex zeros. > > The attached script could be used. It is assuming a $1 parameter that is a > card number ($CARDN) that is used to look up information about the card, > such as the previous PUK in ./cards/$CARDN/ > > >> >> Thanks. >> >> >> >> ___ >> 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] Changing Admin PIN on PIV card
On 12/12/2012 8:01 PM, Ravneet Singh Khalsa wrote: > Hi Douglas, > > Thanks for your suggestion. I tried the following command. > > piv-tool -s 00:2C:00:81:10:31:32:33:34:FF:FF:FF:FF:31:31:31:31:FF:FF:FF:FF > (changing Admin Pin from 1234 to ) > > It didn't work for me. The output of the command above is attached. See if > there is something that you can figure out. That looks very strange, almost like it never ran the command. What would help more would be to turn on debugging in the opensc.conf, debug = 7; and change the debug_file = some.out.out.file; This would show that OpenSC found that this was a PIV card, and any other commands sent to the card to test what type of card it is. If you could send The debug output from opensc-tool -n You say these are Gemalto PIV cards. Do they have actual data on the cards, even demo data? Are they Global Platform cards? What is the ATR? Do you have the Gemalto manual? Do they say anything about how to change the admin PIN? Did they say anything about unlocking the card before doing anything with the card? NIST requires blank cards with the PIV application on the card to be transported locked with the unlocking keys send in some other way. The locking may be done using GP. Did they send any pins or keys with the cards? (They must have, otherwise you would not know what was the admin PIN.) > > Thanks. > > > -Original Message- > From: opensc-devel-boun...@lists.opensc-project.org > [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of Douglas > E. Engert > Sent: Wednesday, December 12, 2012 7:31 AM > To: opensc-devel@lists.opensc-project.org > Subject: Re: [opensc-devel] Changing Admin PIN on PIV card > > > > On 12/11/2012 8:06 PM, Ravneet Singh Khalsa wrote: >> Hi, >> >> Does there any tool or API exists to change Admin PIN on Gemalto PIV Cards > ? > > If the card is following NIST 800-73-3 The piv-tool can do it. > > 800-73 leaves a lot of card management commands up to the vendor, so check > the vendor docs on this and what is the initial PUK. The PUK is not used be > the end user, and some commands to the card may require the global pin vs > the PIV application PIN or PUK as defined in 800-73-3. > > >piv-tool -s 00:2C:00:81:10:$OLDPUK:$NEWPUK > > Where $OLDPUK is the current and $NEWPUK is the new one Both are hex > representation of the numbers padded to 8 with FF > > So to change from 1234567 to 112233 >piv-tool -s > 00:2C:00:81:10:31:32:33:34:35:36:37:ff:31:31:32:32:33:33:ff:ff > > On some cards the previous PUK may have been all hex zeros. > > The attached script could be used. It is assuming a $1 parameter that is a > card number ($CARDN) that is used to look up information about the card, > such as the previous PUK in ./cards/$CARDN/ > > >> >> Thanks. >> >> >> >> ___ >> 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] Muscle smart card Applet various versions from M.U.S.C.L.E. and OpenSC
On 12/12/2012 5:17 AM, Rns Course wrote: >>This appears in the log that GET_STATUS is returning: 00 01 00 05 ... > > i.e. PROTO_VERSION_MAJOR=0, PROTO_VERSION_MINOR=1 > Where does GET_STATUS return 00 01 00 05 in log? > I mean, how did you understand GET_STATUS return 00 01 00 05 from log file? You had sent on 12/9 an attachment of the opensc debug log as output.txt. (but I cant find the original note, but I still have the attachment.) On line in output.txt, APDUs and responses from muscle_match_card in card-muscle.c: 425: APDU: 00 A4 04 00 05 A0 00 00 00 01 430: Response: 90 00 440: APDU: B0 3C 00 00 40 445: Response: 00 01 00 05 00 00 75 30 00 00 5E F6 02 02 00 00 90 00 Looking at the Muscle source that was available which is newer then the 0.9.11 I made the assumption that the actual data returned is from an older version that had Protocol major=0 minor=1, Applet major=0 minor=5 > >>buffer[pos++] = (byte) 1; // Major Card Edge Protocol version n. >>buffer[pos++] = (byte) 3; // Minor Card Edge Protocol version n. >>buffer[pos++] = (byte) 0; // Major Applet version n. >>buffer[pos++] = (byte) 9; // Minor Applet version n. > I changed version in CardEdge.java source to 0.9.11 & 0.9.13 (before that, it > was 0.6.01 at the source!) and compile it again. Its the major protocol version that OpenSC is checking, not the Applet version. > But when I run "pkcs15-init -C" command, the output was as before: > > Using reader with a card: OMNIKEY CardMan 3x21 0 > New User PIN. > Please enter User PIN: (I entered "") > Please type again to verify: > Unblock Code for New User PIN (Optional - press return for no PIN). > Please enter User unblocking PIN (PUK): > User PIN [User PIN] required. > Please enter User PIN [User PIN]: (I entered "") > Failed to create PKCS #15 meta structure: File not found > > How should I force opensc-0.13.0 to work with Muscle 0.9.11? If they are using different protocols, one side or the other will need changes. Buy a Java 2.2.2 card? > THX. > > ------------ > *From:* Douglas E. Engert > *To:* MUSCLE ; OpenSC-devel > > *Sent:* Tuesday, 11 December 2012, 0:01:32 > *Subject:* [opensc-devel] Muscle smart card Applet various versions from > M.U.S.C.L.E. and OpenSC > > I am not using the Muscle card applet, but was looking looking at the OpenSC > debug log for this thread: > Re: [opensc-devel] The smart card reader is known as "VMware Virtual USB CCID > 00 00" in linux ??!! > > The OpenSC card-muscle.c (0.12.2 or 0.13.0) is looking for > PROTO_VERSION_MAJOR=1 > > The author of the original note said: >> I've loaded and initialized Muscle applet (0.9.11) on it. > > > This appears in the log that GET_STATUS is returning: 00 01 00 05 ... > i.e. PROTO_VERSION_MAJOR=0, PROTO_VERSION_MINOR=1 > This version from 2003-12-19, does not sound like the latest to me... > > Yet in the Muscle CVS archives: > http://anonscm.debian.org/viewvc/muscleplugins/trunk/MCardApplet/ > as of 4 years ago has version.properties has: > >APPLET_VERSION_MAJOR=0 >APPLET_VERSION_MINOR=9 > >PROTO_VERSION_MAJOR=1 >PROTO_VERSION_MINOR=3 > > And there have been changes in the SVN 9 months ago, 2 years ago and > 3 years ago, which are not reflected in the Download page: > https://alioth.debian.org/frs/?group_id=30111 > > Can the download versions be update, or the page change to say > compile it yourself? Or point to the OpenSC page? > > > Then on OpenSC-project: > http://www.opensc-project.org/opensc/wiki/MuscleApplet > it says: >"OpenSC supports the Muscle applet, available from Debian SVN:" > svn co svn://svn.debian.org/muscleplugins/trunk/MCardApplet > > (This appears to be the same SVN as on the Muscle page, revision 298 > from 9 months ago.) > > "An updated version, targeting recent JavaCard 2.2.2 cards with > extended APDUs is available from github:" > http://github.com/martinpaljak/MuscleApplet > > This github is 3 years old, yet changes where made to the Muscle SVN > 9 months ago. > > https://github.com/martinpaljak/MuscleApplet/blob/master/src/com/musclecard/CardEdge/CardEdge.java > (3 years old) > buffer[pos++] = (byte) 1; // Major Card Edge Protocol version n. >buffer[pos++] = (byte) 3; // Minor Card Edge Protocol version n. >buffer[pos++] = (byte) 0; // Major Applet version n. >buffer[pos++] = (byte) 9; // Minor Applet version n. >
Re: [opensc-devel] Changing Admin PIN on PIV card
On 12/11/2012 8:06 PM, Ravneet Singh Khalsa wrote:
Hi,
Does there any tool or API exists to change Admin PIN on Gemalto PIV Cards ?
If the card is following NIST 800-73-3 The piv-tool can do it.
800-73 leaves a lot of card management commands up to the vendor,
so check the vendor docs on this and what is the initial PUK. The PUK
is not used be the end user, and some commands to the card may
require the global pin vs the PIV application PIN or PUK as defined
in 800-73-3.
piv-tool -s 00:2C:00:81:10:$OLDPUK:$NEWPUK
Where $OLDPUK is the current and $NEWPUK is the new one
Both are hex representation of the numbers padded to 8 with FF
So to change from 1234567 to 112233
piv-tool -s 00:2C:00:81:10:31:32:33:34:35:36:37:ff:31:31:32:32:33:33:ff:ff
On some cards the previous PUK may have been all hex zeros.
The attached script could be used. It is assuming a $1 parameter that is a
card number ($CARDN) that is used to look up information about the card,
such as the previous PUK in ./cards/$CARDN/
Thanks.
___
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
#!/bin/sh
#
# change a pin or puk or using the old pin or puk
#
# parms
#
# c- change a pin, will prompt for oldpin and newpin
# puk - change the puk using old puk will prompt for newpuk
# r- reset pin using puk prompt for new pin
# If using puk get from database,
# cards/$CARDN.puk
# if changing puk save to database
# save previous as cards/$CARDN.puk.prev
# new as cards/$CARDN.puk
PATH=/opt/smartcard/bin:$PATH
ConvertPin()
{
# $1 is string of hex digits with : or decimal digits
# hh:hh:hh:hh:hh:hh:hh:hh
# 0 meaning 00:00:00:00:00:00:00:00
# place output in CONVERTEDPIN
if [ "X$1" = "X0" ] ; then
CONVERTEDPIN="00:00:00:00:00:00:00:00"
return
fi
XTEST=`echo "$1" | tr "0123456789abcdefABCDEF" "00" `
DTEST=`echo "$1" | tr "0123456789" "00" `
if [ "X$XTEST" = "X00:00:00:00:00:00:00:00" ] ; then
CONVERTEDPIN="$1"
return
fi
case $DTEST in
00)
CONVERTEDPIN=`echo "${1}FF:FF" | sed -e 's/[0-9]/3&:/g'`
;;
000)
CONVERTEDPIN=`echo "${1}FF" | sed -e 's/[0-9]/3&:/g'`
;;
)
CONVERTEDPIN=`echo "${1}" | sed -e 's/[0-9]/3&:/g' -e 's/:$//'`
;;
*)
echo "invalid format of pin=\"$1\""
echo " pin must be 6, 7 or 8 digits or"
echo " hex string like hh:hh:hh:hh:hh:hh:hh:hh"
echo " \"0\" for 00:00:00:00:00:00:00:00"
CONVERTEDPIN=""
;;
esac
set +x
}
##
GetPin()
{
# $1 is number of times to prompt, 1 for now
# $2 is the prompt
#
CONVERTEDPIN=""
until [ "X$CONVERTEDPIN" != "X" ]
do
# echo without the cr, works on Solaris and Linux
printf "%s:" "$2"
read ANS
ConvertPin "$ANS"
done
READPIN=$CONVERTEDPIN
}
##
# mian
##
# Change pin using pin:
# 00 24 00 80 10 oldpin newpin
# Change pin using puk
# 00 2C 00 80 10 oldpuk newpin
# Change puk using puk
# 00 2C 00 81 10 oldpuk newpuk
#
case "X$2" in
Xc*|Xpuk|Xr*)
;;
*)
echo "card number and operation required"
echo " operations are:"
echo "c - change a user pin using the old user pin"
echo "puk - change the puk to new puk"
echo "r - reset the user pin using the puk"
exit 1
;;
esac
CARDN="$1"
OPT="$2"
#
# make sure we have an old puk and it is valid format
#
if [ ! -f cards/$CARDN.puk ] ; then
echo "cards/$CARDN.puk" not found
exit 1
fi
OLDPUK=`cat cards/$CARDN.puk`
ConvertPin $OLDPUK
if [ "X$CONVERTEDPIN" = "X" ] ; then
echo "old puk from \"cards/$CARDN.puk\" is not valid"
exit 1
fi
OLDPUK="$CONVERTEDPIN"
case $OPT in
c*)
GetPin 1 "Old User Pin"
OLDPIN="$READPIN"
GetPin 1 "New User Pin"
NEWPIN="$READPIN"
piv-tool -s 00:24:00:80:10:$OLDPIN:$NEWPIN
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 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
[opensc-devel] Muscle smart card Applet various versions from M.U.S.C.L.E. and OpenSC
I am not using the Muscle card applet, but was looking looking at the OpenSC debug log for this thread: Re: [opensc-devel] The smart card reader is known as "VMware Virtual USB CCID 00 00" in linux ??!! The OpenSC card-muscle.c (0.12.2 or 0.13.0) is looking for PROTO_VERSION_MAJOR=1 The author of the original note said: > I've loaded and initialized Muscle applet (0.9.11) on it. This appears in the log that GET_STATUS is returning: 00 01 00 05 ... i.e. PROTO_VERSION_MAJOR=0, PROTO_VERSION_MINOR=1 This version from 2003-12-19, does not sound like the latest to me... Yet in the Muscle CVS archives: http://anonscm.debian.org/viewvc/muscleplugins/trunk/MCardApplet/ as of 4 years ago has version.properties has: APPLET_VERSION_MAJOR=0 APPLET_VERSION_MINOR=9 PROTO_VERSION_MAJOR=1 PROTO_VERSION_MINOR=3 And there have been changes in the SVN 9 months ago, 2 years ago and 3 years ago, which are not reflected in the Download page: https://alioth.debian.org/frs/?group_id=30111 Can the download versions be update, or the page change to say compile it yourself? Or point to the OpenSC page? Then on OpenSC-project: http://www.opensc-project.org/opensc/wiki/MuscleApplet it says: "OpenSC supports the Muscle applet, available from Debian SVN:" svn co svn://svn.debian.org/muscleplugins/trunk/MCardApplet (This appears to be the same SVN as on the Muscle page, revision 298 from 9 months ago.) "An updated version, targeting recent JavaCard 2.2.2 cards with extended APDUs is available from github:" http://github.com/martinpaljak/MuscleApplet This github is 3 years old, yet changes where made to the Muscle SVN 9 months ago. https://github.com/martinpaljak/MuscleApplet/blob/master/src/com/musclecard/CardEdge/CardEdge.java (3 years old) buffer[pos++] = (byte) 1; // Major Card Edge Protocol version n. buffer[pos++] = (byte) 3; // Minor Card Edge Protocol version n. buffer[pos++] = (byte) 0; // Major Applet version n. buffer[pos++] = (byte) 9; // Minor Applet version n. Which is in line with the PROTO_VERSION_MAJOR the OpenSC code is looking for. Can Martin and Ludovic get together and get these versions in sync, and make it so others don't download the 9 year old version? Thanks. -- 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] The smart card reader is known as "VMware Virtual USB CCID 00 00" in linux ??!!
More on this. Looking at the trace you did send on 12/9/2012: line 418: 0x7fff706e5cc0 14:39:03.351 [pkcs15-tool] card.c:180:sc_connect_card: trying driver: muscle causes the muscle_match_card in card-muscle.c to try and select the muscle applet with APDU: 00 A4 04 00 05 A0 00 00 00 01 with response: 90 00 It then reads some version information for the applet on the card APDU: B0 3C 00 00 40 with response: 00 01 00 05 00 00 75 30 00 00 5E F6 02 02 00 00 90 00 It is Successful, but response[0] == 0x00, but muscle_match_card is looking for 0x01 so it does not recognize the applet. Can you check how you loaded the applet. On 12/10/2012 9:54 AM, Douglas E. Engert wrote: > > > 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 force the ATR to be mapped > to a specific supported card. > > > 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. > > > > > > > > > > > > > > In a previous note you said: >>> Opensc-tool doesn't find the card to show the ATR, because the card reader >>> is not known for it as OMNIKEY. > > > > >> >> No idea. >> > -- 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] PIN login broken in 0.13.0rc1
On 12/10/2012 10:46 AM, Lukas Wunner wrote: > Hi, > > I've issued pull request #111 which enhances pkcs15-gemsafeV1.c > by two features: > > > (1) Multiple key containers are now supported. > > Previously the code would only make the first certificate found > on the card available to the user. By reverse-engineering the > USB communication of the native Windows driver (Gemalto Classic > Client) it turned out that all certificates are stored in the > same file (3F001604). Up to 12 key containers are supported, > this seems to be the maximum that Gemalto's cards are capable of. > I have a card here which can store up to 10 key containers of which > 2 are allocated. This card works perfectly now. > > The private key and certificate are no longer labeled > DS key / DS certificate, but: > DS key #1, DS key #2, ... / DS certificate #1, DS certificate #2", ... > > @Douglas E. Engert: The code introduced by you with commit > 9468d989cf5f279e11f1551164624c2cd1b25948 is still there, > i.e. the key_ref may be overridden by the opensc.conf card flag, > but it will override the key_ref of *all* keys on the card if > there's more than one. I'm not sure if this functionality is > still necessary. We no longer use these cards. The code in 9468d9 may no longer be needed if you are able to associate the certs and keys. > > > (2) ATR-specific PIN policies are now supported. > > Previously the code would use the PIN policy: > BCD, min length 6, max length 8, padded with 0xFF > However the card I was given uses the following policy: > ASCII, min length 4, max length 8, padded with 0x00 > > I tried to find out, again based on the USB communication of the > native Windows driver, whether the card may be queried for its > PIN policy. But to no avail. More specifically, I tried to find > out if the tries_left can be queried from the card, thinking that > the PIN policy is probably returned in the same APDU. So I > deliberately logged in with the wrong PIN once (=> tries_left=2) > and compared the USB communication to the case when the correct > PIN is entered right away. Turns out there's no difference. > So apparently the tries_left can't be queried from the card > and it seems likely that the PIN policy can't be queried either. > If it can, I don't know where it is stored. > > I then realized that the Windows driver installs two files: > policy.ppc and policyname.ini. Turns out the PIN policy is > encoded in these files. The equivalent to these files would > be if the user could specify a PIN policy in opensc.conf. > > Since that doesn't seem to be possible so far, I modified the > code so that ATR-specific PIN policies may be specified. This > is similar to pkcs15-infocamere.c which uses different card > initialization functions based on the ATR of the card. > > > I also fixed the indentation in gemsafe_detect_card(), > sc_pkcs15emu_gemsafeV1_init() and sc_pkcs15emu_gemsafeV1_init_ex(). > That makes reviewing the patch more difficult, sorry. > > People who are using gemsafeV1 cards in production may want to give > this patch a try. > > Best, > > Lukas > ___ > 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] 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 force the ATR to be mapped to a specific supported card. 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. In a previous note you said: >> Opensc-tool doesn't find the card to show the ATR, because the card reader >> is not known for it as OMNIKEY. > > No idea. > -- 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] The smart card reader is known as "VMware Virtual USB CCID 00 00" in linux ??!!
> > > > Reader 0: Omnikey CardMan 3121 00 00 !! > > > > So, the command "opensc-tool -a" has the following output: > > > > Using reader with a card: VMware Virtual USB CCID 00 00 > > Failed to connect to card: Unresponsive card (correctly inserted?) > > > > When I connect the reader to the system, VMWare recognizes it as : > > "Shared OMNIKEY CardMan 3x21 0" in Removable Devices section of VM, so > > fedora finds it as "VMware Virtual USB CCID 00 00" reader not Omnikey! > > How should the card reader be introduced in VM to solve this problem? > > I guess the problem is because of VMWare settings for card reader not > > OpenSC, but I've not found more related forum than here to ask this > > question; > > > > Could you help me please? > > VMWare uses a trick to show the smart card reader in the VM without > disconnecting it from the host. > VMWare uses PC/SC on Windows to access the reader and shows it as a > fake CCID reader in the VM. > > It is strange that you can get the ATR using pcsc_scan but not using > "opensc-tool -a". > > It is also possible to connect your reader directly to the VM as any > other USB device. It will then not be available from Windows. > > Bye > > -- > Dr. Ludovic Rousseau > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > <mailto: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 > -- 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 with VMWare View
On 11/20/2012 3:09 PM, Douglas E. Engert wrote: > > > On 11/20/2012 2:35 PM, Michael Wisniewski wrote: >> Hi! >> >> I'm trying to get my PIV card to work with the "vmware-view" client on >> Ubuntu Linux. I've installed the opensc debian package 0.12.2-2ubuntu1 so >> far. They say to place the PKCS#11 modules in the >> /usr/lib/vmware/view/pkcs11 directory. I've created a symlink in that >> directory to /usr/lib/opensc-pkcs11.so. When starting the program, I get >> the following error... >> > > Do you tell it the name of the library? > > Looks like the package is adding "lib" and ".so" around the name that you > gave, > If it is doing thin internally,try a symlink from libopensc-pkcs11.so.so -> > libopensc-pkcs11.so.so Ooops, that should have been a symlink from libopensc-pkcs11.so.so -> opensc-pkcs11.so > or just copy it to the name expected. > > > >> Could not open module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so.so >> <http://libopensc-pkcs11.so.so/>: >> /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so.so >> <http://libopensc-pkcs11.so.so/>: cannot >> open shared object file: No such file or directory >> >> I was wondering if you knew which package I would have to install to obtain >> "libopensc-pkcs11.so.so <http://libopensc-pkcs11.so.so/>". I've looked >> around for it and haven't had much success finding >> it. I've also tried installing from the opensc git nightly with no luck and >> also upgraded pcsc, but still nothing. >> >> Thanks! >> >> >> ___ >> 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 with VMWare View
On 11/20/2012 2:35 PM, Michael Wisniewski wrote: > Hi! > > I'm trying to get my PIV card to work with the "vmware-view" client on Ubuntu > Linux. I've installed the opensc debian package 0.12.2-2ubuntu1 so far. > They say to place the PKCS#11 modules in the > /usr/lib/vmware/view/pkcs11 directory. I've created a symlink in that > directory to /usr/lib/opensc-pkcs11.so. When starting the program, I get the > following error... > Do you tell it the name of the library? Looks like the package is adding "lib" and ".so" around the name that you gave, If it is doing thin internally,try a symlink from libopensc-pkcs11.so.so -> libopensc-pkcs11.so.so or just copy it to the name expected. > Could not open module /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so.so > <http://libopensc-pkcs11.so.so/>: > /usr/lib/vmware/view/pkcs11/libopensc-pkcs11.so.so > <http://libopensc-pkcs11.so.so/>: cannot > open shared object file: No such file or directory > > I was wondering if you knew which package I would have to install to obtain > "libopensc-pkcs11.so.so <http://libopensc-pkcs11.so.so/>". I've looked > around for it and haven't had much success finding > it. I've also tried installing from the opensc git nightly with no luck and > also upgraded pcsc, but still nothing. > > Thanks! > > > ___________ > 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] New SE (Security Element) Company Formed
On 11/15/2012 3:40 AM, Andreas Kuehne wrote: > Hi Peter, >>> http://www.theregister.co.uk/2012/11/13/trustzone_company >>> >>> Smart cards? Don't think so. >> TrustZone isn't half bad hardware. >> >> But I bet that the solution they come up with will still use exactly >> the same old APDUs, with just a minimum bolted-on, in order to make >> something that just barely works. > we are currently looking for a secure keystore on an android phone. > Anything 'half bad' is better than nothing ;-) > Do you got any alternatives? http://code.google.com/p/seek-for-android/ Says it can use a crypto chip on a microSD card. http://www.apriva.com/products/iss/authentication/reader http://www.apriva.com/sites/default/files/android_sdk.pdf Bluetooth reader and Android SDK http://www.biometricassociates.com/products-baimobile/smart-card-reader-iphone-android.html > > Greetings, > > Andreas > -- 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] I get Card Not Present in Security Devices of FireFox browser?!
On 11/14/2012 9:48 AM, Rns Course wrote: > Hi all; > > I have a Smart Card (SmartCafe Expert 3.2 72k with JavaCard 2.2.1 and GP > 2.1.1). > I could compile Muscle Applet 0.9.11 source code with JavaCard kit 2.2.1 and > jdk 1.4.1, the CardEdge.cap file was generated and then, load and install it > on the card using GPShell 1.4.4 successfuly! > > Now, I want to use (or integrate) this card in OpenSC to be used as a > Cryptographic Token (Smart Card!) > First, I've initialized the applet by the command given on the OpenSC site: > (HERE) http://www.opensc-project.org/opensc/wiki/MuscleApplet > And everything was OK! > Then, I've downloaded and installed opensc-0.12.2.msi package (32 & 64 bit) > on windows 7 (64 bit). > I've modified "opensc.conf" file by the card ATR and "muscle" as the card > driver. > Test with the command "opensc-tool -n" was OK and I saw "MuscleApplet" as the > card driver in response! > > Now, I want to test it with Mozilla FireFox and a CA server (in here, EJBCA) > to generate a keypair in smart card (using muscle applet) and issue a > certificate to be loaded on the card (by opensc > pkcs11 library); > > I do the following in FireFox : > Options> Advanced> Encryption> Security Devices> Load> (opensc-pkcs11.dll in > system32 or syswow64 folders). > After that, the driver of reader (in here, Omnikey CardMan3x21) is displayed > in the list of Device Manager window. > > BUT, when I click on it, the status is "Not Present" ! while the card is in > the reader and detected by opensc-tool (-n option)!!! > > How can I fix this problem? > Is there some settings that may be ignored in the procedure to have this java > card ready to do Cryptographic and Authentication tasks? > > Help me please, I've searched so much to solve this problem with NO RESULT In the opensc.conf set the debug = 8; and define a debug_file. This might give a clue as to how far OpenSC has got with the card. It could also be that if there is no certificate or key on the card, Mozilla is not interested in using it. > > Thanks In Advance. > > > > > > ___ > 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] PublicKey ASN1 decoding
On 11/13/2012 12:26 PM, Viktor Tarasov wrote: > Hello Andreas, > > On Tue, Nov 13, 2012 at 10:26 AM, Andreas Schwier > mailto:andreas.schw...@cardcontact.de>> > wrote: > > What I've still on my list is to fix the EC Public Key encoding. The > current encoding (basically just the EC point) does not allow to carry > domain parameter, so I would like to change that to the > SubjectPublicKeyInfo Format. > > > Douglas was implementing support of EC curves. (Somewhere there are still few > TODOs of him.) I know. I Have my hands full with Shibboleth at the the present time. And yes using the SPKI would be a good idea for EC. > > For me there are no objections to change the format. > > If 'raw' choice has been encoded as object's value for EC key, > also has to be encoded the 'keyInfo' parameter to point to the appropriate > tokenInfo's algorithmInfo. > This algorithmInfo should contain the domain parameter as > 'algorithmInfo.parameters'. > > It seems that SPKI (instead of 'raw') choice is easier to use -- no need to > encode 'keyInfo'. > > What I'm not sure about is whether the encoding format for other key > types (RSA,DSA,GOST etc) should change to > SPKI as well. > > > GOST are also elliptic curves, and can have different algorithm.parameters. > For GOST the SPKI format should be more practical as well. > > The RSA and DSA have no algorithm parameters and so, for them there is no > difference. > > > Do you have an overview which cards store the public key encoded with > sc_pkcs15_encode_pubkey ? > > sc_pkcs15_encode_pubkey() is used by general pkcs15init part, to encode > 'direct' value for PukDF. > Currently it used by the cards that have 'native' public key (stored in SDOs). > (If all these cards implement the card specific 'read-public-key' handler -- > there is no need to add 'direct' value fo PukDF.) > > > > Andreas > > > Kind regards, > Viktor. > > > Am 13.11.2012 10:10, schrieb Viktor Tarasov: > > Hello, > > > > it seems that the reason of recent segmentation faults related to the > > uninitialized public key components (t451, t455) is here: > > > https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-pubkey.c#L373 > > > >/* this should be required, not optional. > > But it is missing in some siemens cards and thus causes warnings */ > >/* so we silence these warnings by making it optional - the card > > works ok without. :/ */ > > > > 'Optional' means that if the encoding of the public key do not conform > > PKCS#1 (as expected by OpenSC) > > the ASN1 decoding procedure silently returns the publicKey data with > > uninitialized components. > > > > The checking of input parameters in OpenSC is not always > present/perfect > > and this provokes segmentation fault in the modules that use the > > 'read-public-key' procedure (tools, pkcs#11). > > > > As for me, the common library part has to be free of the card specific > > issues -- all card specific issues has to be implemented in card > drivers. > > For that reason, recently was introduced new card operation > > 'read-public-key'. > > For a while this handler is designed to read out the 'native' public > > key (stored in SDOs), > > but it can be extended to allow the read out of the non-PKCS#1 content > > of the public key EFs . > > > > If no objections, I will turn off 'optional' flag for the > > 'publicKeyCoefficients' and will extend the argument list of > > 'read-public-key' handler. > > Then 'someone' who interested in support of the proprietary formats in > > OpenSC will implement the corresponding parsing procedure in card > driver. > > > > Kind regards, > > Viktor. > > > > > > > > ___ > > opensc-devel mailing list > > opensc-devel@lists.opensc-project.org > <mailto:opensc-devel@lists.opensc-project.org> > > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > > -- > > -CardContact Software & System Consulting > |.##> <##.| Andreas Schwier > |# #| Schülerweg 38 > |
Re: [opensc-devel] [Muscle] pcscd / firefox / ubuntu on android
On 10/25/2012 1:49 PM, Martin Paljak wrote: > On Thu, Oct 18, 2012 at 9:48 PM, Douglas E. Engert wrote: > >> So until FF and TB get the fixes, OpenSC-0.13.0 adds a new option to >> the opensc.conf file to cache the pin to accommodate older applications. >> >>pin_cache_ignore_user_consent = true; >> > > Just a suggestion-question: OpenSC behavior in not caching the user > consent PIN is logically correct, so why not disregard the user > consent bit instead on the PKCS#15 object level? Part of the problem is long lead times for deployment on both OpenSC and applications. OpenSC is far ahead of the applications, and other PIV/CAC specific pkcs#11 implementations too. The support for CKA_ALWAYS_AUTHENTICATE has been talked about with Mozilla since 2006, 6 years, and code changes to support that have been around for a year and a half (or so) and only this year have made it into the NSS CVS. Its still not clear when the changes will be in TB and FF. But when they do get deployed, thing will work as expected. My Oct 18 note was in response to James Southwell's questions on the MUSCLE list dealing with this same issue. By using OpenSC 0.13.0 and uncommenting the line in opensc.conf he got his card working. One could not just disregard the user consent bit at the PKCS#15 level, because if the card enforces it, the OpenSC and application better send the pin just before the crypto operation, and they don't. A related problem is Mathias Tausig's thread: "Re: [opensc-devel] PIN not sent to card before signing" on 10/23 is another example of a card enforcing user_consent, but the OpenSC code issuing a sign operation, that fail, then trying again, but the security context is now not valid. > > IMHO it feels a bit weird, that there is the PIN caching (to be turned > on or off, on by default), then this mechanism that first disables PIN > caching (user consent), then there is a mechanism that enables it > again. Yes it looks weird. By putting the #pin_cache_ignore_user_consent = true; in the opensc.conf file allows one to provide a fix or circumvention (by just uncommenting the line) to get cards that enforce user_consent with OpenSC 0.13.0 to work with older applications without a code change, just a configuration change. > > This would of course unfortunately mean crippling the semantics of the > module (reporting a "normal" key when in fact it has > CKA_ALWAYS_AUTHENTICATE implemented in the hardware). > > The real problem is the difficulty in exposing the different PKCS#11 > hacks and tweaks to different applications in an easily managed way, > with concurrent applications... The hacks are: pin caching, and PIN caching for user_consent, and these are there because many PKCS#11 implementations don't know how to support CKA_ALWAYS_AUTHENTICATE and many applications don't know how to ask for CKA_ALWAYS_AUTHENTICATE, even though cards are being issued that enforce it. > > > Just a thought. Yes it is messy. CKA_ALWAYS_AUTHENTICATE has been in PKCS#11 V2.20 since 2004, 8 years now. OpenSC 0.12.0 got ahead of these applications by enforcing user_consent, but older applications would still fail, as they did not know how to deal with it. 0.13.0 supports it *AND* provides a simple "uncomment a line in opensc.conf" to work with old applications. > > -- 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] PIN not sent to card before signing
os.c driver. >> It looks like your card is not one of them. This is were others on the list >> with CardOS cards could help. > > I don't understand that. Do you mean, that it selects the wrong card driver? > I have manually created the PKCS#15 application to reference a seperate > signature application. There are 4 pkcs15 emulation modules that appear to use the card-cardos.c driver, pkcs15-aactalis.c, pkcs15-infocamere.c, pkcs15-postecert.c, and pkcs15-tccardos. The PKCS15 emulation modules help fill in some of the details. The setting of the SC_CARD_CAP_ONLY_* flags used in card-cardos.c, are set in pkcs15.c in a fix_starcos-pkcs15-card(), and maybe a similar response to the type of problem you are seeing. (but not a generic fix, if the flags can be derived form some information on the card.) I don't have any CardOS cards or experience with them but others on this list do, and they should respond. What might be the issue is CardOS is not a true PKCS15 card, or does not store all the FLAGS that are required, or none of the previous cards supported user_consent, or user_consent was never set on and keys on these cards. I see the problem, but without any CardOS cards, don't know the best way to fix it. > >> >>> Oct 24 16:35:41 off17 pcscd[4490]: 0377 APDU: 00 2A 9E 9A 14 04 75 95 >>> D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00015614 SW: 69 82 >> >> It tried a third time, but the Security status is not satisfied. >> >>> Now it doesn't change back to the PKCS#15 DF anymore, but it reselects the >>> signature DF anyhow, with the same result. >>> >>> The decicsive lines in the debug log appear to be those: >>> >>> 0xb721d900 16:35:41.195 [opensc-pkcs11] pkcs15- >>> sec.c:479:sc_pkcs15_compute_signature: Private key path '3f001fff' >>> 0xb721d900 16:35:41.195 [opensc-pkcs11] pkcs15-sec.c:42:select_key_file: >>> called 0xb721d900 16:35:41.195 [opensc-pkcs11] card.c:610:sc_select_file: >>> called; type=2, path=3f001fff >>> 0xb721d900 16:35:41.195 [opensc-pkcs11] >>> card-cardos.c:439:cardos_select_file: called >>> >>> It seems like sc_pkcs15_compute_signature selects the path of the private >>> key without a prior check, if it is already there. Do you agree? >>> >>> cheers >>> Mathias >>> >>> P.S.: Did you exclude the mailing list on purpose? >> >> No sorry, must have just hit reply vs reply all. >> >> Getting others involved would be a good idea, as there >> are a number of cards that use the same code, and it looks >> like user_consent was not considered when the sc_pkcs11_compute_signature >> was written. >> >> If you want, send your response to this message to the list. >> > > Done ;-) > > cheers > Mathias > >>> On Wednesday 24. October 2012 08:56:35 you wrote: >>>> On 10/24/2012 7:31 AM, Mathias Tausig wrote: >>>>> On Tuesday 23. October 2012 09:42:51 Douglas E. Engert wrote: >>>>>> On 10/23/2012 3:43 AM, Mathias Tausig wrote: >>>>>>> On Monday 22. October 2012 13:45:36 Douglas E. Engert wrote: >>>>>>>> Based on the information in this thread, it looks like >>>>>>>> pkcs11-tool is is missing two lines that would check >>>>>>>> if the CKA_ALWAYS_AUTHENTICATE is set for the key >>>>>>>> in the sign_data routine. >>>>>>>> >>>>>>>> Can you try the attached patch? >>>>>> >>>>>> The patch I sent you was for 0.13.0pre1. >>>>>> >>>>>> It looks like you applied it to some earlier version, as >>>>>> 0.12.2 and above have: >>>>>> >>>>>> ATTR_METHOD(ALWAYS_AUTHENTICATE, CK_BBOOL); >>>>>> which is equivelent to the line you added: >>>>>> static CK_BBOOL getALWAYS_AUTHENTICATE (CK_SESSION_HANDLE sess, >>>>>> CK_OBJECT_HANDLE obj); >>>>> >>>>> OK. Do you think it would be useful to try out the 0.13 beta version? >>>> >>>> Depending on you needs you could try with 0.12.2 or 0.13.0pre1. >>>> but any fixes will only go into 0.13. >>>> >>>> OK, so it looks like the card is enforcing user_consent. >>>> The best thing to do is modify the opensc.conf something like: >>>> >>>> debug_level = 7; >>>> debug_file = /tmp/opensc-debug.log; >>>> >>>> If you
Re: [opensc-devel] PIN not sent to card before signing
On 10/23/2012 3:43 AM, Mathias Tausig wrote: > On Monday 22. October 2012 13:45:36 Douglas E. Engert wrote: >> Based on the information in this thread, it looks like >> pkcs11-tool is is missing two lines that would check >> if the CKA_ALWAYS_AUTHENTICATE is set for the key >> in the sign_data routine. >> >> Can you try the attached patch? The patch I sent you was for 0.13.0pre1. It looks like you applied it to some earlier version, as 0.12.2 and above have: ATTR_METHOD(ALWAYS_AUTHENTICATE, CK_BBOOL); which is equivelent to the line you added: static CK_BBOOL getALWAYS_AUTHENTICATE (CK_SESSION_HANDLE sess, CK_OBJECT_HANDLE obj); the C_Sign really does C_SignInit, C_SignUpdate, C_SignFinal. Two things might be happening here. Depending on how the card driver was written I suspect it is in the card driver or opensc , that is reselecting the 50 15 and 1F FF file each time (case (B) issue): (A) login(session,CKU_CONTEXT_SPECIFIC); may need to be done just before the C_SignFinal, to put it just before the crypto operation. In the PKCS11-spy output, line 16 should be between lines 18 and 19. (B) Even doing (A) is not good enough as the card driver is sending some select commands between the pin and the crypto operation. In the ADPU trace the order need to be: (1) APDU: 00 A4 08 00 02 50 15 (2) APDU: 00 A4 08 00 02 1F FF (3) APDU: 00 22 01 B6 03 83 01 02 (4) APDU: 00 20 00 81 06 31 32 33 34 35 36 (5) APDU: 00 2A 9E 9A 80 00 01 FF FF FF... Or maybe (4) could be between (2) and (3) You could test if this is correct by using multiple -s options with the opensc-tool adding a -s option for each of the APDUs listed in your trace and using : between bytes. opensc-tool -s 00:A4:08:00:02:50:15 \ -s 00:A4:08:00:02:1F:FF \ -s 00:22:01:B6:03:83:01:02 \ -s 00:20:00:81:06:31:32:33:34:35:36 \ -s 00:2A:9E:9A:80:00:01:FF:FF:(and add the rest ov the line) If that does not work, try moving the PIN up one line. >> > > I tried it out and had to adapt it a little bit to make it compile (the > getALWAYS_AUTHENTICATE function needed a forward declaration). But I'm afraid > it didn't help. It did do an extra C_Login call: > > 12: C_FindObjectsFinal > [in] hSession = 0x92c5f10 > Returned: 0 CKR_OK > > > 13: C_SignInit > [in] hSession = 0x92c5f10 > pMechanism->type=CKM_SHA1_RSA_PKCS > [in] hKey = 0x92c09e8 > Returned: 0 CKR_OK > > > 14: C_GetAttributeValue > [in] hSession = 0x92c5f10 > [in] hObject = 0x92c09e8 > [in] pTemplate[1]: > CKA_ALWAYS_AUTHENTICATE bfa0ef23 / 1 > [out] pTemplate[1]: > CKA_ALWAYS_AUTHENTICATE True > Returned: 0 CKR_OK > > > 15: C_GetTokenInfo > [in] slotID = 0x1 > [out] pInfo: >label: 'GLOBALTRUST test card (Signatur ' >manufacturerID: 'CardOS V4.4 (C) Siemens AG 1994-' >model: 'PKCS#15 ' >serialNumber: '910E207A1616152D' >ulMaxSessionCount: 0 >ulSessionCount: 0 >ulMaxRwSessionCount: 0 >ulRwSessionCount:0 >ulMaxPinLen: 8 >ulMinPinLen: 6 >ulTotalPublicMemory: -1 >ulFreePublicMemory: -1 >ulTotalPrivateMemory:-1 >ulFreePrivateMemory: -1 >hardwareVersion: 0.0 >firmwareVersion: 0.0 >time: '' >flags: 50c > CKF_LOGIN_REQUIRED > CKF_USER_PIN_INITIALIZED > CKF_PROTECTED_AUTHENTICATION_PATH > CKF_TOKEN_INITIALIZED > Returned: 0 CKR_OK > > > 16: C_Login > [in] hSession = 0x92c5f10 > [in] userType = CKU_CONTEXT_SPECIFIC > [in] pPin[ulPinLen] bfa1109d / 6 > 31323334 3536 > Returned: 0 CKR_OK > > > 17: C_Sign > [in] hSession = 0x92c5f10 > [in] pData[ulDataLen] bfa0f348 / 4 > 626C610A > Returned: 257 CKR_USER_NOT_LOGGED_IN > > > 18: C_SignInit > [in] hSession = 0x92c5f10 > pMechanism->type=CKM_SHA1_RSA_PKCS > [in] hKey = 0x92c09e8 > Returned: 0 CKR_OK > > > 19: C_SignUpdate > [in] hSession = 0x92c5f10 > [in] pPart[ulPartLen] bfa0f348 / 4 > 626C610A > Returned: 0 CKR_OK > > > 20: C_SignFinal > [in] hSession = 0x92c5f10 > Returned: 257 CKR_USER_NOT_LOGGED_IN > > > 21: C_Finalize > Returned: 0 CKR_OK > > > Here are the coresponding APDUs > > Oct 23 10:38:15 off17 pcscd[4499]: 8338 APDU: 00 A4 08 00 02 1F FF > Oct 23 10:38:15 off17 pcscd[4499]: 00020184 SW: 90 00 > Oct 23 10:38:15 off17 pcscd[4499]: 1183 APDU: 00 20 00 81 06 31 32 33 34 >
Re: [opensc-devel] PIN not sent to card before signing
slotDescription:'Virtual hotplug slot' '' manufacturerID: 'OpenSC (www.opensc-project.org) ' hardwareVersion: 0.0 firmwareVersion: 0.0 flags: 6 CKF_REMOVABLE_DEVICE CKF_HW_SLOT Returned: 0 CKR_OK 5: C_GetSlotInfo [in] slotID = 0x1 [out] pInfo: slotDescription:'Cherry SmartBoard XX44 00 00' '' manufacturerID: 'OpenSC (www.opensc-project.org) ' hardwareVersion: 0.0 firmwareVersion: 0.0 flags: 7 CKF_TOKEN_PRESENT CKF_REMOVABLE_DEVICE CKF_HW_SLOT Returned: 0 CKR_OK 6: C_GetTokenInfo [in] slotID = 0x1 [out] pInfo: label: 'test card (Signatur ' manufacturerID: 'CardOS V4.4 (C) Siemens AG 1994-' model: 'PKCS#15 ' serialNumber: '910E207A1616152D' ulMaxSessionCount: 0 ulSessionCount: 0 ulMaxRwSessionCount: 0 ulRwSessionCount:0 ulMaxPinLen: 8 ulMinPinLen: 6 ulTotalPublicMemory: -1 ulFreePublicMemory: -1 ulTotalPrivateMemory:-1 ulFreePrivateMemory: -1 hardwareVersion: 0.0 firmwareVersion: 0.0 time: '' flags: 50c CKF_LOGIN_REQUIRED CKF_USER_PIN_INITIALIZED CKF_PROTECTED_AUTHENTICATION_PATH CKF_TOKEN_INITIALIZED Returned: 0 CKR_OK 7: C_OpenSession [in] slotID = 0x1 [in] flags = 0x6 pApplication=(nil) Notify=(nil) [out] *phSession = 0x953bf10 Returned: 0 CKR_OK 8: C_GetTokenInfo [in] slotID = 0x1 [out] pInfo: label: 'test card (Signatur ' manufacturerID: 'CardOS V4.4 (C) Siemens AG 1994-' model: 'PKCS#15 ' serialNumber: '910E207A1616152D' ulMaxSessionCount: 0 ulSessionCount: 0 ulMaxRwSessionCount: 0 ulRwSessionCount:0 ulMaxPinLen: 8 ulMinPinLen: 6 ulTotalPublicMemory: -1 ulFreePublicMemory: -1 ulTotalPrivateMemory:-1 ulFreePrivateMemory: -1 hardwareVersion: 0.0 firmwareVersion: 0.0 time: '' flags: 50c CKF_LOGIN_REQUIRED CKF_USER_PIN_INITIALIZED CKF_PROTECTED_AUTHENTICATION_PATH CKF_TOKEN_INITIALIZED Returned: 0 CKR_OK 9: C_Login [in] hSession = 0x953bf10 [in] userType = CKU_USER [in] pPin[ulPinLen] bfcc30ce / 6 31323334 3536 Returned: 0 CKR_OK 10: C_FindObjectsInit [in] hSession = 0x953bf10 [in] pTemplate[1]: CKA_CLASS CKO_PRIVATE_KEY Returned: 0 CKR_OK 11: C_FindObjects [in] hSession = 0x953bf10 [in] ulMaxObjectCount = 0x1 [out] ulObjectCount = 0x1 Object 0x95369e8 matches Returned: 0 CKR_OK 12: C_FindObjectsFinal [in] hSession = 0x953bf10 Returned: 0 CKR_OK 13: C_SignInit [in] hSession = 0x953bf10 pMechanism->type=CKM_SHA1_RSA_PKCS [in] hKey = 0x95369e8 Returned: 0 CKR_OK 14: C_Sign [in] hSession = 0x953bf10 [in] pData[ulDataLen] bfcc05eb / 4 626C610A Returned: 257 CKR_USER_NOT_LOGGED_IN 15: C_SignInit [in] hSession = 0x953bf10 pMechanism->type=CKM_SHA1_RSA_PKCS [in] hKey = 0x95369e8 Returned: 0 CKR_OK 16: C_SignUpdate [in] hSession = 0x953bf10 [in] pPart[ulPartLen] bfcc05eb / 4 626C610A Returned: 0 CKR_OK 17: C_SignFinal [in] hSession = 0x953bf10 Returned: 257 CKR_USER_NOT_LOGGED_IN 18: C_Finalize Returned: 0 CKR_OK Displaying the private key with pkcs11-tool shows, that CKA_ALWAYS_AUTHENTICATE is set corrrectly: Private Key Object; RSA label: Signaturschlüssel ID: 42 Usage: sign Access: always authenticate cheers Mathias Kind regards, Viktor. ___ 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 -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 --- ,pkcs11-tool.c Sun Sep 16 15:57:44 2012 +++ pkcs11-tool.c Mon Oct 22 13:37:06 2012 @@ -1372,6 +1372,9 @@ r = read(fd, in_buffer, sizeof(in_buffer));
[opensc-devel] Fwd: Re: [Muscle] pcscd / firefox / ubuntu on android
Another user testing 0.13.0pre1 ... Original Message Subject: Re: [Muscle] pcscd / firefox / ubuntu on android Date: Fri, 19 Oct 2012 16:30:50 -0400 From: James Southwell Reply-To: ja...@thesouthwells.com To: Douglas E. Engert Downloaded 0.13pre1 last night and compiled. Email certs work as stated with work around. Thank you. I have one last issue, but it is Citrix related. Jim On Thu, Oct 18, 2012 at 10:59 PM, Douglas E. Engert wrote: > Ask on the opensc-mail list. there is a 0.13.0-rc1 available. > > > On 10/18/2012 7:40 PM, James Southwell wrote: >> >> When is opensc 0.13 going to be released? >> >> Thanks >> ___ >> Muscle mailing list >> mus...@lists.musclecard.com >> http://lists.drizzle.com/mailman/listinfo/muscle >> >> > > -- > > 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] PIN not sent to card before signing
On 10/19/2012 8:02 AM, Mathias Tausig wrote: > Hello! > > I am writing a PKCS#15 application for a (cardos v4.4) smartcard which > references an external signature application. The RSA key and the PIN are > stored in that external application, the PIN needs to be verified upon every > key usage. > > To accomplish this, I have set the userConsent value in the > PrivateKeyDictionaryFile to 1. > > Here is the content of the PrkDF (output from openssl): > > 0:d=0 hl=2 l= 67 cons: SEQUENCE > 2:d=1 hl=2 l= 30 cons: SEQUENCE > 4:d=2 hl=2 l= 18 prim: UTF8STRING:Signaturschlüssel > 24:d=2 hl=2 l= 2 prim: BIT STRING > - 07 80 .. > 28:d=2 hl=2 l= 1 prim: OCTET STRING > - 11. > 31:d=2 hl=2 l= 1 prim: INTEGER :01 > 34:d=1 hl=2 l= 14 cons: SEQUENCE > 36:d=2 hl=2 l= 1 prim: OCTET STRING :B > 39:d=2 hl=2 l= 2 prim: BIT STRING > - 05. >0002 - > 43:d=2 hl=2 l= 2 prim: BIT STRING > - 03 b8 .. > 47:d=2 hl=2 l= 1 prim: INTEGER :02 > 50:d=1 hl=2 l= 17 cons: cont [ 1 ] > 52:d=2 hl=2 l= 15 cons: SEQUENCE > 54:d=3 hl=2 l= 6 cons:SEQUENCE > 56:d=4 hl=2 l= 4 prim: OCTET STRING > - 3f 00 1f ff ?... > 62:d=3 hl=2 l= 2 prim:INTEGER :0400 > 66:d=3 hl=2 l= 1 prim:INTEGER :14 > 69:d=0 hl=2 l= 0 prim: EOC > > The problem is, that when I try to use the card with pkcs11-tool (either with > the --test option or with a --sign command), it doesn't verify the pin before > signing. Here is the relevant part of the APDU output: > > Oct 19 14:40:20 off17 pcscd[4590]: 6755 APDU: 00 A4 08 00 02 1F FF > Oct 19 14:40:20 off17 pcscd[4590]: 00024106 SW: 90 00 > Oct 19 14:40:20 off17 pcscd[4590]: 1410 APDU: 00 20 00 81 06 31 32 33 34 > 35 > 36 > Oct 19 14:40:20 off17 pcscd[4590]: 00048516 SW: 90 00 > Oct 19 14:40:20 off17 pcscd[4590]: 5039 APDU: 00 A4 08 00 02 50 15 > Oct 19 14:40:20 off17 pcscd[4590]: 00024963 SW: 90 00 > Oct 19 14:40:20 off17 pcscd[4590]: 1737 APDU: 00 A4 08 00 02 1F FF > Oct 19 14:40:20 off17 pcscd[4590]: 00028271 SW: 90 00 > Oct 19 14:40:20 off17 pcscd[4590]: 0164 APDU: 00 22 01 B6 03 83 01 02 > Oct 19 14:40:20 off17 pcscd[4590]: 00019795 SW: 90 00 > Oct 19 14:40:20 off17 pcscd[4590]: 0185 APDU: 00 2A 9E 9A 80 00 01 FF FF > FF > FF FF FF FF FF FF F > F FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF > FF FF FF FF FF FF FF F > F FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF > FF FF FF FF FF FF FF F > F FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 09 06 05 2B 0E 03 02 > 1A 05 00 04 14 04 75 9 > 5 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80 > Oct 19 14:40:20 off17 pcscd[4590]: 00039821 SW: 69 82 > > In the first two commands the signature DF (1fff) is entered and the PIN > verified, thant it switches back to the PKCS#15 DF without doing anything > there > (APDU#3). Than the signature DF is reentered and a signing command is tried > without prior authentication. > > Is this a bug, is the userConsent field not heeded, or am I missing something? > It sounds like a bug, in that, the opensc-pkcs11 will support the PKCS#11 CKA_ALWAYS_AUTHENTICATE flag i.e. PKCS15 user_consent, but the pkcs11-tool does not test for it, and prompt for the pin again or use the pin from the command line again. It would not take too much to add the code to pkcs11-tool. Can you run your test using the pkcs11-spy.so as the module with pkcs11-tool? (Mozilla NSS used by TB and FF have the same issue.) OpenSC 0.13.0-rc1 has a new option in the opensc.conf to allow the pin to be cached for uses be applications that do not yet support CKA_ALWAYS_AUTHENTICATE. > cheers > Mathias > > ___ > 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] [Muscle] pcscd / firefox / ubuntu on android
Ask on the opensc-mail list. there is a 0.13.0-rc1 available. On 10/18/2012 7:40 PM, James Southwell wrote: > When is opensc 0.13 going to be released? > > Thanks > ___ > Muscle mailing list > mus...@lists.musclecard.com > http://lists.drizzle.com/mailman/listinfo/muscle > > -- 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] Linking against OpenSC in visual studio 2010
On 10/15/2012 5:08 AM, Amadou Cisse wrote: > Hi, > > I am using opensc to develop a token-based application. > > I have successfully built opensc but in order to link against it in my > project, i need include files. Adding the opensc sources to my project will > trigger a build process that will not work. > What does not work? Do you have some output? > Has anyone encountered something like this? Any solutions or suggestions are > welcomed? Can your application use the PKCS#11 or Microsoft CAPI interfaces thus avoiding the need for any OpenSC header files? > > Thanks. > > -- > Amadou > > > > ___ > 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] W3C takes on Web+SecurityElements
On 10/3/2012 2:04 PM, Anders Rundgren wrote: > On 2012-10-03 20:45, Andreas Schwier wrote: >> Hmmm, so why would I want an IDP if I could prove my identity >> (certificate) and authenticity (client signature in SSL) with the >> credentials I have on my card ? The SSO aspect of the IDP... Using a smart card for every access is an annoyance especially if you have many services a user uses on a daily basis. It also allows for Federations. InCommon for example. >> >> Is it because SAML is easier to integrate than SSL client authentication >> ? Or is it because I want my IDP (e.g. Google / Facebook) to know what >> I'm doing ? The IDP in our case is an enterprise IDP only usable by employees. >> >> The IDP model is perfect for username / password, but IMHO it's of less >> use when you use keys and certificates. In the later case the CA is your >> IDP by providing you with a certificate you can use to authentication >> towards others (who trust that certificate issuer as they would trust >> the IDP). And just lets wait for the first Diginotar incident at an IDP >> - ops they've copied our SAML signing keys...) Yes that is a concern. > > I think one of the reasons is that the folks that created > TSL-client-certificate-authentication > forgot to implement logout in a way that works for web applications. > > They claim that this is a "feature" and that I'm just to understand > understand the beauty of it :-) > So everybody has to write local IDPs using SAML or cookies even if they have > PKI if they want to build anyhthing that looks like a real web app. > > Then there are of course other a very legitimate uses of IDPs where > SAML attributes carry potentially completely alien information like > a role which often is less suitable having in a certificate. Yes, that too. We can map the certificate to an employee and pass employee attributes. Especially helpful if the smart cards are issued by some higher authority. > > Andes > > >> >> Andreas >> >> Am 03.10.2012 15:44, schrieb Douglas E. Engert: >>> >>> On 10/3/2012 5:08 AM, Andreas Schwier (ML) wrote: >>>> So why do you think the smart card industry has never managed to get >>>> their stuff "web compatible" ? >>>> >>>> Isn't OpenSC the best example that "Yes, you can access a protected >>>> website / webapplication / webservice using a smart card and standard >>>> based technology" works ? >>>> >>>> The issue really is, that the topic at hand (PKI) is way to complex for >>>> the average Doe to manage. That's always the downside: Security often >>>> means complexity and comes with a price tag. And if it is complex, hard >>>> to understand and someone offers some cheaper snake-oil, I probably go >>>> for that. >>>> >>>> Rather than exposing the complexity of the matter with a zoo of options >>>> you can choose from, we need to focus on a single generic mechanism and >>>> a well designed user experience. >>>> >>>> It's all there (meaning S/MIME and TLS), it just needs to become a >>>> little simpler to manage. So rather than re-inventing the n-solution for >>>> Web-ID, SSO or One-Time-Passwords, we - as a community - should improve >>>> what is already existing. >>> The approach we are taking for SSO is Shibboleth. >>> >>> http://shibboleth.net/ >>> >>> Using the X509 login handler: >>> >>> https://wiki.shibboleth.net/confluence/display/SHIB2/X.509+Login+Handler >>> >>> OpenSC provides the client cert and key for TLS authentication to the IDP. >>> >>> Shibboleth is all SAML based, and can work with other SAML based >>> services. >>> >>> Support for OTP or whatever then is only needed in the IDP. >>> >>> >>>> Andreas >>>> >>>> >>>> >>>> >>>> >>>> >>>> Am 03.10.2012 11:09, schrieb Anders Rundgren: >>>>> http://www.w3.org/2012/09/sysapps-wg-charter >>>>> <http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ew3%2Eorg%2F2012%2F09%2Fsysapps-wg-charter&urlhash=Tqzg&_t=tracking_disc> >>>>> >>>>> Since the smart card industry have never managed making their stuff "web >>>>> compatible" before, I assume they will fail this time as well. >>>>> >>>>> Anders >>>>> ___ >>>>> 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 > > -- 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] W3C takes on Web+SecurityElements
On 10/3/2012 5:08 AM, Andreas Schwier (ML) wrote: > So why do you think the smart card industry has never managed to get > their stuff "web compatible" ? > > Isn't OpenSC the best example that "Yes, you can access a protected > website / webapplication / webservice using a smart card and standard > based technology" works ? > > The issue really is, that the topic at hand (PKI) is way to complex for > the average Doe to manage. That's always the downside: Security often > means complexity and comes with a price tag. And if it is complex, hard > to understand and someone offers some cheaper snake-oil, I probably go > for that. > > Rather than exposing the complexity of the matter with a zoo of options > you can choose from, we need to focus on a single generic mechanism and > a well designed user experience. > > It's all there (meaning S/MIME and TLS), it just needs to become a > little simpler to manage. So rather than re-inventing the n-solution for > Web-ID, SSO or One-Time-Passwords, we - as a community - should improve > what is already existing. The approach we are taking for SSO is Shibboleth. http://shibboleth.net/ Using the X509 login handler: https://wiki.shibboleth.net/confluence/display/SHIB2/X.509+Login+Handler OpenSC provides the client cert and key for TLS authentication to the IDP. Shibboleth is all SAML based, and can work with other SAML based services. Support for OTP or whatever then is only needed in the IDP. > > Andreas > > > > > > > Am 03.10.2012 11:09, schrieb Anders Rundgren: >> http://www.w3.org/2012/09/sysapps-wg-charter >> <http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ew3%2Eorg%2F2012%2F09%2Fsysapps-wg-charter&urlhash=Tqzg&_t=tracking_disc> >> >> Since the smart card industry have never managed making their stuff "web >> compatible" before, I assume they will fail this time as well. >> >> Anders >> ___________ >> 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] PIV-tool in windows environment
First of all, the piv-tool was designed to be used for test cards only, and only supports the commands from NIST 800-73-3, as each card vendor may have additional commands and requirements, such as Global Platform commands, or the need to finalize a card. NIST 800-73-3 does not provide a way to write a private key to or from the card, thus there is no standard way to escrow a key. That said, piv-tool does have a -s option to allow other commands to be sent to the card, asnd can be used with the vendor documentation. You will need a lot more then piv-tool to do proper card management. http://fips201ep.cio.gov/apl.php has a list of approved products, including card management. On 9/26/2012 7:07 PM, Ravneet Singh Khalsa wrote: > Hello experts, > > I am considering using PIV-tool for certificate enrollment for PIV cards for > my company. I am following the instructions specified in the link > http://www.opensc-project.org/opensc/wiki/PivTool. I have > downloaded the opensc-i686-w64-mingw32-011-base build on my windows 7 client > machine. The instructions on the above link looks like UNIX instructions. Can > I get equivalent windows instructions ? I was > able to generate public key using piv-tool, but I could not generate > certificate request using SSL. Is there equivalent command for Windows > specific environment ? > > The command seems to be pointing to engine_pkcs11.so and opensc-pkcs11.so > files. I couldn’t find these files anywhere. > As Peter saind look for the .dlls I do have a set of scripts to manage test cards, but they are Unix. I can send them, but they are not in top shape, and get changed as needed. > Any help would be appreciated. > > Thanks, > > Ravneet > > I am a programmer and I understand only programming languages. > > > > ___ > 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 0.13 + pcscd as a daemon for Android
On 9/26/2012 6:54 AM, Jean-Michel Pouré - GOOZE wrote: > Dear all, > > I would like to raise questions about using OpenSC 0.13 under Android. I > hope that Ben from Feitian can participate in this discussion. > > The idea behind is that Feitian released the iReader, a ccid card reader > for mobile devices. The iReader is CCID and is supported under OpenSC > (on computer). GOOZE will be releasing the iReader shortly. > > Seek4Android contains an old version of OpenSC 0.11.13. Actually, > Seek4Android requires flashing the device, which is not acceptable for > end-users of current Android systems. > > Did anyone succeeded in compiling today's pcscd and opensc under > Android-4.x? Do you think that today's pcscd and opensc can run inside > Android after compilation with a suitable keychain? > > Any information is welcome. Apriva has an SDK that says it ported PCSC lite to Android, and implies that it has the client running under Java NDK. They are supporting the CAC/PIV cards, looks like they are not using OpenSC, but some other middle ware. But if they did the PCSC port, it looks like OpenSC could use it. Here is their info with a nice diagram. http://www.apriva.com/sites/default/files/android_sdk.pdf Argonne is interested in using PIV cards with Android mobile devices, so are interested in any technologies that could do that, be it OpenSC or other middle ware to blue tooth or ccid readers. > > Kind regards, > Jean-Michel POURE > > > > ___ > 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] Strange issue in framework-pkcs15.c / pkcs15_gen_keypair
On 9/25/2012 5:01 AM, Andreas Schwier (ML) wrote: > Dear all, > > we've come a across a strange issue in OpenSC. When we try to generate a > key pair with parameters not supported by the card, then the framework > code still tries to allocate private/public key objects rather than > returning an error code. > > The questionable code is in line 2675 of framework-pkcs15.c / > pkcs15_gen_keypair. > > Is that an intended behaviour or a plain bug ? Same problem as before. No one has had a PKCS#15 card that supports ECC. The original ECC code added to OpenSC was for client use only, and used the PIV card. For testing the piv-tool could tell the card to generate a key pair, but that was not via and PKCS standards. > > Andreas > -- 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] new release?
Thunderbird 13.0.1 can now sign e-mail. I had forgot to uncomment in opensc.conf: pin_cache_ignore_user_consent = true; a new feature of 0.13.0pre1 See: http://www.opensc-project.org/pipermail/opensc-devel/2012-August/018282.html -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 smime.p7s Description: S/MIME Cryptographic Signature ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
Duh, I see you have 32 and 64 bit msi files. Since I was using 32 bit firefox and Thunderbird, I installed the 32 bit version on W7 64. It install the clients in \Program Files (x86)\... but not the Windows\system32\opensc-pkcs11.dll If I then install the 64 bit msi, it installs the \Program Files\OpenSC\... and installs Windows\system32\opensc-pkcs11.dll. Is the intent that the 64 bit msi install 64 bit tools, and opensc.dll and the 32 bit opensc-pkcs11.dll? Is there a 64 bit opensc-pkcs11.dll? Firefox 8.0.1 works to a web site. Thunderbird 13.0.1 complains about the signing certificate usage, but appears to read the certificates, and TB says the certificate chain is valid and all the CA certs are listed as trusted for signing e-mail. This sounds like a Thunderbird bug. Will have to look some more. but it looks like OpenSC is working. I was able to sign using TB 13.0.1 on Solaris using a test account. On 9/24/2012 2:43 PM, Douglas E. Engert wrote: > > > On 9/24/2012 12:52 PM, Viktor Tarasov wrote: >> On Wed, Sep 19, 2012 at 11:54 PM, Douglas E. Engert > <mailto:deeng...@anl.gov>> wrote: >> >> I have been testing 0.13.0-pre1 from tarball listed below. >> >> Builds on Solaris. >> >> works with MIT Kerberos PKINIT and pam_krb5 to login to AD as the KDC. >> >> Can sign Email using thunderbird 13.0.1. >> >> The pkcs11-tool -derive using ECDH works using a PIV test card from NIST >> and a card I created. (i.e. using the key frome a card and the cert from >> the other card, will produce the same secret key.) >> >> >> Ok, thanks for the testing. >> >> In 0.13.0-pre1 there is the bug that concerns the using of non-initialized >> OID data. >> My non-regression tests were done with the current (*d525ca97e3*) 'master' >> version: >> >> For the OpenSC installed on Linux from tarball >> the following tests of the where done using the pkcs15 and pkcs11 tools, >> with the cards 'CardOS v4.3B', 'SetCOS 4.4.1 B', 'Athena', 'Aventra' and >> 'Feitian': >> - erase card (pkcs15-init -E); >> - initialize (ex. pkcs15-init -C --label "IDX-SCM" -P --auth-id 53434D >> --so-pin "12345678" --so-puk "123456" --pin "99" --puk "88"); >> - generate RSA 1024/2048 (depending on card); >> - import PKCS#12 with user and CA certificates; >> - get public key from imported or generated key; >> - sign data using pkcs15-crypt and pkcs11-tool and verify it with openssl; >> - decrypt the data encypted by openssl; >> >> Using Firefox 12.0 and Thunderbird 15.0.1, on Vista, with IAS/ECC card and >> OpenSC installed from MSI: >> - generate key and sign certificate request; >> - import certificate; >> - authenticate to access protected web page. >> - import PKCS#12; >> - sign mail; >> - decrypt mail. >> >> As for me, still to test are minidriver (IE and outlook), smartcard logon >> (windows) and SM (for the cards that support it). >> >> Do you have other suggestions for the non-regression tests? > > If you have a Windows build, I could test PKCS#11 on Windows 7 with Firefox > and Thinderbird. > > >> >> Kind regards, >> Viktor. >> >> >> On 9/17/2012 3:00 PM, Viktor Tarasov wrote: >> > Hello, >> > >> > Le 15/09/2012 16:52, Kalev Lember a écrit : >> >> On 09/06/2012 08:06 PM, Viktor Tarasov wrote: >> >>> Hello, >> >>> >> >>> current github 'staging' is tagged as v0.13.0-pre1. >> >>> >> >>> If no objections, I will merge this branch into github 'master' -- >> it will be base version to test >> >>> and to prepare the coming release candidate. >> >> Very good idea. I think it makes a lot of sense to have just one >> >> 'master' branch for development; this is what people coming over >> from >> >> other projects tend to expect. >> > >> > >> > 'Master' and 'staging' are actually synchronized and for the new >> pull requests I propose to create them relative to the 'master' branch. >> > Until the end of this release the pull requests to 'staging' are >> also accepted. >> > >> > The tag name 'v0.13.0-pre1' has been changed (sorry) to '0.13.0pre1' >> -- still cannot understand whic
Re: [opensc-devel] new release?
On 9/24/2012 12:52 PM, Viktor Tarasov wrote: > On Wed, Sep 19, 2012 at 11:54 PM, Douglas E. Engert <mailto:deeng...@anl.gov>> wrote: > > I have been testing 0.13.0-pre1 from tarball listed below. > > Builds on Solaris. > > works with MIT Kerberos PKINIT and pam_krb5 to login to AD as the KDC. > > Can sign Email using thunderbird 13.0.1. > > The pkcs11-tool -derive using ECDH works using a PIV test card from NIST > and a card I created. (i.e. using the key frome a card and the cert from > the other card, will produce the same secret key.) > > > Ok, thanks for the testing. > > In 0.13.0-pre1 there is the bug that concerns the using of non-initialized > OID data. > My non-regression tests were done with the current (*d525ca97e3*) 'master' > version: > > For the OpenSC installed on Linux from tarball > the following tests of the where done using the pkcs15 and pkcs11 tools, > with the cards 'CardOS v4.3B', 'SetCOS 4.4.1 B', 'Athena', 'Aventra' and > 'Feitian': > - erase card (pkcs15-init -E); > - initialize (ex. pkcs15-init -C --label "IDX-SCM" -P --auth-id 53434D > --so-pin "12345678" --so-puk "123456" --pin "99" --puk "88"); > - generate RSA 1024/2048 (depending on card); > - import PKCS#12 with user and CA certificates; > - get public key from imported or generated key; > - sign data using pkcs15-crypt and pkcs11-tool and verify it with openssl; > - decrypt the data encypted by openssl; > > Using Firefox 12.0 and Thunderbird 15.0.1, on Vista, with IAS/ECC card and > OpenSC installed from MSI: > - generate key and sign certificate request; > - import certificate; > - authenticate to access protected web page. > - import PKCS#12; > - sign mail; > - decrypt mail. > > As for me, still to test are minidriver (IE and outlook), smartcard logon > (windows) and SM (for the cards that support it). > > Do you have other suggestions for the non-regression tests? If you have a Windows build, I could test PKCS#11 on Windows 7 with Firefox and Thinderbird. > > Kind regards, > Viktor. > > > On 9/17/2012 3:00 PM, Viktor Tarasov wrote: > > Hello, > > > > Le 15/09/2012 16:52, Kalev Lember a écrit : > >> On 09/06/2012 08:06 PM, Viktor Tarasov wrote: > >>> Hello, > >>> > >>> current github 'staging' is tagged as v0.13.0-pre1. > >>> > >>> If no objections, I will merge this branch into github 'master' -- > it will be base version to test > >>> and to prepare the coming release candidate. > >> Very good idea. I think it makes a lot of sense to have just one > >> 'master' branch for development; this is what people coming over from > >> other projects tend to expect. > > > > > > 'Master' and 'staging' are actually synchronized and for the new pull > requests I propose to create them relative to the 'master' branch. > > Until the end of this release the pull requests to 'staging' are also > accepted. > > > > The tag name 'v0.13.0-pre1' has been changed (sorry) to '0.13.0pre1' > -- still cannot understand which common set of characters > > could be used for the release-version/tag-name to satisfy 'git', > 'obs', 'dpkg-build', ... > > > > Commits to 'master' and new tags trigger the jenkins jobs of build, > packaging and some rudimentary test of package and unit tests (for Suse). > > https://opensc.fr/jenkins/view/Open > <https://opensc.fr/jenkins/view/OpenSC-release/>SC-release/ > <https://opensc.fr/jenkins/view/OpenSC-release/> > > > > The resulting packages are transfered to 'download' part of the > opensc-project.org <http://opensc-project.org> file server: > > - commits to > > http://www.opensc-project.org/downloads/projects/opensc/nightly/ > > - releases to > > http://www.opensc-project.org/downloads/projects/opensc/releases/ > > > > > > For a while there are only source tarballs, MSIs for x32 and x64 and > rpm i586 for opensSuSE 12.1 . > > Hope that rapidly the building of releases packages for some > debian/ubuntu distributions will be connected. > > > > It would be nice if you could look/test the tarball or packages of the > release 0.13.0pre1. > &
Re: [opensc-devel] Domain Parameter for ECC Keys
On 9/19/2012 6:11 PM, Andreas Schwier (ML) wrote: > Dear all, > > we've come across a strange behaviour of the pkcs15-lib in OpenSC when > we generate an EC key pair: > > After generating an fresh EC key pair, our code returns a > sc_pkcs15_pubkey containing the EC public key and DER encoded domain > parameter. The public key is then encoded in sc_pkcs15init_generate_key > and added to the DF in the framework when it's immediately decoded again. > > During this encode / decode step the domain parameter are lost. Looked at PKCS#15 v1.1 section 6.4.3 The value is a EC_PubKeyChoice, that can be a raw ECPoint or a spki SubjectPublicKeyInfo. It looks like the sc_pkcs15_encode_pubkey_ec is just returning the ECPoint. sc_pkcs15_decode_pubkey_ec is also assuming the ECPoint. It looks like that code has never been fully tested, and the above code should be modified to use the spki SubjectPublicKeyInfo if there are domain parameters. With the EC work I have done in OpenSC including writing the above two routines, I have not looked at the pkcs15init code at all, as the PIV card is not a PKCS#15 card but rather the PKCS#15 is emulated, and the emulation layer is base on the decoded entries. The PIV does not use the pkcs15init code at all, but rather a special pivtool can be used for test cards to generate a key. It also turns out that the PIV card does not store a pubkey object at all, but derives the pubkey from the certificate. > > I'm wondering why this encode / decode step is done ? No one has a PKCS#15 cards that support EC to test this part of the code. > > If it is required for some reason, then I would rather encode the public > key in SubjectPublicKey structure that would also preserve the domain > parameter in AlgorithmIdentifier. Can you come up with a patch? > > Andreas > -- 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] new release?
I have been testing 0.13.0-pre1 from tarball listed below. Builds on Solaris. works with MIT Kerberos PKINIT and pam_krb5 to login to AD as the KDC. Can sign Email using thunderbird 13.0.1. The pkcs11-tool -derive using ECDH works using a PIV test card from NIST and a card I created. (i.e. using the key frome a card and the cert from the other card, will produce the same secret key.) On 9/17/2012 3:00 PM, Viktor Tarasov wrote: > Hello, > > Le 15/09/2012 16:52, Kalev Lember a écrit : >> On 09/06/2012 08:06 PM, Viktor Tarasov wrote: >>> Hello, >>> >>> current github 'staging' is tagged as v0.13.0-pre1. >>> >>> If no objections, I will merge this branch into github 'master' -- it will >>> be base version to test >>> and to prepare the coming release candidate. >> Very good idea. I think it makes a lot of sense to have just one >> 'master' branch for development; this is what people coming over from >> other projects tend to expect. > > > 'Master' and 'staging' are actually synchronized and for the new pull > requests I propose to create them relative to the 'master' branch. > Until the end of this release the pull requests to 'staging' are also > accepted. > > The tag name 'v0.13.0-pre1' has been changed (sorry) to '0.13.0pre1' -- still > cannot understand which common set of characters > could be used for the release-version/tag-name to satisfy 'git', 'obs', > 'dpkg-build', ... > > Commits to 'master' and new tags trigger the jenkins jobs of build, packaging > and some rudimentary test of package and unit tests (for Suse). > https://opensc.fr/jenkins/view/Open > <https://opensc.fr/jenkins/view/OpenSC-release/>SC-release/ > <https://opensc.fr/jenkins/view/OpenSC-release/> > > The resulting packages are transfered to 'download' part of the > opensc-project.org file server: > - commits to > http://www.opensc-project.org/downloads/projects/opensc/nightly/ > - releases to > http://www.opensc-project.org/downloads/projects/opensc/releases/ > > > For a while there are only source tarballs, MSIs for x32 and x64 and rpm i586 > for opensSuSE 12.1 . > Hope that rapidly the building of releases packages for some debian/ubuntu > distributions will be connected. > > It would be nice if you could look/test the tarball or packages of the > release 0.13.0pre1. > Your remarks, proposals, contributions are heartily welcome. > > Kind regards, > Viktor. > ___ > 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] issue with sc_decompress() call when run on Big Endian OS
On 9/18/2012 10:53 AM, Puneet Khunteta wrote: > Hello, > > I observed that when i use a sc_decompress() call on a Big Endian OS ( Linux > with Arm Processor), i got a error code return -1400. > Where as it works perfectly for the window ( Little Endian) OS. > I have used the same certificate file to de-compress on both devices. > > nRet = sc_decompress(outbuff, (size_t *)&nOutBuffLen, Inbuff, nInBuffLen, > COMPRESSION_AUTO); Why do you need (size_t *) above? What is nOutBuffLen? > > nRet = -1400 ( for Big Endian) > nRet = 0( for little Endian) > > A quick help will be appreciate. Can you use COMPRESSION_GZIP or COMPRESSION_ZLIB to test if this is a problem with GZIP , ZLIB or with the detect_method routine? Do you want to use the sc_decompress_alloc? The only place I see sc_decompress used in OpenSC is used in in card-piv.c and that uses gzip. It works on Solaris sparc, a big endian machine. > > Regards > > > ___ > 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] Windows minidriver and Secure PIN Entry
On 9/10/2012 4:09 PM, Taylor, Tim wrote: > I was the OP of this thread. I've tried the following applications: > - certutil (specifically "certutil -SCInfo" to examine card contents) > - Outlook 2010 (sending signed emails) I was requesting the author of the minidriver mods that added the PIN PAD support to respond, to how they tested the mod (if at all) and what PINPAD reader(s) were tested with (if at all.) I don't think it was me :) > > With both of these, I'm prompted to enter my card PIN in a Windows > dialog box, rather than on the readers pin pad. > > I'm using an OmniKey 3821 reader which has a pin pad. > > - Tim > > On Mon, 2012-09-10 at 09:56 -0500, Douglas E. Engert wrote: >> To the list: >> The minidriver has code to test for reader features to be able to use >> a PIN PAD reader. Someone added that code. Could they please respond >> to this thread? >> >> I would suspect that the calling applications also need to be updated, >> and this may be the problem. >> >> Is there a minidriver application that can be used with a PIN PAD reader? >> If so what is it and what reader was used? >> >> On 9/7/2012 9:33 AM, Taylor, Tim wrote: >>> On Thu, 2012-09-06 at 15:06 -0500, Douglas E. Engert wrote: >>> >>>>> With the PKCS#11 OpenSC calls pcsc_detect_readers and this calls >>>>> the detect_reader_features. >>>>> >>>>> With the minidriver, the Microsoft code passes in the handles of >>>>> open connections to PC/SC, and pcsc_detect_readers is not called, >>>>> so no special features get detected. >>>>> >>>>> It might be possible call the pcsc_reader_features from the minidriver >>>>> but it would require some code changes and testing. >>>> >>>> What version of OpenSC are your using? >>>> >>>> On What Windows OS? >>>> >>>> Looking closer the reader-pcsc.c in github has two sets of code, one >>>> for normal pcsc used by PKCS#11 and one for cardmod i.e. minidriver, >>>> that check for reader features for the pin pad. >>>> >>>> http://msdn.microsoft.com/en-us/windows/hardware/gg487500.aspx >>>> >>>> Version 6 says External PINs for PIN PAD are new. >>>> Vista and later. >>>> >>>> Version 7 Talks about External PINs. >>>> Windows 7 and later. >>>> >>>> So the code may be there. A trace might be helpful. >>> >>> I'm on Windows 7, fully patched. >>> >>> "opensc-tool -i" returns: >>> opensc 0.12.2 [Microsoft 1600] >>> Enabled features:pcsc openssl zlib >>> >>> - Tim >>> ___ >>> 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 > > -- 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] Two back-to-back runs, different results
On 9/6/2012 9:54 PM, B. Scott Michel wrote: On 9/6/2012 1:38 PM, Douglas E. Engert wrote: On 9/6/2012 11:39 AM, B. Scott Michel wrote: Tried another reader, the Cherry ST-1044U. pkcs15-tool identifies the card using card-piv.c's code using the T0 protocol and will correctly print the card's certificates -- the first time. Second run, though, same problem: card is subsequently identified as a T1 card, can't find certificates. What version of OpenSC and pcsc-lite are you running and on what platform? This sounds like an old problem. I'm tracking github and building from source - 0.13. I do an uninstall followed by an install from the resulting disk image (dmg). Looking a the reader-pcsc.c code, it is not clear if the reader->active_protocol is being set correctly. The one piece of info you sent in your initial note indicated it was changing from T0 to T1. It looks like your card can only do T0, thus pcsc should not be saying it is doing T1. Attached is a patch based on the git repository from 0.13.0-pr1 that adds some additional debugging of the processing of the protocol processing. I suspect that the values of reader->active_protocol is not 1, 2, or 1000 as defined by SC_PROTO_* and may be 0, which should not happen. It may be that the version of pcsc on the MAC you have is not returning a valid value for active_proto. That should be 1, 2 or 4. as defined by SCARD_PROTOCOL_* The output of a trace with this patch should show if this is true or not. It should not be changing from T=0 to T=1 after the card was working with T=0 the first time. I figured as much, hence, my motivation to debug and potentially hack source code. Directors of Computer Systems Research Departments are expected to keep hacking skills in excellent shape (Aerospace is the "space" FFRDC in El Segundo, CA, if you're not familiar with us.) pkcs15-tool -v -v -v -v -v -v -c then send the full output, from both the first and second times. Will do. I have some older test cards that may be T=0, I will try them. But I am gone till Monday. Something else to try, is to edit the opensc.conf. you can add debug_file = somefilename; debug = 9; This would cut out interference from other drivers: force_card_driver = "piv"; also try: force_protocol = "t0"; (I have not tried the force_* options.) Will do. -scooter -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 diff --git a/src/libopensc/reader-pcsc.c b/src/libopensc/reader-pcsc.c index 920b6f1..158c06f 100644 --- a/src/libopensc/reader-pcsc.c +++ b/src/libopensc/reader-pcsc.c @@ -242,6 +242,8 @@ static int pcsc_transmit(sc_reader_t *reader, sc_apdu_t *apdu) goto out; } /* encode and log the APDU */ + sc_debug(reader->ctx, SC_LOG_DEBUG_NORMAL, "active_protocol: %02x", reader->active_protocol); + r = sc_apdu_get_octets(reader->ctx, apdu, &sbuf, &ssize, reader->active_protocol); if (r != SC_SUCCESS) goto out; @@ -436,6 +438,9 @@ static int pcsc_reconnect(sc_reader_t * reader, DWORD action) } reader->active_protocol = pcsc_proto_to_opensc(active_proto); + + sc_debug(reader->ctx, SC_LOG_DEBUG_NORMAL, "Reconnect protocol: %02x active_proto: %02x active_protocol: %02x", protocol, active_proto, reader->active_protocol); + return pcsc_to_opensc_error(rv); } @@ -476,6 +481,8 @@ static int pcsc_connect(sc_reader_t *reader) reader->active_protocol = pcsc_proto_to_opensc(active_proto); priv->pcsc_card = card_handle; + sc_debug(reader->ctx, SC_LOG_DEBUG_NORMAL, "Initial active_proto: %02x active_protocol: %02x", active_proto, reader->active_protocol); + sc_debug(reader->ctx, SC_LOG_DEBUG_NORMAL, "Initial protocol: %s", reader->active_protocol == SC_PROTO_T1 ? "T=1" : "T=0"); /* Check if we need a specific protocol. refresh_attributes above already sets the ATR */ @@ -491,6 +498,8 @@ static int pcsc_connect(sc_reader_t *reader) sc_debug(reader->ctx, SC_LOG_DEBUG_NORMAL, "Final protocol: %s", reader->active_protocol == SC_PROTO_T1 ? "T=1" : "T=0"); } + sc_debug(reader->ctx, SC_LOG_DEBUG_NORMAL, "Final active_proto: %02x active_protocol: %02x", active_proto, reader->active_protocol); + /* After connect reader is not locked yet */ priv->locked = 0; ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Windows minidriver and Secure PIN Entry
To the list: The minidriver has code to test for reader features to be able to use a PIN PAD reader. Someone added that code. Could they please respond to this thread? I would suspect that the calling applications also need to be updated, and this may be the problem. Is there a minidriver application that can be used with a PIN PAD reader? If so what is it and what reader was used? On 9/7/2012 9:33 AM, Taylor, Tim wrote: > On Thu, 2012-09-06 at 15:06 -0500, Douglas E. Engert wrote: > >>> With the PKCS#11 OpenSC calls pcsc_detect_readers and this calls >>> the detect_reader_features. >>> >>> With the minidriver, the Microsoft code passes in the handles of >>> open connections to PC/SC, and pcsc_detect_readers is not called, >>> so no special features get detected. >>> >>> It might be possible call the pcsc_reader_features from the minidriver >>> but it would require some code changes and testing. >> >> What version of OpenSC are your using? >> >> On What Windows OS? >> >> Looking closer the reader-pcsc.c in github has two sets of code, one >> for normal pcsc used by PKCS#11 and one for cardmod i.e. minidriver, >> that check for reader features for the pin pad. >> >> http://msdn.microsoft.com/en-us/windows/hardware/gg487500.aspx >> >> Version 6 says External PINs for PIN PAD are new. >> Vista and later. >> >> Version 7 Talks about External PINs. >> Windows 7 and later. >> >> So the code may be there. A trace might be helpful. > > I'm on Windows 7, fully patched. > > "opensc-tool -i" returns: > opensc 0.12.2 [Microsoft 1600] > Enabled features:pcsc openssl zlib > > - Tim > ___ > 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] Windows minidriver and Secure PIN Entry
On 9/5/2012 5:17 PM, Douglas E. Engert wrote: > > > On 9/5/2012 4:32 PM, Taylor, Tim wrote: >> I have installed the drivers from HID Global for this reader. >> >> The same reader device driver will be used regardless of whether the >> PKCS#11 module, or the minidriver is used to interact with the Smart >> Card, right? >> >> And as I mentioned when I use the PCKS#11 driver, I'm prompted to enter >> my pin on the pinpad. When I use the opensc minidriver, I'm prompted to >> enter my pin in a windows dialog box using the PC keyboard. >> >> Is the opensc minidriver not able to detect and use the pinpad? > > > With the PKCS#11 OpenSC calls pcsc_detect_readers and this calls > the detect_reader_features. > > With the minidriver, the Microsoft code passes in the handles of > open connections to PC/SC, and pcsc_detect_readers is not called, > so no special features get detected. > > It might be possible call the pcsc_reader_features from the minidriver > but it would require some code changes and testing. What version of OpenSC are your using? On What Windows OS? Looking closer the reader-pcsc.c in github has two sets of code, one for normal pcsc used by PKCS#11 and one for cardmod i.e. minidriver, that check for reader features for the pin pad. http://msdn.microsoft.com/en-us/windows/hardware/gg487500.aspx Version 6 says External PINs for PIN PAD are new. Vista and later. Version 7 Talks about External PINs. Windows 7 and later. So the code may be there. A trace might be helpful. > > > >> >> - Tim >> >> On Sat, 2012-08-25 at 01:10 +0200, Frank Morgner wrote: >>> The default Windows USB CCID driver does not support secure PIN entry. >>> You need to get a better driver for your reader. Presumably OmniKey >>> provides such a driver. >>> >>> Cheers, Frank. >>> >>> >>> On Friday, August 24 at 03:03PM, Taylor, Tim wrote: >>>> >>>> Hello, >>>> >>>> I've been a long time user of the opensc project on linux. Now I'm >>>> trying to use OpenSC on Windows 7. >>>> >>>> The reader I'm using is an OmniKey 3821 USB CCID device with an LCD >>>> display and a PIN pad. Using the opensc PKCS#11 module in applications >>>> such as firefox or thunderbird works great, requiring the card PIN to be >>>> entered on the PIN pad of the reader as desired. >>>> >>>> Now I'm looking at using the opensc minidriver to provide access for >>>> applications that use the Windows crpyto API. After some fiddling >>>> around, I managed to change the driver for my smart card (Gemalto >>>> TOPDLGX4 144k) to the opensc minidriver. However, when I use an >>>> application that tries to access the card, I'm prompted to enter the PIN >>>> in a Windows dialog rather than the reader PIN pad. >>>> >>>> Is there a way to have the external PIN pad be used to enter card PINs >>>> when using the opensc minidriver? >>>> >>>> - Tim >>>> >>>> ___ >>>> 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 >> >> > -- 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] new release?
OK with me. I can not do any testing till early next week. On 9/6/2012 1:06 PM, Viktor Tarasov wrote: > Hello, > > current github 'staging' is tagged as v0.13.0-pre1. > > If no objections, I will merge this branch into github 'master' -- it will be > base version to test > and to prepare the coming release candidate. > > For the future (after this release), I think (and it was already suggested > here) > that we don't really need two branches in github. > We could use the unique 'master' branch, tag it as needed by release process, > and to manage all proposals as pull requests to 'master'. > > For a while there is no packages (tarbals, MSIs, ...) labeled by tag name, > only the packages automatically built on 'staging' branch and labeled by git > version. > > I will create the release dedicated jenkins jobs and will put thus prepared > packages onto the 'usual' places. > > > Kind regards, > Viktor. > > ___ > 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] Windows minidriver and Secure PIN Entry
On 9/5/2012 4:32 PM, Taylor, Tim wrote: > I have installed the drivers from HID Global for this reader. > > The same reader device driver will be used regardless of whether the > PKCS#11 module, or the minidriver is used to interact with the Smart > Card, right? > > And as I mentioned when I use the PCKS#11 driver, I'm prompted to enter > my pin on the pinpad. When I use the opensc minidriver, I'm prompted to > enter my pin in a windows dialog box using the PC keyboard. > > Is the opensc minidriver not able to detect and use the pinpad? With the PKCS#11 OpenSC calls pcsc_detect_readers and this calls the detect_reader_features. With the minidriver, the Microsoft code passes in the handles of open connections to PC/SC, and pcsc_detect_readers is not called, so no special features get detected. It might be possible call the pcsc_reader_features from the minidriver but it would require some code changes and testing. > > - Tim > > On Sat, 2012-08-25 at 01:10 +0200, Frank Morgner wrote: >> The default Windows USB CCID driver does not support secure PIN entry. >> You need to get a better driver for your reader. Presumably OmniKey >> provides such a driver. >> >> Cheers, Frank. >> >> >> On Friday, August 24 at 03:03PM, Taylor, Tim wrote: >>> >>> Hello, >>> >>> I've been a long time user of the opensc project on linux. Now I'm >>> trying to use OpenSC on Windows 7. >>> >>> The reader I'm using is an OmniKey 3821 USB CCID device with an LCD >>> display and a PIN pad. Using the opensc PKCS#11 module in applications >>> such as firefox or thunderbird works great, requiring the card PIN to be >>> entered on the PIN pad of the reader as desired. >>> >>> Now I'm looking at using the opensc minidriver to provide access for >>> applications that use the Windows crpyto API. After some fiddling >>> around, I managed to change the driver for my smart card (Gemalto >>> TOPDLGX4 144k) to the opensc minidriver. However, when I use an >>> application that tries to access the card, I'm prompted to enter the PIN >>> in a Windows dialog rather than the reader PIN pad. >>> >>> Is there a way to have the external PIN pad be used to enter card PINs >>> when using the opensc minidriver? >>> >>> - Tim >>> >>> _______ >>> 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 > > -- 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] Two back-to-back runs, different results
On 9/5/2012 12:48 PM, Scott Michel wrote: > I am trying to debug an issue with the SCM 311 reader and Oberthur ID One > card in order to better support Macs and smart card-enabled sites. I've been > using pkcs15-tool to list certificates on the card. The result is that on the > first run with the card inserted for the first time, certificates are listed. > On the next, second run, no certificates are listed; pkcs15-tool reports no > certificates. > > Turning up the debugging volume, I get the following unified diff output > (/tmp/run-11 is the first run, /tmp/run-22 is the second run, timestamps > stripped). On the first run, the card is detected as a T0 protocol card. On > the second run, the card is detected as a T1 protocol card. I'm fairly > certain this is a problem (listing certificates requires APDU messages, not > TPDU messages, no?), but not sure where to go look in the code to propose a > patch. (*) > > --- /tmp/run-11 2012-09-05 10:12:04.0 -0700 > +++ /tmp/run-22 2012-09-05 10:12:08.0 -0700 > @@ -21,7 +21,7 @@ > reader-pcsc.c:325:refresh_attributes: current state: 0x0120 > reader-pcsc.c:326:refresh_attributes: previous state: 0x0120 > reader-pcsc.c:380:refresh_attributes: card present > -reader-pcsc.c:497:pcsc_connect: Initial protocol: T0 protocol > +reader-pcsc.c:497:pcsc_connect: Initial protocol: T1 protocol > card.c:868:match_atr_table: ATR : > 3b:db:96:00:80:1f:03:00:31:c0:64:b0:f3:10:00:07:90:00:80 That looks like a DoD CAC, Oberthur ID One 128 v5.5 Dual and the ATR says the protocol is T0. But the card and reader may try and negotiate T1. In a number of Oberthur documents it talks about ISO 7816-3 from 2006 supporting higher baud rates, and the card reader needs to be up to data. It one it talks about a card appearing to be mute. A pcscd debug trace might show something too. Try a newer reader? Is this a dual CAC and PIV card? (Does not look like it as the ATR for PIV has the application.) OpenSC only supports PIV or dual PIV and CAC. You could also try coolkey that supports CAC. > card.c:879:match_atr_table: ATR try : > 3B:DD:18:00:81:31:FE:45:80:F9:A0:00:00:00:77:01:00:70:0A:90:00:8B > card.c:882:match_atr_table: ignored - wrong length > > Leading up to this difference, both files have the same lines (again, > timestamps stripped): > > sc.c:195:sc_detect_card_presence: called > reader-pcsc.c:388:pcsc_detect_card_presence: called > reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check > reader-pcsc.c:325:refresh_attributes: current state: 0x0120 > reader-pcsc.c:326:refresh_attributes: previous state: 0x0122 > reader-pcsc.c:380:refresh_attributes: card present > reader-pcsc.c:393:pcsc_detect_card_presence: returning with: 5 > sc.c:200:sc_detect_card_presence: returning with: 5 > Using reader with a card: SCM SCR 331 00 00 > sc.c:195:sc_detect_card_presence: called > reader-pcsc.c:388:pcsc_detect_card_presence: called > reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check > reader-pcsc.c:325:refresh_attributes: current state: 0x0120 > reader-pcsc.c:326:refresh_attributes: previous state: 0x0120 > reader-pcsc.c:380:refresh_attributes: card present > reader-pcsc.c:393:pcsc_detect_card_presence: returning with: 5 > sc.c:200:sc_detect_card_presence: returning with: 5 > card.c:125:sc_connect_card: called > reader-pcsc.c:468:pcsc_connect: called > reader-pcsc.c:301:refresh_attributes: SCM SCR 331 00 00 check > > Any clues? Try a different reader? > > > -scooter > > (*) Would it be permissible to mark unused parameters in static functions as > unused? Really. It gets in the way of tracking down interesting problems, > like signed/unsigned conversions, integer length issues, ... If the code has > to compile with -Wall, then the code could be selective with respect to which > are really important warnings, no? > ___ > 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] encrypt / decrypt
On 8/23/2012 5:21 AM, j.witvl...@mindef.nl wrote: > See below... > > -Original Message- > From: Douglas E. Engert [mailto:deeng...@anl.gov] > Sent: Wednesday, August 22, 2012 6:27 PM > To: Witvliet, J, CDC/IV/DCOPS/I&S/HIN > Cc: opensc-devel@lists.opensc-project.org > Subject: Re: [opensc-devel] encrypt / decrypt > > [SNIP] > >> -Original Message- >> >> No, the aspect of using a symmetric key didn't slip my mind. >> That very well when encrypting large amount of data... >> But when the symmetric key is large (compared to the data), then the >> overhead does not justify the means. (I think) >> And you have to transfer the encrypted key as well as the encrypted data. >> > > How short are these messages? > > Using PKCS#11 CKM_RSA_X_509, the size of the message must be less then the > size of > the modulus and if using some padded version between 11 bytes less and maybe > half > the size of the modulus. > > Using RSA directly of a previously sent message will produce the same > encrypted > output which could be subject examination or re-play. > > Smime and CMS avoid many of these security issues and others. > -Original Message- > > > Ok Douglas, > > Regarding sizes, they vary between 32B and 1KB. > > Had a look at openssl smime.. > Encryption seems no problem: > OpenSSL> smime -encrypt -in /root/data.txt -out /root/data.enc hwit-43.pem > > > But (returning to the original subject) how to specify the private key on the > card? > OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre > ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre > MODULE_PATH:/usr/lib/libaetpkss.so.3.0 > (dynamic) Dynamic engine loading support > [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so > [Success]: ID:pkcs11 > [Success]: LIST_ADD:1 > [Success]: LOAD > [Success]: MODULE_PATH:/usr/lib/libaetpkss.so.3.0 > Loaded: (pkcs11) pkcs11 engine > OpenSSL> > > OpenSSL> smime -decrypt -in /root/data.enc -out /root/data.dec -engine > pkcs11 -keyform ENGINE > error in smime > No recipient certificate or key specified > [Understandable...] > > > OpenSSL> smime -decrypt -in /root/data.enc -out /root/data.dec -engine > pkcs11 -keyform ENGINE -inkey 43 > engine "pkcs11" set. > Invalid slot number: 0 > PKCS11_get_private_key returned NULL > cannot load signing key file from engine 2771:error:26096080:engine > routines:ENGINE_load_private_key:failed loading private key:eng_pkey.c:126: > unable to load signing key file > error in smime > > while pkcs11-tool -O ... shows > ... > Private Key Object; RSA >label: Vertrouwelijkheid >ID: 43 >Usage: decrypt, unwrap > ... > > Even though I specified to use the pkcs-engine, it still seems to look for a > file for the key. > Same if I specify: "-inkey id_43" This sounds like a slot issue, and you may need to try -inkey slot_1-id_43 You may also want to try using the OpenSC pkcs11-spy to print out the PKCS#11 calls, since you are using your own /usr/lib/libaetpkss.so.3.0 and it may be handling the slot differently the opensc-pkccs11.so does. Something like : OPENSC_PATH=/usr/lib MODULE=$OPENSC_PATH/pkcs11-spy.so PKCS11SPY=/usr/lib/libaetpkss.so.3.0 export PKCS11SPY PKCS11SPY_OUTPUT=/tmp/pkcs11.spy.log export PKCS11SPY_OUTPUT openssl << EOT engine dynamic - -pre SO_PATH:$OPENSC_ENGINE/engines/engine_pkcs11.so -pre ID:pkcs11 -pre NO_VCHECK:1 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:$MODULE smime -decrypt -in /root/data.enc -out /root/data.dec -engine pkcs11 -keyform ENGINE -inkey slot_1-id_43 EOT > > Hans > > > __ > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet > de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt > u verzocht dat aan de afzender te melden en het bericht te verwijderen. De > Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die > verband houdt met risico's verbonden aan het elektronisch verzenden van > berichten. > > This message may contain information that is not intended for you. If you are > not the addressee or if this message was sent to you by mistake, you are > requested to inform the sender and delete the message. The State accepts no > liability for damage of any kind resulting from the risks inherent in the > electronic transmission of messages. > > -- 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] Minidriver assume hexstring encoding for card serial number
On 8/22/2012 1:53 PM, Andreas Schwier wrote:
> Yes, that's basically what our patch is all about. There are actually
> two places in minidriver.c where the tokeninfo->serial_number value is
> copied. We propose to change both as you can see in [1].
Looks good.
>
> Andreas
>
> [1]
> https://github.com/CardContact/OpenSC/commit/724cdd06e23ecd2e822bd1f138d9c3fbdafe9324
>
> Am 22.08.2012 20:30, schrieb Douglas E. Engert:
>>
>> On 8/22/2012 11:24 AM, Andreas Schwier (ML) wrote:
>>> Hi Douglas,
>>>
>>> see below.
>>>
>>> Am 22.08.2012 18:00, schrieb Douglas E. Engert:
>>>> On 8/22/2012 10:09 AM, Andreas Schwier wrote:
>>>>> Hi Douglas,
>>>>>
>>>>> thanks for your infos.
>>>>>
>>>>> The minidriver.c already ensures that the cardid file is always 16 byte.
>>>>> It does this by repeating the token serial number until 16 bytes are
>>>>> filled.
>>>> Unfortunately that gives OpenbSC 16 bytes but does not improve the
>>>> uniqunness.
>>>>
>>>> Fortunately the uniqueness today only needs to extend over all the cards
>>>> as seen on a single machine which may be only a hand full. the cardid
>>>> is not sent to AD for example. But it also means that if the certificates
>>>> or keys on a card are changed, the cardid should also change.
>>>>
>>>>> We can ensure uniqueness of the serial number for our cards, but no
>>>>> uniqueness among all other card vendors. There remains a (very) little
>>>>> probability that a hexadecimal encoded serial number of another vendor's
>>>>> card resembles one of our ASCII serial numbers.
>>>>>
>>>>> Our serial numbers are based on the numbering scheme for machine
>>>>> readable travel documents, a 2 digit country code followed by up to 9
>>>>> ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31
>>>>> in cardid).
>>>> You did not say what was the minimum number of digits are, and
>>>> in you example the first 4 "ACSII digits" are letters not numbers that
>>>> introduce more uniqueness then numbers. Also for a single machine would
>>>> it always see the same country code?
>>> The serial number is always 11 characters (0-9, A-Z). The country code
>>> is the country of the card issuer, within a country the card issuer gets
>>> a 2-character prefix and will define the remaining 7 character.
>> OK, so you are looking at how to handle the failure
>> in minidriver.c at line 1071, not on getting a printable string to show up.
>>
>> 1069 rv =
>> sc_hex_to_bin(vs->p15card->tokeninfo->serial_number, sn_bin, &sn_len);
>> 1070 if (rv)
>> 1071 return SCARD_E_INVALID_VALUE;
>>
>>by change to something like:
>>
>> rv = sc_hex_to_bin(vs->p15card->tokeninfo->serial_number, sn_bin,
>> &sn_len);
>> if (rv) {
>> strncpy(s_bin, vs->p15card->tokeninfo->serial_number,
>> sizeof(sn_bin));
>> sn_len = strlen(vs->p15card->tokeninfo->serial_number);
>> if (sn_len < 2) /* really too short to use as a cardid */
>> return SCARD_E_INVALID_VALUE;
>> if (sn_len > sizeof(sn_bin)) sn_len = sizeof(sn_bin);
>> }
>>
>> I have not tried this.
>>
>> Since this fails, in your case, I don't have any objection to adding
>> something
>> like the above.
>>
>>>> If you have 9 ASCII characters that should introduce enough uniqueness
>>>> to avoid conflicts with your other cards and other vendors cards.
>>>>
>>>> One point I am trying to make is the cardid value is not really seen
>>>> by the user, thus it does not have to be printable, and it could
>>>> hold more uniqueness then a printable string. But if there is not
>>>> enough unique data on the card to populate the cardid you have to use
>>>> whatever you have.
>>> Yes, I understand. I'm just concerned about the serial number visible to
>>> the user at the PKCS#15 and PKCS#11 level. There it would be nice to see
>>> the same serial number as the one printed on the card. My point is, that
>>> currently the minidriver silently assumes that the
>>> tokeninfo->serial_number contains a string with hexadecimal characters.
>&g
Re: [opensc-devel] Minidriver assume hexstring encoding for card serial number
On 8/22/2012 11:24 AM, Andreas Schwier (ML) wrote:
> Hi Douglas,
>
> see below.
>
> Am 22.08.2012 18:00, schrieb Douglas E. Engert:
>>
>> On 8/22/2012 10:09 AM, Andreas Schwier wrote:
>>> Hi Douglas,
>>>
>>> thanks for your infos.
>>>
>>> The minidriver.c already ensures that the cardid file is always 16 byte.
>>> It does this by repeating the token serial number until 16 bytes are filled.
>> Unfortunately that gives OpenbSC 16 bytes but does not improve the
>> uniqunness.
>>
>> Fortunately the uniqueness today only needs to extend over all the cards
>> as seen on a single machine which may be only a hand full. the cardid
>> is not sent to AD for example. But it also means that if the certificates
>> or keys on a card are changed, the cardid should also change.
>>
>>> We can ensure uniqueness of the serial number for our cards, but no
>>> uniqueness among all other card vendors. There remains a (very) little
>>> probability that a hexadecimal encoded serial number of another vendor's
>>> card resembles one of our ASCII serial numbers.
>>>
>>> Our serial numbers are based on the numbering scheme for machine
>>> readable travel documents, a 2 digit country code followed by up to 9
>>> ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31
>>> in cardid).
>> You did not say what was the minimum number of digits are, and
>> in you example the first 4 "ACSII digits" are letters not numbers that
>> introduce more uniqueness then numbers. Also for a single machine would
>> it always see the same country code?
> The serial number is always 11 characters (0-9, A-Z). The country code
> is the country of the card issuer, within a country the card issuer gets
> a 2-character prefix and will define the remaining 7 character.
OK, so you are looking at how to handle the failure
in minidriver.c at line 1071, not on getting a printable string to show up.
1069 rv = sc_hex_to_bin(vs->p15card->tokeninfo->serial_number,
sn_bin, &sn_len);
1070 if (rv)
1071 return SCARD_E_INVALID_VALUE;
by change to something like:
rv = sc_hex_to_bin(vs->p15card->tokeninfo->serial_number, sn_bin,
&sn_len);
if (rv) {
strncpy(s_bin, vs->p15card->tokeninfo->serial_number,
sizeof(sn_bin));
sn_len = strlen(vs->p15card->tokeninfo->serial_number);
if (sn_len < 2) /* really too short to use as a cardid */
return SCARD_E_INVALID_VALUE;
if (sn_len > sizeof(sn_bin)) sn_len = sizeof(sn_bin);
}
I have not tried this.
Since this fails, in your case, I don't have any objection to adding something
like the above.
>>
>> If you have 9 ASCII characters that should introduce enough uniqueness
>> to avoid conflicts with your other cards and other vendors cards.
>>
>> One point I am trying to make is the cardid value is not really seen
>> by the user, thus it does not have to be printable, and it could
>> hold more uniqueness then a printable string. But if there is not
>> enough unique data on the card to populate the cardid you have to use
>> whatever you have.
> Yes, I understand. I'm just concerned about the serial number visible to
> the user at the PKCS#15 and PKCS#11 level. There it would be nice to see
> the same serial number as the one printed on the card. My point is, that
> currently the minidriver silently assumes that the
> tokeninfo->serial_number contains a string with hexadecimal characters.
>>
>>> Our proposed change (see [1]) will not alter the current behaviour with
>>> existing cards. It will just allow a card that uses a ASCII serial
>>> number to work as well.
>>>
>>> An alternative approach - and probably more invasive - would be to use
>>> the result of SC_CARDCTL_GET_SERIALNR in minidriver.c as input for the
>>> cardid file. This way we could still have our human readable serial
>>> number at the PKCS#11 und PKCS#15 level and a little more uniqueness in
>>> the cardid file.
>> On some cards whewre there is no serial readable form the card the
>> SC_CARDCTL_GET_SERIALNR does similar tricts to come up with a "serial number"
>> from what ever data it can use on the card.
>>
>>
>>> This will however break existing installations, as the
>>> content of the cardid file might change with the driver update.
>>>
>> Yes it might break existing installations, as it would look like a new card
>> to the applic
Re: [opensc-devel] encrypt / decrypt
On 8/22/2012 10:51 AM, j.witvl...@mindef.nl wrote: > -Original Message- > From: opensc-devel-boun...@lists.opensc-project.org > [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of Douglas > E. Engert > Sent: Wednesday, August 22, 2012 5:12 PM > To: opensc-devel@lists.opensc-project.org > Subject: Re: [opensc-devel] encrypt / decrypt > > > > On 8/22/2012 9:50 AM, j.witvl...@mindef.nl wrote: >> Hi all, >> >> I've been trying to make more use of our smartcards, but I think I am >> missing the point some how. >> What I would like to do is: >> a) encrypt some data, by means of one of my private keys on my smartcard >> someone else should be able to decrypt it with the public key on my >> certificate. >> >> b) let someone else encrypt some data, by means of my public key on my >> certificate. >> I should be able to decrypt it with one of my private keys on my smartcard. >> >> I speak in plural about keys/certificates, cause we have different pairs for >> authentication/non-repodiation/etc >> >> So first I load the engine: >> OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre >> ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre >> MODULE_PATH:/usr/lib/libaetpkss.so.3.0 >> (dynamic) Dynamic engine loading support >> [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so >> [Success]: ID:pkcs11 >> [Success]: LIST_ADD:1 >> [Success]: LOAD >> [Success]: MODULE_PATH:/usr/lib/libaetpkss.so.3.0 >> Loaded: (pkcs11) pkcs11 engine >> OpenSSL> >> >> And next I try to encrypt something: >> OpenSSL> >> OpenSSL> enc -base64 -in /root/data.txt -out file.txt.enc -engine pkcs11 >> engine "pkcs11" set. >> OpenSSL> >> openssl enc only works with symmetric keys. You could write your own program to use openssl to use RSA. >> OpenSSL> enc -d -aes-256-cbc -a -in file.txt.enc -engine pkcs11 >> engine "pkcs11" set. >> enter aes-256-cbc decryption password: >> error in enc >> OpenSSL> >> >> >> I presume, I'll have to specify which private-key (and PIN), although "-k >> 41" or "-k 43" does not work either, neither does "-key id_43" >> Am I missing something, or is this just not possible? > > Yes you are missing something. Because asymmetric key encryption like RSA is > slow and the amount of data that can be encrypted is limited, what is usually > done is to encrypt the data in a symmetric key, like AES, then encrypt the AES > key using the RSA public key. the encrypted data and the encrypted key are > then > sent, and the process is reversed using the RSA private key. > > This packaging of the message is usually done with something like smime or CMS > Openssl can do both. (CMS in newer versions only) > -Original Message- > > No, the aspect of using a symmetric key didn't slip my mind. > That very well when encrypting large amount of data... > But when the symmetric key is large (compared to the data), then the overhead > does not justify the means. (I think) > And you have to transfer the encrypted key as well as the encrypted data. > How short are these messages? Using PKCS#11 CKM_RSA_X_509, the size of the message must be less then the size of the modulus and if using some padded version between 11 bytes less and maybe half the size of the modulus. Using RSA directly of a previously sent message will produce the same encrypted output which could be subject examination or re-play. Smime and CMS avoid many of these security issues and others. > Hw > > __ > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet > de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt > u verzocht dat aan de afzender te melden en het bericht te verwijderen. De > Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die > verband houdt met risico's verbonden aan het elektronisch verzenden van > berichten. > > This message may contain information that is not intended for you. If you are > not the addressee or if this message was sent to you by mistake, you are > requested to inform the sender and delete the message. The State accepts no > liability for damage of any kind resulting from the risks inherent in the > electronic transmission of messages. > > -- 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] Minidriver assume hexstring encoding for card serial number
On 8/22/2012 10:09 AM, Andreas Schwier wrote:
> Hi Douglas,
>
> thanks for your infos.
>
> The minidriver.c already ensures that the cardid file is always 16 byte.
> It does this by repeating the token serial number until 16 bytes are filled.
Unfortunately that gives OpenbSC 16 bytes but does not improve the uniqunness.
Fortunately the uniqueness today only needs to extend over all the cards
as seen on a single machine which may be only a hand full. the cardid
is not sent to AD for example. But it also means that if the certificates
or keys on a card are changed, the cardid should also change.
>
> We can ensure uniqueness of the serial number for our cards, but no
> uniqueness among all other card vendors. There remains a (very) little
> probability that a hexadecimal encoded serial number of another vendor's
> card resembles one of our ASCII serial numbers.
>
> Our serial numbers are based on the numbering scheme for machine
> readable travel documents, a 2 digit country code followed by up to 9
> ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31
> in cardid).
You did not say what was the minimum number of digits are, and
in you example the first 4 "ACSII digits" are letters not numbers that
introduce more uniqueness then numbers. Also for a single machine would
it always see the same country code?
If you have 9 ASCII characters that should introduce enough uniqueness
to avoid conflicts with your other cards and other vendors cards.
One point I am trying to make is the cardid value is not really seen
by the user, thus it does not have to be printable, and it could
hold more uniqueness then a printable string. But if there is not
enough unique data on the card to populate the cardid you have to use
whatever you have.
>
> Our proposed change (see [1]) will not alter the current behaviour with
> existing cards. It will just allow a card that uses a ASCII serial
> number to work as well.
>
> An alternative approach - and probably more invasive - would be to use
> the result of SC_CARDCTL_GET_SERIALNR in minidriver.c as input for the
> cardid file. This way we could still have our human readable serial
> number at the PKCS#11 und PKCS#15 level and a little more uniqueness in
> the cardid file.
On some cards whewre there is no serial readable form the card the
SC_CARDCTL_GET_SERIALNR does similar tricts to come up with a "serial number"
from what ever data it can use on the card.
> This will however break existing installations, as the
> content of the cardid file might change with the driver update.
>
Yes it might break existing installations, as it would look like a new card
to the application, but with the same certificate on two cards. This could be
an issue if Windows searches the cert store for a certificate, then asks the
user to insert the matching card. i.e. the old card, not the new one.
As long as you have 6 digits or characters in your printable string that should
be fine.
> Andreas
>
> [1]
> https://github.com/CardContact/OpenSC/commit/724cdd06e23ecd2e822bd1f138d9c3fbdafe9324
>
> Am 22.08.2012 16:29, schrieb Douglas E. Engert:
>>
>> On 8/22/2012 5:28 AM, Andreas Schwier (ML) wrote:
>>> Hi everyone,
>>>
>>> we've come across an issue with the minidriver which assumes the card
>>> serial number to be a hex string.
>>>
>>> In our card the serial number is a string composed of ASCII characters.
>>> This works well with pkcs15-tool and the PKCS#11 library, however it
>>> fails with the current minidriver when it tries to convert the hex
>>> string into binary data for the cardid file.
>>>
>>> Neither in PKCS#11 spec nor in ISO 7816-15 I can find a definition for
>>> encoding the serial number as hex string.
>> The minidriver does not use the PKCS#11 standards, it is the Microsoft
>> definition of what it expects in the cardid file that counts.
>>
>> http://www.microsoft.com/whdc/device/input/smartcard/sc-minidriver.mspx
>>
>> Section 5.4.1 says:
>>
>>"The logical name for this file is “CardId”. It is in the root directory."
>>
>>"The file is organized as a 16-byte array. It should be treated as opaque
>> binary data."
>>
>>"This value is assigned by Microsoft software to assure that a unique
>> value is
>> generated for the card. It is unrelated to the serial number that may or
>> may not
>> be assigned to the card during manufacture."
>>
>> In other places it calls it as a GUID.
>>
>> This also means that when displayed, it maybe displayed as a GUID as hex
>> digits
>> with "{", "}" "," and &
Re: [opensc-devel] encrypt / decrypt
On 8/22/2012 9:50 AM, j.witvl...@mindef.nl wrote: > Hi all, > > I've been trying to make more use of our smartcards, but I think I am missing > the point some how. > What I would like to do is: > a) encrypt some data, by means of one of my private keys on my smartcard > someone else should be able to decrypt it with the public key on my > certificate. > > b) let someone else encrypt some data, by means of my public key on my > certificate. > I should be able to decrypt it with one of my private keys on my smartcard. > > I speak in plural about keys/certificates, cause we have different pairs for > authentication/non-repodiation/etc > > So first I load the engine: > OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre > ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre > MODULE_PATH:/usr/lib/libaetpkss.so.3.0 > (dynamic) Dynamic engine loading support > [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so > [Success]: ID:pkcs11 > [Success]: LIST_ADD:1 > [Success]: LOAD > [Success]: MODULE_PATH:/usr/lib/libaetpkss.so.3.0 > Loaded: (pkcs11) pkcs11 engine > OpenSSL> > > And next I try to encrypt something: > OpenSSL> > OpenSSL> enc -base64 -in /root/data.txt -out file.txt.enc -engine pkcs11 > engine "pkcs11" set. > OpenSSL> > > OpenSSL> enc -d -aes-256-cbc -a -in file.txt.enc -engine pkcs11 > engine "pkcs11" set. > enter aes-256-cbc decryption password: > error in enc > OpenSSL> > > > I presume, I'll have to specify which private-key (and PIN), although "-k 41" > or "-k 43" does not work either, neither does "-key id_43" > Am I missing something, or is this just not possible? Yes you are missing something. Because asymmetric key encryption like RSA is slow and the amount of data that can be encrypted is limited, what is usually done is to encrypt the data in a symmetric key, like AES, then encrypt the AES key using the RSA public key. the encrypted data and the encrypted key are then sent, and the process is reversed using the RSA private key. This packaging of the message is usually done with something like smime or CMS Openssl can do both. (CMS in newer versions only) > > Hans > > > __ > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet > de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt > u verzocht dat aan de afzender te melden en het bericht te verwijderen. De > Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die > verband houdt met risico's verbonden aan het elektronisch verzenden van > berichten. > > This message may contain information that is not intended for you. If you are > not the addressee or if this message was sent to you by mistake, you are > requested to inform the sender and delete the message. The State accepts no > liability for damage of any kind resulting from the risks inherent in the > electronic transmission of messages. > ___ > 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] Minidriver assume hexstring encoding for card serial number
On 8/22/2012 5:28 AM, Andreas Schwier (ML) wrote:
> Hi everyone,
>
> we've come across an issue with the minidriver which assumes the card
> serial number to be a hex string.
>
> In our card the serial number is a string composed of ASCII characters.
> This works well with pkcs15-tool and the PKCS#11 library, however it
> fails with the current minidriver when it tries to convert the hex
> string into binary data for the cardid file.
>
> Neither in PKCS#11 spec nor in ISO 7816-15 I can find a definition for
> encoding the serial number as hex string.
The minidriver does not use the PKCS#11 standards, it is the Microsoft
definition of what it expects in the cardid file that counts.
http://www.microsoft.com/whdc/device/input/smartcard/sc-minidriver.mspx
Section 5.4.1 says:
"The logical name for this file is “CardId”. It is in the root directory."
"The file is organized as a 16-byte array. It should be treated as opaque
binary data."
"This value is assigned by Microsoft software to assure that a unique value is
generated for the card. It is unrelated to the serial number that may or may
not
be assigned to the card during manufacture."
In other places it calls it as a GUID.
This also means that when displayed, it maybe displayed as a GUID as hex digits
with "{", "}" "," and "-" added for readability, and some bytes reversed in
little
endian machines. So it may not be recognizable as your serial number.
That said, since the minidriver is emulating a card that should have a cardid
file,
the data to populate the emulated cardid file has to come from the card and be
the same
at every use, and unique across all cards not just one site or one card vendor.
The value or its derivatives are stored in the certificate store and used
to associate cards with data previously cached.
>
> I therefore propose to change the code in minidriver.c to do the following:
>
> 1. try parsing tokeninfo->serial_number as hex string
> 2. if that fails copy serial_number as is with the length being the
> length of the ASCII encoded string
It must be 16 bytes.
>
> This should not interfere with current card drivers which all use a hex
> string as serial number.
>
> Any objections ?
If you can show that your method has enough uniqueness, to not cause problems
with other cards, then no.
>
> Andreas
>
--
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
[opensc-devel] OpenSC Bugs and releases
Viktor, Thanks for going through all OpenSC bug reports the last few days. Its been a long time since that has been done. Do you have a time estimate when you will be done, and when we can have a 0.13.0 release candidate? Thanks. -- 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] [i...@mightymarvels.de: cardos driver problem: PKCS#15 binding failed: Unsupported card]
On 8/15/2012 2:24 PM, i...@mightymarvels.de wrote: > Hello developers, > > I do not want to bother you but the opensc-users list seems completely > inactive. Is there an alternative list or maybe my topic fits here as well? > See > below... > > Thanks, smartmic > > > - Forwarded message from i...@mightymarvels.de - > > Date: Wed, 15 Aug 2012 00:45:50 +0200 > From: i...@mightymarvels.de > To: opensc-u...@lists.opensc-project.org > Subject: cardos driver problem: PKCS#15 binding failed: Unsupported card > > Dear OpenSC users, > > I have a problem reading from a smart card. I have a cardos card, if I want to > run a command of the opensc-tool, it only works if I force the card drive, > e.g. > this works: > $ opensc-tool -c cardos --name > typing.. > $ opensc-tool --name > will give the error: > $ Unsupported card This probable means it in not a cardos card as you suspect. The OpenSC code look at the ATR of the card, and tries to determine the driver to use. Running opensc-tool -a should show the ATR running any of the OpenSC tools with one or more -v options will show more debugging including what driver if any got selected. Also look at the opensc.conf for the debug and debug_file options. > > Now I am interested in having the private key and certificates of the card on > my system (Mac OS X 10.6). > Running > $ pkcs15-tool --list-certificates > gives the error: > $ PKCS#15 binding failed: Unsupported card > > Seems like the same problem above, but there is no "force driver" flag for > pkcs15-tool, is it? How do I solve this? Anyone ideas? > > -smartmic > > > - End forwarded message - > ___ > 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] Some elementary questions on smart card usage
erify C. If this verification succeeds then > the owner of CAC will be allowed to establish an SSL/TLS session with S. It's > obvious that the example that I have in mind consists of establishing an > HTTPS connection from a PC to some HTTPS server S. > The real difference in these two cases is trust of the reader. Over the network only the card can be trusted. For a physical access like a door reader, the reader can also be trusted by the door. The piece you are missing in these cases is not only is the certificate verified, but an application like the TLS server as part of the TLS handshake send some nonce that is to be sent to the card to be signed by the private key on the card, thus proving that card has been unlocked by the pin, and the private key was used to to sign the nonce. In the PIV documents "Logical Access" is the term used for this over the network type of authentication. > Again, is this a correct description? > > Feedback on this will be much appreciated. Again, if this is not the right > forum for these questions, I will be most thankful if somebody could point me > to the appropriate forum(s). > ___ > 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] PIV: signature output format
On 8/13/2012 3:00 AM, Andreas Schwier wrote:
> Hi Douglas,
>
> I'm fine with that. I already changed our card driver to provide the
> r||s format anyway.
>
> After 0.13.0 we should work on the issue.
>
> Did anyone already considered implementing support for PKCS#1 PSS format ?
Not that I know of. Cards that do support padding on the card may need changes
to the card driver modules to take advantage of PSS.
For the PIV all padding is done in by the calling application
or by the OpenSC software if OpenSSL is used. The PIV card
supports only the RSA RAW operation, so it has not been an issue
so far. NIST 800-78-2 says PSS it is an acceptable padding to use.
>
> We have support for it in the SmartCard-HSM and want to add it to OpenSC.
>
> Andreas
>
> Am 13.08.2012 00:45, schrieb Douglas E. Engert:
>>
>> On 8/11/2012 1:26 PM, Andreas Schwier (ML) wrote:
>>> Hi Viktor and Douglas,
>>>
>>> I do also favour to keep the DER signature format at the interface
>>> between the card driver and the pkcs15 framework.
>>
>> OK, we could do that. I would like to wait till after 0.13.0 is released,
>> as the current code is working.
>>
>> What is your scheduling requirements?
>>
>>
>>> At the card driver level we don't know the field size, but we do at the
>>> pkcs15 framework level. And all cards I know use the DER encoded
>>> signature format anyway.
>>>
>>> Maybe we can reuse Douglas code and do a conditional conversion in
>>> sc_pkcs11_signature_final.
>>>
>>> Andreas
>>>
>>>
>>> Am 26.06.2012 08:06, schrieb Viktor Tarasov:
>>>>
>>>> On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert >>> <mailto:deeng...@anl.gov>> wrote:
>>>>
>>>> Just back from vacation...
>>>>
>>>>
>>>> On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
>>>>
>>>> Hi Douglas,
>>>>
>>>> I'm trying to get signature with the PIV card and verify it
>>>> with the 'openssl pkeyutl'.
>>>> I use EC key #04 "CARD AUTH Key".
>>>>
>>>> It fails because of the 'raw' output format of the signature
>>>> produced by OpenSC.
>>>> OpenSSL expects the signature as a ASN1 sequence of two integers.
>>>>
>>>> I've seen in card-piv.c your comments:
>>>>
>>>> https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
>>>>
>>>> /* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
>>>>* Which may have leading 00 to force positive
>>>>* TODO: -DEE should check if PKCS15 want the same
>>>>
>>>>
>>>> It seems that PKCS#15 really wants it.
>>>>
>>>>* But PKCS11 just wants 2* filed_length in bytes
>>>>
>>>> Can you explain more? Why it wants 'raw' data?
>>>>
>>>>
>>>> PKCS#11 v2.30: says:
>>>>
>>>> 6.3.1 EC Signatures
>>>> For the purposes of these mechanisms, an ECDSA signature is an
>>>> octet string of even
>>>> length which is at most two times nLen octets, where nLen is the
>>>> length in octets of the
>>>> base point order n. The signature octets correspond to the
>>>> concatenation of the ECDSA
>>>> values r and s, both represented as an octet string of equal
>>>> length of at most nLen with the
>>>> most significant byte first. If r and s have different octet
>>>> length, the shorter of both must
>>>> be padded with leading zero octets such that both have the same
>>>> octet length.
>>>>
>>>> PKCS#11 2.20 in Section 12.3.1 says the same as above.
>>>>
>>>> PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a
>>>> fixed size of nLen=20.
>>>>
>>>> So PKCS#11 is not returning ASN1 but just the concatenation of r
>>>> and s.
>>>>
>>>>
>>>> Ok, thanks.
>>>>
>>>>* So we have to strip out the integers
>>>>* if present a
Re: [opensc-devel] PIV: signature output format
On 8/11/2012 1:26 PM, Andreas Schwier (ML) wrote:
> Hi Viktor and Douglas,
>
> I do also favour to keep the DER signature format at the interface
> between the card driver and the pkcs15 framework.
OK, we could do that. I would like to wait till after 0.13.0 is released,
as the current code is working.
What is your scheduling requirements?
>
> At the card driver level we don't know the field size, but we do at the
> pkcs15 framework level. And all cards I know use the DER encoded
> signature format anyway.
>
> Maybe we can reuse Douglas code and do a conditional conversion in
> sc_pkcs11_signature_final.
>
> Andreas
>
>
> Am 26.06.2012 08:06, schrieb Viktor Tarasov:
>>
>>
>> On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert > <mailto:deeng...@anl.gov>> wrote:
>>
>> Just back from vacation...
>>
>>
>> On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
>>
>> Hi Douglas,
>>
>> I'm trying to get signature with the PIV card and verify it
>> with the 'openssl pkeyutl'.
>> I use EC key #04 "CARD AUTH Key".
>>
>> It fails because of the 'raw' output format of the signature
>> produced by OpenSC.
>> OpenSSL expects the signature as a ASN1 sequence of two integers.
>>
>> I've seen in card-piv.c your comments:
>>
>> https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
>>
>> /* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
>> * Which may have leading 00 to force positive
>> * TODO: -DEE should check if PKCS15 want the same
>>
>>
>> It seems that PKCS#15 really wants it.
>>
>> * But PKCS11 just wants 2* filed_length in bytes
>>
>> Can you explain more? Why it wants 'raw' data?
>>
>>
>> PKCS#11 v2.30: says:
>>
>>6.3.1 EC Signatures
>>For the purposes of these mechanisms, an ECDSA signature is an
>> octet string of even
>>length which is at most two times nLen octets, where nLen is the
>> length in octets of the
>>base point order n. The signature octets correspond to the
>> concatenation of the ECDSA
>>values r and s, both represented as an octet string of equal
>> length of at most nLen with the
>>most significant byte first. If r and s have different octet
>> length, the shorter of both must
>>be padded with leading zero octets such that both have the same
>> octet length.
>>
>> PKCS#11 2.20 in Section 12.3.1 says the same as above.
>>
>> PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a
>> fixed size of nLen=20.
>>
>> So PKCS#11 is not returning ASN1 but just the concatenation of r
>> and s.
>>
>>
>> Ok, thanks.
>>
>> * So we have to strip out the integers
>> * if present and pad on left if too short.
>> */
>>
>>
>>
>> I would propose to keep the ASN1 encoded data at the PKCS#15
>> level,
>> and, if needed, to convert it to the 'raw' format by dedicated
>> procedure in the pkcs15 framework of pkcs11.
>>
>>
>> Where do you see in PKCS#15 that a ECDSA signature is in ANS1?
>> If it needs to be ASN1, then yes the conversion could be done in
>> the framework.
>>
>>
>> Ok, there is no signature in ASN.1 in pkcs#15, but there some
>> practical reasons.
>>
>> The card itself (Oberthur's PIV) returns the signature encoded in ASN.1;
>> OpenSSL, for which the pkcs15-tool have to provide data in a suitable
>> format, needs also the ASN.1 encoding.
>>
>> So, my suggestion is to keep the encoding returned by the card at the
>> pkcs#15 level,
>> and change it to the 'raw' mode on the pkcs#11 side.
>>
>> Finally, I have no preference, if you prefer to keep it like it is
>> now, we'll be living with.
>>
>>
>>
>> Kind regards,
>> Viktor.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Douglas E. Engert mailto:deeng...@anl.gov>>
>> 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
>
>
--
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] Unsing engine_pks11 with openssl-fips 2.0
I don't anything in this, other then it looks like it never called
OpenSC.
OpenSC is compiled with OpenSSL, and it could be conflicts
with two different versions of OpenSSL.
ldd /usr/lib/engines/engine_pkcs11.so
would show what version it wants to use.
You may have to recompile OpenSC and use the FIPS version
of OPenSSL.
On 8/10/2012 9:32 AM, Mathias Tausig wrote:
> On 08/10/2012 03:41 PM, Douglas E. Engert wrote:
>> Not much to go on below.
>
> Sorry. I will provide more information below.
>
>> Is there a core file produced?
>
> No.
>
>> Can you get a stack trace?
>> Can the fips version be complied with debugging?
>> Can you run this under a debugger?
>
> Three times yes. Here is the stacktrace from gdb:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0001 in ?? ()
> (gdb) bt
> #0 0x0001 in ?? ()
> #1 0x0822ff8a in ASN1_item_sign_ctx (it=0x829e674, algor1=0xb03aeff8,
> algor2=0xb02fcff8,
> signature=0xb0306ff0, asn=0xb05ccfcc, ctx=0xbfffe074) at a_sign.c:257
> #2 0x081c77d9 in X509_sign_ctx (x=0xb04dbf98, ctx=0xbfffe074) at
> x_all.c:100
> #3 0x080a2caa in do_X509_sign (err=0xb7d28fc0, x=0xb04dbf98,
> pkey=0xb0cbafe0, md=0x8302840,
> sigopts=0x0) at req.c:1802
> #4 0x080ae993 in do_body (xret=0xbfffe62c, pkey=0xb0cbafe0,
> x509=0xb0b02f98, dgst=0x8302840,
> sigopts=0x0, policy=0xb27e7fec, db=0xb05f2ff8, serial=0xb0600fec,
> subj=0xb0cb "/C=AT/CN=Test", chtype=4097, multirdn=0, email_dn=1,
> startdate=0x825f5f6 "today", enddate=0x0, days=30, batch=1,
> verbose=0, req=0xb062aff0,
> ext_sect=0xb2563ff0 "usr_cert", lconf=0xb29f6ff0, certopt=0,
> nameopt=0, default_op=1,
> ext_copy=1, selfsign=0) at ca.c:2172
> #5 0x080ad712 in certify (xret=0xbfffe62c, infile=0xb04c
> "/home/ad60095910/tmp/testcsr",
> pkey=0xb0cbafe0, x509=0xb0b02f98, dgst=0x8302840, sigopts=0x0,
> policy=0xb27e7fec,
> db=0xb05f2ff8, serial=0xb0600fec, subj=0xb0cb "/C=AT/CN=Test",
> chtype=4097, multirdn=0,
> email_dn=1, startdate=0x825f5f6 "today", enddate=0x0, days=30, batch=1,
> ext_sect=0xb2563ff0 "usr_cert", lconf=0xb29f6ff0, verbose=0,
> certopt=0, nameopt=0,
> default_op=1, ext_copy=1, selfsign=0) at ca.c:1633
> #6 0x080ac2cc in ca_main (argc=0, argv=0xbfffed98) at ca.c:1233
> #7 0x0809c815 in do_cmd (prog=0xb36a9fa0, argc=20, argv=0xbfffed48) at
> openssl.c:489
> #8 0x0809c436 in main (Argc=20, Argv=0xbfffed48) at openssl.c:381
> (gdb)
>
>
>>
>> If not, can you turn on the debugging in opensc.conf
>> (Note: PINS and other sensitive data are traced)
>
> I tried that, but no debug file was produced. I set "debug=99" and
> "debug_file = /tmp/opensc-debug.log;"
>
>> Or run it with opensc pkcs11-spy to get PKCS#11 trac
>
> I don't know about pkcs11-spy, but I assume that it is a pkcs#11 tracer.
> I already did create a log with the debug facility of the eToken driver
> (reading and exporting it with Safenet's proprietary log viewer). Here
> is the final part of the log:
>
> 0xb7e276c0 16:16:59.271 C_GetAttributeValue [4] ( pTemplate={
> CKA_SENSITIVE=1 } )
> 0xb7e276c0 16:16:59.271 + C_GetAttributeValue( hSession=0x08730004
> hObject=0x08ec0008 pTemplate={ CKA_EXTRACTABLE=1 } )
> 0xb7e276c0 16:16:59.274 C_GetAttributeValue [3] ( pTemplate={
> CKA_EXTRACTABLE=0 } )
> 0xb7e276c0 16:16:59.274 + C_GetAttributeValue( hSession=0x08730004
> hObject=0x08ec0008 pTemplate={ CKA_MODULUS=524 } )
> 0xb7e276c0 16:16:59.281 C_GetAttributeValue [7] ( pTemplate={
> CKA_MODULUS=[256](9d f5 ef 5c b8 1d 15 cb 01 e7 bf ab fc 89 d0 52 cc 94
> c2 6d dc 60 d9 b5 c8 12 06 a1 eb eb 4b 0d 92 76 f0 25 a5 96 44 cf 51 92
> 28 b4 fe 81 79 b4 e9 6a cc c4 87 73 1a 5e 32 f1 5c e4 1f e8 c2 78 25 fa
> 9a 88 ab 3f dd e9 78 e8 1a f6 5a 16 fa 29 05 e5 a3 1d 13 37 86 71 09 11
> fa 5d 5c 1c b9 83 65 8c 83 5c b9 3e cc 01 4a de 8b db fb a2 ad 3c 56 0b
> d5 16 d9 ca 88 b9 7f 4c df 3b f7 9a 7a 52 b1 74 79 c0 62 14 3c 64 30 f8
> db c1 1d 33 ac 67 91 5f 63 ca 79 75 4d 48 76 b1 95 f7 7b f1 22 b3 8d f1
> ca 9b 74 43 06 a6 70 4d 2f 1c 55 26 a2 fc 29 f1 0f 7e 3b e6 c6 53 30 1c
> a4 21 10 3b dc 21 9e 1e df 78 35 d2 e4 48 e2 86 79 59 d0 85 e7 60 0e 3e
> 49 8e fc c1 9b 59 29 3d 0c ab 42 d9 a0 db ca 7b cf 26 ba 7c 63 31 42 ee
> 5a 49 28 7e f3 71 a4 e0 11 87 b5 7d 32 dd b0 bb b1 c4 63 cf d1 77) } )
> 0xb7e276c0 16:16:59.281 + C_GetAttributeValue( hSession=0x08730004
> hObject=0x08ec0008 pTemplate={ CKA_PUBLIC_EXPONENT=524 } )
> 0xb7e276c0 16:16:59.286 C_GetAttributeValue [5] ( pTemplate={
> CKA_PUBLIC_EXPONENT=[3](01 00 01) } )
> 0xb7e276c0 16:16:59.
Re: [opensc-devel] Unsing engine_pks11 with openssl-fips 2.0
Not much to go on below. Is there a core file produced? Can you get a stack trace? Can the fips version be complied with debugging? Can you run this under a debugger? If not, can you turn on the debugging in opensc.conf (Note: PINS and other sensitive data are traced) Or run it with opensc pkcs11-spy to get PKCS#11 trace? On 8/10/2012 3:33 AM, Mathias Tausig wrote: > Hello! > > Has anybody been able to use engine_pkcs11 with the recently released > FIPS approved version of openssl? I failed to do so. > > I was trying to sign a certificate with a FIPS enabled build of openssl > (1.0.1c, FIPS object module 2.0) and the PKCS#11 engine (using a Safenet > eToken). Opensc and engine_pkcs11 are the most recent versions (0.12.2 > and 0.1.8) > > I did this procedure before (with the non-fips version) using an openssl > config file: > > openssl_conf = openssl_def > [openssl_def] > engines = engine_section > [engine_section] > pkcs11 = pkcs11_section > [pkcs11_section] > engine_id = pkcs11 > dynamic_path = /usr/lib/engines/engine_pkcs11.so > MODULE_PATH = libeTPkcs11.so > PIN = topsecret > VERBOSE = EMPTY > init = 0 > [ca] > ... > > and the command > openssl ca -engine pkcs11 -in /tmp/testcsr -keyfile 2:74 -keyform > engine -out /tmp/cert -batch -config /tmp/testConf -md sha1 -subj > "/C=AT/CN=Test" -days 30 > > This worked like charm, but with the fips-build (engine_pkcs11 and the > PKCS#11 client library are the same), I get a segmentation fault: > > Using configuration from /tmp/testConf > initializing engine > engine "pkcs11" set. > Looking in slot 2 for key: 74 > Found 6 slots > [0] Cherry SmartBoard XX44 00 no tok > [1] AKS ifdh 00 00 login (eToken) > [2] AKS ifdh 01 00 login (INTERN) > [3]no tok > [4]no tok > [5]no tok > Found slot: AKS ifdh 01 00 > Found token: INTERN > Found 2 certificates: > 1INTERN (/C=AT/CN=INTERN/emailAddress=int...@test.at) > 2INTERN SUB (/C=AT/CN=INTERN SUB/emailAddress=int...@test.at) > Found 2 keys: > 1 P INTERN > 2 P INTERN SUB > Check that the request matches the signature > Signature ok > The Subject's Distinguished Name is as follows > countryName :PRINTABLE:'AT' > commonName:PRINTABLE:'Test' > Certificate is to be certified until Aug 10 10:17:22 2012 GMT (30 days) > Segmentation fault > > All this is happening with the FIPS-capable build but without actually > enabling FIPS-mode. > > I am quite lost here. Any ideas? > > cheers > Mathias > ___ > 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] new release?
I have sent a pull request to github, wich includes 3 different commits but all listed under the same pull request. (I would have suspected it let be do 3 pull requests.) https://github.com/dengert/OpenSC/commit/1542022a6aefb86de95c734bb3923f2b3b59490e Needed to get code to compile. https://github.com/dengert/OpenSC/commit/d36b8fc45e8e77cd620976cb5c21c08baecd0480 Updates some comments and removes the "PIN Always" from the PIV 9D key. https://github.com/dengert/OpenSC/commit/8052e2f940810f3010542933619d18b98488e84a Implements a solution to the problem described in my message "[opensc-devel] OpenSC, CK_ALWAYS_AUTHENTICATE and Thunderbird" from 8/6/2012 I would like to see these in 0.13.0 if possible as there are users with these problems. On 8/6/2012 9:34 AM, Douglas E. Engert wrote: > I am going to send shortly, under a different subject, a problem dealing with > user_consent, > CK_ALWAYS_AUTHENTICATE, OpenSC and Thunderbird. I would like to see it > addressed in > the next release. > > > On 8/5/2012 12:48 PM, Viktor Tarasov wrote: >> Hello, >> >> Le 22/07/2012 17:44, Viktor Tarasov a écrit : >>> I would like to start preparation of the new release based on the 'staging' >>> branch of GitHub OpenSC . >>> Your suggestions proposals are heartily welcome. >>> >>> As far as I see all 'essential' proposals, >>> that have be committed into the 'staging' branch of OpenSC git repository >>> hosted in opensc-project.org (git://www.opensc-project.org/OpenSC.git), >>> are present in github OpenSC. >>> >>> Unfortunately there is no access to the code review service (gerrit) of >>> opensc-project.org and it's not currently possible to pick-up the >>> 'interesting' requests. >>> So, if anybody interested to see these proposals in the next release, >>> please, do pull request to 'staging' branch of GitHub OpenSC >>> (git://github.com/OpenSC/OpenSC.git) . >> >> If anyone has more or less significant proposals, especially the ones that >> touch the common framework, >> please, create the pull requests for github OpenSC.git/staging until the >> next weekend . >> Don't worry if you will not arrive until this term -- I hope to make >> automatic the essential part of release process and so, >> to make releases more frequents. >> >> The next weekend I hope to start the advanced non-regression tests of the >> current 'staging' and to tag the candidate for release. >> >> Look also if something essential is missing in the current 'NEWS' of >> 'staging'. >> Sorry, 'NEWS' do not reflects in details all the contributions that have >> been made during the last year -- they are too numerous. >> >> 'Codereview' service of opensc-project.org is still not accessible and so >> there is no possibility to pick-up >> the 'useful' proposals that have been made there. >> >> Kind regards, >> Viktor. >> ___ >> 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-java problem
On 8/6/2012 9:39 AM, Vlad Dimitriu wrote: > hello, > I try to use opensc java package, trouble is that I can list all the > information from the token (eToken Aladin PRO 72K -eTPKCS11.dll) but I > cannot login , I get C_Login for PKCS11 slot 0 failed CKR_PIN_INCORRECT. > Of course the pin is correct, I can login to token from the SafeNet > application. Any clue on this kind of issues ? Global PIN vs Application PIN? You can use pcscd -a -d -f to see the APUDs, and look if the command sent when using SafeNet is the same as when using OpenSC. > > > Vlad > ___ > 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
[opensc-devel] OpenSC, CK_ALWAYS_AUTHENTICATE and Thunderbird
This past week, a situation has arising where the combination of OpenSC, Thunderbird and some newer cards have combined to make a signature operation fail. SITUATION: (1) Card enforces pin verify to be the last command to card before a crypto command to do signature for some keys on the card. (NIST-800-73-3 part 1 Section 3.2.3 "PIN Always") (2) OpenSC card driver sets user_consent bit for these keys. (3) OpenSC supports CK_ALWAYS_AUTHENTICATE attribute on private key objects to tell caller PIN is required before a crypto operation. (3) OpenSC sc_pkcs15_pincache* routines will not cache a PIN that is used for any object that has user_consent. (4) On some systems if the user does not have privileges or the rlimit_memlock is to small, PIN caching will not be done. Solaris: requires PRIV_PROC_LOCK_MEMORY privilege, normal users don't have it. Ubuntu: CAP_IPC_LOCK privilege or rlimit_memlock is large enough. 64k default? (5) Productions versions of Thunderbird with NSS do not implement CK_ALWAYS_AUTHENTICATE and don't ask for the attribute. https://bugzilla.mozilla.org/show_bug.cgi?id=357025 is scheduled for NSS 3.14. (6) Thunderbird may send request to card between PIN and crypto even with the above patch. https://bugzilla.mozilla.org/show_bug.cgi?id=613507 is scheduled for NSS 3.1.4 SOFTWARE VERSIONS OUT OF SYNC: OpenSC is running as expected supporting cards that enforce "PIN Always"/user_consent/CK_ALWAYS_AUTHENTICATE, and will not cache PINs in this case. But the PKCS#11 caller must send the PIN just before a crypto opertation The PIN could have been from the initial C_Login or from C_Login with the CKU_CONTEXT_SPECIFIC flag. If the caller does not support CK_ALWAYS_AUTHENTICATE, a signature operation might work if the initial PIN was sent and no other operations were sent to the card before the crypto operation. (It would only work once.) The PIN is not being cached so sc_pkcs15_pincache_revalidate does not work. WHAT CAN WE DO? (1) Wait till NSS 3.14 is implemented in Thunderbird, and distributed by vendors. This is a timing issue, which is out of our control. (2) Modify OpenSC to back off and allow pin caching even for user_consent pins. (But mlock might get in the way, minor problem, as admin can allow it.) (3) Modify OpenSC to add pin_cache_user_consent as a parameter that would be off by default. (4) Create a opensc-pkcs11.tb.hack.so much like the opensc-pkcs11-onepin.so (5) Modify OpenSC to recognize NSS and if it supports CK_ALWAYS_AUTHENTICATE and allow user_concert pin caching. If we do nothing that is (1) and eventually things will work as expected. I don't think (5) can be done as it is too late in the process to cache the first PIN. A signature operation will fail, but a user might be able to try it again. (Makes both TB and OpenSC look bad, and is not user friendly.) (3) would work, but is ugly. Comment? Are there cards other then the PIV that have this problem? -- 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] new release?
I am going to send shortly, under a different subject, a problem dealing with user_consent, CK_ALWAYS_AUTHENTICATE, OpenSC and Thunderbird. I would like to see it addressed in the next release. On 8/5/2012 12:48 PM, Viktor Tarasov wrote: > Hello, > > Le 22/07/2012 17:44, Viktor Tarasov a écrit : >> I would like to start preparation of the new release based on the 'staging' >> branch of GitHub OpenSC . >> Your suggestions proposals are heartily welcome. >> >> As far as I see all 'essential' proposals, >> that have be committed into the 'staging' branch of OpenSC git repository >> hosted in opensc-project.org (git://www.opensc-project.org/OpenSC.git), >> are present in github OpenSC. >> >> Unfortunately there is no access to the code review service (gerrit) of >> opensc-project.org and it's not currently possible to pick-up the >> 'interesting' requests. >> So, if anybody interested to see these proposals in the next release, >> please, do pull request to 'staging' branch of GitHub OpenSC >> (git://github.com/OpenSC/OpenSC.git) . > > If anyone has more or less significant proposals, especially the ones that > touch the common framework, > please, create the pull requests for github OpenSC.git/staging until the next > weekend . > Don't worry if you will not arrive until this term -- I hope to make > automatic the essential part of release process and so, > to make releases more frequents. > > The next weekend I hope to start the advanced non-regression tests of the > current 'staging' and to tag the candidate for release. > > Look also if something essential is missing in the current 'NEWS' of > 'staging'. > Sorry, 'NEWS' do not reflects in details all the contributions that have been > made during the last year -- they are too numerous. > > 'Codereview' service of opensc-project.org is still not accessible and so > there is no possibility to pick-up > the 'useful' proposals that have been made there. > > Kind regards, > Viktor. > ___ > 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] openssl + smartcard + extra libs
On 7/27/2012 6:08 AM, j.witvl...@mindef.nl wrote: > Hi all, > > I'm trying to make our company card a bit more useful. > > What I would like to do is generating a CSR with the help of the items stored > on the card. > So I started with: > OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre > ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre module_PATH:/usr/lib/opensc-pkcs11.so Try to capitalize MODULE_PATH > (dynamic) Dynamic engine loading support > [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so > [Success]: ID:pkcs11 > [Success]: LIST_ADD:1 > [Success]: LOAD > [Failure]: module_PATH:/usr/lib/opensc-pkcs11.so > 2925:error:260AC089:engine routines:INT_CTRL_HELPER:invalid cmd > name:eng_ctrl.c:134: > 2925:error:260AB089:engine routines:ENGINE_ctrl_cmd_string:invalid cmd > name:eng_ctrl.c:316: > Loaded: (pkcs11) pkcs11 engine > OpenSSL> > > Then I remembered, that we need an additional lib from safesign. > But how do I add an additional lib to the ssl command? > I tried: > OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre > ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre > module_PATH:/usr/lib/libaetpkss.so.3.0 > (dynamic) Dynamic engine loading support > [Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so > [Success]: ID:pkcs11 > [Success]: LIST_ADD:1 > [Success]: LOAD > [Failure]: module_PATH:/usr/lib/libaetpkss.so.3.0 > 2925:error:260AC089:engine routines:INT_CTRL_HELPER:invalid cmd > name:eng_ctrl.c:134: > 2925:error:260AB089:engine routines:ENGINE_ctrl_cmd_string:invalid cmd > name:eng_ctrl.c:316: > Loaded: (pkcs11) pkcs11 engine > OpenSSL> > > Obviously, I'm either doing something wrong or forgetting something. > > > Kind regards, Hans > > > > __ > Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet > de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt > u verzocht dat aan de afzender te melden en het bericht te verwijderen. De > Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die > verband houdt met risico's verbonden aan het elektronisch verzenden van > berichten. > > This message may contain information that is not intended for you. If you are > not the addressee or if this message was sent to you by mistake, you are > requested to inform the sender and delete the message. The State accepts no > liability for damage of any kind resulting from the risks inherent in the > electronic transmission of messages. > ___ > 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] Card Driver information to Support SafeNet's DK400 Smart Card
Google for SafeNet DK400
Others have asked this question before, and others have said they would contact
the vendor to get more information on how the card works, but it looks like no
one has.
But the SafeNet product Brief for the Smart Card 400 at:
http://www.safenet-inc.com/WorkArea/linkit.aspx?LinkIdentifier=id&ItemID=8589939020&libID=8589940029
Says that this is "PIV-2 compliant"
So if this is the card, and the card has been initialized, i.e. issued by some
agency
as a PIV card, with certificates, keys, etc, you could try using the PIV driver
in OpenSC.
This would allow a user to use such a card, but none of the extra features that
SafeNet may have added on top of PIV.
For as true PIV card, the default application is required to be the PIV
application. It may
be that the application is on the card, but not the default application.
Try the attached patch to the opensc.conf, and turn on debugging in the
opensc.conf:
debug = 7;
debug_file = /tmp/opensc-debug.log;
Then run pkcs15-tool -C
The driver will try and read all the possible PIV objects on the card,
If not found will say: "Data object read failed: File not found"
If it can read any it will list them in hex.
Send the debug output.
On 7/24/2012 6:04 AM, Puneet Khunteta wrote:
Hello,
I need the opensc provided card driver information to work with SafeNet's DK400
Smart card
Card Atr :
3B:FF:18:00:00:81:31:FE:4D:80:25:A0:00:00:00:56:57:44:4B:34:30:30:06:00:DD
Let me know if any furter information is require.
Please help me asap.
Thank you.
Regards,
Puneet Khunteta
___
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.conf Wed May 11 16:10:52 2011
+++ opensc.conf.dk400 Tue Jul 24 09:15:59 2012
@@ -200,10 +200,10 @@
# }
# PIV cards need an entry similar to this one:
- # card_atr 3B:7D:96:00:00:80:31:80:65:B0:83:11:00:AC:83:00:90:00 {
- # name = "PIV-II";
- # driver = "piv";
- # }
+card_atr
3B:FF:18:00:00:81:31:FE:4D:80:25:A0:00:00:00:56:57:44:4B:34:30:30:06:00:DD {
+name = "PIV-II";
+driver = "piv";
+}
# Estonian ID card and Micardo driver sometimes only play together with
T=0
# In theory only the 'cold' ATR should be specified, as T=0 will
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new release?
OK, sent pull request to fix a regression where some code in piv-tool.c was inadvertently remove in 2011. On 7/22/2012 10:44 AM, Viktor Tarasov wrote: > Hello, > > > I would like to start preparation of the new release based on the 'staging' > branch of GitHub OpenSC . > Your suggestions proposals are heartily welcome. > > As far as I see all 'essential' proposals, > that have be committed into the 'staging' branch of OpenSC git repository > hosted in opensc-project.org (git://www.opensc-project.org/OpenSC.git), > are present in github OpenSC. > > Unfortunately there is no access to the code review service (gerrit) of > opensc-project.org and it's not currently possible to pick-up the > 'interesting' requests. > So, if anybody interested to see these proposals in the next release, > please, do pull request to 'staging' branch of GitHub OpenSC > (git://github.com/OpenSC/OpenSC.git) . > > Kind regards, > Viktor. > > ___ > 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] PIV test cards available from NIST
On 7/23/2012 3:53 AM, Jean-Michel Pouré - GOOZE wrote: > Le dimanche 22 juillet 2012 à 15:12 +0200, j.witvl...@mindef.nl a > écrit : >> Seen the pricetag? $800! > > Utterly expensive, I did not buy any of them. It is a set of 16 test cards. You have to buy the set. The value of the set is not the cards themselves, but the data on the cards, including certificates, keys (RSA and ECC), photos, fingerprints, and other objects (many of them signed) that may be on a PIV card. The data on the cards is useful in testing more then the card drivers. > > > > ___ > 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
[opensc-devel] PIV test cards available from NIST
If anyone is interested, NIST now has for sale a set of 16 test PIV cards which includes both RSA and ECC keys. See: http://www.nist.gov/srd/nistsd33.cfm http://csrc.nist.gov/groups/SNS/piv/testcards.html -- 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] ECDH in 'staging' of github OpenSC/OpenSC
On 6/2/2012 12:50 PM, Viktor Tarasov wrote: > Hi Douglas, > > ECDH support, that you have tested in SM branch, > has been committed into the 'staging' branch of github OpenSC/OpenSC. > https://github.com/OpenSC/OpenSC/tree/staging I have tested today the staging build, with the changes, and the Derivation functions are working as expected. Thanks. The staging branch was built on Solaris, and using two smart cards, with ECC Key Management Keys one from NIST and one where I generated a key. The certs from the two cards were previously read and called cardA.cert.03.pem and cardB.cert.03.pem openssl x509 -noout -in cardA.cert.03.pem -pubkey | openssl ec -pubin -outform DER > cardA.pubkey.pem openssl x509 -noout -in cardB.cert.03.pem -pubkey | openssl ec -pubin -outform DER > cardB.pubkey.pem Inserting cardA: pkcs11-tool -l --derive -m ECDH1-COFACTOR-DERIVE -O -d 03 -i cardB.pubkey.pem Inserting CardB: pkcs11-tool -l --derive -m ECDH1-COFACTOR-DERIVE -O -d 03 -i cardA.pubkey.pem Will produce the same secret key output string. > > I've made only basic (list on-card objects) tests with PIV card. > More substantial tests will be performed later, > when the rest of pending proposals will find their place in 'staging'. > > If you are using Windows environment you can try one of MSIs from > https://opensc.fr/jenkins/view/OpenSC-staging/ I will try and do that next week. > > Kind regards, > Viktor. > > -- 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] PKCS#15 Emulator
On 7/12/2012 4:26 AM, Galoh Haron wrote: > I will work on it this week. > > Between, how do you test your minidriver besides the command certutil -scinfo? > Card Minidriver Certification Kit? (1) IE to a web site supporting SSL client SSL certs. The cert can be on the smartcard. (2) AD Domain login is the most complicated, and requires the PC to be a member of the domain, and have AD setup to accept smartcard login. 2003 requires the certificate to have the msUPN otherName, and the smartcard login extension. The runas command has a /smartcard option which makes testing login easier. (2a) You could also use the runas /netonly /smartcard on a PC that is not a member of the domain, and could also use a Kerberos KDC setup to use PKINIT. (We use AD as our Kerberos KDCs, so have not tried this.) (3) Outlook to sign and encrypt E-mail (although I don't use outlook.) (4) Thunderbird can be built with the nsscapi.dll that will let Thunderbird use the Microsoft certificate store, and thus the minidriver. TB has some problems with using the trusted certs in the cert store, and this is not production code. Since Windows 7 has a built in driver for the PIV card, (the only card I am interested in) I don't use the minidriver much. But since I had the above environment to test the minidriver on Vista last year, I got involved with making sure the mindriver would work with login, and thus added the CARDMOD_LOW_LEVEL_DEBUG to trace processes, threads, DLLs and OpenSC interactions, especially during login. > > Thanks Douglas. > > > > > On Wed, Jul 11, 2012 at 11:27 PM, Douglas E. Engert wrote: >> >> >> On 7/10/2012 8:19 PM, Galoh Haron wrote: >>> >>> Douglas, >>> >>> here is the changes list that i have made for the opensc-minidrver.inf >>> and .minidriver-westcos.reg >>> >>> .inf >>> >>> [Minidriver.NTamd64] >>> + %CardDeviceName%=Minidriver64_Install,SCFILTER\CID_7320006C009000 >>> - %CardDeviceName%=Minidriver64_Install,SCFILTER\CID_00640181010c829000 >>> >>> [Minidriver.NTx86] >>> + %CardDeviceName%=Minidriver32_Install,SCFILTER\CID_7320006C009000 >>> - %CardDeviceName%=Minidriver32_Install,SCFILTER\CID_00640181010c829000 >>> >>> [Minidriver.NTamd64.6.1] >>> + %CardDeviceName%=Minidriver64_61_Install,SCFILTER\CID_7320006C009000 >>> - %CardDeviceName%=Minidriver64_61_Install,SCFILTER\CID_00640181010c829000 >>> >>> [AddRegWOW64] >>> + HKLM, >>> %SmartCardNameWOW64%,"ATR",0x0001,3b,67,00,00,73,20,00,6c,00,90,00 >>> - HKLM, >>> %SmartCardNameWOW64%,"ATR",0x0001,3f,69,00,00,00,64,01,00,00,00,80,90,00 >>> - HKLM, >>> %SmartCardNameWOW64%,"ATRMask",0x0001,ff,ff,ff,ff,ff,ff,ff,00,00,00,f0,ff,ff >>> >>> [Strings] >>> +SmartCardName="SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\MyKAD" >>> - SmartCardName="SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\Cev >>> Westcos" >>> >>> +SmartCardNameWOW64="SOFTWARE\Wow6432Node\Microsoft\Cryptography\Calais\SmartCards\MyKAD" >>> - >>> SmartCardNameWOW64="SOFTWARE\Wow6432Node\Microsoft\Cryptography\Calais\SmartCards\Cev >>> Westcos" >>> >>> .reg >>> Windows Registry Editor Version 5.00 >>> >>> + >>> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\MyKAD] >>> - >>> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\CEV >>> WESTCOS] >>> + "ATR"=hex:3b,67,00,00,73,20,00,6c,00,90,00 >>> - "ATR"=hex:3f,69,00,00,00,64,01,00,00,00,80,90,00 >>> - "ATRMask"=hex:ff,ff,ff,ff,ff,ff,ff,00,00,00,f0,ff,ff >>> >>> I have attached the cardmod.log if you required it. >>> >> >> In line 85 of the trace: >> >> P:13632 T:14000 pCardData:0048E4D8 CardReadFile >> pszDirectoryName = mscp, pszFileName = cmapfile, dwFlags = 0, pcbData=0, >> *ppbData=0 >> check_reader_status >> pCardData->hSCardCtx:0xCD010002 hScard:0xEA02 >> check_reader_status r=5 flags 0x0005 >> sc_pkcs15_read_certificate return 0 >> >> There is no cmapfile returned, and shortly after, the CardDeleteContext >> is called. >> >> >> In my version that may be out of date from 5/26/2011, >> when I last looked at this code, a cmapfile is returned, >> My trace was from a smart card login, and not from certutil.exe >> >> P:816 T:820 pCardData:00F15700 CardReadFile >> >> pszDirectoryName = mscp, pszFileName = cmapfile, dwFl
Re: [opensc-devel] PKCS#15 Emulator
On 7/10/2012 8:19 PM, Galoh Haron wrote:
> Douglas,
>
> here is the changes list that i have made for the opensc-minidrver.inf
> and .minidriver-westcos.reg
>
> .inf
>
> [Minidriver.NTamd64]
> + %CardDeviceName%=Minidriver64_Install,SCFILTER\CID_7320006C009000
> - %CardDeviceName%=Minidriver64_Install,SCFILTER\CID_00640181010c829000
>
> [Minidriver.NTx86]
> + %CardDeviceName%=Minidriver32_Install,SCFILTER\CID_7320006C009000
> - %CardDeviceName%=Minidriver32_Install,SCFILTER\CID_00640181010c829000
>
> [Minidriver.NTamd64.6.1]
> + %CardDeviceName%=Minidriver64_61_Install,SCFILTER\CID_7320006C009000
> - %CardDeviceName%=Minidriver64_61_Install,SCFILTER\CID_00640181010c829000
>
> [AddRegWOW64]
> + HKLM, %SmartCardNameWOW64%,"ATR",0x0001,3b,67,00,00,73,20,00,6c,00,90,00
> - HKLM,
> %SmartCardNameWOW64%,"ATR",0x0001,3f,69,00,00,00,64,01,00,00,00,80,90,00
> - HKLM,
> %SmartCardNameWOW64%,"ATRMask",0x0001,ff,ff,ff,ff,ff,ff,ff,00,00,00,f0,ff,ff
>
> [Strings]
> +SmartCardName="SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\MyKAD"
> - SmartCardName="SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\Cev
> Westcos"
> +SmartCardNameWOW64="SOFTWARE\Wow6432Node\Microsoft\Cryptography\Calais\SmartCards\MyKAD"
> -
> SmartCardNameWOW64="SOFTWARE\Wow6432Node\Microsoft\Cryptography\Calais\SmartCards\Cev
> Westcos"
>
> .reg
> Windows Registry Editor Version 5.00
>
> + [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\MyKAD]
> - [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\CEV
> WESTCOS]
> + "ATR"=hex:3b,67,00,00,73,20,00,6c,00,90,00
> - "ATR"=hex:3f,69,00,00,00,64,01,00,00,00,80,90,00
> - "ATRMask"=hex:ff,ff,ff,ff,ff,ff,ff,00,00,00,f0,ff,ff
>
> I have attached the cardmod.log if you required it.
>
In line 85 of the trace:
P:13632 T:14000 pCardData:0048E4D8 CardReadFile
pszDirectoryName = mscp, pszFileName = cmapfile, dwFlags = 0, pcbData=0,
*ppbData=0
check_reader_status
pCardData->hSCardCtx:0xCD010002 hScard:0xEA02
check_reader_status r=5 flags 0x0005
sc_pkcs15_read_certificate return 0
There is no cmapfile returned, and shortly after, the CardDeleteContext
is called.
In my version that may be out of date from 5/26/2011,
when I last looked at this code, a cmapfile is returned,
My trace was from a smart card login, and not from certutil.exe
P:816 T:820 pCardData:00F15700 CardReadFile
pszDirectoryName = mscp, pszFileName = cmapfile, dwFlags = 0, pcbData=0,
*ppbData=0
check_reader_status
pCardData->hSCardCtx:0xCD010002 hScard:0xEA010001
check_reader_status r=5 flags 0x0005
sc_pkcs15_read_certificate return 0
Guid={31323334-3536-3738-390c-075480510916}
cmapfile entry 0 --- 00F1FB68:86
7B003300 31003300 32003300 33003300 34002D00 33003500 33003600 2D003300
0020 37003300 38002D00 33003900 30006300 2D003000 37003500 34003800 30003500
After this things progress to passing he certificate back.
So it looks like some of the minidriver is not creating the cmapfile,
maybe because it can not find something form your card.
Look at line 832 in minidriver.c (opensc-0.12.2 version)
if(pubkey->algorithm == SC_ALGORITHM_RSA)
is true.
> Thank you.
>
>
>
> On Tue, Jul 10, 2012 at 9:20 PM, Douglas E. Engert wrote:
>>
>>
>> On 7/10/2012 3:35 AM, Galoh Haron wrote:
>>> hello all,
>>>
>>> I found errors in running certutil -scinfo
>>> 1) Can't open the AT_SIGNATURE key for reader
>>> 2) Can't open the At_KEYEXCHANGE key for reader
>>> 3) Cannot open the key for reader
>>>
>>> A pops dialog show .." A smart card was detected but is not the one
>>> required for the current operation. The smart card you are using may
>>> be missing required driver software or a required certificate".
>>
>> Sounds like the MS code is having problems using the minidriver.
>> This could be because your registry is not configured correctly
>> or you code is doing something that does not work under the minidriver.
>> The minidriver may be called during login by more then one process,
>> and by more then one thread. Depending on how your code is written this may
>> cause problems. The minidriver may stay loaded by more then one process
>> for long times. During login, there is no HKLU registry as there is no
>> current user. This also implies that access to files is limited.
>>
>>>
>>> i can view the certificate in mozilla web browser.
>>>
>>> to minidrive everything
>>> 1) I configure the registry as per minidriver-westcost.reg
>>Send your changes to the list.
>
Re: [opensc-devel] PKCS#15 Emulator
ooking for 'keyUsage', tag 0x110, OPTIONAL >>> 2012-07-02 22:06:20.340decoding 'keyUsage' >>> 2012-07-02 22:06:20.340 [pkcs15-tool] asn1.c:1394:asn1_decode: >>> returning with: 0 (Success) >>> 2012-07-02 22:06:20.340 [pkcs15-tool] asn1.c:1394:asn1_decode: >>> returning with: 0 (Success) >>> 2012-07-02 22:06:20.340 [pkcs15-tool] asn1.c:1394:asn1_decode: >>> returning with: 0 (Success) >>> 2012-07-02 22:06:20.340 Looking for 'signatureAlgorithm', tag 0x110 >>> 2012-07-02 22:06:20.340 decoding 'signatureAlgorithm' >>> 2012-07-02 22:06:20.340 called, left=13, depth 1 >>> 2012-07-02 22:06:20.340 Looking for 'algorithm', tag 0x6 >>> 2012-07-02 22:06:20.340 decoding 'algorithm' >>> 2012-07-02 22:06:20.340 Looking for 'nullParam', tag 0x5, OPTIONAL >>> 2012-07-02 22:06:20.340 decoding 'nullParam' >>> 2012-07-02 22:06:20.340 [pkcs15-tool] asn1.c:1394:asn1_decode: >>> returning with: 0 (Success) >>> 2012-07-02 22:06:20.340 Looking for 'signatureValue', tag 0x3 >>> 2012-07-02 22:06:20.340 decoding 'signatureValue' >>> 2012-07-02 22:06:20.340 [pkcs15-tool] asn1.c:1394:asn1_decode: >>> returning with: 0 (Success) >>> 2012-07-02 22:06:20.340 encoding 'serialNumber' >>> 2012-07-02 22:06:20.340 type=4, tag=0x02, parm=013C0380, len=16 >>> 2012-07-02 22:06:20.340 length of encoded item=18 >>> 2012-07-02 22:06:20.340 [pkcs15-tool] card.c:330:sc_unlock: called >>> 2012-07-02 22:06:20.340 [pkcs15-tool] pkcs15.c:959:sc_pkcs15_bind: >>> returning with: 0 (Success) >>> 2012-07-02 22:06:20.340 [pkcs15-tool] >>> pkcs15-cert.c:156:sc_pkcs15_read_certificate: called >>> 2012-07-02 22:06:20.340 X.509 certificate not found >>> 2012-07-02 22:06:20.340 [pkcs15-tool] pkcs15.c:969:sc_pkcs15_unbind: >>> called >>> 2012-07-02 22:06:20.340 [pkcs15-tool] >>> pkcs15-pin.c:596:sc_pkcs15_pincache_clear: called >>> 2012-07-02 22:06:20.340 [pkcs15-tool] card.c:330:sc_unlock: called >>> 2012-07-02 22:06:20.340 [pkcs15-tool] reader-pcsc.c:548:pcsc_unlock: >>> called >>> 2012-07-02 22:06:20.340 [pkcs15-tool] card.c:242:sc_disconnect_card: >>> called >>> 2012-07-02 22:06:20.340 [pkcs15-tool] >>> reader-pcsc.c:498:pcsc_disconnect: called >>> 2012-07-02 22:06:20.542 [pkcs15-tool] card.c:258:sc_disconnect_card: >>> returning with: 0 (Success) >>> 2012-07-02 22:06:20.542 [pkcs15-tool] ctx.c:738:sc_release_context: >>> called >>> 2012-07-02 22:06:20.542 [pkcs15-tool] reader-pcsc.c:736:pcsc_finish: >>> called >>> >>> Obviously I can't used the sc_pkcs15_read_certificate. My card does >>> not support pkcs15. >>> Or did i misunderstand the whole pkcs#15 emulator concept? >>> >>> -galoh >>> >>> >>> >>> ___ >>> 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 > > -- 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] Enable debug problem
On 6/19/2012 8:30 AM, Brian Thomas wrote: > Hello Everybody, > > My company is developing a laptop running Windows XP SP3 which will be > joined to a Windows Server Enterprise 2008 RC2 domain controller in the > field. A minidriver has been implemented to provide an interface to the > Athena ASE smartcard formatted with the PKCS#15 profile. Is this the OpenSC minidriver? Is it signed? > For our laptop > recovery image, we basically take the original Windows XP CD, perform > some minor customization, then seal it using SysPrep. When the new > image is installed on the laptop, the user is presented with the Windows > XP First Run Wizard. The user can successfully join the domain at this > point using an administrator account with password authentication. The > problem occurs at first login--when the system boots, users cannot > authenticate to the system using their smart cards. The following error > is presented: "Your credentials cannot be verified". If during the > creation of the recovery image--sysprep is not used to seal the image; > the domain can be joined and smart card authentication does work. Has > anybody ever encountered any issue such as this or know what could > possibly be causing this issue? Since no one has answered your question, I will just make some comments. I have no experience with SysPprep, but use OpenSC on Windows. It sounds like sysprep is removing something, which could be the minidriver, if it is not signed. It could also be removing the registry entries used by the minidriver. Some things to try after login using a password with the user or admin Then with the card plugged in: (1) See if the "Internet Options" can read the user's certificates on the card. (2) Then in a cmd window try: runas /smartcard /user:user@domain cmd.exe or runas /smartcard /user:user@domain /netonly cmd.exe to see if smart card login works at all. If during your tests, you are testing before the image is created, with a card, then after a new image is created you are testing with the same card, it could be that the user's certificate or CA certificates have been saved in the cert store in the image. SysPrep would most likely clean these out and remove any local users when you do a seal. It could also be your minidriver is not handling login correctly, as it needs to read certificates off the card before the user logins. > > Thanks, > > Brian Thomas > ___ > 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] PIV: signature output format
Just back from vacation...
On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
> Hi Douglas,
>
> I'm trying to get signature with the PIV card and verify it with the 'openssl
> pkeyutl'.
> I use EC key #04 "CARD AUTH Key".
>
> It fails because of the 'raw' output format of the signature produced by
> OpenSC.
> OpenSSL expects the signature as a ASN1 sequence of two integers.
>
> I've seen in card-piv.c your comments:
> https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
>> /* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
>> * Which may have leading 00 to force positive
>> * TODO: -DEE should check if PKCS15 want the same
>
> It seems that PKCS#15 really wants it.
>
>> * But PKCS11 just wants 2* filed_length in bytes
> Can you explain more? Why it wants 'raw' data?
PKCS#11 v2.30: says:
6.3.1 EC Signatures
For the purposes of these mechanisms, an ECDSA signature is an octet string
of even
length which is at most two times nLen octets, where nLen is the length in
octets of the
base point order n. The signature octets correspond to the concatenation of
the ECDSA
values r and s, both represented as an octet string of equal length of at
most nLen with the
most significant byte first. If r and s have different octet length, the
shorter of both must
be padded with leading zero octets such that both have the same octet
length.
PKCS#11 2.20 in Section 12.3.1 says the same as above.
PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a fixed size of
nLen=20.
So PKCS#11 is not returning ASN1 but just the concatenation of r and s.
>
>> * So we have to strip out the integers
>> * if present and pad on left if too short.
>> */
>
>
> I would propose to keep the ASN1 encoded data at the PKCS#15 level,
> and, if needed, to convert it to the 'raw' format by dedicated procedure in
> the pkcs15 framework of pkcs11.
Where do you see in PKCS#15 that a ECDSA signature is in ANS1?
If it needs to be ASN1, then yes the conversion could be done in the framework.
>
> Kind regards,
> Viktor.
>
>
>
>
>
>
>
>
>
>
--
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] Enable debug problem
Is /etc/opensc/opensc.conf world readable? Try adding -v -v -v -v to the opensc-tool command. Debian changes the location of the opensc.conf, so if you compile, it might be in /etc/opensc.conf On 06/14/12 02:13, Alejandro Díaz wrote: > Hi all!! > > I need enable debugging on OpenSC, but I can't do it. > > I've tested with Ubuntu Oneiric package (opensc_0.12.1-1ubuntu1_amd64.deb) > > ~$ opensc-tool --info > opensc 0.12.1 [gcc 4.6.1] > Enabled features: zlib openssl pcsc(/lib/libpcsclite.so.1) > ~$ pcscd --version > pcsc-lite version 1.7.2. > Copyright (C) 1999-2002 by David Corcoran <mailto:corco...@linuxnet.com>>. > Copyright (C) 2001-2010 by Ludovic Rousseau <mailto:ludovic.rouss...@free.fr>>. > Copyright (C) 2003-2004 by Damien Sauveron <mailto:sauve...@labri.fr>>. > Report bugs to <mailto:mus...@lists.musclecard.com>>. > Enabled features: Linux x86_64-pc-linux-gnu serial usb libudev > usbdropdir=/usr/lib/pcsc/drivers ipcdir=/var/run/pcscd > configdir=/etc/reader.conf.d > > > And compiling and installing from last source on github: > > $ opensc-tool --info > opensc 0.12.3-pre1 [gcc 4.6.1] > Enabled features: zlib readline openssl pcsc(libpcsclite.so.1) > $ pcscd --version > pcsc-lite version 1.7.2. > Copyright (C) 1999-2002 by David Corcoran <mailto:corco...@linuxnet.com>>. > Copyright (C) 2001-2010 by Ludovic Rousseau <mailto:ludovic.rouss...@free.fr>>. > Copyright (C) 2003-2004 by Damien Sauveron <mailto:sauve...@labri.fr>>. > Report bugs to <mailto:mus...@lists.musclecard.com>>. > Enabled features: Linux x86_64-pc-linux-gnu serial usb libudev > usbdropdir=/usr/lib/pcsc/drivers ipcdir=/var/run/pcscd > configdir=/etc/reader.conf.d > ~$ pkcs11-tool --login --test --module /usr/lib/opensc-pkcs11.so > Using slot 1 with a present token (0x1) > Logging in to "Alejandro Díaz (User PIN)". > Please enter User PIN: > C_SeedRandom() and C_GenerateRandom(): >seeding (C_SeedRandom) not supported >seems to be OK > Digests: >all 4 digest functions seem to work >MD5: OK >SHA-1: OK >RIPEMD160: OK > Signatures (currently only RSA signatures) >testing key 0 (Private Key) >all 4 signature functions seem to work >testing signature mechanisms: > RSA-X-509: OK > RSA-PKCS: OK > SHA1-RSA-PKCS: OK > MD5-RSA-PKCS: OK > RIPEMD160-RSA-PKCS: OK >testing key 1 (2048 bits, label=Private Key) with 1 signature mechanism > MD5-RSA-PKCS: OK >testing key 2 (2048 bits, label=Private Key) with 1 signature mechanism > MD5-RSA-PKCS: OK > Verify (currently only for RSA): >testing key 0 (Private Key) > RSA-X-509: OK > RSA-PKCS: OK > SHA1-RSA-PKCS: OK > MD5-RSA-PKCS: OK > RIPEMD160-RSA-PKCS: OK >testing key 1 (Private Key) with 1 mechanism > RSA-X-509: OK >testing key 2 (Private Key) with 1 mechanism > RSA-X-509: OK > Unwrap: not implemented > Decryption (RSA) >testing key 0 (Private Key) -- can't be used to decrypt, skipping >testing key 1 (Private Key) -- can't be used to decrypt, skipping >testing key 2 (Private Key) > RSA-X-509: OK > RSA-PKCS: OK > No errors > ~$ opensc-tool -s 00:c0:00::00 > Using reader with a card: C3PO LTC31 (80060327) 00 00 > Sending: 00 C0 00 00 00 > Received (SW1=0x90, SW2=0x00): > 6F 0E 84 07 00 00 00 70 D2 50 01 A5 03 88 01 00 o..p.P.. > > > When i use pkcs11-tool test, opensc-tool or use the card from Firefox all > work fine: > > > ~$ opensc-tool -n > Using reader with a card: C3PO LTC31 (80060327) 00 00 > entersafe > > > but the debug file does not appear at /tmp dir. > > I've edited /etc/opensc/opensc.conf file as the attached files. > > Can you help me? > > Thanks! > > Alejandro Díaz Torres > Área de Proyectos > > Emergya Consultoría > Tfno:+34 954 51 75 77 > Fax:+34 954 51 64 73 > www.emergya.es <http://www.emergya.es> > > > > > ___ > 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] T-Buffer Question
On 6/7/2012 7:46 AM, Jon wrote: > The T-buffer is the Tag Buffer. I think the card conforms to Government > Smart Card Interoperability Specification. > (GSC-IS) as defined in NIST 6887. In particular the card is a military > Alt-Token. That standard predates the PIV standards, NIST 800-73-3. What is the ATR? I might be a dual PIV/CAC card. OpenSC can use PIV. (Windows 7 also has a built in driver for PIV, and if you insert your card, you can see the certificates using the Control panel-> Internet Options->Content->Certificates) > > The commands I'm sending to the card are... > > Select the object. > > 00 A4 04 00 07 a0 00 00 00 79 02 FE. This AID looks like it is a CAC card. (Appendix D1 in 6887) and I think the above should be : 00 A4 04 00 05 a0 00 00 00 79 Then select the file with the certificate container: 00 FE 00 A4 01 00 02 02 FE (Not sure if this is correct. I think you can then read the T-buffer and V-Buffers. > Next I send a read buffer... > > 80 52 00 00 02 01 d0 Retrieve the Tag Buffer. Since you did not select another file, I think you were reading the directory as a file. > > then > > 80 52 00 00 02 02 FF Retrieve FF bytes of the Value buffer. The T-Buffer would most likely fit in 256 bytes, but the certificates in the V-buffer will not. You may have to read this in chunks using the P1 P2 to give the offset of the data > > The tag buffer has the form Tag 1 (length 1 - 3 bytes) Tag 2 ( length 1- 3 > - bytes) > > The value buffer is > > Value 1, Value 2, Value 3, > > The tags in the tag buffer are what I'm trying to figure out.. > > Thanks. > > > > > ___ > 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] T-Buffer Question
On 6/6/2012 7:35 AM, Jon wrote: > I'm writing code to read the certificates on a Cyberflex Access 64K V2c that > has to be compiled with Visual Studio 6. When I get the T-Buffer the data > looks like the following (minus) the two length > bytes. > Can you be more specific? What command did you send to the card and how? What was the length returned? Are you writing the APDU commands? What is a T-Buffer? > 06 00 15 01 72 27 00 00 80 00 FE 02 06 00 15 01 69 3F 06 00 15 01 68 FF 01 01 > 06 00 15 01 67 DD 06 00 15 01 DC 0B 06 00 15 01 66 FF 45 04 00 FF 20 02 C8 25 > 00 FF 20 02 DC 05 00 00 90 00 FE 05 07 00 15 > 01 72 27 07 00 15 01 69 39 07 00 15 01 68 FF 01 01 08 00 15 01 72 27 08 00 15 > 01 69 3A 08 00 15 01 68 FF 01 01 07 00 15 01 67 ED 07 00 15 01 DC 0B 07 00 15 > 01 66 FF 60 04 08 00 15 01 67 ED 08 00 15 01 > DC 0B 08 00 15 01 66 FF A certificate would be much longer, and would most likely be in ASN1, maybe gzip-ed. The above does not look like any of these. The vendor may also have their own "profile" with lots of data elements including certificates in one big file. The above maybe just the first part of it. > > I can't find anything that helps me identify the tags. If any one can help > it would be greatly appreciated. > > Jon > > > > > > ___ > 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] Is it OK to include external library?
On 6/4/2012 10:11 PM, Nguyễn Hồng Quân wrote: > Hello all, > > I'm implementing key generation function for OpenPGP card. > The card requires to calculate the finger print for the key after > generation. I referenced the GnuPG source and saw that it use libgrypt > to do. > > Am I allow to include libgrypt to OpenSC? If yes, how should I do? Parts of OpenSC are loadable modules such as opensc-pkcs11.so, and are also built for Windows. Thus is at all possible please try to use the existing crypto libraries which includes OpenSSL. Any addition of another library will cause all sorts of problems, and add to the complexity of the build process and size of the modules. OpenSSL can generate key fingerprints, and I am not mistaken, should match the fingerprint as generated from OpenPGP. If not OpenSSL has enough crypto functions that it could do this. > > Thanks. > -- 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] ECDH in 'staging' of github OpenSC/OpenSC
On 6/2/2012 12:50 PM, Viktor Tarasov wrote: > Hi Douglas, > > ECDH support, that you have tested in SM branch, > has been committed into the 'staging' branch of github OpenSC/OpenSC. > https://github.com/OpenSC/OpenSC/tree/staging Thanks! > > I've made only basic (list on-card objects) tests with PIV card. > More substantial tests will be performed later, > when the rest of pending proposals will find their place in 'staging'. To use the ECDH one needs a PIV card that can support ECC. No priduction cards with ECC keys are being issued at the current time, but cards are available, and the NIST Demo card set that should be available soon will have ECC keys. Using ECDH with Thunderbird for excrypted e-mail also needs additional mods that have been submitted to Mozilla. These are starting to be committed. > > If you are using Windows environment you can try one of MSIs from > https://opensc.fr/jenkins/view/OpenSC-staging/ I will try and test this week. > > Kind regards, > Viktor. > > -- 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] new release?
On 5/25/2012 6:04 AM, Martin Paljak wrote: > Hello, > > On Wed, May 2, 2012 at 5:31 PM, Douglas E. Engert wrote: >> The SM branch has pulled in many other changes (including >> my C_Derive changes) that I would like to see in the next release. >> If the SM branch is not going to be the bases for the next release, >> then we need to look at what change in the SM branch can be pulled in >> to the release. >> >> Martin, I would like to hear your comments. > > Obviously Viktor and others have had way more time in their hands to > work on OpenSC than me :) > > Also obvious is that the most active branch is supposed to be merged > as the basis for next release, which was more or less the idea of Git > in the first place. > > As the recovery option, the sync problem between Gerrit and github > needs to be cleared. Too much integration is probably not a good idea, > two-way syncing between github pull request and Gerrit has brought no > obvious benefits... > > The most straightforward approach would probably be forcing the github > tree into opensc-project.org and clearing Gerrit... > > Martin Sounds reasonable, but how do we avoid these types of problems in the future? No two-way syncing, with Gerrit or GitHub as the master? > > -- 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] help Me I'm beginner
On 5/11/2012 12:45 PM, hamed izadi wrote: > > Hi > I'm new in PKCS11 and want to create an app under windows platform. the main > goal of this app is to encrypt, decrypt and wipe off files. > I'm trying to use pkcs11 for two factor authentication and use pkcs11 module > for this reason. how can I do that? is it possible with libp11.h that have > presented in site?" if yes how? Please guide me. > I know my question is unusual but I trust your kindness and wait for your > answer. > sorry I'm so poor in English. > best regards. Have you considered: http://windows.microsoft.com/en-PH/windows-vista/Use-a-smart-card-for-file-encryption Then use the OpenSC mindriver to access smart cards supported by OpenSC? http://www.opensc-project.org/opensc/wiki/MiniDriver Or: http://en.wikipedia.org/wiki/FreeOTFE Then use OpenSC's PKCS#11. > -- > Hamed Izadi. > > > ___ > 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] new release?
On 5/2/2012 8:22 AM, Jean-Michel Pouré - GOOZE wrote: > Le mardi 01 mai 2012 à 21:00 +0300, Kalev Lember a écrit : >> >> What I am looking for is an official release, something that Linux >> distributions could pick up. A snapshot of another development branch >> wouldn't really help me here, but I appreciate the suggestion. > > At some point, the SM branch will deprecate other branches: > * This is where most development is done. > * We have a complete approach of a quality circle, starting with > frequent updates and ending with package releases and automatic testing. > > OpenSC hackers are encouraged to switch to SM branch. That still does not answer the questions: What will be in the next "Official" release and when? Will SM be in it? The SM branch has pulled in many other changes (including my C_Derive changes) that I would like to see in the next release. If the SM branch is not going to be the bases for the next release, then we need to look at what change in the SM branch can be pulled in to the release. Martin, I would like to hear your comments. > > Kind regards, > > > > ___ > 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] Biometric integraiton?
On 4/25/2012 10:20 AM, Marc Boorshtein wrote: > On Wed, Apr 25, 2012 at 10:36 AM, Douglas E. Engert wrote: >> >> >> On 4/25/2012 8:10 AM, Marc Boorshtein wrote: >>> So I now I have a PIV card that I know has a certificate on it because >>> I can login to my windows terminal with it (XP). >> >> Is this the same card you were trying a few days ago? Did you get the >> certificates on it? Are you sure the XP login is using the certificate? >> >> Or is this a different card. >> > > Different card. THey don't have a single card yet for both PACS and LACS > > >>> The card is using biometrics or a passphrase to unlock. >> >> The NIST PIV specifications 800-73 call for the storing of a fingerprint >> object on the card, but does not require the card to do the matching, >> and does not define commands to supply the card with a fingerprint and >> to do the match. >> >> Some vendors may may provide vendor specific drivers for their cards. Or >> a second application on the card to do the matching. >> > > Interesting, I never put in a PIN. So does this mean they're not > using a standard PIV technology? They're using software from SafeNet > (Borderless Security I think). When I plugged it into Windows 7 it > sad it could find a driver for the card. Sounds like this: http://csrc.nist.gov/groups/SNS/piv/documents/workshop-Jun272005/SafeNet.pdf Card vendor's can add additional functionality to their cards on top of the PIV NIST standards. Or they can add additional applications to the card, that could share data with the PIV application on the card. To use these addition features, which are most likely proprietary, requires vendor drivers. Sounds like SafeNet has provided the driver to Microsoft to download.) OpenSC, and (ASFAIK the Microsoft PIV driver) only support the NIST standards and will thus work with all the standard features of any PIV complaint card. It sounds like your card has additional features, that could allow for an on card fingerprint match, which would not require the PIN. (The PIV fingerprint object as defined by NIST 800-73 requires PIN authentication to read the object off the card. But an on card match is not reading the object off the card, so I would speculate that it would be allowed.) > > >> Your reader vendor says it has a Linux driver. >> >> OpenSC can read the PIV fingerprint object so the match could be done in >> host software, if you also have some fingerprint reader with driver. >> > > I see, so it sounds like its the middleware thats doing the matching > as opposed to the pin being used to unlock the card. Is not clear. But from a security standpoint, your organization must have looked at the security risks of using these cards with their recommended readers and looked at what is going on under the covers. > >>> We're using Precise Biometrics >>> card reader. When I put the card into my OmniKey 3021 it didn't >>> recognize it at all, said it was an invalid card type (I'll send over >>> the logs). >> >> opensc-tool -a would help identify the card type then See: >> http://smartcard-atr.appspot.com/ >> >>> >>> Here's my question, does OpenSC support any of the biometric readers? >> >> Not at this time. Are there any standards for these, any open source >> available >> > > I don't think so, I can't seem to find anything anyways. > > Thanks > Marc > ___ > 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] Biometric integraiton?
On 4/25/2012 8:10 AM, Marc Boorshtein wrote: > So I now I have a PIV card that I know has a certificate on it because > I can login to my windows terminal with it (XP). Is this the same card you were trying a few days ago? Did you get the certificates on it? Are you sure the XP login is using the certificate? Or is this a different card. > The card is using biometrics or a passphrase to unlock. The NIST PIV specifications 800-73 call for the storing of a fingerprint object on the card, but does not require the card to do the matching, and does not define commands to supply the card with a fingerprint and to do the match. Some vendors may may provide vendor specific drivers for their cards. Or a second application on the card to do the matching. Your reader vendor says it has a Linux driver. OpenSC can read the PIV fingerprint object so the match could be done in host software, if you also have some fingerprint reader with driver. > We're using Precise Biometrics > card reader. When I put the card into my OmniKey 3021 it didn't > recognize it at all, said it was an invalid card type (I'll send over > the logs). opensc-tool -a would help identify the card type then See: http://smartcard-atr.appspot.com/ > > Here's my question, does OpenSC support any of the biometric readers? Not at this time. Are there any standards for these, any open source available > > Thanks > Marc > ___ > 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] PIV card not loading certificates on Fedora 15
240 bytes. See: http://fips201ep.cio.gov/apl.php I see many "File not found" errors... The PIV card does not have a directory of what is present on the card. Normally it has 4 certificates, 4 keys, and other required objects.The assumption is made that there are present on the card, and only when an attempt is made to read the object, will it not be found. This is a big performance improvement for the normal case. I am attaching a pivdump.sh script that can by used to dump objects from the card to files, that can then be processed at a later time. If you send me the CHUID, I can decode it. Thanks Marc ___ 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 #!/bin/bash # Dump the objects on a PIV card in the reader. # to the current directory. # Although pkcs15-tool -C can do this, it dumps # to the printer. # export LD_LIBRARY_PATH=/opt/smartcard/lib export PATH=/opt/smartcard/bin:$PATH export MODULE=/opt/smartcard/lib/opensc-pkcs11.so SLOT=1 P11="pkcs11-tool --slot $SLOT --module $MODULE" PDA="$P11 -r -y data --application-id" PDC="pkcs15-tool -r" echo "dumping ccc" $PDA 2.16.840.1.101.3.7.1.219.0 > ccc echo "dumping chuid" $PDA 2.16.840.1.101.3.7.2.48.0 > chuid #$PDA 2.16.840.1.101.3.7.2.48.2 > uchuid echo "dumping cert objects" # X.509 Certificate for PIV Authentication $PDA 2.16.840.1.101.3.7.2.1.1 > cert.01.object #X.509 Certificate for Digital Signature $PDA 2.16.840.1.101.3.7.2.1.0 > cert.02.object #X.509 Certificate for Key Management $PDA 2.16.840.1.101.3.7.2.1.2 > cert.03.object #X.509 Certificate for Card Authentication $PDA 2.16.840.1.101.3.7.2.5.0 > cert.04.object echo "dumping security, history, discovery" $PDA 2.16.840.1.101.3.7.2.144.0 > security.object $PDA 2.16.840.1.101.3.7.2.96.80 > discovery.object $PDA 2.16.840.1.101.3.7.2.96.96 > history.object URL=`piv-history -u < history.object` if [ "X$URL" != "X" ] ; then FN=`echo "$URL" | sed -e 's?^.*/??'` if [ -f "$FN" ] ; then echo "using existing $FN" else echo "retrieve $URL" wget $URL fi if [ -f "$FN" ] ; then # save in user's .eid.cache (OpenSC needs better way.) rm $HOME/.eid/cache/$FN ln -s `pwd`/$FN $HOME/.eid/cache/$FN fi fi # Not that we have retrieved offline certs to .eid.cache.$FN # get all the certs, including the history and offline for ID in `pkcs15-tool -c | grep "^[]ID.*:" | sed -e 's/^.*://'` ; do echo "dumping x509 cert $ID" $PDC $ID > cert.$ID.pem done # next 3 need PIN echo Will read PIN 3 times: fingerprints printedinfo and facialimage $PDA 2.16.840.1.101.3.7.2.96.16 --login -o fingerprints $PDA 2.16.840.1.101.3.7.2.48.1 --login -o printedinfo $PDA 2.16.840.1.101.3.7.2.96.48 --login -o facialimage ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC and multi-arch support
On 4/11/2012 8:16 AM, Frank Morgner wrote:
> Adjusting the loader to determine the architecture and recognizing
> architecture specific directories would be the more generic solution, I
> think. You can change LD_LIBRARY_PATH or edit /etc/ld.so.conf to do so.
> I think the OS should fix this.
This would appear to be a common problem with many other packages
using dlopen like pam.
dlopen man page says:
If filename contains a slash ("/"), then it is interpreted as a
(relative or absolute) pathname. Otherwise, the dynamic linker
searches for the library as follows (see ld.so(8) for further details):
So can the default be just "libpcsclite.so"?
>
> On Wednesday, April 11 at 01:46PM, Ludovic Rousseau wrote:
>>
>> Hello,
>>
>> pcsc-lite on Debian and Ubuntu now supports multi-arch [1]. A
>> multi-arched library is no more stored in /usr/lib/ but in
>> /usr/lib/x86_64-linux-gnu for amd64 systems and
>> /usr/lib/i386-linux-gnu for i386 systems (and the same naming applies
>> for all the other achitectures).
>>
>> The idea of multi-arch is to be able to have intel 32 and 64 bits
>> programs and libraries installed at the same time on the same system.
>>
>> Now the problem with OpenSC.
>> OpenSC is no more linked with libpcsclite but uses dlopen(3) to load
>> the library at runtime.
>> Since the library has moved the dlopen() call fails and the library
>> can't be found and loaded. See Ubuntu bug #973886 [2].
>>
>> One solution is to link OpenSC with libpcsclite at compile time. This
>> is working because the dynamic linker has been modified for multi arch
>> and knows where to find a library.
>>
>> Now that OpenCT is deprecated and PC/SC should be the only card
>> interface to be used maybe the default could be to link at build
>> time.
>>
>> Is anybody modifying the provider_library= configuration in
>> /etc/opensc.conf to something else than the default value? What is the
>> use case?
>>
>> Bye
>>
>> [1] http://wiki.debian.org/Multiarch
>> [2] https://bugs.launchpad.net/ubuntu/+source/pcsc-lite/+bug/973886
>>
>> --
>> Dr. Ludovic Rousseau
>> ___
>> 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
--
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] Ownership issue and consequences on OpenSC project
On 3/23/2012 3:29 PM, Martin Paljak wrote: On Fri, Mar 23, 2012 at 22:16, Douglas E. Engert wrote: ECDH/C_Derive - One needs a smart card that can do ECC key derivation. I have some test cards and some demo cards from NIST that can do this, The NIST people were using the mods for testing with thunderbird, so there are at least 2 of us. Working as in "working in a test" or "working with my software X in environment Z". The NIST Thunderbird tests required changes to nss to handle EC derivation correctly, and can call opensc-pkcs11.so to decrypt e-mail using a PIV card. I was able to use these nss mods as well. If interested, I can find the references next week.) For example, I have a card that can do ECC derivation, but only a test script to test it against and it is not a PIV card... Great. The card driver would also need modifications I assume. Since The PIV could only do ECDH1-COFACTOR-DERIVE with a KDF_NULL, if your card can do more, then additional code would be needed. The point being the ECDH code so far does not implement a full ECDH, but only that part that could be tested. Attached is a test script that uses the certificate from one card, and derives a key using a second card. When run the other way, both will derive the same key. What this means is that you are not going to get many votes because in some cases only the author can test the code. A +1 from the author may be the most you will get! For non-obvious things, a "did not break anything I use" is as valuable as "works for me as well". In between lies a healthy amount of "don't know what it is but it looks weird" kind of review, which can filter also many things. Martin -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 #!/bin/bash # # test OpenSC pkcs11 with ECDH to derive a key # using the pub key from the certificate # of another card. # Doing the equivement operation using # the two cards should yeild the same derived key. # # $1 is ID of the EC key on the card in the reader. #03 is the Key Managment key, but other keys #and certificates may be obtrained using the #the history object. # # $2 is the PEM encoded certificate that the othercard #will will use to do its derivation. # export LD_LIBRARY_PATH=/opt/smartcard/lib export PATH=/opt/smartcard/bin:$PATH export MODULE=/opt/smartcard/lib/opensc-pkcs11.so SLOT=1 P11="pkcs11-tool --slot $SLOT --module $MODULE" TMP=/tmp/derive.$$ OUT="" O="" while test $# -gt 0 ; do arg="$1" case $arg in -o) shift OUT="-o $1" shift ;; -O) shift O="-O" ;; -*) echo Unknow option $1 exit 1 ;; *) echo "Found $1" break ;; esac done if [ $# -ne 2 ] ; then echo " two paramerters are required" exit 2 fi if [ ! -f $2 ] ; then echo "$2 not found" exit 1 fi openssl x509 -noout -in $2 -pubkey \ | openssl ec -pubin -outform DER > $TMP.other.pubkey.der $P11 -l --derive -m ECDH1-COFACTOR-DERIVE $O \ -d $1 -i $TMP.other.pubkey.der $OUT ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Upgrading aPass2003 Firmware to PIV
On 3/23/2012 2:59 PM, Martin Paljak wrote: > Hello, > > On Tue, Feb 21, 2012 at 16:46, Douglas E. Engert wrote: >> It does not define a load key or any finalize >> commands which would be needed by a production card management system. Martin, You really are catching up on your mail! > > I don't know about PIV internals, but maybe the "finalize" step is > automatic or not needed at all (meaning that key re-generation is > allowed, assuming you want to live without certificates or something > similar) That may be true. The PIV specs leave the card initialization commands up to the vendor, and the intent of the OpenSC PIV driver was to provide user access to the card which is standardized. Thus I have not dealt with card initialization, accept to produce cards for testing. > > Martin > > -- 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] Ownership issue and consequences on OpenSC project
On 3/23/2012 11:48 AM, Martin Paljak wrote: > Hello, > > On Fri, Mar 23, 2012 at 15:17, "Magosányi, Árpád" wrote: >> And you simultaneously don't have enough time to review patches. >> Both are correct and understandable. And there is a way out of this >> situation. >> Require assurance of the stuff is working before even taking a look at >> it: unit tests and/or ack of an established developer, maybe even an end >> user report confirming the thing is working. Or formal verification with >> frama-c. Or whatever you read about in CC part 3 or the strike fighter >> air vehicle coding standards. >> But if the requirements are met, please take a quick look at it and >> commit it. And fast. Because if you raise the bar enough, you won't have >> much junk to sort out and you already have reasonable assurance. > > True. > > The trick is having a system that works and also helps to achieve the > target of having more people *actually* looking at code and some > testing (like automatic building) done before even considering ack-ing > something. But lagging on processing any flow is of course not really > acceptable. > > Given that resources are low, automation should help. Like Gerrit och Jenkins. Another issues with this project is many of the modifications can only be tested by a subset of developers (maybe only one) who have the cards that can use the modification. SM - I don't have any cards that can use this, others may. ePass2300 - GOOZE was willing to sending them out to developers, I don't know how many may have them, and if they do have they voted? It worked for me and I voted +1. (I think I voted.) ECDH/C_Derive - One needs a smart card that can do ECC key derivation. I have some test cards and some demo cards from NIST that can do this, The NIST people were using the mods for testing with thunderbird, so there are at least 2 of us. What this means is that you are not going to get many votes because in some cases only the author can test the code. A +1 from the author may be the most you will get! Many can compile and verify code does not cause other problems, but I suspect most developers will wait for the next pre release before doing and testing at all. That what has happened in the past. > > >> Maybe a daily^H^H^H^H^Hweekly scrum in >> IRC would be a good idea. > > There is #opensc on freenode, but people on opensc-devel have most of > the time to date been against such communication, either because of > timezone differences or just because it is very difficult for a > handful of otherwise busy people to find that time (I guess). > > But a bi-weekly "recap" would be good idea to have. > > > Best, > Martin > ___ > 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 and gerrit
On 3/21/2012 5:32 AM, Jean-Michel Pouré - GOOZE wrote: > Dear all, > >> OK. What do you propose? > > I propose to incorporate OpenSC as a French association under the loi > 1901 law, under a general agreement. There are millions of associations > in France and the government provides a generic paper for incorporation. > I propose to use this paper without modification. Before we incorporate, I have a few questions and comments: What other open source projects have uses this French loi law? Has this helped or hindered their project? What appears to have happened over the last few months is that Martin has started to setup a complicated code review system using Git, GitHub, Gerrit and Jenkins then has not had the time (or lost interest) to complete the process. At the same time as a number of large changes have been submitted and are now stalled. I am assuming that all these systems are running on Martin's computers somewhere in Estonia and the Web site is on the ISP: Hetzner Online AG in Germany. Martin, we have not heard from you on what is going on, and if you can continue to support the infrastructure and effort needed for this project and if not, how do we transfer the administrative burden from you to someone who can handle it. I see Ludvoic is trying to do the best he can with the access and the understanding he has of Gerrit. Peter has been of great help with Git and Gerrit. Martin, we need to hear from you... > > In short: > > * All members are equal. > * Everyone can join the association, without filter. > * The executive board and president is elected every year. > * Recognized developers have an all-time right to join the board. > * We don't need any budget or funding as this is free software. > * I can handle the accounting as this is a bureaucratic issue. > * All information is public and available for download, including > accounting. > > Very important : the executive board would agree to let OpenSC > developers organize themselves according to an organization statement. > > The organisation statement should be one page, explaining the > development processes, close to Viktor proposal with the flexibility > proposed by Alon. i.e. : > > * OpenSC has a stable GIT branch which is the release, an unstable > branch called staging. > * All patches are discussed and committed fast to staging. All > recognized developers can make commits, without any obligation to join > the association, just as in old times. > * Packages on the build farm are released daily to help detecting and > fixing bugs. The quality process comes from flexibility, the fast > release of versions and bug detection. > * We should have date releases, i.e. every two months. The dates are > known in advance, so everyone gets organized for the release. > > In short, we want to give the power back to developers and contributors. > >>> Martin and Ludovic, please confirm on the mailing list each of >> these: >>> A. OpenSC is a self driven-community with several core-developers, >> no >>> leader/owner. >>> B. Martin and Ludovic are core developers, not owners of the >> project. >>> OpenSC is owned by the community. > >> Note that I do not administer any of the OpenSC resources/servers. So >> I can't do much. > > I think there is a misunderstanding in the way OpenSC is organized. I > begin to think that Martin considers himself as an owner, not an > administrator. > > So I am asking again to you Martin and Ludovic: 1) do you agree the > community to be the owner of OpenSC and 2) do you accept to serve the > community. > > Unless you agree that by writing on the mailing list, we are going to > incorporate an association. > >> And what if core developers to not want to join your association? :-) > > As written previously, to make commit to GIT there will be no obligation > to be part of the association. Everyone is free to contribute to GIT and > submit patches and we'll commit them with great pleasure. > > Kind regards, > > > > ___ > 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] gerrit and merge process: "Submitted, Merge Pending" state
Good to see Ludovic and Peter making progress, Thanks!" Rather the stating from zero, or taking a very large branch with many little patches, would it be better to have the authors of these patches combine them into one or a hand full of larger patches? For example my ECDH was 4 separate patches, but I have combined it ito one patch. (But the ECDH is also in the SM branch so if it get in either way that is OK too.) On 3/14/2012 3:59 AM, Viktor Tarasov wrote: > > > On Tue, Mar 13, 2012 at 6:59 PM, Peter Stuge <mailto:pe...@stuge.se>> wrote: > > Peter Stuge wrote: > > I made an attempt to kick change 1 loose. > > Ok, so that worked. It would work fine to repeat this for each > change, even if it is a bit labour intensive at least now, to clear > the backlog. I've done it also for change 2 now. > > As you may recall, approving and submitting the change can be done > also via ssh: > > ssh -P 8882 www.opensc-project.org <http://www.opensc-project.org> gerrit > review $commithash \ > --code-review +2 -s > > I really like this interface to gerrit when patches need no comment > but are good to go as-is. > > The way our Gerrit has been configured it enforces linear submission > of commits to the repository, ie. everything must be submitted to the > git repo in the same order changes were pushed to gerrit by > contributors. > > This is in itself not a bad thing since it forces contributors to pay > attention to changes in the codebase and what commits goes into the > repository, but it does slightly raise the bar for less experienced > git users. It's not really difficult, but it's one more thing to keep > track of; make sure that your commit has the correct parent before > you push. > > >From practical experience with gerrit in several projects I tend to > prefer the cherry-pick strategy when submitting changes. This means > that stuff can be included into the git repository in a different > order than was pushed to gerrit. It also means that humans need to > pay more attention to not submitting changes in the wrong order when > they are interdependent. > > The current config makes it impossible to do something wrong, but can > in some cases create extra work for rebase and review. The > cherry-pick merge strategy makes it very easy to do something wrong, > but can save extra work with rebasing and reviewing+submitting of > updated patch sets. > > The current config has strong arguments, even if it brings slightly > more inconvenience. I actually favor not changing the config, even if > we will have to rebase each and every change. > > > > Commit 51630a844e8e95e7108cb1966c5f3e21b93a463b is the last common commit for > OpenSC/OpenSC.git(staging) and gerrit's repo. > (By the way, this commit where not submitted to OpenSC.git by gerrit -- there > is no Change-Id in comments) > > Two last commits merged into the gerrit's repo are not replicated into > OpenSC/OpenSC.git. > Something wrong with replication configuration? > GitHub refuses not ff merges? > Have you an access to the gerrit's logs? > > I would propose to start from zero: > - merge the OpenSC-SM branch into OpenSC-staging (or simply switch to -- > recently the OpenSC-staging was merged into OpenSC-SM). > - pick from the current gerrit's changesets the useful proposals and apply > them to this branch. > - re-install the Gerit's OpenSC project with the updated github repository. > - limit direct commits to github's OpenSC-staging (or replicate these changes > to the gerrit's repo on the regular base) > - update the list of the Jenkins admins, or install an alternative Jenkins > (like this one https://opensc.fr/jenkins/, https://opensc.fr/gerrit/ > <https://opensc.fr/jenkins/> -- still under > construction), dedicated to the OpenSC-staging and OpenSC-master. It's > needed to implement the glaring lack of an actual jenkins -- the build of > OpenSC linux packages. > > > //Peter > > > Kind wishes, > Viktor. > > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > <mailto: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 -- 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] gerrit and merge process: "Submitted, Merge Pending" state
On 3/13/2012 5:17 AM, Ludovic Rousseau wrote: > Hello Martin, or other gerrit expert, > > I don't know if gerrit is broken or if I do not know how to use it :-) > > Example with https://www.opensc-project.org/codereview/#change,6 > The status is "Submitted, Merge Pending". And has not changed since > Feb 19 (one month ago). > > What is the next step? > So I have to do something manually? > > This patch is the first one in a (long) serie. I am no Gerrit or Git expert either, but from: > http://source.android.com/source/life-of-a-patch.html Googling for: gerrit Submitted, Merge Pending shows some articles, on what this message could mean. It could be a bug: http://code.google.com/p/gerrit/issues/detail?id=600 > Thanks > -- 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-commits] [OpenSC] #429: obtain certificate or private key using slot id and an index
On 3/11/2012 8:51 PM, OpenSC wrote: > #429: obtain certificate or private key using slot id and an index > + >Reporter: BevanCollins | Owner: opensc-devel@… >Type: enhancement| Status: new >Priority: normal | Milestone: > Component: engine_pkcs11 |Version: >Severity: normal | Keywords: > Blocked By: | Blocking: > + > LOAD_CERT_CTRL supports the following formats to specify slot and > certificate: > ,:, id_, slot_-id_, label_, > slot_-label_ > where is the slot number as normal integer > and is the id number as hex string. > and is the textual key label string. > > I need to be able to obtain all certificates loaded on a token without > prior knowledge of the certificates that are stored on the token. AFAIK the OpenSSL engine code can only load one certificate (or key) at a time. It is designed to load one certificate or key and can pass in a clue to the engine, i.e. the slot_-id_ string. OPenSSL engine is not designed to load all certificates and therefore engine_pkcs11 does not have the operation you request multiple certificates. pkcs15-tool -c and pkcs11-tool -O can read or list all the objects on a card. You could use these programs in scripts, or use the code from these programs in your own programs to get the slot and id of all the certificates then use the OpenSSL engine to retrieve these one at a time. You could use a ENGINE_ctrl_cmd to a engine_pkcs11 function added to the pkcs11_cmd_defns in hw_pkcs11.c to enumerate the certificates, and return their IDs. This would only be available if you write code to make the calls, you could not just use it in scripts that call the OpenSLL provided apps. An approach that would not work would be to define a id_INDEX. that could be put into engine_pkcs11.c around line 490, that would return the th cert from the call at line 480 to PKCS11_enumerated_certs. This would return the next cert, but not its id or its label. The main problem with this is you will need to use the matching key and since the enumeration of the keys may not match the enumeration of the certs (as not every cert has to have a key and there is no requirement that the enumerations match.) You still need the id or label of the key which you program would not do not have. > -- 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] ePass2003 pull request to OpenSC
I too would request that Vicktor's Secure Messaging branch would be committed to OpenSC staging branch soon. In addition to the ePass2003 it also contains the ECDH C_Derive code that I have been requesting be added since August, more the 6 months ago. Since yesterday I have been testing the C_Derive using Viktor's repository as listed below, and the C_Derive for ECDH is working. On 3/8/2012 4:37 AM, Jean-Michel Pouré - GOOZE wrote: > Dear all, > > Per discussion with Viktor, the epass2003 was included in Viktor's > Secure Messenging branch: > > To compile the ePass2003 driver: > $ git clone git://github.com/viktorTarasov/OpenSC-SM.git > $ cd OpenSC-SM > $ git checkout --track origin/secure-messaging > $ ./bootstrap > $ ./configure --prefix=/usr --sysconfdir=/etc/opensc --enable-sm > --enable-strict > make > > We hope that Viktor's work and the ePass2003 driver can be committed to > OpenSC staging branch rapidly. Hoping this message can improve the > collaboration process. > > Kind regards, > > > > ___ > 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] Question about struct sc_pkcs15_id
Someone else needs to answer this, as I don't use pkcs15-init for the cards I am familiar with. On 3/9/2012 9:51 AM, evalues evalues wrote: > Hello, > > I try to add two certificates to the smart card with the command pkcs15-init > -T --store-certificate with the option --id, and I use the id 100 with > the first certificate and I use the id 100 > with the second certificate. When I try to add the second certificate I > obtain that there is a certificate with the same id within the smartcard. > > Thank you. > > On Wed, Mar 7, 2012 at 3:59 PM, Douglas E. Engert <mailto:deeng...@anl.gov>> wrote: > > > > On 3/7/2012 7:05 AM, evalues evalues wrote: > > Hello, you are right, I have not explained well the problem, sorry. > > I have a smartcard with three certificates and each certificate have > a different ID (first certificate have the (without dot, all ids are > numbers), second certificate have the id > 100 and > third certificate have the id 1000. I use the function > sc_pkcs15_get_objects to obtain the certificates. After that, I print the id > of each certificate and I obtain the same value 16000 > for the > ids 100 and 1000. I use %lu for print this values. > > > Will not work. the ID may be up to 255 bytes long. > You have to treat it as as an array of unsigned char. > the endian of the machine would also effect the output > if you tried to use %lu. > > > Is there a function sc_pkcs15_id_to_hex_string? > > sc_pkcs15_print_id > > Look at tools/pkcs15-tool.c in the print_cert_info routine. > > > Thank you. > > > On Wed, Mar 7, 2012 at 12:02 AM, Douglas E. Engert <mailto:deeng...@anl.gov> <mailto:deeng...@anl.gov > <mailto:deeng...@anl.gov>>> wrote: > > > > On 3/5/2012 10:45 AM, evalues evalues wrote: > > Hello, > > > > how data is stored in this structure? I have been testing with > numerical data and I think that the data are converted to hexadecimal in > pairs and from right to left. For example, if I have the > number > > 55.555.555 is converted into 85 85 85 85. It is a problem when the > number ends in zero, because, if I have the number 1.000.000 is converted > to16 0 0 0 and if I have the number 10.000.000 is > converted > > to the same value (16000). Due to this, for two objects with > identifiers 1.000.000 and 10.000.000, in opensc they are converted to the > same identifier 16 0 0 0. I don't know if I have > interpreted > > something bad or if really exist this error in opensc. > > You did not say how you were providing 55.555.555 > > It looks like the routine you are using is only looking at hex > digits and ignoring the "."s, and the fact that 1.000.000 has an > odd number of digits. > > One place where it is created is in src/tools/pkcs15-tool.c: >sc_pkcs15_hex_string_to_id(__opt_auth_id, &auth_id) > > sc_pkcs15_id has an octet string and a length. > (The octet string could be printable.) > > So depending on the tool you are trying to use, you can > pass in the hex characters, and let it convert it, > > 31:2e:30:30:30:2e:30:30:30 would be your 1.000.000 > 31:30:2e:30:30:30:2e:30:30:30 would be 10.000.000 > or if you are writing your own code, copy the > asci characters and set the length. > > > > > Thank you. > > > > > > _ > > opensc-devel mailing list > > opensc-devel@lists.opensc-__project.org > <mailto:opensc-devel@lists.opensc-project.org> > <mailto:opensc-devel@lists.__opensc-project.org > <mailto:opensc-devel@lists.opensc-project.org>> > > http://www.opensc-project.org/__mailman/listinfo/opensc-devel > <http://www.opensc-project.org/mailman/listinfo/opensc-devel> > > -- > > Douglas E. Engert mailto:deeng...@anl.gov> > <mailto:deeng...@anl.gov <mailto:deeng...@anl.gov>>> > > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > _____ > opensc-devel mailing list > opensc-devel@lists.open
Re: [opensc-devel] Question about struct sc_pkcs15_id
On 3/7/2012 7:05 AM, evalues evalues wrote: > Hello, you are right, I have not explained well the problem, sorry. > > I have a smartcard with three certificates and each certificate have a > different ID (first certificate have the (without dot, all ids are > numbers), second certificate have the id 100 and > third certificate have the id 1000. I use the function > sc_pkcs15_get_objects to obtain the certificates. After that, I print the id > of each certificate and I obtain the same value 16000 for the > ids 100 and 1000. I use %lu for print this values. Will not work. the ID may be up to 255 bytes long. You have to treat it as as an array of unsigned char. the endian of the machine would also effect the output if you tried to use %lu. Is there a function sc_pkcs15_id_to_hex_string? sc_pkcs15_print_id Look at tools/pkcs15-tool.c in the print_cert_info routine. > > Thank you. > > On Wed, Mar 7, 2012 at 12:02 AM, Douglas E. Engert <mailto:deeng...@anl.gov>> wrote: > > > > On 3/5/2012 10:45 AM, evalues evalues wrote: > > Hello, > > > > how data is stored in this structure? I have been testing with > numerical data and I think that the data are converted to hexadecimal in > pairs and from right to left. For example, if I have the > number > > 55.555.555 is converted into 85 85 85 85. It is a problem when the > number ends in zero, because, if I have the number 1.000.000 is converted > to16 0 0 0 and if I have the number 10.000.000 is > converted > > to the same value (16000). Due to this, for two objects with > identifiers 1.000.000 and 10.000.000, in opensc they are converted to the > same identifier 16 0 0 0. I don't know if I have interpreted > > something bad or if really exist this error in opensc. > > You did not say how you were providing 55.555.555 > > It looks like the routine you are using is only looking at hex > digits and ignoring the "."s, and the fact that 1.000.000 has an > odd number of digits. > > One place where it is created is in src/tools/pkcs15-tool.c: >sc_pkcs15_hex_string_to_id(opt_auth_id, &auth_id) > > sc_pkcs15_id has an octet string and a length. > (The octet string could be printable.) > > So depending on the tool you are trying to use, you can > pass in the hex characters, and let it convert it, > > 31:2e:30:30:30:2e:30:30:30 would be your 1.000.000 > 31:30:2e:30:30:30:2e:30:30:30 would be 10.000.000 > or if you are writing your own code, copy the > asci characters and set the length. > > > > > Thank you. > > > > > > _______ > > opensc-devel mailing list > > opensc-devel@lists.opensc-project.org > <mailto:opensc-devel@lists.opensc-project.org> > > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- > > Douglas E. Engert mailto:deeng...@anl.gov>> > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > ___ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > <mailto: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] Question about struct sc_pkcs15_id
On 3/5/2012 10:45 AM, evalues evalues wrote: > Hello, > > how data is stored in this structure? I have been testing with numerical data > and I think that the data are converted to hexadecimal in pairs and from > right to left. For example, if I have the number > 55.555.555 is converted into 85 85 85 85. It is a problem when the number > ends in zero, because, if I have the number 1.000.000 is converted to16 0 0 0 > and if I have the number 10.000.000 is converted > to the same value (16000). Due to this, for two objects with identifiers > 1.000.000 and 10.000.000, in opensc they are converted to the same identifier > 16 0 0 0. I don't know if I have interpreted > something bad or if really exist this error in opensc. You did not say how you were providing 55.555.555 It looks like the routine you are using is only looking at hex digits and ignoring the "."s, and the fact that 1.000.000 has an odd number of digits. One place where it is created is in src/tools/pkcs15-tool.c: sc_pkcs15_hex_string_to_id(opt_auth_id, &auth_id) sc_pkcs15_id has an octet string and a length. (The octet string could be printable.) So depending on the tool you are trying to use, you can pass in the hex characters, and let it convert it, 31:2e:30:30:30:2e:30:30:30 would be your 1.000.000 31:30:2e:30:30:30:2e:30:30:30 would be 10.000.000 or if you are writing your own code, copy the asci characters and set the length. > > Thank you. > > > ___ > 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
