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: <Repository name= ”SoftHSM”> <Module>/usr/local/lib/libsofthsm.so</Module> <TokenLabel>OpenDNSSEC</TokenLabel> <PIN>1234</PIN> </Repository> 2. Replace the name of the repository such as: <Repository name= ”UtimacoHSM”> 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: <Module>/usr/lib/libcs2_pkcs11.so</Module> 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. <TokenLabel>OpenDNSSEC</TokenLabel> <PIN>utimaco123</PIN>