How do you build against pkcs11-spy to interface to Solaris Cryptographic Framework (SCF)

[Matthew Ball]

Hi OpenSC developers,

I'm new to OpenSC, and am trying to get pkcs11-spy working as an
interface to the Solaris Cryptographic Framework (SCF), but haven't had
any luck so far.  I'd appreciate any pointers!

As background, I'm running on Solaris 10 sparc with OpenSC 0.11.11, and
am simply trying to call the C_Initialize function, which I'm hoping
will then connect to the SCF C_Initialize function and give me some
basic feedback.  Here's my program (called pktest.c):

#include <security/cryptoki.h>
int main() {
    CK_C_INITIALIZE_ARGS stInitializeArgs;
    stInitializeArgs.CreateMutex = NULL_PTR;
    stInitializeArgs.DestroyMutex = NULL_PTR;
    stInitializeArgs.LockMutex = NULL_PTR;
    stInitializeArgs.UnlockMutex = NULL_PTR;
    stInitializeArgs.pReserved = NULL_PTR;
    stInitializeArgs.flags = CKF_OS_LOCKING_OK;
    C_Initialize( &stInitializeArgs );
    return 0;
}

I attempted to link this against pkcs11-spy.so.  The first problem I ran
into was that gcc (version 3.4.5) couldn't even find the library until I
changed the name to libpkcs11-spy.so.  After that, I was able to compile
like this:

# cd [to the directory with libpkcs11-spy.so]
# cp pkcs11-spy.so libpkcs11-spy.so
# gcc -Wall pktest.c -o pktest -L. -lpkcs11-spy

That produced the executable pktest.  Here's how I ran it (with BASH):

# export PKCS11SPY="/usr/lib/libpkcs11.so"
# export LD_LIBRARY_PATH=.
# ./pktest

After running this, I got an infinite recursive loop that eventually
caused a core dump.  In looking at pkcs11-spy.c, this behavior seems
like what you'd expect:  In init_spy, you get "pkcs11_spy->C_Initialize
= C_Initialize", and in C_Initialize, you get "rv =
po->C_Initialize(pInitArgs)", which seems to just call itself again (and
is exactly what happened).

Clearly, I'm missing a very big-picture thing with pkcs11-spy, but
unfortunately I haven't been able to find any documentation to give an
example of correct usage.  Can anyone help?  How is pkcs11-spy supposed
to be included?

--
Thanks!
Matt Ball, Staff Engineer, Sun Microsystems, Inc.
500 Eldorado Blvd, Bldg 5, Broomfield, CO 80021
Office: 303-272-7580  Cell: 303-717-2717  Fax: [phone]

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

[Martin Paljak-2]

Hi Matt,

You're supposed to dlopen() the PKCS#11 library and then use the  
C_Initialize symbol, not link against the module itself. pkcs11-spy.so  
is a special module, that it passes all calls through to another  
module and logs the communication. It is not useful by itself.

Once you have built your application, you can use pkcs11-spy the way  
described here: http://www.opensc-project.org/opensc/wiki/UsingOpensc
To get some glues on how to work with PKCS#11, you can check out  
pkcs11-helper source: http://www.opensc-project.org/pkcs11-helper/

Martin

On 05.11.2009, at 19:46, Matthew Ball wrote:

