PKCS#11 vs OpenSSL (BIND Future Development Question)

[Timothe Litt]

On 03-Jun-18 02:00, Ondřej Surý wrote:
> Hi all,
>
> BIND 9 currently supports two major cryptography provider libraries - OpenSSL[1] 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
>   1a) getting entropy?
>   1b) message digests?
>   1c) HMAC?
>   1d) symmetric crypto (meaning AES)
>   1e) public-key cryptography (aka DNSSEC keys)
>
> (Background: PKCS#11 as currently used in BIND uses PKCS#11 exclusively
> for anything related to crypto.)
>
> 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.)
>
> 3. Would you care if BIND wouldn’t link directly to PKCS#11 library and used
> OpenSSL engine: https://github.com/OpenSC/libp11#openssl-engines
> (Background: the PKCS#11 is full of #ifdefs, for full picture see [1], and it
> doesn’t really make sense to develop the same work-arounds at two different
> places.)
>
> ~~~
>
> 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 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.
>
> 1. https://gitlab.isc.org/isc-projects/bind9/blob/master/lib/isc/include/pk11/site.h
> 2. https://www.openssl.org/docs/fips.html#background
>
> Ondrej
> --
> Ondřej Surý
> ondrej at isc.org
>
>
With the caveat that I don't currently use PKCS#11 with BIND:

#1 - use OpenSSL's engine seems the most reasonable.  Puts most of the
maintenance burden on them.
        Perhaps you can have a script that recommends the necessary
configuration changes - presumably
        this is a one-time thing.

It seems to me that the biggest pain for users is having to compile
against a specific provider. This makes life hard for packagers (and end
users who compile bind).  If nothing else, it would be useful to (I
guess this is option 4):
 a) specify the provider at runtime - e.g. load the right DLL
 b) be able to separately compile that (those) dll(s) for whatever
provider, generating a unique name.
      This would allow packagers to pre-compile whatever set of
providers their customers want, and
      allow specifying which one in the config file.  It would be
minimal change to your code - mostly Makefile
      magic.  Essentially, the BIND version of OpenSSL engines...

      Put another way: in configure one does something like
--build-pkcs11=(hsm1, hsm2, hsm3, softhsm, ...)
      and you get hsm1.so, hsm2.so, hsm3.so, softhsm.so ... and a BIND
that knows how to load/call whichever
      one is loaded, but no provider-dependent code.  Then the bind
config file has 'pkcs11-provider "hsm2";'

      The BIND code -with whatever ugliness - remains unchanged until,
and unless you decide to refactor it.
       That could be incremental - and transparent to users.

       In fact, one of the providers could be OpenSSL (or its engines)
under a BIND interface wrapper...

       Also, this is a static choice - not "runtime detection of
capabilities".  You could do that eventually, of course, as
       part of refactoring to consolidate some/all of the libraries. 
But the end user just configures one
       name for his/her provider.  The idea is to keep things simple -
for the user, and for development.

      On the other hand, if I have multiple machines with different
providers, I don't have to compile
      a unique BIND for each.  I build it once with (at least) the union
of all the required providers, and
      deploy the same image everywhere.  Better yet, with luck my
distribution ships with all the provider libraries that I need, and I
don't compile anything!  The config file is the only variant.

So, if you can switch to OpenSSL, it seems the best long-run option.  If
you can't, (or are encouraged not to by other customers), you could
solve a lot of the customer pain by making the provider loadable.

For entropy, I use a mixture of USB keys and CPU hardware generators. 
As I may have mentioned, I use EntropyBroker to distribute the entropy
securely - this keeps cost reasonable, especially with many VMs (some of
which don't naturally generate a lot of entropy...).  See
https://www.vanheusden.com/entropybroker/ &
https://github.com/flok99/entropybroker. 

Hope this helps.


Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180603/957d7f91/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180603/957d7f91/attachment.bin>