Seems to be caused by this commit, which removed the offending function without actually updating all existing users of it:
http://opencryptoki.git.sourceforge.net/git/gitweb.cgi?p=opencryptoki/opencryptoki;a=commitdiff;h=96ee90cb5662519d61beeb638965ffe2fe40bb2c

Hi David,

  The unresolved symbol is for sure a bug in openCryptoki.  I'll get you a patch for that.

  But it looks like you're trying to open an STDLL directly, as opposed to opening libopencryptoki.so, which is the PKCS#11 API .so.  libopencryptoki.so by design will then open its STDLLs such as PKCS11_TPM.so.

  If you point p11-kit at libopencryptoki.so, do you see the issue?

Thanks,
Kent

[dwmw2@i7 ~]$ p11tool -d 255 --list-tokens
Setting log level to 255
|<2>| p11: loaded provider 'gnome-keyring-module' with 5 slots
|<2>| ASSERT: pkcs11.c:271
|<2>| p11: Cannot load provider /usr/lib64/pkcs11/libopencryptoki.so
|<2>| ASSERT: pkcs11.c:516
|<2>| Cannot load provider: /usr/lib64/pkcs11/libopencryptoki.so

On f17 here:

# cat /etc/pkcs11/modules/opencryptoki 
module: /usr/lib64/opencryptoki/libopencryptoki.so
EOF

# cat /etc/pkcs11/modules/gnome-keyring-module 

# The file is installed/loaded from the default module p11-kit directory
module: gnome-keyring-pkcs11.so

# And where to store and lookup trust objects
x-trust-store: pkcs11:library-manufacturer=GNOME%20Keyring;serial=1:XDG:DEFAULT
x-trust-lookup: pkcs11:library-manufacturer=GNOME%20Keyring
EOF

# p11tool -d 255 --list-tokens
Setting log level to 255
|<2>| p11: loaded provider 'gnome-keyring-module' with 0 slots
|<2>| p11: loaded provider 'opencryptoki' with 2 slots
Token 0:
	URL: pkcs11:library-description=Meta%20PKCS11%20LIBRARY;library-manufacturer=IBM;model=TPM%20v1.1%20Token;manufacturer=IBM%20Corp.;serial=123;token=kentinit
	Label: kentinit
	Manufacturer: IBM Corp.
	Model: TPM v1.1 Token
	Serial: 123


Token 1:
	URL: pkcs11:library-description=Meta%20PKCS11%20LIBRARY;library-manufacturer=IBM;model=IBM%20SoftTok;manufacturer=IBM%20Corp.;serial=123;token=kentinit2
	Label: kentinit2
	Manufacturer: IBM Corp.
	Model: IBM SoftTok
	Serial: 123


|<2>| ASSERT: pkcs11.c:1583
|<2>| ASSERT: pkcs11.c:1629

What tokens is gnome -keyring configured for?

Kent

Hm, it's worse than non-functional. It even causes other modules to fail:

[dwmw2@shinybook modules]$ cat opencryptoki 
module: /usr/lib64/opencryptoki/libopencryptoki.so
[dwmw2@shinybook modules]$ p11tool -d 255 --list-tokens
Setting log level to 255
|<2>| ASSERT: pkcs11.c:451
|<2>| Cannot initialize registered module: Insufficient memory available
|<2>| ASSERT: pkcs11.c:1056
|<2>| ASSERT: pkcs11.c:1629
[dwmw2@shinybook modules]$ openconnect -c 'pkcs11:model=SoftHSM;manufacturer=SoftHSM;serial=1;token=My%20SoftHSM%20token;id=%db%efL%e0_%0a%7b%8c%bf%b4%f9%f3%b0%de%b2%fd%18d%af%95;object=VPN;object-type=cert' -k 'pkcs11:model=SoftHSM;manufacturer=SoftHSM;serial=1;token=My%20SoftHSM%20token;id=%ab%cd;object=VPN;object-type=private' casper:4443
Attempting to connect to [2001:770:15f::2]:4443
Error loading certificate from PKCS#11: The requested data were not available.
Loading certificate failed. Aborting.
Failed to open HTTPS connection to casper
Failed to obtain WebVPN cookie
[dwmw2@shinybook modules]$ sudo rm opencryptoki 
[dwmw2@shinybook modules]$ p11tool --list-tokens
Token 0:
	URL: pkcs11:library-description=Implementation%20of%20PKCS11;library-manufacturer=SoftHSM;model=SoftHSM;manufacturer=SoftHSM;serial=1;token=My%20SoftHSM%20token
	Label: My SoftHSM token
	Manufacturer: SoftHSM
	Model: SoftHSM
	Serial: 1