> Hi OpenSC developers,
>
> I'm new to OpenSC, and am trying to get pkcs11-spy working as an
> interface to the Solaris Cryptographic Framework (SCF), but haven't  
> had
> any luck so far.  I'd appreciate any pointers!
>
> As background, I'm running on Solaris 10 sparc with OpenSC 0.11.11,  
> and
> am simply trying to call the C_Initialize function, which I'm hoping
> will then connect to the SCF C_Initialize function and give me some
> basic feedback.  Here's my program (called pktest.c):
>
> #include <security/cryptoki.h>
> int main() {
>    CK_C_INITIALIZE_ARGS stInitializeArgs;
>    stInitializeArgs.CreateMutex = NULL_PTR;
>    stInitializeArgs.DestroyMutex = NULL_PTR;
>    stInitializeArgs.LockMutex = NULL_PTR;
>    stInitializeArgs.UnlockMutex = NULL_PTR;
>    stInitializeArgs.pReserved = NULL_PTR;
>    stInitializeArgs.flags = CKF_OS_LOCKING_OK;
>    C_Initialize( &stInitializeArgs );
>    return 0;
> }
>
> I attempted to link this against pkcs11-spy.so.  The first problem I  
> ran
> into was that gcc (version 3.4.5) couldn't even find the library  
> until I
> changed the name to libpkcs11-spy.so.  After that, I was able to  
> compile
> like this:
>
> # cd [to the directory with libpkcs11-spy.so]
> # cp pkcs11-spy.so libpkcs11-spy.so
> # gcc -Wall pktest.c -o pktest -L. -lpkcs11-spy
>
> That produced the executable pktest.  Here's how I ran it (with BASH):
>
> # export PKCS11SPY="/usr/lib/libpkcs11.so"
> # export LD_LIBRARY_PATH=.
> # ./pktest
>
> After running this, I got an infinite recursive loop that eventually
> caused a core dump.  In looking at pkcs11-spy.c, this behavior seems
> like what you'd expect:  In init_spy, you get "pkcs11_spy-
> >C_Initialize
> = C_Initialize", and in C_Initialize, you get "rv =
> po->C_Initialize(pInitArgs)", which seems to just call itself again  
> (and
> is exactly what happened).
>
> Clearly, I'm missing a very big-picture thing with pkcs11-spy, but
> unfortunately I haven't been able to find any documentation to give an
> example of correct usage.  Can anyone help?  How is pkcs11-spy  
> supposed
> to be included?
>
> --
> Thanks!
> Matt Ball, Staff Engineer, Sun Microsystems, Inc.
> 500 Eldorado Blvd, Bldg 5, Broomfield, CO 80021
> Office: 303-272-7580  Cell: 303-717-2717  Fax: [phone]
>
> _______________________________________________
> opensc-devel mailing list
> opensc-devel@...
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

--
Martin Paljak
http://martin.paljak.pri.ee
+372.515.6495




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

[Douglas E. Engert]

Matthew Ball wrote:
> Hi OpenSC developers,
>
> I'm new to OpenSC, and am trying to get pkcs11-spy working as an
> interface to the Solaris Cryptographic Framework (SCF), but haven't had
> any luck so far.  I'd appreciate any pointers!
>

So are you trying run
  cryptoadm install provider=/some/path/opensc-pkcs11.so
  cryptoadm install provider=/some/path/pkcs11-spy.so

so that you can use these with unmodified Sun commands?
If so you would need have these libs elfsigned by cert/key signed
by Sun from solaris-crypto-req@...


If you are trying to run a test program to call the Sun
PKCS11, then you need to do what Martin suggested use dlopen
dlsym to get C_GetFunctionList.


I also found that on Solaris, you need to patch the libtool
after the configure is run with this:

--- ,libtool    Mon Jun  8 16:04:31 2009
+++ libtool Mon Jun  8 16:13:01 2009
@@ -314,7 +314,7 @@

  # Commands used to build a loadable module if different from building
  # a shared archive.
-module_cmds=""
+module_cmds="$archive_cmds \${wl}-B \${wl}direct \${wl}-z \${wl}defs"
  module_expsym_cmds=""

  # Whether we are building with GNU ld or not.



The above may be your problem with the loop.

