running named built with --enable-native-pkcs11 without HSM provider library

Evan Hunt each at
Thu Jul 30 17:35:20 UTC 2015

On Thu, Jul 30, 2015 at 10:19:49AM -0700, Carl Byington wrote:
> RHEL7/Centos7 now has softhsm v2 available. What about a new pkcs11
> provider that is just an interface into openssl?
>   --enable-native-pkcs11 \
>   --with-pkcs11=pkcs11-openssl-shim
> Bind uses native pkcs11, but the default .so it loads just redirects all
> the calls into openssl.

That in fact is exactly what SoftHSMv2 does.

> Bind will ask it to generate keys, and will
> assume that that provider will keep the private key part. So we still
> don't end up with the original /var/named/K*.private files.

Technically you still have the files, but instead of the files containing
private key material themselves, they have indentifiers to tell the HSM
(or pseudo-HSM) which key is to be used.

> Well, this new provider is *only* used by bind, so it could run under
> the bind user account, have selinux access to /var/named, and keep its
> private key data in files, possibly in a new /var/named/pkcs11-openssl-
> shim directory.
> With this scheme, we would not need the -pkcs11 rpm subpackages, but
> could use /etc/sysconfig/named to control the switch between providers.

Better than just replicating the behavior of SoftHSMv2 would be a shim
that can switch between multiple PKCS#11 providers. 

You'd build BIND to link to the shim provider. The shim in turn could
pass along PKCS#11 calls to either SoftHSM or some other HSM, depending
on the key. Then for example, you could use a KeyPer (slow but very secure)
for certain high value keys but use software crypto (much faster but less
secure) for others.

This has been on our to-do list for some time but other items have taken

> Does redhat want to write (or fund the writing of) such a shim provider?

We'd certainly be happy for any assistance.

Evan Hunt -- each at
Internet Systems Consortium, Inc.

More information about the bind-users mailing list