default module for pkcs11-tool

[eighthave]

There are many little technical details in the whole process of setting up and using an HSM with opensc, one seems to have a pretty simple answer: providing a default module so pkcs11-tool --list-slots does something by default. From what I read, the concern was the way it was originally implemented, it could be exploited. How about instead hardcoding a default module, i.e. /usr/lib/opensc-pkcs11.so and using that by default if it exists. Distros could then modify that path to the relevant location, i.e. /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so. I'd happily submit a patch to do this if devs here are willing to accept it.

I've been working to smooth out a lot of little details like this in the whole process, you can see the documentation of my efforts here:

• https://guardianproject.info/2014/03/28/security-in-a-thumb-drive-the-promise-and-pain-of-hardware-security-modules-take-one/
• https://dev.guardianproject.info/projects/bazaar/wiki/Improving_the_APK_Signing_Procedure

[alonbl]

There should be no default, module argument should be mandatory. But
this default goes way into the past.

[eighthave]

why should there be no default? I found no reason for that besides the security issue mentioned in the thread where the default was removed. It makes things a lot easier for people getting started when little things like this are fixed.

[alonbl]

There is no such thing as default PKCS#11 provider, the whole concept
is that user should choose.

[eighthave]

The default would be the one most commonly used. From what I've seen, opensc-pkcs11.so is far and away the most common on Debian/Ubuntu/etc. In my process of working with a few different HSMs, I only ever saw opensc-pkcs11.so as an option, I don't think I can think of a single other PKCS11 provider that I needed or even saw documented.

[alonbl]

Commonly used is subjective per user case. It has nothing to do with
distribution. A user that buys openpgp cards expect this to be the
default, another that uses aladdin expect his. Hence there is no
compile time default.

[eighthave]

Yes, its subjective, but if there is a default that matches what most people do, then most people will not have to think about this step, and waste a lot less of people's time. As long as its easy to change the default, which would be fully available using --module, then I don't see any downside. It would not change anyone's existing behavior.

[alonbl]

Once again, you are trying to enforce something that is not to be
enforced. The best solution is to drop the default. If a default is a
must have ~/.opensc-tool with some user defaults. I am not aware that
this tool is so popular that defaults and customization are so
important.

[eighthave]

Can you give concrete reasons why? I'm not interested in customization as much as making things work as easily as possible. Then perhaps opensc will become that popular.

"sensible defaults" are a cornerstone idea of making usable software. I think then my avenue will be to add a default to the Debian package. I never did anything with ~/.opensc-tool, but if there is an /etc/opensc-tool, then I can put the default there.

[alonbl]

~/.opensc-tool can be added instead of what you recommend here if
defaults are so important, please consider submitting a patch for this
instead hard coding yet another irrelevant default.

pkcs11-tool per its name is to load PKCS#11 module, and we loop...
having any default is subjective, hence no default is required.

[eighthave]

~/.opensc-tool cannot be included in a Debian package, packages cannot install into user directories, only something like /etc/opensc/opensc-tool. Does that work for you?

[eighthave]

or perhaps /etc/opensc/opensc-tool.conf makes more sense.

[alonbl]

Once again... I do not see any reason for distribution default. It is
up of user to select what provider he would like to use.

It is like you configure firefox to load specific PKCS#11 module for
all your users, which is incorrect in my opinion.

[eighthave]

If university or company sets up a shared system and they all have a standard HSM setup that they use, then the sysadmins will want to put their defaults into a global config file. Then they don't have to set up each individual user who logs in. This would also include a default module in Firefox, I see no difference.

If I want to find out which slots on my HSM exist, I use pkcs11-tool --list-slots. This is useful when configuring Java PKCS11, and probably others. This is likely the only operation that user will need to do with pkcs11-tool. Forcing all pkcs11-tool users to figure out that they need to load a module, then which module, then the path to that module means that a lot of users will waste time searching around for the answer, like I did.

[alonbl]

This university should install xxx-tool as wrapper of for
their own use and customization, installed as a separate package, for
their user to use.

[eighthave]

I'm not quite sure I understand what you mean, but if you are suggesting that people should create and install per-user versions of the opensc package, that would be an insane maintenance nightmare.

[alonbl]

We already discussed this too long... let's see what others have to say.

What I suggest is for enterprise that use a specific configuration, to
build an utility package to be distributed on all hosts/workstations
with published procedure of how to use and when to use. These
utilities can reside at /usr/bin for users to use. These utilities may
or may not use other utilities of other packages.

It is basic enterprise customization and integration, without any need
of upstream cooperation, nor enforcing one test case on people.

[dengert]

I would tend to agree with Alon. The default should not be built in.

pkcs11-tool is meant to work with any PKCS#11 implementation, not
just OpenSC.
 On 4/1/2014 2:16 PM, Hans-Christoph
  Steiner wrote:

  If university or company sets up a shared system and they all
    have a standard HSM setup that they use, then the sysadmins will
    want to put their defaults into a global config file. Then they
    don't have to set up each individual user who logs in. I would
    also include a default module in Firefox, I see no difference.