> As background, I'm running on Solaris 10 sparc with OpenSC 0.11.11, and
> am simply trying to call the C_Initialize function, which I'm hoping
> will then connect to the SCF C_Initialize function and give me some
> basic feedback.  Here's my program (called pktest.c):
>
> #include <security/cryptoki.h>
> int main() {
>     CK_C_INITIALIZE_ARGS stInitializeArgs;
>     stInitializeArgs.CreateMutex = NULL_PTR;
>     stInitializeArgs.DestroyMutex = NULL_PTR;
>     stInitializeArgs.LockMutex = NULL_PTR;
>     stInitializeArgs.UnlockMutex = NULL_PTR;
>     stInitializeArgs.pReserved = NULL_PTR;
>     stInitializeArgs.flags = CKF_OS_LOCKING_OK;
>     C_Initialize( &stInitializeArgs );
>     return 0;
> }
>
> I attempted to link this against pkcs11-spy.so.  The first problem I ran
> into was that gcc (version 3.4.5) couldn't even find the library until I
> changed the name to libpkcs11-spy.so.  After that, I was able to compile
> like this:
>
> # cd [to the directory with libpkcs11-spy.so]
> # cp pkcs11-spy.so libpkcs11-spy.so
> # gcc -Wall pktest.c -o pktest -L. -lpkcs11-spy
>
> That produced the executable pktest.  Here's how I ran it (with BASH):
>
> # export PKCS11SPY="/usr/lib/libpkcs11.so"
> # export LD_LIBRARY_PATH=.
> # ./pktest
>
> After running this, I got an infinite recursive loop that eventually
> caused a core dump.  In looking at pkcs11-spy.c, this behavior seems
> like what you'd expect:  In init_spy, you get "pkcs11_spy->C_Initialize
> = C_Initialize", and in C_Initialize, you get "rv =
> po->C_Initialize(pInitArgs)", which seems to just call itself again (and
> is exactly what happened).
>
> Clearly, I'm missing a very big-picture thing with pkcs11-spy, but
> unfortunately I haven't been able to find any documentation to give an
> example of correct usage.  Can anyone help?  How is pkcs11-spy supposed
> to be included?
>

--

  Douglas E. Engert  <DEEngert@...>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  [phone]
_______________________________________________
opensc-devel mailing list
opensc-devel@...
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[Matthew Ball]

Hi Douglas,

On 11/05/09 12:50, Douglas E. Engert wrote:

>
> Matthew Ball wrote:
>> Hi OpenSC developers,
>>
>> I'm new to OpenSC, and am trying to get pkcs11-spy working as an
>> interface to the Solaris Cryptographic Framework (SCF), but haven't had
>> any luck so far.  I'd appreciate any pointers!
>>
>
> So are you trying run
>  cryptoadm install provider=/some/path/opensc-pkcs11.so
>  cryptoadm install provider=/some/path/pkcs11-spy.so
>
> so that you can use these with unmodified Sun commands?
> If so you would need have these libs elfsigned by cert/key signed
> by Sun from solaris-crypto-req@...
>

I guess that mentioning SCF was a bit of a red-herring.  My goal is to
develop a new pkcs11 provider, but to start with, I just want to point
to softtoken (something convenient that implements pretty much anything
you need).  After that works, I'm hoping to put the new PKCS#11 library
underneath, then remove pkcs11-spy after development is done.
>
> If you are trying to run a test program to call the Sun
> PKCS11, then you need to do what Martin suggested use dlopen
> dlsym to get C_GetFunctionList.
>
Yup -- this works!  I used libpkcs11.c as a guiding example, and was
able to run the simple test by dynamically linking instead of statically
linking to pkcs11-spy.so

>
> I also found that on Solaris, you need to patch the libtool
> after the configure is run with this:
>
> --- ,libtool    Mon Jun  8 16:04:31 2009
> +++ libtool Mon Jun  8 16:13:01 2009
> @@ -314,7 +314,7 @@
>
>  # Commands used to build a loadable module if different from building
>  # a shared archive.
> -module_cmds=""
> +module_cmds="$archive_cmds \${wl}-B \${wl}direct \${wl}-z \${wl}defs"
>  module_expsym_cmds=""
>
>  # Whether we are building with GNU ld or not.
>

