yubico-piv-tool: ykcs11 performance problem
In various usage, ykcs11 seems fairly slow. For a simple openssl pkeyutl -sign
operation, ykcs11 seems to take quite a lot longer than OpenSC does…
$ time openssl pkeyutl -engine pkcs11 -keyform engine -sign -in foo -out bar \
-inkey 'pkcs11:model=YubiKey%20NEO;id=%01;pin-value=1234'
#engine "pkcs11" set.
real 0m3.771s
user 0m0.033s
sys 0m0.019s
vs. OpenSC:
$ time openssl pkeyutl -engine pkcs11 -keyform engine -sign -in foo -out bar \
-inkey 'pkcs11:manufacturer=piv_II;id=%01;pin-value=1234'
engine "pkcs11" set.
real 0m1.763s
user 0m0.024s
sys 0m0.020s
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 1
- Comments: 20 (3 by maintainers)
FYI: p11-kit-proxy.so was not being built on OS X due to a Makefile bug that has been reported at https://bugs.freedesktop.org/show_bug.cgi?id=98022 and fixed today. But you don’t really need the proxy because it’s just a symlink to
libp11-kit.dylib
(the same file is both the library and a PKCS#11 module), so you can either create the symlink yourself or use the path to the dylib directly in any configuration files.Basically generating and importing keys, while also exposing the possibility of adding vendor specific flags to enable things like touch to sign on the YubiKey. And signing data.
As I said before I think most of the suggestions make sense, being able to use ykcs11 as an OpenSSL engine is a nice addition.
All right then, I’ll try to incorporate some of your fixes and when I have more time to dedicate to this project improve it general. I just didn’t want you (or anybody) to have the impression that this is considered dead.
Perhaps it only builds if you have libffi?
Hmm… On Mac p11-kit does not seem to build
p11-kit-proxy.so
… 😦 This is what it places in the library:So in order to be able to use OpenSC and YKCS11 as you do, I have to have a working p11-kit?
libp11
is not enough?What is engine_pkcs11 using as its default provider? It should be using
p11-kit-proxy.so
, which is a shim that parses the p11-kit configuration then loads the appropriate modules indicated therein, presenting them as its own slots. If it’s built to use something else as its default, then you won’t get the expected results…No, not quite. In my system that would get
opensc-pkcs11.so
rather than YKCS11. So what needs to be configured and how, in order for YKCS11 to be picked as the PKCS#11 provider for OpenSSL, GnuTLS, and p11tool?Also, what does specifying
model=YubiKey%20NEO;
buy you, besides inability to use other tokens? Or is this the “magic incantation” to use YKCS11? Does it then find the appropriate libraries automatically? Or one still needs to point at it in some config file(s)?You may well find that OpenSC would be interested in accepting that the Yubikey is a “PIV-like” device, not actually PIV, and supporting all of those directly. Thus excusing you from reimplementing all the external support gubbins, just for a few extra features 😃
May I ask without offending, what was the “very specific problem” that YKCS11 addresses?
I’ve been using the OpenSC support for a while, and using the Yubikey as the poster child for PKCS#11 support in places such as the OpenConnect PKCS#11 documentation and the Fedora packaging guidelines which say that any package accepting keys/certs on the command line or in a config file SHOULD also accept a PKCS#11 URI such as
pkcs11:manufacturer=piv_II;id=%01
and that users should file bugs against any application which doesn’t.In that time, I haven’t had cause even to file a bug against OpenSC, let alone to want a whole new PKCS#11 provider 😃
Regarding the specific fixes… I think I only filed one patch that wasn’t an incompete proof-of-concept, to fix #91. I’m not too bothered about attribution, and it’s almost a one-liner so it’s probably as easy for you to fix that yourself, as it is for me to set about submitting it in a PR and having you merge it.
@dwmw2 thanks for all your work on this stuff! I (we) really feel that this project needs to be worked on. The PKCS#11 module has been written to address a very specific problem and many things have been left hanging. The reason why this hasn’t been done yet, boils down to lack of time/resources.
In principle I am in favor of incorporating most of the changes you have had to implement. I see some of these are self-contained small diffs. If you want to take the credit for them you are welcome to submit a bunch of pull requests and I’ll be merging them, otherwise I’ll add them myself.
For the “bigger” changes, as I said I agree with them in principle, but I think we should have a slightly different implementation. For example regarding #93 linking against zlib is fine, but I think that that part should be moved from the module into
libykpiv
. We have been discussing internally about adding a series of utility functionsykpiv_util_*
tolibykpiv
so that we could address high level operations like load a certificate, load a private key, generate a selfsigned certificate, etc. This would simplify the logic both inyubico-piv-tool
and inykcs11
. However, as you can imagine it requires some time and work. Other major fixes like the performance issue, or the support of multiple sessions (or lack thereof) are on a similar level: nice to have but no time to work on this now.So, to make a long story short, what I’m trying to say is that this suggestions are valuable and will be addressed, alas not now. If in the meanwhile you are willing to contribute some time and code to the project pull requests are always welcome 😃
@mouse07410 let’s move the p11-kit discussion to https://github.com/OpenSC/libp11/issues/117
In the meantime you can continue by using the
PKCS11_MODULE_PATH
to point engine_pkcs11 to the provider you want to use:It looks like we’re reading all the objects on the card, the moment each session is opened. Perhaps we could read them only on demand?
@martinpaljak did you ever resolve https://lists.freedesktop.org/archives/p11-glue/2014-December/000550.html
???
And back off-topic. 😃
I’ve added the appropriate (?) modules to the directories you mentioned (checked with
pkg-config
to make sure I’m not missing what p11tool` needs), but seem unable to get YKCS11 to work:I added two modules:
What seems to be wrong, in your opinion?
Getting back on-topic for this ticket, it looks like even for producing the output above, it’s iterating over all the objects in the card twice. If I enable the
log-calls
option in the module file, I get the following output…This is what ticket #92 is about — on a modern system, p11-kit covers fairly much all of this for you. You install an appropriate module file to either the directory indicated by
pkg-config --variable=p11_module_configs p11-kit-1
(which will probably be/usr/share/p11-kit/modules
), or to your personal config directory in~/.config/pkcs11/modules/
.Now your PKCS#11 provider module is visible to well-behaved applications automatically. OpenSC is correctly packaged and does that for itself, of course. Having done the same for YKCS11, I now have both OpenSC and YKCS11 available (as well as the default trust roots and GNOME keyring’s PKCS#11 module which are there by default):
So the
model=Yubikey%20NEO
part in myopenssl
command line was telling it which token to use. If I had only specifiedid=%01
and not anything about the token, it probably would have found a match in the OpenSC-provided token first. So yes, in a way that is the “inability to use other tokens”, as you called it. Deliberately so, just as theid=%01
part was for the inability to use other keys. I was specifying the object I wanted openssl to use for this command.There’s nothing new here; this ought to be exactly how you use OpenSC or any other provider, surely?
Um, as shown above? ☺
Although first I had to fix:
1234
You might not need the last two, but you probably will need the first two.
Semi-on-topic: how do you use OpenSSL with YKCS11?