Integration Guide OpenDNSSEC 1.4.8 Debian 4.1.2, CentOS 6.7 Integration Guide: OpenDNSSEC 1.4.8
Imprint copyright 2016 Utimaco IS GmbH Germanusstrasse 4 D-52080 Aachen Germany phone +49 (0)241 / 1696-200 fax +49 (0)241 / 1696-199 web http://hsm.utimaco.com email [email protected] document version 1.2.0 date January 2016 author System Engineering HSM document no. IG_OpenDNSSEC all rights reserved No part of this documentation may be reproduced in any form (printing, photocopy or according to any other process) without the written approval of Utimaco IS GmbH or be processed, reproduced or distributed using electronic systems. Utimaco IS GmbH reserves the right to modify or amend the documentation at any time without prior notice. Utimaco IS GmbH assumes no liability for typographical errors and damages incurred due to them. All trademarks and registered trademarks are the property of their respective owners. Contents
1 Introduction 4
2 Overview 4
3 Requirements 5
3.1 Tested Operating Systems ...... 5
4 Procedures 6
4.1 Install CryptoServer Hardware ...... 6 4.2 Install SecurityServer Software ...... 6
4.3 Configure PKCS#11 R2 ...... 6 4.3.1 PKCS#11 R2 Slot Initialization ...... 6
4.4 Setup OpenDNSSEC ...... 7
4.4.1 Configure OpenDNSSEC ...... 7 4.4.2 Integration Test ...... 8
4.4.3 Sign a Domain Zone ...... 10
5 Further Information 14 Integration Guide: OpenDNSSEC 1.4.8
1 Introduction
This paper provides an integration guide explaining how to integrate a Hardware Security Module (HSM) – CryptoServer – with OpenDNSSEC 1.4.8 on a Linux operating system platform. Thereby
OpenDNSSEC provides a complete zone signing system which operates on HSM automatically. Con- figuration details – especially to domain name system configuration – that go beyond normal con-
figuration for the integration of hardware security module are not explained in this document. For further information to configure and setup e.g. BIND for a domain name system, it is referred to the documents and information of ISC1.
2 Overview
The Domain Name System (DNS) is a hierarchical naming system built on a distributed database for computers, services, or any resource connected to the Internet or a private network. Most im- portantly, it translates domain names meaningful to human-readable identifiers into the numerical identifiers associated with networking equipment for the purpose of locating and addressing these devices worldwide.
Often the Domain Name System is compared with the phone book of the worldwide internet. The orig- inal design of the Domain Name System did not include any security. Instead, it was developed as a simple scalable distributed system. The Domain Name System Security Extensions (DNSSEC) at- tempts to add security, while maintaining backwards compatibility to the existing Domain Name Sys- tem. The RFC 3833 attempts to document some of the known threats to the DNS and how DNSSEC tries to responds to those threats.
DNSSEC was designed to protect Internet resolvers from forged DNS data, such as that created by e.g. DNS cache poisoning. All answers from DNSSEC enabled domain name system are digitally signed.
By verifying the digital signature, a DNS resolver is able to check if the information is correct and complete to the information on the authoritative domain name server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect other information such as general- purpose cryptographic certificates too. Basically cryptographic keys are used to sign domain name related informations. The keys require extensively protection against being stolen or corrupted. A
1http://www.isc.org
Page 4 hardware security module is the best solution in maintaining highest security and performance for the protection of those keys.
The CryptoServer is a hardware security module developed by Utimaco IS GmbH , i.e. a physically pro- tected specialized computer unit designed to perform sensitive cryptographic tasks and to securely manage cryptographic keys and data. In a CryptoServer security system security-relevant actions can be executed and security relevant information can be stored. It can be used as a universal, indepen- dent security component for heterogeneous computer systems.
3 Requirements
Ensure that you have a copy of the CryptoServer Administration Guide and the CryptoServer
PKCS#11 R2 Interface. You should also have prepared an installed Linux operating system (ker- nel 2.6). If you are using PCIe card also compile and install the necessary driver for that card. This guide assumes that a Debian based Linux distribution is used.
Software- and Hardware Requirements
HSM Model Utimaco CryptoServer CSe-Series/Se-Series PCIe Utimaco CryptoServer CSe-Series/Se-Series LAN
REINER SCT cyberJack e-com
HSM Firmware Utimaco CryptoServer 3.30.0
Software Utimaco CryptoServer 3.30.0 OpenDNSSEC 1.4.8
3.1 Tested Operating Systems
The interoperability of the CryptoServer solution, an operating system and the OpenDNSSEC have been tested successfully for the following combinations:
Operating System CryptoServer OpenDNSSEC PCI Support Ethernet Support Version Version
Debian 4.1.2 x86/amd64 3.00.2 1.3.0b1 Yes Yes CentOS 6.7 x86/amd64 3.30.0 1.4.8 Yes Yes
Page 5 Integration Guide: OpenDNSSEC 1.4.8
4 Procedures
To integrate the CryptoServer with OpenDNSSEC and verify the functionality, complete the following steps:
1. Install CryptoServer hardware
2. Install CryptoServer software
3. Configure PKCS#11 R2
4. Setup OpenDNSSEC
4.1 Install CryptoServer Hardware
For more information on commonly installing and setting up CryptoServer PCIe/LAN, see the docu- mentation CryptoServer PCIe/LAN Operating and Installation Manual[3, 4]. There is no need to install any software specific for running CryptoServer. The CryptoServer comes with an already preinstalled set of firmware software.
4.2 Install SecurityServer Software
The SecurityServer software – this includes administrative and library software – has to be installed on your computer system manually. To install the necessary PKCS#11 R2 libraries it is referred to the CryptoServer PKCS#11vR2 Developer Guide[1]. Further configuration steps are explained next.
4.3 Configure PKCS#11 R2
The PKCS#11 R2 library and configuration files for Linux operating system have to be installed man- ually. For further installations steps, please refer to QuickStart Guide PKCS#11 R2 [2].
4.3.1 PKCS#11 R2 Slot Initialization
Initialize a PKCS#11 R2 slot to store the necessary cryptographic keys used for OpenDNSSEC later in this document. CONSOLE
# p11tool2 Login=ADMIN,:cs2:cyb:USB0 slot=0 Label=OpenDNSSEC InitToken=123456
# p11tool2 slot=0 LoginSO=123456 InitPin=utimaco123
Page 6 Here the InitPin parameter determines the PKCS#11 R2 user pin of a slot. This pin will be used later in this document for the PKCS#11 R2 user authentication.
4.4 Setup OpenDNSSEC
Currently the OpenDNSSEC software is available as software package but only in the unstable branch of Debian. Therefore we are going to build OpenDNSSEC from source code. To build OpenDNSSEC suc- cessfully, it is necessary to install several open-source packages OpenDNSSEC depends on. Further information to dependencies can be found at their web site2. Make sure that you install all required software using e.g. apt-get or aptitude and gem. If some packages are still missing while configuring OpenDNSSEC, rerun configure after installing the proper packages.
1. Download and extract the sources for OpenDNSSEC 1.4.8.3
2. Install required packages listed at
http://www.opendnssec.org/documentation/using-opendnssec/.
3. Configure :
CONSOLE
# ./configure
4. Build and install :
CONSOLE
# make
# make install
4.4.1 Configure OpenDNSSEC
After a successful installation of OpenDNSSEC several configuration files must be adjusted. The changes concern the configuration of HSM, location of zone files and signing policies. For the inte- gration we require to adjust the contents of the file conf.xml only. Among other configuration things – which are not part of this documentation – it contains a repository section.
OpenDNSSEC manages keys in so called repositories. OpenDNSSEC has two types of repositories. They differ in their manner of storage of keys. We use the PKCS#11 R2 type here because will store all keys within the CryptoServer. We only are going to adjust the repository section to connect to the HSM. All
2http://www.opendnssec.org/documentation/using-opendnssec/ 3http://www.opendnssec.org/download/
Page 7 Integration Guide: OpenDNSSEC 1.4.8
other adjustment we not described here and it is referred to documentation . Adapt the configuration file conf.xml as follows:
1. Locate the repository section in /etc/opendnssec/conf.xml:
2. Replace the name of the repository such as:
The repository name is often later used as parameter of OpenDNSSEC commands. Most of the
commands we will see in chapter 4.4.2.
3. Provide the location of the PKCS#11 R2 library as module information:
4. Adjust the values for PKCS#11 R2 token label and PKCS#11 R2 the user pin. Use the informa- tion you have entered in chapter 4.3.1 e.g.
4.4.2 Integration Test
In this chapter some of the basic PKCS#11 R2 operations in context of DNSSEC will be performed on the CryptoServer using the OpenDNSSEC utility ods-hsmutil. The aim of the next procedures is to show that it is possible to communicate with the HSM. Therefore actions like listing keys, key creation and deletion of keys will be performed. When you have logging enabled as mentioned in the previous chapter you verify the communication between OpenDNSSEC and the CryptoServer.
Page 8 1. Run the following command to assure a proper configuration of the CryptoServer PKCS#11 R2 environment and the OpenDNSSEC:
CONSOLE
# ods-hsmutil info
Repository: UtimacoHSM
Module: /usr/local/lib/libcs2_pkcs11.so
Slot: 0
Token Label: OpenDNSSEC
Manufacturer: Utimaco Safeware AG
Model: CryptoServer
Serial: CS50 CS309944
The PKCS#11 R2 slot 0 is used here as specified during the slot initialization in chapter 4.3.1.
2. Generate a 1024 bit RSA key:
CONSOLE
# ods-hsmutil generate UtimacoHSM rsa 1024
Generating 1024 bit RSA key in repository: UtimacoHSM
Key generation successful: bc60482f5afcb329cfe30a9a42954192
As already mentioned the repository name, which is UtimacoHSM in this case, is used for almost
all operations performed using the OpenDNSSEC utility ods-hsmutil.
3. List the contents of the repository including the previously generated RSA key:
CONSOLE
# ods-hsmutil list UtimacoHSM
Listing keys in repository: UtimacoHSM
1 key found.
Repository ID Type
------
UtimacoHSM bc60482f5afcb329cfe30a9a42954192 RSA/1024
Note the key ID as it necessary for the further operations.
Page 9 Integration Guide: OpenDNSSEC 1.4.8
4. Create a DNSKEY Resource Record using the previously generated RSA key:
CONSOLE
# ods-hsmutil dnskey bc60482f5afcb329cfe30a9a42954192 utimaco.com
utimaco.com. 3600 IN DNSKEY 256 3 5
AwEAAeC3+phKXXR/+isb0kXYgUIjbYwn6fcq68fHbT0FjNxtX
Z1lAhfRndqaJpQk+19a85JK2qlrwVoYUAyLa1KJRB2x4Pilcd
mTDsMkdekpsPlpCe4BimVB9hMILX8rFLcE7tyaZuWp3YikA22
I0BQTb9KNedP95Auz/zdiSiC/kVhd ;{id = 10263 (zsk), size = 1024b}
5. Delete the previously generated RSA key:
CONSOLE
# ods-hsmutil remove bc60482f5afcb329cfe30a9a42954192
Key remove successful.
6. Finally run a automatic test ods-hsmutil of the utility:
CONSOLE
# ods-hsmutil test UtimacoHSM
Please verify if all tests have been completely successful.
4.4.3 Sign a Domain Zone
In this section, we generate a zone-signing key (ZSK) and a key-signing key (KSK) and sign a domain zone using these keys. Since we initialized slot 0 and OpenDNSSEC as token label in section 4.3.1, we use this configuration to sign a zone. Before you go for signing, you have to update several con-
figuration files. Follow the below steps to sign a zone:
1. Before sign a zone, make sure you have properly configured conf.xml, kasp.xml and zonelist.xml
files which you can find in /etc/opendnssec/.
(a) conf.xml: This file provides overall configuration of OpenDNSSEC. You specify logging facility, HSM
repository, database location, system paths of other configuration files and privileges in this configuration file.
Page 10
Page 11 Integration Guide: OpenDNSSEC 1.4.8
(b) kasp.xml: This xml file is define policies those can be used to sign zones. Replace the name of the
repository such as:
For more details on this configuration file, visit www.opendnssec.org.
(c) zonelist.xml:
This file contains list of zones that will be signed and policy.
/var/opendnssec/signconf/example.utimaco.com.xml
/var/opendnssec/unsigned/example.utimaco.com
/var/opendnssec/signed/example.utimaco.com
Copy zone file which you want to sign into /etc/opendnssec/unsigned directory/.
Page 12 2. Run the following command to import your zone list and policy into the database.
CONSOLE
# ods-ksmutil setup
This commnad will always run first, if you run the system first time.
3. To start or stop two daemons, ods-signerd and ods-enforcerd of OpenDNSSEC, run the following
commands:
CONSOLE
# ods-control start
# ods-control stop
4. Generate keys and keys maintenance
CONSOLE
# ods-ksmutil key generate --policy
Where the interval defines how long the pool of created keys should last for. Note that OpenDNS- SEC will generate keys on the fly and use above command if there is a situation where user would
prefer to pre-generating a pool of keys. However the timings of this generation will not be easy to predict. After third step, the keys will be generated automatically and you can visualize the
details by running below command:
CONSOLE
# ods-ksmutil key list
Keys:
Zone: Keytype: State: Date of next transition:
example.utimaco.com ZSK active 2010-10-16 09:59:28
example.utimaco.com KSK ready waiting for ds-seen
To change the state of KSK from ready to active(as you can see above), run below command with the CKA_ID:
CONSOLE
# ods-ksmutil key ds-seen -z example.utimaco.com -k
If KSK is in publish state, wait until key is available in ready state.
Page 13 Integration Guide: OpenDNSSEC 1.4.8
5. When you update the any configuration file such as conf.xml, kasp.xml or zonelist.xml, you must run the below command:
CONSOLE
# ods-ksmutil update all
6. When you update the contents of unsigned zone file, you must manually tell signer engine to sign a unsigned zone (or re-sign zone) again by running following command:
CONSOLE
# ods-signer sign
5 Further Information
This document forms a part of the information and support which is provided by the Utimaco IS
GmbH. Additional documentation can be found on the product CD in the documentation directory. All CryptoServer product documentation is also available at the Utimaco IS GmbH website: http://hsm.utimaco.com
Page 14 References
[1] UTIMACO IS GMBH. CryptoServer PKCS#11vR2 Developer Guide, 2012. 2012-0007.
[2] UTIMACO IS GMBH. QuickStart Guide – PKCS#11 (R2) – Linux, 2014. SGCS_QSG_PKCS11_en.
[3] UTIMACO IS GMBH. CryptoServer LAN V4 – Operating Manual, 2015. M012-0002-en.
[4] UTIMACO SAFEWARE AG. SafeGuard CryptoServer PCIe – Operating and Installation Manual, 2011. M010-0004-en.
Page 15 Contact
Utimaco IS GmbH Germanusstraße 4 D - 52080 Aachen Germany phone +49 241 1696 - 200 fax +49 241 1696 - 199 web https://hsm.utimaco.com email [email protected]