[dwmw2@shinybook modules]$ openconnect -c 'pkcs11:model=SoftHSM;manufacturer=SoftHSM;serial=1;token=My%20SoftHSM%20token;id=%db%efL%e0_%0a%7b%8c%bf%b4%f9%f3%b0%de%b2%fd%18d%af%95;object=VPN;object-type=cert' -k 'pkcs11:model=SoftHSM;manufacturer=SoftHSM;serial=1;token=My%20SoftHSM%20token;id=%ab%cd;object=VPN;object-type=private' casper:4443
Attempting to connect to [2001:770:15f::2]:4443
PIN required for My SoftHSM token
Enter PIN:
SSL negotiation with casper
Server certificate verify failed: signer not found

Certificate from VPN server "casper" failed verification.
Reason: signer not found
Enter 'yes' to accept, 'no' to abort; anything else to view: ^C

I disabled gnome-keyring, for simplicity.

Looks like its returning CKR_HOST_MEMORY, which is likely to either mean the pkcsslotd daemon isn't running, or the user you're running this as isn't a member of the pkcs11 group.

Created attachment 590967 [details]
Patch fixing unresolved symbols in the software and tpm stdlls

opencryptoki-2.4.1-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/opencryptoki-2.4.1-2.fc17

Is there any chance we can to to the point where installing the TPM PKCS#11 module makes it "just work"? If not, is there some documentation (in the package) about what one needs to do to get it running?

I do now have the openssl tpm engine working again on this machine, which is a good start. The reason I'm investigating PKCS#11 again is because I'm trying to make things work fron GnuTLS. In fact we may have a way of doing that which works directly with the TPM from GnuTLS rather than using PKCS#11¹, but still it would be nice if the PKCS#11 support was easier to use.

¹ http://www.mail-archive.com/help-gnutls@gnu.org/msg02598.html

opencryptoki-2.4-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/opencryptoki-2.4-2.fc16

Take a look here, I'm open to suggestions on a better location:

/usr/share/doc/opencryptoki-2.4.1/README

Since PKCS#11 has the USER and SO roles WRT each token there will always be some setup required before first use.

Package opencryptoki-2.4.1-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing opencryptoki-2.4.1-2.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-9319/opencryptoki-2.4.1-2.fc17
then log in and leave karma (feedback).

I didn't have opencryptoki installed, which provides that README file. I only installed opencryptoki-tpmtok, and it wasn't pulled in as a dependency.

After installing the opencryptoki package (and updating everything to 2.4.1-2.fc17) I see that the file is mostly about building and installing opencryptoki. The last section covers running it, and the commands listed there don't seem to work as given:

# pkcsconf -I
usage:	pkcsconf [-itsmMIupPh] [-c slotnumber -U userPIN -S SOPin -n newpin]

OK, so I suppose I need to specify a slot? Perhaps using the 'display slot info' or 'display token info' options will give me a clue what I'm supposed to put there...

[root@shinybook Downloads]# pkcsconf -s
Error initializing the PKCS11 library: 0x2 (CKR_HOST_MEMORY)
[root@shinybook Downloads]# pkcsconf -t
Error initializing the PKCS11 library: 0x2 (CKR_HOST_MEMORY)

