2 BIND 9 PKCS #11 (Cryptoki) support
6 PKCS #11 (Public Key Cryptography Standard #11) defines a platform-
7 independent API for the control of hardware security modules (HSMs)
8 and other cryptographic support devices.
10 BIND 9 is known to work with two HSMs: The Sun SCA 6000 cryptographic
11 acceleration board, tested under Solaris x86, and the AEP Keyper
12 network-attached key storage device, tested with Debian Linux,
13 Solaris x86 and Windows Server 2003.
17 See the HSM vendor documentation for information about installing,
18 initializing, testing and troubleshooting the HSM.
20 BIND 9 uses OpenSSL for cryptography, but stock OpenSSL does not
21 yet fully support PKCS #11. However, a PKCS #11 engine for OpenSSL
22 is available from the OpenSolaris project. It has been modified by
23 ISC to work with with BIND 9, and to provide new features such as
24 PIN management and key by reference.
26 The patched OpenSSL depends on a "PKCS #11 provider". This is a shared
27 library object, providing a low-level PKCS #11 interface to the HSM
28 hardware. It is dynamically loaded by OpenSSL at runtime. The PKCS #11
29 provider comes from the HSM vendor, and and is specific to the HSM to be
32 There are two "flavors" of PKCS #11 support provided by the patched
33 OpenSSL, one of which must be chosen at configuration time. The correct
34 choice depends on the HSM hardware:
36 - Use 'crypto-accelerator' with HSMs that have hardware cryptographic
37 acceleration features, such as the SCA 6000 board. This causes OpenSSL
38 to run all supported cryptographic operations in the HSM.
40 - Use 'sign-only' with HSMs that are designed to function primarily as
41 secure key storage devices, but lack hardware acceleration. These
42 devices are highly secure, but are not necessarily any faster at
43 cryptography than the system CPU--often, they are slower. It is
44 therefore most efficient to use them only for those cryptographic
45 functions that require access to the secured private key, such as
46 zone signing, and to use the system CPU for all other computationally-
47 intensive operations. The AEP Keyper is an example of such a device.
49 The modified OpenSSL code is included in the BIND 9.7.0b1 release, in the
50 form of a context diff against OpenSSL 0.9.8l. Before building BIND 9
51 with PKCS #11 support, it will be necessary to build OpenSSL with this
52 patch in place and inform it of the path to the HSM-specific PKCS #11
55 Obtain OpenSSL 0.9.8l:
57 wget http://www.openssl.org/source/openssl-0.9.8l.tar.gz
61 tar zxf openssl-0.9.8l.tar.gz
63 Apply the patch from the BIND 9 release:
65 patch -p1 -d openssl-0.9.8l \
66 < bind-9.7.0b1/bin/pkcs11/openssl-0.9.8l-patch
68 (Note that the patch file may not be compatible with the "patch"
69 utility on all operating systems. You may need to install GNU patch.)
71 When building OpenSSL, place it in a non-standard location so that it
72 does not interfere with OpenSSL libraries elsewhere on the system.
73 In the following examples, we choose to install into "/opt/pkcs11/usr".
74 We will use this location when we configure BIND 9.
76 EXAMPLE 1--BUILDING OPENSSL FOR THE AEP KEYPER ON LINUX:
78 The AEP Keyper is a highly secure key storage device, but does
79 not provide hardware cryptographic acceleration. It can carry out
80 cryptographic operations, but it is probably slower than your
81 system's CPU. Therefore, we choose the 'sign-only' flavor when
84 The Keyper-specific PKCS #11 provider library is delivered with the
85 Keyper software. In this example, we place it /opt/pkcs11/usr/lib:
87 cp pkcs11.GCC4.0.2.so.4.05 /opt/pkcs11/usr/lib/libpkcs11.so
89 This library is only available for Linux as a 32-bit binary. If we are
90 compiling on a 64-bit Linux system, it is necessary to force a 32-bit
91 build, by specifying -m32 in the build options.
93 Finally, the Keyper library requires threads, so we must specify -pthread.
96 ./Configure linux-generic32 -m32 -pthread \
97 --pk11-libname=/opt/pkcs11/usr/lib/libpkcs11.so \
98 --pk11-flavor=sign-only \
99 --prefix=/opt/pkcs11/usr
101 After configuring, run "make" and "make test". If "make test" fails
102 with "pthread_atfork() not found", you forgot to add the -pthread
105 EXAMPLE 2--BUILDING OPENSSL FOR THE SCA 6000 ON SOLARIS:
107 The SCA-6000 PKCS #11 provider is installed as a system library,
108 libpkcs11. It is a true crypto accelerator, up to 4 times faster
109 than any CPU, so the flavor shall be 'crypto-accelerator'.
111 In this example, we are building on Solaris x86 on an AMD64 system.
114 ./Configure solaris64-x86_64-cc \
115 --pk11-libname=/usr/lib/64/libpkcs11.so \
116 --pk11-flavor=crypto-accelerator \
117 --prefix=/opt/pkcs11/usr
119 (For a 32-bit build, use "solaris-x86-cc" and /usr/lib/libpkcs11.so.)
121 After configuring, run "make" and "make test".
123 Once you have built OpenSSL, run "apps/openssl engine pkcs11" to confirm
124 that PKCS #11 support was compiled in correctly. The output should be
125 one of the following lines, depending on the flavor selected:
127 (pkcs11) PKCS #11 engine support (sign only)
131 (pkcs11) PKCS #11 engine support (crypto accelerator)
133 Next, run "apps/openssl engine pkcs11 -t". This will attempt to initialize
134 the PKCS #11 engine. If it is able to do so successfully, it will report
137 If the output is correct, run "make install".
141 When building BIND 9, the location of the custom-built OpenSSL
142 library must be specified via configure.
144 EXAMPLE 3--CONFIGURING BIND 9 FOR LINUX
146 To link with the PKCS #11 provider, threads must be enabled in the
149 The PKCS #11 library for the AEP Keyper is currently only available as
150 a 32-bit binary. If we are building on a 64-bit host, we must force a
151 32-bit build by adding "-m32" to the CC options on the "configure"
155 ./configure CC="gcc -m32" --enable-threads \
156 --with-openssl=/opt/pkcs11/usr \
157 --with-pkcs11=/opt/pkcs11/usr/lib/libpkcs11.so
159 EXAMPLE 4--CONFIGURING BIND 9 FOR SOLARIS
161 To link with the PKCS #11 provider, threads must be enabled in the
165 ./configure CC="cc -xarch=amd64" --enable-threads \
166 --with-openssl=/opt/pkcs11/usr \
167 --with-pkcs11=/usr/lib/64/libpkcs11.so
169 (For a 32-bit build, omit CC="cc -xarch=amd64".)
171 If configure complains about OpenSSL not working, you may have a 32/64-bit
172 architecture mismatch. Or, you may have incorrectly specified the path to
173 OpenSSL (it should be the same as the --prefix argument to the OpenSSL
176 After configuring, run "make", "make test" and "make install".
180 BIND 9 includes a minimal set of tools to operate the HSM, including
181 "pkcs11-keygen" to generate a new key pair within the HSM, "pkcs11-list"
182 to list objects currently available, and "pkcs11-destroy" to remove
185 In UNIX/Linux builds, these tools are built only if BIND 9 is configured
186 with the --with-pkcs11 option. (NOTE: If --with-pkcs11 is set to "yes",
187 rather than to the path of the PKCS #11 provider, then the tools will be
188 built but the provider will be left undefined. Use the -m option or the
189 PKCS11_PROVIDER environment variable to specify the path to the provider.)
193 First, we must set up the runtime environment so the OpenSSL and PKCS #11
194 libraries can be loaded:
196 export LD_LIBRARY_PATH=/opt/pkcs11/usr/lib:${LD_LIBRARY_PATH}
198 When operating an AEP Keyper, it is also necessary to specify the
199 location of the "machine" file, which stores information about the Keyper
200 for use by PKCS #11 provider library. If the machine file is in
201 /opt/Keyper/PKCS11Provider/machine, use:
203 export KEYPER_LIBRARY_PATH=/opt/Keyper/PKCS11Provider
205 These environment variables must be set whenever running any tool
206 that uses the HSM, including pkcs11-keygen, pkcs11-list, pkcs11-destroy,
207 dnssec-keyfromlabel, dnssec-signzone, dnssec-keygen (which will use
208 the HSM for random number generation), and named.
210 We can now create and use keys in the HSM. In this case, we will
211 create a 2048 bit key and give it the label "sample-ksk":
213 pkcs11-keygen -b 2048 -l sample-ksk
215 To confirm that the key exists:
219 object[0]: handle 2147483658 class 3 label[8] 'sample-ksk' id[0]
220 object[1]: handle 2147483657 class 2 label[8] 'sample-ksk' id[0]
222 Before using this key to sign a zone, we must create a pair of BIND 9
223 key files. The "dnssec-keyfromlabel" utility does this. In this case,
224 we will be using the HSM key "sample-ksk" as the key-signing key for
227 dnssec-keyfromlabel -l sample-ksk -f KSK example.net
229 The resulting K*.key and K*.private files can now be used to sign the
230 zone. Unlike normal K* files, which contain both public and private
231 key data, these files will contain only the public key data, plus an
232 identifier for the private key which remains stored within the HSM.
233 The HSM handles signing with the private key.
235 If you wish to generate a second key in the HSM for use as a zone-signing
236 key, follow the same procedure above, using a different keylabel, a
237 smaller key size, and omitting "-f KSK" from the dnssec-keyfromlabel
240 pkcs11-keygen -b 1024 -l sample-zsk
241 dnssec-keyfromlabel -l sample-zsk example.net
243 Alternatively, you may prefer to generate a conventional on-disk key,
246 dnssec-keygen example.net
248 This provides less security than an HSM key, but since HSMs can be
249 slow or cumbersome to use for security reasons, it may be more
250 efficient to reserve HSM keys for use in the less frequent
251 key-signing operation. The zone-signing key can be rolled more
252 frequently, if you wish, to compensate for a reduction in key
255 Now you can sign the zone. (Note: If not using the -S option to
256 dnssec-signzone, it will be necessary to add the contents of both
257 K*.key files to the zone master file before signing it.)
259 dnssec-signzone -S example.net
261 Verifying the zone using the following algorithms: NSEC3RSASHA1.
262 Zone signing complete:
263 Algorithm: NSEC3RSASHA1: ZSKs: 1, KSKs: 1 active, 0 revoked, 0 stand-by
266 SPECIFYING THE ENGINE ON THE COMMAND LINE
268 The OpenSSL engine can be specified in named and all of the dnssec-*
269 tools by using the "-E <engine>" command line option. If BIND 9 is built
270 with the --with-pkcs11 option, this option defaults to "pkcs11".
271 Specifying the engine will generally not be necessary unless for
272 some reason you wish to use a different OpenSSL engine.
274 If you wish to disable use of the "pkcs11" engine--for troubleshooting
275 purposes, or because the HSM is unavailable--set the engine to the empty
278 dnssec-signzone -E '' -S example.net
280 This causes dnssec-signzone to run as if it were compiled without the
281 --with-pkcs11 option.
283 RUNNING NAMED WITH AUTOMATIC ZONE RE-SIGNING
285 If you want named to dynamically re-sign zones using HSM keys, and/or to
286 to sign new records inserted via nsupdate, then named must have access
287 to the HSM PIN. This can be accomplished by placing the PIN into the
288 openssl.cnf file (in the above examples, /opt/pkcs11/usr/ssl/openssl.cnf).
290 The location of the openssl.cnf file can be overridden by setting the
291 OPENSSL_CONF environment variable before running named.
295 openssl_conf = openssl_def
297 engines = engine_section
299 pkcs11 = pkcs11_section
301 PIN = <PLACE PIN HERE>
303 This will also allow the dnssec-* tools to access the HSM without
304 PIN entry. (The pkcs11-* tools access the HSM directly, not via
305 OpenSSL, so a PIN will still be required to use them.)
307 PLEASE NOTE: Placing the HSM's PIN in a text file in this manner
308 may reduce the security advantage of using an HSM. Be sure this
309 is what you want to do before configuring BIND 9 in this way.