I didn't have to do this after using dlopen/dlsym to interface to
pkcs11-spy.so, so this may be a problem for a different context.

>
>
> The above may be your problem with the loop.
>
>
>
>> As background, I'm running on Solaris 10 sparc with OpenSC 0.11.11, and
>> am simply trying to call the C_Initialize function, which I'm hoping
>> will then connect to the SCF C_Initialize function and give me some
>> basic feedback.  Here's my program (called pktest.c):
>>
>> #include <security/cryptoki.h>
>> int main() {
>>     CK_C_INITIALIZE_ARGS stInitializeArgs;
>>     stInitializeArgs.CreateMutex = NULL_PTR;
>>     stInitializeArgs.DestroyMutex = NULL_PTR;
>>     stInitializeArgs.LockMutex = NULL_PTR;
>>     stInitializeArgs.UnlockMutex = NULL_PTR;
>>     stInitializeArgs.pReserved = NULL_PTR;
>>     stInitializeArgs.flags = CKF_OS_LOCKING_OK;
>>     C_Initialize( &stInitializeArgs );
>>     return 0;
>> }
>>
>> I attempted to link this against pkcs11-spy.so.  The first problem I ran
>> into was that gcc (version 3.4.5) couldn't even find the library until I
>> changed the name to libpkcs11-spy.so.  After that, I was able to compile
>> like this:
>>
>> # cd [to the directory with libpkcs11-spy.so]
>> # cp pkcs11-spy.so libpkcs11-spy.so
>> # gcc -Wall pktest.c -o pktest -L. -lpkcs11-spy
>>
>> That produced the executable pktest.  Here's how I ran it (with BASH):
>>
>> # export PKCS11SPY="/usr/lib/libpkcs11.so"
>> # export LD_LIBRARY_PATH=.
>> # ./pktest
>>
>> After running this, I got an infinite recursive loop that eventually
>> caused a core dump.  In looking at pkcs11-spy.c, this behavior seems
>> like what you'd expect:  In init_spy, you get "pkcs11_spy->C_Initialize
>> = C_Initialize", and in C_Initialize, you get "rv =
>> po->C_Initialize(pInitArgs)", which seems to just call itself again (and
>> is exactly what happened).
>>
>> Clearly, I'm missing a very big-picture thing with pkcs11-spy, but
>> unfortunately I haven't been able to find any documentation to give an
>> example of correct usage.  Can anyone help?  How is pkcs11-spy supposed
>> to be included?
>>
>

--
Thanks!
Matt Ball, Staff Engineer, Sun Microsystems, Inc.
500 Eldorado Blvd, Bldg 5, Broomfield, CO 80021
Office: 303-272-7580  Cell: 303-717-2717  Fax: [phone]

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

[Matthew Ball]

Hi Folks,

I think I may have figured out part of the problem with using pkcs11-spy
with static linking.  It appears that when statically linking against
pkcs11-spy.so (as is described in the original message below), the ldsym
command returns a pointer to the C_GetFunctionList function within
pkcs11-spy.so itself instead of the function with the same name in the
library that pkcs11-spy is loading.  This is probably because there is a
name collision and the linker just picks the symbol that's already loaded.

I was able to work around this issue by using the dlmopen command
instead of lt_dlopen to load the library.  Here's roughly the change to
C_LoadModule (at src/pkcs11/libpkcs11.c):

line 43:  mod->handle = lt_dlopen(mspec);
change to:  mod->handle = dlmopen(LM_ID_NEWLM, mspec, RTLD_LAZY);

(and change the rest of the function to use dlsym instead of lt_dlsym, etc)

By using dlmopen with the LM_ID_NEWLM, it tells the linker to start a
new link map for the newly loaded library.  This seems to solve the problem.

Unfortunately, ldmopen is not a libtool command, so using ldmopen may
not be particularly portable.  Does anyone know of an equivalent command
or approach using libtool?