So I remember that I think I've been told above that this error means that the dæmon isn't running, and evidently the broken error reporting isn't fixed in the new package, because it's still giving that useless error message.

Running 'systemctl start pkcsslotd.service' makes it happier... now 'pkcsconf -t' and '-i' and '-s' all say:
C_GetSlotList returned 0 slots. Check that your tokens are installed correctly.

'yum reinstall ./opencryptoki-tpmtok-2.4.1-2.fc17.x86_64.rpm' doesn't help.

The README does also have a URL which I figure might be more enlightening... but it's a 404.

I freely concede that I can be dim at times, but I don't think I'm *just* being dense here; this is *too* hard to set up. It shouldn't be quicker and easier for me to write native TPM support in my application than it is to use the PKCS#11 token! (Thanks for reviewing that, btw :)

David, your are not dense for sure, but a first real user of opencryptoki instead :-)

Regarding the dependencies - is there a use case when only the library (aka the -libs subpackage) can be used without the supporting daemon & co?

David: Yeah I'll admit our docs have been historically bad, I don't think this has anything to do with you. :-)  I'll get this worked on in the upstream code.

Dan: each of the opencryptoki-*tok packages will require both what you have in the opencryptoki and opencryptoki-libs package.

Apps will open libopencryptoki.so (just a thin layer with the PKCS#11 APIs in it) which then opens any of the installed libpkcs11_*.so libs, which do all the heavy lifting for a particular token.

We are making major changes for 3.0 BTW and just starting the design process so now is a good time for suggestions.

Thanks,
Kent

The opencryptoki-tpmtok package (2.4.1-2.fc17) *doesn't* have a dependency on opencryptoki; only opencryptoki-libs. Should it?

As for design suggestions: the main thing I care about is the final packaging. When I install the opencryptoki-tpmtok package it should "Just Work" as far as possible. It should install a file into /etc/pkcs11/modules which causes the module to get loaded and appear in 'p11tool --list-tokens' output, etc.
It should automatically initialise its storage as much as possible, or give clear error messages with directions to the tools that the user needs to run.

Perhaps the PKCS#11 APIs in libopencryptoki.so should be a library that is used by the actual tokens, rather than the other way round as it is at the moment.

(In reply to comment #16)
> The opencryptoki-tpmtok package (2.4.1-2.fc17) *doesn't* have a dependency
> on opencryptoki; only opencryptoki-libs. Should it?

Kent says it should and I will fix it ASAP

David, could you try opencryptoki-2.4.2-1.fc18 (http://koji.fedoraproject.org/koji/buildinfo?buildID=326717) after a rebuild for your Fedora? It should have the deps corrected.

I can certainly try. Please can you point me at a set of simple instructions which tell me how to use it on Fedora? Kent pointed out that what I was doing wasn't right anyway.

Assume that I have a TPM working, and have taken ownership and set PINs, etc., and that things like OpenConnect are working fine with direct TPM access.

All I need to do is set up opencryptoki and (presumably) something in /etc/pkcs11/modules/ to make it get *used*, which is lacking from the packages... or something like that?

Unfortunately I'm not an expert on how to use this opencryptoki/pkcs11 stuff. If I understand correctly then p11-kit is some upper layer library that can work with multiple pkcs11 providers and these are configured via files in /etc/pkcs11/modules directory. opencryptoki could provide an integration sub-package that would contain the /etc/pkcs11/modules/opencryptoki config file ...

(In reply to comment #20)
> Unfortunately I'm not an expert on how to use this opencryptoki/pkcs11
> stuff. 

That's not unfortunate. What's unfortunate is that you *need* to be an expert, in order to use it :)

> If I understand correctly then p11-kit is some upper layer library
> that can work with multiple pkcs11 providers and these are configured via
> files in /etc/pkcs11/modules directory.

Yes, something like that. And then they "just work" with tools like p11tool (and show up when you run p11tool --list-tokens, etc.). And in seahorse and you can use them with PKCS#11 URLs (which p11tool --list-all will show you) with other things like the OpenConnect VPN client.

> opencryptoki could provide an integration sub-package that would contain the
> /etc/pkcs11/modules/opencryptoki config file ...

That would be a nice improvement for the future. To start with, I'd settle just for some instructions on how to get to that point *manually*.

Kent kind of hinted in comment 6 about what might need doing — in retrospect perhaps I was just being dim; given the error message "Insufficient memory available", of *course* I should have thought of the things he mentions there... or maybe not.

FWIW I don't have TPM hardware here; I'm using the TPM emulator. It shouldn't be hard to reproduce.

First the TPM token needs to know what your SRK secret is. How to make it aware is available in doc/README.tpm_stdll, but an example of setting it to all zeros:

export OCK_SRK_SECRET="0000000000000000000000000000000000000000"
export OCK_SRK_MODE=TSS_SECRET_MODE_SHA1

and one for setting it to some plaintext password:

export OCK_SRK_SECRET="MySecret"
export OCK_SRK_MODE=TSS_SECRET_MODE_PLAIN

Then to initialize the TPM token, (assuming its in slot 0, pkcsconf -t will tell you the slot):

pkcsconf -I -c 0
pkcsconf -P -c 0
pkcsconf -u -c 0

The default SO pin is 87654321. The default USER pin is 12345678.

Note that p11-kit isn't required for any pkcs11 app to use any pkcs11 implementation.  The point of p11-kit is to make life easy for p11 apps on the system to find the p11 providers, but really the integration of p11-kit and the p11 providers and the p11 users is just a new pain point for you guys.

Personally I don't think its any more difficult for an app to be pkcs11-aware than it is to become p11-kit aware, so it seems a bit difficult to justify p11-kit's existence. Its yet another confusing layer in a stack that users already don't understand.

Kent

[root@shinybook gtls]# export OCK_SRK_MODE=TSS_SECRET_MODE_PLAIN
[root@shinybook gtls]# export OCK_SRK_SECRET="1234"
[root@shinybook gtls]# pkcsconf -I -c 0
Error initializing the PKCS11 library: 0x2 (CKR_HOST_MEMORY)
[root@shinybook gtls]# rpm -q opencryptoki opencryptoki-tpmtok
opencryptoki-2.4.1-2.fc17.x86_64
opencryptoki-tpmtok-2.4.1-2.fc17.x86_64
[root@shinybook gtls]# pkcsconf  -t
Error initializing the PKCS11 library: 0x2 (CKR_HOST_MEMORY)

The TPM is working fine though...

# ./openconnect -c ~dwmw2/.cert/certificate.pem -k tpmkeyauth.pem $VPNHOST  
Attempting to connect to $VPNHOST:443
Enter TPM SRK PIN:
Enter TPM key PIN:
Using client certificate 'Woodhouse, David'
SSL negotiation with $VPNHOST

Confused by the PIN dance. If the PKCS#11 module can ask me for a PIN for its own purposes, why can't it require that I provide the SRK PIN through that mechanism? Why would they be different?


I'm not really sure what it takes for an app to be pkcs11-aware or p11-kit-aware, so I don't really have an opinion on that.

In the OpenConnect VPN client I just pass URLs to GnuTLS of the form 'pkcs11:object=VPN%20Certificate', instead of filenames, and it all "just works".

There are GUI widgets which allow the user to *select* a PKCS#11 cert+key from all the objects in all the available tokens (i.e. the set listed by p11tool --list-all), which at some point I'll wire up in the NetworkManager configuration GUI, rather than having to provide that URL manually. And tools like seahorse will allow you to import certificates/keys into the available tokens.

service pkcsslotd start will get rid of the CKR_HOST_MEMORY errors. I agree this is a confusing error.

Since pkcsconf is just a pkcs#11 app (not doing anything specific to opencryptoki) we were left with PKCS#11 API return code values to use to indicate the error which is specific to opencryptoki, the failure to attach to shared memory when the daemon isn't running.

re the PIN dance, the PKCS#11 spec requires that you establish the SO (Security Officer) and USER (everybody else) roles to use a token. All the PCKS#11 APIs were designed with just the use of these roles in mind to do everything. The TPM's SRK is a token-specific requirement that the PKCS#11 spec knows nothing about, so we had to figure out a way make opencryptoki aware of it, given the PKCS#11 APIs don't give us a way to pass it in.

opencryptoki-2.4-2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

opencryptoki-2.4.1-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Is there a reason we can't map the owner and SRK PINs directly to the SO and USER PINs?

Now (with an appropriate file in /etc/pkcs11/modules and myself added to the pkcs11 group) the TPM token appears in 'p11tool --list-tokens'. But it doesn't seem to appear in seahorse so I can't use the GUI tools to import a certificate.

Apparently this is because it doesn't have the 'user-pin-initialized' flag set.

[dwmw2@shinybook src]$ pkcsconf -I -c 0
Enter the SO PIN: 
Enter a unique token label: TPM
[dwmw2@shinybook src]$ pkcsconf -P -c 0
Enter the SO PIN: 
Enter the new SO PIN: 
Re-enter the new SO PIN: 
[dwmw2@shinybook src]$ pkcsconf -u -c 0
Enter the SO PIN: 
Enter the new user PIN: 
Re-enter the new user PIN: 
[dwmw2@shinybook src]$ pkcsconf -t
Token #0 Info:
	Label: TPM                             
	Manufacturer: IBM Corp.                       
	Model: TPM v1.1 Token  
	Serial Number: 123             
	Flags: 0x80445 (RNG|LOGIN_REQUIRED|CLOCK_ON_TOKEN|TOKEN_INITIALIZED|USER_PIN_TO_BE_CHANGED)
	Sessions: 0/-2
	R/W Sessions: -1/-2
	PIN Length: 6-127
	Public Memory: 0xFFFFFFFF/0xFFFFFFFF
	Private Memory: 0xFFFFFFFF/0xFFFFFFFF
	Hardware Version: 1.0
	Firmware Version: 1.0
	Time: 10:30:25

Aha, if I use 'pkcsconf -p' instead of 'pkcsconf -u' to set the user PIN, *then* it sets the user-pin-initialized flag and the module appears in seahorse.

But then when I use seahorse to import a certificate which works fine elsewhere, I get a failure:

(seahorse:5107): Gck-DEBUG: perform_create_object: failed CKR_TEMPLATE_INCOMPLETE to create object: (18) [ { CKA_CLASS = CKO_PRIVATE_KEY }, { CKA_KEY_TYPE = CKK_RSA }, { CKA_PRIVATE =  (1) "\x01" }, { CKA_MODULUS =  (128) NOT-PRINTED }, { CKA_PUBLIC_EXPONENT =  (3) NOT-PRINTED }, { CKA_PRIVATE_EXPONENT =  (128) NOT-PRINTED }, { CKA_PRIME_1 =  (64) NOT-PRINTED }, { CKA_PRIME_2 =  (64) NOT-PRINTED }, { CKA_COEFFICIENT =  (64) NOT-PRINTED }, { CKA_LABEL =  (32) "Remote Access Linux for dwoodhou" }, { CKA_TOKEN =  (1) "\x01" }, { CKA_DECRYPT =  (1) "\x01" }, { CKA_SIGN =  (1) "\x01" }, { CKA_SIGN_RECOVER =  (1) "\x01" }, { CKA_UNWRAP =  (1) "\x01" }, { CKA_SENSITIVE =  (1) "\x01" }, { CKA_LABEL =  (32) "Remote Access Linux for dwoodhou" }, { CKA_ID =  (20) "\xd1nH\xb4\x1c\x86\xaa\xd5\xc1N\x0f\xc4\x07ls\xac\xd3(F\xc3" } ]

Adding Joy on cc. Joy, can you take a look at the certificate import failure David had in comment #29 while I'm out?

Thanks,
Kent