But FireFox is using NSS, that is capable of using multiple PKCS#11
modules, including the built in ones. 
You need to add the path to the PKCS#11 shared lib as a security
module. 
You will need to use the same module for pkcs11-tool. 
  If I want to find out which slots on my HSM exist, I use pkcs11-tool
      --list-slots. This is useful when configuring Java
    PKCS11, and probably others.


No, the definition of the slots is dependent on the implementation
of the PKCS#11 implementation, not on the HSM.
Even with the Java PKCS#11:https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html#Intro
you will have to specify the the path to the PKCS#11 module, or to
NSS, where you will have to specify path.
   This is likely the only operation that user will need to do
    with pkcs11-tool. Forcing all pkcs11-tool
    users to figure out that they need to load a module, then which
    module, then the path to that module means that a lot of users
    will waste time searching around for the answer, like I did.


They figure out the path with FireFox of Java anyway, and better be
using the same path if they want to use the slots correctly. 
The pkcs11-tool is designed to be a simple  low level tool, that
will work with any PKCS#11. 
  —
    Reply to this email directly or view
      it on GitHub.

-- 

Douglas E. Engert [email protected]

[martinpaljak]

Without long explanations:

• I understand your wish to make "things work out of the box". But with pkcs11-tool it eventually it boils down to "give a default path to ls" when most people anyway use a graphical file browser.
• The best would be to move pkcs11-tool (as well as pkcs11-spy?) out of OpenSC but IMHO it is way to weak to survive on its own. Maybe p11-kit would be a nice place ?
• You can alias pkcs11-tool --module /path into your shell to use a default module if you don't want to type
• All the command line utilities are utilities and while you can do some useful things with them, it is not even closely similar to the "ls" command, that actually gets used on daily basis.
• Do continue your quest on making things more usable. But I think this should be exactly like it is.

[LudovicRousseau]

Maybe a default behaviour would be to use any module present in /usr/lib/pkcs11/ directory.

Now we have multi-arch /usr/lib/pkcs11/ could contain libraries for different architectures. For example /usr/lib/pkcs11/x86_64-linux-gnu-opensc-pkcs11.so could be a symbolic link to /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so.

[alonbl]

PKCS#11 spec is explicit loading a provider, not implicit load any in directory.

[martinpaljak]

I think the best option right now would be to have OPENSC_PKCS11_TOOL_DEFAULT_MODULE environment variable. Realistically maybe just a PKCS11_MODULE would be enough. And maybe pkcs11-spy should share the name for the module to load. Whoever needs to make the utility to load something by default can set this system-wide variable for every user profile etc.

[martinpaljak]

And some distribution can set this variable by default (but this should clearly not be encouraged under usual circumstances).

In the longer term it would be good to have some meaningful test suite for PKCS#11, so that the basic "does OpenSC PKCS#11 module work for my setup" smoke-test functionality of pkcs11-tool --test could be accomplished by something more meaningful and pkcs11-tool could be a separate stand-alone package, together with pkcs11-spy. IMHO they both be more viable if bundled together with some other pkcs11 toolkit/library, like p11-kit or pkcs11-helper. The only requirement I can think of is ease of self-contained build on non-posix platforms (read: windows) and this is the only question if moving it to p11-kit (if p11-kit folks would accept it, of course) or elsewhere. @stefwalter @alonbl what would you think?

[alonbl]

I think the best option right now would be to have
OPENSC_PKCS11_TOOL_DEFAULT

If people are to be abused by the default, such as providing their PIN to
non trusted provider, then using the environment is not good.

[martinpaljak]

If you don't trust your environment, then the rest is anyway moot IMO. It makes sense to make things more convenient for a user, if it is deemed absolutely necessary by the user, thus such environment variable. If users are worried about PIN security, then anyway the only sensible solution is a dedicated pinpad device.

In fact, to me it feels that having a standard environment variable which dedicates a PKCS#11 module to load (unless a more specific command is given by the user and the application would need to load one), is as meaningful and useful as having /usr/lib/pkcs11 (not a silver bullet but useful nevertheless).

[martinpaljak]

Splitting pkcs11-tool/spy from OpenSC would make it pretty obvious for most people that there should be no "by default OpenSC module" policy in those utilities.

[alonbl]

In fact, to me it feels that having a standard environment variable which
dedicates a PKCS#11 module to load

Please keep in mind that if you are to provide standards, you should
support multiple providers within this environment and also an optional
argument for provider so that nss and similar provider may be initialized.

[martinpaljak]

Multiple providers? Why? If there is a need for multiple providers, then there is a need for a more complicated setup, which means that the simple "hint" by an environment variable is not sufficient.

For the NSS case, PKCS11_MODULE=<separator like ; or :> would do, but then again, IMHO NSS is not your "average module" users want to use. Which are the similar providers that require arguments to C_Initialize ? There's also for sure modules that require certain threading setup or barf, but that's not something we need to support finetuning for, IMHO.

[alonbl]

