PKCS#11 vs OpenSSL (BIND Future Development Question)


#1

BIND 9 currently supports two major cryptography provider libraries - OpenSSL and PKCS#11.

The PKCS#11 interface is very fragile, as the different vendors implement different parts of the standard, and BIND needs to be compiled with a specific PKCS#11 provider defined at the compile time. This is certainly suboptimal, and we are looking at ways how to improve that.

So, if you are running BIND with PKCS#11 HSM, or you are thinking about such setup, I would be interested to hear answer to couple of questions:

1. What functions of PKCS#11 do you care about?
Background: PKCS#11 as currently used in BIND uses PKCS#11 exclusively for anything related to crypto.

  • Getting entropy to seed PRNG
  • Message Digests (MD5, SHA-1, SHA-2)
  • HMAC
  • Symmetric Cryptography (meaning AES)
  • Public-Key Cryptography (aka DNSSEC keys)

0 voters

2. Would you be fine if BIND double linked with OpenSSL and PKCS#11?
Background: if some of the answers to previous question were NO, BIND would have to use OpenSSL as a provider for these functions and it would make the code more slimmer, and easier to test.

  • yes
  • no

0 voters

3. Would you care if BIND wouldn’t link directly to PKCS#11 library and used
OpenSSL engine

Background: the PKCS#11 is full of #ifdefs, for full picture see lib/isc/include/pk11/site.h, and it doesn’t really make sense to develop the same work-arounds at two different places.

  • oh, please no
  • yes, this seems reasonable

0 voters

There are three possible course of actions we might take:

  1. Convert the PKCS#11 usage to OpenSSL PKCS#11 engine. That would save us from most of the headaches with PKCS#11, but it might require some configuration changes for existing deployments.

  2. Convert the non public-key cryptography parts to OpenSSL. This would allow people to keep the DNSSEC private keys inside the HSMs, but all the other crypto would come from OpenSSL. (OpenSSL itself has FIPS 140-2 validation if that means anything to you.)

  3. Keep the status quo

There are some extra options to these three:

A. Improve the PKCS#11 handling to runtime detection of HSM capabilities
B. Support OpenSSL and PKCS#11 DNSSEC keys at the same time, say to store KSKs in PKCS#11 and ZSK on disk…

The A is non-issue for 1., likely to happen with 2., and unlikely to happen with 3.
The B will happen with 1., likely to happen with 2., and impossible to happen with 3.

As usual, the goal is to balance the time we have to spend on improving BIND, and our development resources are limited, so any resources saved by reducing the code we need to maintain would free our hands to do something else (like A or B).

Also please note that this is not going to affect any previously released version of BIND, just future releases.


#2

There are few issues to consider when going the pkcs#11 way:

  1. you don’t want to re-implement everything, and keep up implementing when new algorithms are being added in the pkcs#11 standard (relying on existing wrapper like engine_pkcs11/libp11 would help)
  2. you do want to provide a consistent interface to refer to objects like keys stored in a crypto token. In fedora we went with PKCS#11 URIs (rfc7512), and updated projects like engine_pkcs11, nss and gnutls to use them transparently. With that your users can rely on existing tools which scan and list smart card objects (p11tool), and bind will look consistent with all other major apps.
  3. you do want to somehow discover the pkcs11 “drivers” available in the system. In fedora we register such drivers via p11-kit, and they are made available to all applications using engine_pkcs11 (and other crypto libs of course).