1 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
2 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
3 [<!ENTITY mdash "—">]>
5 - Copyright (C) 2010, 2012-2015 Internet Systems Consortium, Inc. ("ISC")
7 - Permission to use, copy, modify, and/or distribute this software for any
8 - purpose with or without fee is hereby granted, provided that the above
9 - copyright notice and this permission notice appear in all copies.
11 - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
12 - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
13 - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
14 - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
15 - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
16 - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
17 - PERFORMANCE OF THIS SOFTWARE.
21 <title>PKCS#11 (Cryptoki) support</title>
23 PKCS#11 (Public Key Cryptography Standard #11) defines a
24 platform-independent API for the control of hardware security
25 modules (HSMs) and other cryptographic support devices.
28 BIND 9 is known to work with three HSMs: The AEP Keyper, which has
29 been tested with Debian Linux, Solaris x86 and Windows Server 2003;
30 the Thales nShield, tested with Debian Linux; and the Sun SCA 6000
31 cryptographic acceleration board, tested with Solaris x86. In
32 addition, BIND can be used with all current versions of SoftHSM,
33 a software-based HSM simulator library produced by the OpenDNSSEC
37 PKCS#11 makes use of a "provider library": a dynamically loadable
38 library which provides a low-level PKCS#11 interface to drive the HSM
39 hardware. The PKCS#11 provider library comes from the HSM vendor, and
40 it is specific to the HSM to be controlled.
43 There are two available mechanisms for PKCS#11 support in BIND 9:
44 OpenSSL-based PKCS#11 and native PKCS#11. When using the first
45 mechanism, BIND uses a modified version of OpenSSL, which loads
46 the provider library and operates the HSM indirectly; any
47 cryptographic operations not supported by the HSM can be carried
48 out by OpenSSL instead. The second mechanism enables BIND to bypass
49 OpenSSL completely; BIND loads the provider library itself, and uses
50 the PKCS#11 API to drive the HSM directly.
53 <title>Prerequisites</title>
55 See the documentation provided by your HSM vendor for
56 information about installing, initializing, testing and
57 troubleshooting the HSM.
61 <title>Native PKCS#11</title>
63 Native PKCS#11 mode will only work with an HSM capable of carrying
64 out <emphasis>every</emphasis> cryptographic operation BIND 9 may
65 need. The HSM's provider library must have a complete implementation
66 of the PKCS#11 API, so that all these functions are accessible. As of
67 this writing, only the Thales nShield HSM and SoftHSMv2 can be used
68 in this fashion. For other HSMs, including the AEP Keyper, Sun SCA
69 6000 and older versions of SoftHSM, use OpenSSL-based PKCS#11.
70 (Note: Eventually, when more HSMs become capable of supporting
71 native PKCS#11, it is expected that OpenSSL-based PKCS#11 will
75 To build BIND with native PKCS#11, configure as follows:
78 $ <userinput>cd bind9</userinput>
79 $ <userinput>./configure --enable-native-pkcs11 \
80 --with-pkcs11=<replaceable>provider-library-path</replaceable></userinput>
83 This will cause all BIND tools, including <command>named</command>
84 and the <command>dnssec-*</command> and <command>pkcs11-*</command>
85 tools, to use the PKCS#11 provider library specified in
86 <replaceable>provider-library-path</replaceable> for cryptography.
87 (The provider library path can be overridden using the
88 <option>-E</option> in <command>named</command> and the
89 <command>dnssec-*</command> tools, or the <option>-m</option> in
90 the <command>pkcs11-*</command> tools.)
93 <title>Building SoftHSMv2</title>
95 SoftHSMv2, the latest development version of SoftHSM, is available
97 <ulink url="https://github.com/opendnssec/SoftHSMv2">
98 https://github.com/opendnssec/SoftHSMv2
100 It is a software library developed by the OpenDNSSEC project
101 (<ulink url="http://www.opendnssec.org">
102 http://www.opendnssec.org
104 which provides a PKCS#11 interface to a virtual HSM, implemented in
105 the form of a SQLite3 database on the local filesystem. It provides
106 less security than a true HSM, but it allows you to experiment with
107 native PKCS#11 when an HSM is not available. SoftHSMv2 can be
108 configured to use either OpenSSL or the Botan library to perform
109 cryptographic functions, but when using it for native PKCS#11 in
110 BIND, OpenSSL is required.
113 By default, the SoftHSMv2 configuration file is
114 <replaceable>prefix</replaceable>/etc/softhsm2.conf (where
115 <replaceable>prefix</replaceable> is configured at compile time).
116 This location can be overridden by the SOFTHSM2_CONF environment
117 variable. The SoftHSMv2 cryptographic store must be installed and
118 initialized before using it with BIND.
121 $ <userinput> cd SoftHSMv2 </userinput>
122 $ <userinput> configure --with-crypto-backend=openssl --prefix=/opt/pkcs11/usr --enable-gost </userinput>
123 $ <userinput> make </userinput>
124 $ <userinput> make install </userinput>
125 $ <userinput> /opt/pkcs11/usr/bin/softhsm-util --init-token 0 --slot 0 --label softhsmv2 </userinput>
130 <title>OpenSSL-based PKCS#11</title>
132 OpenSSL-based PKCS#11 mode uses a modified version of the
133 OpenSSL library; stock OpenSSL does not fully support PKCS#11.
134 ISC provides a patch to OpenSSL to correct this. This patch is
135 based on work originally done by the OpenSolaris project; it has been
136 modified by ISC to provide new features such as PIN management and
140 There are two "flavors" of PKCS#11 support provided by
141 the patched OpenSSL, one of which must be chosen at
142 configuration time. The correct choice depends on the HSM
148 Use 'crypto-accelerator' with HSMs that have hardware
149 cryptographic acceleration features, such as the SCA 6000
150 board. This causes OpenSSL to run all supported
151 cryptographic operations in the HSM.
156 Use 'sign-only' with HSMs that are designed to
157 function primarily as secure key storage devices, but lack
158 hardware acceleration. These devices are highly secure, but
159 are not necessarily any faster at cryptography than the
160 system CPU — often, they are slower. It is therefore
161 most efficient to use them only for those cryptographic
162 functions that require access to the secured private key,
163 such as zone signing, and to use the system CPU for all
164 other computationally-intensive operations. The AEP Keyper
165 is an example of such a device.
170 The modified OpenSSL code is included in the BIND 9 release,
171 in the form of a context diff against the latest versions of
172 OpenSSL. OpenSSL 0.9.8, 1.0.0, and 1.0.1 are supported; there are
173 separate diffs for each version. In the examples to follow,
174 we use OpenSSL 0.9.8, but the same methods work with OpenSSL
178 The latest OpenSSL versions as of this writing (January 2015)
179 are 0.9.8zc, 1.0.0o, and 1.0.1j.
180 ISC will provide updated patches as new versions of OpenSSL
181 are released. The version number in the following examples
182 is expected to change.
185 Before building BIND 9 with PKCS#11 support, it will be
186 necessary to build OpenSSL with the patch in place, and configure
187 it with the path to your HSM's PKCS#11 provider library.
190 <title>Patching OpenSSL</title>
192 $ <userinput>wget <ulink>http://www.openssl.org/source/openssl-0.9.8zc.tar.gz</ulink></userinput>
194 <para>Extract the tarball:</para>
196 $ <userinput>tar zxf openssl-0.9.8zc.tar.gz</userinput>
198 <para>Apply the patch from the BIND 9 release:</para>
200 $ <userinput>patch -p1 -d openssl-0.9.8zc \
201 < bind9/bin/pkcs11/openssl-0.9.8zc-patch</userinput>
204 Note that the patch file may not be compatible with the
205 "patch" utility on all operating systems. You may need to
209 When building OpenSSL, place it in a non-standard
210 location so that it does not interfere with OpenSSL libraries
211 elsewhere on the system. In the following examples, we choose
212 to install into "/opt/pkcs11/usr". We will use this location
213 when we configure BIND 9.
216 Later, when building BIND 9, the location of the custom-built
217 OpenSSL library will need to be specified via configure.
222 <title>Building OpenSSL for the AEP Keyper on Linux</title>
224 The AEP Keyper is a highly secure key storage device,
225 but does not provide hardware cryptographic acceleration. It
226 can carry out cryptographic operations, but it is probably
227 slower than your system's CPU. Therefore, we choose the
228 'sign-only' flavor when building OpenSSL.
231 The Keyper-specific PKCS#11 provider library is
232 delivered with the Keyper software. In this example, we place
233 it /opt/pkcs11/usr/lib:
236 $ <userinput>cp pkcs11.GCC4.0.2.so.4.05 /opt/pkcs11/usr/lib/libpkcs11.so</userinput>
239 This library is only available for Linux as a 32-bit
240 binary. If we are compiling on a 64-bit Linux system, it is
241 necessary to force a 32-bit build, by specifying -m32 in the
245 Finally, the Keyper library requires threads, so we
246 must specify -pthread.
249 $ <userinput>cd openssl-0.9.8zc</userinput>
250 $ <userinput>./Configure linux-generic32 -m32 -pthread \
251 --pk11-libname=/opt/pkcs11/usr/lib/libpkcs11.so \
252 --pk11-flavor=sign-only \
253 --prefix=/opt/pkcs11/usr</userinput>
256 After configuring, run "<command>make</command>"
257 and "<command>make test</command>". If "<command>make
258 test</command>" fails with "pthread_atfork() not found", you forgot to
259 add the -pthread above.
264 <title>Building OpenSSL for the SCA 6000 on Solaris</title>
266 The SCA-6000 PKCS#11 provider is installed as a system
267 library, libpkcs11. It is a true crypto accelerator, up to 4
268 times faster than any CPU, so the flavor shall be
269 'crypto-accelerator'.
272 In this example, we are building on Solaris x86 on an
276 $ <userinput>cd openssl-0.9.8zc</userinput>
277 $ <userinput>./Configure solaris64-x86_64-cc \
278 --pk11-libname=/usr/lib/64/libpkcs11.so \
279 --pk11-flavor=crypto-accelerator \
280 --prefix=/opt/pkcs11/usr</userinput>
283 (For a 32-bit build, use "solaris-x86-cc" and /usr/lib/libpkcs11.so.)
286 After configuring, run
287 <command>make</command> and
288 <command>make test</command>.
293 <title>Building OpenSSL for SoftHSM</title>
295 SoftHSM (version 1) is a software library developed by the
297 (<ulink url="http://www.opendnssec.org">
298 http://www.opendnssec.org
301 PKCS#11 interface to a virtual HSM, implemented in the form of
302 a SQLite3 database on the local filesystem. SoftHSM uses
303 the Botan library to perform cryptographic functions. Though
304 less secure than a true HSM, it can allow you to experiment
305 with PKCS#11 when an HSM is not available.
308 The SoftHSM cryptographic store must be installed and
309 initialized before using it with OpenSSL, and the SOFTHSM_CONF
310 environment variable must always point to the SoftHSM configuration
314 $ <userinput> cd softhsm-1.3.7 </userinput>
315 $ <userinput> configure --prefix=/opt/pkcs11/usr </userinput>
316 $ <userinput> make </userinput>
317 $ <userinput> make install </userinput>
318 $ <userinput> export SOFTHSM_CONF=/opt/pkcs11/softhsm.conf </userinput>
319 $ <userinput> echo "0:/opt/pkcs11/softhsm.db" > $SOFTHSM_CONF </userinput>
320 $ <userinput> /opt/pkcs11/usr/bin/softhsm --init-token 0 --slot 0 --label softhsm </userinput>
323 SoftHSM can perform all cryptographic operations, but
324 since it only uses your system CPU, there is no advantage to using
325 it for anything but signing. Therefore, we choose the 'sign-only'
326 flavor when building OpenSSL.
329 $ <userinput>cd openssl-0.9.8zc</userinput>
330 $ <userinput>./Configure linux-x86_64 -pthread \
331 --pk11-libname=/opt/pkcs11/usr/lib/libsofthsm.so \
332 --pk11-flavor=sign-only \
333 --prefix=/opt/pkcs11/usr</userinput>
336 After configuring, run "<command>make</command>"
337 and "<command>make test</command>".
341 Once you have built OpenSSL, run
342 "<command>apps/openssl engine pkcs11</command>" to confirm
343 that PKCS#11 support was compiled in correctly. The output
344 should be one of the following lines, depending on the flavor
348 (pkcs11) PKCS #11 engine support (sign only)
352 (pkcs11) PKCS #11 engine support (crypto accelerator)
356 "<command>apps/openssl engine pkcs11 -t</command>". This will
357 attempt to initialize the PKCS#11 engine. If it is able to
358 do so successfully, it will report
359 <quote><literal>[ available ]</literal></quote>.
362 If the output is correct, run
363 "<command>make install</command>" which will install the
364 modified OpenSSL suite to <filename>/opt/pkcs11/usr</filename>.
368 <title>Configuring BIND 9 for Linux with the AEP Keyper</title>
370 To link with the PKCS#11 provider, threads must be
371 enabled in the BIND 9 build.
374 The PKCS#11 library for the AEP Keyper is currently
375 only available as a 32-bit binary. If we are building on a
376 64-bit host, we must force a 32-bit build by adding "-m32" to
377 the CC options on the "configure" command line.
380 $ <userinput>cd ../bind9</userinput>
381 $ <userinput>./configure CC="gcc -m32" --enable-threads \
382 --with-openssl=/opt/pkcs11/usr \
383 --with-pkcs11=/opt/pkcs11/usr/lib/libpkcs11.so</userinput>
388 <title>Configuring BIND 9 for Solaris with the SCA 6000</title>
390 To link with the PKCS#11 provider, threads must be
391 enabled in the BIND 9 build.
394 $ <userinput>cd ../bind9</userinput>
395 $ <userinput>./configure CC="cc -xarch=amd64" --enable-threads \
396 --with-openssl=/opt/pkcs11/usr \
397 --with-pkcs11=/usr/lib/64/libpkcs11.so</userinput>
399 <para>(For a 32-bit build, omit CC="cc -xarch=amd64".)</para>
401 If configure complains about OpenSSL not working, you
402 may have a 32/64-bit architecture mismatch. Or, you may have
403 incorrectly specified the path to OpenSSL (it should be the
404 same as the --prefix argument to the OpenSSL
410 <title>Configuring BIND 9 for SoftHSM</title>
412 $ <userinput>cd ../bind9</userinput>
413 $ <userinput>./configure --enable-threads \
414 --with-openssl=/opt/pkcs11/usr \
415 --with-pkcs11=/opt/pkcs11/usr/lib/libsofthsm.so</userinput>
419 After configuring, run
420 "<command>make</command>",
421 "<command>make test</command>" and
422 "<command>make install</command>".
425 (Note: If "make test" fails in the "pkcs11" system test, you may
426 have forgotten to set the SOFTHSM_CONF environment variable.)
430 <title>PKCS#11 Tools</title>
432 BIND 9 includes a minimal set of tools to operate the
434 <command>pkcs11-keygen</command> to generate a new key pair
436 <command>pkcs11-list</command> to list objects currently
438 <command>pkcs11-destroy</command> to remove objects, and
439 <command>pkcs11-tokens</command> to list available tokens.
442 In UNIX/Linux builds, these tools are built only if BIND
443 9 is configured with the --with-pkcs11 option. (Note: If
444 --with-pkcs11 is set to "yes", rather than to the path of the
445 PKCS#11 provider, then the tools will be built but the
446 provider will be left undefined. Use the -m option or the
447 PKCS11_PROVIDER environment variable to specify the path to the
452 <title>Using the HSM</title>
454 For OpenSSL-based PKCS#11, we must first set up the runtime
455 environment so the OpenSSL and PKCS#11 libraries can be loaded:
458 $ <userinput>export LD_LIBRARY_PATH=/opt/pkcs11/usr/lib:${LD_LIBRARY_PATH}</userinput>
461 This causes <command>named</command> and other binaries to load
462 the OpenSSL library from <filename>/opt/pkcs11/usr/lib</filename>
463 rather than from the default location. This step is not necessary
464 when using native PKCS#11.
467 Some HSMs require other environment variables to be set.
468 For example, when operating an AEP Keyper, it is necessary to
469 specify the location of the "machine" file, which stores
470 information about the Keyper for use by the provider
471 library. If the machine file is in
472 <filename>/opt/Keyper/PKCS11Provider/machine</filename>,
476 $ <userinput>export KEYPER_LIBRARY_PATH=/opt/Keyper/PKCS11Provider</userinput>
479 Such environment variables must be set whenever running
480 any tool that uses the HSM, including
481 <command>pkcs11-keygen</command>,
482 <command>pkcs11-list</command>,
483 <command>pkcs11-destroy</command>,
484 <command>dnssec-keyfromlabel</command>,
485 <command>dnssec-signzone</command>,
486 <command>dnssec-keygen</command>, and
487 <command>named</command>.
490 We can now create and use keys in the HSM. In this case,
491 we will create a 2048 bit key and give it the label
495 $ <userinput>pkcs11-keygen -b 2048 -l sample-ksk</userinput>
497 <para>To confirm that the key exists:</para>
499 $ <userinput>pkcs11-list</userinput>
501 object[0]: handle 2147483658 class 3 label[8] 'sample-ksk' id[0]
502 object[1]: handle 2147483657 class 2 label[8] 'sample-ksk' id[0]
505 Before using this key to sign a zone, we must create a
506 pair of BIND 9 key files. The "dnssec-keyfromlabel" utility
507 does this. In this case, we will be using the HSM key
508 "sample-ksk" as the key-signing key for "example.net":
511 $ <userinput>dnssec-keyfromlabel -l sample-ksk -f KSK example.net</userinput>
514 The resulting K*.key and K*.private files can now be used
515 to sign the zone. Unlike normal K* files, which contain both
516 public and private key data, these files will contain only the
517 public key data, plus an identifier for the private key which
518 remains stored within the HSM. Signing with the private key takes
519 place inside the HSM.
522 If you wish to generate a second key in the HSM for use
523 as a zone-signing key, follow the same procedure above, using a
524 different keylabel, a smaller key size, and omitting "-f KSK"
525 from the dnssec-keyfromlabel arguments:
528 (Note: When using OpenSSL-based PKCS#11 the label is an arbitrary
529 string which identifies the key. With native PKCS#11, the label is
530 a PKCS#11 URI string which may include other details about the key
531 and the HSM, including its PIN. See
532 <xref linkend="man.dnssec-keyfromlabel"/> for details.)
535 $ <userinput>pkcs11-keygen -b 1024 -l sample-zsk</userinput>
536 $ <userinput>dnssec-keyfromlabel -l sample-zsk example.net</userinput>
539 Alternatively, you may prefer to generate a conventional
540 on-disk key, using dnssec-keygen:
543 $ <userinput>dnssec-keygen example.net</userinput>
546 This provides less security than an HSM key, but since
547 HSMs can be slow or cumbersome to use for security reasons, it
548 may be more efficient to reserve HSM keys for use in the less
549 frequent key-signing operation. The zone-signing key can be
550 rolled more frequently, if you wish, to compensate for a
551 reduction in key security. (Note: When using native PKCS#11,
552 there is no speed advantage to using on-disk keys, as cryptographic
553 operations will be done by the HSM regardless.)
556 Now you can sign the zone. (Note: If not using the -S
557 option to <command>dnssec-signzone</command>, it will be
558 necessary to add the contents of both <filename>K*.key</filename>
559 files to the zone master file before signing it.)
562 $ <userinput>dnssec-signzone -S example.net</userinput>
564 Verifying the zone using the following algorithms:
566 Zone signing complete:
567 Algorithm: NSEC3RSASHA1: ZSKs: 1, KSKs: 1 active, 0 revoked, 0 stand-by
572 <title>Specifying the engine on the command line</title>
574 When using OpenSSL-based PKCS#11, the "engine" to be used by
575 OpenSSL can be specified in <command>named</command> and all of
576 the BIND <command>dnssec-*</command> tools by using the "-E
577 <engine>" command line option. If BIND 9 is built with
578 the --with-pkcs11 option, this option defaults to "pkcs11".
579 Specifying the engine will generally not be necessary unless
580 for some reason you wish to use a different OpenSSL
584 If you wish to disable use of the "pkcs11" engine —
585 for troubleshooting purposes, or because the HSM is unavailable
586 — set the engine to the empty string. For example:
589 $ <userinput>dnssec-signzone -E '' -S example.net</userinput>
593 <command>dnssec-signzone</command> to run as if it were compiled
594 without the --with-pkcs11 option.
597 When built with native PKCS#11 mode, the "engine" option has a
598 different meaning: it specifies the path to the PKCS#11 provider
599 library. This may be useful when testing a new provider library.
603 <title>Running named with automatic zone re-signing</title>
605 If you want <command>named</command> to dynamically re-sign zones
606 using HSM keys, and/or to to sign new records inserted via nsupdate,
607 then named must have access to the HSM PIN. In OpenSSL-based PKCS#11,
608 this is accomplished by placing the PIN into the openssl.cnf file
609 (in the above examples,
610 <filename>/opt/pkcs11/usr/ssl/openssl.cnf</filename>).
613 The location of the openssl.cnf file can be overridden by
614 setting the OPENSSL_CONF environment variable before running
617 <para>Sample openssl.cnf:</para>
619 openssl_conf = openssl_def
621 engines = engine_section
623 pkcs11 = pkcs11_section
625 PIN = <replaceable><PLACE PIN HERE></replaceable>
628 This will also allow the dnssec-* tools to access the HSM
629 without PIN entry. (The pkcs11-* tools access the HSM directly,
630 not via OpenSSL, so a PIN will still be required to use
634 In native PKCS#11 mode, the PIN can be provided in a file specified
635 as an attribute of the key's label. For example, if a key had the label
636 <userinput>pkcs11:object=local-zsk;pin-source=/etc/hsmpin</userinput>,
637 then the PIN would be read from the file
638 <filename>/etc/hsmpin</filename>.
642 Placing the HSM's PIN in a text file in this manner may reduce the
643 security advantage of using an HSM. Be sure this is what you want to
644 do before configuring the system in this way.