Thanks!
-Matt

On 11/05/09 11:23, Martin Paljak wrote:

> Hi Matt,
>
> You're supposed to dlopen() the PKCS#11 library and then use the
> C_Initialize symbol, not link against the module itself. pkcs11-spy.so
> is a special module, that it passes all calls through to another
> module and logs the communication. It is not useful by itself.
>
> Once you have built your application, you can use pkcs11-spy the way
> described here: http://www.opensc-project.org/opensc/wiki/UsingOpensc
> To get some glues on how to work with PKCS#11, you can check out
> pkcs11-helper source: http://www.opensc-project.org/pkcs11-helper/
>
> Martin
>
> On 05.11.2009, at 19:46, Matthew Ball wrote:
>
>> Hi OpenSC developers,
>>
>> I'm new to OpenSC, and am trying to get pkcs11-spy working as an
>> interface to the Solaris Cryptographic Framework (SCF), but haven't had
>> any luck so far.  I'd appreciate any pointers!
>>
>> As background, I'm running on Solaris 10 sparc with OpenSC 0.11.11, and
>> am simply trying to call the C_Initialize function, which I'm hoping
>> will then connect to the SCF C_Initialize function and give me some
>> basic feedback.  Here's my program (called pktest.c):
>>
>> #include <security/cryptoki.h>
>> int main() {
>>    CK_C_INITIALIZE_ARGS stInitializeArgs;
>>    stInitializeArgs.CreateMutex = NULL_PTR;
>>    stInitializeArgs.DestroyMutex = NULL_PTR;
>>    stInitializeArgs.LockMutex = NULL_PTR;
>>    stInitializeArgs.UnlockMutex = NULL_PTR;
>>    stInitializeArgs.pReserved = NULL_PTR;
>>    stInitializeArgs.flags = CKF_OS_LOCKING_OK;
>>    C_Initialize( &stInitializeArgs );
>>    return 0;
>> }
>>
>> I attempted to link this against pkcs11-spy.so.  The first problem I ran
>> into was that gcc (version 3.4.5) couldn't even find the library until I
>> changed the name to libpkcs11-spy.so.  After that, I was able to compile
>> like this:
>>
>> # cd [to the directory with libpkcs11-spy.so]
>> # cp pkcs11-spy.so libpkcs11-spy.so
>> # gcc -Wall pktest.c -o pktest -L. -lpkcs11-spy
>>
>> That produced the executable pktest.  Here's how I ran it (with BASH):
>>
>> # export PKCS11SPY="/usr/lib/libpkcs11.so"
>> # export LD_LIBRARY_PATH=.
>> # ./pktest
>>
>> After running this, I got an infinite recursive loop that eventually
>> caused a core dump.  In looking at pkcs11-spy.c, this behavior seems
>> like what you'd expect:  In init_spy, you get "pkcs11_spy->C_Initialize
>> = C_Initialize", and in C_Initialize, you get "rv =
>> po->C_Initialize(pInitArgs)", which seems to just call itself again (and
>> is exactly what happened).
>>
>> Clearly, I'm missing a very big-picture thing with pkcs11-spy, but
>> unfortunately I haven't been able to find any documentation to give an
>> example of correct usage.  Can anyone help?  How is pkcs11-spy supposed
>> to be included?
>>
>> --
>> Thanks!
>> Matt Ball, Staff Engineer, Sun Microsystems, Inc.
>> 500 Eldorado Blvd, Bldg 5, Broomfield, CO 80021
>> Office: 303-272-7580  Cell: 303-717-2717  Fax: [phone]
>>
>> _______________________________________________
>> opensc-devel mailing list
>> opensc-devel@...
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>

--
Thanks!
Matt Ball, Staff Engineer, Sun Microsystems, Inc.
500 Eldorado Blvd, Bldg 5, Broomfield, CO 80021
Office: 303-272-7580  Cell: 303-717-2717  Fax: [phone]

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