If you want other tools to follow, this should be generic usage too, so
applications such as Firefox or OpenVPN can take advantage of this. Most
PKCS#11 aware well behaved applications cannot assume single provider.

Otherwise, please make sure OPENSC_ prefix is added.

[martinpaljak]

Tools != applications, like Firefox? The idea is not to provide a method for configuration of the whole application, but a hint to the application (if it wishes to use it). And I don't think that this requires multiple providers. Compare to JAVA_HOME and multiple JDK-s on the same machine?

[eighthave]

If someone wanted to log the PIN of a PKCS#11 provider, it would be much much simpler to just read the key events directly from the system. I don't really have an opinion on using an env var, but it is definitely very very standard on all things UNIXy to support a global config file whenever there is also a user-specific conf file supported. A global /etc/opensc/opensc-tool.conf would provide what I need.

[martinpaljak]

For PKCS#11 related things, we need to decouple it from OpenSC with clear borders. Or we end up with a similar mess as NSS.

[alonbl]

JAVA_HOME is to specify single JVM of your choice, bad example.

[martinpaljak]

A bad example? No, it is not. PKCS#11 as it currently exists is very much similar to the JRE problem. There are several, and which one you choose depends on a lot of factors. JAVA_HOME is a hint the same way as PKCS11_LIBRARY would be a hint. You really need to give a lot of options to your JRE as well, for a serious example. Yet for simple projects it suffices. So it is in many ways similar to the PKCS#11 issue - you need to specify from where to look a specific set of keys for a specific task.

[alonbl]

Hmmm.... java application MUST use single JRE, hence JAVA_HOME contains
single path.

PKCS#11 aware application may use N providers, hence the example is not
that great.

You seek something generic to be used by other utilities, this simple case
of assuming single provider always breaks when the user actually use the
tools. In enterprise it happens when the next RFC is issued and a new
vendor is selected.

So if you assume something of pkcs11-tool, please make it specific to this
tool.

This entire discussion is quite strange... as if end user needs to run this
tool in order to obtain information something wrong to begin with.

[martinpaljak]

I'm sorry, I don't really get your point. pkcs11-tool MUST use a PKCS#11 library to be useful. It MAY use several to be even more useful. For optimal results it MAY happen that the the utility (because this is in question right now, not a full-blown application like OpenVPN) would need more than a single provider for the key(s) it needs to perform its duty. The question right now is which module to use (instead of outright failing) if not specified by the user. Lets take another example from Unix world: there is a single $HOME yet cd command might make more sense with a different default depending on use case and requirements.

I believe that having a PKCS11_MODULE (mind the name, could be something else) to be used as the default for pkcs11-tool or pkcs11-spy instead of specifying it manually from the command line or dedicated environment variable makes a lot of sense. If it doesn't work for you, don't use it. For Firefox/NSS, I hope they would fix a lot of other and more important things rather than depend on a new "suggested feature for PKCS#11-apps" which I'm sure is off their radars anyway.

To re-iterate my view on this issue: it is wrong to marry OpenSC's pkcs11-tool with opensc-pkcs11.so. But it is totally reasonable to be able to give a PKCS#11-aware application such as pkcs11-tool a module path to load via and environment variable by default. The idea is not to give a "100% API-correct configuration and initialization parameters" but rather a hint to an application that might want make to use such a hint.

So instead of all these long lines of discussion a simple patch of around 5 changed lines that would actually implement this feature would be more useful than this philosophical discussion. And would not harm anyone while possibly giving a benefit for someone.

[frankmorgner]

@martinpaljak +1 for a pragmatic solution!

Does anyone want to submit a patch for: "use OpenSC's implementation by default and let the user configure something else"?

[dwmw2]

It would be better to load p11-kit-proxy.so as the default provider if it's available. The p11-kit configuration specifies which modules which should be available by default to a given process, and p11-kit-proxy.so is the simple way for an existing PKCS#11 consumer to access them.

$ pkg-config --variable=proxy_module p11-kit-1
/usr/lib64/p11-kit-proxy.so

[dwmw2]

The current default also doesn't do the right thing when running pkcs11-tool from the build directory. When running from the build directory, we expect libtool (or something) to set up LD_LIBRARY_PATH such that we run with libraries and everything else from the build directory. That isn't working for opensc_pkcs11.so, which ends up finding the old version that's installed in the system.

(Well, kind of. It seems to search $LD_LIBRARY_PATH but doesn't look in /usr/lib64/pkcs11/ which is where PKCS#11 modules seem to live on my system (as reported by 'pkg-config --variable=p11_module_path p11-kit-1').

[frankmorgner]

Well, you could make a PR with improvement. Apart from adding the correct postfix to opensc_pkcs11.so, I don't see your corner cases supported with a reasonable amount of effort. But you're free to try out.

Yes, it makes sense to use p11-kit's pkcs#11module by default, if and only if we know that it will be installed along with OpenSC. This makes sense, for example when building the package for Mac OS X. However, you would only have to add --with-pkcs11-provider=PATH to the configure flags in MacOSX/build-package.in (read: it is already supported).