Adding upstream version 1:9.16.44.upstream/1%9.16.44upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 287 insertions, 0 deletions

diff --git a/doc/arm/pkcs11.rst b/doc/arm/pkcs11.rst
new file mode 100644
index 0000000..bce9ef6
--- /dev/null
+++ b/doc/arm/pkcs11.rst
@@ -0,0 +1,287 @@
+.. Copyright (C) Internet Systems Consortium, Inc. ("ISC")
+..
+.. SPDX-License-Identifier: MPL-2.0
+..
+.. This Source Code Form is subject to the terms of the Mozilla Public
+.. License, v. 2.0.  If a copy of the MPL was not distributed with this
+.. file, you can obtain one at https://mozilla.org/MPL/2.0/.
+..
+.. See the COPYRIGHT file distributed with this work for additional
+.. information regarding copyright ownership.
+
+.. _pkcs11:
+
+PKCS#11 (Cryptoki) Support
+--------------------------
+
+Public Key Cryptography Standard #11 (PKCS#11) defines a
+platform-independent API for the control of hardware security modules
+(HSMs) and other cryptographic support devices.
+
+BIND 9 is known to work with three HSMs: the AEP Keyper, which has been
+tested with Debian Linux, Solaris x86, and Windows Server 2003; the
+Thales nShield, tested with Debian Linux; and the Sun SCA 6000
+cryptographic acceleration board, tested with Solaris x86. In addition,
+BIND can be used with all current versions of SoftHSM, a software-based
+HSM simulator library produced by the OpenDNSSEC project.
+
+PKCS#11 uses a "provider library": a dynamically loadable
+library which provides a low-level PKCS#11 interface to drive the HSM
+hardware. The PKCS#11 provider library comes from the HSM vendor, and it
+is specific to the HSM to be controlled.
+
+There are two available mechanisms for PKCS#11 support in BIND 9:
+OpenSSL-based PKCS#11 and native PKCS#11. With OpenSSL-based PKCS#11,
+BIND uses a modified version of OpenSSL, which loads the
+provider library and operates the HSM indirectly; any cryptographic
+operations not supported by the HSM can be carried out by OpenSSL
+instead. Native PKCS#11 enables BIND to bypass OpenSSL completely;
+BIND loads the provider library itself, and uses the PKCS#11 API to
+drive the HSM directly.
+
+Prerequisites
+~~~~~~~~~~~~~
+
+See the documentation provided by the HSM vendor for information about
+installing, initializing, testing, and troubleshooting the HSM.
+
+Native PKCS#11
+~~~~~~~~~~~~~~
+
+Native PKCS#11 mode only works with an HSM capable of carrying out
+*every* cryptographic operation BIND 9 may need. The HSM's provider
+library must have a complete implementation of the PKCS#11 API, so that
+all these functions are accessible. As of this writing, only the Thales
+nShield HSM and SoftHSMv2 can be used in this fashion. For other HSMs,
+including the AEP Keyper, Sun SCA 6000, and older versions of SoftHSM,
+use OpenSSL-based PKCS#11. (Note: Eventually, when more HSMs become
+capable of supporting native PKCS#11, it is expected that OpenSSL-based
+PKCS#11 will be deprecated.)
+
+To build BIND with native PKCS#11, configure it as follows:
+
+::
+
+   $ cd bind9
+   $ ./configure --enable-native-pkcs11 \
+       --with-pkcs11=provider-library-path
+
+
+This causes all BIND tools, including ``named`` and the ``dnssec-*``
+and ``pkcs11-*`` tools, to use the PKCS#11 provider library specified in
+provider-library-path for cryptography. (The provider library path can
+be overridden using the ``-E`` argument in ``named`` and the ``dnssec-*`` tools,
+or the ``-m`` argument in the ``pkcs11-*`` tools.)
+
+Building SoftHSMv2
+^^^^^^^^^^^^^^^^^^
+
+SoftHSMv2, the latest development version of SoftHSM, is available from
+https://github.com/opendnssec/SoftHSMv2. It is a software library
+developed by the OpenDNSSEC project (https://www.opendnssec.org) which
+provides a PKCS#11 interface to a virtual HSM, implemented in the form
+of an SQLite3 database on the local filesystem. It provides less security
+than a true HSM, but it allows users to experiment with native PKCS#11
+when an HSM is not available. SoftHSMv2 can be configured to use either
+OpenSSL or the Botan library to perform cryptographic functions, but
+when using it for native PKCS#11 in BIND, OpenSSL is required.
+
+By default, the SoftHSMv2 configuration file is ``prefix/etc/softhsm2.conf``
+(where ``prefix`` is configured at compile time). This location can be
+overridden by the SOFTHSM2_CONF environment variable. The SoftHSMv2
+cryptographic store must be installed and initialized before using it
+with BIND.
+
+::
+
+   $  cd SoftHSMv2
+   $  configure --with-crypto-backend=openssl --prefix=/opt/pkcs11/usr
+   $  make
+   $  make install
+   $  /opt/pkcs11/usr/bin/softhsm-util --init-token 0 --slot 0 --label softhsmv2
+
+
+OpenSSL-based PKCS#11
+~~~~~~~~~~~~~~~~~~~~~
+
+OpenSSL-based PKCS#11 uses engine_pkcs11 OpenSSL engine from libp11 project.
+
+For more information, see https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11
+
+PKCS#11 Tools
+~~~~~~~~~~~~~
+
+BIND 9 includes a minimal set of tools to operate the HSM, including
+``pkcs11-keygen`` to generate a new key pair within the HSM,
+``pkcs11-list`` to list objects currently available, ``pkcs11-destroy``
+to remove objects, and ``pkcs11-tokens`` to list available tokens.
+
+In UNIX/Linux builds, these tools are built only if BIND 9 is configured
+with the ``--with-pkcs11`` option. (Note: If ``--with-pkcs11`` is set to ``yes``,
+rather than to the path of the PKCS#11 provider, the tools are
+built but the provider is left undefined. Use the ``-m`` option or the
+``PKCS11_PROVIDER`` environment variable to specify the path to the
+provider.)
+
+Using the HSM
+~~~~~~~~~~~~~
+
+For OpenSSL-based PKCS#11, the runtime environment must first be set up
+so the OpenSSL and PKCS#11 libraries can be loaded:
+
+::
+
+   $ export LD_LIBRARY_PATH=/opt/pkcs11/usr/lib:${LD_LIBRARY_PATH}
+
+This causes ``named`` and other binaries to load the OpenSSL library
+from ``/opt/pkcs11/usr/lib``, rather than from the default location. This
+step is not necessary when using native PKCS#11.
+
+Some HSMs require other environment variables to be set. For example,
+when operating an AEP Keyper, the location of
+the "machine" file, which stores information about the Keyper for use by
+the provider library, must be specified. If the machine file is in
+``/opt/Keyper/PKCS11Provider/machine``, use:
+
+::
+
+   $ export KEYPER_LIBRARY_PATH=/opt/Keyper/PKCS11Provider
+
+Such environment variables must be set when running any tool that
+uses the HSM, including ``pkcs11-keygen``, ``pkcs11-list``,
+``pkcs11-destroy``, ``dnssec-keyfromlabel``, ``dnssec-signzone``,
+``dnssec-keygen``, and ``named``.
+
+HSM keys can now be created and used. In this case, we will create
+a 2048-bit key and give it the label "sample-ksk":
+
+::
+
+   $ pkcs11-keygen -b 2048 -l sample-ksk
+
+To confirm that the key exists:
+
+::
+
+   $ pkcs11-list
+   Enter PIN:
+   object[0]: handle 2147483658 class 3 label[8] 'sample-ksk' id[0]
+   object[1]: handle 2147483657 class 2 label[8] 'sample-ksk' id[0]
+
+Before using this key to sign a zone, we must create a pair of BIND 9
+key files. The ``dnssec-keyfromlabel`` utility does this. In this case, we
+are using the HSM key "sample-ksk" as the key-signing key for
+"example.net":
+
+::
+
+   $ dnssec-keyfromlabel -l sample-ksk -f KSK example.net
+
+The resulting K*.key and K*.private files can now be used to sign the
+zone. Unlike normal K\* files, which contain both public and private key
+data, these files contain only the public key data, plus an
+identifier for the private key which remains stored within the HSM.
+Signing with the private key takes place inside the HSM.
+
+To generate a second key in the HSM for use as a
+zone-signing key, follow the same procedure above, using a different
+keylabel, a smaller key size, and omitting ``-f KSK`` from the
+``dnssec-keyfromlabel`` arguments:
+
+::
+
+   $ pkcs11-keygen -b 1024 -l sample-zsk
+   $ dnssec-keyfromlabel -l sample-zsk example.net
+
+Alternatively, a conventional on-disk key can be generated
+using ``dnssec-keygen``:
+
+::
+
+   $ dnssec-keygen example.net
+
+This provides less security than an HSM key, but since HSMs can be slow
+or cumbersome to use for security reasons, it may be more efficient to
+reserve HSM keys for use in the less frequent key-signing operation. The
+zone-signing key can be rolled more frequently, if desired, to
+compensate for a reduction in key security. (Note: When using native
+PKCS#11, there is no speed advantage to using on-disk keys, as
+cryptographic operations are done by the HSM.)
+
+Now the zone can be signed. Please note that, if the -S option is not used for
+``dnssec-signzone``, the contents of both
+``K*.key`` files must be added to the zone master file before signing it.
+
+::
+
+   $ dnssec-signzone -S example.net
+   Enter PIN:
+   Verifying the zone using the following algorithms:
+   NSEC3RSASHA1.
+   Zone signing complete:
+   Algorithm: NSEC3RSASHA1: ZSKs: 1, KSKs: 1 active, 0 revoked, 0 stand-by
+   example.net.signed
+
+Specifying the Engine on the Command Line
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When using OpenSSL-based PKCS#11, the "engine" to be used by OpenSSL can
+be specified in ``named`` and all of the BIND ``dnssec-*`` tools by
+using the ``-E <engine>`` command line option. If BIND 9 is built with the
+``--with-pkcs11`` option, this option defaults to "pkcs11". Specifying the
+engine is generally not necessary unless
+a different OpenSSL engine is used.
+
+To disable use of the "pkcs11" engine - for
+troubleshooting purposes, or because the HSM is unavailable - set
+the engine to the empty string. For example:
+
+::
+
+   $ dnssec-signzone -E '' -S example.net
+
+This causes ``dnssec-signzone`` to run as if it were compiled without
+the ``--with-pkcs11`` option.
+
+When built with native PKCS#11 mode, the "engine" option has a different
+meaning: it specifies the path to the PKCS#11 provider library. This may
+be useful when testing a new provider library.
+
+Running ``named`` With Automatic Zone Re-signing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For ``named`` to dynamically re-sign zones using HSM keys,
+and/or to sign new records inserted via nsupdate, ``named`` must
+have access to the HSM PIN. In OpenSSL-based PKCS#11, this is
+accomplished by placing the PIN into the ``openssl.cnf`` file (in the above
+examples, ``/opt/pkcs11/usr/ssl/openssl.cnf``).
+
+The location of the openssl.cnf file can be overridden by setting the
+``OPENSSL_CONF`` environment variable before running ``named``.
+
+Here is a sample ``openssl.cnf``:
+
+::
+
+       openssl_conf = openssl_def
+       [ openssl_def ]
+       engines = engine_section
+       [ engine_section ]
+       pkcs11 = pkcs11_section
+       [ pkcs11_section ]
+       PIN = <PLACE PIN HERE>
+
+This also allows the ``dnssec-\*`` tools to access the HSM without PIN
+entry. (The ``pkcs11-\*`` tools access the HSM directly, not via OpenSSL, so
+a PIN is still required to use them.)
+
+In native PKCS#11 mode, the PIN can be provided in a file specified as
+an attribute of the key's label. For example, if a key had the label
+``pkcs11:object=local-zsk;pin-source=/etc/hsmpin``, then the PIN would
+be read from the file ``/etc/hsmpin``.
+
+.. warning::
+
+   Placing the HSM's PIN in a text file in this manner may reduce the
+   security advantage of using an HSM. Use caution
+   when configuring the system in this way.